LibTorch单/多线程CPU推理延迟差异疑问及同延迟可能性咨询

现象是否正常？ #

这种情况完全正常，在单样本CPU推理场景中十分普遍。

详细原因解释 #

• 线程管理开销过高：启动64个线程需要额外的创建、调度、上下文切换成本，单样本推理的计算量通常很小，根本无法摊平这些开销，反而会因为频繁的线程调度拖慢整体速度。
• 模型并行度不足：如果你的模型以串行算子为主（比如简单全连接链、部分RNN结构），多线程无法有效拆分计算任务，线程间的同步等待反而会浪费时间。
• 内存带宽瓶颈：CPU推理时，内存与计算单元间的数据传输是核心瓶颈。64个线程同时争抢内存带宽，会导致数据读取延迟飙升，直接拖慢推理速度。
• 底层库调度策略限制：LibTorch依赖OpenMP/MKL-DNN做线程管理，这些库在小计算量场景下的调度策略并非最优，线程数超过可并行任务数时，会出现大量线程空转的情况。

不同线程数能否实现相同推理延迟？ #

可以，但需要满足特定条件：

• 增大推理任务量：当batch size足够大，或者模型包含大量可并行的计算算子（比如CNN卷积层），多线程能充分发挥作用，此时调整线程数到合适值（比如等于物理核心数），延迟可能和单线程接近甚至更低。
• 优化线程配置：通过at::set_num_interop_threads()控制算子间并行线程数，配合at::set_num_threads()调整算子内并行线程数，找到适配当前模型与硬件的平衡点。
• 减少不必要同步：检查模型中是否存在强制同步的算子，或调整LibTorch编译参数，禁用非必要的线程同步机制。

内容的提问来源于stack exchange，提问作者IDO