ONNX Runtime在CPU上默认配置性能远未达最优，需调优会话初始化、数据流和线程调度：设intra_op_num_threads为物理核心数（如32），inter_op_num_threads为1–4，启用ORT_ENABLE_ALL图优化，锁定输入形状，使用io_binding避免内存拷贝，并充分预热。
ONNX Runtime在CPU上默认配置远未发挥硬件潜力，不调参直接跑session.run，延迟通常比优化后高2–5倍。关键不在模型本身，而在会话初始化、数据流和线程调度这三处。
设置intra_op_num_threads和inter_op_num_threads
CPU推理性能卡在“线程没用满”或“线程抢资源”上。Python默认只用1个线程，而现代服务器普遍是16核以上。必须显式配置：
-
intra_op_num_threads设为物理核心数（如32核CPU就设32），让单个算子（如GEMM、Conv）内部充分并行 -
inter_op_num_threads建议设为1–4，过大反而因调度开销拖慢；YOLOv5这类串行结构模型设1即可 - 禁用
enable_parallel_execution对多数CV模型无益，反而增加同步成本，保持False更稳
启用ORT_ENABLE_ALL图优化并固定输入形状
动态shape（比如[-1, 3, -1, -1]）会让ONNX Runtime跳过90%的图优化。生产环境几乎都用固定分辨率，务必导出时锁定维度：
- PyTorch转ONNX时加
dynamic_axes=None，或明确指定input_shape=(1,3,640,640) - 创建
SessionOptions时设graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALL - 避免在
session.run前做np.expand_dims或torch.unsqueeze——这些操作触发隐式copy，直接构造好(1,3,H,W)的np.ndarray喂进去
用io_binding绕过Host→CPU内存拷贝
每次session.run传入新numpy.ndarray，ORT默认重新分配buffer并拷贝数据。高频推理下，这部分开销可能占总延迟30%以上：
Secure Python Code Sandbox
下载
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
立即学习“Python免费学习笔记（深入）”；
- 提前创建
io = session.io_binding() - 用
io.bind_cpu_input("input", input_array)绑定一次，后续复用同一数组地址 - 确保
input_array是C-contiguous且dtype为np.float32，否则绑定失败或退化为拷贝 - 输出也建议用
bind_output+ 预分配output buffer，避免每次新建array
预热+避免torch.tensor()隐式复制
冷启动和数据类型转换是两个最隐蔽的延迟源：
- 服务启动后立即执行至少5轮
session.run（用真实输入shape），触发page fault、kernel cache、thread pool warmup - 别用
torch.tensor(outputs[0])包装ORT输出——它强制copy；改用torch.from_numpy(outputs[0])共享内存 - 如果后续要用CUDA tensor，先
torch.from_numpy再.to("cuda")，比torch.tensor(...).to("cuda")快2–3倍
真正卡住性能的，往往不是模型结构，而是io_binding没绑、intra_op_num_threads仍为1、或者每次推理都在重复分配和拷贝内存。这些点调完，YOLOv5在32核CPU上的单图延迟能从180ms压到60ms以内——但前提是所有参数都对齐真实部署场景，而不是套用教程里的“通用值”。
