NVIDIA Dynamo
编排层如何通过 Smart KV Router 与多级 KVBM 加速数据中心级 LLM 推理
核心要点：
- 定位：编排层 (orchestration)，不替代推理引擎；站在 TRT-LLM / vLLM / SGLang 之上
- 核心组件：Frontend + Smart Router （Radix Tree + 负载） + Planner + Worker + KVBM （4 级） + NIXL （传输）
- Smart Router：事件驱动 Radix Tree, score = a · overlap_blocks - b · prefill_load
- KVBM 四级：HBM (ns) / DRAM (μs) / NVMe (10-100 μs) / 远程对象存储 (ms)
- NIXL：异步非阻塞 P2P, UCX / GDR / GDS / S3 over RDMA / Azure Blob 多 backend
- 官方加速：DeepSeek-R1 671B + GB200 NVL72 up to 30× tokens/GPU; Llama 70B + Hopper 2×+
NVIDIA Dynamo 是 NVIDIA 于 2025 年 3 月 18 日 GTC 主题演讲上发布的开源分布式推理服务框架，定位为"AI factory 的操作系统"。它不是一个新的推理引擎，而是站在 TensorRT-LLM / vLLM / SGLang 之上的编排层，把多机多卡的推理引擎实例组织成一个协调的 PD 分离集群，并提供 KV cache 感知的智能路由、多级 KV 缓存卸载、SLA 驱动的弹性扩缩容。本文聚焦 Dynamo 特有内容；PD 分离的通用原理见 9.2 Prefill/Decode 分离原理, KV 传输物理瓶颈见 9.7 KV cache 跨节点传输瓶颈。
为什么从 Triton 演化到 Dynamo
核心问题：Reasoning 时代 Triton 在哪几个维度撞墙？Dynamo 怎么回应？
Triton Inference Server （2018 年开源） 是 NVIDIA 多年来的通用推理服务器，覆盖 TensorRT / PyTorch / ONNX / OpenVINO / RAPIDS FIL 等多种 backend，但其设计假设是"模型 = 一个进程内的前向函数" — 一次推理请求由一个 worker 独立完成。这套假设在 reasoning model 时代撞墙：
- 请求生命周期不再是毫秒级：reasoning model (o1 / DeepSeek-R1 / Claude 3.7) 的 CoT 可生成上千个 token，单请求秒级到分钟级
- prefill / decode 资源画像截然不同：prefill compute-bound、decode memory-bound，硬塞同一 GPU 浪费一半
- KV cache 已是部署成本主体：长上下文场景 KV 远大于权重，但 Triton 无 KV cache 概念
- 请求间存在大量 prefix 重叠：system prompt、多轮对话天然重复，但 Triton 不感知
Dynamo 的回答：把推理 serving 重新定义为分布式系统问题 — [1] 把 prefill / decode 拆到不同 worker pool; [2] 在 worker 之上引入 KV cache 感知的全局调度；[3] 把 KV cache 从 GPU HBM 解耦到多级存储；[4] 用专门的传输库 (NIXL) 把这一切的跨节点搬运做到 RDMA 级延迟。Triton 没有消失 — 改名 Dynamo-Triton，继续做通用模型 serving; Dynamo 则是 LLM-specific 的新框架，与 Dynamo-Triton 互补而不重叠。
架构组件怎么分工
核心问题：数据面 + 控制面 + 入口 + 传输层各自的角色？事件流怎么走？
Dynamo 的组件按数据面与控制面两层划分：
| 层 | 组件 | 角色 |
|---|---|---|
| 入口 | Frontend | OpenAI-compatible REST API，接受 /v1/completions 等请求，做 tokenize 与协议转换 |
| 控制面 | Smart Router | KV-aware 路由决策，维护 Radix Tree 索引 worker KV 状态 |
| 控制面 | Planner | SLA 驱动的扩缩容控制器，监控队列长度与延迟 |
| 数据面 | Worker (Prefill) | 跑推理引擎做 prefill，输出 KV cache，发布 KV 块 stored 事件 |
| 数据面 | Worker (Decode) | 拉取 prefill 产出的 KV，做自回归 decode |
| 数据面 | KV Block Manager (KVBM) | 跨 worker 的多级 KV 存储抽象，整合 LMCache、Vast、WEKA 等存储插件 |
| 传输层 | NIXL | 零拷贝 RDMA / GDS / S3 over RDMA 等异构传输，被所有 worker 调用 |
@tbl-dynamo-components Dynamo 架构组件
事件流：Worker 通过 ZMQ pub-sub 把 KV 块的 Stored / Removed 事件广播给 Smart Router, Router 据此实时更新 Radix Tree。请求到达时，Router 计算请求 prefix 与各 worker 已缓存块的 overlap，结合 worker 当前 prefill 队列负载选 (prefill_worker, decode_worker) 对。Prefill 完成后通过 NIXL 把 KV 块直接 push 到 decode worker 的 GPU 内存，无需经过 Frontend 转发。
实现语言：核心 Rust (~54%) 跑性能敏感的 router / worker 控制逻辑，Python (~30%) 做接口与扩展，Go (~13%) 做基础设施工具。Rust 内核的目的是消除 Python GIL 在高并发路由场景下的延迟尾部。
Smart KV Router 是什么
核心问题：Radix Tree 索引怎么工作？路由 score 公式 + 三种路由模式？
Smart Router 是 Dynamo 区别于"普通 PD 调度器"的核心组件，做两件事：KV cache 命中最大化 + worker 负载均衡。
Radix Tree KV 索引：Router 把每个 worker 上已存在的 KV 块按 token hash 链组织成 Radix Tree。新请求到达时，对 prompt 做相同 hash，沿 tree 走最长公共前缀，得出每个 worker 的 effective_overlap_blocks （该 worker 命中的前缀块数）。Tree 的更新源是 worker 通过 ZMQ 发出的 Stored / Removed 事件，因此索引是 eventually-consistent 而非强一致。
路由打分：默认实现 DefaultWorkerSelector 把命中数与负载折成 logit:
score(w) = a * effective_overlap_blocks(w) - b * prefill_load_scale(w)
其中 prefill_load_scale 反映 worker 当前 prefill 队列深度。Router 选 score 最大的 worker 做 prefill。
三种路由模式：
| 模式 | 用法 |
|---|---|
| KV-aware （默认） | 用 Radix Tree + load score 选 prefill worker |
| Direct | 外部 orchestrator 已指定 worker, Router 直通 |
| Aggregated fallback | 没有 prefill pool 时退化为聚合 serving，直接选 decode worker |
@tbl-dynamo-router-modes Smart Router 的三种路由模式
与 Mooncake Conductor 的差别：Mooncake 的 Conductor 是单逻辑实例 （高可用副本），全局调度；Dynamo Smart Router 是分布式 Rust 服务，事件驱动更新，没有单点。两者都做 cache-aware 调度，但 Dynamo 的 Radix Tree 是 worker-side 事件触发的反推索引，Mooncake 的 prefix cache table 是 Conductor 维护的中心化结构。
KVBM 多级 KV cache 是什么
核心问题：四级存储介质 / 三层抽象 / 实测吞吐？
KV cache 随上下文长度线性增长，128K context 的 KV 体量可超过 GPU HBM; reasoning model 多轮对话场景累积更夸张。Dynamo 的 KV Block Manager (KVBM) 把 KV cache 视作分层存储对象：
| 层 | 介质 | 典型延迟 | 用途 |
|---|---|---|---|
| L1 | GPU HBM | ns | 当前活跃请求的 KV |
| L2 | Host DRAM | us | 短期空闲对话、prefix 共享池 |
| L3 | 本地 NVMe SSD | 10-100 us | 中期会话状态 |
| L4 | 远程对象存储 (Vast / WEKA / S3) | ms | 长尾用户的会话、跨集群共享 |
@tbl-dynamo-kv-tiers KVBM 的四级 KV cache 层级
KVBM 三层抽象：
- Model Integration 层：对接 TensorRT-LLM / vLLM （SGLang 在路上），把引擎的 KV 块语义抽象为统一接口
- Memory Management 层：追踪每个块的位置、热度，执行 offload / prefetch 策略
- Storage & Transfer 层：经 NIXL 完成跨机搬运，插件化对接 LMCache、Vast、WEKA 等存储
事件式 vs 拉取式：KV 块的搬运不是 batch 同步、而是事件触发的异步流水线 — prefill worker 算完一个块立即通过 NIXL push 到 decode worker （类似 Mooncake 的 layer-wise prefill），与下一个块的计算 overlap。
实测吞吐数据 （NVIDIA 公开博客）：
| 场景 | 吞吐 |
|---|---|
| Vast Data + GPU Direct Storage 到单 H100 | 35 GB/s |
| WEKA 经 RDMA zero-copy 到 8 GPU | 270 GB/s |
@tbl-dynamo-kv-bench KVBM 公开实测吞吐
这些数字是 KV 卸载链路 （远端存储 → GPU） 的纯传输带宽，单 H100 的 35 GB/s 接近 PCIe Gen5 x16 的上限 64 GB/s 的一半，说明 GDS 链路本身已逼近主机端硬件极限。
NIXL 传输底座是什么
核心问题：NIXL 的核心抽象 / 5 种 backend / 部署约束？
NIXL (NVIDIA Inference Xfer Library) 是 Dynamo 抽离出来的独立开源库，专门解决 inference 场景的 P2P 数据搬运。
核心抽象：用户用 descriptor 描述源/目的内存的位置 (host DRAM / GPU HBM / NVMe / object store)，调用 read / write 非阻塞接口，NIXL 根据 descriptor 自动选最优 backend:
| Backend | 适用路径 |
|---|---|
| UCX （默认） | 通用 RDMA (InfiniBand / RoCE) 与 TCP fallback |
| GPU-initiated networking | GDR-Copy, GPU 直接发起的 RDMA |
| GPU Direct Storage (GDS) | NVMe ⇄ GPU HBM 绕过 CPU |
| S3 over RDMA | 兼容 S3 协议的对象存储经 RDMA 加速 |
| Azure Blob | 公有云对象存储 |
@tbl-dynamo-nixl-backends NIXL 支持的传输后端
关键设计点：
- 非阻塞 post + 状态轮询：所有传输异步发起，调用方独立查询完成，便于与 compute overlap
- 动态元数据交换：worker 弹性加入/退出无需预设拓扑，适合长跑 serving 集群
- memory section + metadata handler：本地内存注册与远端代理元数据分离，支持热重连
部署约束：Dynamo 文档明确指出 KV 跨节点传输必须用 RDMA (IB / RoCE / AWS EFA)；纯 TCP fallback 下 TTFT 可能恶化 200-500 倍。NVLink 因为进程隔离原因不能桥接 pod。
Dynamo 跟既有推理栈是什么关系
核心问题：Triton / TRT-LLM / vLLM / SGLang 各自怎么定位？
| 组件 | 与 Dynamo 关系 |
|---|---|
| Dynamo-Triton （前 Triton） | 独立产品，仍服务通用模型 (ONNX / TensorRT / PyTorch / FIL)。Dynamo 文档定位 Dynamo 为 LLM-specific 补充：disagg serving + prefix caching + KV 多级缓存，Triton 不具备 |
| TensorRT-LLM | 被 Dynamo 调用的推理引擎之一，full backend 支持，自身也支持 disagg serving, Dynamo 在其上加多机编排与 KV-aware 路由 |
| vLLM | Dynamo 主流 backend 之一，KVBM 完整支持，二者深度集成 |
| SGLang | Dynamo 主流 backend, full disagg + KV-aware routing 支持；KVBM 集成在 2026 Q2 路线图上 |
| PyTorch | Dynamo 1.x 起作为 backend 支持，用于自定义模型 |
@tbl-dynamo-stack-relation Dynamo 与既有推理栈的关系
核心定位：Dynamo 是编排层 (orchestration)，不替代任何推理引擎。一个典型部署是 "Dynamo Frontend + Smart Router + Planner + 多个 SGLang 或 TensorRT-LLM worker"。对比来看：
- 单独跑 vLLM：单机 serving，自己做 PagedAttention 和 continuous batching，没有跨机 PD 分离
- 单独跑 SGLang：内置 PD 分离 mini-LB (详见 9.5 SGLang PD)，但调度策略相对静态、不做 KV 多级
- 用 Dynamo 串起 SGLang：保留 SGLang 引擎，把 mini-LB 换成 Smart Router，把 KV 接入 KVBM 多级存储
性能数据和适用场景
核心问题：官方 benchmark 数字 + 哪些场景适合 / 不适合？
官方公开 benchmark
| 模型 / 硬件 | 对比基线 | Dynamo 加速 |
|---|---|---|
| DeepSeek-R1 671B / GB200 NVL72 | 同硬件无 Dynamo | up to 30× tokens/GPU |
| Llama 70B / Hopper (H100/H200) | 同硬件无 Dynamo | 2×+ performance |
| MoE 模型 (wide EP) / GB200 NVL72 | NVIDIA B200 系统 | up to 7× MoE 吞吐 |
| Reasoning + GB200 NVL72 复合 | 基线 | up to 15× compounding |
@tbl-dynamo-bench-official Dynamo 官方公开 benchmark
注意事项：
- 这些数字是 NVIDIA 自家 benchmark，对比基线常是"同硬件不做 PD 分离 / 不开 KV-aware 路由"，并非与其他开源 serving 框架 (Mooncake / SGLang) 横评
- 30× / 15× 等 compounding 数字隐含的是 Dynamo 三大技术 (disagg + KV routing + KV offload) 同时启用
- 单独某一项 （例如只开 KV-aware routing） 的增益没有公开拆解
- 没有公开第三方 （MLPerf / 学术机构） 独立 benchmark; Mooncake FAST'25 论文的对比组里没有 Dynamo （Dynamo 发布晚 8 个月）
适用 / 不适用场景
适合：
- 长会话、多轮对话 → KV 卸载收益高
- 高并发、大量空闲会话 → 把闲 KV 沉到 DRAM/SSD 是关键
- 共享 system prompt 场景 → KV-aware routing 直接砍 prefill 重算
- 内存/成本受限部署 → 多级 KV 让单 GPU 等效"看见"更多 KV
- 主机带宽好的平台 (NVLink-C2C, e.g. GB200) → 卸载链路不堵
不适合：纯短请求 (chat-completion 1-2K input)、prefix 重叠极低 （例如 arXiv summarization），此时 KV-aware 路由命中率低、KV 卸载收益微弱，反而徒增 router 延迟。
Takeaway
| 知识点 | 核心结论 |
|---|---|
| 定位 | 编排层，不替代推理引擎，站在 TRT-LLM / vLLM / SGLang 之上 |
| 架构 | Frontend + Smart Router + Planner + Worker + KVBM + NIXL |
| Smart Router | 事件驱动 Radix Tree, score = a·overlap - b·prefill_load |
| vs Mooncake Conductor | 分布式 Rust 无单点 vs 单逻辑实例；事件驱动 vs 中心化 table |
| KVBM 四级 | HBM (ns) / DRAM (μs) / NVMe (10-100 μs) / 远程对象存储 (ms) |
| NIXL 5 backend | UCX / GDR / GDS / S3 over RDMA / Azure Blob |
| 部署约束 | 跨 pod 必须 RDMA (IB/RoCE/EFA); TCP fallback 200-500× 恶化 |
| 官方加速 | R1 671B + GB200 30×; Llama 70B + Hopper 2×+；但无第三方横评 |