NVIDIA Dynamo 딥다이브
— GPU 한 장이 아니라 데이터센터 전체로 LLM을 서빙하는 법

vLLM·SGLang·TensorRT-LLM 위에 얹는 오케스트레이션 레이어. Rust로 빌드된 분산 추론 프레임워크 ai-dynamo/dynamo (6.8k stars · Apache-2.0 · v1.1.1)를 한국어로 처음부터 풀어 봅니다.

1프로젝트 한줄 요약

레포 한 줄 설명은 이렇게 적혀 있다: "A Datacenter Scale Distributed Inference Serving Framework". NVIDIA가 만든 만큼 자사 GPU(B200·GB200·GB300·H100·H200) 최적화가 강하지만, 라이선스는 Apache-2.0이라 누구나 가져다 쓰고 수정할 수 있다.

2왜 지금 주목받는가

2026년 LLM 인프라의 패러다임 전환

2024년까지만 해도 LLM의 화두는 "어떻게 잘 학습시키느냐"였다. 하지만 ChatGPT·Claude·Gemini가 일상이 되면서 추론 토큰 양이 학습 토큰 양을 압도하기 시작했다. 모델 하나를 잘 만드는 것보다, 그 모델을 수억 명에게 싸게 빨리 돌리는 것이 진짜 경쟁력이 된 것이다.

경쟁 제품과 무엇이 다른가

핵심은 Dynamo는 추론 엔진을 만들지 않는다는 점이다. 그래서 vLLM·SGLang·TensorRT-LLM과 경쟁하지 않고 그들의 매니저 역할을 자처한다. "최고의 추론 엔진은 매년 바뀌지만, 그것들을 묶는 방법은 점점 안정될 것"이라는 베팅이다.

벤치마크가 보여주는 충격

오픈소스 인프라 트렌드의 한 축

2025~2026년 LLM 추론 인프라 오픈소스는 크게 세 갈래로 갈라졌다:

• 엔진 단(單) 노드: vLLM, SGLang, TensorRT-LLM, llama.cpp, MLX
• 오케스트레이션: Dynamo, Ray Serve, KServe, NVIDIA NIM
• 응용 플랫폼: Ollama (로컬), Dify (앱), LiteLLM (라우터)

Dynamo는 가운데 칸의 NVIDIA표 정통 후보다. AWS·Google·Mistral·Moonshot AI(Kimi K2)·Baseten 같은 굵직한 사용처가 이미 붙어 있고, MLPerf 추론 벤치마크 신기록도 Dynamo로 세워졌다.

3기술 스택 전체 지도

3-1. 언어 구성과 그 이유

3-2. 백엔드(추론 엔진) 매트릭스

세 엔진 모두 사실상 동등하게 지원한다. 사용자는 자기 모델·하드웨어·라이선스 사정에 맞게 고르면 된다. TensorRT-LLM은 NVIDIA GPU 전용이고 빠르지만 컴파일 시간이 길고, vLLM·SGLang은 더 쉽고 멀티 벤더(AMD MI300 등)를 좀 더 본다.

3-3. Rust 크레이트 의존성의 풍경

Cargo.toml의 workspace.dependencies를 보면 Dynamo가 어느 생태계 위에 서 있는지가 한눈에 드러난다.

# 비동기 런타임
tokio = "=1.48.0"          # 사실상 Rust 비동기의 표준
async-stream / async-trait # 스트리밍 응답
hyper / axum / tower-http  # HTTP 서버

# 메시징·서비스 디스커버리
async-nats = "0.45"        # JetStream 메시지 큐
etcd-client = "0.17"       # 분산 키-값 저장소
tmq = "0.5"                # ZeroMQ 바인딩 (SGLang 통신)

# GPU
cudarc = "0.19.3"          # CUDA Rust 바인딩

# 데이터 구조·해싱
blake3 = "1"               # KV cache 해시 (충돌 거의 0)
xxhash-rust                # 빠른 해시
dashmap / moka             # 동시성 맵·캐시

