一台 128 核的服务器跑大模型推理的吞吐量却不如 32 核机器——这种情况在实际工程中并不罕见。根本原因往往不是核数不够而是线程之间的沟通成本太高以及内存访问路径不对。本篇聚焦两个关键优化方向线程亲和性Thread Affinity和NUMA 感知NUMA-Aware解释它们的原理并提供可直接使用的配置方案。1 多核 CPU 的内存访问模型1.1 UMA vs NUMA现代高核数服务器处理器几乎都是 NUMA 架构NUMA 节点 0 NUMA 节点 1 ┌─────────────────────┐ ┌─────────────────────┐ │ CPU Core 0-31 │ │ CPU Core 32-63 │ │ L3 Cache (共享) │ │ L3 Cache (共享) │ │ 内存控制器 │◄──────►│ 内存控制器 │ │ 本地 DRAM │ │ 本地 DRAM │ └─────────────────────┘ └─────────────────────┘本地内存访问Core 0 访问 NUMA 节点 0 的内存 → 低延迟远端内存访问Core 0 访问 NUMA 节点 1 的内存 → 需跨 NUMA 互联延迟高约 30-50%1.2 大模型推理的内存访问特征以 7B 模型FP16约 14GB为例模型权重在内存中占据连续大块空间每次推理都需要将权重从内存加载到 CPU 缓存若线程分散在多个 NUMA 节点权重可能被分散在不同 NUMA 节点的内存上产生大量远端内存访问2 查看系统 NUMA 拓扑在优化之前先了解机器的 NUMA 布局# 查看 NUMA 节点数量和每个节点的 CPU 分布numactl--hardware# 示例输出# available: 2 nodes (0-1)# node 0 cpus: 0 1 2 3 ... 31# node 0 size: 128000 MB# node 1 cpus: 32 33 34 ... 63# node 1 size: 128000 MB# node distances:# node 0 1# 0: 10 20# 1: 20 10# 查看详细 CPU 拓扑核/线程/NUMAlscpu--extended# 查看当前进程的 NUMA 绑定情况numastat-p$(pgrep python)3 NUMA 感知推理部署3.1 numactl 绑定最简单的方式用numactl将推理进程绑定到单个 NUMA 节点# 将推理进程绑定到 NUMA 节点 0内存也从节点 0 分配numactl--cpunodebind0--membind0python inference_server.py# 多实例部署节点 0 和节点 1 各跑一个实例numactl--cpunodebind0--membind0python inference_server.py--port8080numactl--cpunodebind1--membind1python inference_server.py--port80813.2 Python 中的 NUMA 感知内存分配importosimportctypesdefset_numa_policy(node:int):将当前进程的内存分配策略设置为绑定到指定 NUMA 节点# MPOL_BIND 2表示严格绑定到指定节点libnumactypes.CDLL(libnuma.so.1)nodemaskctypes.c_ulong(1node)# 绑定到 node 节点libnuma.set_mempolicy(2,ctypes.byref(nodemask),64)# 在模型加载前调用set_numa_policy(node0)importtorch modeltorch.load(model.pt)# 权重将分配在 NUMA 节点 0 的内存上4 线程亲和性优化4.1 什么是线程亲和性线程亲和性Thread Affinity / CPU Pinning是指将线程固定到特定的 CPU 核心上运行避免操作系统调度器在核心间迁移线程。为什么重要线程迁移会导致该线程的 L1/L2 缓存数据失效迁移后需要重新预热缓存这对推理性能影响可达 10-20%。4.2 OpenMP 线程亲和性配置llama.cpp、PyTorch 等框架使用 OpenMP 进行多线程并行通过环境变量控制线程亲和性# OMP_PROC_BIND: 线程绑定策略# close - 线程尽量靠近主线程适合数据局部性优化# spread - 线程均匀分散适合独立并行任务# master - 所有线程绑定到主线程所在核心exportOMP_PROC_BINDcloseexportOMP_PLACEScores# 以物理核为单位不包含超线程exportOMP_NUM_THREADS32# 线程数 NUMA 节点 0 的物理核数# 验证绑定效果OMP_DISPLAY_ENVTRUE python-cimport torch; print(torch.get_num_threads())4.3 taskset 手动绑定# 将 Python 进程绑定到 CPU 0-31NUMA 节点 0 的物理核taskset-c0-31 python inference_server.py# 查看进程的 CPU 亲和性掩码taskset-p$(pgrep python)# 组合 NUMA 绑定和 CPU 亲和性绑定numactl--membind0taskset-c0-31 python inference_server.py4.4 Python 代码中设置亲和性importosimportpsutildefpin_to_cores(core_list:list[int]):将当前进程绑定到指定 CPU 核心ppsutil.Process(os.getpid())p.cpu_affinity(core_list)print(fProcess{os.getpid()}pinned to cores:{p.cpu_affinity()})# 推理进程绑定到 NUMA 节点 0 的核心0-31pin_to_cores(list(range(32)))5 超线程HyperThreading对推理的影响超线程允许一个物理核运行两个逻辑线程但二者共享计算单元和缓存。在大模型推理中超线程的影响存在争议场景超线程收益纯矩阵乘法计算密集通常无益甚至降低性能竞争 FPU 单元IO 密集型预处理有一定收益混合批处理多请求并行略有帮助建议对推理服务进行 A/B 测试分别在OMP_NUM_THREADS物理核数和OMP_NUM_THREADS逻辑核数下测试取性能更好的配置。# 查看物理核数 vs 逻辑核数lscpu|grep-E^CPU\(s\)|Thread\(s\) per core|Core\(s\) per socket# CPU(s): 128# Thread(s) per core: 2 - 超线程开启逻辑核物理核×2# Core(s) per socket: 326 llama.cpp 的多核配置示例llama.cpp 是目前 CPU 推理最高效的开源实现其线程配置# -t: 线程数建议等于物理核数而非逻辑核数# -ngl: 将多少层卸载到 GPU纯 CPU 推理设为 0# NUMA 节点 032 物理核INT4 量化模型numactl--cpunodebind0--membind0\./llama-cli\-m./models/llama-3-8b.Q4_K_M.gguf\-t32\-ngl0\-p你好请介绍一下自己7 总结多核 CPU 推理优化的核心是减少跨 NUMA 访问和保持缓存热数据单 NUMA 节点部署模型权重与计算线程在同一 NUMA 节点消除远端内存延迟线程亲和性用OMP_PROC_BINDclose或taskset固定线程保持缓存热度线程数 物理核数超线程对矩阵运算通常无益不要盲目开满逻辑核数多实例 单实例高并发场景下每个 NUMA 节点跑一个独立实例比单实例多线程更高效