随着大语言模型参数规模从数十亿跃升至数千亿，单 GPU 的内存与算力已无法承载完整的推理需求。模型并行技术虽然解决了容量问题，却引入了新的挑战：如何在成百上千块 GPU 之间协调请求路由、共享 KV 缓存，并确保数据搬运的开销不会抵消并行计算带来的收益。NVIDIA Dynamo 正是为填补这一 orchestration 空白而生的数据中心级分布式推理服务框架。
分离式服务的性能跃迁
传统的大语言模型部署将推理过程的两个阶段 —— 预填充（prefill）与解码（decode）—— 放在同一 GPU 或同一节点上执行。这种聚合式部署虽然实现简单，却忽视了两个阶段截然不同的计算特性。预填充阶段处理用户输入并生成首个输出 token，属于计算密集型操作，其耗时与输入序列长度呈线性关系；而解码阶段逐 token 生成后续内容，属于内存密集型操作，瓶颈在于从显存中读取已缓存的键值向量。当长输入短输出的请求（如摘要任务）涌入时，预填充 GPU 成为瓶颈，而解码 GPU 却处于闲置状态，资源利用效率大打折扣。
Dynamo 引入的分离式服务（disaggregated serving）将这两个阶段部署在不同的 GPU 集合甚至不同节点上，使每个阶段可以独立选择最优的模型并行策略。例如，预填充阶段可以采用较低的张量并行度以减少通信开销，而解码阶段可以采用较高的张量并行度以提升内存带宽利用率。这种解耦使得系统能够针对不同请求模式动态调整资源配置，在吞吐量与延迟之间做出更精细的权衡。实际测试表明，在 NVIDIA GB200 NVL72 上运行 DeepSeek-R1 671B 模型时，Dynamo 通过分离式服务将请求吞吐量提升至传统聚合部署的 30 倍；在 Hopper GPU 上运行 Llama 70B 时，性能提升也超过两倍。
智能规划器的动态资源调度
分离式服务虽然能显著提升性能，但并非所有场景都适用。当预填充请求激增而解码资源闲置时，强行分离反而会增加 KV 缓存跨节点传输的延迟开销。此时更合理的策略是将部分解码 GPU 临时转为预填充任务，或者在聚合模式下处理这批请求。决策需要综合考量 GPU 队列等待时间、KV 缓存传输耗时、不同配置下的处理时长预估，以及服务级别目标（SLO）如首 token 时间与 token 间延迟的约束。在拥有数百块 GPU 的大规模集群中，这种决策的复杂度呈指数级增长。
Dynamo Planner 正是为解决这一决策难题而生。它持续监控集群中各 GPU 的容量指标，包括计算利用率、内存占用、请求队列长度等，并将这些实时数据与应用的 SLO 要求相结合。Planner 会在每轮调度决策中评估当前请求应当采用分离式还是聚合式服务，以及应当为预填充和解码阶段各分配多少 GPU 资源。当系统负载变化时，Planner 会自动触发 GPU 资源的动态再分配，确保整体吞吐量最大化同时满足延迟约束。这一机制使得 Dynamo 能够在流量高峰期快速扩容预 - fill 资源，在低谷期回收闲置节点，实现按需分配的弹性调度。
KV 缓存感知的智能路由
在多轮对话或智能体工作流中，同一用户的请求往往与历史上下文高度相似。如果每次都重新计算 KV 缓存，不仅浪费计算资源，还会显著增加响应延迟。高效复用 KV 缓存的关键在于快速判断新请求与已有缓存的相似度，并将请求路由至缓存命中的工作节点。然而在分离式服务或多节点部署中，KV 缓存分散在大量 GPU 的显存中，如何追踪这些缓存的位置并做出最优路由决策，是一个分布式系统层面的难题。
Dynamo Smart Router 采用基数树（Radix Tree）结构索引所有活跃的 KV 缓存块，并为每个新请求计算与现有缓存的 overlap 分数。该分数综合考量缓存命中率与集群负载均衡，最终决定将请求发送至哪个 GPU 节点处理。与简单的轮询或基于负载的路由不同，Smart Router 将缓存复用率纳入路由决策的核心考量，从而减少不必要的重复计算。测试数据显示，在 DeepSeek-R1 Distill Llama-70B 模型的 100K 真实请求测试集中，Smart Router 相比传统路由方案显著降低了 KV 缓存的重新计算开销，使 GPU 能够服务更多用户请求。
多层次 KV 缓存管理策略
KV 缓存的存储成本随并发请求数线性增长，而 GPU 显存容量有限且价格高昂。当缓存规模扩大到数十 TB 甚至 PB 级别时，将其全部保留在 GPU 显存中既不经济也不现实。Dynamo 的分布式 KV 缓存管理器（KV Cache Manager）允许将访问频率较低的缓存块逐级迁移至成本更低的存储层次：首先是主机 CPU 内存，然后是本地 SSD，最后是网络对象存储。这种分层策略使得系统能够在控制存储成本的同时，保留历史缓存以供复用。
缓存管理器的淘汰策略需要在缓存命中率与查找延迟之间取得平衡。过于激进地淘汰会导致大量缓存失效，增加重复计算开销；过于保守则会占用过多上层存储资源，增加元数据管理的复杂度。Dynamo 的智能淘汰策略基于访问频率与时间局部性动态调整各层存储的配额，确保高频访问的数据优先保留在 GPU 显存中。此外，该管理器支持跨节点、跨集群的分布式缓存索引，能够在分离式服务场景下协调预填充与解码节点之间的缓存共享。值得注意的是，KV 缓存管理器采用框架无关的设计，可与 PyTorch、SGLang、TensorRT-LLM、vLLM 等主流推理引擎协同工作。
低延迟异构数据传输层 NIXL
分离式服务与多层次缓存管理都依赖于高效的数据搬运能力。在大规模部署中，KV 缓存需要在预填充 GPU 与解码 GPU 之间传输，张量并行需要跨节点的 AllReduce 通信，缓存逐层下放需要跨存储介质的读写。传统方案需要针对每种数据传输场景选择不同的底层库与协议，增加了系统复杂度和性能优化的难度。
NVIDIA 推理传输库（NIXL）为 Dynamo 提供了统一的异步数据传输 API，能够在异构内存与存储之间高效移动数据。NIXL 支持 HBM、DRAM、本地 SSD、网络块存储与对象存储等多种内存区域，并兼容 NVLink、NVSwitch、InfiniBand、RoCE 与以太网等多种互连协议。无论数据源是 GPU 显存还是远程对象存储，NIXL 都提供一致的非阻塞传输语义，使上层应用无需关心底层实现细节。结合 Dynamo 的策略引擎，NIXL 能够自动选择最优的传输后端，在延迟与吞吐量之间做出最佳权衡。实测表明，借助 NIXL 与 Dell PowerScale 存储的集成，DeepSeek 模型的 TTFT 性能提升了 19 倍。
部署实践与框架集成
Dynamo 采用 Rust 与 Python 混合开发，核心调度与数据传输组件以 Rust 编写以确保高性能，插件与上层接口采用 Python 以便于扩展。作为推理引擎无关的框架，Dynamo 同时支持 vLLM、SGLang 与 TensorRT-LLM 三大主流后端，并提供统一的 OpenAI 兼容 HTTP 前端。部署时只需启动前端服务、路由器与工作节点，即可组建完整的推理集群。前端支持 TLS 加密与多种 KV 存储后端（包括 etcd 与文件系统），能够适应不同的生产环境需求。
在实际落地过程中，需要关注几个关键配置参数。首先是分离式服务的启用阈值，建议根据请求的输入输出序列长度比例动态切换 —— 当输入序列显著长于输出序列时，分离式服务收益更大。其次是 KV 缓存的淘汰策略参数，包括各层存储的容量上限与淘汰触发阈值，需根据工作负载的访问模式进行调整。此外，NIXL 的传输并发度与缓冲区大小也会影响跨节点数据传输的效率，建议在部署前通过基准测试确定最优配置。
NVIDIA Dynamo 的开源仓库提供了完整的文档、容器镜像与示例配置，开发者可根据自身基础设施选择 Kubernetes 编排或裸机部署方式。对于追求极致性能的生产环境，Dynamo 也将与 NVIDIA AI Enterprise 和 NIM 微服务集成，提供企业级的支持与稳定性保障。
资料来源：NVIDIA 官方技术博客与 ai-dynamo/dynamo GitHub 仓库。