TensorRT 推理调试三件事：精度丢失、性能瓶颈与图结构分析-育师

TensorRT 推理调试三件事：精度丢失、性能瓶颈与图结构分析

【免费下载链接】TensorRTNVIDIA® TensorRT™ is an SDK for high-performance deep learning inference on NVIDIA GPUs. This repository contains the open source components of TensorRT.项目地址: https://gitcode.com/GitHub_Trending/tens/TensorRT

模型换成 FP16 或 INT8 之后输出开始飘、延迟忽高忽低、层融合后完全看不出网络还在跑什么——这三个问题几乎每个用 TensorRT 上线推理的同学都会撞上。TensorRT 本身不只是一个高性能推理 SDK，它的开源组件里就藏着一条完整的调试链：Polygraphy 负责精度比对与定位，trtexec 负责逐层计时，onnx-graphsurgeon 负责拆开看图。下面按"出什么问题 → 用哪把工具 → 看什么结果"的路子走一遍。

精度丢了，一条命令定位问题层

这一节解决"FP16/INT8 一开精度就掉，但不知道是哪层背锅"的难题。

TensorRT 仓库里的 tools/Polygraphy 是一套命令行调试工具，check子工具用来逐张量比较两个引擎的输出，debug子工具组（源码在 polygraphy/tools/debug）则是精度定位的主力。其中debug precision的工作方式很直白：它把网络里的层分批标记成更高精度（默认 FP32）后反复重建引擎，用二分思路不断缩小范围，最后告诉你"前 N 层跑高精度，精度就达标了"。跑起来大致是这样：

polygraphy debug precision \ --model model.onnx \ --fp16 \ --check "python compare_outputs.py"

这条命令会自动做多轮建引擎和验证，--check里放你自己写的输出比对脚本作为"裁判"。结束时它会打印一个明确结论：把最前面的几层固定成 FP32，精度即可回到可接受范围。

拿到结论后别急着收工：量化模型里 Quantize/Dequantize 节点附近的层往往是误差热点，可以顺手用debug build反复构建引擎、把产物按"合格/不合格"分目录归档，缩小到具体某一层再上高精度。

推理变慢了，用 trtexec 导出逐层耗时

这一节解决"整体变慢了，但不知道瓶颈卡在哪个算子"的问题。

仓库 samples/trtexec 里的 trtexec 不只是跑推理的壳子，它还会测量并报告每一层（也就是融合后的算子组）的执行耗时，天然就是一个性能分析器。加上 profile 导出参数（参考trtexec --help里--exportProfile一类选项），每层耗时就会落到一个 JSON 文件里，打开后一眼能看出哪层占大头。

常见结论无非两种：某层耗时异常高（可能选到了不理想的 kernel 或精度组合，回到上一节的精度/精度组合上调整），或者时间均匀分布在很多层上（那更可能是 batch、内存拷贝的问题，而不是单个算子）。如果想在引擎构建阶段就盯着进度，仓库里还有一个 samples/sampleProgressMonitor 示例，演示了用 Progress Monitor API 给构建过程挂进度条，适合封装进自己的部署脚本。

模型到底做了什么，把图拆开看

这一节解决"优化之后黑箱感太重，想逐层核对网络行为"的需求。

tools/onnx-graphsurgeon 是 TensorRT 配套的图编辑库，可以把 ONNX 网络加载成对象模型：每个节点、每条边都能遍历、查询和修改，改完再导回 ONNX。它最常被用在做转换前的"手术"——删除冗余节点、折叠常量、替换不支持的算子，也可以给关键层挂上 Identity 之类的调试节点，把中间张量"暴露"出来比对。

而 Polygraphy 的debug reduce子工具（实验特性）则更狠：它能把一个跑挂的 ONNX 模型自动压缩到"最小的失败子图"，只保留触发问题的节点，再排查就容易得多。仓库 tools/Polygraphy/examples/cli/debug 下的示例配图就直观展示了瘦身前后的对比：

这张图就是"原模型 vs 最小失败子图"的样子，节点数量肉眼可见地少了一大截——调试从全图缩小到几十个节点，效率完全不同。

动手前先做好环境

工具版本不齐是调试路上最常见的坑：Polygraphy、onnx-graphsurgeon 和 TensorRT 运行时最好来自同一发布版本。仓库 docker/ 目录里提供了 ubuntu、rockylinux 等多平台 Dockerfile，用官方镜像起环境最省心；命令行装好后跑一下polygraphy --help确认工具链可用。

另外一个容易忽视的点：debug precision、debug build这类工具内部会反复重建引擎，单轮不慢，跑一轮完整定位可能要不少时间。把每轮的引擎文件和输出张量按目录归档好（工具本身就会分 good/bad 归档），出问题时可以回溯到具体某一步，而不是从头再来。