NVIDIA Dynamo 1.0 如何赋能生产规模下的多节点推理

推理模型的规模正在迅速扩大，并越来越多地被集成到智能体（agentic）AI 工作流中，这些工作流会与其他模型和外部工具进行交互。在生产环境中部署这些模型和工作流需要将其分布在多个 GPU 节点上，这要求对 GPU 进行精心的编排与协调。

现已推出的 NVIDIA Dynamo 1.0 通过在大规模分布式环境中加速生成式 AI 和推理模型，解决了这些问题。该 AI 框架为生产级多节点 AI 部署提供低延迟、高吞吐量的分布式推理能力。

Dynamo 支持领先的开源推理引擎，包括 SGLang、NVIDIA TensorRT LLM 和 vLLM。它还在 MLPerf 和 SemiAnalysis InferenceX 等受信赖的第三方基准测试中取得了优异表现，进一步巩固了其作为生产级推理平台的地位。正如近期的 SemiAnalysis InferenceX 基准测试所示，Dynamo 在 NVIDIA Blackwell 上可将服务请求数量提升高达 7 倍。

SemiAnalysis InferenceX，更新于 2026 年 3 月 3 日。测试结果针对 DeepSeek R1-0528，FP4 精度，1k/1k，交互性能：约 50 tok/sec/user。

本文详细介绍了早期采用者如何将 Dynamo 集成到实际推理工作流中、所实现的系统级性能提升，以及为该框架添加的最新功能与优化。

早期采用者与实际影响

在去年的 GTC 大会上，NVIDIA 推出了 NVIDIA Dynamo，这是一个专为多节点 AI 部署构建的低延迟、高吞吐量分布式推理框架。自那时起，NVIDIA 一直与开源生态系统紧密合作，对 Dynamo 进行加固，以使其具备生产级性能并支持大规模工作负载。在此期间，Dynamo 取得了多项重要里程碑：

• 已成功部署于生产工作流：AstraZeneca、Baseten、ByteDance、CoreWeave、Crusoe、DigitalOcean、Gcore、GMI Cloud、Nebius、Meituan、Pinterest、Prime Intellect、Rednote、SoftBank Corp.、Tencent Cloud、Together AI、Vultr 等众多企业已在生产环境中部署 Dynamo，以扩展多节点推理、优化吞吐量并改善延迟。观看 Dynamo Day 录播，直接聆听已部署 Dynamo 的机构分享。
• 集成至托管 Kubernetes 环境：Alibaba Cloud、Amazon Web Services (AWS)、Google Cloud、Microsoft Azure 以及 Oracle Cloud Infrastructure (OCI) 已构建相关集成方案，展示如何将 Dynamo 无缝部署至其托管的 Kubernetes 环境中，以扩展推理能力来满足日益增长的 AI 需求。
• 获主流开源框架采用：NIXL 等模块化 Dynamo 组件已被 llm-d、NVIDIA TensorRT LLM、SGLang 和 vLLM 等推理引擎广泛采用，用于加速 GPU 间的 KV cache 传输。LMCache 已将其 KV 缓存直接集成至 Dynamo 的存储解决方案中，SGLang 已将其 HiCache 方案集成至 Dynamo 的 Router 中，LangChain 则构建了一项集成，可向 Dynamo 的 Router 注入智能体提示，充分验证了其可组合架构。
• 激发来自 AI 生态各方的贡献：AI 社区的开发人员为 Dynamo 做出了贡献并拓展了其功能。Mooncake 与 Alibaba 为 Dynamo AIConfigurator 扩展了 SGLang 支持；Microsoft 在 Azure Kubernetes Service (AKS) 上对 Dynamo 进行了测试与加固，贡献了修复代码、部署指南、公开演示以及 Planner/AIConfigurator 增强功能；Prime Intellect 协同设计并集成了 LoRA adapter 支持；Baseten 则在类生产环境中验证了早期 Dynamo 功能，随后将漏洞修复与加固补丁提交至上游。
• 实现与存储解决方案的集成：Cloudian、DDN、Dell、Everpure（原 Pure Storage）、HPE、IBM、NetApp、VAST 和 WEKA 已将 Dynamo 集成至其 AI 解决方案中。这使得推理工作负载能够突破 GPU 显存限制，借助存储技术支持超大上下文长度。

