让广域网调度变便宜：一份有据可依的路线图
远程专家调度可行且逐位相同——但广域网解码受往返约束。这里是削减成本的计划，立足于 DeepSeek、Petals 等的生产数据（路线图，尚未交付）。
框定：*我们测量*的数字均按实测陈述；一切被描述为计划的内容都是路线图，而非已交付的结果。目标是把远程专家调度——已经正确且已付酬（见配套文章）——的广域网往返做得足够便宜，让一台遥远的 GPU 或一部手机成为一等的蜂群成员，而不是拖慢的那个。
我们自己的测量，坦白公布：调度每 token 每层约花 110 KB——12.3 KB 出站（dispatch）加 98.3 KB 返回（combine）。这 8× 的不对称，是因为每个被选中的专家在加权求和*之前*就返回其完整输出。直连时是 1.2% 的吞吐开销；经 CDN 中继则为 ~28%。这些是事实。本文余下的部分讲我们打算如何弥合差距——以及为何字节才是容易的部分。
广域网解码受往返约束
这里最重要的一个已发表结果不是我们的——是 Petals 的：当 RTT 从 <5 ms 升到 100 ms，解码从 1.24 降到 0.57 steps/s，而把带宽砍到 1/10 几乎不改变它。延迟主导；带宽是富余的。这重新框定了整个问题：削减字节是余量，而削减往返才是实质。下面每一项都按它能去掉多少往返成本排序。
精度优先的字节削减
- 返回加权部分和，而非原始专家输出。由线性性，骨干的 combine 无论哪种方式都精确，但 worker 返回一个求和后的向量而非 8 个——这就是那 ~8× 的 combine 削减，也正是 DeepSeek-V3 / DeepEP 在生产中所做的。
- 跨多个 worker 用并行星形，而非串行链：ΣRTT 坍缩为 max RTT。
- 线路上用 F16——我们已经接受约 0.998 的跨后端 cosine，因此 F16 传输落在既有容差之内；之后再上分块 INT8/FP8，在我们自己的 argmax/cosine 闸门对 Q4_K_M 权重放行之后（Petals 已展示在真实互联网上用 INT8 而无质量损失）。
- 这些合起来瞄准每 token ~110 KB → 9–12 KB（~12×）——真实，但记住它是*余量*，而非瓶颈。
实质：更少的往返、被隐藏的往返
- 投机解码把许多 token 变成一次往返。在实测的 80 ms 广域网上，盈亏平衡只需每步 ~1.15–1.2 个被接受的 token——因此即便是一个弱 n-gram 猜测也能取胜（原生 Jacobi 可能适得其反；技术选择很重要）。我们的调度协议已经携带
n_tokens > 1，因此无需改动线路。 - 网关上的连续批处理把并发请求折叠进一次往返；槽亲和的前缀缓存让一个会话停留在同一批副本上。
- 延迟隐藏：共享专家是一个独立的加性项，因此骨干在远程往返期间*在本地*计算它（ScMoE 报告在 PCIe 上 1.82×，无需重训）。把 hot 专家留在本地，只把 cold 的发到远程（EPLB 在生产中复制最热的约 32 个，换来 2.54× 的解码提速）。
按对端选路，以及 200 Gb/s 改变什么
路径策略：可公网路由的对端走直连路径（那条 1.2% 的路线）；中继只留给 NAT 后的设备。而当宽阔的 200 Gb/s 链路到来，110 KB 在 ~4.4 µs 内序列化——甚至在上述削减之前，带宽项就已消失，一份 794 MB 的切片在 ~32 ms 内传完。但 RTT 是物理规律；它不会缩小——因此即便在 200 G 下，投机解码与重叠仍是真正的杠杆。粗管道真正要紧之处，在于多骨干联邦（多个骨干共享一个专家池）和受带宽约束的工作：长提示词 prefill 与大批量吞吐。
一个如实陈述的告诫：传输层本身（WebSocket vs QUIC、掩码开销、NAT 打洞）没有可供我们引用的外部结果——那是我们会在宣称任何东西之前自己测量的工程。上文的一切都建立在已发表的生产数据（DeepEP / DeepSeek-V3、Petals、DeepSpeed-MoE、ScMoE、SGLang/EPLB）加我们自己的测量之上；当某个路线图项交付时，它的数字与时态会在此更新。
接入目标
我们的调度钩子挂在 build_moe_ffn 上——推理引擎中 43 种 MoE 架构共享的一个函数。三条不变式与模型无关：MoE 数学（routed = Σ wᵢ·Eᵢ(x)，线性）、共享的代码路径，以及 GGUF 标准的堆叠专家张量（最外层 ne[2] → 块对齐切片）。因此接入一个新模型不是重新设计——而是过一遍针对每个模型的 argmax/cosine 验证闸门。
| 模型 | 专家 · 路由 | 每专家 (Q4≈) | 共享 | 状态 |
|---|---|---|---|---|
| Step-3.7-Flash 198B（今日服务中） | 288 · top-8 | 在机队上实测 | 是 | 服务中 — 16 个 stage，两台机器 |
| Qwen3.5-122B | 256 · top-8 | 5.3 MB（实测） | 是 | 已在 3 台机器上端到端服务 |
| GLM-5.2 744B | — | — | 是 | 已在 linkcpp 上验证 — 报告未公开 |
| GLM-4.5 / 4.6 355B | 160 · top-8 | ~13 MB | 是 | 计划中（钩子已验证） |
| MiniMax-M2 230B | 256 · top-8 | ~8 MB | 否 | 计划中（钩子已验证） |
| DeepSeek-V3 / R1 671B | 256 · top-8 | ~25 MB | 是 | 计划中（deepseek2 计算图） |
| Kimi K3 2.8T | — | — | 是 | 下一道关卡 — 在 p4 上验证 |
| Qwen3-235B | 128 · top-8 | ~11 MB | 否 | 就绪 |
| gpt-oss-120b | 128 · top-4 | ~14 MB | 否 | 就绪 |
| Llama 4 Maverick 400B | 128 · top-1 | ~70 MB | 是 | 计划中（每隔一层是 MoE） |
| MiniMax M3 428B | 128 · top-4 | 待定（GGUF） | 是 | 等待上游引擎 |
| Mixtral 8×22B | 8 · top-2 | ~170 MB | 否 | 可用 — 仅限 GPU worker |
整个行业正在向细粒度 MoE 收敛——专家更小、数量更多、稀疏度更高（DeepSeek、Qwen、Kimi、GLM、gpt-oss 都朝这个方向走）。朝那个方向的每一步，都让蜂群的参与单位更小、稀缺市场的颗粒更细。上面这些模型不是愿望清单；每一个都已经流过我们在测试机队上运行的同一个调度钩子——接入是一道验证闸门，而非一个工程项目。