NVIDIA Dynamo 1.0, 공식 수치 5가지로 확인했습니다

GTC 2026에서 조용히 발표된 오픈소스 소프트웨어가 있습니다. 하드웨어 발표에 가려졌지만, AWS·Google·Microsoft 모두 이미 붙었고 Pinterest 수억 명 서비스에도 들어갔습니다. 그런데 “7배”라는 숫자엔 조건이 있고, 단일 GPU 서버엔 오히려 불필요할 수 있습니다.

Dynamo 1.0이 뭔지, 한 줄로 정리하면

NVIDIA Dynamo 1.0은 2026년 3월 16일 GTC 2026에서 정식 프로덕션 버전으로 발표된 오픈소스 AI 추론 프레임워크입니다. 원래 GTC 2025에서 처음 공개됐고, 약 1년 간 클라우드 파트너들과 함께 실제 프로덕션 환경에서 테스트한 뒤 이번에 1.0으로 격상됐습니다. GitHub 저장소 주소는 github.com/ai-dynamo/dynamo이며 무료 오픈소스입니다. (출처: NVIDIA 공식 뉴스룸, 2026.03.16)

NVIDIA 스스로 이걸 “AI 팩토리의 운영체제”라고 부릅니다. 컴퓨터에서 운영체제가 CPU·메모리·프로그램을 조율하듯, Dynamo는 데이터센터 안의 GPU와 메모리 자원을 유기적으로 조율해 AI 추론 워크로드를 처리합니다.

핵심 구성 요소는 네 가지입니다. 먼저 Dynamo Planner는 입력 길이와 출력 길이를 보고 GPU 자원을 동적으로 재배치합니다. Smart Router는 KV 캐시 상태를 실시간으로 보면서 “이 요청은 어느 GPU로 보내야 캐시 재활용이 최대화되는지”를 계산합니다. Distributed KV Cache Manager는 KV 캐시를 GPU 메모리에서 CPU·SSD·원격 스토리지까지 계층적으로 관리합니다. 마지막으로 NIXL(NVIDIA Inference Xfer Library)은 GPU 간 데이터 이동을 고속으로 처리하는 전송 레이어입니다.

7배라는 숫자, 여기서 걸립니다

NVIDIA는 “Dynamo가 Blackwell GPU의 추론 성능을 최대 7배 향상시킨다”고 발표했습니다. 공식 출처는 SemiAnalysis InferenceX 벤치마크(2026년 3월 3일 업데이트)입니다. (출처: NVIDIA Developer Blog, 2026.03.16)

그런데 해당 벤치마크의 측정 조건을 살펴보면 이렇습니다. 모델은 DeepSeek R1-0528 FP4, GPU는 NVIDIA GB200 NVL72, 서빙 방식은 분리 서빙(Disaggregated Serving)에 광폭 전문가 병렬 처리(Wide Expert Parallel)를 결합한 구성입니다. 프롬프트 길이는 1K/1K, 인터랙티브 응답 기준 약 50토큰/초/사용자 조건입니다. 이것이 의미하는 바는 명확합니다. 단일 GPU 서버나 소규모 클러스터에서는 이 수치가 재현되지 않습니다.

분리 서빙이란 프리필(Prefill) 단계와 디코드(Decode) 단계를 서로 다른 GPU 그룹에 나눠 처리하는 방식입니다. 이 방식은 규모가 커질수록 효과가 극대화됩니다. 반대로 GPU 1~2개짜리 소규모 배포에서는 오히려 Dynamo의 오케스트레이션 오버헤드가 추가될 수 있습니다. DigitalOcean의 기술 문서에서도 명시적으로 “Dynamo는 단일 GPU를 빠르게 만들기 위한 것이 아니다. 클러스터 전체에서 중복 작업을 막고 적합한 GPU가 적합한 추론 단계를 처리하도록 하기 위한 것이다”라고 설명합니다. (출처: DigitalOcean 공식 블로그, 2026.03.04)

vLLM·SGLang이랑 뭐가 다른가요?

Reddit의 LocalLLaMA 커뮤니티에서도 이 점이 자주 혼동됩니다. “TRT-LLM, vLLM, SGLang이 Dynamo 안에 들어갑니다. Dynamo는 이들의 업그레이드 버전입니다”라는 설명이 있는데, 이게 정확합니다. Dynamo는 백엔드 추론 엔진에 구애받지 않는 엔진-불가지론(engine-agnostic) 오케스트레이션 레이어입니다.

