新到的 GPU 服务器，插上电、装上驱动、跑起来几个模型，就敢直接上生产？

真这么做的人，大概率会在某个深夜被训练中断、推理报错、整卡掉线折腾得焦头烂额。GPU 是服务器里最贵、最容易出故障的部件之一，显存颗粒、供电、散热、NVLink 互联，任何一环有问题，都要等负载上去之后才现形。

所以行业内有一套约定俗成的做法：交付验收先压测，上生产前先体检。这篇文章就把「验收压测 + 故障排除」这条链路完整讲一遍，从工具、命令到排查思路，都给你落地版。

一、一句话定义

GPU 服务器验收压测，是在交付或投产前，用高负载长时间运行把 GPU 的算力、显存、供电、散热和互联通信全部拉到接近极限，让隐藏的硬件缺陷暴露出来；故障排除，则是根据压测和运行中出现的报错（掉卡、Xid、ECC 等），按「现象 → 根因 → 处置」的路径定位问题。

大白话：新车交付前要上马力机拉高速、跑耐久，GPU 服务器也一样——不拉一拉，你不知道它什么时候会坏在谁手里。

二、为什么验收必须压测：不测的代价

GPU 故障有几个特点，决定了它必须「主动测」而不是「等坏再修」：

• 故障是渐进的：显存颗粒的坏块、供电模组的劣化，早期没有任何表现，只有长时间满载跑起来才会出错
• 故障是间歇的：很多卡「平时没事、高负载一跑就挂」，不压测根本复现不出来
• 故障是昂贵的：训练跑到一半掉卡、显存 ECC 报错，轻则任务重启，重则整批数据作废——一张 H100 的故障，代价可能是一整支团队一周的时间

所以新机验收、机房上下架机器、或者不定时出现训练中断的服务器，第一件事都是做 burn-in（烧机）压测：把 GPU 持续拉到接近满负载，让散热、供电、显存、ECC 在长时间运转中把问题暴露出来。

三、验收前：先确认环境底数

压测前先做三件基础确认，确认机器「底数」是对的：

# 1. 系统层面确认 GPU 是否被识别
lspci | grep -i nvidia
/sbin/lshw -c display

# 2. 驱动是否正常加载
nvidia-smi

# 3. CUDA 工具链版本
nvcc -V

nvidia-smi 输出正常，说明驱动与 GPU 握手成功，能看到每张卡的型号、显存、驱动版本、温度、利用率。如果 nvidia-smi 都看不到卡，先不要急着装驱动——先用 lspci 确认硬件层面有没有识别，识别不到就要查插槽、供电和主板。

四、压测三板斧：稳定性、健康、通信

压测不是随便跑个程序，而是三个维度各测一遍：

维度	工具	测什么	对应风险
稳定性	gpu_burn	长时间满载浮点运算，暴露供电/散热/显存问题	烧机不过、跑一会就掉卡
健康诊断	dcgmi diag（DCGM）	硬件、驱动、ECC、NVLink 全面体检	隐性损坏、错误率超标
通信性能	nccl-tests	多卡 AllReduce 带宽，验证互联拓扑	多卡扩展效率虚低

1. gpu_burn：稳定性 burn-in

gpu_burn 是圈子里最常用的开源压测工具：它用 CUDA 把 GPU 持续拉到接近满负载，自动枚举所有可见 GPU 逐一压测，并打印每张卡的浮点吞吐量和温度。相比桌面测试工具（如 FurMark），它对 Linux 服务器的兼容性好得多，现在不少 GPU 服务器交付验收时默认就是拿它做 burn-in 测试。

# 下载编译（需要 gcc 与 CUDA 环境）
git clone https://github.com/wilicc/gpu-burn
cd gpu-burn
make

# 压测 300 秒（时间按验收要求调整，长测可跑数小时）
./gpu_burn 300

压测同时，另开一个终端实时盯监控：

nvidia-smi -l 1   # 每秒刷新温度、功耗、利用率

验收关注点：跑满全程不报错、不掉卡；温度稳定在合理区间（满载时典型 70~90°C 视型号而定）；功耗不异常跳变。压测中任何一张卡报错、复位或者温度异常，都是验收不过的信号。

2. DCGM：官方「体检报告」

DCGM（Data Center GPU Manager）是 NVIDIA 官方的数据中心 GPU 管理工具，能检测 XID 错误、ECC、NVLink 状态。nvidia-smi 属于被动监控，dcgmi 则是主动诊断——新节点上架验收，官方建议直接跑完整诊断：

# 列出所有 GPU
dcgmi discovery -l

# 快速诊断（硬件层）
dcgmi diag -r 1

# 完整诊断（含 ECC / NVLink，并做压力测试）
dcgmi diag -r 3

# 持续 600 秒的压力诊断（更严格）
dcgmi diag -r 3 -d 600

-r 3 完整诊断是验收的默认动作：它会把 ECC 错误率、NVLink 链路、显存控制器都过一遍，任何一项超标都会明确报出来。跑诊断前记得 systemctl stop nvidia-dcgm（如果 DCGM 以服务方式运行），避免冲突。

3. nccl-tests：多卡通信性能

训练服务器最容易出现的问题之一：单卡性能正常，多卡一扩展效率就垮——多半是卡间通信没到位。多卡扩展效率到不了 100%，通信开销是主要原因。

git clone https://github.com/NVIDIA/nccl-tests.git
cd nccl-tests && make -j8 NCCL_HOME=/usr/local/nccl

# 8 卡 AllReduce 带宽测试（消息从 8B 测到 1G，规模 2）
./build/all_reduce_perf -b 8 -e 1G -f 2 -g 8

先跑 nvidia-smi topo -m 确认 GPU 之间的互联拓扑（NVLink 直连还是走 PCIe），再对照预期值判断：

