WAN-Dispatch billig machen: eine fundierte Roadmap
Remote-Experten-Dispatch funktioniert und ist byte-identisch — aber eine WAN-Dekodierung ist roundtrip-gebunden. Hier ist der Plan, die Kosten zu senken, fundiert in Produktionszahlen von DeepSeek, Petals und anderen (Roadmap, nicht ausgeliefert).
Rahmung: Die Zahlen, die *wir gemessen* haben, sind als gemessen ausgewiesen; alles, was als Plan beschrieben ist, ist eine Roadmap, kein ausgeliefertes Ergebnis. Das Ziel ist, den Remote-Experten-Dispatch — bereits korrekt und bezahlt (siehe den Begleitbeitrag) — zu nehmen und den WAN-Roundtrip billig genug zu machen, dass eine entfernte GPU oder ein Smartphone ein erstklassiges Schwarmmitglied ist, kein langsames.
Unsere eigene Messung, schlicht veröffentlicht: Dispatch kostet etwa 110 KB pro Token pro Layer — 12.3 KB hinaus (Dispatch) plus 98.3 KB zurück (Combine). Die 8×-Asymmetrie rührt daher, dass jeder ausgewählte Experte seine volle Ausgabe *vor* der gewichteten Summe zurückgibt. Direkt verbunden sind das 1.2 % Durchsatz-Overhead; durch ein CDN-Relay ~28 %. Das sind die Fakten. Der Rest dieses Beitrags ist, wie wir die Lücke zu schließen gedenken — und warum Bytes der leichte Teil sind.
Eine WAN-Dekodierung ist roundtrip-gebunden
Das mit Abstand wichtigste veröffentlichte Ergebnis hier ist nicht unseres — es ist das von Petals: Wenn die RTT von <5 ms auf 100 ms steigt, fällt die Dekodierung von 1.24 auf 0.57 steps/s, während ein 10×-Bandbreitenschnitt sie um ~0 ändert. Latenz dominiert; Bandbreite ist Reserve. Das rahmt das ganze Problem neu: Bytes zu schaben ist Spielraum, aber Roundtrips zu senken ist die Substanz. Jeder Punkt unten ist danach gereiht, wie viel Roundtrip-Kosten er entfernt.
Bytereduktion, Genauigkeit zuerst
- Gewichtete Teilsummen zurückgeben, nicht rohe Expertenausgaben. Durch Linearität ist das Combine des Backbones so oder so exakt, aber der Worker gibt einen summierten Vektor statt 8 zurück — das ist die ~8×-Combine-Reduktion, und genau das tun DeepSeek-V3 / DeepEP in Produktion.
- Paralleler Stern, keine serielle Kette über mehrere Worker: ΣRTT kollabiert zu max RTT.
- F16 auf der Leitung — wir akzeptieren bereits einen Cross-Backend-cosine von ~0.998, F16-Transport liegt also innerhalb der bestehenden Toleranz; blockweise INT8/FP8 später, nachdem unser eigenes argmax/cosine-Gate es gegen Q4_K_M-Gewichte freigibt (Petals zeigte INT8 über das echte Internet ohne Qualitätsverlust).
- Zusammen zielen diese auf ~110 KB → 9–12 KB pro Token (~12×) — real, aber es bleibt der *Spielraum*, nicht der Engpass.
Die Substanz: weniger Trips, verborgene Trips
- Spekulatives Dekodieren verwandelt viele Tokens in einen Roundtrip. Bei gemessenen 80 ms WAN liegt der Break-even bei nur ~1.15–1.2 akzeptierten Tokens/Schritt — selbst ein schwacher n-Gramm-Tipp gewinnt also (Vanilla-Jacobi kann nach hinten losgehen; die Technikwahl zählt). Unser Dispatch-Protokoll trägt bereits
n_tokens > 1, es ist also keine Leitungsänderung nötig. - Continuous Batching am Gateway faltet nebenläufige Anfragen in einen Trip; Slot-Affinity-Prefix-Caching hält eine Session auf denselben Repliken.
- Latenzverbergung: Der geteilte Experte ist ein unabhängiger additiver Term, der Backbone berechnet ihn also *lokal* während des Remote-Roundtrips (ScMoE berichtet 1.82× über PCIe, ohne Retraining). Halte heiße Experten lokal, schicke nur kalte remote (EPLB repliziert die ~32 heißesten für einen 2.54×-Dekodier-Speedup in Produktion).
Nach Peer routen, und was 200 Gb/s ändert
Pfad-Policy: öffentlich routbare Peers nehmen den direkten Pfad (die 1.2%-Route); das Relay ist nur für NAT-gebundene Geräte. Und wenn breite 200-Gb/s-Verbindungen ankommen, serialisiert sich die 110 KB in ~4.4 µs — der Bandbreitenterm verschwindet schon vor den obigen Reduktionen, und eine 794-MB-Scheibe geht in ~32 ms über die Leitung. Aber RTT ist Physik; sie schrumpft nicht — spekulatives Dekodieren und Overlap bleiben also die echten Hebel selbst bei 200 G. Wo die Fat Pipe wirklich zählt, ist Multi-Backbone-Föderation (mehrere Backbones teilen sich einen Expertenpool) und bandbreitengebundene Arbeit: Langprompt-Prefill und Groß-Batch-Durchsatz.
Ein Vorbehalt, ehrlich gesagt: Die Transportschicht selbst (WebSocket vs. QUIC, Masking-Overhead, NAT-Hole-Punching) hat kein externes Ergebnis, das wir zitieren können — das ist Engineering, das wir selbst messen werden, bevor wir irgendetwas behaupten. Alles oben ruht auf veröffentlichten Produktionszahlen (DeepEP / DeepSeek-V3, Petals, DeepSpeed-MoE, ScMoE, SGLang/EPLB) plus unseren eigenen Messungen; wenn ein Roadmap-Punkt ausgeliefert wird, werden seine Zahlen und sein Tempus hier aktualisiert.
Onboarding-Ziele
Unser Dispatch-Hook sitzt auf build_moe_ffn — einer einzigen Funktion, die 43 MoE-Architekturen in der Inferenz-Engine teilen. Drei Invarianten sind modellunabhängig: die MoE-Mathematik (routed = Σ wᵢ·Eᵢ(x), linear), der geteilte Codepfad und GGUFs standardmäßig gestapelte Expertentensoren (äußerstes ne[2] → blockausgerichtetes Slicing). Ein neues Modell zu onboarden ist also kein Redesign — es ist ein Durchlauf durch ein argmax/cosine-Verifikations-Gate je Modell.
| Modell | Experten · Routing | je Experte (Q4≈) | geteilt | Status |
|---|---|---|---|---|
| Step-3.7-Flash 198B (heute im Einsatz) | 288 · top-8 | auf der Flotte gemessen | ja | im Einsatz — 16 Stages, zwei Maschinen |
| Qwen3.5-122B | 256 · top-8 | 5.3 MB (gemessen) | ja | Ende-zu-Ende über 3 Maschinen bedient |
| GLM-5.2 744B | — | — | ja | auf linkcpp verifiziert — Bericht unveröffentlicht |
| GLM-4.5 / 4.6 355B | 160 · top-8 | ~13 MB | ja | geplant (Hook verifiziert) |
| MiniMax-M2 230B | 256 · top-8 | ~8 MB | nein | geplant (Hook verifiziert) |
| DeepSeek-V3 / R1 671B | 256 · top-8 | ~25 MB | ja | geplant (deepseek2-Graph) |
| Kimi K3 2.8T | — | — | ja | nächstes Gate — Verifikation auf p4 |
| Qwen3-235B | 128 · top-8 | ~11 MB | nein | bereit |
| gpt-oss-120b | 128 · top-4 | ~14 MB | nein | bereit |
| Llama 4 Maverick 400B | 128 · top-1 | ~70 MB | ja | geplant (MoE in jeder zweiten Layer) |
| MiniMax M3 428B | 128 · top-4 | TBD (GGUF) | ja | wartet auf Upstream-Engine |
| Mixtral 8×22B | 8 · top-2 | ~170 MB | nein | funktioniert — nur GPU-Worker |
Die Industrie konvergiert auf feinkörniges MoE — kleinere Experten, mehr davon, höhere Sparsity (DeepSeek, Qwen, Kimi, GLM, gpt-oss sind alle diesen Weg gegangen). Jeder Schritt in diese Richtung macht die Teilnahmeeinheit des Schwarms kleiner und das Korn des Knappheitsmarkts feiner. Die Modelle oben sind keine Wunschliste; jedes fließt bereits durch denselben Dispatch-Hook, den wir auf unserer Testflotte betreiben — Onboarding ist ein Verifikations-Gate, kein Engineering-Projekt.