揭秘 NVIDIA Dynamo：分布式AI推理的高效引擎

全文概览

随着生成式AI模型规模的爆炸式增长，企业面临推理成本激增、分布式部署复杂度高、资源利用率低等挑战。传统推理框架在跨多节点扩展时，常因KV缓存重复计算、GPU负载不均、通信延迟等问题导致性能瓶颈。NVIDIA Dynamo作为新一代开源推理框架，专为大规模分布式环境设计，通过解耦式服务、智能路由、动态资源调度等创新技术，将推理吞吐量提升30倍以上。本文将深入解析其核心架构、技术优势及实际应用场景，帮助开发者高效部署生成式AI模型，降低推理成本并释放GPU潜能。

1. 核心创新

• 解耦式服务：分离预填（计算密集型）与解码（内存密集型）阶段，独立优化资源分配。
• 动态GPU调度：根据实时负载智能分配GPU资源，平衡预填与解码阶段的计算需求。
• LLM感知的KV缓存复用：减少重复计算，提升缓存命中率。
• 异步数据传输：通过NVIDIA推理传输库（NIXL）实现跨GPU低延迟通信。

2. 技术对比与适用场景

• 与主流框架对比：
  • Dynamo：动态图优化，无缝集成PyTorch生态，适合快速迭代与中小规模部署。
  • TensorRT-LLM：极致性能优化，适合生产环境对延迟敏感的场景。
  • vLLM：高并发连续批处理，适用于通用推理服务。

3. 关键技术组件

• 规划器：动态监控GPU负载，优化资源分配策略。
• 智能路由：基于KV缓存重叠分数与负载均衡，智能分配请求。
• 分布式KV缓存管理器：分层存储KV缓存，释放GPU内存压力。
• NIXL通信库：跨异构存储的高性能数据传输，支持GPUDirect RDMA与网络化存储。

阅读收获

1. 掌握解耦式服务原理：理解如何通过分离预填与解码阶段提升吞吐量。
2. 技术选型指南：根据场景选择Dynamo、TensorRT-LLM或vLLM框架。
3. 资源优化策略：学习动态调度、KV缓存分层管理等实用技巧。
4. 部署实战经验：获取从单GPU到千卡集群的扩展方法与工具链支持。

NVIDIA今日在GTC 2025大会上宣布推出NVIDIA Dynamo。NVIDIA Dynamo是一款面向大规模分布式环境部署生成式AI和推理模型的高性能、低延迟开源推理服务框架。在NVIDIA Blackwell上运行开源DeepSeek-R1模型时，该框架可将处理请求数量提升高达30倍。NVIDIA Dynamo兼容PyTorch、SGLang、NVIDIA TensorRT-LLM和vLLM等开源工具，进一步扩展了推理工具社区，助力开发者和AI研究人员加速AI开发。

20250326-2214-7.png

NVIDIA Dynamo的核心创新包括：

• 通过分离预填和解码推理阶段提升GPU吞吐量 • 根据动态需求智能调度GPU以优化性能 • 基于LLM感知的请求路由避免KV缓存重复计算成本 • GPU间异步数据传输加速缩短推理响应时间 • 跨不同内存层级卸载KV缓存提升系统吞吐量

Dynamo 与常见推理框架的差异是什么？

Dynamo 作为 NVIDIA 的推理优化工具，与其他主流推理框架（如 vLLM、TensorRT-LLM、SGLang）在设计目标、优化策略和应用场景上有显著差异。以下从技术实现、性能优化和适用场景三个维度对比分析：

一、核心定位差异

二、关键技术差异

1. 动态图 vs 静态图优化

• Dynamo： • 动态编译：基于 PyTorch 的动态计算图（JIT），实时优化模型执行路径。 • Python 原生：保留 Python 语法灵活性，支持动态形状（Dynamic Shape）和条件分支。 • 其他框架： • vLLM/SGLang：依赖静态图优化，需预先固定模型结构和输入形状。 • TensorRT-LLM：通过 ONNX 转换实现静态图优化，牺牲部分灵活性换取性能。

2. 批处理策略

