NVIDIA Dynamo 实战手册：分布式推理的“调度器 + 路由器 + KV 管理 + 超低延迟通信”

关键词
NVIDIA Dynamo、分布式推理、解耦式服务（Disaggregated Serving）、KV Cache 路由、NIXL、vLLM/SGLang/TensorRT-LLM、GPUDirect RDMA、Kubernetes

摘要
这篇是给“要把推理跑到多机多卡，还想把成本压下去”的工程师看的 Dynamo 入门到实操。先把它和 Dynamo-Triton 的关系说清，再把四大组件（Planner、Smart Router、KV Cache Manager、NIXL）逐一拆开，解释为什么“解耦 prefill 与 decode”能让吞吐上去。然后给出最小复现：本机一条命令起前端 + SGLang 后端，curl 就能打；再做一版“解耦服务”的小实验，看路由与 KV 复用怎么生效。最后补上 K8s 部署要点、观测指标（TTFT/ITL）、以及和 vLLM / TensorRT-LLM 的协同选择。官方披露的典型数据：在 GB200 NVL72 上跑 DeepSeek-R1，请求吞吐可提升至 30×；在 Hopper 上跑 Llama-70B 吞吐提升 2×+（均依工作负载而定）。

---

目录

1. Dynamo 是什么：和 Dynamo-Triton 有何不同、适用在哪些场景
2. 架构一图读懂：四大组件如何协同
3. 为什么要“prefill/decode 解耦”：瓶颈剖面与 30× 提升的来龙去脉
4. 最小复现（单机）：起一个前端 + 一个 SGLang 后端 → curl 打通
5. KV Cache 路由与复用：命中率如何换吞吐
6. 做一版“解耦服务”小实验：把 prefill/ decode 分开跑
7. NIXL：把“KV 在不同节点间飞快搬运”的那些底层条件
8. 上生产：K8s 部署、监控与 SLO 驱动的资源规划

---

1) Dynamo 是什么：定位、边界与和 Dynamo-Triton 的关系

一句话：NVIDIA Dynamo 是面向多机多卡的低延迟分布式推理框架，核心卖点是解耦式服务（prefill / decode 分池）、KV-cache 感知路由与超低延迟的数据搬运（NIXL），把上百到上千张 GPU 编排成“像一块大加速器”。(NVIDIA Developer)

• 与 Dynamo-Triton（原 Triton Inference Server）：两者同属 “NVIDIA Dynamo 平台”。Triton（现称 Dynamo-Triton）覆盖多模态/多框架的通用推理服务；而 Dynamo（本文主角）专注大模型分布式推理与队列/路由/资源调度等“系统工程”能力。官方 FAQ 明确：Triton 继续维护，在平台内与 Dynamo 互补。(NVIDIA Developer Forums)
• 面向对象：需要把 LLM 等生成式模型规模化并降低时延/成本的团队；兼容 vLLM、TensorRT-LLM、SGLang 等不同后端。(NVIDIA Developer)

2) 架构一图读懂（UML）：四大组件如何协同

• Frontend：OpenAI 兼容入口（Rust 实现），负责接入与流式返回。(GitHub)
• Planner：按 TTFT/ITL/队列长度/GPU 利用等指标，动态扩缩 prefill / decode 池；决定是否解耦与如何分配 GPU。(GitHub)
• Router（KV-aware）：跟踪 KV 所在与价值，把相似上下文路由到已有 KV的 worker，减少重建。(GitHub)
• Distributed KV Manager：在显存/主存/存储间做分层管理与回灌；与后端的 KVBM/内部 RadixKV 等衔接。(GitHub)
• NIXL：面向推理的数据传输库，统一封装 NVLink/NVSwitch/InfiniBand/RoCE/Ethernet 与 GPUDirect RDMA/Storage、UCX、S3 等后端，自动择优传输路径，前提与配置见官方文档。(NVIDIA Developer)

3) 为什么要解耦 prefill / decode：瓶颈剖面与“30×”的由来

