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

1. 目的

本文记录当前 pvn3d-dev 容器内三条推理链的测速方法与实测结果：

1. 原生 PyTorch 推理
2. ONNX Runtime 混合推理
3. TensorRT 混合推理

这里的"混合推理"含义固定为：

• rgb_backbone 走 ONNX Runtime 或 TensorRT
• PointNet2 保留原生 PyTorch + CUDA Extension
• fusion_head 走 ONNX Runtime 或 TensorRT

相关代码：

• benchmark_linemod_hybrid_perf.py
• model_wrappers.py
• run_linemod_hybrid_ort.py
• run_linemod_hybrid_trt.py

2. 测试环境

本文结果来自当前实测容器：

• 容器：pvn3d-dev
• 仓库路径：/workspace/workflow/self/PVN3D
• Conda 环境：pvn3d
• Python：3.8.20
• PyTorch：1.10.0+cu113
• CUDA：11.3
• GPU：NVIDIA GeForce RTX 4060 Laptop GPU
• ONNX：1.14.1
• ONNX Runtime：1.16.3
• ONNX Runtime provider：CPUExecutionProvider
• TensorRT：8.6.1

这里最重要的一条环境边界是：

• 当前容器里的 ONNX Runtime 没有 CUDAExecutionProvider
• 所以本文的 ONNX 混合推理，实际是 CPU ORT + GPU PointNet2

这会直接拉低 ORT 混合链的速度。

3. 测试对象与口径

3.1 测试对象

当前测速固定使用：

• LINEMOD ape
• sample_index=0
• checkpoint：weights/ape_pvn3d_best.pth.tar
• ONNX：
  • deploy/models/onnx_ape/rgb_backbone.onnx
  • deploy/models/onnx_ape/fusion_head.onnx
• TensorRT engine：
  • deploy/models/engine_ape/rgb_backbone.engine
  • deploy/models/engine_ape/fusion_head.engine

3.2 输入配置

当前测速口径与导出配置保持一致：

• height=480
• width=624
• crop_left=8
• num_points=4096

3.3 两组计时指标

测速脚本输出两组结果：

• network_only
  只统计网络前向链路
• end_to_end
  统计网络前向链路 + cal_frame_poses_lm + eval_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 预热与轮次

本文正式结果的固定配置为：

• warmup=5
• repeat=20

脚本会输出：

• mean_ms
• median_ms
• min_ms
• max_ms
• p95_ms
• fps_from_mean

4. 测试脚本说明

测速脚本在：

• benchmark_linemod_hybrid_perf.py

这个脚本统一封装了三条链：

1. native
2. ort_hybrid
3. trt_hybrid

4.1 native

直接调用：

• full_model(cld_rgb_nrm, rgb, choose)

这是当前原生 PyTorch 基线。

4.2 ort_hybrid

执行顺序：

1. rgb_backbone.onnx
2. pointnet2_native
3. fusion_head.onnx

具体来说：

• rgb 进 ORT
• cld_rgb_nrm 进原生 PointNet2
• out_rgb + choose + pcld_emb 再进 ORT

4.3 trt_hybrid

执行顺序：

1. rgb_backbone.engine
2. pointnet2_native
3. fusion_head.engine

TRT Python 侧不依赖 pycuda，而是直接用：

• torch.cuda
• tensor.data_ptr()

把 GPU 指针交给 TensorRT。

4.4 为什么脚本还要加载 tar

当前 tar 权重有两个作用：

1. 给 PointNet2 Native CUDA 提供参数
2. 给 full_model 提供原生 PyTorch 基线

这也是为什么当前 ONNX / TRT 测试还属于"混合部署测试"，而不是完全脱离 PyTorch 的纯部署态。

5. 测试步骤

5.1 进入容器

docker exec -it pvn3d-dev bash
source /opt/conda/etc/profile.d/conda.sh
conda activate pvn3d
cd /workspace/workflow/self/PVN3D

5.2 确认产物存在

ls deploy/models/onnx_ape
ls deploy/models/engine_ape

当前至少应存在：

• deploy/models/onnx_ape/rgb_backbone.onnx
• deploy/models/onnx_ape/fusion_head.onnx
• deploy/models/engine_ape/rgb_backbone.engine
• deploy/models/engine_ape/fusion_head.engine

5.3 先做一轮短测

python deploy/benchmark_linemod_hybrid_perf.py \
  --backend all \
  --warmup 1 \
  --repeat 3 \
  --output deploy/benchmarks/smoke_perf.json

这一步的目的不是看最终速度，而是确认：

• 路径正确
• ORT / TRT / 原生三条链都能正常跑通
• 输出 JSON 正常生成

5.4 正式测速命令

python deploy/benchmark_linemod_hybrid_perf.py \
  --backend all \
  --warmup 5 \
  --repeat 20 \
  --output deploy/benchmarks/linemod_ape_perf_formal.json

5.5 结果文件

正式测试结果保存在：

• linemod_ape_perf_formal.json

6. 实测结果

6.1 network_only

后端	mean_ms	median_ms	p95_ms	FPS
原生 PyTorch	125.034	125.241	129.945	7.998
ONNX 混合	1451.208	1441.314	1586.186	0.689
TRT 混合	71.455	72.369	77.452	13.995

6.2 end_to_end

后端	mean_ms	median_ms	p95_ms	FPS
原生 PyTorch	133.172	133.114	137.570	7.509
ONNX 混合	1495.829	1485.719	1708.724	0.669
TRT 混合	82.575	83.133	85.622	12.110

6.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_backbone
• fusion_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_lm
• eval_metric_lm

这些步骤虽然比前向轻，但仍会增加一部分总时延。

当前实测里：

• 原生链 network_only -> end_to_end 增加约 8.1 ms
• TRT 混合链 network_only -> end_to_end 增加约 11.1 ms
• ORT 混合链 network_only -> end_to_end 增加约 44.6 ms

8. 当前结论

基于当前 pvn3d-dev 容器环境，速度测试结论很明确：

1. 当前最值得继续推进的是 TRT 混合推理
2. 当前 ONNX 混合推理 更适合做功能验证，不适合代表最终部署性能
3. 原生 PyTorch 可以继续作为基线，用于功能和性能对照

对当前环境来说，更合理的角色划分是：

• 原生 PyTorch
  作为精度与速度基线
• ONNX 混合
  作为结构联调与功能验证链
• TRT 混合
  作为当前阶段的性能优先部署方案