PVN3D 原生 / ONNX 混合 / TRT 混合推理速度测试

1. 目的本文记录当前pvn3d-dev容器内三条推理链的测速方法与实测结果原生 PyTorch 推理ONNX Runtime 混合推理TensorRT 混合推理这里的“混合推理”含义固定为rgb_backbone走 ONNX Runtime 或 TensorRTPointNet2保留原生PyTorch CUDA Extensionfusion_head走 ONNX Runtime 或 TensorRT相关代码benchmark_linemod_hybrid_perf.pymodel_wrappers.pyrun_linemod_hybrid_ort.pyrun_linemod_hybrid_trt.py2. 测试环境本文结果来自当前实测容器容器pvn3d-dev仓库路径/workspace/workflow/self/PVN3DConda 环境pvn3dPython3.8.20PyTorch1.10.0cu113CUDA11.3GPUNVIDIA GeForce RTX 4060 Laptop GPUONNX1.14.1ONNX Runtime1.16.3ONNX Runtime providerCPUExecutionProviderTensorRT8.6.1这里最重要的一条环境边界是当前容器里的 ONNX Runtime 没有CUDAExecutionProvider所以本文的 ONNX 混合推理实际是CPU ORT GPU PointNet2这会直接拉低 ORT 混合链的速度。3. 测试对象与口径3.1 测试对象当前测速固定使用LINEMODapesample_index0checkpointweights/ape_pvn3d_best.pth.tarONNXdeploy/models/onnx_ape/rgb_backbone.onnxdeploy/models/onnx_ape/fusion_head.onnxTensorRT enginedeploy/models/engine_ape/rgb_backbone.enginedeploy/models/engine_ape/fusion_head.engine3.2 输入配置当前测速口径与导出配置保持一致height480width624crop_left8num_points40963.3 两组计时指标测速脚本输出两组结果network_only只统计网络前向链路end_to_end统计网络前向链路 cal_frame_poses_lmeval_metric_lm也就是说network_only更适合比较三个后端本身的前向速度end_to_end更接近当前整条测试链的真实耗时这里再明确一下两者的边界network_only到网络输出结束也就是得到pred_kp_of、pred_rgbd_seg、pred_ctr_of就停止计时end_to_end在network_only的基础上继续执行 pose 求解和评估再停止计时按当前代码路径理解就是network_only只看模型前向本身要多久end_to_end看“模型前向 pose solver ADD/ADD-S 评估”整条测试链一共要多久3.4 预热与轮次本文正式结果的固定配置为warmup5repeat20脚本会输出mean_msmedian_msmin_msmax_msp95_msfps_from_mean4. 测试脚本说明测速脚本在benchmark_linemod_hybrid_perf.py这个脚本统一封装了三条链nativeort_hybridtrt_hybrid4.1native直接调用full_model(cld_rgb_nrm, rgb, choose)这是当前原生 PyTorch 基线。4.2ort_hybrid执行顺序rgb_backbone.onnxpointnet2_nativefusion_head.onnx具体来说rgb进 ORTcld_rgb_nrm进原生 PointNet2out_rgb choose pcld_emb再进 ORT4.3trt_hybrid执行顺序rgb_backbone.enginepointnet2_nativefusion_head.engineTRT Python 侧不依赖pycuda而是直接用torch.cudatensor.data_ptr()把 GPU 指针交给 TensorRT。4.4 为什么脚本还要加载tar当前tar权重有两个作用给PointNet2 Native CUDA提供参数给full_model提供原生 PyTorch 基线这也是为什么当前 ONNX / TRT 测试还属于“混合部署测试”而不是完全脱离 PyTorch 的纯部署态。5. 测试步骤5.1 进入容器dockerexec-itpvn3d-devbashsource/opt/conda/etc/profile.d/conda.sh conda activate pvn3dcd/workspace/workflow/self/PVN3D5.2 确认产物存在lsdeploy/models/onnx_apelsdeploy/models/engine_ape当前至少应存在deploy/models/onnx_ape/rgb_backbone.onnxdeploy/models/onnx_ape/fusion_head.onnxdeploy/models/engine_ape/rgb_backbone.enginedeploy/models/engine_ape/fusion_head.engine5.3 先做一轮短测python deploy/benchmark_linemod_hybrid_perf.py\--backendall\--warmup1\--repeat3\--outputdeploy/benchmarks/smoke_perf.json这一步的目的不是看最终速度而是确认路径正确ORT / TRT / 原生三条链都能正常跑通输出 JSON 正常生成5.4 正式测速命令python deploy/benchmark_linemod_hybrid_perf.py\--backendall\--warmup5\--repeat20\--outputdeploy/benchmarks/linemod_ape_perf_formal.json5.5 结果文件正式测试结果保存在linemod_ape_perf_formal.json6. 实测结果6.1network_only后端mean_msmedian_msp95_msFPS原生 PyTorch125.034125.241129.9457.998ONNX 混合1451.2081441.3141586.1860.689TRT 混合71.45572.36977.45213.9956.2end_to_end后端mean_msmedian_msp95_msFPS原生 PyTorch133.172133.114137.5707.509ONNX 混合1495.8291485.7191708.7240.669TRT 混合82.57583.13385.62212.1106.3 相对速度按mean_ms计算TRT 混合比原生 PyTorch快约1.75x在network_only口径下最明显TRT 混合比原生 PyTorch快约1.61x在end_to_end口径下仍成立TRT 混合比ONNX 混合快约20.31x在network_only口径下TRT 混合比ONNX 混合快约18.12x在end_to_end口径下7. 结果解读7.1 为什么 TRT 混合最快原因很直接rgb_backbonefusion_head这两段在 TRT 下都走 GPU engine减少了 CPU 执行和中间框架开销。PointNet2 虽然仍然是原生 CUDA但前后两段已经被 TRT 压缩掉了大部分前向耗时。7.2 为什么 ONNX 混合最慢当前不是 ONNX 图结构有问题而是执行后端配置本身慢。容器内当前 ORT provider 只有CPUExecutionProvider所以rgb_backbone.onnx和fusion_head.onnx都在 CPU 上执行而 PointNet2 在 GPU 上执行。这样会带来CPU 前向耗时高CPU / GPU 之间额外的数据搬运三段链路之间同步成本更大因此当前 ORT 混合结果只能说明功能链路是通的不能把它当作最终部署性能上限。7.3 为什么end_to_end比network_only略慢因为end_to_end还包含cal_frame_poses_lmeval_metric_lm这些步骤虽然比前向轻但仍会增加一部分总时延。当前实测里原生链network_only - end_to_end增加约8.1 msTRT 混合链network_only - end_to_end增加约11.1 msORT 混合链network_only - end_to_end增加约44.6 ms8. 当前结论基于当前pvn3d-dev容器环境速度测试结论很明确当前最值得继续推进的是TRT 混合推理当前ONNX 混合推理更适合做功能验证不适合代表最终部署性能原生 PyTorch可以继续作为基线用于功能和性能对照对当前环境来说更合理的角色划分是原生 PyTorch作为精度与速度基线ONNX 混合作为结构联调与功能验证链TRT 混合作为当前阶段的性能优先部署方案