• vLLM： • 连续批处理（Continuous Batching）：动态合并请求，减少空闲时间，适合高并发场景。 • Dynamo： • 解耦式服务（Decoupled Serving）：上下文编码与生成阶段分离，独立优化资源分配。 • TensorRT-LLM： • 静态批处理：预定义最大批次大小，需权衡内存占用与吞吐量。

3. 内存与量化支持

三、适用场景对比

1. 开发效率优先

• Dynamo： • 适合需要快速迭代、依赖 PyTorch 生态的场景（如研究实验、中小规模部署）。 • 示例：微调后的 LLaMA 模型快速部署为 API 服务。 • vLLM： • 适合高并发通用服务，但对模型修改灵活性较低（需适配其 API）。

2. 性能极致优化

• TensorRT-LLM： • 适合生产环境对延迟和吞吐量要求极高的场景（如自动驾驶实时推理）。 • 示例：部署 175B 参数 GPT 模型的 FP8 量化版本。 • SGLang： • 适合自定义 Transformer 变体模型（如 Sparse Mixture-of-Experts）。

3. 硬件适配

• Dynamo： • 依赖 PyTorch 的 CUDA 生态，适配 NVIDIA GPU（需 CUDA 11.8+）。 • TensorRT-LLM： • 支持多厂商硬件（如 NVIDIA/AMD），但需 ONNX 格式转换。

四、典型工作流对比

Dynamo 工作流：

• 1
• 2
• 3
• 4

# PyTorch 动态图 → Dynamo 编译 → 服务化部署
model = torch.load("llama.pt")
compiled_model = dynamo.optimize(model, backend="trt")  # 使用 TensorRT 后端
serve(compiled_model)  # 集成到 FastAPI 等框架
Copy

vLLM 工作流：

• 1
• 2

llm = LLM(model="meta-llama/Llama-2-7b", dtype="f16", enable_lora=False)
output = llm.generate(requests)  # 内置连续批处理
Copy

TensorRT-LLM 工作流：

• 1
• 2

# ONNX 转换 → TensorRT 编译 → C++ 部署
python -m tensorrt_llm.builder --model=lmsys/vicuna-13b-v1.5 --fp8
Copy

五、总结

• Dynamo 的优势： • 无缝集成 PyTorch 生态，降低迁移成本。 • 动态编译平衡灵活性与性能，适合快速迭代场景。 • 局限性： • 性能略逊于 TensorRT-LLM 等纯 C++ 优化框架。 • 依赖 PyTorch 运行时，无法完全脱离 Python 环境。

选择建议： • 若需快速部署 PyTorch 模型并保持灵活性 → Dynamo • 若追求极端性能且接受部署复杂度 → TensorRT-LLM • 若专注高并发通用服务 → vLLM

即日起，开发者可通过ai-dynamo/dynamo GitHub仓库获取NVIDIA Dynamo。对于寻求快速投产和企业级安全、支持及稳定性的企业，NVIDIA Dynamo将作为NVIDIA AI Enterprise的一部分，集成到NVIDIA NIM微服务中。

本文档将详解NVIDIA Dynamo的架构与核心组件，重点阐述其如何通过解耦式服务实现生成式AI模型的经济高效扩展，从单GPU到数千GPU规模。

加速多节点AI推理部署

AI推理将助力开发者通过整合推理模型到工作流中，构建更直观理解用户需求的突破性应用。然而这也带来显著的持续性成本，对那些希望以可控成本扩展模型以满足AI爆炸性需求的企业构成挑战。

自NVIDIA于2018年推出首款开源AI推理服务器NVIDIA Triton以来，其目标始终是加速AI创新并降低推理成本。作为首个整合TensorFlow、PyTorch、ONNX、OpenVINO等框架专属推理服务的统一平台，Triton显著降低了推理成本并缩短了AI模型上市时间（TTM）。目前该平台已被亚马逊、微软、甲骨文云、DocuSign、Perplexity、Snap等全球领先企业用于生产环境部署，下载量超过100万次。

