Rendre le dispatch WAN bon marché : une feuille de route étayée

Le dispatch distant d'experts fonctionne et est identique octet pour octet — mais un décodage WAN est borné par les allers-retours. Voici le plan pour en réduire le coût, étayé par des chiffres de production de DeepSeek, Petals et d'autres (feuille de route, pas livré).

Notre propre mesure, publiée sans détour : le dispatch coûte environ 110 KB par token par couche — 12.3 KB à l'aller (dispatch) plus 98.3 KB au retour (combine). L'asymétrie de 8× vient de ce que chaque expert sélectionné renvoie sa sortie complète *avant* la somme pondérée. En lien direct, c'est un surcoût de débit de 1.2 % ; via un relais CDN, ~28 %. Voilà les faits. Le reste de ce billet, c'est comment nous entendons combler l'écart — et pourquoi les octets sont la partie facile.

Le résultat publié le plus important ici n'est pas le nôtre — c'est celui de Petals : quand le RTT passe de <5 ms à 100 ms, le décodage chute de 1.24 à 0.57 steps/s, tandis qu'une coupe de bande passante de 10× ne le change que de ~0. La latence domine ; la bande passante a du mou. Cela recadre tout le problème : rogner des octets, c'est de la marge, mais couper les allers-retours, c'est la substance. Chaque point ci-dessous est classé selon la quantité de coût d'aller-retour qu'il retire.

• Renvoyer des sommes partielles pondérées, pas les sorties brutes des experts. Par linéarité, le combine du backbone est exact dans les deux cas, mais le worker renvoie un seul vecteur sommé au lieu de 8 — c'est la réduction ~8× du combine, et c'est précisément ce que font DeepSeek-V3 / DeepEP en production.
• Étoile parallèle, pas chaîne série sur plusieurs workers : ΣRTT s'effondre à max RTT.
• F16 sur le fil — nous acceptons déjà un cosine inter-backends de ~0.998, le transport F16 est donc dans la tolérance existante ; INT8/FP8 par blocs plus tard, une fois que notre propre porte argmax/cosine l'aura validé face aux poids Q4_K_M (Petals a montré de l'INT8 sur l'internet réel sans perte de qualité).
• Ensemble, ceux-ci visent ~110 KB → 9–12 KB par token (~12×) — réel, mais rappelez-vous que c'est la *marge*, pas le goulot.

• Le décodage spéculatif transforme plusieurs tokens en un seul aller-retour. À un WAN mesuré de 80 ms, le seuil de rentabilité n'est que de ~1.15–1.2 tokens acceptés par pas — même une faible supposition n-gram l'emporte donc (le Jacobi vanilla peut se retourner contre soi ; le choix de la technique compte). Notre protocole de dispatch porte déjà n_tokens > 1, aucun changement sur le fil n'est donc nécessaire.
• Le lotissement continu au gateway replie les requêtes concurrentes en un seul trajet ; le cache de préfixes à affinité de slot garde une session sur les mêmes répliques.
• Masquage de latence : l'expert partagé est un terme additif indépendant, le backbone le calcule donc *localement* pendant l'aller-retour distant (ScMoE rapporte 1.82× sur PCIe, sans réentraînement). Gardez les hot experts en local, n'envoyez à distance que les froids (EPLB réplique les ~32 plus chauds pour une accélération de décodage de 2.54× en production).

Politique de chemin : les pairs routables publiquement prennent la voie directe (la route à 1.2 %) ; le relais est réservé aux seuls appareils derrière NAT. Et quand arriveront de larges liens 200 Gb/s, les 110 KB se sérialisent en ~4.4 µs — le terme de bande passante disparaît avant même les réductions ci-dessus, et une tranche de 794 MB s'expédie en ~32 ms. Mais le RTT, c'est de la physique ; il ne rétrécit pas — le décodage spéculatif et le chevauchement restent donc les vrais leviers, même à 200 G. Là où le gros tuyau compte réellement, c'est la fédération multi-backbone (plusieurs backbones partageant un pool d'experts) et le travail borné par la bande passante : prefill de prompts longs et débit à gros lots.

Notre hook de dispatch se pose sur build_moe_ffn — une seule fonction que partagent 43 architectures MoE dans le moteur d'inférence. Trois invariants sont indépendants du modèle : le calcul MoE (routé = Σ wᵢ·Eᵢ(x), linéaire), la voie de code partagée, et les tenseurs d'experts empilés standard de GGUF (ne[2] le plus externe → découpe alignée sur les blocs). Intégrer un nouveau modèle n'est donc pas une refonte — c'est un seul passage par une porte de vérification argmax/cosine propre au modèle.

L'industrie converge vers le MoE à grain fin — des experts plus petits, plus nombreux, une sparsité plus élevée (DeepSeek, Qwen, Kimi, GLM, gpt-oss ont tous pris cette voie). Chaque pas dans cette direction rend l'unité de participation de l'essaim plus petite et le grain du marché de rareté plus fin. Les modèles ci-dessus ne sont pas une liste de souhaits ; chacun passe déjà par le même hook de dispatch que nous exécutons sur notre flotte de test — l'intégration est une porte de vérification, pas un projet d'ingénierie.