使用 NVIDIA Dynamo-Triton 中的 NVIDIA TensorRT（NVIDIA 深度学习推理优化库） 多设备集成简化跨多个 GPU（图形处理器） 的模型服务 | NVIDIA 技术
生成式 AI 的计算和内存需求日益超出单个 GPU 所能提供的范围。NVIDIA TensorRT 多设备推理是一项新功能，它使单个 TensorRT 网络能够使用 NCCL 支持的分布式集合通信在多个 GPU 上执行，同时保留 TensorRT 推理优化。从 TensorRT 11.0 开始全面支持该功能。
NVIDIA Dynamo-Triton（原 NVIDIA Triton Inference Server）26.07 版本启用了 TensorRT 后端的多设备推理能力。一个 Triton KIND_MODEL 实例可以拥有多个 GPU，创建按 rank 划分的 TensorRT 执行上下文、CUDA（NVIDIA 并行计算平台和编程模型） 流和 NCCL 通信器，并为每个请求一起启动各 rank。应用程序通过 gRPC 端点调用一个命名模型，而无需自行协调 GPU rank。
对于部署生成式 AI 的组织而言，这弥合了多 GPU 加速与可消费推理服务之间的差距。团队可以用额外的 GPU 资源换取更短的请求延迟，保持应用程序接口和周边工作流稳定，将引擎打包为带版本的 Triton 模型，并将 rank 和通信器生命周期代码从客户端中移除。对于延迟敏感的生成式媒体工作流，更短的结果返回时间可以减少用户等待时间，并加速审查与改进循环。
本文使用 NVIDIA Cosmos 3 Nano 视频生成来演示这一集成，这是一个长序列工作负载，曾在上一篇文章《使用 NVIDIA TensorRT 多设备推理支持跨多个 GPU 扩展 AI 推理》中介绍过。Diffusers 继续负责编排提示词、潜变量、无分类器引导（CFG）、调度、VAE 解码和帧后处理。Dynamo-Triton 服务于 36 层去噪 Transformer（深度学习中的注意力模型架构），TensorRT 多设备推理使用 Ulysses 上下文并行将其 44,160 个视频 token 分布到多达八个 NVIDIA GPU 上。
Dynamo-Triton 如何服务 TensorRT 多设备模型？
分布式 Ulysses 图在部署前被编译到每个 TensorRT plan 中。Dynamo-Triton TensorRT 后端加载带版本的 plan，创建多 rank 执行状态，并暴露一个 gRPC 模型端点。客户端向该端点发送 Transformer 请求；它不协调参与的 GPU rank。
Cosmos 3 Nano 模型为这一边界提供了一个实际示例。Transformer 占单 GPU 生成时间的 93.4%，使其成为加速影响最大的阶段。35 个去噪步骤中的每一步都需要一次负向或无条件预测以及一次用于 CFG 的提示词条件预测。因此，Diffusers 代理在每一步进行两次顺序 Triton 调用，每次生成共 70 次 Transformer RPC。每个请求携带准备好的张量，并将 noise_patches 返回到应用程序工作流。
Dynamo-Triton 如何激活上下文并行分布式 TensorRT plan？
分布式图被编译到每个上下文并行 TensorRT plan 中。Dynamo-Triton 配置激活该 plan；它不会将单设备引擎转换为分布式引擎。单设备基线在 GPU 0 上使用标准 GPU 模型实例。双 GPU、四 GPU 和八 GPU 变体使用 KIND_MODEL，启用 TensorRT 后端多设备路径，并标识参与的 rank。
# Excerpt from the generated CP8 config.pbtxt
name: "cosmos3_cp8"
backend: "tensorrt"
max_batch_size: 0
instance_group [
{ kind: KIND_MODEL count: 1 }
]
parameters [
{ key: "enable_multi_device" value: { string_value: "true" } },
{ key: "multi_device_gpus" value: { string_value: "0,1,2,3,4,5,6,7" } }
]使用 Ulysses 上下文并行分布 Cosmos 3
本示例中固定的 Cosmos 3 Nano 配置生成 44,160 个视频 token。在上下文并行大小为八（CP8）时，每个 rank 在注意力之外处理 5,520 个视频 token。较短的 2,992 token 文本路径保持复制。在 36 个 Transformer 层中的每一层内，Ulysses 围绕注意力改变分区轴，使每个 rank 为非重叠的注意力头子集处理完整的视频序列。
该引擎从 PyTorch 导出，并使用 Torch-TensorRT 编译。三个本地转换器将导出载体操作降低到 TensorRT 公共分布式集合通信层：reduce-scatter、all-to-all 和 all-gather。每个被接受的上下文并行 plan 包含两个初始 reduce-scatter、36 个 Transformer 层中每层三个 all-to-all，以及一个最终 all-gather。由此产生的拓扑为两个 reduce-scatter 加 108 个 all-to-all 加一个 all-gather。
端到端生成延迟基准测试
所有四种变体均运行在同一个健康的八 GPU NVIDIA 系统上。单设备基线使用一个 GPU；CP2、CP4 和 CP8 分别使用两个、四个和八个 rank。每次运行均使用 1280×720 输出、24 FPS 下的 189 帧以及 35 个去噪步骤。
每个结果包含一次预热，随后是五次测量的完整生成。计时涵盖提示词处理、70 次 Dynamo-Triton 调用、CFG 和调度器更新、VAE 解码以及帧后处理。请注意，模型加载和 mp4 编码未包含在内。
表 1 比较了 SD、CP2、CP4 和 CP8 Cosmos 3 运行结果。端到端延迟从单 GPU 上的 156.595 秒降至八 GPU 上的 34.183 秒，而 transformer RPC 加速比提升至 6.09 倍。
| 变体 | GPU 数量 | E2E 均值 | E2E 加速比 | RPC 均值 | RPC 加速比 | RPC 占比 | | --- | --- | --- | --- | --- | --- | --- | | SD | 1 | 156.595 | 1.00x | 146.192 | 1.00x | 93.4% | | CP2 | 2 | 87.999 | 1.78x | 77.548 | 1.89x | 88.1% | | CP4 | 4 | 53.093 | 2.95x | 42.661 | 3.43x | 80.4% | | CP8 | 8 | 34.183 | 4.58x | 23.993 | 6.09x | 70.2% |
在单 GPU 上，transformer RPC 占生成时间的 93.4%。在 CP8 下，该占比降至 70.2%。在各类配置中，测量 RPC 路径之外的时间保持在 10.2 至 10.5 秒之间，因此提示词处理、调度器更新、VAE 解码、后处理以及其他客户端开销在总时间中所占比例变得更大。
在宣称性能提升之前验证生成输出
每个变体均使用相同的种子和生成配置。验证采样了第 0、47、94、141 和 188 帧，检查了格式和时间变化，并将每个上下文并行输出与单设备结果进行比较。CP2、CP4 和 CP8 均通过了平均绝对误差（MAE）≤ 25 和峰值信噪比（PSNR）≥ 18 dB 的配置阈值。
这些输出并不声称像素级完全一致。CP2 和 CP4 测得 MAE 为 12.759，PSNR 为 21.111 dB。CP8 测得 MAE 为 16.316，PSNR 为 19.400 dB。联系表也显示整个片段中相同的连贯动作：一个机械臂在清洗盘子。
开始简化多 GPU 模型服务
对于产品团队而言，当响应时间比最小化单个请求所分配的 GPU 数量具有更大商业价值时，这些结果展示了一个实用选项。此前需要超过两分半钟的完整 Cosmos 3 生成现在约 34 秒即可完成，同时应用程序继续使用常规的模型服务接口。
团队仍需根据资源与延迟的权衡来决定最佳方案。该基准测试未测量并发请求吞吐量、每个生成视频的成本或总拥有成本（TCO）。团队应结合自身的 SLO 和部署经济性来评估这些指标。
要在您自己的环境中复现本文展示的结果，请从 NGC 下载 NVIDIA Dynamo-Triton 26.07。然后使用链接的 TensorRT、Torch-TensorRT、Diffusers 和 Cosmos 资源。
要了解更多信息，请查看以下相关资源：
- Dynamo-Triton TensorRT 后端多设备指南
- TensorRT 多设备文档
- Dynamo-Triton 模型仓库文档
转载声明：本文为转载整理，原文版权归原作者及原站点所有。
原文作者：Tanya Lenz；如有侵权，请联系管理员删除。