随着开源模型规模增长近2000倍，并越来越多地集成到需要与其他模型交互的智能AI工作流中，生产环境部署变得愈发复杂。跨多节点分布式部署需要精细的GPU集群编排协调，而新出现的分布式推理优化方法（如解耦式服务）将单个用户请求拆分到不同GPU处理，进一步增加了协作与数据传输的挑战。

为应对分布式生成式AI推理服务的挑战，我们推出NVIDIA Dynamo——Triton的继任者。基于Triton的成功经验，Dynamo采用全新模块化架构，专为多节点分布式环境部署生成式AI模型而设计。

多节点分布式环境部署LLM 存在哪些挑战？

一、硬件与资源管理挑战

1. 内存管理难题 大模型参数量巨大，单节点显存易饱和，需通过分层缓存策略（如将不常用参数存储在低速存储）和量化技术（如FP16/BF16精度压缩）优化内存占用。
2. 计算资源需求高 模型推理需大量GPU并行计算，需合理分配节点资源并设计算子融合、图优化等策略提升吞吐量。
3. 能耗与成本控制 大规模部署导致高电力消耗，需通过动态资源调度（如GPU预留实例）和模型压缩（如知识蒸馏、剪枝）平衡性能与成本。

二、网络与通信优化挑战

1. 通信延迟与带宽限制 节点间数据传输依赖网络拓扑，需配置高速互联（如InfiniBand）或优化NCCL库参数（如设置NCCL_SOCKET_IFNAME指定网卡）以减少通信开销。
2. 分布式同步与容错 需实现故障恢复机制（如Ray集群的自动容错）和一致性协议（如Paxos），确保部分节点失效时系统仍稳定运行。

三、模型并行化与扩展性挑战

1. 模型切分与负载均衡 需采用流水线并行（Pipeline Parallelism）或张量并行（Tensor Parallelism）技术分配计算任务，避免热点数据导致负载失衡。
2. 可扩展性限制 随模型规模增长，需验证系统线性扩展能力，通过动态调整批处理大小和序列长度优化资源利用率。

四、数据与稳定性挑战

1. 数据一致性与缓存策略 多节点需保证KV缓存共享或通过分布式文件系统（如NFS）同步模型参数，同时设计缓存亲和性策略减少跨节点访问延迟。
2. 服务稳定性保障 需建立监控与告警机制（如实时跟踪延迟、吞吐量），结合A/B测试验证模型在不同场景下的鲁棒性。

NVIDIA Dynamo支持跨GPU节点无缝扩展推理工作负载，并通过动态GPU工作线程分配高效应对波动需求及多模型AI流水线的流量瓶颈。该框架兼容NVIDIA TensorRT-LLM、vLLM、SGLang等主流LLM框架，集成包括解耦式服务在内的前沿优化技术，将推理的不同阶段分配到不同GPU设备以提升性能。

在NVIDIA GB200 NVL72上实现LLM推理性能30倍提升

传统LLM部署将预填和解码阶段置于同一GPU或节点，尽管这两个阶段对资源需求差异显著。这种做法限制了性能优化，导致GPU资源利用率不足。

预填阶段处理用户输入生成首个输出标记，属于计算密集型；而解码阶段生成后续标记，属于内存密集型。将两者部署在同一GPU或节点会导致资源利用低效，尤其在长输入序列场景下。此外，不同硬件需求也限制了模型并行策略的灵活性，导致性能潜力未被充分挖掘。

为解决这些问题，解耦式服务将预填和解码阶段分配到不同GPU或节点。这使开发者能够独立优化各阶段，采用差异化的模型并行策略，并为不同阶段分配不同GPU设备（图1）。

20250326-2214.png

图1. 解耦式服务将预填和解码分配至不同GPU以优化性能

例如，预填阶段可采用低张量并行度以减少通信开销，而解码阶段则通过高张量并行度提升内存操作效率。这种设计实现了更高效的资源分配、降低服务成本，并更好地控制服务级别目标（如首次响应时间TTFT和逐标记延迟ITL）。