Dynamo 1.0 在这些里程碑的基础上进一步构建，标志着该框架的成熟度与生产就绪状态。继续阅读以了解本次更新的更多亮点。

借助 Dynamo 与 NVIDIA NeMo Agent Toolkit 将智能体推理加速 4 倍

当前的推理运行时对所有请求和 KV 缓存块一视同仁——在多轮对话中重复使用的系统提示词，其淘汰优先级与一次性使用的思维链相同。然而，多轮智能体会复用前缀并遵循可预测的模式。被驱逐的多轮 KV 缓存块需要重新计算，导致算力浪费和推理成本上升。Dynamo 通过全新的智能体推理优化填补了这一空白：

• Dynamo 前端 API：接收智能体提示（每次请求的元数据，如延迟敏感性、预期输出长度和缓存控制），并将其传递给路由器和 KV 缓存管理器。
• Dynamo KV 感知路由器：利用优先级和延迟相关的智能体提示控制队列顺序，确保面向用户的对话轮次优先于后台任务运行。它可接收预期输出序列长度（OSL）以提升负载均衡的准确性。
• Dynamo KV 缓存管理器：支持实验性的缓存锁定功能。被锁定的节点在指定时间内可抵抗淘汰，并会被移至主机内存而非直接删除。

社区基于这些优化构建了自定义路由，并将智能体提示集成到 LangChain 的 ChatNVIDIADynamo 和 NVIDIA NeMo Agent Toolkit 等流行框架中。

在 NVIDIA Hopper 平台上运行 Llama 3.1 模型时，结合 Dynamo 与 NeMo Agent Toolkit 可使 TTFT 最多缩短 4 倍，吞吐量提升 1.5 倍。

推进多模态推理优化

Dynamo 1.0 引入了三项新功能，旨在加速以图像为主的工作负载中的多模态推理——在这些场景中，图像编码可能成为瓶颈：

• 解耦的编码/预填充/解码（E/P/D）：Dynamo 不再将 E/P/D 运行在同一 GPU 上，而是将其划分为具有独立扩缩容能力的独立阶段。在专用工作节点上运行编码阶段可实现独立扩缩容，从而改善批处理、内存效率和整体吞吐量。
• 多模态嵌入缓存：一个基于 CPU 的最近最少使用（LRU）缓存将计算出的图像嵌入存储在 GPU 之外，使重复图像完全跳过编码步骤。该功能同时适用于解耦和聚合架构。
• 多模态 KV 路由：多模态 KV 路由扩展了 Dynamo 的 KV 感知路由器，以纳入图像内容考量。专用的多模态路由器会先下载图像，然后选择缓存重叠率最高的后端工作节点，包括包含图像的块的重叠情况。

在 NVIDIA GB200 上运行 Qwen3-VL-30B-A3B-Instruct-FP8 多模态模型时，Dynamo 的嵌入缓存将图像请求的首词元延迟（TTFT）最高缩短 30%，吞吐量最高提升 25%。

增加对视频生成的原生支持

新型视频生成模型正在为电影级画质和动作真实感树立新标杆。但高效部署它们并非易事：其推理工作负载计算和内存密集程度极高，尤其是在高分辨率下。

Dynamo 1.0 新增了对视频生成模型的原生支持，并集成了 FastVideo、SGLang Diffusion、TensorRT LLM Diffusion 和 vLLM-Omni 等领先的开源推理框架。这使得 Dynamo 的模块化架构——包括其低开销前端、流式传输能力和高效调度引擎——能够应用于现代视频工作负载。

该集成证明了最先进的视频生成技术可以在 Dynamo 上高效交付。如需了解如何使用 Dynamo 部署视频生成模型的分步指南，请查阅此操作指南。

使用 Dynamo ModelExpress 将推理启动速度提升 7 倍

