24편 · 약 16분

NVIDIA Dynamo 1.0: 데이터센터 스케일 LLM 추론 오케스트레이션 — SLO Planner·KV Block Manager·NIXL의 동작 방식

왜 지금 Dynamo를 봐야 하나

2026년 3월 16일, GTC에서 NVIDIA Dynamo 1.0이 GA로 출시됐다. Prefill-Decode 분리 추론이 개념에서 프로덕션 표준으로 자리잡기 시작했지만, 그 위에 오케스트레이션 레이어가 빠져 있었다. 단순히 vLLM 인스턴스를 두 그룹으로 나누는 것만으로는 해결되지 않는 문제들이 있었다.

Prefill 노드와 Decode 노드의 GPU 비율을 실시간으로 어떻게 조정할 것인가
GPU 메모리가 가득 찼을 때 KV 캐시를 어디에 보낼 것인가
어떤 Prefill 노드에 요청을 보내야 KV 캐시 재계산을 줄일 수 있는가
수십~수백 노드 규모에서 이 모든 것을 어떻게 운영할 것인가

Dynamo는 이 네 가지 질문에 대한 답으로 만들어진 프레임워크다. NIXL(전송), KV Block Manager(메모리 계층), SLO Planner(동적 스케줄링), KV-aware 라우터(스마트 라우팅) 네 구성요소가 분리 추론 인프라 전체를 묶는다.

공개된 벤치마크에서 DeepSeek-R1을 NVIDIA Blackwell(GB200 NVL72)에서 실행했을 때 모놀리식 서빙 대비 최대 7배 처리량 향상을 측정했다고 발표됐다.

Dynamo가 추가하는 것: 분리 추론의 오케스트레이션 레이어

Prefill-Decode 분리 추론 자체는 vLLM이나 SGLang 안에서 구현할 수 있다. Dynamo는 그 위에 놓이는 별도의 오케스트레이션 레이어다.

vLLM만 쓸 경우 운영자가 직접 해야 하는 것들:

Prefill/Decode 노드 비율 수동 관리
KV 캐시가 가득 찼을 때 수동 대응
어느 노드로 요청을 보낼지 단순 로드밸런싱 이상의 로직 부재
수십 노드 이상에서 KV 캐시 상태 추적 불가

Dynamo는 이 오케스트레이션을 자동화한다. 엔진 안에 들어가는 것이 아니라 엔진 위에서 조율한다. vLLM, SGLang, TensorRT-LLM을 그대로 쓰면서 Dynamo 구성요소만 추가하는 구조다.

전체 아키텍처

NVIDIA Dynamo 1.0 전체 아키텍처

이 아키텍처에서 요청 처리 흐름은 다음과 같다.

클라이언트 요청이 KV-aware 라우터에 도착한다.
라우터가 KV 캐시 중복 점수를 계산해 최적 Prefill 노드를 선택한다.
Prefill 노드가 프롬프트를 처리하고 KV 캐시를 생성한다.
NIXL이 KV 캐시를 Decode 노드로 전송한다.
Decode 노드가 토큰을 생성해 클라이언트에게 스트리밍한다.
SLO Planner가 전체 부하를 모니터링하며 GPU 비율을 조정한다.

구성요소 1: NIXL — KV 캐시 전송 라이브러리

NIXL(NVIDIA Inference Xfer Library)은 Prefill 노드와 Decode 노드 사이에서 KV 텐서를 이동시키는 저수준 전송 라이브러리다.

vLLM의 KVConnector 인터페이스가 추상화를 제공하고, NIXL이 실제 전송을 담당한다. 전송은 비차단(non-blocking)으로 동작한다. Prefill 노드의 GPU forward pass가 계속 다른 요청을 처리하는 동안 KV 전송이 백그라운드에서 진행된다.

지원 백엔드:

백엔드	지연	대역폭	권장 환경
RDMA (InfiniBand)	< 1 ms	400 Gbps+	동일 클러스터, 고성능
RoCE via UCX	< 2 ms	200 Gbps+	이더넷 기반 고속 네트워크
NVMe-oF	수 ms	스토리지 의존	로컬 SSD 경유
TCP 폴백	50–200 ms	네트워크 의존	RDMA 없는 환경
S3 호환	수십~수백 ms	클라우드 의존	크로스-클라우드 KV 공유

RDMA가 없는 환경에서도 TCP 폴백으로 동작하지만, KV 전송 지연이 TTFT에 그대로 추가된다. 프로덕션 배포에서 RDMA 환경 여부가 Dynamo 도입의 핵심 전제가 된다.

구성요소 2: KV Block Manager — 다층 메모리 계층

KV Block Manager(KVBM)는 KV 캐시를 GPU HBM, CPU DRAM, 로컬 SSD, 원격 오브젝트 스토리지 사이에서 비용과 속도를 고려해 자동으로 이동시키는 엔진이다.

계층 1: GPU HBM (L1 캐시)

위치
인퍼런스 엔진과 동일 GPU 메모리

특성
최고속 접근, 수십~수백 GB 한계

