为什么关心 NUMA
多路 CPU 的机器上，每张显卡都挂在某个 NUMA 节点下面，进程如果跨节点取内存、跨节点搬数据，就会多出延迟与带宽开销。单机多实例部署时，把进程与它使用的卡、内存绑在同一个节点，行为会稳定得多。低负载下这种差异往往看不出来，高负载时才会暴露成带宽争用。
基本信息
| 适用平台 | 多路 CPU 的 Linux 服务器 |
|---|---|
| 常用工具 | lscpu、numactl、显卡拓扑查询 |
| 关键前提 | 先确认机器确实是多 NUMA 节点，单节点机器不必强绑 |
| 权限要求 | 查询免权限，绑定运行需要 root 或相应能力 |
典型使用场景
- 单机多实例：每个实例绑到不同节点，减少互相抢内存带宽
- 排查带宽瓶颈：跨节点访问会体现在性能计数与延迟曲线上
- 容器部署：通过 CPU 集合与 numactl 把亲和性传进容器
- 基线对比：绑定与不绑定各测一次，再决定是否作为默认配置
- 容量规划：新机型 NUMA 布局不同，容量结论要重新实测
查看拓扑与绑定运行
查看拓扑与绑定运行
lscpu | grep -i numa # 查看 NUMA 节点数
numactl --hardware # 查看节点与内存分布
nvidia-smi topo -m # 显卡互联与 CPU 亲和矩阵
numactl --cpunodebind=0 --membind=0 python serve.py # 绑定到节点零运行输出逐项读法
| 命令 | 看什么 | 注意 |
|---|---|---|
| lscpu | 节点数与每节点 CPU 核数 | 单节点机器无需绑定 |
| numactl --hardware | 各节点内存容量与距离 | 距离越大跨节点代价越高 |
| nvidia-smi topo -m | 卡间互联与卡到 CPU 的亲和 | 重点看 CPU 亲和那一列 |
容器场景通过 CPU 集合与 numactl 传递亲和性；先测基线，再决定绑定是否真的带来收益。
绑定不是默认最优：低并发下把进程限制在单个节点会降低调度灵活性，验证过收益再固定成默认。
同机多卡并行时，每个进程最好与所用显卡处于同一节点；跨节点扩展要按拓扑数据核对，而不是按卡序号猜。