挂起挂在哪一步
张量并行或流水并行的推理服务，挂起大多发生在初始化或某一次集合通信上：所有进程都在等一个不会来的对端。排查第一步是让通信库把过程打出来，看清卡在建立连接、选择链路还是某次集合通信；第二步是核对卡间拓扑与网络状态；同时给通信配上超时，让失败以报错形式暴露，而不是无限等待。
基本信息
| 适用平台 | Linux 下的单机多卡与多机部署 |
|---|---|
| 调试开关 | 通信库的调试级别环境变量，如输出详细初始化信息 |
| 核对工具 | 显卡拓扑查询、网卡与链路状态查询 |
| 常见配置项 | 网卡选择、通信超时、设备可见性变量 |
| 恢复动作 | 按预案整体重启全部进程，不要只重启一部分 |
典型使用场景
- 启动即挂：核对各进程可见设备数是否一致
- 跑到某一步才挂：多为负载相关，查拓扑与掉队的进程
- 多机环境：先确认网卡与链路状态正常
- 加超时：把无限等待变成可观测的失败，便于快速恢复
- 复现记录：记下并发、输入长度与挂起前最后一条日志
调试与证据
调试与证据
NCCL_DEBUG=INFO <启动命令> 2>&1 | tee /tmp/nccl.log # 仅排查窗口内开启
nvidia-smi topo -m # 核对卡间互联方式
grep -i -E 'timeout|error|unhandled' /tmp/nccl.log | tail
env | grep CUDA_VISIBLE_DEVICES # 核对设备可见性卡点分段
| 卡在哪 | 常见原因 | 核对方法 |
|---|---|---|
| 通信库初始化 | 可见设备数不一致或端口冲突 | 比对各进程的环境变量与日志时间戳 |
| 建立连接 | 网卡选择错误、链路异常 | 查网卡状态与链路错误计数 |
| 集合通信中 | 拓扑不匹配或单个进程掉队 | 核对拓扑矩阵与各进程进度 |
| 结束后不返回 | 同步点缺失或应用层逻辑问题 | 结合应用日志与抓栈确认 |
详细调试日志量大且有性能开销，只用于排查窗口，结束后关掉。
给集合通信设置超时：长时间无进展时框架能主动报错退出，恢复动作才有可能做成自动化。