📚 课程目录第4章性能分析工具

4. 性能分析工具：使用ONNX Runtime profiling、TensorRT、PyTorch等工具分析瓶颈

核心原理：推理性能瓶颈的三层定位逻辑

批量推理优化的前提是准确找到瓶颈所在。ONNX模型从框架导出到最终部署，性能损耗可能出现在三个层面：图优化层（算子融合、冗余节点消除）、运行时调度层（线程池分配、内存复用、IO张量拷贝）以及硬件执行层（kernel选择、显存带宽、量化精度）。不同工具从不同视角切入：ONNX Runtime profiling提供端到端算子级耗时；TensorRT通过构建期日志和层级分析暴露引擎优化细节；PyTorch Profiler则适合在模型导出前定位动态图阶段的瓶颈。三者并非互斥，而是形成“从框架到引擎再到硬件”的递进式诊断链路。

核心原则：先做粗粒度定位（哪一层/哪一段最慢），再做细粒度归因（是算子本身慢，还是数据搬运/同步等待导致）。切勿直接跳到算子级优化，否则容易陷入局部最优。

方法流程：三种工具的标准使用路径

4.1 ONNX Runtime Profiling：最直接的算子级耗时分析

ONNX Runtime自带的profiler能够记录每个算子（或融合后的节点）的执行时间、内存分配和形状信息。启用方式简单，只需在SessionOptions中开启即可：

import onnxruntime as ort
import numpy as np

sess_options = ort.SessionOptions()
sess_options.enable_profiling = True  # 开启profiling
sess_options.profile_file_prefix = "batch_infer"

session = ort.InferenceSession("model.onnx", sess_options, providers=["CUDAExecutionProvider"])
# 执行若干次推理
for _ in range(10):
    session.run(None, {"input": np.random.randn(8, 3, 224, 224).astype(np.float32)})

# 结束后生成时间线文件，如 batch_infer_*.json
prof_file = session.end_profiling()
print(f"Profile saved to: {prof_file}")

生成的JSON文件可用Chrome的chrome://tracing或Perfetto打开。重点关注：单算子耗时Top10、算子间空隙（gap）以及输入输出拷贝时间。若发现某个算子（如LayerNorm）耗时异常高，可进一步检查其输入shape是否触发动态分支。

4.2 TensorRT：构建期日志与层级分析

TensorRT在构建引擎时会输出详细的优化日志，包括：哪些层被融合、哪些层使用了低精度（FP16/INT8）、哪些层回退到FP32。使用Trtexec工具可快速获得摘要：

# 构建引擎并输出详细日志
trtexec --onnx=model.onnx --saveEngine=model.trt --fp16 --verbose

# 关键日志解读
[V] Layer (Conv_0) fused with Activation_1 into (Conv_0+Activation_1)
[I] Detected 3 layers with precision FP16
[W] Layer (Gather_5) could not be fused, using FP32 fallback

若日志中出现大量“could not be fused”或“fallback”，说明模型结构存在阻碍融合的节点（如动态Shape的Gather、非连续内存访问的Slice）。此时应回到模型导出阶段，尝试固定Shape或替换算子。

4.3 PyTorch Profiler：导出前的动态图瓶颈排查

在模型尚未导出ONNX时，使用PyTorch Profiler可以定位动态图中的CPU/GPU瓶颈，尤其是数据加载与GPU利用率不匹配的问题：

from torch.profiler import profile, ProfilerActivity

with profile(activities=[ProfilerActivity.CPU, ProfilerActivity.CUDA],
             record_shapes=True, profile_memory=True) as prof:
    for _ in range(5):
        output = model(input_tensor)

print(prof.key_averages().table(sort_by="cuda_time_total", row_limit=15))

重点关注cuda_time_total和cpu_time_total的比值。若CPU时间远大于GPU时间，说明数据预处理或张量搬运阻塞了计算流水线；若GPU利用率低于50%，则需增大batch size或使用CUDA Graph捕获。

案例实战：一个ResNet-50批量推理的瓶颈定位全过程

假设我们有一个导出的ResNet-50 ONNX模型，batch size=16，在A10 GPU上推理延迟为45ms，目标优化到20ms以内。按以下步骤进行诊断：

步骤	工具	发现	结论
1	PyTorch Profiler	数据加载耗时12ms，GPU空闲等待	预处理未与GPU计算重叠
2	ONNX Runtime Profiling	BatchNorm+Conv融合未生效，存在大量Transpose	图优化不彻底
3	TensorRT构建日志	检测到3个Resize层无法融合，回退FP32	动态分辨率导致优化受阻

针对上述发现，采取三项措施：

固定输入分辨率为224×224，消除Resize动态分支，使TensorRT完成全图融合；
在ONNX导出时删除冗余Transpose，通过onnxsim工具简化图结构；
使用CUDA Stream异步加载数据，使预处理与GPU推理并行。

优化后延迟降至18ms，满足目标。整个诊断过程耗时约2小时，其中profiling数据解读占70%时间——工具本身很快，瓶颈分析才是关键。

误区与复盘：性能分析中的常见陷阱

误区一：只关注算子耗时，忽略内存分配。ONNX Runtime的profiler默认不显示内存分配时间，但实际推理中，频繁的临时张量分配可能占20%以上耗时。务必在SessionOptions中开启enable_mem_pattern并检查arena_extend_strategy设置。

误区二：TensorRT日志中“fallback”不一定是坏事。某些算子（如TopK）在FP16下精度损失较大，回退FP32是正确行为。应结合精度验证结果判断，而非一味追求全FP16。

复盘要点：性能分析工具的输出只是“症状”，真正的“病因”往往在模型结构或数据流水线中。建议建立如下诊断习惯：

每次优化只改一个变量，对比profiling输出差异；
将ONNX Runtime的optimization_level从ORT_ENABLE_ALL逐步降级，观察耗时变化，判断图优化贡献度；
使用TensorRT的layer_info接口输出每层详细参数，与ONNX Runtime的算子耗时交叉比对，定位“工具间表现不一致”的深层原因。

最后，务必保存每次优化的profiling文件作为基线。批量推理优化是迭代过程，没有基线数据，后续回归测试将无从谈起。性能分析工具的价值不在于“跑一次出报告”，而在于建立可对比、可追溯的优化闭环。