Disaggregated LLM Serving Analysis
Disaggregated LLM Serving 심층 분석
Prefill-Decode Disaggregation · KV Transfer · Network Fabric · Remote Cache · Elastic Pooling
Disaggregated LLM serving은 prefill과 decode를 같은 GPU 위에서 함께 처리하지 않고, 서로 다른 자원 특성에 맞는 풀로 분리해 운영하는 구조입니다. 핵심은 단순한 역할 분담이 아니라 prefill이 만든 KV를 decode 쪽으로 어떤 지연과 비용으로 전달하느냐를 시스템의 1급 문제로 다루는 데 있습니다.
최근 연구들은 이 분리가 TTFT와 TPOT를 동시에 다루는 방법으로 수렴하고 있습니다. DistServe는 phase를 다른 GPU에 배치해 간섭을 제거하고, Sarathi-Serve는 chunked prefill과 stall-free scheduling으로 decode를 멈추지 않게 만들며, Mooncake는 KVCache 중심의 분리형 아키텍처로 장문맥과 과부하 상황을 함께 다룹니다.
1. 왜 Prefill과 Decode를 분리하려 하는가
긴 프롬프트를 인코딩하는 prefill은 큰 GEMM 비중이 높아 연산 집약적이며, 첫 토큰까지의 시간(TTFT)에 직접 영향을 줍니다. 반면 decode는 비교적 작은 step을 오래 반복하면서 KV를 지속적으로 읽기 때문에 메모리 대역폭과 locality가 더 중요합니다.
즉 두 단계는 같은 추론이지만 좋아하는 하드웨어 조건이 다릅니다. 그래서 한 풀은 prefill 효율에, 다른 풀은 decode 안정성에 맞게 구성하면 전체 클러스터 활용이 더 좋아질 수 있습니다. DistServe가 TTFT와 TPOT를 분리해 최적화한 이유도 여기에 있습니다.
그림 1. prefill과 decode가 요구하는 자원 특성의 차이
2. 핵심 개념
| 개념 | 의미 | 서빙 관점 |
|---|---|---|
| Prefill | 프롬프트 전체를 한 번에 인코딩하는 단계 | TTFT를 좌우하는 연산 집약 구간 |
| Decode | 다음 토큰을 하나씩 생성하는 단계 | TPOT와 tail latency를 좌우하는 메모리 집약 구간 |
| KV Handoff | prefill에서 만든 KV를 decode 풀로 넘기는 과정 | 전송 지연과 설치 비용이 핵심 병목 |
| Affinity | 같은 prefix나 KV를 가진 요청을 가까운 decode 풀로 모으는 정책 | 캐시 적중률과 locality를 높임 |
| Remote KV | KV를 local HBM 밖의 DRAM, CXL, 네트워크 풀에 두는 방식 | 용량은 늘지만 지연 예산을 더 써야 함 |
3. 비교/분석
| 접근 | 배치/배포 방식 | 강점 | 한계 |
|---|---|---|---|
| Colocated serving | 하나의 GPU/풀에서 prefill과 decode를 함께 처리 | 구조가 단순하고 전송 비용이 없다 | prefill이 decode를 흔들기 쉽다 |
| Chunked prefill / stall-free batching | 같은 클러스터 안에서 prefill을 잘게 나눠 decode 사이에 섞는다 | throughput과 latency의 균형을 맞추기 쉽다 | 자원 분리는 아니어서 간섭이 남는다 |
| Disaggregated serving | prefill과 decode를 다른 GPU 또는 다른 클러스터에 둔다 | phase별 자원 최적화가 쉽고 간섭이 줄어든다 | KV handoff, affinity, routing이 복잡해진다 |
DistServe는 분리형 배치에서 7.4x 더 많은 요청 또는 12.6x 더 타이트한 SLO를 보고했고, Sarathi-Serve는 Mistral-7B에서 2.6x, Falcon-180B에서 최대 5.6x의 serving capacity 향상을 보고했습니다. Mooncake는 KVCache-centric disaggregation으로 장문맥 워크로드와 과부하 상황을 함께 다룹니다.
4. 기본 구조는 KV를 서비스 경계 너머로 넘기는 구조다
disaggregation에서는 ingress가 요청을 받고, prefill cluster가 프롬프트를 처리해 layer별 KV를 생성합니다. 이후 이 KV를 chunk 또는 page 단위로 직렬화해 decode cluster로 보내고, decode 쪽은 이를 block pool에 적재한 뒤 active sequence에 연결합니다.
이때 병목은 '어디서 계산하느냐'만이 아니라 'KV를 언제 설치하고 어느 decode 노드에 붙이느냐'로 이동합니다. 그래서 네트워크 계층, install metadata, affinity 정책이 모델 자체만큼 중요해집니다.
- ingress가 요청을 받고 prefix와 queue 상태를 본다.
- prefill cluster가 프롬프트를 처리하고 layer별 KV를 만든다.
- KV를 chunk나 page 단위로 직렬화해 fabric으로 보낸다.
- decode cluster가 local block pool에 KV를 설치하고 sequence에 연결한다.
- scheduler는 local fast path와 remote path를 함께 보며 다음 토큰 생성을 이어간다.
그림 2. ingress, prefill cluster, KV transfer, decode cluster로 이어지는 기본 구조
Remote KV는 메모리 절약이자 네트워크 의존성이다
remote KV 또는 disaggregated cache는 decode 노드의 HBM 압박을 줄여 주지만, 반대로 latency budget 일부를 네트워크에 맡깁니다. 따라서 remote path와 local fast path를 함께 두고, 자주 쓰는 prefix는 가까운 곳에 고정하는 식의 계층형 운영이 많습니다.
prefill이 만든 KV는 프롬프트 길이와 layer 수에 비례해 커지므로, 전송 비용이 작지 않습니다. 작은 요청은 serialization과 설치 고정비가 문제이고, 큰 요청은 네트워크 대역폭과 수신 측 install 지연이 병목이 됩니다.
또한 decode가 KV 도착을 기다리는 동안은 GPU가 계산할 준비가 되어 있어도 실제 토큰 생성이 지연될 수 있습니다. 그래서 page 정렬, chunk streaming, partial install, KV compression과 같은 보완 기법이 함께 따라옵니다.
그림 3. build, pack, ship, install, attach로 이어지는 KV handoff 파이프라인
5. 장단점
| 상황 | 유리한 이유 | 불리한 이유 |
|---|---|---|
| 긴 프롬프트가 많고 생성은 짧다 | prefill과 decode의 자원 성격이 크게 달라 분리 이득이 크다 | KV handoff가 길어지면 이득이 줄어든다 |
| 멀티테넌트 decode pool을 안정적으로 유지하고 싶다 | decode 쪽을 따로 보호할 수 있다 | 운영 정책과 장애 면이 커진다 |
| prefix reuse가 높다 | affinity와 cache hit가 좋아진다 | 요청이 자주 바뀌면 remote fetch가 반복된다 |
| 네트워크가 빡빡하다 | local pool의 HBM 압박은 줄일 수 있다 | 전송 지연이 TPOT를 갉아먹는다 |
긴 프롬프트가 많고 생성 길이는 짧거나, prefill burst와 decode steady-state를 분리해 관리하고 싶은 워크로드에서는 disaggregation의 이득이 큽니다. 또한 멀티테넌트 환경에서 decode pool을 안정적으로 유지하고 싶을 때도 장점이 분명합니다.
반대로 KV 전송 지연이 충분히 작지 않거나, affinity를 잃어 remote fetch가 반복되면 분리 이득이 빠르게 줄어듭니다. 운영 복잡도와 장애면이 커진다는 점도 실제 도입 장벽입니다.
그림 4. disaggregation이 유리한 경우, 비용이 커지는 경우, 실전 보완책
6. 관련 기술
prefill cluster와 decode cluster가 분리되면, 스케줄러는 단일 GPU 위의 batch만 보는 것이 아니라 두 풀의 큐 길이, KV 전송 대기, decode affinity, remote cache 상태까지 함께 판단해야 합니다. 동일 prefix를 공유하는 요청은 같은 decode 쪽으로 모으는 편이 유리하고, prefill burst는 decode ITL을 흔들지 않도록 별도 완충이 필요합니다.
즉 disaggregated serving은 배포 토폴로지 변경이면서 동시에 스케줄링 문제의 차원 확장입니다. prefix caching, paged KV, admission control, elastic pooling이 함께 묶여야 의미 있는 성능이 나옵니다.
그림 5. router, prefill service, KV fabric, decode service로 이어지는 disaggregated serving 스택
| 자료 | 포인트 |
|---|---|
| Continuous Batching Analysis | token-level slot refill과 chunked prefill로 prefill/decode 간섭을 줄인다 |
| Prefix Caching Analysis | shared prefix의 KV를 재사용해 prefill 중복을 줄인다 |
| KV Cache Offloading Analysis | KV budget을 HBM 밖으로 넓혀 disaggregated cache와 이어진다 |
| LLM Inference Scheduler Analysis | admission, backpressure, queue 길이를 함께 본다 |
| DistServe: arXiv:2401.09670 | prefill/decode를 다른 GPU에 분리하고 TTFT/TPOT 요구를 함께 맞춘다 |
| Sarathi-Serve: arXiv:2403.02310 | chunked-prefills와 stall-free schedules로 batching 간섭을 줄인다 |
| Mooncake: arXiv:2407.00079 | KVCache-centric disaggregation, early rejection, 장문맥 중심 운영 |
DistServe와 Sarathi-Serve는 같은 prefill/decode 문제를 서로 다른 운영 철학으로 풀고, Mooncake는 이를 분리형 cache와 scheduler까지 확장합니다. 이 문서의 핵심은 분리 자체보다 KV handoff, affinity, 그리고 스케줄러가 함께 움직여야 한다는 점입니다.
7. 핵심 정리
disaggregated LLM serving의 본질은 prefill과 decode의 비대칭성을 인정하고, 두 단계를 각기 다른 최적화 대상으로 분리하는 데 있습니다. 하지만 성능의 진짜 승부처는 분리 자체가 아니라 그 사이의 KV handoff와 affinity 유지입니다.
따라서 이 구조는 단순히 GPU를 둘로 나누는 아이디어가 아니라, 네트워크, 메모리, 캐시, 스케줄러가 함께 재설계되는 분산 serving 아키텍처로 이해하는 편이 정확합니다. TTFT와 TPOT를 각각 따로 보면서도, 실제 운영에서는 SLO와 큐 길이를 함께 묶어 봐야 합니다.
- prefill과 decode를 분리하면 compute-bound 단계와 memory-bound 단계를 서로 다른 풀에 맞춰 최적화할 수 있습니다.
- 하지만 실제 성능을 가르는 요소는 KV handoff의 직렬화, 전송, 설치 비용과 decode affinity 유지입니다.
- 따라서 disaggregated serving은 단순한 배치 분리가 아니라 router, KV fabric, scheduler, remote cache를 함께 설계하는 분산 추론 구조입니다.
- 네트워크 지연이 큰 환경에서는 local fast path, page 단위 스트리밍, sticky routing 같은 보완책이 필요합니다.