• 共栈问题：把 prefill（构建 KV，算力密集、吞吐优先）与 decode（自回归生成，延迟敏感）放同一 GPU 池，容易出现资源耦合与队列互相拖拽。
• 解耦思路：把两类阶段分池，配合 Planner 的动态调度（并发、队列、KV 热度）、Router 的KV 命中路由与 NIXL 的低延迟跨机搬运，形成整体吞吐与时延的优化。
• 官方披露的数据点（场景相关）：NVIDIA 在 2025-03 的技术文章中给出示例：在 GB200 NVL72 上跑 DeepSeek-R1 级别的大规模推理，解耦与路由/传输优化组合下，请求吞吐可达 ~30× 提升；在 Hopper 上跑 Llama-70B，2×+ 级提升。具体倍数依赖 ISL/OSL 分布、并发、KV 命中率与网络/拓扑。(NVIDIA Developer)
• 不是“强制解耦”：Planner 会按时延/吞吐目标与 KV 传输成本，动态选择解耦或聚合，避免过度拆分带来的反效果。(NVIDIA Developer)

4) 最小复现（单机）：前端 + SGLang 后端，curl 打通

目标：本机起一个 OpenAI 兼容前端 + 一个 SGLang Worker，用 curl 发起对话，感受 Dynamo 的接入与路由骨架。以下命令与路径来自官方仓库/文档的 “Running an LLM API server / SGLang backend”。(GitHub)

环境准备（建议新 venv）

# 安装 uv 并创建虚拟环境（或用你习惯的方式）
curl -LsSf https://astral.sh/uv/install.sh | sh
uv venv venv && source venv/bin/activate

# 安装 Dynamo（选择 SGLang 后端；也可换成 [vllm] / [trtllm]）
uv pip install "ai-dynamo[sglang]"

启动前端（OpenAI 兼容 HTTP）

python -m dynamo.frontend --http-port 8000
# 前端默认会连本机的控制面与路由；实际分布式部署会外接 etcd/NATS 等

启动后端（SGLang Worker）

# 选择你本机可承载的模型
python -m dynamo.sglang --model deepseek-ai/DeepSeek-R1-Distill-Llama-8B

发起请求（非流式示例）

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" -d '{
  "model":"deepseek-ai/DeepSeek-R1-Distill-Llama-8B",
  "messages":[{"role":"user","content":"Hello from Dynamo"}],
  "stream":false, "max_tokens":64
}'

你应该关注的点

• 前端提供 OpenAI 兼容接口（便于替换你的现有调用链），Router 会在本机把请求打到 SGLang Worker；同理可切换到 vLLM 或 TensorRT-LLM Worker。(GitHub)
• 如果要走向多机与解耦服务（prefill 池 / decode 池分离）、SLA 驱动的 Planner，官方 docs 与 Quickstart 提供了 K8s 与后端组合的样例；NIXL/GPUDirect RDMA 的网络/驱动要求请提前核对。(NVIDIA Developer)

——

5) KV Cache 路由与复用：把“相似上下文”送去对的人（含最小实验与 UML）

核心思路
Dynamo 的 Router 维护全局 KV 信息（位置、命中价值），当新的请求到来时，优先把它路由到已经拥有相似上下文 KV 的 worker，减少重建 KV 的大活儿，等价于“直接省掉一段 prefill”。开启方式很直接：在前端或服务环境把 DYN_ROUTER_MODE=kv，其余保持默认即可。官方文档把这一策略写清楚，并给出了 KV 路由的设计与层次结构。(NVIDIA Docs)

最小复现实验（单机多 worker）

1. 起底座（NATS/etcd）：

git clone https://github.com/ai-dynamo/dynamo && cd dynamo
docker compose -f deploy/docker-compose.yml up -d   # 启动 etcd 与 NATS

2. 起前端（OpenAI 兼容），打开 KV 路由：

export DYN_ROUTER_MODE=kv
python -m dynamo.frontend --http-port 8000

3. 起两个解码型 worker（以 SGLang 为例，同一模型名即可）：

uv venv venv && source venv/bin/activate
uv pip install "ai-dynamo[sglang]"
python -m dynamo.sglang --model deepseek-ai/DeepSeek-R1-Distill-Llama-8B   # worker-1
# 另一个终端再起一份相同命令作为 worker-2

