ONNX Runtime：多线程推理

可视化演示

三步展示多线程推理：基于任务依赖图的拓扑调度、粗粒度（算子间）/细粒度（算子内）并行粒度、以及intra_op/inter_op_num_threads线程数配置。

线程池机制：稳固的后厨帮工团队

后厨不会等客人点完菜才跑去人才市场雇人，而是常年养着一支固定的帮工团队——来单就干，没单待命。ONNX Runtime 也遵循同样的智慧：它在线程池里预先创建好一批工作线程，模型推理时只管往“出菜单”上挂任务，线程们自会认领。

线程池按职责分为两类。第一类是 IntraOp 线程池，负责“算子内并行”——就像切墩师傅把一颗白菜分成四份，四人同时切。一个矩阵乘法算子可以把输出矩阵切成若干块，分给池内多个线程同时计算。第二类是 InterOp 线程池，负责“算子间并行”——就像炒锅组里，A师傅炒宫保鸡丁，B师傅同时炒麻婆豆腐，只要两个算子互不依赖，就可以并行推进。

任务队列是这套系统的枢纽。图执行器按依赖关系扫描计算图，把可并行的节点投入队列，线程池从队列头部取任务执行。队列模型决定了公平性与延迟上下限。

正是在这种“预建团队 + 队列分发”的机制下，ONNX Runtime 避免了频繁创建线程的开销，也让每一颗 CPU 核心都像后厨的灶台一样被充分使用。理解了线程池的双池结构，你就抓住了整个多线程推理的地基。

并行执行模式：多口锅同时开火

一支帮工团队在手，怎么把活派出去才能最快出菜？后厨有三种典型的并行打法，ONNX Runtime 的并行执行模式与之如出一辙。

数据并行对应“同一道菜多锅同时炒”——模型输入是多张图片时，把一批图片切分成多份，每份由一个线程走完整的计算链。这依靠 IntraOp 线程池发力。任务并行对应“不同菜品分头做”——计算图中互不依赖的分支算子，分别交给 InterOp 线程池里的不同线程，各算各互不打扰。流水线并行则更有意思：像传菜流水线，样本 A 的卷积还没算完，样本 B 已开始前处理，样本 C 已进入下一步，三个样本在时间轴上交错推进，让每个算子都保持忙碌。

不管哪种模式，都有一个“同步与等待”的问题——菜必须全部出锅才能上齐。执行引擎在汇合点等待最慢的线程完成，所以并行越快，木桶效应越明显。这正好引出了 Amdahl 定律：

回到后厨，哪怕是世界上最优秀的帮工团队，也要等最后一道菜出锅才能上席。这就是并行执行的宿命——识别模型里哪些环节是“不可并行的独灶”，才是优化的真正起点。

图优化调度：菜谱流程的重排

有了好团队，菜谱本身也得合理。大厨拿到食材，不会机械地照着菜谱一步一步来，而是会琢磨：哪两步能合并？哪步可以提前做？ONNX Runtime 的图优化调度做的就是这件事——在执行之前，先把计算图“重新编排”一遍。

算子融合是最经典的优化。后厨里“焯水→爆炒”本是两道工序，中间要过一遍凉水、换一次锅，费时费力。融合之后，焯完水直接下锅炒，中间环节全省。ONNX Runtime 会把 Conv + BatchNorm + ReLU 这种高频组合融合成一个自定义算子，内核启动次数从三次降为一次，中间张量也无需写回内存。

拓扑排序决定先做哪道菜。图执行器按照依赖关系排出无环的执行顺序，保证每个算子的输入就绪后才被调度。子图划分则是把整个计算图切分成可在 CPU、GPU 等不同设备上执行的子图。内存复用优化让多个不再使用的中间张量共享同一块缓存，像洗碗工把盘子洗干净立刻给下一道菜用，省下大量内存分配开销。