# HF Hub
hf-hub = "0.4.2"           # 모델 다운로드 (rustls-tls)
modelexpress-client = "0.3" # 모델 가중치 스트리밍

# 관측 가능성
prometheus / tracing
opentelemetry-otlp         # OTel → Tempo/Jaeger 연동

3-4. Python 측 의존성

pyproject.toml의 [project.optional-dependencies]는 백엔드별로 분리되어 있다. uv pip install "ai-dynamo[sglang]" 식으로 필요한 것만 골라 깔 수 있다.

• [sglang] — SGLang 추론 엔진
• [vllm] — vLLM 추론 엔진
• [trtllm] — TensorRT-LLM (별도 NVIDIA PyPI 인덱스 필요)
• 코어: 빌드는 maturin(Rust↔Python 브릿지), 패키지 관리는 uv(astral.sh의 초고속 pip 대체)

3-5. 인프라·운영 스택

4아키텍처 심화 분석

4-1. 큰 그림: 6개 핵심 컴포넌트

4-2. 핵심 설계 패턴 1 — Disaggregated Serving (분리 서빙)

전통적인 LLM 추론은 한 GPU가 prefill(입력 처리) → decode(토큰 생성)를 모두 한다. 문제는 두 단계가 GPU를 완전히 다르게 쓴다는 점이다.

4-3. 핵심 설계 패턴 2 — KV-Aware Routing

LLM은 같은 시스템 프롬프트로 시작하는 요청이 많다(예: "당신은 친절한 한국어 어시스턴트입니다..."). 이 부분의 KV cache는 한 번 계산해두면 그대로 재사용 가능한데, 아무 GPU나 골라 보내면 매번 새로 계산해야 한다.

Dynamo의 KV Router는 토큰 prefix를 BLAKE3로 해싱해서, 어느 워커가 그 prefix의 KV를 이미 가지고 있는지 NATS 메시지로 받아 본다. 가지고 있는 워커에게 보내면 prefill 시간이 거의 0이 된다. 그래서 TTFT 2배 단축.

4-4. 핵심 설계 패턴 3 — KVBM 4단 계층 캐싱

KV cache는 빠르지만 비싸다. GPU HBM은 비싸고 좁아서 긴 컨텍스트나 동시 요청이 많아지면 금방 꽉 찬다. KVBM은 "안 쓰는 KV는 더 싼 곳으로 내려보낸다"는 발상.

OS의 페이지 캐시·CPU 캐시 계층 구조와 똑같은 발상을 KV cache에 적용한 것이다. lib/kvbm-* 크레이트 시리즈가 이걸 구현한다: kvbm-engine(코어), kvbm-kernels(CUDA 커널), kvbm-logical(논리 계층), kvbm-physical(물리 계층), kvbm-consolidator(통합).

4-5. 핵심 설계 패턴 4 — SLA-Based Planner

워크로드는 시시각각 변한다. 점심 시간에 폭증, 새벽에 한산. Planner는 Prometheus 메트릭(현재 TTFT, ITL, queue depth)을 보고 "prefill 워커 1개 더 띄울까? decode 줄일까?"를 자동 판단한다.

핵심은 AIConfigurator가 미리 10,000개 이상의 토폴로지 조합을 시뮬레이션해 두는 것. 실제 GPU를 안 태워보고도 "이 워크로드에는 prefill 4 + decode 8이 최적"이라는 답을 미리 안다.

4-6. 핵심 설계 패턴 5 — ModelExpress + Grove

• ModelExpress: 새 워커를 띄울 때 모델 가중치를 HuggingFace에서 매번 다운받지 않고, 이미 가중치를 가진 GPU에서 NVLink/NIXL로 GPU↔GPU 직접 스트리밍. 7× 더 빠른 cold start.
• Grove: GB200 NVL72 같은 시스템에서는 GPU 72개가 NVLink 도메인으로 묶여 있다. K8s 기본 스케줄러는 그걸 모른다. Grove Operator는 "이 워크로드는 같은 NVLink 도메인에 묶어줘"라고 알려주는 토폴로지-aware gang scheduling을 한다.

