NVIDIA Dynamo 1.0：推理扩展首先是调度问题

先说结论

模型放上更多 GPU，不会自然得到低延迟。生产推理要同时解决请求该去哪、KV cache 在哪、prefill 与 decode 如何扩缩、故障后请求如何迁移。Dynamo 1.0 的价值更像推理控制平面：协调已有 engine、缓存、网络和 Kubernetes，而不是替换模型。

问题

Agent 请求长度差异大，还会重复系统提示和历史前缀。普通轮询可能把请求送到没有缓存的 worker，重新做 prefill；长输出又会堵住短交互。扩容时每个副本重复下载权重、编译 kernel，也让流量高峰中的 GPU 等待。单看 tokens/s 会遮住首 token、并发量和启动时间之间的取舍。

核心机制

Dynamo 支持 vLLM、SGLang 和 TensorRT-LLM 等 engine。KV-aware router 结合队列与缓存重合度选 worker；frontend 可传延迟敏感度、预期输出长度和缓存控制等 hint；KV manager 能分层保存与追踪 cache。encode、prefill、decode 可拆开独立扩缩，ModelExpress 则通过就绪 checkpoint 和高速权重流复用启动工作。健康探针、网络信号、取消与迁移处理失效 worker。

原文报告，在特定 Blackwell InferenceX 配置中请求量最高提升 7 倍；Hopper 上结合 NeMo Agent Toolkit 的实验首 token 时间最高降低 4 倍、吞吐最高提高 1.5 倍。它们是 NVIDIA 引用的特定软硬件与负载结果，本教程没有独立复现。

如何接到 Zero-to-AI 学习实践

先为服务定义三项 SLO：首 token、每用户生成速度、可承受并发。再给请求记录输入长度、预期输出、共享前缀 ID 和优先级。只有观察到缓存错配或队列不均，才引入 KV 感知路由；单机小流量不要为了“生产级”先上多节点控制面。

测量时把 prefill、decode、排队和数据搬运分开。长输入短输出通常更在意 prefill 与缓存复用，短输入长输出更容易受 decode 资源约束。路由器做出的选择也要留下原因和命中状态，否则平均延迟变差时无法判断是缓存陈旧、队列预测错误，还是 worker 本身异常。

先用真实流量分布做容量画像，再谈扩容策略。

低成本实验

用表格或几十行本地脚本模拟两台 worker、12 个请求。为每个请求填 prefill 成本、decode 步数和前缀 ID。比较轮询与“优先送到已有同前缀 cache、否则选短队列”两种策略，计算总重复 prefill、平均等待和最长等待。再让一台 worker 在第六个请求失效，记录是否可迁移。这个实验验证调度直觉，不代表 GPU 性能复现。

成功证据： 两种策略的计算规则和逐请求结果可复核；至少出现一个“缓存更近但队列更长”的冲突案例，并能同时报告重复 prefill、平均等待与最长等待。

停止线： 没有冲突案例、失效 worker 的处理规则不一致，或开始把表格模拟推导成真实集群性能时，停止比较并补齐实验条件。

误区

• KV 命中最高不一定整体最优，拥塞 worker 的等待可能超过重算成本。
• 把 prefill/decode 拆开会增加传输与运维复杂度，负载不匹配时未必获益。
• “production-ready”是厂商对 1.0 与生态采用的定位，不等于任何集群无需容量测试和故障演练。

原文与证据边界

页面同时包含产品说明、合作方案例和厂商基准。公开信息足以理解组件职责，但不足以推导个人硬件收益。所有倍数都需绑定页面给出的模型、GPU、数据集、并发与 SLO 条件。

本文是原创中文实践解读，不是逐句译文。英文原文见 NVIDIA 官方技术文章。