Baseten verkürzt Delta-Weight-Sync für GLM-5.3 von 36 auf 15 Sekunden

Von der CPU-Kopie zur GPU als Parent

Beim Delta-Weight-Sync veröffentlicht ein Trainer in der Umgebung des Kunden vollständige Checkpoints und dünnbesetzte Deltas in einem Objektspeicher. Laut Baseten ist jeder Delta-Tensor als zstd(parent_bytes XOR new_bytes) abgelegt. Sobald ein Snapshot hochgeladen ist, schickt der Trainer eine Sync-Anfrage, in der er die gewünschte Policy benennt. Rollout-Cluster laden jedes Objekt einmal über das Baseten Delivery Network (BDN) herunter, rekonstruieren die neue Policy und aktualisieren ihre GPUs direkt im Speicher. Trainer- und Rollout-GPUs teilen sich keine Infrastruktur, daran ändert sich nichts.

Das erste Design hielt den vollständigen Parent-Checkpoint im Host-Speicher, weil der Decoder ihn brauchte, um XOR-Bytes in neue Werte umzurechnen. Baseten nennt drei Nachteile. Jedes Replikat belegte für GLM-5.3 rund 770 GB Host-RAM. Auf einem 8×B300-Knoten passten diese Kopie und ein 1,1 TB großer Host-KV-Cache nicht gleichzeitig hinein, sodass der Cache auf 275 GB schrumpfen musste. Die Übernahme der CPU-Kopie in die neue Policy dauerte pro Update etwa 45 Sekunden und blockierte das nächste Delta. Und jedes Update musste sowohl auf der GPU als auch auf der CPU-Kopie landen, wodurch zwei Wahrheitsquellen entstanden.

Im neuen Design wird das Modell beim Start aus einer lokalen Kopie auf der Festplatte geladen. Jeder bereitgestellte Tensor wird über das GPU-Layout der Engine dagegen geprüft, eine Adler-32-Prüfsumme pro Tensor wird gespeichert, und die Kopie wird gelöscht. Ab dann hält der GPU-Speicher den einzigen Parent.

So funktioniert das Update

Trifft ein Delta ein, geht der native Decoder von Baseten die zstd-Befehle direkt durch und behält nur die XOR-Bytes ungleich null: die Position und die XOR-Maske jedes geänderten Elements. Den dichten XOR-Tensor baut er nie auf und liest auch keine Modellgewichte. Während die alte Policy weiter Anfragen bedient, sammelt jeder GPU-Worker die alten Werte an den geänderten Positionen ein, wendet die XOR-Maske an, um absolute neue Werte zu erhalten, prüft das Ergebnis gegen die Prüfsumme des Trainers und überführt die Werte in einen Schreibplan im nativen Tensor-Layout der Engine.

Auch der Prüfsummenschritt ist günstiger geworden. Da jedes Byte unabhängig zu Adler-32 beiträgt und nur von seiner Position und seinem Wert abhängt, lässt sich der Effekt eines geänderten Bytes in konstanter Zeit berechnen. Baseten startet mit der beim Start gespeicherten Prüfsumme, addiert pro geändertem Byte eine Korrektur und vergleicht das Ergebnis mit dem des Trainers. Laut Unternehmen wurde dadurch das gesamte Update um bis zu 2,3-fach schneller: Ein Kimi-K3-Update mit einem 30-GB-Delta sank von rund 230 auf rund 100 Sekunden. Ein beschädigter Download oder ein falscher Parent wird abgelehnt, bevor etwas auf die GPU geschrieben wird.

Innerhalb der Pause schließt das System die Annahme neuer Anfragen und hält laufende Requests an Ort und Stelle an, schreibt neue Werte und aktualisiert abgeleitete Gewichte, veröffentlicht dann die neue Policy-Version und öffnet die Annahme wieder. Bei GLM-5.3 beträgt die Pause 0,8 statt 6 Sekunden, und die 45-sekündige CPU-Übernahme entfällt.

Weil sich Update-Arbeit nun GPUs und CPUs mit dem Serving teilt, hat Baseten weitere Maßnahmen ergriffen:

• Ein parallelitätsbewusster Decoder, der jedes Delta danach aufteilt, welche GPU welche Änderung besitzt, und Änderungen auf Adressen im gepackten Layout dieser GPU abbildet, einschließlich geswizzelter FP8- und FP4-Skalierungsfaktoren.
• Update-Planung in einem separaten, CUDA-freien Hilfsprozess, damit CPU-intensive Arbeit nicht um den GIL in der Python-Scheduler-Schleife von SGLang konkurriert.
• Pipeline aus Download und Dekodierung, bei der jeder Shard direkt nach dem Eintreffen dekodiert wird, auf nativen Threads mit niedriger Priorität, die so dimensioniert sind, dass 16 Kerne für das Serving frei bleiben.

Kimi K3 auf GB300 und KV-Cache-Offloading

Kimi K3 umfasst in seinem bereitgestellten MXFP4-Layout 1,7 TB. Mit einem CPU-Checkpoint bräuchte laut Baseten jeder GB300-Knoten für seine Hälfte der Gewichte rund 838 GB Host-Speicher, fast das gesamte Speicherlimit eines Serving-Containers. Das Unternehmen nennt dies eine harte Einschränkung, da GB300-Systeme mit vorkonfigurierter Hardware geliefert werden. Das neue Design läuft auf zwei GB300-Knoten mit je vier GPUs. Jeder Knoten dekodiert, verifiziert und stagt nur die Tensoren, die ihm gehören, und beide müssen erfolgreich schreiben, bevor die neue Policy veröffentlicht wird. Bei einem 8,4-GB-Delta vergehen bei Kimi K3 von der Sync-Anfrage bis zu den aktiven Gewichten 75 Sekunden, bei einer Pause von 4,1 Sekunden.

Der frei gewordene Host-Speicher lässt sich außerdem als KV-Cache-Ebene nutzen. Aus der GPU verdrängte KV-Seiten werden in den Host-Speicher zurückgeschrieben statt verworfen, sodass eine spätere Anfrage mit demselben Präfix sie neu lädt, anstatt das Prefill erneut auszuführen. Baseten gibt an, dass das Nachladen eines verdrängten Präfixes mit 150.000 Tokens aus dem CPU-Speicher 0,48 Sekunden dauert, gegenüber 4,9 Sekunden bei einem frischen Prefill.

Im AgentX-Benchmark mit Kimi K3 verglich Baseten das Offloading im neuen Design mit dem alten CPU-Checkpoint-Setup. Bei einer Parallelität von 16 passt der KV-Cache auf die GPU, es gibt also keinen Unterschied. Bei einer Parallelität von 48 steigt die Trefferquote von 2 auf 92 Prozent, und der Ausgabedurchsatz pro GPU wächst um das 3,2-Fache.

Was das für Nutzer von RL-Rollouts bedeutet

Für Teams, die Rollouts im Reinforcement Learning betreiben, bedeuten kürzere Syncs und Pausen, dass die bereitgestellte Policy dem Trainer schneller folgt und das nächste Delta angewendet werden kann, sobald es eintrifft. Laut Baseten ermöglicht das Design zudem Kimi-K3-RL-Rollouts auf 8:GB300, die bisher durch den CPU-Speicher blockiert waren.

Baseten weist darauf hin, dass alle Läufe mit einem Replikat und trainerförmigen Fixture-Deltas liefen, gemessen von der Sync-Anfrage des Trainers bis zur ersten neuen Antwort. Interessierte Teams verweist das Unternehmen auf seine Dokumentation zu RL-Rollouts oder auf sein Team.