为什么需要跨多 GPU 部署模型
随着生成式 AI 模型参数规模与上下文长度的增长，单卡显存与算力越来越难以容纳一整个模型实例。当一个模型在单卡上放不下、或者单卡的吞吐不足以满足线上请求量时，团队就必须考虑把推理任务分布到多块 GPU 上。这种“多设备推理”并不是简单地把模型切成两半运行——它需要解决跨卡通信、张量切分、调度与同步等问题，否则推理延迟和吞吐都会得不偿失。
TensorRT 多设备推理解决的是什么
TensorRT 多设备推理是 TensorRT 11.0 起正式支持的一项能力，它让同一个 TensorRT 网络可以跨多块 GPU 执行，底层借助 NCCL 的分布式集合通信来完成跨设备数据交互。更重要的是，它并不是“另起一套”推理引擎，而是保留了 TensorRT 原本的推理优化路径，例如算子融合、量化、内核选择等能力。这意味着团队既可以享受 TensorRT 的优化成果，又能把单卡放不下的网络扩展到多卡，而不必切换到一套完全不同的推理栈。
适用场景与不适合的场景
从工程经验看，这项能力最直接的价值集中在几类场景：
- 单卡显存装不下整个模型或 KV cache，必须拆分到多卡；
- 单卡吞吐已接近瓶颈，需要横向扩展以支撑并发请求；
- 团队已经在使用 TensorRT，希望继续沿用同一套优化与部署链路；
- 对延迟敏感，希望用多卡并行来压低单请求响应时间。
反过来，对于本身就放得下、吞吐压力也不大的中小模型，单卡 + 单实例部署往往更简单也更便宜，把模型拆到多卡反而会引入额外的通信开销与工程复杂度，没有必要为多设备能力额外付费。
选型时需要关注的几个标准
是否引入 TensorRT 多设备推理，不能只看模型参数大小，还要综合几个维度评估：
- 显存瓶颈的来源：是权重放不下，还是推理过程中 KV cache 或激活值超限？不同瓶颈对应的拆分策略与通信模式不同。
- GPU 之间的互联：多设备推理依赖 NCCL 通信，NVLink、PCIe、跨节点网络的带宽和延迟差异巨大，直接影响推理时延。
- 延迟与吞吐目标：多卡并行会带来同步开销，只有当扩展带来的吞吐增益明显大于通信成本时才是正向收益。
- 现有技术栈：如果团队已经在用 Dynamo-Triton 做模型服务，那么基于 TensorRT 多设备推理扩展多 GPU 是较为顺滑的路径，迁移成本较低。
成本与落地建议
多 GPU 部署不只是软件改造，还牵涉到硬件、运维和能耗成本。建议在落地前做几件事：
- 先做单卡基线测量，记录显存占用、p50/p99 延迟与吞吐，作为多卡方案对比的基准；
- 用真实业务流量压测多卡方案，关注高并发下延迟是否反而恶化；
- 评估互联拓扑，优先选择 NVLink 域内的多卡组合，跨节点扩展要预留足够的网络预算；
- 将多设备能力纳入统一的推理服务层，例如 Dynamo-Triton，避免每个业务线重复实现调度与副本管理；
- 关注监控与故障域，单卡故障不应拖垮整个推理集群。
如何用起来
TensorRT 11.0 起，TensorRT 多设备推理已获得正式支持。团队可以先升级到 TensorRT 11.0 及以上版本，确认现有模型能正常构建为 TensorRT 引擎，再开启多设备执行配置。对于模型服务层，Dynamo-Triton 与 TensorRT 多设备推理进行了集成，可以在同一个服务框架下使用多 GPU 推理能力，无需为多卡场景单独搭一套服务。具体接入步骤通常包括：安装或升级到支持多设备的 TensorRT 与 Dynamo-Triton 版本；按 TensorRT 的多设备要求配置网络结构与跨卡通信参数；在 Dynamo-Triton 中按多 GPU 后端的要求完成模型仓库配置与实例部署；用代表性请求做端到端的延迟与吞吐验证，再逐步扩大到生产流量。建议先在小规模集群上验证通信开销和扩展效率，再决定是否推广到更大规模。
结论
当生成式 AI 模型的需求超过单卡能力时，多设备推理是从“能跑”走向“跑得起”的关键环节。TensorRT 11.0 起提供的多设备推理能力，结合 Dynamo-Triton 的模型服务框架，为已经在 TensorRT 技术栈上的团队提供了一条相对平滑的多 GPU 扩展路径。选型时应当回到业务本身：先确认是否存在真实的显存或吞吐瓶颈，再判断多卡并行的收益能否覆盖通信与运维成本，最后用真实流量验证扩展效率。