现代推理集群会根据流量波动不断动态启停新的副本。每个新进程都必须重复执行同样繁重的启动流程：

• 下载模型检查点
• 从远程或共享存储加载权重
• 应用模型优化
• 编译内核
• 构建 NVIDIA CUDA 图

为解决这一挑战，Dynamo 确保通过两项全新的 ModelExpress 功能，将 Worker 启动过程中耗时的操作仅执行一次并多次复用：

检查点恢复：Dynamo 不再将每个副本视为全新启动，而是仅运行一次完整的初始化序列，将“就绪服务”状态捕获至持久化存储中，随后通过从该检查点恢复来使新副本上线，而非从头重新构建一切。

模型权重流式传输：ModelExpress 不再让每个新 Worker 独立下载模型权重、将其写入本地或共享存储后再加载至 GPU 内存，而是在初始 Worker 上仅加载一次模型，随后借助 NVIDIA Inference Xfer Library (NIXL) 和 NVIDIA NVLink，通过高带宽互连将权重直接流式传输至其他 Worker，从而消除对存储带宽的依赖。

对于大型模型，尤其是在需要快速大幅扩展的集群中，在 NVIDIA H200 上部署 DeepSeek v3 等大型 MoE 模型时，模型权重流式传输可将模型加载速度提升高达 7 倍。

在 NVIDIA GB300 NVL72 上扩展 Kubernetes

NVIDIA Grove 是 Dynamo 开源生态的一部分，它作为一个开源 API，简化了在 Kubernetes 上部署具有分层 Gang 调度与拓扑感知能力的 AI 工作负载。在 Dynamo 1.0 中，Grove 增加了对 NVIDIA GB300 NVL72 等机架级系统上 NVIDIA NVLink 架构的自动化配置功能。该功能允许用户定义跨越基础设施各层级的放置策略——从云区域和可用区，一直细化到数据中心、网络区块、机架、主机，乃至非统一内存访问（NUMA）节点。

传统上，使用 NVIDIA GB300 NVL72 的 NVLink 架构需要用户手动定义和管理计算域。本次版本引入了统一的拓扑 API，使开发者能够在同一 NVIDIA NVL72 机架上无缝共置预填充与解码任务，从而优化 KV 缓存传输；为满足低延迟需求，可将整个推理栈限制在单一数据中心内；同时可将前端服务部署在附近的纯 CPU 节点上以实现高效的请求处理。Grove 通过与先进的 AI 调度器（如 KAI scheduler）集成，确保这些约束条件得到严格贯彻。

与 Kubernetes Inference Gateway 的集成

此前的 Dynamo 版本曾引入一款插件，允许用户将 Kubernetes 原生的 Inference Gateway 扩展路由功能与 Dynamo 的 KV 感知路由相结合。

在典型的 Dynamo 部署中，路由由 Dynamo 的 KV 感知路由负责处理。该路由会评估每个工作节点的队列深度及相关 KV 缓存信息，随后通过加权综合这些因素来做出概率性路由决策。

Dynamo 的 KV 感知路由可运行于 Inference Gateway 内部，从而在基于 Kubernetes 的环境中充分利用路由插件、过滤器及其他网关能力的集成优势。

零配置部署快速且具备延迟感知能力的推理服务

部署大模型需要深厚的专业知识，以便通过复杂的扩缩容与配置步骤来平衡延迟、吞吐量和成本目标。Dynamo 全新推出的 Dynamo 图部署请求（DGDR）消除了这一障碍，提供了一条从服务级别目标（SLO）直达优化推理部署的简易单步路径。

DGDR 将 Planner 与 AIConfigurator 的智能相结合，整合为统一且 Kubernetes 原生的部署流程。开发者无需再穿梭于各类工具、脚本与反复试错之间，现在只需在 YAML 文件中指定模型、目标硬件与流量目标（未来不久将通过直观的 Web UI 提供），Dynamo 便会自动处理剩余环节。