4. 打两拨“相似前缀”的请求，观察第二拨 TTFT 明显下降（KV 命中）：

# 第一拨：构建/填满 KV
curl -s http://localhost:8000/v1/chat/completions -H "Content-Type: application/json" -d '{
  "model":"deepseek-ai/DeepSeek-R1-Distill-Llama-8B",
  "messages":[{"role":"user","content":"Explain the differences between transformers and RNNs, with code."}],
  "stream":true, "max_tokens":128
}' >/dev/null

# 第二拨：相似前缀，命中路由
curl -s http://localhost:8000/v1/chat/completions -H "Content-Type: application/json" -d '{
  "model":"deepseek-ai/DeepSeek-R1-Distill-Llama-8B",
  "messages":[{"role":"user","content":"Explain the differences between transformers and RNNs, but focus on inference-time behavior."}],
  "stream":true, "max_tokens":128
}'

Router/前端暴露的指标会显示 KV 命中率、TTFT/ITL 变化；Prometheus/Grafana 的集成在官方监控指南里有现成 dashboard。(NVIDIA Docs)

UML（KV 路由时序）

要点

• 启用 KV 路由只需环境变量；NATS/etcd 用于发现与消息通道。(NVIDIA Docs)
• KV 管理层使用分层结构和（版本中）Radix-Tree 维护全局注册，异步搬移由 NIXL 负责。(NVIDIA Docs)

6) Prefill/Decode 解耦小实验：把吞吐“拆”出来（含 UML 与指令）

为什么要拆
prefill（构建 KV）吞吐导向、decode（自回归）延迟导向；共栈时两个阶段会互相拖拽。Dynamo 把两者分池，再配合 KV 路由与高速搬运，官方在 GTC 文章中给出“在 Blackwell/GB200 集群上跑 DeepSeek-R1，可把请求吞吐拉到 ~30× 的量级（视工作负载而定）”。(NVIDIA Developer)

三节点骨架（官方示例思路，单机也能模拟）

• 节点 A：NATS + etcd + Frontend + Processor
• 节点 B：Decode Worker 池
• 节点 C：Prefill Worker 池（专职构建 KV）
  示例拓扑与命令在文档 “disagg skeleton” 与后续版本的部署指南里。(NVIDIA Docs)

最短命令路径（可先本机多进程模拟）

# 1) 基础设施
docker compose -f deploy/docker-compose.yml up -d   # etcd + NATS

# 2) 前端
export DYN_ROUTER_MODE=kv
python -m dynamo.frontend --http-port 8000

# 3) 起一个 prefill 专用 worker（关键是角色标记）
#    不同版本/后端的标志位略有差异，文档示例为：
python -m dynamo.sglang --model deepseek-ai/DeepSeek-R1-Distill-Llama-8B --is-prefill-worker

# 4) 起一个 decode 池（可多份）
python -m dynamo.sglang --model deepseek-ai/DeepSeek-R1-Distill-Llama-8B

某些版本的 role/flag 名称以文档为准；SGLang/ vLLM/ TRT-LLM 的具体参数以各自 README 为准，Dynamo 后端是引擎无关的。(NVIDIA Docs)

UML（解耦时序 + KV 传输）

怎么判定“拆”对了

• 监控 TTFT/ITL 与 吞吐/每 GPU 请求数；Dynamo 的 SLA Planner/监控文档写清楚：TTFT/ITL 统计需要 stream:true 的请求才会产出延迟指标，SLA Planner 会用这些指标做扩缩容。(NVIDIA Docs)
• ISL/OSL 结构不同效果不同：长输入（ISL 大）更能吃到解耦红利；官方也有“部署前评测脚本”用于按 ISL/OSL、SLA 目标扫描推荐的 prefill/decode 配置。(NVIDIA Docs)

已知坑位（来自 issue/实战）

• 跨机解耦时，如果 RDMA/UCX 配置不当，会出现“prefill 节点起得好好的，decode 卡在等 KV 传输”的挂起，相关 issue 有排查步骤（打开 UCX 日志等）。(GitHub)

