本文由 PowerShell 中文社区团队整理，内容来自 NVIDIA B300 / H200 / H100 等整机验收与长稳压测项目的现场交付记录。作者邓鹏，PowerShell 中文社区创始人，深圳市研创信息科技有限公司 CTO，51CTO 认证讲师，长期从事 AI 算力服务器验收、NVLink 互联验证与 7×24 长稳压力测试。文中参数为公开规格参考，实测数值请以同批次健康机为基线；落地时仍需结合机房供电、散热条件与验收标准评估。

目录

• 一、验收比压测更严格：三个真实现场
• 二、主流高端 AI 算力平台对比与列示
  • 2.1 规格对比总表
  • 2.2 分组解读：四类平台的不同验收重心
• 三、验收前的四项准备
• 四、六阶段验收流程与判据
• 五、12 条验收现场注意事项
• 六、争议与责任划分：验收单到底在保护谁
• 七、验收报告模板
• 八、结语

一、验收比压测更严格：三个真实现场

压力测试是手段，验收是目的。两者的差别在于：压测只需要"跑出数据"，验收还需要"数据能签字"。签字意味着责任转移——从这一刻起，设备状态由使用方承担。

三个我们亲历的现场，说明了为什么验收标准不能松：

现场一：8 卡全在，但有一条 NVLink 只跑了一半速率。
设备到货通电，nvidia-smi显示 8 张卡全部正常，验收当天签字。两周后分布式训练上量，AllReduce 性能只有预期的一半，nccl-tests一跑才发现某两条卡对的 P2P 带宽明显偏低。追溯时厂商答复"交付时nvidia-smi正常"，但nvidia-smi本身并不检查链路速率——这一项从来不在默认检查范围里。

现场二：单机 IB 测试全绿，跨机带宽腰斩。
交换机某个端口协商降速，单机自测（自己 ping 自己、自己打自己）永远发现不了。直到多机训练任务开始 hang，才用两机对接测出问题。这类故障在所有 AI 集群交付里占比很高，因为"跨机满带宽长时间"这个条件最容易漏。

现场三：第七天凌晨掉电。
前六天长稳一切正常，第七天机柜整体掉电。查 BMC SEL 日志发现是电源冗余配置与机柜供电容量不匹配，GPU 满载瞬间的浪涌把整柜拉闸。这个问题在开箱验收阶段完全看不出来，只能靠整机满负载 + 供电容量核算提前排除。

这三个现场的共性：问题都不在"设备是否通电"层面，而在"负载是否达到真实工况"层面。验收的价值，就是把负载推到真实工况，然后看数据说话。

二、主流高端 AI 算力平台对比与列示

2.1 规格对比总表

下表为公开规格参考，用于确定验收基线量级（不同厂商整机配置、功耗策略差异较大，实际以到货机型规格书为准）：

整机集成侧，浪潮 NF5688 系列、超聚变 FusionServer G 系列、Supermicro SYS 系列、Dell PowerEdge XE 系列、新华三等厂商均提供 4 卡/8 卡 HGX 机型，方法论通用，差异集中在 BIOS/BMC 功耗策略、散热方案（风冷/液冷）与网络拓扑。

2.2 分组解读：四类平台的不同验收重心

第一类：机架级超大规模方案（GB300 NVL72 / GB200 NVL72）

这类方案不是"一台服务器"，而是"一个机柜 = 一个计算单元"，72 张 GPU 通过 NVSwitch 全互联。验收重心从单机转向机架：

• NVSwitch 全互联的带宽一致性（不是点对点，而是任意卡对之间）；
• 液冷系统的流量、压力、快接头状态与漏液检测告警联动；
• 整柜功耗与配电容量核算（这是最容易出问题的环节）；
• 机架级 RDMA 网络与 NCCL 大规模集合通信（72 卡规模的 AllReduce 需要专门的拓扑验证）。

第二类：8 卡 HGX 训练机型（B300 / B200 / H200 / H100）

当前交付量最大的一类，也是本文六阶段流程的主要对象。共同重心：单卡满载稳定性、NVLink P2P 带宽矩阵、700W~1400W 功耗墙下的散热能力。型号越新，功耗密度越高，散热验证的权重要相应加大。

