摘要

  • SoftBank 的 NCCL 全链路性能检查发现，一条特定链路的吞吐降到正常值的某个不特定比例；与此同时，LED 为绿色、Link Status 为 UP、光功率仍在正常范围。三项状态有效，但不足以完成工作负载验收。
  • JANOG58 讲稿把 switch、optics、NIC、光纤与连接器污染列为排障面，却没有公开根因、精确吞吐比例、事件 BER/FEC 数值或经测量的修复结果。示例页上的 BER/FEC 数字与更换 optics 图示不能被改写成事故记录。
  • 机架级容量应以可复现的每链路负载基线和物理层证据验收，并在修复后重放同一测试。GPU 数量、ASN／前缀可见性和绿色状态都不能代替这一步。

状态灯没有失效。它忠实地报告了一个比业务目标更窄的事实。

SoftBank 在 2026 年 7 月 16 日 JANOG58 Day 2 分享了 Rack-Scale GPU サーバーの NW 設計と運用までの苦悩。演讲者是 Yasuhiro Uchida 与 Chaocheng Chang。官方 56 页讲稿说明，团队用 NCCL benchmark 检查所有链路时，发现一条特定链路的通信吞吐量降到“本来の数分の一程度”。原文没有说三分之一，也没有给出任何精确比例。

同一页同时记录：LED 为 Green，Link Status 为 UP，光功率在正常范围内。把四项放在一起，才得到真正的运行问题：设备存在、接口上线、接收功率未越线，但预期工作负载需要的链路速率没有交付。

这不是一次普通服务器的孤立端口检查。讲稿把 GB200 NVL72 作为一个机架级系统处理：18 个 compute tray，每个 tray 有四块 B200 GPU；九个 switch tray，每个装有两个 NVSwitch。讲稿称单机架功率超过 100 kW。NVIDIA 的硬件文档也给出 72 GPU、36 CPU、18 compute tray、九 switch tray，以及被动铜缆背板、电源架、busbar 与液冷 manifold 等参考构成。

这些是架构证据，不是故障链路的性能证明。SoftBank 2025 年 12 月的公开说明称，1,224 块 Blackwell GPU 的平台已于 12 月 22 日投入运行，并计划未来扩展到 4,000 块以上。前者是运营商自述的已部署规模，后者仍是计划。无论哪一个数字，都不告诉客户有多少条链路在此刻达到验收基线。

讲稿还把网络分成三个 fabric。Compute Fabric 承担 GPU rack 之间的 scale-out 通信；Converged Fabric 承担前端、存储和 NCCL bootstrap；OOB Fabric 承担 switch、server、facility 与 NVSwitch 管理。逻辑分工使运行边界更清楚，却不会自动让物理依赖彼此独立。

OOB 部分给出了一个很具体的例子。仅靠 leaf switch 的管理端口可能形成单点。讲稿提出，通过 Compute Fabric underlay 交换 loopback reachability，可以用较少的线缆改善运维可达性，同时明确说明这不是 OOB 的替代。用于修复生产 fabric 的路径，不能悄悄变成依赖该 fabric 才能工作的唯一修复路径。

吞吐异常也遵循同样的原则。绿灯证明状态电路满足条件；Link UP 证明接口完成相应的管理或协议状态；正常光功率证明收光没有触发所设阈值。这些信号没有承诺 lane error、纠错余量、队列或端到端 rate 一定符合 NCCL collective 的需要。

因此，正确结论不是“状态灯无用”，更不是用一个 workload benchmark 取代全部物理指标。证据只支持增加一项更贴近交付目标的验收：链路必须在指定拓扑与负载下给出可复现的速率。

为什么这个缺口在机架级系统里特别昂贵？因为 collective 的完成时间受慢链路和退化链路影响，而不是由端口标签的平均值决定。一条仍被系统识别、却只能交付正常值一部分的链路，可能让后面的 GPU 保持通电和计入资产，却不能形成预期的可售计算容量。安装容量与可交付容量在这里分开。

SoftBank 随后列出的排障面包括 switch、optics、NIC、光纤和连接器污染。这是一条候选依赖链，不是根因列表。公开讲稿没有说明最终是哪一个部件，也没有给出故障时的实际 BER、FEC histogram、lane counter 或精确光功率。

