Belasting-adaptieve schaling

Kvasirs MoE-serveerpad groeit en krimpt met het verkeer: de coördinator schakelt bewezen workers opnieuw in onder verzadiging, en de bridge werft inactieve nodes door de expertvraag te verhogen — alles pull-gebaseerd, zodat ook NAT-apparaten meedoen.

Kvasirs MoE-serveerpad schaalt elastisch mee met de belasting, in twee samenwerkende lagen. Bij rust serveert de coördinator alles lokaal voor het snelste pad per token; bij verzadiging laten de twee lagen hieronder de zwerm groeien — en krimpen hem weer wanneer de piek voorbij is.

Engine-status. Sharding op expertkorrel is gebouwd en gedemonstreerd op Kvasirs vorige engine, en de resultaten hieronder komen uit dat werk. De huidige engine, [p4](/wiki/p4), serveert vandaag op laagkorrel; het overzetten van expert-sharding daarnaartoe is ontworpen en in uitvoering. Waar een detail een tool of een route noemt, is dat de tool of route die op de vorige engine draaide.

Laag 1

Coördinatorkant: belasting-adaptieve dispatch

De backbone-coördinator (een linkcpp-server die het volledige model draait) serveert gerouteerde experts ofwel op zijn eigen GPU (snel, lokaal) ofwel door ze naar externe workers te dispatchen. Een achtergrondthread beslist elke paar seconden welke van de twee:

  • Hij pollt zijn eigen inferentieslots. Wanneer busy >= saturation threshold (standaard 2) staat de coördinator onder belasting.
  • Onder belasting, als een bewezen worker live is — een waarvan last_serve_ms > 0, d.w.z. hij heeft daadwerkelijk eerder experts berekend — blijft de coördinator ernaartoe dispatchen voorbij de normale inactiviteitstimeout, en geeft zo voorrang aan totale doorvoer boven latentie per token.
  • Een worker die verbinding maakte maar nooit serveerde (een telefoon die de relay belde maar nooit rekende) wordt niet geworven onder belasting, omdat ernaartoe dispatchen het snelle lokale pad zou vervangen door een trage fallback. Nieuwe workers krijgen nog steeds een eerste poging via een kort respijtvenster.
  • De zelfquery is in tijd begrensd zodat een vastgelopen poll de dispatch nooit kan blokkeren.
Laag 2

Besturingsvlakkant: belasting-adaptieve werving

Het besturingsvlak bewaakt elke MoE-coördinator en laat de workerpool groeien wanneer dat nodig is:

  • Een achtergrondlus pollt de slots van elke coördinator en registreert verzadiging per model.
  • Zolang een model verzadigd is, wordt zijn effectief expert-replicadoel verhoogd (base + boost). De dekkingsmarkt leest dan al-gedekte experts opnieuw als schaars, en een model met geen live workers wordt geseed vanuit zijn GGUF-metadata (aantal experts), zodat de vraag zelfs vanaf nul zichtbaar is.
  • Inactieve nodes pollen de vraagmarkt (/api/expert-volunteer) en krijgen een (layer, expert-range)-plak toegewezen om te serveren. Ze downloaden de plak, bellen de relay en registreren dekking; het besturingsvlak bedraadt ze automatisch in de dispatch-map van de coördinator.
  • Wanneer de belasting wegebt, valt het doel terug en verdwijnt de vraag, zodat de extra workers niet meer gedispatcht worden en na verloop van tijd wegvallen.

Het ontwerp is pull-gebaseerd: nodes vragen om werk in plaats van dat het naar hen wordt geduwd, zodat een worker achter NAT meedoet zonder enige inkomende connectiviteit. Een in Laag 2 geworven node die begint te serveren wordt een bewezen worker die Laag 1 vervolgens onder belasting ingeschakeld houdt — de twee lagen componeren tot één elastische lus.

Observability: GET /api/moe/recruitment rapporteert busy/saturation per model en de base- versus effectieve target; /api/expert-demand draagt een recruiting-vlag.