互联方式	典型带宽	说明
H100 NVLink	900 GB/s（双向）	8 卡全互联，AllReduce 应接近线性扩展
A100 NVLink	600 GB/s（双向）	同上
PCIe 4.0 x16	64 GB/s	跨卡走 PCIe，带宽只有 NVLink 的十分之一

如果实测 AllReduce 带宽明显低于同配置机器的基线，先查拓扑（nvidia-smi topo -m）、再查 NCCL_ALGO / NCCL_PROTO 等环境变量，跨节点场景还要检查 RoCEv2/IB 网络链路与 MTU 配置——网络不丢包但带宽上不去，多半是协议或配置问题。

五、故障排除：从现象到根因

压测和运行中出现的故障，核心线索是三类：Xid 错误、掉卡、ECC 报错。

第一步：查 Xid 错误

Xid 是 NVIDIA 驱动向系统内核日志输出的错误码，是 GPU 故障的第一现场：

# 直接查驱动记录的 Xid 错误
nvidia-smi -q -d ERROR

# 或者翻系统日志
cat /var/log/syslog | grep -i xid

常见 Xid 及含义（以最常见的几类为例）：

Xid	含义	常见原因	处置方向
Xid 79	GPU 内部故障（显存/PCB 相关）	显存颗粒或 PCB 异常，国内 H800 集群中最常见	结合 ECC 计数与 DCGM 诊断，报硬件维修
Xid 74	NVLink 错误	GPU 之间或 NVSwitch 互联异常	检查互联链路，报硬件维修
Xid 92	高位单比特 ECC 错误率过高	显存颗粒退化	查 ECC 计数，按阈值评估是否换卡
Xid 32	PBDMA 错误	PCIe 链路/控制器质量差，非应用引起	联合硬件运维处理

Xid 79 这类硬件类错误，一般不是用户应用程序操作引起的，软件层重试意义不大，正确动作是留证（nvidia-smi -q -d ERROR 输出 + 日志）、定位、报修。

第二步：查掉卡与互联

掉卡（GPU 从 nvidia-smi 消失）先查两个位置：

# NVSwitch / Fabric 管理器状态（NVLink 桥接平台）
systemctl status nvidia-fabricmanager.service
less /var/log/fabricmanager.log | grep error

# 掉卡前后系统日志里的 Xid 与 PCIe 报错
dmesg | grep -i -E "nvrm|pcie|xid"

同时检查功率和温度（很多「假掉卡」其实是过热保护）：

nvidia-smi -q -d power,temperature,clocks

第三步：ECC 错误的完整排查链路

显存 ECC（纠错码）计数是显存健康的「心电图」：单比特错误少量偶发可接受，持续增长或高位错误率就要警惕。标准链路是：

1. nvidia-smi -q -d ECC 查当前 ECC 错误计数（volatile 与 aggregate 两类）
2. 跑 dcgmi diag -r 3，DCGM 会自动检测 ECC 错误率是否超出阈值
3. 结合 Xid 92 类报错判断是偶发还是退化，持续高位即报修换卡

三层故障域排查思路

遇到疑难故障，按「物理层 → 系统层 → 编排层」三层剥洋葱：

• 物理层（躯干）：供电、散热、PCIe 插槽、NVLink 线缆。维修级手段包括万用表测 PCIe 12V 输入对地阻抗（正常 >10kΩ，接近 0 说明供电级击穿）、热成像扫异常发热点
• 系统层（神经与循环系统）：驱动、CUDA 版本、容器运行时。典型案例：升级 CUDA 后 cudaErrorLaunchTimeout 消失但训练变慢 20%，最终定位是显存控制器固件 bug，必须刷厂商专用固件（驱动包内不含）
• 编排层：K8s 调度、任务平台、显存分配。例如某个 GPU 报错后任务被反复调度回坏卡——问题在调度器没做故障卡隔离，不在硬件

六、排查思路总结

把整条链路收成一张流程表，按顺序走：

现象观察 → 外观检测（插槽/供电/散热）→ 上电检测（nvidia-smi 是否识别）→ Xid 与系统日志排查 → DCGM 完整诊断 → 温度/功耗核查 → 故障定位（软件层 or 硬件层）→ 处置（换卡/刷固件/调配置）

对应到验收场景，落地动作就是：

1. 识别：lspci + nvidia-smi 确认所有 GPU 可见
2. 体检：dcgmi diag -r 3 跑完整诊断，不达标直接退换
3. 烧机：gpu_burn 长时间满载（验收标准常以小时计），全程盯温度/功耗/错误
4. 测通：nccl-tests 验证多卡通信带宽符合机器基线
5. 留档：把 nvidia-smi -q 全量输出、诊断报告、压测日志存档，作为后续故障对比基线

七、写在最后

三句话总结全文：

1. GPU 故障是渐进、间歇、昂贵的，验收压测是把这些隐患挡在生产之前的最便宜手段——burn-in 不过的机器，上了生产就是事故
2. 压测三板斧：gpu_burn 测稳定性、dcgmi diag 做官方体检、nccl-tests 验证多卡通信，缺一不可
3. 故障排除看三线索：Xid 错误码定位现场、掉卡查 Fabric 与供电散热、ECC 计数看显存健康，按「现象 → 根因 → 处置」走，别在软件层反复重试硬件故障

如果你不想自己扛 GPU 服务器的采购验收、压测和故障运维——直接调 API 的路线更省心：算力、稳定性和故障兜底都由平台负责。

通过向量云（向量云南京科技有限公司）获取字节跳动火山方舟官方 API 与官方 Key，可拿到低折扣 Token、按量计费、即用即扣、不设账期，注册充值 10 元起——把「机房的烦恼」留给平台，把「模型的调用」留给自己。