Last-adaptive Skalierung

Kvasirs MoE-Serving-Pfad wächst und schrumpft mit dem Verkehr: Der Koordinator reaktiviert bewährte Worker unter Sättigung, und die Bridge rekrutiert brachliegende Knoten, indem sie die Experten-Nachfrage erhöht — alles pull-basiert, sodass auch NAT-Geräte beitreten.

Kvasirs MoE-Serving-Pfad skaliert elastisch mit der Last, in zwei zusammenwirkenden Schichten. Wenn es ruhig ist, bedient der Koordinator alles lokal für den schnellsten Pfad pro Token; wenn er sättigt, lassen die beiden Schichten darunter den Schwarm wachsen — und schrumpfen ihn wieder, wenn der Andrang vorbei ist.

Engine-Status. Experten-Sharding wurde auf Kvasirs vorheriger Engine gebaut und vorgeführt, und die Ergebnisse unten stammen aus dieser Arbeit. Die aktuelle Engine, [p4](/wiki/p4), bedient heute auf Layer-Körnung; die Übertragung des Experten-Shardings darauf ist entworfen und in Arbeit. Wo ein Detail ein Werkzeug oder eine Route benennt, ist es das, was auf der vorherigen Engine lief.

Schicht 1

Koordinator-Seite: last-adaptiver Dispatch

Der Backbone-Koordinator (ein linkcpp-server, der das vollständige Modell ausführt) bedient geroutete Experten entweder auf seiner eigenen GPU (schnell, lokal) oder indem er sie an entfernte Worker disponiert. Ein Hintergrund-Thread entscheidet alle paar Sekunden, welches von beidem:

  • Er pollt seine eigenen Inferenz-Slots. Wenn busy >= saturation threshold (Standard 2), steht der Koordinator unter Last.
  • Unter Last, wenn ein bewährter Worker aktiv ist — einer mit last_serve_ms > 0, d. h. er hat tatsächlich schon Experten berechnet —, disponiert der Koordinator weiter an ihn über den normalen Idle-Timeout hinaus und bevorzugt den Gesamtdurchsatz gegenüber der Latenz pro Token.
  • Ein Worker, der sich verbunden, aber nie bedient hat (ein Smartphone, das sich ins Relay eingewählt, aber nie gerechnet hat), wird unter Last nicht rekrutiert, weil ein Dispatch an ihn den schnellen lokalen Pfad durch einen langsamen Fallback ersetzen würde. Neue Worker bekommen dennoch einen ersten Versuch über ein kurzes Kulanzfenster.
  • Die Selbstabfrage ist zeitlich begrenzt, sodass ein hängender Poll niemals den Dispatch blockieren kann.
Schicht 2

Steuerungsebene: last-adaptive Rekrutierung

Die Steuerungsebene beobachtet jeden MoE-Koordinator und vergrößert den Worker-Pool bei Bedarf:

  • Eine Hintergrundschleife pollt die Slots jedes Koordinators und erfasst die Sättigung pro Modell.
  • Solange ein Modell gesättigt ist, wird sein effektives Experten-Replika-Ziel angehoben (Basis + Boost). Der Abdeckungsmarkt liest bereits abgedeckte Experten dann wieder als knapp, und ein Modell ohne aktive Worker wird aus seinen GGUF-Metadaten (Expertenanzahl) geseedet, sodass die Nachfrage selbst von null an sichtbar ist.
  • Brachliegende Knoten pollen den Nachfragemarkt (/api/expert-volunteer) und bekommen eine (layer, expert-range)-Scheibe zum Bedienen zugewiesen. Sie laden die Scheibe herunter, wählen sich ins Relay ein und registrieren Abdeckung; die Steuerungsebene verdrahtet sie automatisch in die Dispatch-Map des Koordinators.
  • Wenn die Last abebbt, fällt das Ziel zurück und die Nachfrage verschwindet, sodass die zusätzlichen Worker nicht mehr disponiert werden und herausaltern.

Das Design ist pull-basiert: Knoten fragen nach Arbeit, statt geschoben zu werden, sodass ein Worker hinter NAT ohne eingehende Konnektivität teilnimmt. Ein in Schicht 2 rekrutierter Knoten, der zu bedienen beginnt, wird zu einem bewährten Worker, den Schicht 1 dann unter Last engagiert hält — die beiden Schichten fügen sich zu einer einzigen elastischen Schleife zusammen.

Beobachtbarkeit: GET /api/moe/recruitment meldet pro Modell busy/saturation und das Basis- gegenüber dem effektiven Ziel; /api/expert-demand trägt ein recruiting-Flag.