在NVIDIA GB200 NVL72上部署开源DeepSeek-R1模型时，NVIDIA Dynamo通过解耦式服务将处理请求数量提升高达30倍。在NVIDIA Hopper上部署Llama 70B模型时，其吞吐量性能更是提升超过两倍。

20250326-2214-1.png

图2. 当在NVIDIA GB200 NVL72上运行DeepSeek-R1 671B模型时，NVIDIA Dynamo实现了卓越的吞吐量性能，性能提升达30倍。在NVIDIA Hopper GPU上运行Llama 70B模型时，其性能提升超过两倍。

左：TensorRT-LLM，FP4，ISL/OSL（输入/输出）：32K/8K。未启用Dynamo：飞行批处理，TEP16PP4DP4。启用Dynamo：解耦式服务，上下文：EP4DP16，生成：EP64DP3。预计性能可能发生变化。 右：vLLM，FP8，ISL/OSL（输入/输出）：3K/50。未启用Dynamo：飞行批处理，TP8DP2。启用Dynamo：解耦式服务，上下文：TP2DP4，生成：TP8。

对上述推理调优参数的理解

1. vLLM

• 意义：基于 PyTorch 的高性能 LLM 推理框架，核心优化点包括：
  • 连续批处理（Continuous Batching）：动态合并请求，减少空闲时间，提升吞吐量。
  • PagedAttention：显存分页管理，避免 OOM（显存溢出）。
• 适用场景：高并发、低延迟的推理服务部署。

2. FP8

• 意义：使用 8 位浮点精度（FP8）量化模型参数，相比 FP16/FP32：
  • 显存占用减少 50%~75%（1 FP8 = 0.5 FP16 或 0.25 FP32）。
  • 计算吞吐量提升（GPU FP8 单元带宽更高）。
• 注意：需 GPU 支持 FP8（如 NVIDIA H100/A100）。

二、序列长度配置

ISL/OSL：3K/50

• ISL（Input Sequence Length）：输入序列最大长度（3K = 3000 tokens）。
• OSL（Output Sequence Length）：输出序列最大长度（50 tokens）。
• 作用：
  • 控制上下文窗口大小，直接影响显存占用（序列越长，显存需求越高）。
  • 需根据业务场景调整（如客服对话需较长上下文，摘要任务较短）。

三、并行策略配置

• 飞行批处理（Flight Batching）：
  • vLLM 默认的动态批处理策略，允许在推理过程中持续合并请求，减少批处理间隙。
  • 相比静态批处理（Static Batching），更适合高并发场景。
• TP8DP2：
  • TP（Tensor Parallelism）= 8：模型切分为 8 个 GPU 张量并行子任务（需 8 卡）。
  • DP（Data Parallelism）= 2：数据并行副本数为 2（总 GPU 数 = TP × DP = 16 卡）。
  • 典型场景：模型参数量过大（如 100B+），需通过张量并行分摊计算。

为实现大规模分布式和解耦式推理服务，NVIDIA Dynamo包含四项关键技术：

1. NVIDIA Dynamo 规划器
2. NVIDIA Dynamo 智能路由
3. NVIDIA Dynamo 分布式KV缓存管理器
4. NVIDIA推理传输库（NIXL）

20250326-2214-2.png

图3. NVIDIA Dynamo架构

NVIDIA Dynamo 规划器：优化分布式推理中的GPU资源

在大规模分布式和解耦式推理系统中，高效管理GPU资源是提升吞吐量和降低延迟的关键。虽然解耦式服务能显著提高推理吞吐量和效率，但并非所有请求都适合这种方案。

设想一个场景：大量需要长输入序列长度（ISL）但短输出序列长度（OSL）的摘要请求突然涌入，导致预填充GPU过载。此时，解码GPU可能处于闲置状态，而预填充GPU成为瓶颈。此时，允许解码GPU以传统聚合方式同时执行预填充和解码任务，或调整解码GPU执行预填充任务，可能更高效。这种策略可平衡负载、缓解预填充GPU压力并提升整体吞吐量。

决定采用解耦式或聚合式服务，或分配多少GPU到各阶段，需综合考量多个因素。这些因素包括预填充与解码GPU间KV缓存传输所需时间、GPU队列等待时间，以及解耦式和聚合式配置的预估处理时间。在数百GPU的大规模环境中，这些决策会迅速变得复杂。

