NVIDIA Dynamo 的 KV Cache 感知路由解决什么问题？

Q: Dynamo 的 KV Cache 感知路由主要解决什么问题？

解决多节点 LLM 推理中因请求随机分发导致的 KV Cache 复用率低、重复计算与网络冗余问题；其本质是将 KV 缓存状态作为路由决策的第一类因子。

Q: 芯元一实测中，KV 感知调度对吞吐与延迟的实际影响有多大？

在 480B·TP4×2 全机形态下，KV 分层加速吞吐提升 35–36%（R3 实测）；480B·TP8 三档并发下 TTFT p50 降低 26–32%（R2 实测）。

Q: 国产平台能否实现类似 Dynamo 的效果？是否必须用 NVIDIA 硬件？

不必依赖 NVIDIA 硬件；芯元一在 AMD MI308X 与昇腾 910B 平台均验证了 KV 感知路由语义层的可行性（R1/R8/R9 实测），关键在于构建可插拔的状态同步与决策模块。

发布2026/11/8DynamoKV Cache路由

直接答案

Dynamo 通过 KV Cache 感知路由缓解跨节点推理中 KV 重传与缓存不一致问题；芯元一 FX100 实测在 TP4×2 全机形态下 KV 分层加速吞吐提升 35–36%（R3 实测），验证该类架构对国产算力栈的适配价值。

Dynamo 的 KV Cache 感知路由本质是解决“谁该服务谁”的调度失配

NVIDIA Dynamo 是其 G3.5 AI 原生网络架构中面向大模型推理服务的关键组件，定位为「KV Cache 感知的分布式路由层」。它不直接存储 KV，也不执行计算，而是通过实时感知各 GPU 节点上已缓存的 KV Cache 片段（key-value token pairs），动态决定新请求应路由至哪个节点——前提是该节点已持有对应前缀的 KV 缓存。据《Introducing NVIDIA BlueField-4-Powered Inference Context Memory Storage Platform》技术博客，Dynamo 与 CMX（Context Memory Storage）、Spectrum-X 构成协同通路：CMX 提供低延迟上下文存储层，Spectrum-X 提供 pod 级高带宽互联，而 Dynamo 则负责在二者之间建立语义级路由决策。

这一设计直指当前多节点 LLM 推理中的一个隐性瓶颈：KV Cache 复用率低导致的重复计算与网络放大。当同一用户会话或共享前缀的批量请求被随机分发至不同节点时，各节点需独立重算相同前缀的 KV，不仅浪费显存带宽（如 vLLM 中 PagedAttention 已优化单卡内碎片，但跨节点无感知），更引发 RoCE 网络中大量冗余 KV 传输。SGLang 论文指出 RadixAttention 依赖前缀树复用机制提升命中率，但该机制的前提是请求能被导向已缓存对应前缀的节点——这正是 Dynamo 所补足的调度层能力。

换言之，Dynamo 解决的不是“能不能存”，而是“存了之后能不能被正确找到并复用”。它把 KV Cache 从被动存储对象，升级为主动参与路由决策的第一类调度因子。

路由失配的代价：实测中可见的吞吐与延迟双损

路由失配的工程后果，在芯元一 R2/R3 实测中具象化为两个可量化的性能洼地：

第一，冷恢复长上下文场景下吞吐显著受限。以 480B MoE 模型（Qwen3-Coder-480B-FP8）在 TP4×2（8 卡）部署形态为例：若无 KV 感知路由，各节点 KV 缓存孤立，冷启动后需频繁跨节点拉取或重算，导致实测吞吐仅 4.1 tok/s（R2 实测）；启用 FX100 KV 分层加速后，全机口径吞吐达 74.9 tok/s，提升 17.3× ——但该值仍受限于基线路由策略。进一步在 TP4×2 全机形态下引入 KV 感知调度逻辑（R3 实测），吞吐提升稳定落在 +35–36% 区间，说明路由优化与存储加速存在正交增益。

第二，首 token 延迟（TTFT）受并发干扰剧烈。R2 实测显示：480B·TP8 配置下，并发从 1 升至 16 时，TTFT p50 从 10.17s 恶化至 35.73s（+251%）。该恶化主因并非计算瓶颈，而是多请求争抢有限的 KV 加载通道，且无路由引导导致冷盘读取比例升高。当路由能将共享前缀请求聚向同一缓存节点，冷读盘频次下降，TTFT p50 可稳定压至 7.53–26.35s 区间，降幅达 26–32%。

这两组数字共同指向一个结论：KV Cache 的物理存在 ≠ 逻辑可用；路由层缺失，会使存储层加速收益被网络与调度开销部分抵消。

国产算力栈的适配路径：不复制 Dynamo，但需同等路由语义能力

Dynamo 是 NVIDIA 封闭生态中的专有组件，其深度耦合 BlueField DPU、DOCA Memos 与 Spectrum-X 硬件栈，无法直接移植。但其背后的技术诉求——即“基于 KV Cache 存在状态的动态请求分发”——具有普适性。Mooncake 论文提出的 KVCache-centric disaggregated architecture，亦强调跨节点 KV 池化与前缀复用需配套的请求路由机制，印证了该范式非 NVIDIA 独有。

芯元一在 AMD MI308X ×8 平台（ROCm 7.2 + vLLM 0.20.1）上的实测表明：即使无 Dynamo 类原生路由，通过在 vLLM 上游代码中注入 KV 缓存状态探针（R8 报告），配合 FX100 阵列的 NVMe-oF 元数据一致性保障，已可实现类似效果。例如在 Qwen2.5-32B 冷读盘场景中，LMCache 并行读补丁使 TTFT 从 37.97s 降至 9.30s（R1 实测），改善达 4.1×，其底层依赖正是对 KV 片段位置的精确感知与定向拉取。

这意味着，国产算力栈无需复刻 Dynamo 的具体实现，但必须构建等效的 KV-aware routing semantic layer：它可运行于 CPU 或 DPU，不强求硬件绑定，但需满足三项能力：（1）实时同步各节点 KV 缓存指纹（如前缀哈希、token range）；（2）支持低延迟查询与路由决策（<1ms）；（3）与现有推理框架（vLLM/SGLang）兼容的插件接口。R9 实测中 FX100 在昇腾 910B 平台对 DeepSeek-70B 模型加载加速达 9.3×（1399s → 150s），也佐证该语义层在异构平台上的可迁移性。

结语：路由是 KV Cache 价值释放的“最后一公里”

Dynamo 的核心启示不在于其专利代码，而在于它将 KV Cache 从“被管理的对象”升维为“调度的依据”。在国产算力中心建设中，存储加速（如 FX100/FX300）与网络升级（RoCEv2/Spectrum-X 类比方案）已逐步落地，但若路由层仍沿用传统负载均衡策略，KV Cache 的复用潜力将长期被低估。芯元一提供全栈联测服务（G1–G4 门禁化流程），支持客户在真实生产模型（480B/32B/14B）与硬件平台（AMD/昇腾）上，验证 KV 感知路由语义层与自研存储阵列的协同效能。如需该形态，可在联测中定制验证。