生成式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计划中。Dynamo-Triton的TensorRT后端加载带版本号的计划，创建多rank执行状态，并对外暴露一个gRPC模型端点。客户端向该端点发送Transformer请求，而不需要协调参与运算的GPU rank。
Cosmos 3 Nano模型提供了这一边界的实际案例。Transformer部分占单GPU生成总耗时的93.4%，是最值得优化加速的环节。35个去噪步骤中的每一步都需要一次负向（无条件）预测和一次基于提示词的条件预测，用于实现CFG。因此，Diffusers代理每一步会依次发出两次Triton调用，每次生成共产生70次Transformer RPC调用。每个请求携带准备好的张量，并将noise_patches返回给应用工作流。
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都能针对不重叠的头部子集处理完整的视频序列。
该引擎从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编码时间。
对比SD（单设备）、CP2、CP4和CP8四种Cosmos 3运行方案的测试结果显示：端到端延迟从单GPU的156.595秒降至八GPU的34.183秒，Transformer RPC加速比达到6.09倍。
在单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分贝。
需要说明的是，这些输出并非像素级完全一致。CP2和CP4测得的MAE为12.759，PSNR为21.111分贝；CP8测得的MAE为16.316，PSNR为19.400分贝。对比图同样显示，整段视频中呈现的动作是一致连贯的：一个机械臂在清洁盘子。
开始简化多GPU模型服务
对产品团队而言，当响应速度比控制单次请求占用的GPU数量更具业务价值时，这些结果展示了一个实用的选择方案。此前需要两分半钟以上才能完成的完整Cosmos 3生成任务，现在大约34秒即可完成，同时应用程序仍可继续使用常规的模型服务接口。
不过，团队仍需根据资源与延迟之间的权衡关系来决定最佳方案。本次基准测试并未衡量并发请求的吞吐量、每段生成视频的成本，或整体拥有成本（TCO）。各团队应结合自身的服务水平目标（SLO）和部署经济性，对这些指标进行评估。
如果想在自己的环境中重现本文展示的结果，可以从NGC下载NVIDIA Dynamo-Triton 26.07版本，然后参考TensorRT、Torch-TensorRT、Diffusers和Cosmos的相关资源文档。
如需了解更多信息，请查阅以下相关资源：
Dynamo-Triton TensorRT后端多设备指南
TensorRT多设备文档
Dynamo-Triton模型仓库文档
Q&A
Q1：NVIDIA TensorRT多设备推理是什么？
A：这是一项让单个TensorRT网络借助NCCL支持的分布式集合操作，在多个GPU上运行的新能力，同时能保留TensorRT本身的推理优化特性，从TensorRT 11.0版本开始得到完整支持。
Q2：使用TensorRT多设备推理后，Cosmos 3的生成速度能提升多少？
A：根据测试结果，端到端生成延迟从单GPU的156.595秒降至八GPU的34.183秒，Transformer RPC部分的加速比达到6.09倍，原本需要两分半钟以上的生成任务缩短到约34秒完成。
Q3：多GPU生成的视频质量会不会因为并行处理而下降？
A：验证结果显示不会明显下降。CP2、CP4和CP8三种配置均通过了设定的图像质量阈值，虽然输出结果并非像素级完全一致，但整段视频呈现的动作依然连贯一致。