Eviction 기준
새 요청에 메모리 필요 시 LRU 기반 CPU로 이동

계층 2: CPU DRAM (L2 캐시)

위치
노드 CPU 메모리 (수 TB 가능)

특성
HBM 대비 수배 용량, 수 μs 접근

사용 시점
HBM에서 evict된 KV, 재요청 시 GPU 재로드

계층 3: Local NVMe SSD

위치
노드 직접 연결 NVMe

특성
수 TB 용량, 수 μs~수십 μs 접근

Dynamo 1.0 지원
로컬 스토리지 KV 오프로드 지원

계층 4: S3 / Azure Blob (원격 오브젝트 스토리지)

위치
클라우드 오브젝트 스토리지

특성
무제한 용량, 수십~수백 ms 접근

Dynamo 1.0 추가
AWS S3, Azure Blob API 공식 지원

KV Block Manager 계층별 운영 방식

KVBM은 KV 블록이 계층 간을 이동할 때마다 이벤트를 emit한다. KV-aware 라우터의 인덱서가 이 이벤트를 소비해 클러스터 전체의 KV 블록 위치를 추적한다. 이 메커니즘이 다음 구성요소인 스마트 라우팅의 기반이 된다.

구성요소 3: KV-aware 라우터 — 캐시 중복 최소화

KV-aware 라우터는 들어오는 요청을 어느 Prefill 노드로 보낼지 결정할 때 KV 캐시 중복 점수(overlap score) 를 계산한다.

기본 로드밸런서는 CPU 사용률이나 큐 깊이만 본다. KV-aware 라우터는 추가로 "이 요청의 프롬프트 프리픽스를 이미 캐싱하고 있는 노드"를 우선 선택한다.

예를 들어 동일한 시스템 프롬프트를 반복해서 사용하는 챗봇 트래픽이 있을 때:

라우터가 시스템 프롬프트 KV가 이미 HBM에 있는 Prefill 노드를 선택한다.
해당 노드는 시스템 프롬프트 KV를 재계산하지 않고 사용자 입력 부분만 처리한다.
Prefill 지연과 GPU 연산이 모두 줄어든다.

캐시 중복 점수가 낮은 요청(완전히 새로운 프리픽스)에는 단순 로드밸런싱을 적용한다.

구성요소 4: SLO Planner — 실시간 GPU 재배분

SLO Planner는 Prefill 풀과 Decode 풀의 GPU 비율을 실시간으로 조정하는 계획·스케줄링 엔진이다.

정적 구성에서는 배포 시점에 Prefill 3 : Decode 7 같은 비율을 정해두어야 한다. 트래픽 패턴이 변하면 어느 한쪽이 유휴 상태가 되거나 병목이 생긴다.

SLO Planner는 다음 기준으로 GPU를 동적으로 재배분한다.

Prefill 큐가 길어질 때: Decode 풀에서 GPU를 Prefill 풀로 전환해 TTFT를 낮춘다.
Decode 큐가 길어질 때: 반대로 GPU를 Decode 풀로 전환해 TBT 안정성을 확보한다.
전체 부하가 낮을 때: GPU를 유휴 상태로 두거나 절전 모드로 전환한다.

이 재배분은 Kubernetes Pod 수준에서 일어난다. SLO Planner가 K8s Deployment의 replica 수를 조정하고, 새 Pod이 기존 엔진과 동일한 설정으로 구동된다.

엔진 호환성

Dynamo는 특정 추론 엔진에 종속되지 않는다. 현재 공식 지원하는 엔진:

엔진	Dynamo 통합 방식	비고
vLLM	KVConnector 인터페이스 + NIXL	가장 성숙한 통합
NVIDIA TensorRT-LLM	KVBM을 엔진 내부에 직접 설치	Blackwell 최적화
SGLang	NIXL 전송 레이어 연동	RadixAttention과 병행 운영 가능

Dynamo 1.0부터 KVBM은 Dynamo 전체 스택 없이도 개별 엔진에 독립적으로 설치할 수 있다. vLLM에 KVBM만 추가해 다층 KV 오프로딩 기능만 사용하는 구성이 가능하다.

Kubernetes 배포 패턴

Dynamo의 레퍼런스 배포는 Kubernetes 기반이다. Azure AKS, AWS EKS에서 공식 가이드가 제공된다.

# Dynamo Helm Chart 설치 (참고용 간략 예시)
helm install dynamo nvidia-dynamo/dynamo \
  --set prefill.replicas=3 \
  --set decode.replicas=7 \
  --set sloPlanner.enabled=true \
  --set kvbm.tiers="gpu,cpu,ssd" \
  --set router.cacheAware=true

SLO Planner가 활성화되면 prefill.replicas와 decode.replicas는 초기값으로만 작동하고 이후 자동 조정된다.

운영자가 추가로 설정해야 하는 것:

노드 affinity 규칙: Prefill용 노드와 Decode용 노드 분리 (GPU 사양이 다른 경우)
RDMA 네트워크 설정: InfiniBand 또는 RoCE 구성 확인
KVBM 스토리지 마운트: NVMe SSD PVC, S3 버킷 자격증명