비유하자면 vLLM이나 SGLang은 각각의 GPU에서 모델을 실행하는 공장 기계입니다. Dynamo는 공장 전체의 생산 라인을 관리하는 공장 관리 시스템(MES)입니다. 어느 기계에 어떤 작업을 보내고, 중간 재고(KV 캐시)를 어디에 쌓아두고, 기계 하나가 고장났을 때 어떻게 작업을 이관할지를 결정합니다.

실제로 Dynamo 1.0은 vLLM, SGLang, TensorRT-LLM을 모두 지원하며, LangChain·LMCache·llm-d 등 생태계 프레임워크와도 통합됐습니다. Pinterest·Perplexity·Cursor처럼 이미 vLLM을 쓰던 기업들이 Dynamo를 추가로 도입한 것도 이 때문입니다. 기존 스택을 바꾸지 않고 그 위에 얹을 수 있었기 때문입니다. (출처: NVIDIA 공식 뉴스룸, 2026.03.16)

실제 수치로 보는 KV-Aware 라우팅 효과

DigitalOcean이 Workato AI Research Lab과 함께 진행한 실측 테스트가 있습니다. 모델은 Llama-3.3-70B-Instruct FP8, GPU는 NVIDIA H200 16개(2노드), 프롬프트 길이는 100K 토큰입니다. 동일 하드웨어에서 KV-Aware 라우팅 유무만 바꿨을 때의 결과입니다. (출처: DigitalOcean 공식 블로그, 2026.03.04)

이 수치에서 가장 주목할 부분은 동시 요청 32개일 때만 극적인 차이가 난다는 점입니다. 16개 동시 요청에서 TTFT 개선율은 17.2%에 그칩니다. 요청이 몰릴수록 KV-Aware 라우팅의 효과가 기하급수적으로 커집니다. 이는 KV 캐시 재활용의 특성상 공유 프리픽스를 가진 요청이 많을수록 이득이 쌓이기 때문입니다. 트래픽이 일정하고 낮은 환경에서는 효과가 제한적이라는 뜻이기도 합니다.

수치를 좀 더 직접적으로 해석하면 이렇습니다. GPU당 처리량이 67% 오른다는 것은, 동일한 워크로드를 처리하는 데 필요한 GPU 수가 약 40% 줄어든다는 의미입니다. 기존에 GPU 10대가 필요했다면 6대로 같은 서비스가 됩니다. GPU 비용이 시간당 수십만 원 수준인 대규모 서비스에서는 연간 인프라 비용 절감이 상당해집니다. 이는 추정이 아니라 실측 데이터에서 역산한 수치입니다.

Model 시작 시간을 7배 줄이는 기능이 있습니다

대규모 AI 추론 클러스터는 트래픽에 따라 Worker 수를 늘리고 줄입니다. 문제는 새 Worker가 뜰 때마다 모델 체크포인트 다운로드 → 가중치 로드 → 커널 컴파일 → CUDA 그래프 빌드라는 긴 초기화 과정을 반복해야 한다는 점입니다. DeepSeek V3 같은 대형 MoE 모델에서는 이 과정이 수십 분을 잡아먹을 수 있습니다.

Dynamo 1.0의 ModelExpress는 이 문제를 두 가지 방법으로 해결합니다. 첫째 체크포인트 복원(Checkpoint Restore)으로, 첫 번째 Worker에서 전체 초기화를 한 번 마친 뒤 그 상태를 영구 스토리지에 저장합니다. 이후 새 Worker는 처음부터 초기화하지 않고 저장된 상태에서 바로 복원합니다. 둘째 모델 가중치 스트리밍(Model Weight Streaming)으로, 첫 번째 Worker가 가중치를 다운로드한 뒤 나머지 Worker들은 NVLink와 NIXL을 통해 그 가중치를 직접 스트리밍받습니다. 각 Worker가 개별적으로 스토리지에서 다운로드하는 구조를 없앤 것입니다.

결과는 DeepSeek V3 기준 H200에서 모델 로딩 시간 7배 단축입니다. (출처: NVIDIA Developer Blog, 2026.03.16) 갑자기 트래픽이 터져서 서버를 10분 안에 3배로 늘려야 하는 상황에서 이 차이는 서비스 품질을 가르는 수준입니다. “GPU 성능이 좋으면 됐지”라고 생각하기 쉬운 부분이지만, 스케일아웃 속도 자체가 병목이 되는 구간이 있다는 걸 Dynamo가 정면으로 공략하고 있습니다.

에이전틱 AI에 특화된 이유

