WAN ディスパッチを安くする：地に足のついたロードマップ
リモートエキスパートディスパッチは機能し、バイト単位で同一だ——だが WAN デコードは往復律速だ。ここでは DeepSeek・Petals ほかのプロダクション数値に基づいて、そのコストを削る計画を示す（出荷済みではなくロードマップ）。
枠組み：*我々が測定した*数値は測定値として述べ、計画として記すものはすべてロードマップであって出荷済みの結果ではない。目標は、リモートエキスパートディスパッチ——すでに正しく、報酬も支払われている（対になる記事を参照）——を取り上げ、WAN の往復を、遠方の GPU やスマートフォンが遅い一員ではなく一級のスウォームメンバーになるほど安くすることだ。
我々自身の実測を率直に公表する：ディスパッチはレイヤーごとトークンごとに約 110 KB かかる——送り 12.3 KB（dispatch）に戻り 98.3 KB（combine）。この 8 倍の非対称は、選ばれた各エキスパートが加重和の*前に*自分の完全な出力を返すためだ。直結ならスループットのオーバーヘッドは 1.2%；CDN リレー経由なら 約 28%。これらが事実だ。この記事の残りは、我々がどうその差を埋めるつもりか——そしてなぜバイトが簡単な部分なのか——である。
WAN デコードは往復律速である
ここで最も重要な公表結果は我々のものではない——Petals のものだ：RTT が <5 ms から 100 ms へ上がると、デコードは 1.24 から 0.57 steps/s へ落ちるが、帯域幅を 10 倍削っても変化はほぼ 0 だ。レイテンシが支配し、帯域幅には余裕がある。これは問題全体を捉え直させる：バイトを削るのは余裕づくりだが、往復を削ることこそが本質だ。以下の各項目は、往復コストをどれだけ取り除くかで順位づけしている。
精度優先のバイト削減
- 生のエキスパート出力ではなく、加重した部分和を返す。線形性により、バックボーンの combine はどちらでも厳密だが、ワーカーは 8 本ではなく合算した 1 本のベクトルを返す——それが約 8 倍の combine 削減で、まさに DeepSeek-V3 / DeepEP がプロダクションで行っていることだ。
- 直列チェーンではなく並列スターを複数ワーカーにまたがって：ΣRTT が max RTT に潰れる。
- 配線上は F16——我々はすでにクロスバックエンドの cosine 約 0.998 を受け入れているため、F16 転送は既存の許容誤差の内側だ；ブロック単位の INT8/FP8 は後で、我々自身の argmax/cosine ゲートが Q4_K_M 重みに対してそれを通過させてから（Petals は実インターネット上で INT8 を品質劣化なしに示した）。
- これらを合わせると 約 110 KB → トークンあたり 9–12 KB（約 12 倍）を狙える——本物だが、それは*余裕*であってボトルネックではないことを忘れずに。
本質：往復を減らし、往復を隠す
- 投機的デコードは多くのトークンを一度の往復に変える。実測 80 ms の WAN では、損益分岐点はわずか約 1.15–1.2 の受理トークン/ステップ——だから弱い n-gram の推測でも勝てる（素の Jacobi は裏目に出うる；技法の選択が肝心だ）。我々のディスパッチプロトコルはすでに
n_tokens > 1を運ぶため、配線の変更は不要だ。 - ゲートウェイでの連続バッチングが並行リクエストを一度の往復に畳み込む；スロットアフィニティのプレフィックスキャッシュがセッションを同じ複製にとどめる。
- レイテンシ隠蔽：共有エキスパートは独立した加算項なので、バックボーンはリモート往復の間にそれを*ローカルで*計算する（ScMoE は PCIe 上で 1.82 倍、再学習なしと報告）。hot エキスパートはローカルに保ち、cold なものだけをリモートに送る（EPLB は最も hot な約 32 個を複製し、プロダクションでデコード 2.54 倍の高速化）。
ピアで経路を選ぶ、そして 200 Gb/s が変えるもの
経路ポリシー：公開ルーティング可能なピアは直結経路を取る（1.2% の経路）；リレーは NAT 配下のデバイス専用だ。そして広い 200 Gb/s のリンクが到来すれば、110 KB は 約 4.4 µs でシリアライズされる——上記の削減より前に帯域幅の項が消え、794 MB のスライスは約 32 ms で送られる。だが RTT は物理であり、縮まない——だから投機的デコードとオーバーラップは 200 G でも本物のレバーであり続ける。太パイプが真に効くのは、マルチバックボーン連合（複数のバックボーンが一つのエキスパートプールを共有）と帯域律速の仕事——長いプロンプトのプリフィルと大バッチのスループット——だ。
正直に述べる注意点一つ：トランスポート層そのもの（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 ステージ、2 マシン |
| 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 ワーカーのみ |
業界は細粒度 MoE へ収束しつつある——より小さなエキスパート、より多くの数、より高いスパース性（DeepSeek・Qwen・Kimi・GLM・gpt-oss はすべてこの方向へ動いた）。その方向への一歩ごとに、スウォームの参加単位は小さくなり、希少性市場の粒度は細かくなる。上のモデルたちは願望リストではない；それぞれがすでに、我々がテストフリートで走らせているのと同じディスパッチフックを流れている——オンボーディングはエンジニアリングプロジェクトではなく検証ゲートだ。