Disaggregated LLM Inference

2024 년 LLM 서빙 시스템(vLLM, TensorRT-LLM, SGLang…)이 대부분 continuous batching 위에 서 있다. 한 GPU 가 prefill 토큰과 decode 토큰을 같은 forward 안에 섞는다. 이 강의는 그 “섞는다” 가 — 두 단계의 자원 형태가 다르기 때문에 — TTFT 와 TPOT 둘 다를 동시에 최적화하지 못한다고 진단하고, 두 단계를 다른 GPU 로 보내는 길을 깐다.

강의 자체의 transcript 가 비어 있으므로 이 노트는 두 편의 논문과 production 자료를 base 로 재구성한다. 두 논문이 핵심이다.

• Splitwise (Microsoft Research, 2024 ISCA) — Patel et al. “Splitwise: Efficient generative LLM inference using phase splitting.” Azure 환경에서의 prefill/decode 분리.
• DistServe (UCSD, 2024 OSDI) — Zhong et al. “DistServe: Disaggregating prefill and decoding for goodput-optimized LLM serving.” SLO 기반 스케줄링과 GPU pool 자동 분배.

발표자 Junda Chen 은 DistServe 공저자로 알려져 있다 (확인 필요 — 강의 transcript 없음). 두 시스템 모두 같은 결론에 도달한다 — 같은 GPU 안에서는 prefill 의 큰 batch 가 decode 의 latency 를 잡아먹는다. 강의의 인지적 frame 은 그 자리부터 시작한다.

그래서 강의의 서사는 이 흐름이다 — (§02) 왜 두 단계의 자원 형태가 다른지 산수로 보고 → (§03) 같은 GPU 에 두면 어떤 interference 가 발생하는지 → (§04–05) 분리하면 KV cache 를 옮겨야 하는데 그 비용이 얼마인지 → (§07) 결과적으로 같은 SLO 아래에서 얼마나 더 많은 요청을 받을 수 있는지.

두 단계의 차이를 한 줄로 요약하면 — prefill 은 토큰을 한꺼번에 본다, decode 는 한 번에 한 토큰. 같은 attention/FFN 이 한쪽에서는 큰 GEMM 으로 돌고 한쪽에서는 GEMV 의 연속이 된다. 이 비대칭이 disaggregation 의 산수적 출발점이다.

이 관찰은 latency 메트릭에도 그대로 박힌다 — TTFT (time to first token) 는 prefill 비용에 묶이고 (compute / FLOPS), TPOT (time per output token) 는 decode 비용에 묶인다 (HBM bandwidth). 한 GPU 안에서 둘을 같이 돌리는 한, batch 를 늘려서 하나를 살리면 다른 하나가 죽는다.

vLLM 의 continuous batching 은 매 step 마다 새 요청의 prefill 을 진행 중인 decode batch 와 함께 돈다. 평균 throughput 은 좋아지지만 — 그 step 의 decode 토큰이 prefill 의 거대한 GEMM 끝나기를 기다린다. 한 step 의 latency 가 boundary 에서 spike. 이게 disaggregation 이 풀려는 첫 번째 구체적 문제다.

DistServe 논문의 핵심 표현 — “decoupling these two phases lets us tune their parallelism / batch / placement independently for goodput, instead of throughput.” goodput = SLO 안에서 받은 요청 수. 평균 throughput 이 아니라 SLO 만족한 요청의 throughput 을 본다는 게 disaggregation 의 metric 정의 자체다.

prefill GPU 가 만든 결과는 KV cache다 — layer 별로 K, V 두 텐서. decode GPU 가 attention 을 돌리려면 이 KV 가 그 GPU 의 HBM 에 있어야 한다. 그래서 옮겨야 한다. 이 비용이 분리의 이득을 잡아먹지 않는지가 disaggregation 의 운명을 결정한다.

긴 context 모델 — 32K, 128K — 에서는 KV cache 가 4 GB, 16 GB 까지 커진다. 그러면 PCIe 라도 100ms+ 의 migration 이 prefill 시간 (~수백 ms) 의 상당 부분이 된다. 이 영역은 chunked-migration / overlapping (§05) 으로만 풀린다.

naive 한 구현은 prefill 을 끝까지 다 돌린 뒤 KV cache 80 layer 를 통째로 보낸다. Splitwise / DistServe 둘 다 같은 트릭을 쓴다 — layer i 의 KV 가 만들어지는 즉시 layer i 를 send 한다. prefill 의 layer i+1 GEMM 이 도는 동안 layer i 의 KV 가 PCIe / NVLink 위로 흐른다. compute 와 통신이 겹친다.

# 의사코드 — layer-pipelined KV send (prefill 측)
comm_stream = torch.cuda.Stream()

for i, layer in enumerate(model.layers):
    h, kv_i = layer.forward(h)         # default stream
    with torch.cuda.stream(comm_stream):
        comm_stream.wait_stream(
            torch.cuda.current_stream())
        kv_send_async(
            kv_i,                      # {K_i, V_i}
            dst=decode_rank,
            tag=(req_id, i),
        )
# 마지막 layer 만 sync 대기
torch.cuda.current_stream().wait_stream(comm_stream)

분리의 가치는 같은 자원 예산 안에서 비교해야 보인다. “8장 GPU 가 있으면 다 같이 prefill+decode 를 하는 게 좋은가, 아니면 4장은 prefill, 4장은 decode 로 묶는 게 좋은가?” 두 시스템 모두 같은 비교를 한다. 결과는 모델 / SLO / 워크로드 mix 에 따라 다르지만 — 긴 prompt + 짧은 output 일수록 분리가 이긴다.