图优化调度像是大厨在营业前把菜谱改得行云流水。一次好的图优化，效果比盲目加线程还明显——少了反复启动和搬运，后厨的自然就出菜快了。这也是为什么 ONNX Runtime 在执行前会先跑一轮优化 pass 的原因。

线程配置策略：调整帮厨人数

既然有线程池，那该配多少人？ONNX Runtime 提供了两个旋钮：intra_op_num_threads 和 inter_op_num_threads。前者控制算子内并行的线程数（切墩组几人），后者控制算子间并行的线程数（炒锅组几口锅）。两个旋钮不是越大越好，需要根据模型结构和服务器核数精心调配。

在代码里只需两行：

线程绑定是另一个关键旋钮。默认情况下操作系统可以任意调度线程，这会导致 CPU 缓存频繁失效。把线程绑定到固定物理核，就像每个帮工固定用同一把菜刀——刀具趁手，切菜自然快。NUMA 感知更进一步：在多路服务器上，CPU 访问不同内存条的速度不一样。聪明的调度器会让线程优先使用本节点内存，减少跨总线的远程读取。

动态调整指的是运行时根据负载自动增减并行度。比如在线推理服务白天流量大，可以用多线程模式；夜间流量低，切换成低功耗单线程模式。

调整帮厨人数是一门平衡的艺术：人手太少出菜慢，人手太多挤在一个灶台反而碍手碍脚。用并行效率这个仪表盘，你可以一眼看出配置是否合理——效率跌破 50%，就该考虑减员或换优化策略了。

so = ort.SessionOptions()so.intra_op_num_threads = 4so.inter_op_num_threads = 2

性能分析：找到拖后腿的环节

后厨生意好不好，不能光看“出了多少菜”，还要看“客人等了多久”。ONNX Runtime 多线程推理的性能，同样需要从两个维度审视：吞吐量（每秒能处理多少请求）和延迟（单个请求从进到出花多久）。两者常常此消彼长——多线程榨出高吞吐，但线程间的协调也可能让单请求延迟微升。

性能分析最常用的指标是 CPU 利用率。如果开着 8 线程跑模型，CPU 利用率却只有 40%，说明线程在空等——可能是数据喂得太慢，也可能是线程竞争锁太厉害。线程竞争就像两个帮工抢同一把勺：一个紧紧攥着锁，另一个只能干瞪眼。上下文切换过多时，CPU 大量时间耗在切换线程上而不是真正的计算上。

瓶颈定位的逻辑是从整体到局部：先用 profiler 看每个算子的耗时占比，找出最耗时的前三个算子，再深入分析它们是否吃满了并行度。比如一个矩阵乘算子在 4 线程下只用了 1.2 倍加速，那就该检查是数据量太小拆不开，还是内存带宽到了极限。

在后厨，一道菜上慢了可能是切菜的磨洋工，也可能是等锅等太久。性能分析的意义正是找出那个“磨洋工”的环节。记得先测数据再下结论——优化靠直觉，很容易把时间浪费在根本无关紧要的步骤上。

工程实践：真实餐厅的经营之道

理论讲完了，回到真实世界的烟火气。假设你正在部署一个图像分类服务，模型是 ResNet-50 转成的 ONNX 格式。服务器的 CPU 是 16 核，你该用几个线程？经验公式是：intra_op = 4、inter_op = 2 起步，然后做网格搜索。图像模型里卷积算子是计算大头，调高 intra_op 能显著加速；如果模型结构是类似 GoogLeNet 这种多分支并行结构，增加 inter_op 效果更好。

NLP 场景就不太一样。BERT 这类 Transformer 模型以矩阵乘为主，算子间依赖强，多设 inter_op 线程意义不大，反而应该把所有线程都集中到 intra_op 上。更进阶的玩法是动态批处理：把并发到达的多个请求攒成一波，用数据并行一次性推理，吞吐量能翻好几倍——就像后厨把四个人的单子合并成一大锅炖。

