Das SGLang-Team und das Ling-Infra-Team von Ant Group haben am 21. August ein gemeinsames Optimierungsprotokoll veröffentlicht: Beim Betrieb von Ling-3.0-flash auf vier Blackwell-GPUs senkten sie die Zeit pro ausgegebenem Token (TPOT) bei einer Nebenläufigkeit von 1 von 3,33 Millisekunden auf 1,53 Millisekunden – ein Rückgang um 54 Prozent –, während der Durchsatz von 288 auf 606 Token pro Sekunde stieg. Mit dem selbst trainierten Entwurfsmodell DSpark sank die durchschnittliche TPOT weiter auf 0,78 Millisekunden, der Durchsatz stieg auf 1120 Token pro Sekunde, und im Schnitt wurden pro Runde 9,95 Entwurfs-Token akzeptiert.
Ling-3.0-flash ist ein MoE-Modell mit hybrider linearer Aufmerksamkeit: Von den 42 Schichten nutzen 35 die lineare KDA-Aufmerksamkeit und 7 die volle MLA-Aufmerksamkeit, mit 512 Routing-Experten, einer versteckten Schichtbreite von 2560 und einem Vokabular von rund 157.000 Tokens. Unter bf16 belegen die Gewichte etwa 63 GB pro Karte. Für den Test wurde per Tensor-Parallelität auf vier Teile aufgeteilt, ebenfalls unter bf16.
Eigentlich ist es die GPU, die untätig ist
Diese Optimierung zielt auf den Fall ab, in dem die Batchgröße gleich 1 ist. Die meisten öffentlichen Erfolge bei der Inferenzoptimierung konzentrieren sich auf den Gesamtdurchsatz bei hoher Nebenläufigkeit, weil das die Abrechnungsstruktur der Cloud-Anbieter widerspiegelt. Eine andere Art von Last fühlt sich unmittelbarer an: Nebenläufigkeit gleich 1 – lokal laufende Modelle, Code-Vervollständigung, ein Agent, der eine lange Kette seriell abarbeitet. Nur eine Anfrage läuft zur gleichen Zeit, und der Nutzer starrt auf den Bildschirm und wartet, dass die Wörter erscheinen.
Sinkt die Nebenläufigkeit, wird die GPU untätig. Die Rechenlast pro Dekodierschritt ist so gering, dass sie kaum ins Gewicht fällt – die GPU ist mit ihrer Arbeit fertig und wartet auf die nächste Anweisungsgruppe, die von der CPU kommt. Sobald die Host-Seite an irgendeiner Stelle einen Wert aus dem Grafikspeicher zurücklesen muss, um den nächsten Schritt zu entscheiden, muss die gesamte Pipeline anhalten und auf diese Synchronisation warten.
"at batch 1, look for blocking reads of device values on the host path before anything else, because each one converts the entire host loop from hidden work into a GPU bubble."
Bei einer Nebenläufigkeit von 1 sollte man zuerst nach blockierenden Lesevorgängen von Grafikspeicherwerten auf dem Host-Pfad suchen – jeder einzelne verwandelt den sonst verborgenen Host-Overhead in eine GPU-Blase.
Die Wartezeiten einzeln beseitigen
Die erste Kategorie ist Leerlauf auf der Host-Seite. Der Ansatz besteht darin, die GPU-Synchronisationspunkte bei jedem Schritt zu entfernen: Im KDA-Aufmerksamkeits-Backend wird festgelegt, dass die Sequenzlänge nicht auf die CPU zurückgelesen werden muss, sodass die zugehörigen Indizes durchgehend im Grafikspeicher bleiben. So können die Anweisungen für Schritt k+1 bereits abgeschickt werden, bevor überhaupt bekannt ist, wie viele Entwurfs-Token in Schritt k akzeptiert wurden – der Host muss nicht mehr auf das Ergebnis warten.
Die zweite Kategorie verkürzt die Arbeit auf dem kritischen GPU-Pfad. Mit Programmatic Dependent Launch (PDL) wird das Laden von Gewichten, das nicht vom Ergebnis des vorherigen Kernels abhängt, vorzeitig angestoßen. Routing und MoE werden von zwei Kernel-Starts zu einem einzigen zusammengefasst – bei einer Größenordnung von 512 Experten macht allein der Startaufwand einen spürbaren Unterschied. Die Rechengenauigkeit von Router-Gate und lm_head wurde von fp32 auf bf16 umgestellt, was allein rund 10 Prozent Verbesserung brachte. Der zyklische KDA-Zustand unter spekulativem Dekodieren wird jetzt in Phasen aktualisiert und erst nach erfolgreicher Verifikation endgültig übernommen.
Diese Änderungen sind alle in SGLang eingeflossen: die Aufnahme von Metadaten in CUDA-Graphs, ein zusammengeführter KDA-Verifikationskernel, ein vom Host direkt ausgegebener FlashInfer-Ausführungsplan (der blockierende Grafikspeicher-Rücklesevorgänge überflüssig macht) sowie eine Ablaufreihenfolge, die Entwurf, Verifikation und Erweiterung in einem Schritt zusammenfasst.
Umgerechnet in menschlich spürbare Zeit
Eine grobe Rechnung für eine lange Antwort mit 5000 Token: Bei 3,33 Millisekunden pro Token dauert das Schreiben 16,6 Sekunden; bei 1,53 Millisekunden sind es 7,7 Sekunden; bei 0,78 Millisekunden nur noch 3,9 Sekunden. Derselbe Rechner, dasselbe Modell, derselbe wartende Mensch – der Unterschied reicht von 'schnell noch Tee holen' bis 'fertig, bevor man den Satz zu Ende gesprochen hat'. Dieser Unterschied kommt nicht von neuer Hardware, sondern davon, das Warten auf der Host-Seite restlos zu beseitigen.
Die entscheidende Zahl bei DSpark ist die durchschnittliche Akzeptanzlänge von 9,95. Die Logik des spekulativen Dekodierens besteht darin, dass ein kleines Modell zunächst eine Folge rät und das große Modell sie in einem Durchgang verifiziert – je mehr richtig geraten wird, desto mehr Schritte werden gespart. Eine Akzeptanzlänge nahe 10 bedeutet, dass eine Verifikation des großen Modells fast zehn normale Dekodierschritte ersetzt. Diese Zahl hängt direkt mit der Trainingsweise des Entwurfsmodells zusammen – das Entwurfsmodell von DSpark wurde aus der Ausgabeverteilung von Ling-3.0-flash nach dessen Post-Training destilliert, und die Verlustfunktion enthält einen eigenen Optimierungsterm für die Akzeptanzlänge. Die Trefferquote ist also antrainiert, kein Zufallstreffer.
Eine Zusammenarbeit stromaufwärts
Hinter diesem Protokoll stehen drei gemeinsam genannte Parteien: RadixArk auf SGLang-Seite, das Ling-Infra-Team von Ant sowie inclusionAI von Ant. Die Modellgewichte und die Befehle zur Reproduktion wurden zusammen mit der DSpark-Variante veröffentlicht.
Dass chinesische Open-Source-Modelle in den Ranglisten auftauchen, ist in den letzten Jahren nichts Ungewöhnliches mehr. Ungewöhnlich ist die Mitsprache auf der Ebene des Inferenz-Stacks: Diese Optimierung hat nicht darauf gewartet, dass das Upstream-Framework nachzieht, sondern brachte die eigene Hardware-Rechnung und reale Last mit, änderte den Upstream-Code direkt und führte die Änderungen wieder zusammen. Für alle, die mit demselben Framework deployen, lassen sich diese Schalter einfach umlegen – unabhängig davon, von wem das Modell stammt.
Quellen: offizieller SGLang-Techblog, CocoLoop, öffentliche Modellkarte von Ant inclusionAI; TPOT, Durchsatz und Akzeptanzlänge wurden anhand der im Blog angegebenen Reproduktionsbefehle und Benchmark-Ergebnisse überprüft, jeweils gemessen bei Nebenläufigkeit 1, Tensor-Parallelität auf 4 Karten und bf16.