1. 初识trtexec：你的TensorRT性能优化瑞士军刀
第一次接触trtexec时，我正为一个图像识别项目焦头烂额。当时训练好的ONNX模型在测试服务器上跑得比蜗牛还慢，直到同事扔给我一行命令："试试这个黑魔法工具"。这个命令行工具就像TensorRT生态里的多功能军刀，不仅能完成模型格式转换，还能进行细致的性能剖析和调优。
trtexec是NVIDIA TensorRT工具包中的命令行工具，专门用于：
- 将主流框架模型（ONNX/Caffe/UFF）转换为TensorRT引擎
- 快速验证模型在目标硬件上的推理性能
- 通过参数微调挖掘GPU的每一分算力
与TensorRT的Python API相比，trtexec最大的优势在于无需编写代码就能完成完整的工作流。比如你想测试ONNX模型在T4显卡上的INT8量化效果，只需要：
trtexec --onnx=model.onnx --int8 --best2. 模型转换实战：从ONNX到TensorRT引擎
2.1 静态batch转换：基础操作
最常见的场景是把训练好的ONNX模型转为TensorRT引擎。假设我们有个图像分类模型mnist.onnx，基础转换命令如下：
trtexec --onnx=mnist.onnx --saveEngine=mnist.trt但这样生成的引擎可能不是最优解。我建议新手加上这三个黄金参数：
trtexec --onnx=mnist.onnx \ --explicitBatch \ --workspace=2048 \ --best \ --saveEngine=mnist_optimized.trt--explicitBatch：显式声明batch维度，避免后续shape调整的坑--workspace：设置临时内存空间（单位MB），复杂模型需要更大空间--best：自动尝试所有精度组合（FP32/FP16/INT8）寻找最优解
2.2 动态shape处理：真实场景必备
实际部署中，输入尺寸往往不固定。比如视频分析场景，可能同时处理480p和1080p的帧。这时就需要动态shape支持：
trtexec --onnx=yolov5s.onnx \ --minShapes=images:1x3x320x320 \ --optShapes=images:8x3x640x640 \ --maxShapes=images:16x3x1280x1280 \ --saveEngine=yolov5s_dynamic.trt这里有个容易踩的坑：三个shape参数必须同时设置，且格式要严格遵循维度名称:尺寸的格式。我曾经因为漏写optShapes导致引擎性能下降50%。
3. 性能基准测试：找出系统瓶颈
3.1 基础性能指标获取
转换完引擎后，第一件事就是跑基准测试：
trtexec --loadEngine=model.trt \ --iterations=100 \ --duration=10 \ --exportTimes=perf.json这会输出几个关键指标：
- Latency：单次推理耗时（ms）
- Throughput：每秒处理的样本数（samples/s）
- GPU Utilization：显存和计算单元占用率
在我的RTX 3090上测试ResNet50时，发现FP16模式比FP32快2.3倍，而INT8又能比FP16快1.8倍——这就是--best参数的威力。
3.2 多流并发优化
当单流无法吃满GPU时，可以尝试多流并发。比如处理视频流时：
# 生成不同batch的引擎 trtexec --onnx=model.onnx --saveEngine=bs1.trt --buildOnly --batch=1 trtexec --onnx=model.onnx --saveEngine=bs4.trt --buildOnly --batch=4 # 测试不同流组合 trtexec --loadEngine=bs1.trt --streams=4 trtexec --loadEngine=bs4.trt --streams=2有个经验公式：最佳流数 ≈ GPU SM数量 × 2。比如A100有108个SM，可以尝试216个流。但要注意，流数过多反而会因为调度开销降低性能。
4. 高级调优技巧：榨干GPU性能
4.1 精度与速度的平衡
TensorRT支持混合精度计算，通过--fp16和--int8控制。但INT8需要校准数据：
trtexec --onnx=model.onnx \ --int8 \ --calib=/path/to/calibration/data \ --saveEngine=model_int8.trt实测发现，不是所有模型都适合INT8。像BERT这类NLP模型，INT8可能导致精度暴跌。我的调优策略是：
- 先用
--best自动尝试所有精度 - 对最优结果进行人工验证
- 必要时使用
--layerPrecisions逐层指定精度
4.2 显存优化技巧
大模型常遇到显存不足的问题，这几个参数能救命：
trtexec --onnx=large_model.onnx \ --workspace=4096 \ --minTiming=10 \ --avgTiming=100 \ --saveEngine=optimized.trt--workspace：增大临时内存（单位MB）--minTiming/avgTiming：减少kernel搜索次数--noTF32：禁用TF32加速（某些显卡需要）
曾经处理过一个3D分割模型，默认参数总是OOM。把workspace从1024调到8192后，不仅转换成功，推理速度还提升了20%。
5. 实战问题排查指南
5.1 常见错误与解决方案
问题1：转换时报错"Unsupported ONNX opset version"
- 解决方案：用
--onnxOpSet=11指定opset版本
问题2：动态shape模型推理时shape不匹配
- 解决方案：运行时必须用
--shapes指定具体shape：trtexec --loadEngine=dynamic.trt --shapes=input:1x3x256x256
问题3：INT8精度损失严重
- 解决方案：增加校准数据量，或使用
--calibCache复用校准缓存
5.2 调试信息获取
当遇到诡异问题时，这些调试选项很有用：
trtexec --onnx=problem_model.onnx \ --verbose \ --exportProfile=profile.json \ --exportLayerInfo=layers.json--verbose：打印详细日志--exportProfile：输出各层耗时--exportLayerInfo：保存层结构信息
有次遇到模型转换成功但推理结果全错的情况，通过分析layer信息发现是某个自定义插件未正确加载。
6. 生产环境部署建议
6.1 引擎兼容性处理
不同GPU架构生成的引擎不能混用。我习惯用这样的命名规则：
model_<arch>_<precision>.trt例如：
- Ampere架构FP16引擎：
resnet50_a100_fp16.trt - Turing架构INT8引擎：
yolov4_t4_int8.trt
6.2 性能监控方案
长期运行的推理服务需要监控：
trtexec --loadEngine=service.trt \ --iterations=0 \ --duration=0 \ --spin \ --exportTimes=monitor.csv--spin：持续运行不退出--exportTimes：定期保存性能数据
配合Prometheus+Grafana，可以打造完整的性能监控看板。