5디렉토리 구조 해부

6기술별 학습 포인트

6-1. Rust로 인프라 짜기

Dynamo는 Rust로 짠 진지한 분산 시스템의 좋은 표본이다. 다음을 직접 읽을 수 있다:

• Tokio 비동기 패턴: async/await, channels, select!, JoinHandle 관리
• axum HTTP 서버: 라우팅, 미들웨어, OpenAPI 자동 생성
• maturin + PyO3: Rust 구조체를 Python에서 그대로 받기
• workspace 분할: 22개 크레이트로 책임 분리, 컴파일 캐시 활용
• tracing + OpenTelemetry: 분산 트레이싱을 Rust 코드에 어떻게 박는가

6-2. LLM 추론 엔진 이해하기

vLLM·SGLang·TensorRT-LLM 셋 다 Dynamo 백엔드로 등장한다. 각각 한 번씩 직접 띄워보면:

• vLLM: PagedAttention, continuous batching의 원조
• SGLang: RadixAttention(prefix 트리 캐시), 빠른 JSON 디코딩
• TensorRT-LLM: NVIDIA 컴파일 최적화의 끝판왕, FP8/FP4 양자화

Dynamo 추상화 덕분에 같은 API로 백엔드만 바꿔가며 비교 가능. "세 엔진의 강점/약점을 표로 정리"는 면접에서도 강력한 카드.

6-3. KV cache 메커닉스

모든 LLM 추론 최적화는 KV cache로 통한다. Dynamo를 공부하면 자연스럽게 알게 되는 것들:

• 왜 GPU 메모리의 절반 이상을 KV가 먹는가
• PagedAttention의 페이지 단위 관리
• Prefix sharing이 왜 그렇게 큰 이득인가
• 오프로딩(GPU→CPU→SSD)의 트레이드오프
• FP8/INT4 KV 양자화로 메모리 절반 줄이기

6-4. Kubernetes Operator 패턴

deploy/operator/의 Go 코드는 K8s Operator를 처음 배우기에 좋은 예시다.

• CRD(Custom Resource Definition): DynamoGraphDeploymentRequest 같은 자기만의 K8s 리소스 정의
• Reconciler 루프: "원하는 상태"와 "실제 상태"의 차이를 메우는 무한 루프
• controller-runtime: kubebuilder가 만들어내는 표준 골격
• Operator SDK 패턴: Finalizers, OwnerReferences, Status 서브리소스

6-5. 분산 시스템 기본기

• etcd: Raft 기반 분산 KV 저장소. 서비스 디스커버리에 사용
• NATS JetStream: 가벼운 메시지 큐, KV 이벤트 broadcasting
• Service Mesh 없이도 되는 이유: 인프라가 GPU 노드 한정이라 단순 TCP면 충분
• Health Check + Request Migration: 워커 죽어도 사용자 요청은 안 죽게 하는 트릭

6-6. 관측 가능성 (Observability)

Prometheus + OpenTelemetry 조합은 모던 SRE의 표준. Dynamo는 둘 다 쓴다.

• tracing crate: Rust 안에서 span 만들기 → OpenTelemetry로 export
• Grafana 대시보드: TTFT P50/P95/P99, queue depth, GPU 활용률
• NVTX: NVIDIA Nsight 프로파일러에 마커 박기 (cargo profile 옵션)

7하드웨어·시스템 요구사항

최소 ~ 권장 사양

OS/소프트웨어

• OS: Ubuntu 24.04 (공식 빌드 가이드 기준), Ubuntu 22.04도 가능
• Rust: 2024 edition, toolchain 자동 핀
• Python: 3.10~3.13
• CUDA: 12.x 권장 (백엔드별로 상이)
• 시스템 패키지: build-essential libhwloc-dev libudev-dev pkg-config libclang-dev protobuf-compiler python3-dev cmake
• 패키지 매니저: uv (필수에 가까움)

