上架自检的三步
新机器或换卡后，不用等业务部署才知道卡好不好。三步能覆盖硬件、驱动与框架栈的常见问题：先确认设备识别与驱动版本，再用真实矩阵运算验证计算路径，多卡机器再补一次通信基线。每一步都有明确的通过判据，比只看一眼设备列表扎实得多。
单卡与计算自检
单卡与计算自检
# 1) 设备识别与驱动版本
nvidia-smi -L
nvidia-smi --query-gpu=name,driver_version,memory.total --format=csv
# 2) 真实矩阵运算：验证计算单元与显存可用
python - <<'PY'
import torch
a = torch.randn(4096, 4096, device='cuda')
b = a @ a
print('matmul ok', float(b.sum()), torch.cuda.get_device_name(0))
PY
# 3) 多卡机器接着跑通信基线（见 nccl-tests 相关条目）检查项与判据
| 检查项 | 通过判据 | 异常表现 |
|---|---|---|
| 设备识别 | 设备数量与卡型符合采购单 | 少卡或名称不符 |
| 驱动版本 | 与框架要求一致 | 版本过低导致容器或框架报错 |
| 显存容量 | 与规格一致 | 容量偏低说明看错卡或子型号不符 |
| 矩阵运算 | 计算成功且结果可打印 | 报内核不可用或运算异常 |
| 多卡通信 | 带宽在合理区间 | 带宽远低于链路规格 |
典型使用场景
- 新机验收：在交付前跑一遍，问题当场暴露
- 换卡后复核：确认备件规格与性能与原卡一致
- 驱动或工具链升级后：重新跑自检，确认没有回退
- 扩容前预检：批量脚本逐台执行，结果汇总成清单
- 故障恢复确认：处理后重新验证计算与通信链路
多卡机器在一轮矩阵运算后补一次通信基线：计算正常但通信异常时，单卡测试是完全看不出来的。
自检脚本要能一键批量执行并把结果落到文件：多台机器逐台手工跑，结论容易丢失，也难与其他批次对比。
自检通过不代表长稳可靠：新卡投产前建议跑一段满载测试，观察温度与降频情况，否则问题会在业务高峰才暴露。