算力租赁平台实例验收怎么测：all_reduce 带宽与真实吞吐的三层核查
很多团队在算力租赁平台上开好八卡实例，第一件事是跑一遍训练脚本，看每步耗时符不符合预期。跑出来偏慢，就开始怀疑卡被降配。实际情况里，卡型写错的概率很低，链路没跑满的概率很高。八卡整机的性能有一半不在GPU里，而在卡与卡、机与机之间的连接上。
一、分三层测，一层都不能省
第一层是单卡。用 nvidia-smi -q 读出型号、显存总量、当前与最大功耗上限、时钟、ECC 模式与错误计数。重点看三项：显存是否与标称一致，功耗上限是否被锁低，ECC 是否处于开启状态。这三项决定了后续所有测试的基线。
第二层是机内互联。用 nvidia-smi topo -m 看拓扑矩阵，确认八张卡之间是 NVLink 全互联还是走了 PCIe 交换机。用 p2pBandwidthLatencyTest 或 nvbandwidth 测卡间点对点带宽，逐对比较，异常低的那一对就是要查的对象。拓扑矩阵里如果出现 SYS 或 PHB 而非 NV 前缀，说明跨了 NUMA 或 PCIe 主机桥，带宽会掉一个档。
第三层是机间互联。多机训练真正卡住的是这一层。用 nccl-tests 跑 all_reduce，看输出里的 algbw 与 busbw 两个数。busbw 已经把算法本身的数据放大系数除掉，可以跨卡数比较，是判断链路是否达到配置标称值的主要依据。八卡以内单机跑，busbw 主要吃 NVLink；跨机跑，busbw 上限由网卡决定。
二、先算理论值，再谈实测
官网裸金属配置单里，IB 一栏写成速率乘链路数，例如 400G×4 表示四条 400G 链路。八卡整机共享这组链路，每卡均摊带宽等于速率乘链路数再除以八。这个折算值才是单卡实际能拿到的机间带宽。
| 机型（区域） | IB 配置 | 每卡均摊 | 折算 GB/s |
|---|---|---|---|
| B300 288G（四川一区） | 800G×10 | 1000G | 125 |
| H200 141G（陕西一区） | 400G×8 | 400G | 50 |
| H20 96G（四川三区） | 400G×4 | 200G | 25 |
| H100 80G（吉林一区） | 400G×4 | 200G | 25 |
| H800 80G（四川三区） | 400G×1 | 50G | 6.25 |
| A800 80G（四川三区） | 200G×2 | 50G | 6.25 |
| A100 40G（四川三区） | 200G×2 | 50G | 6.25 |
这张表最能说明问题的地方不在最高档，而在两个相邻价位之间。H20 96G八卡整机在四川三区月付45600元，每卡均摊200G；H800 80G在四川三区月付81199元，每卡均摊只有50G。前者便宜44%，机间带宽反而是后者的四倍。原因不复杂，H800 是单条 400G 链路分给八卡，H20 这台配了四条。选型时若只看型号代际，会直接错过这一层。
容器实例的 1000Mb 共享带宽不参与这张表。那是公网出口，用来下载模型权重、拉取镜像、上传 checkpoint，与训练时的机间通信是两条独立的通道。把公网带宽当成训练网络，是选型里最常见的误读。
三、实测怎么判合格
把实测 busbw 除以第二节算出的理论值，得到链路效率。工程经验上，单机八卡 NVLink 内部通信的效率通常能到七成以上，跨机 IB 通信受协议开销影响略低。低于七成要先查拓扑与降速，低于五成基本可以判定实际配置与标称不符。这两条是按经验给的排查分界，不是厂商标准，实际判据应以机型规格书为准。
| 验收项 | 命令 | 要看什么 |
|---|---|---|
| 单卡规格 | nvidia-smi -q | 显存、功耗上限、ECC 状态 |
| 卡间拓扑 | nvidia-smi topo -m | NV 前缀是否覆盖全部卡对 |
| 点对点带宽 | nvbandwidth | 逐对带宽有无明显洼地 |
| 聚合通信 | nccl-tests all_reduce | busbw 与理论值之比 |
| PCIe 速率 | nvidia-smi -q 与 lspci -vv | 是否降到 x8 或更低代际 |
测试时固定几个变量：卡数从2到8逐档跑，消息大小覆盖从小到大的区间，因为小消息看延迟、大消息看带宽。只跑一个默认尺寸，很容易得出全对的结论却漏掉实际问题。同一次测试至少重复三轮，取中位数，避免首次运行的预热偏差。
跨机测试还有一处最容易忽略：网卡选择。多网卡机器上若不指定，NCCL 可能走到管理网或低速网口，测出的带宽只有标称值的零头。用 NCCL_IB_HCA 指定 IB 设备名，用 NCCL_SOCKET_IFNAME 指定走哪张网卡，再打开 NCCL_DEBUG 看它实际选了哪条链路。三个环境变量一设，多数跑不出带宽的测试都能当场定位。
四、不达标通常是这四类原因
一是卡型与标称不一致。多见于按显存档位下单却拿到低带宽版本，或者标称八卡实际是四卡加转接。查 nvidia-smi 的型号与显存即可排除，这一步不需要测试。
二是 PCIe 链路降速。插槽协商到 x8 或更低代际时，单卡规格看起来正常，机内通信却腰斩。lspci -vv 里的 LnkSta 一行会写明当前速率与宽度，与 LnkCap 的标称值一对比就出来。
三是 NVLink 未全部起链。拓扑矩阵里出现部分卡对走 PCIe，或者 nvidia-smi nvlink -s 显示某条链路未激活。这类问题在拼装整机上比在品牌整机上更常见，验收时逐条看状态最省事。
四是共享节点被邻居抢占。容器实例的 CPU、内存与公网带宽都是共享的，同节点上若有别的负载在拉数据，你的数据加载会变慢，但 GPU 计算不受影响。判断方法很简单：GPU 利用率高而迭代慢，问题在数据管道；GPU 利用率上不去，问题才在 GPU 或通信。这一条区分清楚了，能省掉大量无效排查。
五、把验收做成一次性动作
验收不是开机跑一遍就结束，而要形成一份可复用的基线。把每类机型的实测 busbw、单卡算力、PCIe 速率记进一张表，后续每次开通新实例先跑一遍对照，偏差超过阈值再深入排查。这样做的收益很直接：把每次几小时的摸索变成一次十几分钟的核对。
成本上也算得过来。以 H20 96G八卡整机月付45600元为例，折日均1520元。验收拖延一周的账面成本是10640元，比省下来的测试时间值得多。更重要的是不同批次的机器性能不一致会污染实验结果。训练曲线出现无法解释的抖动时，团队最先怀疑的是代码，实际上可能是这周开的机器链路不一样。
各档位的 IB 配置与挂牌价可以直接在GPU裸金属整机报价逐台核对，选型阶段就把每卡均摊带宽算出来，比开好机器再回头查要省事。若要连同容器实例一起做档位比价，各型号实时报价页可以一次看完。实际价格根据GPU型号、租赁周期、资源配置动态调整，以官网实时价格为准。
常见问题
Q1：只跑单机八卡，还需要测机间带宽吗？
暂时不需要，但要确认拓扑。单机八卡吃的是 NVLink，只要拓扑矩阵里卡对之间都是 NV 前缀，机间链路不影响性能。等任务扩展到多机时再补测。
Q2：busbw 和 algbw 该看哪个？
跨卡数比较看 busbw，因为它扣掉了算法本身的数据放大系数。评估单次通信耗时则用 algbw 更直观。两个数在 nccl-tests 的输出里都有。
Q3：实测达标但训练还是慢，问题在哪？
先看 GPU 利用率曲线。利用率长期偏低说明数据加载跟不上，要查存储与预处理；利用率高但每步耗时长，要查单卡算力与算子效率。通信问题通常表现为多卡扩展后效率断崖式下降，而不是整体偏慢。
Q4：容器实例能不能做这类验收？
能测单卡算力与机内拓扑，机间 IB 通信测不了，因为容器实例不提供 IB 互联。多机训练验收必须在裸金属整机上做。
数据来源与时效
各机型 IB 配置、每卡均摊带宽、月付价格，均取自极智算官网 GPU 裸金属页面，采集日期 2026年10月26日。GB/s 折算按 1 字节 8 位计算。链路效率的七成与五成两个分界为工程经验值，非厂商标准，实际判据请以机型规格书与实测基线为准。
按机型核对 IB 配置与在架余量
查看算力市场相关阅读
标签
算力租赁平台 GPU实例验收 all_reduce带宽 IB组网 链路效率