在 x86 GPU 服务器场景下，很多性能问题并不是显卡本身“跑不动”，而是 CPU 核心、内存、PCIe 和 GPU 之间的数据通路没有对齐。core-to-core-latency 这类工具的价值就在于：它能把“CPU 核心之间有多远”这件事量化出来，再结合 nvidia-smi topo -m、numactl、lscpu 等命令，可在 GPU 服务器上做更准确的 NUMA 亲和性、进程绑定和通信路径规划。
主要内容：
CPU 核心间延迟对 GPU 服务器的影响
现代 x86 服务器通常采用 NUMA 架构。每个 NUMA 节点有自己的 CPU 核心、本地内存和 PCIe 根复合体。CPU 访问本地内存通常更快，跨节点访问则需要经过 QPI/UPI 等片间互联，延迟更高、带宽也可能下降。
GPU 服务器尤其容易暴露这个问题：
所以，core-to-core-latency 测的是 CPU 核心间延迟，但它能间接反映 NUMA 拓扑、核心布局和缓存一致性路径对性能的影响。
core-to-core-latency 的作用与定位
core-to-core-latency 是一个用于测量 CPU 核心间通信延迟的基准工具。它会把测试线程绑定到指定核心，利用缓存一致性协议和原子操作，测量不同核心对之间的往返延迟。
它适合回答这些问题：
需要注意：它不是 GPU 带宽测试工具，也不能直接替代 NCCL 测试、GPU 显存带宽测试或网络延迟测试。更合理的用法是把它作为 CPU 拓扑和 NUMA 局部性的辅助诊断工具。
core-to-core-latency 的安装与使用
先安装 Rust 工具链，然后安装工具：
cargo install core-to-core-latency
运行默认测试：
core-to-core-latency
如果需要更高精度，可以增加迭代次数并导出 CSV：
core-to-core-latency 5000 --csv > c2c_latency.csv
测试时建议：
core-to-core-latency 的输出分析
输出通常会给出不同核心对之间的延迟，例如最小、平均、最大延迟，以及具体核心编号。
可以这样看：
不要只盯一个平均数。更关键的是看“哪些核心之间明显更慢”，以及这些慢路径是否正好出现在 GPU 数据通路附近。
core-to-core-latency 与 GPU 拓扑结合
单看 core-to-core-latency 还不够，建议配合 GPU 拓扑一起分析：
nvidia-smi topo -m numactl --hardware lscpu -e=CPU,NODE,SOCKET,CORE
nvidia-smi topo -m 会显示 GPU 与 GPU、GPU 与 NIC、GPU 与 CPU 亲和性以及 NUMA 亲和性。
常见连接类型含义如下：
结合方法包括：
nvidia-smi topo -m 确认 GPU 属于哪个 NUMA 节点；numactl --hardware 确认该 NUMA 节点包含哪些 CPU 核心；numastat 观察跨节点内存访问是否下降。典型排查思路
假设一台双路服务器上有 8 张 GPU，训练时发现多卡通信效率不稳定。可以先做拓扑快照：
lscpu numactl --hardware nvidia-smi topo -m
再运行核心间延迟测试：
core-to-core-latency 5000 --csv > c2c_latency.csv
如果发现某些核心对延迟明显更高，再检查 GPU 亲和性：
nvidia-smi topo -m
如果 GPU0–GPU3 亲和于 NUMA 0，而业务进程被调度到了 NUMA 1 的核心上，就可能出现跨节点访问。此时可以用 numactl 或 taskset 做绑定验证：
numactl --cpunodebind=0 --membind=0 your_command
如果绑定后 GPU 利用率更稳定、通信延迟下降，说明拓扑对齐确实带来了收益。反之，如果绑定后性能下降，可能是绑核范围过小、核心不足，或者绑定到了离 GPU 更远的节点，需要重新对照拓扑验证。
注意事项
使用时机
以下场景比较适合引入 core-to-core-latency：