接下来的页面解释了 pre-FEC BER、post-FEC BER 以及 FEC histogram bin，并用正常／异常 pattern 展示如何定位，还在示例图中出现了更换 optics。所有数值和更换动作都位于示例排障页面。它们不能被当作这次事件的计数器，也不能据此写成“更换光模块后恢复”。

诊断、维修和恢复是三段证据。BER 可以显示纠错前错误，FEC 可以显示纠错正在消耗多少余量；更换一个部件可以检验假设。只有重放最初发现问题的全链路性能测试，才能证明 workload-relevant rate 已经回来。公开材料没有 before/after benchmark，也没有组件级因果结论。

讲稿提出的监控方向仍然清楚。第 48 页直接把 Link UP = OK 标成“不充分”，要求更重视 BER/FEC 等物理指标，按周／月收集 interface 与 optics log、分析趋势，并从只发现 interface down 转向发现退化征兆。

这是一项运行设计，不是预测成功的证据。材料没有公开告警阈值、留存策略、误报率、提前发现的故障或可用性改善。因此文章可以说 SoftBank 识别了盲区并提出更贴近物理机制的账本，不能说它已经实现预测性维修。

服务单位决定验收缺口由谁承担。讲稿比较 rack、tray 与 GPU 三种交付方式，最后写明 SoftBank 目前在权衡后提供 rack 与 tray 单位，GPU 单位仍是分析过但未选定的方式。

整 rack 交付的逻辑分区更简单，却把 Compute Fabric、CDU、NVSwitch、compute tray 和 busbar 等单点或共同依赖带给同一客户。tray 单位适合较小客户，但需要 NVLink partition。讲稿指出，NVSwitch 管理进程在 rack 内共用，是单点；若要提高 SLA，需要 rack／SU 单位冗余。

这也说明锁定不只来自某一块 GPU。Cable cartridge、NVLink topology、ORv3 rack、48V busbar、液冷接口、合格部件清单、firmware、partition 管理与 benchmark 基线共同决定替换路径。一个供应商可以准确地说自己的部件在规格内，合成系统却仍可能太慢。

权力随控制面分开。SoftBank 对自己运营的平台拥有验收、监控、workload admission 与客户恢复权；NVIDIA 以及 switch、NIC、optics 供应商控制参考设计、firmware、诊断和支持边界；facility 团队控制电力、液冷和物理进入。JANOG 有权发布会议记录，但不会因此取得对任何生产网络的验收授权。

成本也沿这条链分配。SoftBank 支付高密度线缆、光模块、switch、备件、昂贵 lab、机架电力、冷却和跨供应商排障人力。若退化链路通过名义检查，tenant 承担作业延迟与昂贵 GPU 空转。规模较小的购买者可能无力复制整 rack 备件与验证环境，因而更依赖集成供应商的诊断结论。

可信的反事实应从每条必要链路的身份开始。把可移植的 NCCL 分布或其他 workload baseline，与 link state、光功率、lane counter、pre/post-FEC BER、FEC histogram、两端设备、module、光纤、firmware 和时间戳绑定。出现偏差时，一次只替换一个有界部件，保留计数器变化，并在维修后重放完全相同的全链路测试。

tenant 未必需要看到每个 vendor 私有计数器，但 service owner 必须能证明：验收时链路达到声明速率，维修后又回到同一分布。趋势、告警、ticket、部件更换与恢复验证必须是五个不同记录，不能由一个“已关闭”状态替代。

外部可达性仍是另一层。管理前缀和客户前缀可以继续被 BGP 看见，而内部 collective 路径仍交付不足。ASN 与前缀可见性证明路由身份和到服务边缘的可达，不证明机架内部吞吐，也不让 registry、标准组织或会议取得性能验收权。

JANOG58 这项案例的结论因此比“多看 BER”更严格：只有当目标速率被重现、物理证据可追踪、维修后同一测试闭环时，一条机架级链路才成为可交付容量。绿灯和 Link UP 说明它存在；负载验收才说明它可用。

来源