尧图网页设计 
简介面向算法部署工程师与目标检测研究者这份TensorRT实战项目系统展示了GroundingDINO开集目标检测从模型训练到NVIDIA GPU高效推理的完整部署链路。项目针对真实部署中的性能瓶颈重点讲解TensorRT模型优化、精度保持与硬件兼容性处理可适配安全监控、自动驾驶、医学影像等对未见过类别有识别需求的场景。压缩包共122个文件大小13.91MB其中53个Python脚本与31个Pyc编译文件构成主程序逻辑配套onnx模型和可运行engine权重便于直接验证cu/cpp源码对应自定义的ms_deform_attn等算子xml、txt文档用于配置与流程说明。目前已有187人学习浏览。除详尽流程教程与全部源码外资源还包含训练好的pth权重、ipynb示例笔记并针对模型转换、推理提速、结果分析等环节给出可复现步骤与排错思路开发者可按图索骥迁移到自有项目。1. 从 PyTorch 到 TensorRTGroundingDINO 部署的真正难处在哪目标检测进入开集时代之后GroundingDINO 几乎成了「文本指哪打哪」的标配算法但很多人 PyTorch 里玩得转一到 TensorRT 部署就翻车。原因很直接它不是单分支检测器而是文本编码器、视觉 backbone、跨模态解码器三个模块拼在一起的直接导出的 ONNX 在 TensorRT 里经常跑不动或者跑起来精度对不上。这篇文章就是把「PT 权重转 ONNX、ONNX 转 TensorRT engine、Python 侧推理封装」这条链路上的每个参数和坑位讲清楚适合手里已有 GroundingDINO 权重、正打算做服务化或边缘端部署的算法工程师。照着一章章走半天内能拿到一个能跑的 engine。2. 环境对齐与 ONNX 导出先让模型结构适合 TensorRT2.1 版本组合怎么选TensorRT、CUDA、GPU 的匹配逻辑部署 TensorRT 的第一步不是写代码而是把版本组合先定死。常见做法是 Python 3.10 CUDA 11.8 TensorRT 8.6 以上这一档PyTorch 用 2.0 左右就够导出用了。要注意nvidia-smi里看到的 CUDA 版本只是驱动支持的上限真正决定 TensorRT 能不能用的是你装的那个 CUDA toolkit 版本这个两个概念经常被混在一起报错的时候特别容易绕晕。另外很多人问 TensorRT 10.x 能不能支持 GTX 1070 这类老卡。装是能装但 GTX 1070 是 Pascal 架构fp16 的加速能力很弱转成 fp16 engine 之后延迟不一定比 fp32 低多少。我一般遇到这种卡就直接用 fp32 构建省得折腾半天精度还掉点。这是选择精度档前必须先想清楚的一件事。组件推荐组合说明Python3.103.8 也能跑但个别算子导出有坑PyTorch2.0 左右仅用于导出模型推理时不依赖它CUDA11.8与 TensorRT 配套不是看 nvidia-smiTensorRT8.6 及以上对动态 shape 和 ONNX opset 17 支持好onnx / onnxruntime各自最新稳定版一个做简化一个做导出后验证2.2 导出前的模型瘦身固定文本输入与 forward 替换GroundingDINO 官方推理接口是传字符串 captions模型内部再用 BERT tokenizer 把文本转成 input_ids、attention_mask 这些张量。这个设计在 PyTorch 里很顺手但到了导出 ONNX 就成了灾难——tokenizer 是纯 Python 逻辑没法被 torch.onnx.export 跟踪。最常见的做法是绕过 tokenizer写一个导出专用的 wrapper直接接收 token 张量。文本长度也要先定死。GroundingDINO 的文本分支可以处理变长 prompt但 TensorRT 对动态 shape 支持有限变长 token 意味着每次推理都要重新分配显存工程上非常不划算。业界常规做法是统一 pad 到固定长度比如 256。句子不够就补[PAD]超过 256 就先截断attention_mask 对应位置置 0告诉模型这些位置不用管。这个长度一旦定下来整个 engine 的输入输出形状就全定了。import torch.nn as nn class GroundingDINOExportWrapper(nn.Module): def __init__(self, model, max_text_len256): super().__init__() self.model model self.max_text_len max_text_len def forward(self, images, input_ids, attention_mask, token_type_idsNone, position_idsNone): # 直接传张量跳过 tokenizer 和预处理 return self.model( images, input_ids, attention_mask, token_type_ids, position_ids )这个 wrapper 的关键点在于绕过了captions字符串入口把所有文本相关的动态逻辑挡在模型外。具体输入名以你导出的 ONNX 为准不同版本的 GroundingDINO 输入顺序略有差异导出前用onnx.load打印一遍输入名最保险。我用这个方式导出过几个权重版本文本分支的输入基本上就是上面这几个张量个别版本没有 position_ids删掉对应行就行。2.3 导出与简化验证脚本导出时有三件事容易翻车模型忘记切 eval 模式、没有包 torch.no_grad、opset 版本太低。前两个会导致 ONNX 里混入 BatchNorm 的统计更新逻辑推理结果对不上。opset 方面SwinT 里有 roll 这类算子opset 11 导出会报错或者变成一堆难以优化的子图我一般直接用 17。import torch torch.onnx.export( wrapper, (images, input_ids, attention_mask, token_type_ids, position_ids), groundingdino.onnx, opset_version17, do_constant_foldingTrue, input_names[images, input_ids, attention_mask, token_type_ids, position_ids], output_names[logits, boxes], dynamic_axes{ images: {0: batch, 2: height, 3: width}, input_ids: {0: batch}, attention_mask: {0: batch}, token_type_ids: {0: batch}, position_ids: {0: batch}, }, )这里只把图像的宽高和 batch 设成动态文本的 token 长度保持静态 256这样 TensorRT 构建时的 shape 组合少很多。接下来做简化GroundingDINO 导出的 ONNX 里会产生大量冗余的 Gather、Reshape、Cast不简化的话 TensorRT 解析时容易报 unsupported node。import onnx from onnxsim import simplify onnx_model onnx.load(groundingdino.onnx) model_simp, check simplify(onnx_model) assert check, onnxsim 简化失败检查算子支持情况 onnx.save(model_simp, groundingdino_sim.onnx)简化后用 onnxruntime 跑一遍输出和 PyTorch 的 logits、boxes 做余弦相似度对比大于 0.99 才算导出成功。这一步不能省否则你分不清是 TensorRT 的问题还是 ONNX 就已经错了。3. trtexec 构建 engine动态 batch 参数与精度档选择3.1 构建命令与核心参数ONNX 验证通过后构建 engine 首选 trtexec不要去写自定义 builder 脚本。trtexec 是 TensorRT 自带的命令行工具参数覆盖了绝大多数场景而且报错信息比 Python API 直观。一个能跑的构建命令大概长这样trtexec \ --onnxgroundingdino_sim.onnx \ --saveEnginegroundingdino_fp16.engine \ --minShapesimages:1x3x320x320,input_ids:1x256,attention_mask:1x256,token_type_ids:1x256,position_ids:1x256 \ --optShapesimages:1x3x800x800,input_ids:1x256,attention_mask:1x256,token_type_ids:1x256,position_ids:1x256 \ --maxShapesimages:2x3x1280x1280,input_ids:1x256,attention_mask:1x256,token_type_ids:1x256,position_ids:1x256 \ --fp16 \ --memPoolSizeworkspace:2048MiB注意--minShapes、--optShapes、--maxShapes三组参数必须把所有动态输入都覆盖到。很多人只写了 images 的动态范围其他输入没写结果构建时 TensorRT 认为它们只支持一种 shape运行时报 binding shape 不匹配。这个报错很隐晦它不会直接告诉你哪个输入漏了只会在你传不同长度 token 时突然崩溃。3.2 动态 shape 的 min/mid/max 怎么设动态 shape 的三档数值直接决定显存占用和性能。min 设太小没有意义设太大又浪费max 设太高会导致 TensorRT 为每个可能的分辨率都预留显存OOM 风险成倍上升。我一般用 320 作为最小边800 作为常规推理分辨率1280 作为上线。max batch 设成 2 就够绝大多数服务场景用了想压吞吐就设 4前提是你的显存扛得住。档位图像输入文本输入说明minShapes1x3x320x3201x256最低分辨率optShapes1x3x800x8001x256常规推理分辨率maxShapes2x3x1280x12801x256上限超过就截断或缩放之所以把文本输入在所有档位都写成 1x256是因为它不走动态轴只是随 batch 变化。如果某天你想在推理时支持更长 prompt就得重新构建 engine这是 TensorRT 静态优化的代价不是 bug。3.3 从 engine 到推理Python 侧加载与预处理engine 构建完成后推理封装需要处理一个核心问题TensorRT 的输入输出内存要自己管不像 PyTorch 那样自动分配显存。通常用 pycuda 分配 device memory再通过 ctypes 把数据拷进去。封装类里最关键的是 binding name 要和构建时保持一致。import pycuda.autoinit import pycuda.driver as cuda import numpy as np import tensorrt as trt class TRTEngine: def __init__(self, engine_path): with open(engine_path, rb) as f: self.engine f.read() runtime trt.Runtime(trt.Logger(trt.Logger.WARNING)) self.engine runtime.deserialize_cuda_engine(self.engine) self.context self.engine.create_execution_context() self.bindings {} self._allocate_buffers() def _allocate_buffers(self): for name in self.engine: shape self.engine.get_tensor_shape(name) size trt.volume(shape) dtype trt.nptype(self.engine.get_tensor_dtype(name)) self.bindings[name] cuda.mem_alloc(size * dtype.itemsize)trt.volume(shape)计算的是总元素个数乘上 dtype 的字节数才是实际要分配的显存大小。如果某次推理输入分辨率变了需要先调用context.set_input_shape更新动态 shape再拷数据。这一步容易忘忘了之后推理结果要么是空的要么直接段错误。图像预处理也必须固定写法OpenCV 读出来是 BGRGroundingDINO 训练时用的是 RGB并且做了 ImageNet 的 mean/std 归一化。先cv2.cvtColor转通道再 resize最后归一化转成 NCHW 布局。3.4 开集后处理文本 prompt 与类别框的对应逻辑推理拿到的输出是 logits 和 boxes。logits 的形状是 [batch, num_queries, num_concepts]num_concepts 和你的 prompt token 数量相关boxes 是 [batch, num_queries, 4]保存的是归一化坐标。GroundingDINO 的 logits 不是直接概率要过一层 sigmoid再用两个阈值筛box_threshold 控制框的可信度text_threshold 控制文本匹配度。官方 demo 常用的组合是 0.35 和 0.25我会在这个基础上根据业务场景微调。import torch from torchvision.ops import nms logits logits.sigmoid()[0] # [num_queries, num_concepts] boxes boxes[0] # [num_queries, 4] max_logits, max_idx logits.max(dim-1) keep max_logits box_threshold # 先框过滤 filtered_boxes boxes[keep] filtered_scores max_logits[keep] keep_idx nms(filtered_boxes, filtered_scores, iou_threshold0.5) result filtered_boxes[keep_idx]NMS 这一步不能省GroundingDINO 的 query 机制在开集场景下经常对同一个目标产生多个候选框。开集检测的「开」体现在 max_idx 对应的类别名由你的 prompt 动态决定模型并没有固定类别列表。4. 部署避坑记录五个高频问题与排查方法4.1 高频报错现象、原因、解决现象trtexec 构建到一半报 UNSUPPORTED_NODE日志里指向 Gather 或 Reshape 算子。原因GroundingDINO 的 SwinT backbone 里有 roll 操作和动态 shape 计算导出后残留了一堆非常量维度的 ReshapeTensorRT 解析不了。这个在 opset 11 时几乎必现在 opset 17 加上 onnxsim 简化之后基本消失。解决导出时 opset 固定 17简化阶段要盯着 onnxsim 输出的 check 结果如果 check 为 False 别强存。还不行的话手动把那几个 Reshape 的目标 shape 替换成常量张量。现象构建过程中显存暴涨最终报 out of memory 退出。原因maxShapes 设太激进TensorRT 为所有档位的 shape 组合都分配了优化空间。尤其是 images 的 max 开到 4x3x1280x1280 时跨模态注意力模块的中间张量会非常恐怖。解决把 max batch 降到 2分辨率上限降到 1280或者把--memPoolSize从 2048MiB 提到 4096MiB。我一般两个同时调先降显存占用再给 workspace 加预算。现象engine 跑起来了但检测框位置整体偏移小目标全漏。原因八成是预处理里的通道顺序搞反了。OpenCV 读图默认 BGR而 GroundingDINO 在 ImageNet 上训练时用的是 RGB少一行cv2.COLOR_BGR2RGB整个特征分布就偏了。这个错在 PyTorch 推理时不明显因为 PyTorch 也有不少人顺手就错过去了但在 TensorRT 的固定张量计算下会被放大。解决预处理里严格走 RGB 归一化并且用一张已知检测结果的图做回归测试确认框的 IoU 和 PyTorch 输出对得上。现象固定 token 长度后推理正常换一批 prompt 就输出错乱。原因padding 到 256 时把注意力掩码写错了。比如新 prompt 长度只有 50剩下 206 个 pad 位置 attention_mask 没置 0模型把无效 token 也当成真实语义参与跨模态注意力。解决tokenizer 输出后手动检查 attention_mask 的统计值。我一般会断言attention_mask[:, :real_len].sum() real_len跑一个 prompt 就能发现。现象fp16 engine 构建顺利但漏检率比 PyTorch 高一倍。原因GroundingDINO 的跨模态注意力模块对精度敏感fp16 下 softmax 和归一化层的动态范围被压缩logits 分不清相近语义。解决用性能分析工具定位掉点的层把 layer norm 和 attention 相关节点切回 fp32。如果项目周期紧可以先在 fp16 下把 box_threshold 从 0.35 降到 0.30观察召回是否恢复实在这条路走不通就直接回退 fp32 构建。4.2 精度掉点排查与取舍精度对齐一定要有一个对拍脚本把 PyTorch 输出和 TensorRT 输出放在同一张图上比较。只要 IoU 低于 0.9 或者 logits 的均值绝对误差大于 0.05就说明中间某个环节引入了不一致。先用它的结果定位问题阶段再决定是改预处理还是换精度档。torch_logits, torch_boxes model(image_tensor, captions) trt_logits, trt_boxes engine.infer(image_np, token_dict) # 计算框级 IoU 和 logits 差异 iou box_iou(torch_boxes[0], trt_boxes[0]) logits_diff (torch_logits - trt_logits).abs().mean() print(fIoU: {iou.mean().item():.4f}, logits MAE: {logits_diff.item():.4f})这里有个取舍问题fp16 的推理延迟可能比 fp32 快 30%但精度掉点一旦超过业务容忍度再大的加速也白搭。我的经验是先跑 fp32 打通全链路再开 fp16 做对比两边指标差得不多才允许 fp16 上线。5. 验证部署效果性能压测脚本与一条最后的习惯5.1 推理性能压测与结果回归engine 装好后性能压测不要只跑一次就下结论。GPU 推理第一次调用时有 kernel 加载开销混在统计数据里会拉高平均延迟。我一般先跑 10 次 warm-up再跑 100 次正式统计取平均延迟和吞吐。import time for _ in range(10): engine.infer(images, token_dict) # warm-up start time.time() for _ in range(100): engine.infer(images, token_dict) avg_ms (time.time() - start) / 100 * 1000 print(favg latency: {avg_ms:.2f} ms)trtexec 也可以做纯吞吐测试但它的输入是随机噪声不能验证功能正确性只能用来快速对比不同精度档的延迟差距。完整的工程脚本和流程教程已经打包在项目资源里下载后里面有我调试好的导出脚本、trtexec 配置和推理封装类输入你自己的 prompt 就能跑起来。5.2 一条最后的习惯以前我把 engine 导出来就以为部署完事了后来被一个环境问题卡了一整天才发现是 TensorRT 版本和 CUDA 小版本没对齐。从那以后我每换一台机器或升级任何一个组件都强制自己先跑一遍环境矩阵脚本确认 PID、CUDA、TensorRT 三者的版本和编译选项全部记录在案再开始构建。这个习惯帮我省了无数个加班的晚上希望帮到你。本文还有配套的精品资源点击获取 GroundingDINO部署TensorRT全攻略：从ONNX导出到工程化落地
简介面向算法部署工程师与目标检测研究者这份TensorRT实战项目系统展示了GroundingDINO开集目标检测从模型训练到NVIDIA GPU高效推理的完整部署链路。项目针对真实部署中的性能瓶颈重点讲解TensorRT模型优化、精度保持与硬件兼容性处理可适配安全监控、自动驾驶、医学影像等对未见过类别有识别需求的场景。压缩包共122个文件大小13.91MB其中53个Python脚本与31个Pyc编译文件构成主程序逻辑配套onnx模型和可运行engine权重便于直接验证cu/cpp源码对应自定义的ms_deform_attn等算子xml、txt文档用于配置与流程说明。目前已有187人学习浏览。除详尽流程教程与全部源码外资源还包含训练好的pth权重、ipynb示例笔记并针对模型转换、推理提速、结果分析等环节给出可复现步骤与排错思路开发者可按图索骥迁移到自有项目。1. 从 PyTorch 到 TensorRTGroundingDINO 部署的真正难处在哪目标检测进入开集时代之后GroundingDINO 几乎成了「文本指哪打哪」的标配算法但很多人 PyTorch 里玩得转一到 TensorRT 部署就翻车。原因很直接它不是单分支检测器而是文本编码器、视觉 backbone、跨模态解码器三个模块拼在一起的直接导出的 ONNX 在 TensorRT 里经常跑不动或者跑起来精度对不上。这篇文章就是把「PT 权重转 ONNX、ONNX 转 TensorRT engine、Python 侧推理封装」这条链路上的每个参数和坑位讲清楚适合手里已有 GroundingDINO 权重、正打算做服务化或边缘端部署的算法工程师。照着一章章走半天内能拿到一个能跑的 engine。2. 环境对齐与 ONNX 导出先让模型结构适合 TensorRT2.1 版本组合怎么选TensorRT、CUDA、GPU 的匹配逻辑部署 TensorRT 的第一步不是写代码而是把版本组合先定死。常见做法是 Python 3.10 CUDA 11.8 TensorRT 8.6 以上这一档PyTorch 用 2.0 左右就够导出用了。要注意nvidia-smi里看到的 CUDA 版本只是驱动支持的上限真正决定 TensorRT 能不能用的是你装的那个 CUDA toolkit 版本这个两个概念经常被混在一起报错的时候特别容易绕晕。另外很多人问 TensorRT 10.x 能不能支持 GTX 1070 这类老卡。装是能装但 GTX 1070 是 Pascal 架构fp16 的加速能力很弱转成 fp16 engine 之后延迟不一定比 fp32 低多少。我一般遇到这种卡就直接用 fp32 构建省得折腾半天精度还掉点。这是选择精度档前必须先想清楚的一件事。组件推荐组合说明Python3.103.8 也能跑但个别算子导出有坑PyTorch2.0 左右仅用于导出模型推理时不依赖它CUDA11.8与 TensorRT 配套不是看 nvidia-smiTensorRT8.6 及以上对动态 shape 和 ONNX opset 17 支持好onnx / onnxruntime各自最新稳定版一个做简化一个做导出后验证2.2 导出前的模型瘦身固定文本输入与 forward 替换GroundingDINO 官方推理接口是传字符串 captions模型内部再用 BERT tokenizer 把文本转成 input_ids、attention_mask 这些张量。这个设计在 PyTorch 里很顺手但到了导出 ONNX 就成了灾难——tokenizer 是纯 Python 逻辑没法被 torch.onnx.export 跟踪。最常见的做法是绕过 tokenizer写一个导出专用的 wrapper直接接收 token 张量。文本长度也要先定死。GroundingDINO 的文本分支可以处理变长 prompt但 TensorRT 对动态 shape 支持有限变长 token 意味着每次推理都要重新分配显存工程上非常不划算。业界常规做法是统一 pad 到固定长度比如 256。句子不够就补[PAD]超过 256 就先截断attention_mask 对应位置置 0告诉模型这些位置不用管。这个长度一旦定下来整个 engine 的输入输出形状就全定了。import torch.nn as nn class GroundingDINOExportWrapper(nn.Module): def __init__(self, model, max_text_len256): super().__init__() self.model model self.max_text_len max_text_len def forward(self, images, input_ids, attention_mask, token_type_idsNone, position_idsNone): # 直接传张量跳过 tokenizer 和预处理 return self.model( images, input_ids, attention_mask, token_type_ids, position_ids )这个 wrapper 的关键点在于绕过了captions字符串入口把所有文本相关的动态逻辑挡在模型外。具体输入名以你导出的 ONNX 为准不同版本的 GroundingDINO 输入顺序略有差异导出前用onnx.load打印一遍输入名最保险。我用这个方式导出过几个权重版本文本分支的输入基本上就是上面这几个张量个别版本没有 position_ids删掉对应行就行。2.3 导出与简化验证脚本导出时有三件事容易翻车模型忘记切 eval 模式、没有包 torch.no_grad、opset 版本太低。前两个会导致 ONNX 里混入 BatchNorm 的统计更新逻辑推理结果对不上。opset 方面SwinT 里有 roll 这类算子opset 11 导出会报错或者变成一堆难以优化的子图我一般直接用 17。import torch torch.onnx.export( wrapper, (images, input_ids, attention_mask, token_type_ids, position_ids), groundingdino.onnx, opset_version17, do_constant_foldingTrue, input_names[images, input_ids, attention_mask, token_type_ids, position_ids], output_names[logits, boxes], dynamic_axes{ images: {0: batch, 2: height, 3: width}, input_ids: {0: batch}, attention_mask: {0: batch}, token_type_ids: {0: batch}, position_ids: {0: batch}, }, )这里只把图像的宽高和 batch 设成动态文本的 token 长度保持静态 256这样 TensorRT 构建时的 shape 组合少很多。接下来做简化GroundingDINO 导出的 ONNX 里会产生大量冗余的 Gather、Reshape、Cast不简化的话 TensorRT 解析时容易报 unsupported node。import onnx from onnxsim import simplify onnx_model onnx.load(groundingdino.onnx) model_simp, check simplify(onnx_model) assert check, onnxsim 简化失败检查算子支持情况 onnx.save(model_simp, groundingdino_sim.onnx)简化后用 onnxruntime 跑一遍输出和 PyTorch 的 logits、boxes 做余弦相似度对比大于 0.99 才算导出成功。这一步不能省否则你分不清是 TensorRT 的问题还是 ONNX 就已经错了。3. trtexec 构建 engine动态 batch 参数与精度档选择3.1 构建命令与核心参数ONNX 验证通过后构建 engine 首选 trtexec不要去写自定义 builder 脚本。trtexec 是 TensorRT 自带的命令行工具参数覆盖了绝大多数场景而且报错信息比 Python API 直观。一个能跑的构建命令大概长这样trtexec \ --onnxgroundingdino_sim.onnx \ --saveEnginegroundingdino_fp16.engine \ --minShapesimages:1x3x320x320,input_ids:1x256,attention_mask:1x256,token_type_ids:1x256,position_ids:1x256 \ --optShapesimages:1x3x800x800,input_ids:1x256,attention_mask:1x256,token_type_ids:1x256,position_ids:1x256 \ --maxShapesimages:2x3x1280x1280,input_ids:1x256,attention_mask:1x256,token_type_ids:1x256,position_ids:1x256 \ --fp16 \ --memPoolSizeworkspace:2048MiB注意--minShapes、--optShapes、--maxShapes三组参数必须把所有动态输入都覆盖到。很多人只写了 images 的动态范围其他输入没写结果构建时 TensorRT 认为它们只支持一种 shape运行时报 binding shape 不匹配。这个报错很隐晦它不会直接告诉你哪个输入漏了只会在你传不同长度 token 时突然崩溃。3.2 动态 shape 的 min/mid/max 怎么设动态 shape 的三档数值直接决定显存占用和性能。min 设太小没有意义设太大又浪费max 设太高会导致 TensorRT 为每个可能的分辨率都预留显存OOM 风险成倍上升。我一般用 320 作为最小边800 作为常规推理分辨率1280 作为上线。max batch 设成 2 就够绝大多数服务场景用了想压吞吐就设 4前提是你的显存扛得住。档位图像输入文本输入说明minShapes1x3x320x3201x256最低分辨率optShapes1x3x800x8001x256常规推理分辨率maxShapes2x3x1280x12801x256上限超过就截断或缩放之所以把文本输入在所有档位都写成 1x256是因为它不走动态轴只是随 batch 变化。如果某天你想在推理时支持更长 prompt就得重新构建 engine这是 TensorRT 静态优化的代价不是 bug。3.3 从 engine 到推理Python 侧加载与预处理engine 构建完成后推理封装需要处理一个核心问题TensorRT 的输入输出内存要自己管不像 PyTorch 那样自动分配显存。通常用 pycuda 分配 device memory再通过 ctypes 把数据拷进去。封装类里最关键的是 binding name 要和构建时保持一致。import pycuda.autoinit import pycuda.driver as cuda import numpy as np import tensorrt as trt class TRTEngine: def __init__(self, engine_path): with open(engine_path, rb) as f: self.engine f.read() runtime trt.Runtime(trt.Logger(trt.Logger.WARNING)) self.engine runtime.deserialize_cuda_engine(self.engine) self.context self.engine.create_execution_context() self.bindings {} self._allocate_buffers() def _allocate_buffers(self): for name in self.engine: shape self.engine.get_tensor_shape(name) size trt.volume(shape) dtype trt.nptype(self.engine.get_tensor_dtype(name)) self.bindings[name] cuda.mem_alloc(size * dtype.itemsize)trt.volume(shape)计算的是总元素个数乘上 dtype 的字节数才是实际要分配的显存大小。如果某次推理输入分辨率变了需要先调用context.set_input_shape更新动态 shape再拷数据。这一步容易忘忘了之后推理结果要么是空的要么直接段错误。图像预处理也必须固定写法OpenCV 读出来是 BGRGroundingDINO 训练时用的是 RGB并且做了 ImageNet 的 mean/std 归一化。先cv2.cvtColor转通道再 resize最后归一化转成 NCHW 布局。3.4 开集后处理文本 prompt 与类别框的对应逻辑推理拿到的输出是 logits 和 boxes。logits 的形状是 [batch, num_queries, num_concepts]num_concepts 和你的 prompt token 数量相关boxes 是 [batch, num_queries, 4]保存的是归一化坐标。GroundingDINO 的 logits 不是直接概率要过一层 sigmoid再用两个阈值筛box_threshold 控制框的可信度text_threshold 控制文本匹配度。官方 demo 常用的组合是 0.35 和 0.25我会在这个基础上根据业务场景微调。import torch from torchvision.ops import nms logits logits.sigmoid()[0] # [num_queries, num_concepts] boxes boxes[0] # [num_queries, 4] max_logits, max_idx logits.max(dim-1) keep max_logits box_threshold # 先框过滤 filtered_boxes boxes[keep] filtered_scores max_logits[keep] keep_idx nms(filtered_boxes, filtered_scores, iou_threshold0.5) result filtered_boxes[keep_idx]NMS 这一步不能省GroundingDINO 的 query 机制在开集场景下经常对同一个目标产生多个候选框。开集检测的「开」体现在 max_idx 对应的类别名由你的 prompt 动态决定模型并没有固定类别列表。4. 部署避坑记录五个高频问题与排查方法4.1 高频报错现象、原因、解决现象trtexec 构建到一半报 UNSUPPORTED_NODE日志里指向 Gather 或 Reshape 算子。原因GroundingDINO 的 SwinT backbone 里有 roll 操作和动态 shape 计算导出后残留了一堆非常量维度的 ReshapeTensorRT 解析不了。这个在 opset 11 时几乎必现在 opset 17 加上 onnxsim 简化之后基本消失。解决导出时 opset 固定 17简化阶段要盯着 onnxsim 输出的 check 结果如果 check 为 False 别强存。还不行的话手动把那几个 Reshape 的目标 shape 替换成常量张量。现象构建过程中显存暴涨最终报 out of memory 退出。原因maxShapes 设太激进TensorRT 为所有档位的 shape 组合都分配了优化空间。尤其是 images 的 max 开到 4x3x1280x1280 时跨模态注意力模块的中间张量会非常恐怖。解决把 max batch 降到 2分辨率上限降到 1280或者把--memPoolSize从 2048MiB 提到 4096MiB。我一般两个同时调先降显存占用再给 workspace 加预算。现象engine 跑起来了但检测框位置整体偏移小目标全漏。原因八成是预处理里的通道顺序搞反了。OpenCV 读图默认 BGR而 GroundingDINO 在 ImageNet 上训练时用的是 RGB少一行cv2.COLOR_BGR2RGB整个特征分布就偏了。这个错在 PyTorch 推理时不明显因为 PyTorch 也有不少人顺手就错过去了但在 TensorRT 的固定张量计算下会被放大。解决预处理里严格走 RGB 归一化并且用一张已知检测结果的图做回归测试确认框的 IoU 和 PyTorch 输出对得上。现象固定 token 长度后推理正常换一批 prompt 就输出错乱。原因padding 到 256 时把注意力掩码写错了。比如新 prompt 长度只有 50剩下 206 个 pad 位置 attention_mask 没置 0模型把无效 token 也当成真实语义参与跨模态注意力。解决tokenizer 输出后手动检查 attention_mask 的统计值。我一般会断言attention_mask[:, :real_len].sum() real_len跑一个 prompt 就能发现。现象fp16 engine 构建顺利但漏检率比 PyTorch 高一倍。原因GroundingDINO 的跨模态注意力模块对精度敏感fp16 下 softmax 和归一化层的动态范围被压缩logits 分不清相近语义。解决用性能分析工具定位掉点的层把 layer norm 和 attention 相关节点切回 fp32。如果项目周期紧可以先在 fp16 下把 box_threshold 从 0.35 降到 0.30观察召回是否恢复实在这条路走不通就直接回退 fp32 构建。4.2 精度掉点排查与取舍精度对齐一定要有一个对拍脚本把 PyTorch 输出和 TensorRT 输出放在同一张图上比较。只要 IoU 低于 0.9 或者 logits 的均值绝对误差大于 0.05就说明中间某个环节引入了不一致。先用它的结果定位问题阶段再决定是改预处理还是换精度档。torch_logits, torch_boxes model(image_tensor, captions) trt_logits, trt_boxes engine.infer(image_np, token_dict) # 计算框级 IoU 和 logits 差异 iou box_iou(torch_boxes[0], trt_boxes[0]) logits_diff (torch_logits - trt_logits).abs().mean() print(fIoU: {iou.mean().item():.4f}, logits MAE: {logits_diff.item():.4f})这里有个取舍问题fp16 的推理延迟可能比 fp32 快 30%但精度掉点一旦超过业务容忍度再大的加速也白搭。我的经验是先跑 fp32 打通全链路再开 fp16 做对比两边指标差得不多才允许 fp16 上线。5. 验证部署效果性能压测脚本与一条最后的习惯5.1 推理性能压测与结果回归engine 装好后性能压测不要只跑一次就下结论。GPU 推理第一次调用时有 kernel 加载开销混在统计数据里会拉高平均延迟。我一般先跑 10 次 warm-up再跑 100 次正式统计取平均延迟和吞吐。import time for _ in range(10): engine.infer(images, token_dict) # warm-up start time.time() for _ in range(100): engine.infer(images, token_dict) avg_ms (time.time() - start) / 100 * 1000 print(favg latency: {avg_ms:.2f} ms)trtexec 也可以做纯吞吐测试但它的输入是随机噪声不能验证功能正确性只能用来快速对比不同精度档的延迟差距。完整的工程脚本和流程教程已经打包在项目资源里下载后里面有我调试好的导出脚本、trtexec 配置和推理封装类输入你自己的 prompt 就能跑起来。5.2 一条最后的习惯以前我把 engine 导出来就以为部署完事了后来被一个环境问题卡了一整天才发现是 TensorRT 版本和 CUDA 小版本没对齐。从那以后我每换一台机器或升级任何一个组件都强制自己先跑一遍环境矩阵脚本确认 PID、CUDA、TensorRT 三者的版本和编译选项全部记录在案再开始构建。这个习惯帮我省了无数个加班的晚上希望帮到你。本文还有配套的精品资源点击获取