분리형 Prefill/Decode — NVIDIA Dynamo와 llm-d

프리필(Prefill)은 연산 병목(compute-bound)이고 디코드(decode)는 메모리 병목(memory-bound)입니다. 둘을 같은 GPU에서 실행하면 한쪽 자원이 낭비됩니다. 분리(Disaggregation)는 프리필과 디코드를 별도의 풀(pool)로 나누고, NIXL(RDMA/InfiniBand 또는 TCP 폴백)을 통해 KV 캐시(KV cache)를 전달합니다. NVIDIA Dynamo(GTC 2025 발표, 1.0 정식 출시)는 vLLM/SGLang/TRT-LLM 위에 올라가는 상위 스택(stack-above) 오케스트레이터입니다. Planner Profiler와 SLA Planner가 프리필 대 디코드 비율을 자동으로 맞춰(rate-match) 서비스 수준 목표(SLO)를 충족시킵니다. NVIDIA가 공개한 처리량(throughput) 개선치는 대략 다음 범위에 있습니다. developer.nvidia.com(2025-06)은 GB200 NVL72 + Dynamo 환경에서 DeepSeek-R1 MoE가 중간 지연(medium-latency) 영역 기준으로 약 6배 개선됨을 보여주고, Dynamo 제품 페이지(developer.nvidia.com, 게시일 미상)는 GB300 NVL72 + Dynamo가 Hopper 대비 최대 50배 MoE 처리량을 낸다고 광고합니다. "30x" 수치는 풀스택(full-stack) Blackwell + Dynamo + DeepSeek-R1 보고들을 모은 커뮤니티 집계(community aggregate)입니다. 정확히 30배라고 명시한 단일 1차 출처(primary source)는 찾지 못했으므로 방향성 있는 주장(directional claim)으로 다뤄야 합니다. llm-d(Red Hat + AWS)는 쿠버네티스 네이티브(Kubernetes-native)입니다. 프리필, 디코드, 라우터(router)를 각각 독립된 서비스(Service)로 두고 역할별 HPA(수평 자동 스케일러)를 적용합니다. llm-d 0.5는 계층적 KV 오프로딩(hierarchical KV offloading), 캐시 인식 LoRA 라우팅(cache-aware LoRA routing), UCCL 네트워킹, 0까지 축소(scale-to-zero)를 추가합니다. 경제성 측면에서, 여러 고객 공개 자료를 종합한 내부 합산(internal rollup)에 따르면 동일 SLA 조건에서 코로케이트(colocated) 서빙에서 Dynamo 기반 분리형 서빙으로 전환할 때 연 2백만 달러 규모의 추론(inference) 지출에서 3040% 절감, 즉 연 60만80만 달러 절감이 시사됩니다. 이 $2M→$600-800K 수치는 단일 공개 사례 연구(published case study)가 아니라 내부 합성치(internal composite)입니다. 인용 출처(reference citation)가 아니라 자릿수 기준점(order-of-magnitude anchor)으로 사용해야 합니다. 짧은 프롬프트(512 토큰 미만, 짧은 출력)에는 전송 비용을 정당화할 만한 이득이 나오지 않습니다.

유형: Learn 언어: Python (표준 라이브러리, 분리형 대 코로케이트 비교용 토이 시뮬레이터) 선수 지식: Phase 17 · 04 (vLLM Serving Internals), Phase 17 · 08 (Inference Metrics) 예상 시간: 약 75분

학습 목표

• 프리필과 디코드가 왜 서로 다른 최적 GPU 할당(optimal GPU allocation)을 갖는지 설명하고, 코로케이션(colocation)에서 발생하는 낭비를 정량화합니다.
• 분리형 아키텍처를 도식화합니다. 프리필 풀, 디코드 풀, NIXL을 통한 KV 전송, 라우터가 포함됩니다.
• 분리가 이득을 내지 못하는 조건(짧은 프롬프트, 짧은 출력)을 말할 수 있습니다.
• NVIDIA Dynamo(상위 스택형)와 llm-d(쿠버네티스 네이티브형)를 구분하고, 각각이 어울리는 운영 맥락(operational context)에 연결합니다.

