200G 之问
我们的蜂群 hub 已经能用货架上的现成部件以 200 Gb/s 互联——其中一个就内置在 GB10 里。这里讲一条粗管道为分布式 MoE 买来什么，以及它买不到的那一样东西。
前提：广域网解码受 RTT 约束，而非受带宽约束——我们的通信路线图表明字节是容易的部分。那么当 hub 拿到 200 Gb/s 链路时，真正改变的是什么？关于*容量*的几乎一切，关于*延迟*的几乎一无所变。
硬件并不科幻——一个就随我们的 GB10 worker 一起出货
计算我们 122B 专家的那台 GB10 Grace Blackwell，板载了一块带两个 200 GbE QSFP 端口的 NVIDIA ConnectX-7。两台这样的机器用一根约 100 美元的 QSFP56 DAC 线缆直连——一个零交换机的 200G 双 hub 集群。ARM 在这里是一等公民：在 x86 数据中心驱动这些网卡的那套 mlx5 驱动栈，同样在 aarch64 上驱动它们，而 GB10 正是 aarch64。
细则：GB10 在多主机模式下通过两条 PCIe Gen5 x4 链路馈送它的 ConnectX-7。实测满速（~185–190 Gb/s）需要 RoCE（RDMA）和正确映射的拓扑——在映射错误的路径上朴素地跑 TCP 只能到 ~95 Gb/s 甚至更差。粗管道是用配置买来的，不只是靠线缆。
200G 在每种距离上都是目录里的现货
| 距离 | 部件 | 外形规格 |
|---|---|---|
| 机架 (0.5–3 m) | QSFP56 DAC 铜缆 | 线缆，~$100 |
| 房间 (~30 m) | AOC 有源光缆 | 线缆 |
| 园区 (2–10 km) | 200G FR4 / LR4 光模块 | QSFP56 模块 |
| 城域 (~40 km) | 200G ER4 光模块 | QSFP56 模块 |
| 区域 (~120 km) | 400G ZR+ 相干，以 200G 线速运行 | QSFP-DD 模块 |
| 长途 (数百 km) | 运营商 200G 波长 / DWDM 线路系统 | 租用服务 |
在广域网里，*线缆*不过是标准单模光纤——速率中性的玻璃，早已铺遍每一座城市。速率活在两端的可插拔光模块里，而 OpenZR+ 让 200G 跑 120 km 成了一个你插进交换机的模块，而非一个电信工程。再往上，你就得租一条波长了。
蜂群里每一个带宽项都消失了
- 一个调度载荷（如今约 110 KB/token/层，线路路线图之后约 10 KB）在微秒内序列化——载荷大小彻底不再是设计约束。
- 一份专家切片在 ~32 ms 内传完（794 MB，理论值），整个 122B 模型在 ~3 s 内同步——覆盖市场再平衡与新 hub 接入变得近乎瞬时。
- 长上下文 prefill——唯一真正吃带宽的阶段——以线速推进，因此 100K-token 提示词上的首 token 时间变成受骨干计算约束。
- 批量调度在没有线路上限的情况下扩展：跨众多用户流聚合的专家池流量，恰恰是粗管道所吸收的那种吃带宽、耐延迟的负载。正是这一点让多骨干联邦——多个 hub，各自为自己的用户持有 KV，共享一个专家池——变得可行。
光不会赶路
光纤以 ~5 µs/km 传送光，再多的带宽也改变不了这一点。一次 13 ms 的往返，在 200 Gb/s 下仍是 13 ms。自回归解码为每个分片层、每个 token 都要付这次往返——这正是为什么即便在市面上最粗的管道相连的 hub 之间，投机解码（每次往返 k 个 token）与共享专家重叠（在调度在途时进行计算）仍然不可或缺。带宽买来吞吐；唯有对往返的自律才买得到延迟。
于是架构落定为两层。一个 hub 层——由 200G 级链路相连的骨干与 hot 专家，其容量实质上无界——和一个边缘层——443 中继上的手机与小设备，持有稀缺市场分配给它们的专家长尾。粗管道让第一层感觉像一台机器；中继让第二层向任何人敞开。两者互不替代：这种分割*就是*设计本身。