第三类：存量卡（A100 / A800 / H800）

新机交付少，但大量仍在服役，更多出现在"扩容混插"和"二手/翻新设备入库"场景。验收重心转向：显存 ECC 错误历史计数、风扇与散热器老化（转速是否还能拉满）、NVLink 链路协商状态。混插场景还要额外确认固件版本一致性和 NCCL 拓扑兼容性。

第四类：国产与异构方案（昇腾 910B / MI300X）

工具链不同（npu-smi、rocm-smi），但验收逻辑一致：满载温度、互联带宽、长稳一致性、驱动与框架版本匹配。这类方案特别要注意软件栈版本矩阵——CANN 或 ROCm 版本与训练框架的对应关系，验收时必须写入报告，否则后续升级会踩坑。

三、验收前的四项准备

3.1 一致基线：把"出厂状态"固化下来

• 逐卡记录序列号、VBIOS 版本、GPU 固件；
• 记录 BMC/iDRAC 版本与 SEL 日志起点（建议清空后重新计数）；
• 记录网卡固件、交换机端口配置与线缆编号；
• 统一驱动/CUDA/NCCL 版本，验收期间禁止任何变更。

这一套基线是后续所有争议的唯一判据。没有基线，"设备交付时是好的"这句话你无法反驳。

3.2 环境准备：三个容易被忽略的前提

1. 机柜供电容量核算：按整机满载功耗 × 台数 × 1.2 冗余系数核算，确认 PDU 与上级配电不成为瓶颈；
2. 进风温度：确认机房冷通道温度在设计范围内（一般 18~27℃），否则后续所有温度数据都不可比；
3. 网络链路：确认 IB/RoCE 交换机端口速率、光模块型号与线缆一致性，跨机测试的对端机器提前就位。

3.3 监控先行

DCGM Exporter + Prometheus + Grafana 必须在压测开始前跑起来，同时接入 BMC 的电源、风扇、进风温度数据。没有时序数据的验收，等于没验收。

3.4 验收标准前置成文

在设备到货前就与厂商/集成商书面确认：判定通过的阈值是什么（温度上限、ECC 是否零容忍、NCCL 带宽下限、长稳时长）。避免出现"跑完了再讨论算不算合格"的被动局面。

四、六阶段验收流程与判据

① 到货检查 → ② DCGM 深度诊断 → ③ 逐卡满载与显存压测 → ④ 互联与网络验证 → ⑤ 整机联合负载 → ⑥ 7×24 长稳 → 验收报告

关键命令示例：

# 阶段②：官方深度诊断dcgmi diag-r3# 阶段③：逐卡烤机（依次换 CUDA_VISIBLE_DEVICES）CUDA_VISIBLE_DEVICES=0./gpu_burn600nvidia-smi dmon-spucvmet-d5-oTD>card0_monitor.log# 阶段④：互联三件套nvbandwidth-tdevice_to_device_memcpy_read ./build/all_reduce_perf-b8G-e8G-g8ib_write_bw-dmlx5_0--report_gbits-R

五、12 条验收现场注意事项

这一节是全文最值得收藏的部分，每一条都来自现场踩过的坑。

1. 不要先升级驱动。
用到货自带版本跑完基线再评估升级。新驱动配新 CUDA、新 NCCL 的组合问题在 Blackwell 平台上并不少见，一旦升级后出现异常，责任立刻变得模糊。

2. GPU 必须逐卡压，不能 8 卡一起跑。
混跑会把单卡问题稀释在平均值里。8 卡平均温度 78℃ 听起来很正常，实际可能是 7 张 76℃、1 张 92℃。

3. 温度看"平台期"，不看瞬时峰值。
健康卡满载 10~15 分钟进入温度平台，波动应在 3℃ 内。仍在缓慢爬升的，先查散热器安装与导风罩方向，不要急着怀疑 GPU 本身。

