Sharding d'experts

Découper un MoE au grain de l'expert, pour qu'un téléphone porte 42–340 MB d'experts au lieu d'une couche de 1.4 GB.

Le sharding d'experts abaisse l'unité de portage de l'essaim d'une couche (~1.4 GB sur le 122B) à un expert (5.3 MB). Un appareil faible télécharge une tranche de 8–64 experts (42–340 MB), la charge comme worker à fonction pure — sans attention, sans KV, sans sampler — et calcule ses experts chaque fois que le routeur du backbone les sélectionne.

État du moteur. Le sharding au grain de l'expert a été construit et démontré sur le moteur précédent de Kvasir, et les résultats ci-dessous proviennent de ce travail. Le moteur actuel, [p4](/wiki/p4), sert aujourd'hui au grain de la couche ; le portage du sharding d'experts vers lui est conçu et en cours. Quand un détail nomme un outil ou une route, c'est celui qui tournait sur le moteur précédent.

Deux rôles

Backbone × worker

Le point de coupe dans une couche MoE (le routeur tourne une fois, sur le backbone).

cur   = ffn_norm(x)                     # backbone
ids,p = top_k(softmax(cur @ router), 8) # backbone — authoritative
send  (cur rows, local_ids) → worker    # ~6 KB per decode step
recv  expert_out            ← worker    # worker: 3 mat-muls
x = x + combine(p, partials) + shared(cur)   # backbone — exact
  • Le backbone garde la voie dense (attention, norms, routeur, expert partagé, combine) et conserve tous les experts en réplique de secours déchargée en RAM, pour tolérer le churn.
  • Les workers (linkcpp-expert-worker --serve) répondent (n_used, n_tokens, cur, sel) → experts sur un flux TCP de longue durée — le même flux que le relais 443 tunnelise pour les téléphones.
  • La couverture s'auto-répare via le marché de couverture d'experts : POST /api/expert-coverage bat le rappel des détentions, GET /api/expert-demand agrège la rareté, et POST /api/expert-volunteer attribue la plage la plus rare, taillée au budget du nœud.
Mesuré, pas promis

Vérifié sur du matériel réel

  • Calcul shardé == monolithique à max|Δ| = 3.6e-12 près (un regroupement exact, pas une approximation).
  • Dispatch inter-processus sur un décodage 122B réel : argmax MATCH, cosine des logits 0.99869 — identique octet pour octet à l'in-process.
  • Un Galaxy S25 a téléchargé de façon autonome sa tranche de 1.58 GB et calculé les experts de la layer-0 à chaque token : 8/8 tokens identiques à l'exécution locale.
  • Un GPU distant à travers l'Internet public — un aller-retour WAN par token — est resté greedy 8/8 identique (cosine 0.99773) : 1.2% de surcoût de débit sur un lien direct, ~28% via une bordure CDN. Le coût honnête d'un dispatch sériel, token par token, et pourquoi le levier du tissu est le traitement par lots, non une latence plus basse.
  • Le dispatch par lots atteint 53k tok/s par worker à batch 512 (ROCm) — la propriété de tissu de débit qui rend l'essaim praticable.