生成式 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 流和 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 返回给应用程序工作流。
图 1. Dynamo-Triton（原 Triton Inference Server）现已在底层运行 TensorRT 多设备推理——仅需一次模型端点调用### Dynamo-Triton 如何激活上下文并行分布式 TensorRT 计划？
分布式图被编译进每个上下文并行 TensorRT 计划中。Dynamo-Triton 配置激活该计划；它不会将单设备引擎转换为分布式引擎。单设备基线在 GPU 0 上使用标准 GPU 模型实例。双 GPU、四 GPU 和八 GPU 变体使用 KIND_MODEL
，启用 TensorRT 后端多设备路径，并标识参与的 rank。
# 生成的 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 针对不重叠的 head 子集处理完整的视频序列。
*图 2.*Ulysses 通过围绕标准注意力的 TensorRT 分布式集合通信层实现。它不使用单独的多设备注意力算子。该引擎从 PyTorch 导出，并使用 Torch-TensorRT 编译。三个本地转换器将导出载体操作下沉到 TensorRT 公共分布式集合通信层：reduce-scatter、all-to-all 和 all-gather。每个被接受的上下文并行方案包含两个初始 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% |
表 1. SD、CP2、CP4 和 CP8 Cosmos 3 运行的比较
图 3. 不同 GPU 配置下的端到端和 Triton transformer RPC 延迟
图 4. 加速比与理想线性扩展的对比在单 GPU 上，transformer RPC 占生成时间的 93.4%。在 CP8 时，该占比降至 70.2%。在各类配置中，测量 RPC 路径之外的时间保持在 10.2 到 10.5 秒之间，因此提示词处理、调度器更新、VAE 解码、后处理以及其他客户端开销在总时间中占据更大比例。
图 5. 各 GPU 配置下的端到端延迟分解## 在宣称性能之前验证生成输出
每个变体都使用相同的种子和生成配置。验证过程对第 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。联系表也显示整个片段中动作连贯一致：一只机械臂在清洗盘子。
图 6. SD、CP2、CP4 和 CP8 之间相同种子的视觉验证
图 7. 八 GPU Cosmos 3 输出## 开始简化多 GPU 模型服务
对于产品团队而言，当响应时间比尽量减少分配给单个请求的 GPU 数量具有更高商业价值时，这些结果展示了一种实用选择。此前需要超过两分半钟的完整 Cosmos 3 生成现在约 34 秒即可完成，同时应用程序仍继续使用常规的模型服务接口。
团队仍必须根据资源与延迟之间的权衡来决定最佳方案。该基准测试并未测量并发请求吞吐量、每个生成视频的成本或总拥有成本（TCO）。团队应结合自身的 SLO 和部署经济性来评估这些指标。
要在您自己的环境中复现本文介绍的结果，请从 NGC 下载 NVIDIA Dynamo-Triton 26.07。然后使用所链接的 TensorRT、Torch-TensorRT、Diffusers 和 Cosmos 资源。
要了解更多信息，请查看以下相关资源：