4. ECC 看趋势，不看单次绝对值。
少量可纠正错误不一定致命，但压测前后计数增长过快，就是 HBM 颗粒隐患的前兆。double-bit 错误零容忍，出现即报修。

5. 带宽要画成矩阵，不能只看平均值。
8×8 的 P2P 带宽做成热力图，一条离群链路比"平均带宽不达标"更有诊断价值，也更难被厂商以"整体达标"为由驳回。

6. 网络测试必须跨机、满端口、长时间。
单机自测发现不了交换机端口降速和光模块问题。这一条是 AI 集群验收里最高频的翻车点。

7. 集合通信要跑到实际规模。
8 卡验收用 8 卡规模跑 NCCL，机架级方案要跑到 72 卡规模。用小规模数据推断大规模表现，在 NVSwitch 拓扑下是不成立的。

8. 液冷机型单独验证，不能套用风冷经验。
冷却液流量、供回水温度、快接头密封、漏液检测告警联动，四项缺一不可。风冷经验直接搬到液冷机架，是近几年新交付场景里最大的一类事故来源。

9. 整机联合负载不可省。
GPU 独烤通过不代表整机没问题。CPU 满载后抢电、内存带宽争用、NVMe 写满缓存，这些问题只在联合负载下暴露。

10. 功耗与配电要双向核对。
既看 GPU 是否达到功耗墙（长期只有 70% 以下说明在异常降频），也看整机功耗是否超出机柜配电预算。两者方向相反，都要看。

11. 时序数据必须留档，保留期覆盖整个质保期。
Prometheus 数据、dmon 日志、dcgmi 报告、BMC SEL，全部按机器序列号归档。后续任何一次故障争议，这份数据是唯一能自证的东西。

12. 验收单上的每一行都要有数据支撑。
写"运行正常"而没有对应截图和日志的条目，等于没测。签字前逐项核对：这条结论的数据在哪？

六、争议与责任划分：验收单到底在保护谁

现场最常见的三类争议，以及验收阶段可以做的预防：

核心原则一句话：验收不是走流程，是把"设备状态"从一个模糊描述变成一组可追溯的数据。数据在谁手里，话语权就在谁手里。

七、验收报告模板

有条件通过的项必须写明"整改内容 + 复测时间 + 未整改的后果承担方"，否则等于默认豁免。

八、结语

高端 AI 服务器的验收，本质上是一次"用数据换确定性"的交易：你付出几天时间，换来的是未来三年出事时手里有据可依。

一条经验总结送给大家：所有高价值、低容错的交付，胜负在动手之前就已经定了——基线够不够全，标准够不够硬，数据留没留档。

关于作者 / 出品

本文由 PowerShell 中文社区团队推出。作者邓鹏，PowerShell 中文社区创始人，深圳市研创信息科技有限公司 CTO，西安交通大学计算机专业毕业，51CTO 认证讲师（2021 年度十大新锐讲师）。

社区团队承接企业底层 IT 基础设施的技术服务，主要包括：AD 域控的新建部署、跨林迁移、域名更换、跨境 RODC 部署、域故障修复与账号权限治理；Exchange 邮件系统的版本升级迁移、数据库恢复、传输与安全排障；VMware 平台迁移与 Citrix CVAD 云桌面部署、性能调优；XSKY、华为、浪潮、深信服等分布式存储的故障定位与服务器 RAID 数据恢复；NVIDIA B300 / H100 算力服务器的整机验收、NVLink 互联验证与 7×24 长稳压力测试。同时提供系统迁移、内网安全加固、信创适配、PowerShell 自动化脚本定制与运维实战培训。

服务按"先评估、后动手"的流程推进：前期完成现状调研与风险评估，交付环境健康检查报告、实施方案与完整回滚预案，实施后提供验收文档；生产环境的高危变更，一律在备份与回滚方案确认后执行。技术服务不含硬件设备采购。

完整版《NVIDIA B300 Blackwell 服务器验收与压力测试》标准化方案及验收报告模板，可在 PowerShell 中文社区官网查阅：www.powershell.com.cn

本文首发于 CSDN，由 PowerShell 中文社区团队出品，转载请注明作者邓鹏与出处。