P2P 与卡间通信
多卡之间通信是否支持 PCIe 点对点直传（P2P）影响很明显：数据中心卡通常支持，部分消费级卡在硬件或驱动层面被限制。不支持 P2P 时，卡间数据要经主机内存中转，延迟与带宽同时变差，张量并行、多卡共享缓存这类通信密集的负载对这一点最敏感。
基本信息
| 考察对象 | GPU 间 P2P 能力与拓扑距离 |
|---|---|
| 查看命令 | nvidia-smi topo -m |
| 拓扑标识 | NV#、PIX、PXB、PHB、SYS |
| 框架侧确认 | torch.cuda.can_device_access_peer |
| 受影响负载 | 张量并行、多卡通信吞吐 |
典型使用场景
- 多卡部署前做插槽与选卡规划，先看拓扑再定并行策略
- 张量并行吞吐不达预期时，核对通信是否真的走了直连路径
- 容器或虚拟化环境下确认 P2P 是否被上层禁用
- 容量规划时判断是否需要 NVLink 机型而不是堆 PCIe 卡
- 旧机器上提示可以多卡并行，实际扩展效率远低于账面
- 同型号不同批次或固件的卡混插时逐对核对，避免表现与预期不符
检查拓扑与 P2P 能力
检查拓扑与 P2P 能力
nvidia-smi topo -m # 看卡间是 NV#、PIX/PXB、PHB 还是 SYS
nvidia-smi topo -p2p r # 直接查 P2P 读能力矩阵（部分版本支持）
python -c "import torch; print(torch.cuda.can_device_access_peer(0,1))" # 框架视角是否可用
# 结论要三处一致：拓扑、能力矩阵、框架实测，缺一处都可能误判拓扑标识怎么读
| 标识 | 含义 | 通信代价 |
|---|---|---|
| NV# | 走 NVLink 互联 | 最低 |
| PIX | 同一 PCIe 交换芯片下 | 低 |
| PXB | 经过 PCIe 交换树 | 较低 |
| PHB | 经过主机桥 | 中等 |
| SYS | 跨 NUMA 插槽 | 高 |
组卡时把张量并行的多张卡放在同一 PCIe 树或同一 NVLink 域内，是最省事的优化；跨 NUMA 插槽做 TP 常表现为通信占比高、扩展效率差。
虚拟化与部分消费卡会屏蔽 P2P：nvidia-smi 显示支持但框架调用失败时，先查驱动与虚拟化层配置，再决定是否改并行方案。
验证方式：跑一次小规模集合通信微基准，把实测带宽与拓扑表里的预期路径对照，两条信息一起看比单看标识可靠。