先说个真事。自己装机跑AI训练，机器是双路EPYC加四张卡，之前训练YOLOv8，loss掉得挺顺，但GPU利用率总是跳来跳去，天气一热甚至降到70%以下。一开始怀疑是数据加载线程太少，调了num_workers，没用。后来发现CPU跑在remote内存上的比例高得吓人，换到本地内存后，训练时间直接缩了快三成。这背后的工具就是numactl，平时很多人都当它是个“查拓扑的小命令”，实际上在AI训练场景里，它是个调性能的好东西。
这篇文章就把这套绑核玩法整个拆开聊——先说清楚为什么绑核能提速，再说怎么看拓扑、怎么绑、怎么验证，顺手把WSL2环境里的坑也填了。
1. 为什么绑核能带来接近30%的训练加速
1.1 先说清楚NUMA到底是怎么回事
多路服务器或者桌面级工作站，比如双路EPYC、双路Xeon，甚至单个大核心数的处理器，内部都是NUMA架构。NUMA全称是Non-Uniform Memory Access，非一致内存访问。啥意思呢？每个CPU都有自己的本地内存，访问本地内存快，访问别的CPU的内存慢。
拿双路工作站来说，CPU0和CPU1各自挂着一半内存条。如果你的CPU0上的进程去读CPU1上的内存，路径要经过两个CPU之间的互连总线，延迟高，带宽也打折。两种访问差异有多大？用latency测试工具可以测，本地内存访问延迟在100纳秒上下，远端轻轻松松超200纳秒，极端情况下翻倍都不止。
AI训练恰恰就是“内存带宽敏感 + 访问延迟敏感”的典型负载。每轮迭代要读图、做增强、把数据搬到GPU显存，参数更新又要读写内存。一旦数据所在的内存节点和计算所在的核心不匹配，额外的跨节点访问会拖慢整个pipeline。
很多时候大家训练慢，不是GPU不够好，是CPU和内存之间的“路”太堵了。
1.2 绑核的真正意义不只是锁CPU
所谓“绑核”，字面上是让进程只跑在指定CPU核心上，但真正值钱的是把内存访问也一起“钉死”在同一个NUMA节点上。
numactl的两个关键参数就能干这事：
--cpunodebind：指定进程运行在哪个NUMA节点的CPU核上。--membind：指定内存分配只从哪个NUMA节点取。
两者一组合，进程跑在节点0的CPU上，内存也从节点0分配，本地访问，性能自然好。
有人问，只用taskset -c绑CPU不行吗？taskset确实能锁核，但它管不了内存分配策略。Linux内存分配默认是“优先本地分配”，第一次缺页时哪个核发起的请求就优先从那个节点分配。如果你进程运行一会儿后核心被调度器赶走了，后续的内存分配就可能落到别的地方。用numactl --membind可以把内存策略锁死，比单独taskset可靠得多。
1.3 为什么AI训练收益尤其大
AI训练的数据管线通常包含几个环节：CPU读图片、解码、缩放、归一化，拼成batch放到pin memory，然后GPU通过DMA直接搬进显存。
这个链路里有大量CPU与内存的交互，而GPU搬数据、同步数据又依赖CPU持续响应。跨NUMA访问会让每一步都变慢，最终表现为GPU一个step等数据等很久。
PyTorch训练里那种“GPU利用率在90%和40%之间反复横跳”的现象，八成离不开CPU管线没优化好。绑核之后，数据管线稳定跑在同一个NUMA节点上，GPU侧不用干等，吞吐量自然上来了。标题里说30%的加速，在不同场景下我也实测过，数据量小、迭代快的任务收益尤其明显，最夸张的一次是练一个小型分类模型，耗时降了接近四成。
2. 动手前先看清机器的CPU和GPU拓扑
2.1 用lscpu和numactl拿到基础布局
绑核第一步是搞清楚机器到底有几个NUMA节点、每个节点包含哪些核心。打开终端执行：
lscpu | grep -E "NUMA|Socket|Core|Thread"输出大概长这样：
NUMA node0 CPU(s): 0-31,64-95 NUMA node1 CPU(s): 32-63,96-127意思是两颗CPU，每个CPU各管一个NUMA节点，每个节点32个物理核，开了超线程后总共64个逻辑核。
再看内存分布：
numactl --hardware输出里会列出每个node的可用内存大小。注意，如果两路内存条插得不均，比如CPU0那侧插了128GB，CPU1那侧只插了64GB，那大容量侧往往更适合放AI训练任务，因为本地内存大，不容易出现内存不足被迫跑到远端的情况。
很多服务器的BIOS默认把内存interleave打开，也就是两个节点的内存交叉使用，此时numactl --hardware看到的可能就是均分状态。对AI训练来说，建议关掉interleave，保持本地内存优先，性能更稳定。
2.2 用nvidia-smi topo -m确认GPU挂在哪个CPU下面
服务器主板上PCIe槽位是有讲究的。GPU插在CPU0的PCIe控制器上还是CPU1的，直接影响数据通路。执行：
nvidia-smi topo -m输出是一张GPU间的互连矩阵，还会显示每个GPU和CPU/NIC的连接关系。重点关注CPU Affinity这一列，比如：
GPU0 CPU Affinity NUMA Affinity GPU0 0-31,64-95 N/A GPU1 32-63,96-127 N/A这就说明GPU0挂在CPU0那边，GPU1挂在CPU1那边。绑定的时候，跑GPU0的数据管线任务要把CPU绑到node0，跑GPU1就绑到node1。
另一招更直观，看GPU挂在哪个PCIe控制器下：
lspci -s $(nvidia-smi --query-gpu=pci.bus_id --format=csv,noheader | head -n1 | sed 's/0000://;s/\.0$//') -v | grep -E "NUMA node"能看到这张卡所属的NUMA节点号。多卡机器建议每张卡都查一遍，做到心中有数。
2.3 结合HBM和CPU拓扑规划训练任务
GPU显存属于GPU内部资源，和CPU端NUMA关系不大，但HBM和显存带宽会影响数据回传。CPU端绑好NUMA了，GPU端也要选对卡，尽量避免跨PCIe switch访问另一颗CPU下的显卡。
用nvidia-smi topo -m看互连矩阵时，两个GPU之间的连接类型如果是PIX（同一个PCIe switch下），那它们之间通信最快；如果是PXB，说明隔了一个PCIe switch；如果是SYS，说明它们分别挂在不同的CPU下，要走CPU之间的总线。多卡训练做数据并行时，同节点训练速度明显优于跨节点，绑核要结合这个矩阵来安排。
3. 实操：多卡训练绑核的完整步骤
3.1 第一步：确认你的训练框架支持什么级别的并行
PyTorch里有多卡并行方案，最常见的是DistributedDataParallel（DDP）。DDP启动时通常用torchrun，每个GPU对应一个进程，进程数量等于GPU数量。
要配合绑核，最干净的方式是让torchrun的每个rank自动绑到对应GPU所在NUMA节点的核上。实测可用的启动脚本大致如下：
#!/bin/bash export CUDA_VISIBLE_DEVICES=0,1,2,3 torchrun --nproc_per_node=4 \ --master_port=29500 \ train.py --epochs 100 --batch-size 64这样启动的所有进程默认可能跑在任意核心上。绑核要做的就是给每个rank指定CPU亲和性。
3.2 第二步：给每个rank单独绑核
常见做法是在训练脚本里通过os.sched_setaffinity限制当前进程的CPU集合。
比如rank0对应GPU0，GPU0挂在node0，就把它绑到node0的核上：
import os import torch def bind_process_to_node(rank, node_cores): """ 将当前进程绑定到指定的CPU核心列表 node_cores: 例如 [list(range(0, 8))] """ pid = os.getpid() os.sched_setaffinity(pid, node_cores) if __name__ == "__main__": rank = int(os.environ.get("LOCAL_RANK", 0)) # 假设GPU0/1在node0，GPU2/3在node1 if rank < 2: node_cores = list(range(0, 32)) + list(range(64, 96)) bind_process_to_node(rank, node_cores) else: node_cores = list(range(32, 64)) + list(range(96, 128)) bind_process_to_node(rank, node_cores) # 接下来正常开始训练这里有个容易犯的错：直接绑全部逻辑核，包括超线程对。AI训练大部分是计算密集兼内存密集，不需要同时占满所有硬件线程。把两个逻辑核绑同一个物理核可能导致资源争抢，性能反而下降。
更合理的绑定策略是只绑每个物理核上的一个逻辑核。比如双路机器，node0物理核范围可能是0-31，超线程对是64-95，那绑核就只绑0-31，不要带上64-95。
3.3 第三步：用numactl命令直接启动，绕过代码改动
如果用命令行直接启动训练，不想改代码，用numactl也能实现同样的效果：
# rank0进程绑定到node0的CPU和内存，跑GPU0 CUDA_VISIBLE_DEVICES=0 numactl --cpunodebind=0 --membind=0 \ torchrun --nproc_per_node=1 --master_port=29500 train.py # rank1进程绑定到node1的CPU和内存，跑GPU1 CUDA_VISIBLE_DEVICES=1 numactl --cpunodebind=1 --membind=1 \ torchrun --nproc_per_node=1 --master_port=29500 train.py这种方式对不熟悉的同学更直观，每个GPU一个终端窗口或者用后台任务启动就行。但注意，torchrun默认可能还会启动一些子进程，numactl只对直接启动的命令生效，子进程是否继承要看--nproc_per_node的机制。通常torchrun --nproc_per_node=1时，子进程就是当前进程自己，继承没问题。
3.4 第四步：给DataLoader的worker也加上亲和性
光绑主进程不绑数据加载worker，效果会打折扣。PyTorch的DataLoader开启num_workers>0后，worker是独立进程，CPU调度器可能把worker放到任意核心上，甚至跑到别的NUMA节点。
推荐的解法是在worker初始化时也绑核。设置worker_init_fn：
def worker_init_fn(worker_id): pid = os.getpid() # 根据worker_id分配不同的核心,避免大家都挤在同一个核上 core_list = list(range(worker_id * 4, worker_id * 4 + 4)) os.sched_setaffinity(pid, core_list) DataLoader( dataset, batch_size=64, num_workers=8, worker_init_fn=worker_init_fn, pin_memory=True, )注意pin_memory=True也很关键，它会在CPU端分配page-locked memory，让GPU搬运数据更快。绑核加上pin memory，数据管线通常能稳不少。
3.5 第五步：验证绑定是否生效
绑定不是绑完就完了，要确认到底绑定到了哪里。最直接的验证方法：
# 查看当前训练进程跑在哪个核上 ps -eo pid,psr,comm | grep train.pypsr列就是当前进程实际运行的核心号。如果进程在不同核心间跳动，说明绑定没生效。绑定的情况下，psr的值应该稳定在你设定的范围内。
更准确的方式是用taskset查看CPU亲和性掩码：
taskset -cp <pid>输出类似：
pid 12345's current affinity list: 0-31这里显示0-31，说明绑核成功。
内存绑定的验证相对抽象。可以先看进程的NUMA内存分配统计：
numastat -p <pid>这个命令显示进程在哪个node上实际分配了多少内存。如果--membind=0生效，且本轮训练数据都从node0分配，你会看到node1那列数值很小，node0那列才是大头。
3.6 第六步：动态调整核心数，找到最优绑核区间
绑核不是绑得越少越好，也不是绑得越多越好。核心数太少，解码和预处理速度跟不上；核心数太多，多进程混在一起反而争抢L3缓存和内存带宽。
建议的调参方法是：先用numactl --hardware确认每个节点的物理核心数，然后从“一半物理核”开始试，比如node0有32个物理核，先绑16个，再逐步递增观察训练吞吐量。
记录指标时用nvidia-smi dmon -s pu -c 100盯GPU利用率，同时用mpstat -P ALL 1观察各核心使用率。核心绑少了，GPU利用率会周期性掉到0；绑多了，出现CPU上下文切换开销，训练时长反而增加。找到一个“GPU利用率长期稳定在95%以上”的区间就对了。
4. 如何查看组件到底绑在哪个核上
4.1 ps加上排序，快速全览
训练过程中想快速知道所有子进程分别跑在哪个核心上：
ps -eo pid,psr,comm | awk '$3 ~ /python/ {print $1, $2, $3}'如果显示的结果中psr值都在你绑定的范围内，说明没问题。如果跳出范围了，那就是有地方没绑住，最常见的是torchrun又拉起了别的进程，或者有第三方库自己起线程池。
4.2 用htop可视化核对
htop打开后按F2进入设置，在Display options里勾选Detailed CPU time和CPU frequency，每个核心的使用率会单独显示。训练时能看到哪些核在满负荷跑，哪些核闲得流油。
绑核后，应该是你指定的那些核心高负载，其他核心基本空闲。如果所有核心都均匀忙，说明你可能误绑了整个NUMA节点且超线程也被算进去了。
4.3 用mpstat查看实时负载分布
mpstat -P ALL 1每行对应一个核心，%usr高说明计算繁忙，%sys高说明系统调用频繁。AI训练里如果%sys占比偏高，往往意味着有大量内存分配或GPU相关的系统调用，考虑优化内存分配策略。
4.4 在PyTorch脚本里打印所属NUMA节点
还可以在训练脚本中临时打一行日志，确认当前进程实际所在的NUMA节点：
import os import numa # 需要安装: pip install python-numa def print_numa_info(): pid = os.getpid() node = numa.numaset_run_node_mask() print(f"[PID {pid}] allowed NUMA nodes: {node}") print_numa_info()不过python-numa在部分环境里编译容易出问题。如果不想额外装依赖，直接检查/proc/<pid>/status中的Cpus_allowed_list和Mems_allowed_list：
grep -E "Cpus_allowed_list|Mems_allowed_list" /proc/<pid>/status输出清晰明了，不依赖Python库。
5. WSL2环境下的绑核指南
5.1 WSL2的NUMA拓扑和原生Linux不一样
现在很多人直接在Windows上用WSL2跑AI训练。WSL2底层是虚拟机，默认把宿主机的CPU资源全部暴露给VM，但NUMA拓扑不一定透传。在WSL2里执行lscpu，很可能看到：
NUMA node0 CPU(s): 0-15 NUMA node1 CPU(s): 16-31或者干脆只有一个NUMA节点。这取决于Windows宿主机是否开启了嵌套虚拟化透传，以及WSL版本。
如果WSL2里只有一个NUMA节点，那numactl --cpunodebind=0 --membind=0相当于没绑，因为它把所有资源都归到一个节点了。想恢复真实的NUMA拓扑，要检查Windows侧是否启用了nested virtualization，或者在.wslconfig中配置：
[wsl2] nestedVirtualization=true memory=64GB processors=16注意，processors=16表示给WSL2分配16个逻辑核，不是物理核也不是节点数。想要模拟多NUMA节点，需要你的CPU本身支持并且BIOS里没有关闭。
5.2 WSL2里绑核的常见坑
WSL2里numactl命令可能默认没装，先补上：
sudo apt install numactl然后执行numactl --hardware看拓扑。如果只有一个node，强行--membind=1会直接报错。
另外一个坑是WSL2的GPU显存访问走的是/dev/dxg，CPU与GPU之间的数据拷贝路径跟原生Linux不完全一样，整体数据管线的热点也可能不同。在WSL2环境里，绑核收益不像原生Linux那么稳定，但把数据加载线程绑到物理核上依然有正面效果，尤其是当Windows宿主机负载高的时候。
踩过几次坑之后，我自己的经验是：如果只是做实验、调模型，WSL2绑不绑核影响不大；如果要做正式训练，直接进原生Linux环境，绑核收益比WSL2明显得多。
5.3 WSL2里查看绑核是否生效
WSL2里同样可以用taskset -cp <pid>和grep Cpus_allowed_list /proc/<pid>/status查看。唯一要注意的是，WSL2的CPU编号可能与Windows任务管理器显示的逻辑核编号差一个偏移，别按Windows那边的编号去核对。
6. 常见问题与排查技巧实录
6.1 绑了核反而更慢了，怎么回事
绑核后性能下降，多半是你的进程没有独占这些核心。机器上还有别的服务在跑，比如监控agent、数据库、桌面环境，这些进程会把你的核心抢走。
排查方法：
# 查看CPU0-7上的进程 ps -eo pid,psr,comm | awk '$2 >= 0 && $2 <= 7'如果发现系统进程挤在你绑定的核心上，要么把系统服务挪到别的核心，要么把训练进程绑到一段更“干净”的核心区间。
另一个原因是超线程在捣乱。绑了包含超线程对的核心，两个逻辑核共享同一个物理核的执行单元，计算型任务抢资源抢得厉害。解决办法是只绑物理核中的一个逻辑核，让出超线程对给系统用。
6.2 GPU利用率看着高，训练速度却没提升
GPU利用率高只是表象，要区分是计算繁忙还是等待繁忙。用nvidia-smi dmon看：
nvidia-smi dmon -s pu -c 50列里关键看fb（显存使用）和sm（流处理器利用率）。sm高才是真的在算，fb高说明数据堆积在显存里了。如果sm不高但fb已经很高，说明模型计算主导，绑核帮不上太大忙，瓶颈在显存带宽或者算子本身。
6.3 numactl命令不存在或参数不对
有些精简系统没装numactl：
sudo apt install numactl # Debian/Ubuntu sudo yum install numactl # CentOS/RHEL安装后注意--cpunodebind和--physcpubind的区别。--cpunodebind需要NUMA节点编号，--physcpubind需要逻辑核心编号。AI训练建议用--cpunodebind=0 --membind=0这种节点级绑定，让系统在节点内自由调度核心。
6.4 多进程下内存分配不均衡
用numastat -p查看每个rank的进程内存分布时，如果发现node1的进程分配了node0的内存，说明--membind没完全生效。这种情况往往出现在torchrun的父进程先分配了内存，然后fork出子进程，子进程继承了父进程的内存分配结果。
解决办法是在脚本入口显式调用os.sched_setaffinity和numactl类库重新设置，或者尽量用脚本里的worker_init_fn、torch.cuda.set_device来绑定设备后，再重新分配内存。顺序很关键：先绑核，再初始化CUDA，再分配训练数据。
6.5 验证脚本里绑核失败的常见原因
最常见的原因是在真正的worker进程里没有执行绑定代码。torchrun --nproc_per_node=4会拉起4个子进程，如果你的代码只在主进程里调用了bind_process_to_node，子进程没有继承这个绑定。要在每个进程入口的最前面执行绑定逻辑，而且必须在torch.cuda.set_device之前执行。
6.6 无法确认哪些核属于哪个NUMA节点
懒人版方法：
ls /sys/devices/system/node/node0/cpulist ls /sys/devices/system/node/node1/cpulist这个路径下的内容直接给出节点对应的核心列表，比lscpu输出更明确。查看GPU挂载的节点：
cat /sys/bus/pci/devices/0000:01:00.0/numa_node设备编号从nvidia-smi --query-gpu=pci.bus_id --format=csv,noheader拿。注意有些老GPU驱动不给numa_node写有效值，会显示-1，这时候用nvidia-smi topo -m的CPU Affinity更靠谱。
7. 一套通用绑核脚本模板
平时我自己用的一套脚本，基本上拿到任何一台多卡Linux机器都能直接用。核心思路是探测GPU的NUMA归属，然后把训练进程绑到对应节点，同时把DataLoader worker分散到该节点的不同核心上。
#!/bin/bash # 绑定GPU worker到正确的NUMA节点 # 用法: ./bind_train.sh 4 0,1,2,3 NUM_RANKS=$1 GPU_LIST=$2 IFS=',' read -r -a GPU_ARR <<< "$GPU_LIST" for ((i=0; i<NUM_RANKS; i++)); do GPU_ID=${GPU_ARR[$i]} # 查询GPU挂在哪个NUMA节点 BUS_ID=$(nvidia-smi --query-gpu=pci.bus_id --format=csv,noheader -i $GPU_ID | sed 's/0000://;s/\.0$//') NUMA_NODE=$(cat /sys/bus/pci/devices/$BUS_ID/numa_node 2>/dev/null) if [[ "$NUMA_NODE" == "-1" || -z "$NUMA_NODE" ]]; then echo "警告: GPU ${BUS_ID} 没有有效的NUMA节点信息，跳过绑定" continue fi CPULIST=$(cat /sys/devices/system/node/node${NUMA_NODE}/cpulist) echo "GPU $GPU_ID -> NUMA节点 $NUMA_NODE, CPU核心: $CPULIST" # 启动一个rank，绑定到对应节点 CUDA_VISIBLE_DEVICES=$GPU_ID \ numactl --cpunodebind=$NUMA_NODE --membind=$NUMA_NODE \ torchrun --nproc_per_node=1 --master_port=$((29500 + i)) \ train.py --local-rank=$i & done wait这套脚本有几个地方按需改：训练脚本接收的--local-rank参数名可能不同，有的用--rank；master_port不冲突就行；机器人起来后注意清理进程。
生产环境里我更倾向用mpirun或者SLURM来统一管理核绑定，但大多数自己搭的机器上，上面这个脚本够用到退役。
8. 绑核之外，还有两个能和白折腾钱的配置
8.1 确认BIOS里没傻傻地关掉NUMA
有的服务器BIOS默认Memory Interleaving开启，此时系统把两根CPU上的内存统统交叉使用，物理上看起来就是一个大内存池，没有远端访问的概念。但对多路CPU训练来说，关掉interleave、让每个CPU紧贴自己的内存，整体性能通常更好。开机进BIOS，找NUMA Optimization或Memory Interleaving相关选项，设为NUMA/Enabled（取决于厂商喜欢用哪种叫法）。
8.2 CPU频率策略要调成性能模式
绑核优化了“去哪个核跑”，但如果核心本身一直在低频摸鱼，带宽还是上不来。多数Linux发行版默认的CPU调频策略是powersave或ondemand，对训练这种持续高负载并不友好。
# 查看当前策略 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor # 全部核心设为performance sudo cpupower frequency-set -g performance注意，设成performance后功耗会上升，风扇会更吵，机房或者家里都要做好散热。笔记本用户慎用，实在要跑训练还是外接电源并监控温度。
9. 验证加速效果：到底怎么测才是准的
不少人绑完核之后拿time一算总时长，发现“好像快了点”，但说不清快了多少。要严谨地验证，建议用固定的随机种子，跑固定轮数，把时间统计拆开来看。
data loading time：数据加载占总时长比例。compute time：模型前向反向计算时间。sync time：多卡通信时间。
PyTorch自带torch.profiler能把这些时间拆出来：
import torch from torch.profiler import profile, ProfilerActivity with profile(activities=[ProfilerActivity.CPU, ProfilerActivity.CUDA]) as prof: for i, batch in enumerate(train_loader): loss = train_step(batch) if i > 50: break print(prof.key_averages().table(sort_by="cuda_time_total", row_limit=15))对比绑核前后的结果，重点看DataLoader相关的耗时有没有下降。训练总时长虽然可能只有5%-15%的提升，但data loading这一项通常能砍掉30%以上。瓶颈越倾向于CPU侧，收益越明显。
10. 最后再多说一句自己的经验
掉过不少坑之后，悟出来一个道理：绑核这事不是“抄个命令就完事”，而是要理解你的机器到底是几路CPU、每张卡挂在哪个PCIe控制器下面、内存条怎么插。拓扑对了，命令就变得很机械：CPU绑到GPU对应的节点，内存绑到同一节点，worker分散到不同核心。只要这些做对了，训练速度的提升是可以稳定复现的。
如果你现在训练的机器经常出现GPU利用率波动、数据加载卡顿、或者多卡训练时各卡利用率不均，先从绑核查起，性价比极高。查完绑核再查内存频率和PCIe带宽，一步一步来，别一上来就怀疑显卡坏了。
这套方法在单卡机器上同样适用，哪怕只有一张卡，绑对NUMA节点也能减少数据加载的抖动。反正花不了几分钟，试试不吃亏。