Dynamo 1.0의 출시 타이밍이 GTC 2026과 맞아 떨어진 건 우연이 아닙니다. 에이전틱 AI 워크로드는 일반 LLM 서비스와 구조적으로 다릅니다. 하나의 사용자 질문에 대응하는 게 아니라, 여러 모델이 서로를 호출하고, 도구를 실행하고, 이전 스텝의 결과를 다음 스텝에 넘기는 긴 체인으로 이뤄집니다. 이 구조에서 KV 캐시 관리가 중요해집니다.

기존 추론 런타임은 모든 요청과 KV 캐시 블록을 동등하게 취급합니다. 하지만 에이전트에서 여러 턴에 걸쳐 재사용되는 시스템 프롬프트가 일회성 추론 연쇄와 같은 우선순위로 취급되면 낭비가 생깁니다. Dynamo 1.0은 이를 위한 에이전트 힌트(Agent Hints) 시스템을 도입했습니다. 요청마다 지연 민감도·예상 출력 길이·캐시 제어 정보를 메타데이터로 전달해, 라우터와 KV 캐시 매니저가 사용자 대면 작업을 백그라운드 작업보다 먼저 처리하도록 합니다.

공식 수치로 보면, Dynamo와 NVIDIA NeMo Agent Toolkit을 함께 사용했을 때 NVIDIA Hopper에서 Llama 3.1 모델 기준 TTFT 최대 4배 단축, 처리량 1.5배 향상이 측정됐습니다. (출처: NeMo Agent Toolkit GitHub, 2026.03) 또한 멀티모달 추론에서는 이미지 임베딩을 CPU에 캐싱해 반복 이미지 처리 시 TTFT 최대 30%, 처리량 최대 25% 향상을 달성했습니다. 에이전트 파이프라인에서 같은 이미지 첨부 파일이 반복 참조되는 상황에서 실질적인 차이가 납니다.

이걸 써야 하는 상황, 안 써도 되는 상황

모든 AI 서비스에 Dynamo가 필요한 건 아닙니다. 솔직히 말하면, 작은 팀이나 단일 GPU 환경이라면 오히려 복잡도만 추가될 수 있습니다.

한 가지 덧붙이면, Dynamo는 운영 복잡도가 실재합니다. 라우팅 프론트엔드, 계측된 Worker 백엔드, KV 캐시 매니저가 각각 분리된 포드(Pod)로 실행되며 실시간 조율이 필요합니다. “vLLM 몇 대를 로드밸런서 뒤에 붙이는 것”과는 수준이 다른 분산 시스템입니다. Kubernetes 운영 경험이 전제되어야 제 값을 받을 수 있습니다. NVIDIA는 이 복잡도를 낮추기 위해 Dynamo Graph Deployment Request(DGDR)라는 원클릭 배포 기능을 1.0에 포함시켰지만, 프로덕션 튜닝은 여전히 사람 손이 필요합니다.

Q&A

마치며

GTC 2026에서 Vera Rubin과 파인만 칩이 헤드라인을 장식하는 동안 Dynamo 1.0은 조용히 발표됐습니다. 그런데 이번 주에 실제로 영향을 미치는 건 Dynamo 쪽입니다. Rubin 플랫폼은 아직 2026년 하반기 출하 예정이지만, Dynamo는 오늘 GitHub에서 바로 내려받을 수 있습니다.

솔직히 말하면, 이 소프트웨어의 주 타깃은 스타트업이 아닙니다. AWS·Azure·Google Cloud·CoreWeave·Together AI처럼 수천~수만 GPU를 운영하는 조직들이 이미 프로덕션에서 쓰고 있습니다. Pinterest 수억 명 서비스, Perplexity AI, Cursor가 이미 올라가 있다는 점이 검증의 증거입니다.

개인적으로 가장 흥미로운 부분은 ModelExpress의 모델 가중치 스트리밍입니다. 추론 성능보다 훨씬 덜 주목받지만, 스케일아웃 속도를 7배 줄인다는 건 트래픽이 갑자기 몰리는 서비스에서 체감 차이가 큽니다. AI 서비스의 병목이 “GPU 성능”에서 “GPU를 빨리 늘리는 속도”로 이동하고 있다는 걸 Dynamo가 먼저 파악하고 있는 것 같습니다.

본 포스팅 참고 자료

1. NVIDIA 공식 뉴스룸 — Dynamo 1.0 발표 (2026.03.16)
2. NVIDIA Developer Blog — Dynamo 1.0 기술 세부 사항 (2026.03.16)
3. DigitalOcean 공식 블로그 — Workato 실측 벤치마크 (2026.03.04)
4. GitHub — ai-dynamo/dynamo 오픈소스 저장소
5. NVIDIA Developer Blog 한국어 — Dynamo 원래 소개 글 (GTC 2025)