8직접 해볼 수 있는 실습 과제

난이도 ★ — 동작 확인 (1~2시간)

docker run --gpus all --network host --rm -it \
  nvcr.io/nvidia/ai-dynamo/sglang-runtime:1.1.1

# 컨테이너 안에서
python3 -m dynamo.frontend --http-port 8000 --discovery-backend file &
python3 -m dynamo.sglang --model-path Qwen/Qwen3-0.6B --discovery-backend file &

# 호스트에서
curl localhost:8000/v1/chat/completions -d '{
  "model": "Qwen/Qwen3-0.6B",
  "messages": [{"role":"user","content":"안녕"}]
}'

난이도 ★★ — 라우팅 관찰 (반나절)

난이도 ★★★ — 분리 서빙 직접 구성 (1~2일)

난이도 ★★★★ — K8s 배포 (3~5일)

난이도 ★★★★★ — 코드 기여 (장기)

9관련 기술 심화 학습 로드맵

1주차 — LLM 추론 기초

• Transformer attention의 KV cache 동작 원리 (3blue1brown 시리즈 + Andrej Karpathy nanoGPT)
• vLLM PagedAttention 논문 읽기
• HuggingFace transformers로 작은 모델 직접 추론 → KV cache 메모리 측정

2주차 — 추론 엔진 비교

• vLLM, SGLang, TensorRT-LLM 각각 단일 GPU에서 동일 모델(Llama-3-8B-Instruct) 추론
• 벤치마크: TTFT, ITL, throughput 비교
• 각 엔진의 라이선스·생태계·강점 정리

3주차 — Rust 비동기 시스템 프로그래밍

• Tokio 공식 튜토리얼 끝까지
• axum으로 OpenAI 호환 mock 서버 만들기
• tracing + opentelemetry 연동해 분산 트레이싱 콘솔 출력

4주차 — Dynamo Quick Start

• 섹션 8 실습 1~2 완료
• Dynamo 공식 문서 docs.nvidia.com/dynamo/ Getting Started 전체 정독
• Disaggregated Serving 디자인 문서 읽기

5주차 — KV 라우팅과 캐싱

• NATS JetStream 직접 띄우고 publish/subscribe 코드 짜기
• lib/kv-router 코드 읽으며 prefix 매칭 알고리즘 따라가기
• BLAKE3 vs xxhash vs SHA-256 벤치마크 비교

6주차 — Kubernetes Operator

• kubebuilder 튜토리얼로 mini Operator 만들기
• Dynamo Operator 코드 읽기 (Go, deploy/operator/)
• DGDR CRD 스펙 분석 + 자기 모델용 YAML 작성

7주차 — 실전 배포

• 섹션 8 실습 3 (분리 서빙) 또는 실습 4 (EKS/GKE)
• Prometheus + Grafana로 SLA 대시보드 직접 구성
• Planner 메트릭으로 auto-scale 시연

8주차 — 기여·확장

• 섹션 8 실습 5 (PR 도전)
• 또는 자기 백엔드 어댑터(예: MLX, AMD ROCm vLLM) 만들기 시도
• 블로그 글로 8주간의 학습 기록 정리 → 커리어 포트폴리오

10핵심 키워드 사전

11참고 링크

공식

• GitHub 레포 (ai-dynamo/dynamo)
• 공식 문서 (Fern 호스팅)
• 레시피 모음 (모델별 배포 YAML)
• Design Proposals (RFC)
• NGC 미리 빌드된 컨테이너

커뮤니티

• Discord 서버
• Office Hours 플레이리스트 (격주)
• Dynamo Day 발표 영상

벤치마크·블로그

• NVIDIA 공식 1.0 발표 글
• Baseten: Dynamo로 2× 빠른 추론
• SemiAnalysis InferenceMax 벤치마크

주변 생태계

• vLLM
• SGLang
• TensorRT-LLM
• ModelExpress (가중치 스트리밍)
• Grove (K8s gang scheduler)
• AIConfigurator (토폴로지 시뮬레이터)