7) NIXL 要点：让 KV 在节点间“高速穿梭”（接口、后端与排查）

它做了什么
NIXL = Inference Xfer Library。面向推理的点对点传输库，统一抽象 GPU/CPU/文件/块/对象存储多介质，按硬件/驱动能力自动选最优路径（NVLink/NVSwitch、InfiniBand/RoCE、以太网；支持 GPUDirect RDMA/Storage、UCX/Libfabric 等）。Dynamo 的“prefill→decode 解耦 + KV 复用”之所以不被传输开销吃掉，靠的就是这层。(GitHub)

启用与前置

• 你几乎不用改代码：NIXL Connect 会自动挑选传输后端；实际可用路径取决于你的网络/驱动（有没有 RDMA、NVLink 拓扑如何）。(NVIDIA Docs)

• 如何确认在走“快路”：

  • 查看 NIXL/UCX 日志（issue 建议打开 UCX_LOG_LEVEL=info、UCX_PROTO_INFO=y 做排查）；
  • 观察 decode 侧的 KV 接收速率、跨节点吞吐是否接近链路上限。(GitHub)

UML（NIXL 组件视图）

延伸资料：GitHub 与多篇工程实践文章对 NIXL 的插件化与 GPUDirect 路径有更细的演示。(GitHub)

8) 上生产：K8s 部署、观测与 SLO（TTFT/ITL）驱动的资源规划

一键的起步

• 官方提供 dynamo deploy/Helm、K8s 监控清单与 Quickstart（含 kube-prometheus-stack）；默认就能把 Prometheus/Grafana 拉起来抓指标。(NVIDIA Docs)
• 平台页/开发者页概览了 Dynamo 与 Dynamo-Triton 的定位与支持矩阵，你可以按模型谱系与后端（vLLM / TensorRT-LLM / SGLang）来选。(NVIDIA Developer)

SLA Planner：用“体验指标”拉动资源

• TTFT（首 token）与 ITL（相邻 token 延迟）是 Planner 的一等指标；要注意：只有流式请求才会产出这些延迟度量，非流式下看不到。(NVIDIA Docs)
• Planner 还会看prefill 队列长度与decode KV 利用来扩缩 prefill/ decode 池。(NVIDIA Docs)

UML（K8s 观测与扩缩的组件图）

上线清单（最少要做的几件事）

• 启用 KV 路由：前端设 DYN_ROUTER_MODE=kv，确认命中率面板正常出数。(NVIDIA Docs)
• 评测再上量：用“部署前评测脚本”喂入你的 ISL/OSL 分布 + 目标 TTFT/ITL，拿到推荐的 prefill/decode 配置与并行映射。(NVIDIA Docs)
• 监控到位：落地 kube-prometheus-stack，导入 Dynamo 指标面板，确保 TTFT/ITL、KV 命中率、跨节点带宽、GPU 利用率都有。(NVIDIA Docs)
• 云上配方可对标：如需参考大厂实践，可看 Google Cloud 的 AI Hypercomputer × Dynamo 解耦推理 recipe。(Google Cloud)

---

个人简介

作者简介：全栈研发，具备端到端系统落地能力，专注人工智能领域。
个人主页：观熵
个人邮箱：privatexxxx@163.com
座右铭：愿科技之光，不止照亮智能，也照亮人心！

专栏导航

