TensorRT 生产落地案例

TensorRT 生产落地案例

案例一：在线 OCR 服务从 PyTorch 迁到 TensorRT。背景是检测与识别两个模型直接用 PyTorch 推理，长尾延迟高、显存占用大，单卡并发上不去。做法是先把两个模型分别导出 ONNX，用 onnxruntime 跑一遍数值对齐，确认导出没走样；再用 trtexec 编译 FP16 engine，服务侧用 Python 加载 engine，配合多 context 与多 stream 做批内并发；输入统一 pad 到固定尺寸，直接走静态 shape，省掉 profile 带来的复杂度。关键配置是：编译时 workspace 给足，engine 序列化后随镜像分发，每张卡只保留一份反序列化结果并复用多个 context。效果上，延迟与显存占用都有明显下降、单卡吞吐上升，具体幅度随模型与硬件差异较大，以自己压测为准。踩的坑有三个：一是某算子转 ONNX 时被拆成一串小算子，反而比原版慢，改用 plugin 合并后恢复；二是最初每个请求新建 context，显存碎片严重、尾延迟抖动，改成 context 池后稳定；三是升级驱动之后忘了重编 engine，反序列化直接失败，后来把 engine 编译放进 CI，按 GPU 架构分别产出产物。

案例二：边缘设备上的 INT8 部署。背景是 Jetson 类设备功耗受限，FP16 也吃不消。做法是先拿 FP16 打通整条链路，确认正确性之后再开 INT8，并用线上真实采样数据做校准，逐层对比输出，发现掉点的层就单独回退到 FP16。踩的坑是：校准集分布与线上差异大时，精度掉得比预期严重，后来改成从线上采样；另外部分子图在 INT8 下不被支持，运行时会静默回退到更高精度，必须打开 verbose 日志确认实际的精度路径，否则你以为在跑 INT8，其实还有一大段在跑 FP32。