实践中最大的坑是死锁与竞争排查。如果自定义算子里调用了一个会等待其他线程释放锁的函数，而那个线程又卡在这个算子的任务队列上——两个师傅互相等对方的锅，整个推理服务就冻住了。排查办法是先用 top -H 看线程状态，再用 gdb 抓线程栈，确认是锁等待还是死循环。

经营好一家真实的后厨，靠的不是某一招绝活，而是对每个环节的了解。图像分类靠 intra_op 提速度，NLP 靠动态批处理提吞吐，死锁排查靠线程栈定位。把这些经验沉淀成自己的调优清单，下一次遇到新模型就能快速找到最优配置。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""ONNX Runtime 多线程推理性能对比演示"""import timeimport numpy as npimport onnximport onnxruntime as ortfrom onnx import helper, TensorProto  def build_demo_model(path="demo_model.onnx"):    """构造一个简单的三层 MLP 模型并保存为 ONNX 文件"""    X = helper.make_tensor_value_info("X", TensorProto.FLOAT, [1, 64])    Y = helper.make_tensor_value_info("Y", TensorProto.FLOAT, [1, 10])    weight1 = np.random.randn(64, 128).astype(np.float32)    weight2 = np.random.randn(128, 10).astype(np.float32)     initializers = [        helper.make_tensor("W1", TensorProto.FLOAT, [64, 128], weight1.flatten()),        helper.make_tensor("B1", TensorProto.FLOAT, [128], np.zeros(128, dtype=np.float32)),        helper.make_tensor("W2", TensorProto.FLOAT, [128, 10], weight2.flatten()),        helper.make_tensor("B2", TensorProto.FLOAT, [10], np.zeros(10, dtype=np.float32)),    ]    nodes = [        helper.make_node("MatMul", ["X", "W1"], ["fc1"]),        helper.make_node("Add", ["fc1", "B1"], ["fc1b"]),        helper.make_node("Relu", ["fc1b"], ["act1"]),        helper.make_node("MatMul", ["act1", "W2"], ["fc2"]),        helper.make_node("Add", ["fc2", "B2"], ["Y"]),    ]    graph = helper.make_graph(nodes, "demo_mlp", [X], [Y], initializers)    model = helper.make_model(graph, opset_imports=[helper.make_opsetid("", 13)])    onnx.save(model, path)    return path  def benchmark(model_path, intra, inter, rounds=100):    """在指定线程数配置下测量平均推理延迟（毫秒）"""    so = ort.SessionOptions()    so.intra_op_num_threads = intra    so.inter_op_num_threads = inter    sess = ort.InferenceSession(model_path, so, providers=["CPUExecutionProvider"])    x = np.random.randn(1, 64).astype(np.float32)    for _ in range(10):  # warmup        sess.run(None, {"X": x})    start = time.perf_counter()    for _ in range(rounds):        sess.run(None, {"X": x})    avg_ms = (time.perf_counter() - start) / rounds * 1000    return avg_ms  if __name__ == "__main__":    model_path = build_demo_model()    print("=== ONNX Runtime 多线程推理性能对比 ===")    for intra, inter in [(1, 1), (2, 1), (4, 1), (4, 2), (8, 2)]:        avg = benchmark(model_path, intra, inter)        print(f"intra={intra:2d} inter={inter:2d} | 平均延迟 {avg:8.2f} ms")

1. sess_options = ort.SessionOptions()创建会话配置对象，所有线程旋钮都挂在这个“控制面板”上。
2. so.intra_op_num_threads = intra设置算子内并行线程数，决定单个算子拆成几块算。
3. so.inter_op_num_threads = inter设置算子间并行线程数，决定同时跑几个独立算子。
4. sess.run(None, {"X": x})真正执行一次推理，第一个参数为 None 表示返回所有输出。
5. time.perf_counter()高精度计时器，比 time.time() 更适合毫秒级性能测量。

常见误区

面试题