在幕后，AIConfigurator 会运行基于仿真的快速推荐以支持敏捷迭代，而 Planner 则会进行更深度的集群内性能剖析，以实现精准的生产级优化。两条路径最终都会生成一个可自动部署的 Dynamo 图部署（DGD），在无需手动编写部署配置的情况下，精准匹配用户在成本、性能与可扩展性方面的期望平衡。

借助故障检测与请求迁移提升系统韧性

Dynamo 的核心设计原则之一是“默认具备韧性”，确保即使单个工作节点发生故障或卡死，应用程序仍能持续运行。更新后的 Dynamo 容错机制融合了两大核心支柱：

早期故障检测：Dynamo 新增了一种与框架无关的“金丝雀健康检查”机制，可按自定义频率对工作节点进行探测。若检查未收到有效响应，该节点将被标记为不健康并从路由列表中剔除。此外，Dynamo 前端还会利用网络层信号进行主动检测。若向某个工作节点建立新流连接失败，或现有流在请求处理中途意外中断，该节点将立即从活跃节点池中暂时剔除（约 5 秒），以确保不再向其分发新请求。

请求取消与迁移：开箱即用启用请求取消支持，允许在继续执行已无意义时终止正在进行中的任务。当某个工作节点不可用时，Dynamo 可将受影响的请求迁移至另一工作节点并恢复处理，从而保留请求本身，而非强制客户端从头重新提交。这确保了故障不会自动转化为用户可见的错误。

结合 Dynamo 新增的分层健康检测机制以及取消与迁移功能，Dynamo 旨在即使在单个工作节点发生故障时，也能保持 LLM 应用程序的响应能力。

将 KV 缓存扩展至存储

在 Dynamo 1.0 中，KV 块管理器（KVBM）引入了多项特性，以提升灵活性、可见性及部署选项：

• 对象存储支持：KVBM 现已兼容 Amazon Simple Storage Service (S3) 以及主流存储厂商和云提供商采用的 Azure 风格 Blob API。这使得模型运营者能够将 KVBM 与现有文件系统、S3 或其他云对象存储集成，而无需为每个后端单独构建 KV 卸载流水线。
• 全局 KV 事件发布：每当 KV 块在存储层级（GPU 内存、CPU 内存、本地 SSD 和远程存储）之间移动或被驱逐时，KVBM 都会触发事件。KV 路由器的索引器会消费这些事件，以维护跨集群一致的 KV 块位置视图，从而在多个模型副本和推理引擎之间实现更智能的路由和更高的缓存复用率。
• 可通过 pip 安装的模块：KVBM 现可直接安装至 vLLM 或 TensorRT LLM 等推理引擎中，无需依赖完整的 Dynamo 技术栈。使用不同推理框架的团队可以共享同一套 KV 卸载工具，而无需重新实现驱逐策略与存储集成。

展望未来

展望未来，Dynamo 产品路线图将侧重于扩展多模态能力，以支持更丰富且更具上下文感知能力的交互；推进基于扩散的模型，以解锁实时、更高质量的视频生成能力；以及扩展智能体工作负载和强化学习。Dynamo 正与社区一起在开放环境中构建。想要参与贡献，请访问 NVIDIA GitHub 仓库 查看代码和议题，参加双周的 Dynamo 办公时间，并深入阅读现有的技术博客。

致谢

Akshatha Kamath、Anish Maddipoti、Anna Tchernych、Ben Hamm、Biswa Ranjan Panda、Dhruv Nandakumar、Ekin Karabulut、Ganesh Kudleppanavar、Hannah Simmons、Hannah Zhang、Harry Kim、Hongkuan Zhou、Hyunjae Woo、Ishan Dhanani、Itay Neeman、Jacky Hui、Jakub Kosek、John Kim、Kavin Krishnan、Kyle Kranen、Maksim Khadkevich、Michael Demoret、Moein Khazraee、Neal Vaidya、Neelay Shah、Qi Wang、Ryan McCormick、Sanjay Chatterjee、Schwinn Saereesitthipitak、Suman Tatiraju、Vikram Sharma Mailthody、Vishwanath Venkatesan 以及许多其他人为本帖文做出了贡献。