OPEN SOURCE DEEP DIVE
Dynamo：推理引擎之上的数据中心级编排层，KV 感知路由、分层 KVBM 与 SLA 驱动的 Planner
NVIDIA 开源（Apache-2.0）的编排层，Rust 写性能路径、Python 留扩展面。明确不替代 SGLang/TensorRT-LLM/vLLM，而是把它们接成协同的多节点系统：分离式 prefill/decode、KV 感知路由（Qwen3-Coder 480B 上 TTFT 快 2 倍）、KVBM 把 KV cache 卸载到 CPU/SSD/远端、ModelExpress 走 NVLink 流式传权重让冷启动快 7 倍、Planner 按 SLA 自动扩缩（阿里生产环境违约少 80% 且 TCO 低 5%）、Grove 做 NVL72 拓扑感知调度。
引擎之上的那一层：把一堆 GPU 变成一个推理系统
Dynamo 是 NVIDIA 开源（Apache-2.0）的数据中心级推理栈，README 第一句就把自己的岗位说清楚了：它是推理引擎之上的编排层，不替代 SGLang、TensorRT-LLM 或 vLLM，而是把它们变成一套协同的多节点推理系统。用 Rust 写性能关键路径，用 Python 留扩展面。
这个定位很重要，因为它意味着 Dynamo 与前两者不是竞品而是上下层。单个引擎优化的是「一张卡或一个节点内部怎么把 token 吐得更快」；Dynamo 优化的是「一堆已经各自很快的节点，怎么在集群尺度上不互相浪费」。它也直说了边界：如果你只在一张 GPU 上跑一个模型，光用推理引擎就够了。
什么时候需要它：五个判据
README 给的使用场景清单可以直接当选型判据读：跨多张 GPU 或多个节点服务 LLM 且需要协调；想要 KV 感知路由以避免重复 prefill；需要让 prefill 与 decode 独立扩缩容（分离式服务）；想要在满足延迟 SLA 的前提下把总拥有成本压到最低的自动扩缩；需要新副本拉起时的快速冷启动。五条里有一条不成立，就该先考虑只用引擎。
六个核心组件
| 组件 | 做什么 | 为什么重要 |
|---|---|---|
| 分离式 Prefill/Decode | 把 prefill 与 decode 拆成可独立扩缩的 GPU 池 | 两个阶段的计算特征不同（prefill 算力密集、decode 访存密集），拆开才能各自跑到最优硬件配比，GPU 利用率上得去 |
| KV 感知路由 | 按 worker 负载与 KV cache 重叠度决定请求去哪 | 命中已有前缀就不必重算 prefill——公开结果是 TTFT 快 2 倍 |
| KVBM（KV Block Manager） | 把 KV cache 在 GPU → CPU → SSD → 远端存储之间分层卸载 | 有效上下文长度突破显存上限；长上下文与 agentic 长会话的容量问题从「买更多卡」变成「分层存储」 |
| ModelExpress | 通过 NIXL/NVLink 在 GPU 之间直接流式传输模型权重 | 新副本冷启动快 7 倍；扩容速度决定了自动扩缩能不能真的跟上流量 |
| Planner | SLA 驱动的自动扩缩器，先给负载画像再决定各池规模 | 在满足延迟目标的前提下最小化 TCO，把「留多少余量」从人工经验变成可计算 |
| Grove | Kubernetes operator，做拓扑感知的 gang scheduling（面向 NVL72） | 机架级部署里，副本落在哪个机架、哪台主机、哪个 NUMA 节点会直接改变通信成本 |
这六个组件合起来回答的是同一个问题：当推理从「一台机器上的一个进程」变成「一个数据中心里的一组服务」，多出来的那些成本（重复 prefill、冷启动、扩缩容余量、拓扑不匹配）该由谁吃掉。Dynamo 的答案是编排层。
公开结果与它的口径
| 结果 | 条件 |
|---|---|
| 每 GPU 吞吐高 7 倍 | DeepSeek R1 在 GB200 NVL72 上用 Dynamo，对比不用 Dynamo 的 B200（SemiAnalysis InferenceX） |
| 吞吐高 750 倍 | DeepSeek-R1 在 GB300 NVL72（InferenceX v2） |
| 模型启动快 7 倍 | ModelExpress 权重流式传输，DeepSeek-V3 在 H200 |
| TTFT 快 2 倍 | KV 感知路由，Qwen3-Coder 480B（Baseten 基准） |
| SLA 违约少 80% | Planner 自动扩缩，同时 TCO 低 5%（阿里云栖大会 2025） |
读这张表要小心两件事。第一，「7 倍」那一行同时换了硬件（GB200 NVL72 对 B200）与软件（有 Dynamo 对没有），所以它是整机架方案对单卡的比较，不是纯软件收益；「750 倍」同理，跨了两代机架。第二，2 倍 TTFT 与 80% SLA 违约这两行来自 Baseten 与阿里云的第三方场景，比 NVIDIA 自己的对比更可信，因为它们有具体负载（Qwen3-Coder 480B）与具体口径。本站按项目宣称收录前两条，第三方两条标注来源。
后端支持与治理
特性矩阵按后端分列：分离式服务、KV 感知路由、SLA Planner、多模态、工具调用在 SGLang / TensorRT-LLM / vLLM 三家都是全绿；KVBM 目前 SGLang 侧标注为在建，另两家已支持。完整矩阵还覆盖 LoRA、请求迁移、投机解码与特性间的相互作用。三个引擎都被当后端接，这本身就是「编排层不站队」的证据。
治理上有两点值得记录：一是仓库用 dep:draft / proposed / approved / implementing / completed / deferred / superseeded 一整套标签管理设计提案，设计讨论是公开且可追溯的；二是它维护公开的社区日历与例会（例如 2026-09-10 的 Baseten × Dynamo × SGLang RL 后训练 meetup），说明 RL 后训练的服务化已经是这条链路上的正式议题，而不只是推理服务的附属。
与本站已收录的 Neroued/ninfer 对照着看更有意思：ninfer 是把范围收到极窄（单卡、五个注册权重、拒绝非 sm_120a 架构）去换单卡极限吞吐，Dynamo 是把范围放到极宽（跨机架、跨引擎、跨存储层）去换集群效率。推理栈的两端各自都有人认真做，中间那段（单节点多卡的通用服务）才是 vLLM 与 SGLang 的主战场。