TensorRT Support Matrix 的结论只能回答“该软硬件组合是否处于支持范围”，不能直接回答“目标模型引擎已经在生产条件下验证可用”。采购时，矩阵应作为第一道准入门槛；真正决定能否部署的，是目标 GPU、操作系统、驱动、CUDA、TensorRT 版本、模型图、精度策略和运行负载共同构成的验证结果。
先区分支持范围与交付承诺
支持矩阵通常按 TensorRT 发布版本列出可配套的 GPU 架构、操作系统、CUDA 及相关组件。它的价值是排除明显不匹配的组合，例如计划使用的系统或 CUDA 不在该版本覆盖范围内。但“支持某类 GPU 架构”并不等同于某个 ONNX 模型、某种批量策略或某项业务精度要求已经得到验证。采购文件不宜把矩阵条目写成端到端业务验收结论，而应把它写成环境准入依据。
GPU 架构要落到实际部署节点
采购方应确认的是实际可交付节点上的 GPU 架构，而不是仅确认产品系列名称。还要记录计划启用的 GPU 数量、主机操作系统、虚拟化或容器边界，以及驱动和 CUDA 的版本关系。不同节点若混用架构，不能假定同一份序列化引擎可无差别复用；应按官方文档、目标 TensorRT 版本和现场运行环境分别复核。TensorRT 的功能与版本说明可在 TensorRT Developer Documentation 中核对，采购评审应以拟锁定版本的页面内容为准。
操作系统和 CUDA 是组合条件
矩阵中的操作系统与 CUDA 条目不是可任意拼接的标签。部署镜像需要同时满足宿主机驱动、容器运行时、CUDA 用户态库和 TensorRT 包的要求。升级 CUDA、替换基础镜像或调整驱动后，即使 GPU 未变，也应重新检查对应版本的支持关系。对于离线、受控网络或长期维护环境，建议在采购阶段冻结候选版本组合，并保留安装包来源、镜像摘要、驱动版本和构建命令，避免验收后因仓库更新而无法复现。
引擎构建与引擎运行应分开验收
TensorRT 会把模型转换为面向目标环境的推理引擎。工程上应区分“可以构建引擎”“可以加载引擎”和“持续稳定地执行目标请求”三个层级。先在目标 GPU 与目标软件栈上构建，再在同类运行节点加载并执行；不要只用开发机的构建成功替代生产验证。官方快速入门中的安装、模型转换和运行流程可参考 TensorRT Quick Start Guide，但其示例流程不能替代针对业务模型的验收。
动态 shape 是矩阵外的常见失效点
动态输入尺寸或动态 batch 往往要求明确优化配置文件及其最小、最优和最大形状。矩阵显示支持目标 GPU 时，模型仍可能因请求形状超出配置、某些算子组合不适配或内存需求不可接受而失败。验证集必须覆盖线上真实的形状分布、边界尺寸、并发和冷启动场景。验收指标至少应包括引擎构建是否成功、所有目标 shape 的加载与执行结果、输出与基线的误差边界、错误日志、峰值显存观察及持续运行的稳定性；阈值应由业务方预先定义。
插件与模型精度不能由矩阵背书
使用自定义插件时，插件二进制、接口版本、依赖库和目标环境必须一起验证。插件能够编译或被加载，不表示其数值语义与性能行为符合预期。FP32、FP16、INT8 等精度路径也应分别测试：量化校准数据、算子回退、输入预处理和后处理都会改变最终结果。一个反例是，基础 GPU 与 CUDA 组合位于矩阵范围内，但模型包含未覆盖的插件或 INT8 校准不满足业务误差要求，此时该组合仍不适合按目标精度上线。
把采购条款改写为可执行的验证门
- 锁定候选 GPU 架构、操作系统、驱动、CUDA、TensorRT 和容器镜像版本，并逐项对照官方当前文档。
- 以真实模型、真实预处理和代表性输入构建引擎，保留构建日志、配置文件及失败信息。
- 在计划运行节点执行功能、精度、形状覆盖、显存和稳定性测试，并将验收阈值写入交付条件。
- 发生构建失败、精度超限或运行不稳时，优先回退到已验证的软件组合或基线推理路径；必要时改用已验证精度、固定 shape 配置，或暂停该目标节点部署。
把矩阵用于决策，而不是替代测试
矩阵适合回答候选方案是否值得进入验证，不能单独证明目标引擎可交付。采购评审应要求供应方或实施方提供版本对应关系、可复现构建记录和目标环境测试证据。涉及特定硬件、地区可得性或后续版本变更时，仍须按官方文档与现场环境复核，不应依据历史截图或泛化承诺作决定。
WeChat
Profile