Am 21. August 2026 kündigten das RadixArk SGLang-Team und das Ant Ling Infra-Team die Single-Request-Dekodierungsoptimierungsergebnisse für Ling-3.0-Flash auf dem offiziellen LMSYS-Blog an. In einer festen Umgebung mit 4 NVIDIA Blackwell-GPUs, TP4, bf16 und Nebenläufigkeit auf 1 erhöhte der optimierte NEXTN-Pfad den durchschnittlichen Ausgabedurchsatz von 288 Tok/s auf 606 Tok/s und reduzierte die durchschnittliche Ausgabe-Token-Zeit von 3,33 Millisekunden auf 1,53 Millisekunden.
Warum ist Batch 1 schwer zu optimieren?
Dieses Ergebnis gilt für ein Szenario mit geringer Nebenläufigkeit, in dem nur eine Anfrage kontinuierlich dekodiert wird. Ohne groß angelegte Anfragen zur gemeinsamen Start- und Planungsauflage spiegeln die Synchronisation zwischen CPU und GPU sowie kleine Startverzögerungen des Kernels direkt die Wartezeiten der Nutzer wider, was es schwieriger macht, den Systemaufwand zu verbergen als die Hochdurchsatz-Batchverarbeitung.
Leistung bedeutet nicht nur, mit einem einzelnen Kern zu verdoppeln
Das Team entfernte zunächst die CPU-Sequenzlängensynchronisation, die den Host bei jedem Schritt einfrieren ließ, sodass die Hostvorbereitung mit der GPU-Ausführung überlappen konnte; Anschließend wird die programmatische Abhängigkeitsinitiierung verwendet, um MoE, Routing, KDA und Total Reduction Pfade zu verbinden, um Lücken zwischen kleinen Kernen zu verringern. Die übrigen Optimierungen umfassen außerdem Operator-Fusion, KDA-Neukalibrierung sowie die Anpassung der Routing-Gate- und Ausgangskopfberechnungen von fp32 auf bf16.
Diese Veränderungen verkürzten gemeinsam die kritischen Wege. Laut offizieller Erklärung sind das BF16-Routergatter und der Ausgangskopf die größten Einzeländerungen nach der strukturellen Anpassung, was zu einer Verbesserung von etwa 10 % führt. Das Team konzentrierte sich nicht ausschließlich auf kurzfristige Spitzen, sondern bewertete die Stabilität anhand der durchschnittlichen Zeit pro Token und der Akzeptanzlänge.
DSpark integrierte außerdem das "Raten von mehr Token" in die Optimierung
Der gleiche Bericht testete auch die spekulative Dekodierung bei DSpark-Konfidenzplanung. In einem kontrollierten Vergleich derselben Maschine, desselben Befehls und 1000 Anfragen erreichte DSpark durchschnittlich 1120 Tok/s, 0,78 ms TPOT und eine durchschnittliche Akzeptanzlänge von 9,95. Sein Vorteil liegt nicht nur in der Schnelligkeit in einem einzelnen Schritt, sondern auch in der Möglichkeit, pro Validierung mehr Prädiktionstoken einzureichen.
Aber 1120 Tok/s können nicht direkt als universelle Geschwindigkeit für alle Aufgaben betrachtet werden. Das Testen verwendet eine feste 8192-Token-Eingabe, 1024-Token-Ausgabe, gierige Dekodierung und synthetische Zufallslasten; Tipp-Inhalt, Ausgabeverteilung, Kontextlänge, Stichprobeneinstellungen und Hardware beeinflussen alle die Akzeptanzrate spekulativer Token. Die offizielle Erklärung behandelt 9,95 auch eindeutig als Ergebnis unter dieser Arbeitsbelastung und nicht als eine inhärente Konstante des Modells.
Was bedeutet das für Einsatzteams?
Diese Optimierung änderte keine Modellparameter oder Antwortqualität; was sich änderte, war, wie das Inferenzsystem die Host-Arbeit, GPU-Kernel und die Entwurfvalidierung anordnet. Niedrige Nebenzeitigkeitslatenz umfasst oft Planung, Kommunikation, numerische Genauigkeit und spekulative Strategien, was es schwierig macht, die tatsächliche Geschwindigkeit ausschließlich auf Basis der Grafikkartenrechenleistung zu erklären.
Reproduktionsexperimente sollten Hardware, SGLang-Version, Ein-/Ausgabelänge und Dekodierungsparameter sperren und dann TPOT, Durchsatz und Korrektheit vergleichen. Die direkte Anwendung von experimentellen Zahlen auf verschiedene GPUs oder Geschäftsverkehr führt leicht zu überoptimistischen Kapazitätsschätzungen.