문제

8장의 H100에서 Llama 3.3 70B를 실행한다고 합시다. 혼합 워크로드(긴 프롬프트 + 짧은 출력)에서는 대부분의 연산이 프리필에 쓰였기 때문에 디코드 동안 GPU가 유휴 상태(idle)로 남습니다. 다른 워크로드(짧은 프롬프트 + 긴 출력)에서는 그 반대가 일어납니다. 프리필과 디코드를 같이 두는 코로케이트 구성은 결국 둘 다 과잉 프로비저닝(over-provision)한다는 뜻입니다.

예산에 미치는 영향은 큽니다. GPU 시간의 20~40%가 잘못된 자원에서 낭비됩니다. 메모리 병목인 디코드를 돌리려고 H100의 연산 능력을 사고 있거나, 연산 병목인 프리필을 돌리려고 H100의 HBM 대역폭(bandwidth)을 사고 있는 셈입니다. 둘 다 비싼 낭비입니다.

분리는 프리필과 디코드를 각자의 병목에 맞춰 크기를 조정한(sizing) 별도의 풀로 나눕니다. KV 캐시는 고대역폭 인터커넥트(high-bandwidth interconnect)를 통해 프리필 풀에서 디코드 풀로 이동합니다.

개념

병목이 다른 이유

프리필(Prefill) — 입력 프롬프트 전체에 대해 트랜스포머(transformer)를 한 번의 순전파(forward)로 돌립니다. 행렬 곱(matrix multiplication)이 지배하므로 연산 병목입니다. H100 FP8은 유효 처리량 기준 약 2000 TFLOPS를 제공합니다. 배치 효율(batch efficiency)도 좋습니다. 한 번의 순전파가 많은 토큰을 동시에 처리하기 때문입니다.

디코드(Decode) — 한 번에 한 토큰씩 생성하며 매 반복마다 전체 가중치(weights)를 읽습니다. 메모리 대역폭 병목입니다. HBM3는 약 3 TB/s를 제공합니다. 배치 효율은 동시성이 높을 때(high concurrency)만 좋습니다. 가중치 읽기가 배치 전체에 걸쳐 분산 상각(amortize)되기 때문입니다.

둘을 코로케이트하면 두 작업 모두에 최적화된 GPU를 사는 셈입니다. H100은 두 작업 모두 잘 처리하지만 어느 경우에도 비용은 같습니다. 규모가 커지면 프리필 풀은 H100/연산 중심으로, 디코드 풀은 H200/메모리 중심 또는 공격적인 양자화(aggressive quantization)를 적용한 구성으로 분리하고 싶어집니다.

아키텍처

            ┌──────────────┐
  Request → │    Router    │ ───────────────────────┐
            └──────┬───────┘                        │
                   │                                │
                   ▼ (prompt only)                  │
            ┌──────────────┐    KV cache    ┌───────▼──────┐
            │ Prefill pool │ ─── NIXL ────► │ Decode pool  │
            │  (compute)   │                │  (memory)    │
            └──────────────┘                └──────┬───────┘
                                                   │ tokens
                                                   ▼
                                                 Client

NIXL은 NVIDIA의 노드 간 전송 계층(inter-node transport)입니다. 가능하면 RDMA/InfiniBand를 사용하고, 그렇지 않으면 TCP 폴백을 사용합니다. 전송 지연(transfer latency)은 실제로 발생하는 비용입니다. 70B FP8 모델에서 4K 토큰 프롬프트의 KV 캐시를 옮기는 데 보통 20~80ms가 걸립니다. 그래서 짧은 프롬프트로는 분리가 정당화되지 않습니다. 전송 비용(transfer tax)이 절감액보다 커지기 때문입니다.

