-j JSON 开关，或「DCGM 绿灯就能开 RMA」。上海滔涵实业（TAOHAN）协助国内交付冻结验收包——本页不公开渠道价。nvbandwidth 深 CLI 见对篇带宽验收文。要点速览
按目标选工具：DCGM 机内分诊，nvbandwidth 链路拷贝，nccl-tests 集合通信，gpu-burn 机房浸泡，NVIDIA Field Diagnostic 走 RMA。前四件缺一则到货验收不完整；没有 fieldiag.log 且未开 ECC 的 RMA 不完整。适合 HGX/B300 类政企签收；不适合当报价，也不适合把 DCGM 绿灯当成 NVIDIA RMA 资格。下文 B300 通过线为模拟样例，待与 datasheet 确认。
GPU 压测五件套是什么？定义与适合/不适合
GPU 服务器压测工具栈是指政企机房在 GPU 服务器 / HGX 类机箱 CapEx 签收前应冻结的五件互补角色。DCGM / dcgmi 回答「这张卡在操作系统里是否生病」。nvbandwidth 回答「链路拷贝有多快」。nccl-tests 回答「接近训练的集合通信有多快」。gpu-burn 回答「满载能否撑过数小时」。NVIDIA Field Diagnostic（fieldiag） 才是 RMA 权威。它们不能互相替代。
适合：HGX / B300 类到货验收、机群巡检、区分 PCIe / NVLink / 热路径、组装 RMA 证据包。不适合：用本页报 GPU 价；把 gpu-burn 或 DCGM Pass 当 Field Diagnostic；把渠道走廊里的 B300 数字当机箱 SLA；ECC 关闭跑 Field Diag；仅因双路箱 SYS P2P 是 PCIe 量级就整机拒收；训练集群 PO 跳过 nccl-tests。
- 适合： GPU 服务器 / HGX / B300 类到货；机群巡检；隔离 PCIe vs NVLink vs 热；带 fieldiag.log 的 RMA 包。
- 不适合： 报价；DCGM 绿灯当 NVIDIA RMA；ECC 关闭跑 Field Diag；把 SYS 量级约 50 GB/s 当 NV18 坏了；训练单跳过集合通信。
| 工具 | 角色 | 典型输出 | 耗时量级 | 权威性 |
|---|---|---|---|---|
DCGM / dcgmi | 机内健康、ECC、内存、PCIe、计算插件 | Pass / Fail / Warn / Skip | 分钟级（L1–L3）；L4 可能数小时 | 不是 RMA 资格 |
| nvbandwidth | HBM / PCIe / P2P memcpy 带宽（CE 或 SM） | GB/s（或 TB/s）矩阵 | 默认约 1–2 分钟；-b 2048 -i 10 更长 | 链路/路径证据 |
| nccl-tests | 最接近训练的集合通信（all_reduce_perf 等） | algbw / busbw，wrong 计数 | 单机分钟级；多节点 MPI 更长 | Fabric + NCCL 配置 |
| gpu-burn | 满载浸泡（功耗、热、计算错误） | errors、Gflop/s、温度 | 日常 15–30 分钟；严格交付 12–24 小时 | 机房与稳定性 — 不是 RMA |
NVIDIA Field Diagnostic（fieldiag） | 离线/全面硬件诊断 | Pass/Fail + fieldiag.log | OEM 包；量级约 2 小时（L1）/ 4.5–5.5 小时（L2）— 待确认 | RMA 权威 |
按目标和场景怎么选工具？
先把买方目标映射到第一把工具，再按场景顺序执行。不要仅凭 DCGM Fail 开 RMA：失败可能来自主机、驱动、散热、供电或干扰，不一定是 GPU ASIC。
| 买方目标 | 第一把工具 | 原因 |
|---|---|---|
| 快速健康 / 这张卡病了吗？ | dcgmi diag（先 1 级快测，再 3 级长测） | 一轮覆盖软件 + 内存/PCIe（L2+）+ 计算/压测（L3） |
| HBM 带宽够不够？ | nvbandwidth D2D CE（精确名用 -l） | 对照量级峰值约 80% |
| PCIe Gen5 x16 是否健康？ | nvbandwidth H2D/D2H CE | 单向通过线 ≥ 约 50 GB/s（模拟样例） |
| 多卡 NVLink / P2P | nvbandwidth P2P SM 和 nccl-tests | 先看 NV18 vs SYS（nvidia-smi topo -m） |
| 接近训练的集合通信 | nccl-tests all_reduce_perf | 最接近真实训练流量 |
| 机房 PDU / 散热 / 浸泡 | gpu-burn（8 卡满载） | errors=0，温度量级 <90 °C（模拟样例） |
| RMA 材料包 | Field Diagnostic + fieldiag.log（+ bug report） | DCGM/gpu-burn 只是佐证 |
| 场景 | 建议顺序 |
|---|---|
| 新机到货 | 基线 nvidia-smi/topo → DCGM L2/L3 → nvbandwidth（CE+SM）→ nccl-tests → gpu-burn 12–24 小时 → 有 OEM 包 / RMA 风险高时再 Field Diagnostic |
| 故障分诊 | dcgmi diag → 定向插件（ECC/内存、PCIe、nvbandwidth）→ 故障随卡走则交叉插槽 |
| 日常巡检 | dcgmi diag -r 1（快测）+ 默认 ./nvbandwidth |
| RMA | Field Diagnostic 且 ECC 开启；附 fieldiag.log；DCGM JSON 是附件不是替代 |
| 机房供电/散热签收 | gpu-burn 全卡；盯 PDU / CDU / 进风 |
DCGM / dcgmi diag 实际能证明什么？
DCGM Diagnostics 是机内健康套件。NVIDIA 官方文档写明：它们不修复故障、不能替代 NVIDIA Field Diagnostics、也不能判定 RMA 资格。绿灯只说明在这台主机、这套驱动上，所选插件没有失败——不等于 NVIDIA 会接受换板。结果令牌为 Pass / Fail / Skip / Warning；把 Skip 当成「不是干净绿灯」。
套件选择器（DCGM 用户指南）：1 / quick / short = 软件部署检查；2 / medium 增加 memory + pcie；3 / long 增加 diagnostic、memory_bandwidth、定向压测/功耗，以及存在时的 nvbandwidth 插件与 nccl_tests 插件；4 / xlong 在 L3 上再加 memtest + pulse_test。机房常用：dcgmi discovery -l、dcgmi diag -r 1、dcgmi diag -r 3、dcgmi diag -r memory -i <GPU_INDEX>、dcgmi diag -r 2 -t pcie，JSON 用 dcgmi diag -r 1 -j，另有 dcgmi dmon / health / topo。nvbandwidth 插件 Fail 时，先装二进制并让 GPU 空闲（is_allowed），再怪 ASIC。上海滔涵实业把 DCGM JSON 与 PO 验收单同目录归档，只当分诊，绝不拿它当 RMA 工单。
什么时候跑 nvbandwidth，什么时候跑 nccl-tests？
需要 memcpy/链路证据时跑 nvbandwidth：D2D（HBM）、H2D/D2H（PCIe）、P2P（NVLink 或 SYS）。官方 GitHub（2026-09-19）：CUDA 11.x+（多节点 12.3+ + 驱动 550+），CMake 3.20+，默认 buffer 512 MiB（-b），默认迭代 3（-i），JSON 用 --format json（不是博客 -j）。冻结 -t 名前务必 ./nvbandwidth -l。严格验收常用 -b 2048 -i 10。CE 是 Copy Engine（链路天花板，不吃 SM）；SM 是内核拷贝（更接近应用成本）。用例族存在时两条都跑。深 CLI 与精确用例拼写见对篇带宽验收文；本页只要路径族和拓扑课：同 socket 的 NV18 应对高；跨 CPU 的 SYS 走 PCIe 本来就低。
采购单是训练集群时跑 nccl-tests。常见：all_reduce_perf（最常用）、all_gather_perf、alltoall_perf、broadcast_perf、reduce_perf、reduce_scatter_perf、sendrecv_perf。单机 8 卡示例：./build/all_reduce_perf -b 8 -e 128M -f 2 -g 8。读 algbw（算法带宽）、busbw（总线带宽）；wrong 必须保持 0。消息太小永远打不满 fabric 天花板。多节点 MPI 与 NCCL_IB_* 旋钮因站点而异 / 待确认——当模式写，不要当每套网络的复制粘贴。nvbandwidth 健康但 nccl-tests 慢，多半是 NCCL/IB/拓扑，不是 ASIC 死了。
gpu-burn 何时该浸泡——何时不安全？
gpu-burn（社区仓库 wilicc/gpu-burn，不是 NVIDIA Field Diagnostic）是机房浸泡：满载、功耗、热、计算错误。常用：./gpu_burn 1800（30 分钟）、./gpu_burn -d 3600（1 小时双精度）、./gpu_burn 7200（2 小时）。日常巡检 15–30 分钟；严格交付 12–24 小时且 errors=0。另开终端 watch -n 1 nvidia-smi。「≥90 °C 立即查风扇」属渠道走廊量级，待与 OEM 热规格确认。多卡满载可能跳 PDU/OPP——机房未签收时要分步上卡。两小时后出现 gpu-burn 错误，往往先查 CDU/风扇，不是自动 NVIDIA RMA。不要把 30 分钟绿灯浸泡当成 Field Diagnostic。
GPU RMA 必须跑 NVIDIA Field Diagnostic 吗？
按政企机房常规路径，NVIDIA/厂商 RMA 包通常必须跑。官方名称：NVIDIA Field Diagnostic / HW Field Diag。GPU Debug Guidelines 称它为权威、全面的 NVIDIA 工具，RMA 前通常要求；是否/何时/如何跑，联系系统厂商。二进制为 ./fieldiag（OEM 包可能包一层 fieldiag.sh --level1/--level2/--sit）。ECC 必须开启；仅在 ECC 关闭时出现的失败不具备 RMA 资格（NVIDIA RMA Process）。产物是 fieldiag.log——缺日志会拖工单。向 OEM / NVIDIA 支持索取，不像 gpu-burn 可公开 clone。HGX SKU 常有机型专用包。渠道走廊里的模块耗时（L1 约 2 小时 / L2 约 4.5–5.5 小时，--sit 约 34 分钟）属 OEM 包量级 / 待确认。跟你这套包里的 Field Diagnostic Quick Start（DU-05711-001 / DU-05363-001 类文档），不要假定每箱都走同一套 Rufus U 盘流程。渠道叙述的错误码（540 NVRM Fatal、140 NvLink bus、143 PCI Express、PEX ERROR）相对 OEM 日志解码器仍待确认，不要当成公开 NVIDIA 错误目录。
B300 模拟样例通过线
全文标注：示意性 B300 类 8 卡双路；待与 OEM datasheet / 你的 PO 确认。 不要当合同 SLA。
| 指标 | 工具 | 理论量级 | 样例通过线 | 偏低先查 |
|---|---|---|---|---|
| HBM D2D | nvbandwidth CE | ~8 TB/s | ≥ 约 80%（≥ 约 6.4 TB/s） | 时钟、温度、HBM |
| PCIe H2D / D2H | nvbandwidth CE | Gen5 x16 ~64 GB/s | 单向 ≥ 约 50 GB/s | Gen/Width、槽位、亲和 |
| PCIe 双向 | nvbandwidth CE | 总量 ~40–55 GB/s 量级 | 半双工拆分不要当失败 | 同上 |
| NVLink P2P | nvbandwidth SM | NV18 双向 ~900 GB/s 量级 | ~800–900 GB/s 量级 | Bridge、topo -m、nvlink -s |
| 跨 CPU SYS | nvbandwidth | ~50 GB/s PCIe 量级 | 预期就低 — 不是 NV18 失败 | 拓扑矩阵 |
| 集合通信 | nccl-tests | busbw 随消息变大上升 | 峰值 + wrong=0 | NCCL/IB/拓扑 |
| 浸泡 | gpu-burn | errors=0；温度量级 <90 °C | 12–24 小时交付 | PDU、CDU、风扇 |
| 硬件 / RMA | fieldiag | Pass + 日志 | Fail → OEM RMA 路径 | ECC 开；交叉插槽 |
nvbandwidth 测链路拷贝有多快；nccl-tests 测接近训练的集合通信有多快；gpu-burn 测满载能否撑住；Field Diagnostic 是 RMA 权威；DCGM 是机内分诊尺。GPU 栈之后可选 stress-ng --vm / memtester 测 DRAM、stress-ng --cpu 加 turbostat 测 CPU——待与 OEM 确认，不是第六件对等工具。
HowTo：到货 vs RMA 顺序（步骤 1–6）
按政企机房清单执行。nvbandwidth 的 -t 名称以你编译版本的 -l 为准。
- 步骤 1 — 采集基线。 保存 nvidia-smi -q（SKU、驱动、CUDA、PCIe Gen/Width、时钟/温度）、nvidia-smi topo -m、nvidia-smi nvlink -s 到带日期目录。可能走 RMA 时确认 ECC 已开启。
- 步骤 2 — 机内分诊。 dcgmi discovery -l，再在空闲 GPU 上 dcgmi diag -r 1（快）与 dcgmi diag -r 3（长）；用 -j 存 JSON。Skip/Fail 标未签收，不是自动 RMA。
- 步骤 3 — 测链路。 从 GitHub 编译 nvbandwidth；./nvbandwidth -l；默认扫一遍再跑 D2D CE、H2D/D2H CE、P2P SM，参数 -b 2048 -i 10 --format json。对照 NV18 与 SYS（跨 CPU SYS 是 PCIe 量级不要当 NVLink 坏了）。
- 步骤 4 — 测集合通信。 单机 all_reduce_perf（-g 8 量级），仅当 PO 是集群才上多节点；wrong 必须为 0；归档 busbw 峰值。
- 步骤 5 — 机房浸泡。 严格交付 gpu-burn 12–24 小时（冒烟 15–30 分钟）；errors=0；盯 PDU/CDU/nvidia-smi。不能替代 Field Diagnostic。
- 步骤 6 — RMA 材料包（仅当硬件仍可疑）。 ECC 开启下跑 OEM NVIDIA Field Diagnostic；保留 fieldiag.log + nvidia-bug-report.log.gz；故障随 GPU 走则交叉插槽。经厂商/NVIDIA 提交——DCGM/gpu-burn 日志是附件，不是工单本身。
真实应用场景
把下面五张买方画像映射到你的业务、机房与商务约束后再冻结 CapEx。五件套顺序不变，只是侧重不同。
场景 A：新到 8× B300 HGX 节点
业务画像： 财务没有带宽+浸泡包不签字。
架构匹配： 走步骤 1–5；货箱有 OEM U 盘/ISO 再加 Field Diagnostic。
场景 B：在线机架单卡 Xid / ECC 风暴
业务画像： 生产机架，一张卡吵。
架构匹配： DCGM 定向 → 对该 index 跑 nvbandwidth → 隔离并交叉插槽后再 Field Diag。
场景 C：32 节点日常巡检
业务画像： 运维要便宜的日检尺。
架构匹配： DCGM 快测 + 默认 nvbandwidth；漂移才升级 L3。
场景 D：供应商争议 NV18 数字
业务画像： 「演示过了」对「NV18 只有 50 GB/s」。
架构匹配： nvbandwidth JSON + topo -m + 对篇带宽门槛；不要只拿截图吵架。
场景 E：浸泡出错后单张 SXM 走 RMA
业务画像： gpu-burn 数小时后报错，买方要换板。
架构匹配： Field Diagnostic + 日志 + ECC 开启政策；单凭 gpu-burn 错误不是 NVIDIA 工单。
常见坑
| 现象 | 可能原因 | 检查 |
|---|---|---|
| DCGM 绿灯，训练仍慢 | 集合通信/fabric，不是 ASIC 健康 | nccl-tests + nvbandwidth P2P |
| NV18 格子约 50 GB/s | Bridge / 其实是 SYS | topo -m，重插 NVLink Bridge |
| H2D 约 30 GB/s | Gen4 或 x8 | nvidia-smi -q PCIe |
| gpu-burn 两小时后出错 | 热/电，还不到「必须 RMA」 | CDU、风扇，再 Field Diag |
| RMA 被退回 | 没有 fieldiag.log 或 ECC 关着 | RMA Process 政策 |
dcgmi diag -r nvbandwidth Fail | 插件二进制缺失 / MCUTIL>10% | 安装 nvbandwidth；GPU 空闲 |
| Fieldiag U 盘起不来 | OEM ISO 不对 / 驱动仍加载 | 跟你这套包的 QSG |
常见问题
DCGM 和 NVIDIA Field Diagnostic 有什么区别？
gpu-burn 结果能不能拿去走 NVIDIA RMA？
新到的 B300 服务器该先跑哪把工具？
双路 8 卡为何跨 CPU 的 P2P 只有约 50 GB/s？
nvbandwidth 和 nccl-tests 要不要都跑？
跑 Field Diagnostic / 申请 RMA 前必须开 ECC 吗？
参考来源
- NVIDIA DCGM Diagnostics — 套件级别；不能替代 Field Diag / RMA
- dcgmi diag CLI
- NVIDIA nvbandwidth（GitHub） — 默认 512 MiB，--format json
- NVIDIA nccl-tests
- gpu-burn（社区）
- NVIDIA Field Diagnostic
- NVIDIA RMA Process — ECC 开启、fieldiag.log
- NVIDIA GPU Debug Guidelines — Field Diag 为 RMA 权威
- NVIDIA NCCL
- nvidia-smi 文档
关键结论
政企 GPU 签收包应围绕五件互补工具：DCGM 做机内分诊（不是 RMA），nvbandwidth 用默认 512 MiB 与 --format json 测链路，nccl-tests 测集合通信，gpu-burn 12–24 小时浸泡，NVIDIA Field Diagnostic 在 ECC 开启下产出 fieldiag.log 才是 RMA 工单。B300 数字一律标模拟样例 / pending confirmation。上海滔涵实业（TAOHAN）协助国内买方在 CapEx 签收前锁定该清单——不公开渠道 GPU 价。
相关阅读
签收前先锁五件套清单
若政企机房仍在只贴一张 DCGM 截图、没有 Field Diagnostic 路径的情况下签收 GPU，请把机箱型号、GPU 数量以及货箱是否含 OEM fieldiag 包发给上海滔涵实业（TAOHAN）。我们协助冻结 DCGM / nvbandwidth / nccl-tests / gpu-burn / Field Diagnostic 验收包——不公开价格。
联系滔涵 · 冻结 GPU 验收清单