此时，NVIDIA Dynamo规划器发挥作用。它持续监控分布式推理环境中GPU的容量指标，并结合应用服务等级目标（SLO）如TTFT和ITL，判断是否应以分散或聚合方式处理新请求，或是否需向各阶段分配更多GPU。NVIDIA Dynamo规划器确保预填充和解码阶段的GPU资源高效分配，适应波动负载的同时保持系统峰值性能。

20250326-2214-3.png

图4. GPU规划器通过分析GPU容量指标，为处理新请求或分配GPU工作者做出最优决策

NVIDIA Dynamo 智能路由：减少KV缓存的高成本重新计算

在响应用户提示前，LLM需构建输入请求的上下文理解，即KV缓存。这一过程计算密集且随输入请求大小呈二次增长。复用KV缓存可避免从头计算，减少推理时间和计算资源消耗。这对频繁执行相同请求的场景（如系统提示、单用户多轮聊天机器人交互、代理工作流）尤为有利。为此需要高效的数据管理机制，判断何时何地可复用KV缓存。

NVIDIA Dynamo智能路由跨多节点和解耦式部署的大规模GPU集群追踪KV缓存，智能路由新请求，最大限度减少其重新计算。它通过Radix Tree哈希存储请求，实现在分布式环境中追踪KV位置。同时采用专用算法管理KV缓存的插入和淘汰，确保保留最相关数据块。

20250326-2214-4.png

图5. NVIDIA Dynamo智能路由避免KV缓存重新计算，加速模型响应并提升用户体验

2x HGX-H100节点。8x DeepSeek-R1-Distill-Llama-70B。vLLM，FP8，张量并行：2 数据来源：10万真实R1请求，平均ISL/OSL（输入/输出）：4K/800

当新推理请求到达时，NVIDIA Dynamo智能路由计算该请求与分布式集群所有GPU内存中已激活KV缓存块的重叠分数。结合重叠分数和GPU集群的工作负载分布，智能路由将请求导向最合适的工作者，最小化KV缓存重新计算并平衡集群负载。

与轮询或负载均衡路由不同，此方法通过考量缓存命中率、负载均衡和GPU容量优化整体系统性能，高效处理请求并消除资源瓶颈。通过减少不必要的KV缓存重新计算，NVIDIA Dynamo智能路由释放GPU资源，使AI服务提供商能处理更多用户请求，最大化加速计算投资回报。

NVIDIA Dynamo 分布式KV缓存管理器：将KV缓存卸载至成本效益更高的存储

构建用户请求的KV缓存资源密集且成本高昂。复用KV缓存以减少重新计算是常见做法。但随着AI需求增长，需存储在GPU内存中供复用的KV缓存量可能迅速超出预算。这对试图高效管理KV缓存复用的AI推理团队构成重大挑战。

NVIDIA Dynamo KV缓存管理器通过将较旧或访问频率较低的KV缓存块卸载到成本更低的存储（如CPU主机内存、本地存储或网络对象存储），解决了这一问题。该功能使组织能以GPU内存成本的极小部分存储PB级KV缓存数据。通过将KV缓存卸载至不同存储层级，开发者可释放宝贵GPU资源，同时保留历史KV缓存以减少推理计算成本。

20250326-2214-5.png

图6. NVIDIA Dynamo分布式KV缓存管理器将访问频率较低的KV缓存卸载至更经济的存储层级

NVIDIA Dynamo KV缓存管理器采用先进缓存策略，优先将高频访问数据保留在GPU内存，低频数据迁移至共享CPU主机内存、SSD或网络对象存储。其智能淘汰策略平衡过度缓存（引发查找延迟）与缓存不足（导致查找失败和KV缓存重新计算）的问题。

此外，该功能支持跨多GPU节点管理KV缓存，适用于分布式和解耦式推理服务，并提供分层缓存能力，在GPU、节点和集群层级制定卸载策略。