성능 주장과 현실적 해석

NVIDIA가 GTC 2026에서 발표한 수치:

환경	비교 대상	처리량 향상
DeepSeek-R1, GB200 NVL72 (Blackwell)	모놀리식 서빙	최대 7×
일반 LLM, RDMA 환경	단순 P/D 분리	2–3× 추가 향상

이 수치는 최적 조건에서 측정된 것이다. 현실 배포에서 주의할 점:

RDMA 없는 환경(TCP 폴백)에서는 NIXL 전송 지연이 TTFT를 늘린다.
KV-aware 라우팅 이득은 프리픽스 중복이 높을수록 크다. 트래픽 패턴이 다양하면 단순 로드밸런싱과 차이가 줄어든다.
KVBM의 CPU DRAM Eviction은 GPU 재로드 지연을 만든다. HBM이 가득 찰 때 캐시 히트율이 낮아지면 오히려 성능이 저하될 수 있다.
SLO Planner의 GPU 재배분 속도는 K8s Pod 기동 시간에 제한된다.

Open question: KVBM의 S3 계층 접근은 수십~수백 ms 지연이 발생한다. 이것이 실제 서비스 SLO에 미치는 영향이 충분히 문서화되지 않았다.

운영자 도입 판단 기준

Dynamo가 적합한 환경

GPU 클러스터 규모: 수십 노드 이상, Prefill/Decode 비율 수동 관리가 어려운 경우
네트워크: RDMA(InfiniBand, RoCE) 지원 환경
트래픽 패턴: 시스템 프롬프트 공유율이 높아 KV 캐시 재사용 효과가 큰 경우
엔진: vLLM 또는 TRT-LLM을 이미 사용 중인 경우

도입 전 확인 사항

RDMA 네트워크 가용 여부: 없으면 TCP 폴백, KV 전송 지연 수십~수백 ms 발생
GPU 이종 혼합 여부: Prefill용 신형 고-FLOP GPU, Decode용 고 HBM 대역폭 GPU 분리 가능한지
K8s 버전 및 Dynamo Helm Chart 버전 호환성 확인
KVBM 계층 선택: SSD 없는 환경이라면 HBM → DRAM → S3 2계층 구성
SLO Planner 활성화: 초기에는 정적 비율로 시작해 부하 패턴 파악 후 활성화 권장

이 프레임워크를 한 문장으로 요약하면

NVIDIA Dynamo 1.0은 Prefill-Decode 분리 추론을 프로덕션 규모에서 운영하는 데 필요한 오케스트레이션 계층 — 스마트 라우팅, 동적 GPU 재배분, 다층 KV 메모리 계층 — 을 단일 프레임워크로 제공한 것이다.

아직 RDMA 환경 의존성, S3 계층 활용의 현실적 효과, Kubernetes Pod 기동 시간에 의한 재배분 지연 등 운영자가 직접 검증해야 할 미지수가 남아 있다. 그러나 수십 노드 이상 규모에서 Prefill/Decode 비율 관리와 KV 캐시 재사용을 자동화하는 오픈소스 솔루션이 GA로 나온 것 자체가 이 생태계의 성숙도를 보여준다.

References

NVIDIA Dynamo 1.0 GA 발표 — NVIDIA Technical Blog (2026-03-16): https://developer.nvidia.com/blog/nvidia-dynamo-1-production-ready/
NVIDIA Dynamo 소개 — NVIDIA Technical Blog: https://developer.nvidia.com/blog/introducing-nvidia-dynamo-a-low-latency-distributed-inference-framework-for-scaling-reasoning-ai-models/
NVIDIA Dynamo 공식 문서 — Overall Architecture: https://docs.dynamo.nvidia.com/dynamo/design-docs/overall-architecture
NVIDIA Dynamo 공식 문서 — Disaggregated Serving: https://docs.dynamo.nvidia.com/dynamo/design-docs/disaggregated-serving
NVIDIA Dynamo GitHub: https://github.com/ai-dynamo/dynamo
LMCache + NVIDIA Dynamo 1.0 블로그 (2026-03-16): https://blog.lmcache.ai/en/2026/03/16/lmcache-nvidia-dynamo-1-0-a-match-made-in-inference-heaven/
Dynamo on AKS (Azure Kubernetes Service) 가이드 (2026-03-16): https://blog.aks.azure.com/2026/03/16/dynamo-on-aks-part-3
NVIDIA Dynamo + AWS EKS 가이드: https://aws.amazon.com/blogs/machine-learning/accelerate-generative-ai-inference-with-nvidia-dynamo-and-amazon-eks/
KV Block Manager 상세 — Predictive Multi-Tier Memory Management (arXiv:2604.26968): https://arxiv.org/pdf/2604.26968
NIXL과 disaggregated inference 심화 — Spheron Blog: https://www.spheron.network/blog/nvidia-nixl-disaggregated-inference-guide/