达拉斯 GPU 物理机跑 CUDA 程序 OOM 了，怎么看是显存不够还是 NCCL 通信炸了

在 达拉斯 8×H100 物理机 上跑分布式训练时，程序崩溃报 OOM（Out of Memory）。但这个 OOM 是显存真的不够，还是 NCCL 多卡通信出了问题？云数方舟 教你一步步排查。

第一步：用 nvidia-smi 看显存占用。崩溃时快速执行：
nvidia-smi
看 Memory-Usage 列。如果某张卡显存接近或达到 100%（如 81500MiB / 81920MiB），说明是显存真的不够。如果显存只用了 20-30% 就 OOM，那大概率是 NCCL 通信问题。

第二步：设置 NCCL_DEBUG=INFO。运行训练前：
export NCCL_DEBUG=INFO
export NCCL_DEBUG_SUBSYS=ALL
重新运行程序，日志会输出 NCCL 的初始化、通信、同步信息。如果出现：
– NCCL WARN Connect to XXX failed → 网络连通性问题。
– NCCL WARN Timeout → GPU 间通信超时（可能 NVLink 故障或 PCIe 问题）。
– NCCL INFO Trees → 正常建立通信树。

第三步：CUDA_LAUNCH_BLOCKING=1 定位具体算子。
export CUDA_LAUNCH_BLOCKING=1
这会让 CUDA 内核同步执行（每次 kernel launch 都等待完成），报错信息会精确到是哪个算子 OOM。默认异步模式下，报错位置可能滞后，误导排查方向。

第四步：检查 NCCL 通信网络。在 8×H100 上，NCCL 优先使用 NVLink/NVSwitch（GPU 间），其次使用 PCIe，最后使用网络（如果跨节点）。单机内不应走网络。如果日志显示 NCCL 尝试通过网卡（如 eth0）通信，说明 NVLink 配置有问题。检查：
nvidia-smi topo -m → GPU 间应为 NV# 或 SYS（跨 CPU）。
ls /dev/nvidia* → 应有 /dev/nvidia0 到 /dev/nvidia7。

症状	可能原因	排查命令
显存 100% + OOM	Batch size 太大 / 模型太大	nvidia-smi
显存 30% + OOM	NCCL 通信失败	NCCL_DEBUG=INFO
卡在初始化	GPU 拓扑/NVLink 问题	nvidia-smi topo -m
特定算子 OOM	算子中间变量太大	CUDA_LAUNCH_BLOCKING=1

行动建议。在 达拉斯 GPU 物理机 上跑分布式训练前，先用 nvidia-smi dmon 监控 GPU 利用率和显存，确认 NVLink 带宽正常（> 400 GB/s）。如果 NCCL 通信持续报错，尝试：export NCCL_IB_DISABLE=1（禁用 InfiniBand，强制用 NVLink/PCIe），或 export NCCL_SOCKET_IFNAME=lo（强制走本地回环，适用于单机）。记住：OOM 不一定是显存不够——在 8×H100 的 640GB 总显存面前，大部分 OOM 其实是通信配置错误。

---

📌 查看云数方舟达拉斯 GPU 方案：
云数方舟官网 ｜ 达拉斯显卡服务器（8×H100）

本文由 云数方舟 技术团队原创发布，转载请注明出处。