观熵系列专栏导航：
具身智能：具身智能
国产 NPU × Android 推理优化：本专栏系统解析 Android 平台国产 AI 芯片实战路径，涵盖 NPU×NNAPI 接入、异构调度、模型缓存、推理精度、动态加载与多模型并发等关键技术，聚焦工程可落地的推理优化策略，适用于边缘 AI 开发者与系统架构师。
DeepSeek国内各行业私有化部署系列：国产大模型私有化部署解决方案
智能终端Ai探索与创新实践：深入探索 智能终端系统的硬件生态和前沿 AI 能力的深度融合！本专栏聚焦 Transformer、大模型、多模态等最新 AI 技术在 智能终端的应用，结合丰富的实战案例和性能优化策略，助力 智能终端开发者掌握国产旗舰 AI 引擎的核心技术，解锁创新应用场景。
企业级 SaaS 架构与工程实战全流程：系统性掌握从零构建、架构演进、业务模型、部署运维、安全治理到产品商业化的全流程实战能力
GitHub开源项目实战：分享GitHub上优秀开源项目，探讨实战应用与优化策略。
大模型高阶优化技术专题
AI前沿探索：从大模型进化、多模态交互、AIGC内容生成，到AI在行业中的落地应用，我们将深入剖析最前沿的AI技术，分享实用的开发经验，并探讨AI未来的发展趋势
AI开源框架实战：面向 AI 工程师的大模型框架实战指南，覆盖训练、推理、部署与评估的全链路最佳实践
计算机视觉：聚焦计算机视觉前沿技术，涵盖图像识别、目标检测、自动驾驶、医疗影像等领域的最新进展和应用案例
国产大模型部署实战：持续更新的国产开源大模型部署实战教程，覆盖从 模型选型 → 环境配置 → 本地推理 → API封装 → 高性能部署 → 多模型管理 的完整全流程
Agentic AI架构实战全流程：一站式掌握 Agentic AI 架构构建核心路径：从协议到调度，从推理到执行，完整复刻企业级多智能体系统落地方案！
云原生应用托管与大模型融合实战指南
智能数据挖掘工程实践
Kubernetes × AI工程实战
TensorFlow 全栈实战：从建模到部署：覆盖模型构建、训练优化、跨平台部署与工程交付，帮助开发者掌握从原型到上线的完整 AI 开发流程
PyTorch 全栈实战专栏： PyTorch 框架的全栈实战应用，涵盖从模型训练、优化、部署到维护的完整流程
深入理解 TensorRT：深入解析 TensorRT 的核心机制与部署实践，助力构建高性能 AI 推理系统
Megatron-LM 实战笔记：聚焦于 Megatron-LM 框架的实战应用，涵盖从预训练、微调到部署的全流程
AI Agent：系统学习并亲手构建一个完整的 AI Agent 系统，从基础理论、算法实战、框架应用，到私有部署、多端集成
DeepSeek 实战与解析：聚焦 DeepSeek 系列模型原理解析与实战应用，涵盖部署、推理、微调与多场景集成，助你高效上手国产大模型
端侧大模型：聚焦大模型在移动设备上的部署与优化，探索端侧智能的实现路径
行业大模型 · 数据全流程指南：大模型预训练数据的设计、采集、清洗与合规治理，聚焦行业场景，从需求定义到数据闭环，帮助您构建专属的智能数据基座
机器人研发全栈进阶指南：从ROS到AI智能控制：机器人系统架构、感知建图、路径规划、控制系统、AI智能决策、系统集成等核心能力模块
人工智能下的网络安全：通过实战案例和系统化方法，帮助开发者和安全工程师识别风险、构建防御机制，确保 AI 系统的稳定与安全
智能 DevOps 工厂：AI 驱动的持续交付实践：构建以 AI 为核心的智能 DevOps 平台，涵盖从 CI/CD 流水线、AIOps、MLOps 到 DevSecOps 的全流程实践。
C++学习笔记？：聚焦于现代 C++ 编程的核心概念与实践，涵盖 STL 源码剖析、内存管理、模板元编程等关键技术
AI × Quant 系统化落地实战：从数据、策略到实盘，打造全栈智能量化交易系统
大模型运营专家的Prompt修炼之路：本专栏聚焦开发 / 测试人员的实际转型路径，基于 OpenAI、DeepSeek、抖音等真实资料，拆解 从入门到专业落地的关键主题，涵盖 Prompt 编写范式、结构输出控制、模型行为评估、系统接入与 DevOps 管理。每一篇都不讲概念空话，只做实战经验沉淀，让你一步步成为真正的模型运营专家。

---

🌟 如果本文对你有帮助，欢迎三连支持！

👍 点个赞，给我一些反馈动力
⭐ 收藏起来，方便之后复习查阅
🔔 关注我，后续还有更多实战内容持续更新