NVIDIA Dynamo KV缓存管理器与PyTorch、SGLang、TensorRT-LLM和vLLM等后端兼容，支持通过NVIDIA NVLink、NVIDIA Quantum交换机和NVIDIA Spectrum交换机扩展大规模分布式集群的KV缓存存储。

NVIDIA推理传输库（NIXL）：低延迟、硬件无关的通信

大规模分布式推理依赖张量、流水线和专家并行等模型并行技术，需跨节点和节点内低延迟、高吞吐通信，利用GPUDirect RDMA。这些系统还需在解耦式服务环境中快速传输预填充与解码GPU工作者间的KV缓存。

此外，它们需支持硬件和网络无关的加速通信库，可高效跨GPU和存储层级（如CPU内存、块、文件及对象存储）移动数据，并兼容多种网络协议。

20250326-2214-6.png

图7. NVIDIA推理传输库（NIXL）抽象了异构存储设备间的数据移动复杂性

NVIDIA推理传输库（NIXL）是高性能、低延迟的点对点通信库，提供一致的数据移动API，利用相同语义快速异步跨不同存储层级移动数据。其专为推理数据移动优化，支持非阻塞和非连续数据传输。

NIXL支持异构数据路径和多种存储类型（包括本地SSD），以及NVIDIA存储合作伙伴的网络化存储。

NIXL使NVIDIA Dynamo能通过统一API与GPUDirect存储、UCX和S3等通信库交互，无论传输通过NVLink（C2C或NVSwitch）、InfiniBand、RoCE还是以太网。结合NVIDIA Dynamo策略引擎，NIXL自动选择最佳后端连接，并抽象不同存储类型的差异。这通过通用“内存区”实现，可为HBM、DRAM、本地SSD或网络化存储（块、对象或文件存储）。

开始使用NVIDIA Dynamo

现代LLM的参数规模持续扩大，融入推理能力，并被嵌入代理AI工作流。这导致推理阶段生成更多token，需部署在分布式环境，推高成本。因此，优化推理服务策略以降低成本并支持分布式环境无缝扩展至关重要。

NVIDIA Dynamo基于其前身NVIDIA Triton的成功经验，采用模块化架构，支持分布式推理和解耦式服务，可在多节点部署中实现卓越扩展性能。

部署新生成式AI模型的开发者可立即通过GitHub仓库ai-dynamo/dynamo入手。AI推理开发者和研究人员受邀在GitHub上为NVIDIA Dynamo贡献力量。加入NVIDIA Dynamo Discord服务器——NVIDIA分布式推理框架的官方开发者和用户社区。

使用SGLang、TensorRT-LLM或vLLM作为后端的Triton用户，可将这些后端部署到NVIDIA Dynamo中，从而在大规模部署中受益于分布式和解耦式推理服务。使用其他AI后端的Triton用户可探索NVIDIA Dynamo，并通过GitHub的技术文档和教程制定迁移计划，将AI工作负载迁移到NVIDIA Dynamo。NVIDIA AI Enterprise用户将继续获得现有Triton部署的生产分支支持。NVIDIA Dynamo计划纳入NVIDIA AI Enterprise，并通过NVIDIA NIM微服务实现快速简易部署。

延伸思考

这次分享的内容就到这里了，或许以下几个问题，能够启发你更多的思考，欢迎留言，说说你的想法~

1. 平衡灵活性与性能：在资源有限的环境中，如何权衡Dynamo的动态编译灵活性与TensorRT-LLM的静态优化性能？
2. KV缓存策略优化：如何设计自适应淘汰算法，既保证高频缓存命中率，又避免低频缓存占用过多GPU内存？
3. 未来扩展性：随着模型参数规模突破万亿级，Dynamo架构如何应对通信开销与存储层级的进一步挑战？

原文标题：Introducing NVIDIA Dynamo, A Low-Latency Distributed Inference Framework for Scaling Reasoning AI Models

Mar 18, 2025 By Amr Elmeleegy[1], Harry Kim[2], David Zier[3], Kyle Kranen[4], Neelay Shah[5], Ryan Olson[6] and Omri Kahalon[7]