Dynamo와 llm-d 비교

NVIDIA Dynamo(GTC 2025 발표, 1.0 정식 출시):

• vLLM, SGLang, TRT-LLM 위에 오케스트레이터로 올라갑니다.
• Planner Profiler가 워크로드를 측정하고, SLA Planner가 프리필 대 디코드 비율을 자동으로 구성합니다.
• 러스트(Rust) 코어와 파이썬(Python) 확장성을 갖춥니다.
• 처리량 개선: NVIDIA는 GB200 NVL72 + Dynamo 환경에서 DeepSeek-R1 MoE가 중간 지연 영역 기준 6배라고 보고합니다(developer.nvidia.com, 2025-06). 풀스택 Blackwell + Dynamo + DeepSeek-R1 구성에서 "최대 30배"라는 커뮤니티 보고는 단일 1차 출처가 없으므로 방향성 있는 수치로 다뤄야 합니다.
• GB300 NVL72 + Dynamo: Dynamo 제품 페이지 기준 Hopper 대비 최대 50배 MoE 처리량(developer.nvidia.com, 게시일 미상).

llm-d(Red Hat + AWS, 쿠버네티스 네이티브):

• 프리필, 디코드, 라우터를 각각 독립된 쿠버네티스 서비스로 둡니다.
• 역할별 HPA를 사용하며, 신호로는 프리필의 큐 깊이(queue depth)와 디코드의 KV 사용률(KV utilization)을 씁니다.
• topologyConstraint packDomain: rack 설정은 고대역폭 KV 전송을 위해 프리필과 디코드의 클리크(clique)를 같은 랙(rack)에 묶어 배치합니다.
• llm-d 0.5(2026): 계층적 KV 오프로딩, 캐시 인식 LoRA 라우팅, UCCL 네트워킹, 0까지 축소를 제공합니다.

관리형 상위 스택 오케스트레이터를 원한다면 Dynamo를 사용합니다. 쿠버네티스 네이티브 프리미티브(primitive)를 원하고 CNCF 생태계에 헌신하기로 했다면 llm-d를 사용합니다.

경제성

내부 합성치이며, 단일 공개 사례 연구가 아니라 자릿수 기준점입니다.

• 코로케이트 서빙에서 연 2백만 달러의 추론 지출.
• Dynamo를 적용한 분리형 서빙으로 전환.
• 동일한 요청 볼륨(request volume), 동일한 P99 지연 SLA.
• 보고된 절감액: 연 60만80만 달러(3040% 감소).
• 새 하드웨어 추가는 없음.

이 수치는 단일 인용 가능 사례 연구가 아니라 여러 고객 공개 자료에서 합성한 것입니다. 가장 가까운 공개 데이터 포인트는 Dynamo KV 라우팅을 통해 TTFT가 2배 빨라지고 처리량이 61% 높아졌다는 Baseten 자료(baseten.co, 2025-10)와, 4060% KV 적중률(KV hit rate)에서 토큰 당 비용 효율(tokens/$)이 60130% 늘어난다는 VAST + CoreWeave 전망치(vastdata.com, 2025-12)입니다. 절감은 각 풀을 적정 규모로 맞추는(right-sizing) 데서 나옵니다. RAG처럼 8K 이상 접두(prefix)를 갖는 프리필 비중이 큰 워크로드가 균형 잡힌 워크로드보다 더 큰 이득을 봅니다.

분리하지 말아야 할 때

• 프롬프트가 512 토큰 미만이고 출력이 200 토큰 미만일 때: 전송 비용이 이득을 압도합니다.
• 작은 클러스터(GPU 4장 미만): 풀 다양성이 충분하지 않습니다.
• 팀이 역할별 스케일링을 갖춘 두 개의 GPU 풀을 운영할 수 없을 때: Dynamo가 돕긴 하지만 간단한 작업은 아닙니다.
• RDMA 패브릭(fabric)이 없을 때: TCP 전송 비용이 더 큽니다.

