Am 21. August haben das Ant-Ling-Infrastrukturteam, Alibaba und das SGLang-Team im LMSYS-Blog eine Komponente namens Weight Cache Daemon vorgestellt: ein dauerhaft im GPU-Speicher laufender Prozess, der quantisierte und bereits aufgeteilte Gewichte auf der GPU hält, sodass eine neu gestartete Inferenz-Engine sie per CUDA IPC per Zero-Copy übernehmen kann. Die Zahlen des Teams: Das Laden der FP8-Gewichte von Ling-2.6-1T sinkt von rund 495 Sekunden auf 0,63 Sekunden, der gesamte Start von 8,8 Minuten auf 0,528 Minuten.
Acht der achteinhalb Minuten gehen fürs Lesen von der Platte drauf
Das Team hat einen kompletten Start in Einzelteile zerlegt. Ling-2.6-1T FP8 läuft auf 8 H20-3e-GPUs, die Gewichte liegen auf einer 3,5-TB-NVMe-SSD; vom Start bis zur Betriebsbereitschaft vergehen rund 527 Sekunden. Davon entfallen 495 Sekunden – 93,9 Prozent – auf das Laden der Gewichte; die Tokenizer-Initialisierung braucht 13 Sekunden, die verteilte Torch-Initialisierung 5 Sekunden, die CUDA-Graph-Aufzeichnung 7,7 Sekunden, der Rest zusammen weniger als 6 Sekunden.
Jede Karte muss rund 120 GB Safetensors von der Platte lesen, deserialisieren, tensor-parallel aufteilen und anschließend FP8-quantisieren und neu anordnen – insgesamt 161 Shards. Diese Pipeline läuft bei jedem Neustart komplett neu, obwohl ihr Ergebnis deterministisch ist: Bei gleichem Modell und gleicher Konfiguration landen am Ende immer dieselben Tensoren im Speicher – und die liegen häufig noch dort, wo der vorherige Prozess sie hinterlassen hat, kaum dass er beendet wurde.
Für den Produktivbetrieb bedeuten diese paar Minuten, dass die P99-Tail-Latenz während des Neustarts stark ansteigt, laufende Anfragen komplett fehlschlagen oder endlos in der Warteschlange hängen und Rolling Updates wie Fehlerwiederherstellung durch genau diesen Zyklus ausgebremst werden.
Die Gewichte bleiben im Speicher liegen
Auf jeder GPU läuft ein Daemon-Prozess, einer pro TP Rank. Er lädt einmal nach der kompletten Pipeline von der Platte und exportiert danach alle Parameter und Buffer aus model.state_dict() als CUDA-IPC-Handles, die er über einen Unix Socket an sich verbindende Engine-Prozesse weitergibt. Die Engine baut die Modellstruktur zunächst auf dem meta device auf, ohne Speicher zu reservieren, und lässt dann die data-Pointer jedes Parameters auf die gemappten Tensoren zeigen. Beide Prozesse teilen sich denselben physischen Speicher, ganz ohne Kopiervorgang. Auch Nachbearbeitungsparameter wie weight_scale, die während der FP8-Quantisierung entstehen, werden mitgecacht – die erneute Quantisierung entfällt damit.
Zwei Sicherheitsschranken sind eingebaut. Die eine ist ein Konfigurations-Fingerabdruck: Modellpfad, TP/PP/DP-Aufteilung, Quantisierungsmethode samt Konfigurations-Hash und dtype müssen übereinstimmen, dazu kommen GPU-Rechenkapazität und Torch-Version als Umgebungsmerkmale. Der Hintergrund: Unterschiedliche Architekturen oder Torch-Versionen durchlaufen andere Nachbearbeitungspfade – die Gewichte lassen sich zwar sauber mappen, ergeben dann aber Unsinn. Indem die Umgebung Teil des Fingerabdrucks wird, wird aus diesem unsichtbaren Fehler eine klare Nichtübereinstimmung, die zum Laden von der Platte zurückfällt.
Die andere Schranke ist eine Whitelist der Quantisierungsmethoden. Derzeit sind nur keine Quantisierung und block-wise FP8 verifiziert; per-tensor FP8, Marlin sowie AWQ/GPTQ lösen sofort einen Fehler aus. Der Grund: CUDA IPC exportiert nur die rohen Tensordaten, während diese Methoden einen Teil ihrer Wirkung in Python-seitigen Metadaten ablegen oder die Gewichte umordnen und transponieren – gemappt kämen dabei falsche Werte heraus. Das Team lässt es lieber hart fehlschlagen, als stillschweigend falsche Ergebnisse zu liefern.
Stürzt der Daemon ab, bleibt die laufende Engine unberührt – der CUDA-Referenzzähler läuft weiter, und der Speicher wird erst freigegeben, wenn beide Seiten beendet sind. Startet der Daemon neu, liest er erneut von der Platte und exportiert die Handles neu, erst dann kann sich eine neue Engine wieder verbinden.
Nebenbei gelöst: die Kostenfrage des Hot Standby
Die Komponente kennt drei Modi: daemon (die Engine startet den Daemon selbst, der erste Start bleibt langsam), client (verbindet sich mit einem bereits laufenden Daemon, Neustart in Sub-Sekunden) und off (Standard, läuft über die Platte – bei Ling-2.6-1T dauert das 405 bis 411 Sekunden).
Praktisch relevanter als die reine Start-Beschleunigung sind mehrere Einsatzmuster. Mehrere Engine-Instanzen auf derselben Karte mappen dieselben Gewichte – die Platte wird nur einmal gelesen, die Quantisierung nur einmal ausgeführt. Ein hochpriorer Online-Dienst und ein niedrigpriorer Offline-Batch-Job teilen sich eine Karte; wird Letzterer verdrängt, ist er in Sub-Sekunden wieder einsatzbereit. Beim Failover übernimmt die Standby-Engine per Zero-Copy dieselben Gewichte und bleibt heiß – fällt die Primärinstanz aus, übernimmt sie innerhalb einer Sekunde.
Der letzte Punkt ist ein handfester Kostenfaktor. Grob gerechnet: Eine Ling-2.6-1T-Instanz belegt 8 H20-3e-Karten; klassisches Hot Standby bedeutet, dass acht weitere Karten daneben ungenutzt mitlaufen. Mit gemeinsam genutzten Gewichten entfällt genau diese dauerhaft belegte Kartengruppe. Bei Rolling Updates gilt Ähnliches: Bei rund 8,8 Minuten pro Zyklus verbrennt jede Instanz je Neustart-Runde etwa 1,2 GPU-Stunden im Leerlauf – bei einem Cluster mit hundert und mehr Instanzen summiert sich ein einziges Upgrade auf dreistellige GPU-Stunden.
Noch nicht am Ziel
Weight Cache Daemon ist die erste Ausbaustufe des Fast Engine Recovery Framework. Auf der Roadmap stehen Kaltstarts unter 10 Sekunden und Hot-Standby-Failover unter 1 Sekunde. Als Nächstes sind CUDA-Graph-Serialisierung, Kernel-Caching und die Optimierung der verteilten Initialisierung geplant. Laut der oben genannten Aufschlüsselung summieren sich diese Posten auf rund 26 Sekunden – genau das, was nach den Gewichten als größter Brocken übrig bleibt.
Auch Zahlen für die Qwen3-235B-FP8-Klasse wurden veröffentlicht: rund 235 GB Gewichte, 306 bis 327 Sekunden beim Laden von der Platte, unter einer Sekunde beim IPC-Mapping – etwa Faktor 500. Bei Ling-2.6-1T sind es rund Faktor 780.
Im Blogbeitrag wird nebenbei das gerade veröffentlichte 2,8T-Modell Kimi K3 erwähnt. Steigt die Parameterzahl, wächst die Ladezeit von der Platte linear mit – das IPC-Mapping bleibt dagegen praktisch konstant, und diese Differenz wird mit jedem größeren Modell größer. Für Teams, die bereits Modelle im Billionen-Parameter-Bereich betreiben, wandelt sich der Preis eines Neustarts gerade von „ein paar Minuten warten" zu „fast kein Warten mehr" – und das wirkt sich nicht nur auf Verfügbarkeitszahlen aus, sondern auch darauf, wie mutig man Konfigurationen ändert und wie bereitwillig man zwei Dienste auf derselben Karte unterbringt.
Quellen: LMSYS-Org-Techblog, CocoLoop, SGLang-Projektdokumentation; die Aufschlüsselung der Startzeit sowie die Vergleichszahlen zu Gewichtsladen und IPC-Mapping stammen aus der vom Team veröffentlichten Single-Node-Benchmark-Tabelle.