위 수치는 일반적 70B/8GPU 비교를 재구성한 예시. DistServe 논문 Table 3 / Splitwise eval 의 트렌드를 기준으로 — 절대값은 모델·SLO·워크로드 mix 에 따라 크게 변함. 확인 필요.

두 논문은 같은 시기 (2024) 에 같은 아이디어를 다른 각도로 구현했다. Splitwise 가 Azure 의 production 워크로드를 실제 분석해 분리의 정당성을 깔았고, DistServe 가 SLO 기반 자동 placement / parallel sweep 을 형식화했다. 같이 보면 — 한쪽은 시스템 설계의 outer envelope, 다른 쪽은 inner optimization.

disaggregation 을 production 에 도입하기 전에 짚을 trade-off. 그저 “분리하면 빨라진다” 가 아니라 — 어떤 워크로드 / 어떤 모델 / 어떤 토폴로지에서 이득이 있고 어디서 잃는가.

또 하나의 production 관찰 — prefill GPU 의 utilization 이 떨어질 때가 잦다. prefill 은 burst 형태 (요청이 들어올 때만 발생) 인데 decode 는 sustained (요청이 살아있는 한 계속). 같은 4+4 라도 prefill GPU 가 idle 인 시간이 길다면 — 그 GPU 를 일시적으로 decode 로 합류시키는 elastic reconfig 가 다음 단계. SGLang / vLLM v1 의 disagg 기능이 이 방향.

2024 후반부터 disaggregation 의 두 갈래가 진행 중이다. (a) chunked prefill + 분리 hybrid — 단순 분리의 자원 활용 단점을 chunked 로 보완. (b) attention 자체 분리 — 모델의 attention layer 를 KV-heavy machine 으로, FFN/MLP 를 compute-heavy machine 으로.

disaggregation 의 핵심 사실들과 직접 읽어야 할 자료들을 묶어둔다.

손에 새기기 — 실습 시퀀스

1. KV cache 크기 산수 — 가지고 있는 모델의 layer / n_kv_heads / head_dim 을 곱해 KV bytes/token 을 계산. prompt 평균 길이를 곱해 한 요청당 KV 크기, 평균 active req 수를 곱해 cluster KV footprint 를 추정.
2. vLLM 으로 co-located baseline — 8-GPU 노드에서 70B 를 TP=8 로 띄우고 sweep. --max-num-batched-tokens 와 --max-num-seqs 를 바꿔가며 TTFT/TPOT 분포 측정. p99 spike 가 어디서 생기는지 확인.
3. vLLM disagg 옵션 켜기 — 같은 cluster 에서 --kv-transfer-config 으로 prefill/decode 분리. 4+4 배치. 같은 trace 로 비교.
4. chunked prefill 와 비교 — SGLang 의 chunked prefill 모드와 disagg 의 4+4 모드를 같은 trace 로 돌리고 — 어떤 워크로드 mix 에서 어느 쪽이 이기는지 표.
5. NCCL trace 로 transfer 시각화 — NCCL_DEBUG=INFO 로 KV transfer 의 실제 시간을 timeline 위에 찍어 본다. layer-pipelined hide 가 잘 일어났는지 직접 확인.
6. cross-node 시도 — 두 노드 사이에 InfiniBand 로 disagg. 같은 노드 NVLink 와 비교해 latency 추가분 측정. 200 Gb/s vs 400 Gb/s 의 영향.

disaggregation 은 LLM serving 의 큰 frame 이라 GPU Mode 의 여러 강의와 직접 닿는다. 어떤 강의가 같은 trade-off 의 다른 면을 다루는지를 묶어둔다.

이 강의는 video transcript 추출이 실패한 상태라 — 본문은 두 논문(Splitwise, DistServe)과 production 자료 위에서 재구성했다. 강의에서만 등장했을 가능성이 있는 사실들을 직접 영상에서 검증해야 한다.

• 발표자 Junda Chen 의 정확한 소속과 강의에서 다룬 자기 work — DistServe 공저자 또는 vLLM disagg 구현자 후보. transcript 없어 강의 내내 어떤 시스템을 중심으로 깐 건지 미확인.
• 강의에서 보여준 실제 benchmark 수치 — 본 노트의 30~80% 같은 수치는 두 논문 평균치를 재구성한 예시. 강의에서 더 구체적인 production trace (Azure / 확인 필요) 가 등장했을 가능성.
• chunked prefill vs full disagg 의 trade-off 비교 — 강의에서 두 접근의 어느 쪽을 더 강하게 옹호했는지 미확인. 이 노트는 두 접근이 hybrid 로 합쳐진다는 frame 으로 정리.
• cross-node / cross-cluster 동작 — InfiniBand / RDMA 위에서 KV transfer 의 실제 latency 분포는 강의에서 다뤘을 가능성이 높지만 직접 인용 없음.
• vLLM 의 disagg 구현 디테일 — vLLM 의 connector / KV transfer protocol 위치. 2024 후반부터 v1 에 들어가는 중. 강의 시점의 안정도가 미확인.
• 모델별 분리 이득의 차이 — Llama-3-70B / Mixtral 8x22B / DeepSeek-V3 처럼 architecture (GQA, MoE, MLA) 가 다르면 KV cache 형태도 다르다. 어느 모델에서 가장 큰 이득이 나는지 강의 안 정량화 미확인.
• elastic reconfiguration — 시간대별 traffic 변동에 따라 prefill/decode pool 크기를 동적으로 바꾸는 시스템 — 강의에서 어느 정도 깊이로 다뤘는지 미확인. SGLang / vLLM 모두 이 방향.