라우터는 Phase 17 · 11과 통합됩니다

분리형 라우터는 KV 캐시를 인식합니다(Phase 17 · 11). 요청은 자신의 접두(prefix)를 가지고 있는 디코드 풀로 도착합니다. 매칭이 없으면 프리필 → 디코드 흐름을 탑니다. 적중률과 분리는 함께 시너지(compound)를 냅니다. 캐시 인식 라우터가 새로운 프리필이 필요한지 자체를 결정합니다.

진짜 숫자는 Blackwell의 MoE에서 나온다

GB300 NVL72 + Dynamo는 Hopper 기준선 대비 50배 MoE 처리량을 보여줍니다. MoE 전문가 라우팅(expert routing)은 프리필에서는 연산 중심이고 디코드에서는 메모리 중심(전문가 캐시 때문)이라서 분리가 이중의 이득을 가져옵니다. 2026년 프런티어(frontier) 모델 서빙은 MoE 중심입니다(DeepSeek-V3, 향후 GPT-5 계열).

기억해야 할 숫자

벤치마크 수치는 변동합니다. NVIDIA와 추론 스택은 분기마다 갱신된 결과를 올립니다. 인용 전에 반드시 다시 확인해야 합니다.

• GB200 NVL72 + Dynamo에서 DeepSeek-R1: 중간 지연 영역 기준 기준선 대비 약 6배 처리량(developer.nvidia.com, 2025-06). 풀스택 Blackwell + Dynamo 구성의 "최대 30배" 주장은 단일 1차 출처가 없는 방향성 집계입니다.
• GB300 NVL72 + Dynamo: Hopper 대비 최대 50배 MoE 처리량(developer.nvidia.com, 게시일 미상).
• 절감 기준점(내부 합성치, 단일 사례 연구 아님): 동일 SLA에서 연 2백만 달러 지출 중 연 60만~80만 달러 절감.
• 분리 임계점: 프롬프트 512 토큰 초과 + 출력 200 토큰 초과.
• NIXL을 통한 KV 전송: 70B FP8에서 4K 프롬프트 KV 기준 20~80ms.

사용해보기

code/main.py는 코로케이트 서빙과 분리형 서빙을 시뮬레이션합니다. 처리량, 요청당 비용, 프롬프트 길이에 따른 손익분기점(crossover)을 보고합니다.

산출물 만들기

이 강의는 outputs/skill-disaggregation-decider.md를 만듭니다. 워크로드와 클러스터가 주어지면 분리를 적용할지 여부를 결정합니다.

연습문제

1. 쉬움: code/main.py를 실행합니다. 어느 프롬프트 길이에서 분리가 코로케이션을 이깁니까?
2. 중간: P99 접두 길이 8K, 출력 300인 RAG 서비스의 프리필 풀과 디코드 풀을 설계합니다.
3. 중간: 순수 쿠버네티스 환경이고 파이썬 런타임 선호가 없습니다. Dynamo와 llm-d 중 하나를 고릅니다.
4. 어려움: KV 전송 비용을 계산합니다. 70B FP8에서 4K 프리필은 약 500 MB의 KV입니다. RDMA 100 GB/s라면 전송에 5ms가 걸립니다. TCP 10 GB/s라면 50ms입니다. 자신의 SLA에는 어느 쪽이 중요합니까?
5. 어려움: MoE 전문가 라우팅은 KV 접근 패턴을 바꿉니다. 토큰마다 다른 전문가가 활성화(activate)되는 MoE에서 분리는 어떻게 동작합니까?

핵심 용어

더 읽을거리

• NVIDIA — Introducing Dynamo
• NVIDIA — Disaggregated LLM Inference on Kubernetes
• TensorRT-LLM Disaggregated Serving blog
• llm-d GitHub
• llm-d 0.5 release notes