Beim Betrieb eines auf GLM-5 basierenden Coding Agents im Umfang von mehreren hundert Millionen Anfragen werden der Reproduktions- und Behebungsprozess zweier KV-Cache-Race-Condition-Bugs sowie Optimierungen zur Verbesserung des Durchsatzes vorgestellt.
Hintergrund
Scaling Laws treiben nicht nur Innovationen bei Modellparametern und Datenumfang voran, sondern bringen auch das Infrastruktur-Engineering an seine Grenzen. Z.ai nennt die dabei entstehenden Nebenwirkungen Scaling Pain.
Während mit der GLM-5-Serie komplexe Coding-Agent-Workloads in einer Größenordnung von mehreren hundert Millionen pro Tag verarbeitet wurden, berichteten einige Nutzer über Anomalien wie verzerrte Ausgabe (garbled output), wiederholte Generierung und die Erzeugung seltener Zeichen. Diese Probleme ließen sich in Standard-Inferenzumgebungen überhaupt nicht reproduzieren und traten nur in Umgebungen mit hoher Parallelität und langem Kontext auf.
Zusammenfassung der wichtigsten Ergebnisse
| Element | Wert |
|---|---|
| Anteil an fehlerhaften Ausgaben nach Anwendung von Bug Fix #1 | 0,1 % → unter 0,03 % |
| Durchsatzverbesserung durch LayerSplit (40K~120K Token) | +10 % ~ +132 % |
| HiCache-Fix als Beitrag zu SGLang PR #22811 | ✅ |
Erkennung von Anomalien: Nutzung von Speculative-Decoding-Metriken
Bereits die automatische Erkennung solcher Anomalien war eine schwierige Aufgabe. Heuristiken wie reguläre Ausdrücke produzierten viele False Positives und False Negatives, und modellbasierte Klassifikatoren waren für groß angelegte Experimente zu teuer.
Der Durchbruch kam durch Speculative-Decoding-Metriken.
- Verzerrte Ausgabe / seltene Zeichen:
spec_accept_lengthist extrem niedrig → Signal für eine Inkonsistenz des KV-Cache-Zustands zwischen Draft-Modell und Target-Modell - Wiederholte Generierung:
spec_accept_rateist extrem hoch → Signal, dass durch einen beschädigten KV-Cache das Attention-Muster in eine Wiederholungsschleife konvergiert
Darauf aufbauend wurde eine Online-Monitoring-Strategie implementiert. Sobald mehr als 128 Token generiert wurden und spec_accept_length < 1.4 oder spec_accept_rate > 0.96 gilt, wird die Generierung sofort abgebrochen und ein Retry über den Load Balancer angestoßen. Damit wurde Speculative Decoding von einem Performance-Optimierungswerkzeug zu einem Echtzeit-Monitoring-Werkzeug für Ausgabequalität erweitert.
Bug Fix #1: KV-Cache-Race-Condition in einer PD-Entkopplungsarchitektur
Ursache
In einer PD-(Prefill-Decode)-Entkopplungsarchitektur wird zur Kontrolle der Tail Latency ein timeoutbasierter Mechanismus zum Abbruch von Anfragen eingesetzt. Wenn Prefill nicht innerhalb der vorgegebenen Zeit abgeschlossen wird, bricht die Decode-Seite die betreffende Anfrage ab und gibt den KV-Cache frei.
Das Problem war, dass das Abort-Signal nicht korrekt an die Prefill-Seite übermittelt wurde. Selbst nachdem Decode den KV-Cache freigegeben und einer neuen Anfrage (Req2) neu zugewiesen hatte, liefen die RDMA-Write-Operationen und die Prefill-Berechnung der vorherigen Anfrage (Req1) weiter und überschrieben den KV-Cache von Req2.
Behebung
Nach dem Auslösen eines Abort sendet Decode nun eine Benachrichtigung an die Prefill-Seite, und Prefill gibt nur dann ein „sicher freigebbar“-Signal zurück, wenn eine der folgenden beiden Bedingungen erfüllt ist.
- Der RDMA-Write hat noch nicht begonnen
- Alle bereits ausgelösten Write-Operationen sind abgeschlossen
Erst nach dieser Bestätigung verwendet Decode den KV-Cache erneut. Dadurch sank der Anteil fehlerhafter Ausgaben von 0,1 % auf unter 0,03 %.
Bug Fix #2: Fehlende Garantie der Load-Use-Reihenfolge in HiCache
Ursache
Coding-Agent-Workloads haben eine durchschnittliche Eingabelänge von über 70K Token und eine hohe Wiederverwendungsrate von Präfixen. Dafür kommt HiCache (hierarchischer KV-Cache) zum Einsatz, bei dem der KV-Cache asynchron aus dem CPU-Speicher eingelagert wird, während Load Stream und Forward Stream überlappend ausgeführt werden.
Das Problem war, dass der Indexer-Kernel keine Synchronisationsvorgabe mit dem Abschluss des Ladens des Indexer-Cache spezifizierte. Wenn der Forward Stream vor dem Load Stream mit der Ausführung beginnt, entsteht ein read-before-ready-Muster, bei dem auf einen noch nicht geladenen KV-Cache zugegriffen wird, was zu fehlerhaften Ausgaben führte.
Behebung
Vor der Ausführung des Indexer-Kernels wurde ein expliziter Synchronisationspunkt mit dem Load Stream eingefügt, sodass der Forward Stream Berechnungen erst dann fortsetzt, wenn die Daten vollständig bereitstehen. Diese Korrektur wurde als PR #22811 in die SGLang-Community eingebracht.
Optimierung: LayerSplit (verteilte Speicherung des KV-Cache auf Layer-Ebene)
Der gemeinsame Flaschenhals beider Bugs war die Last in der Prefill-Phase selbst. Um dies grundlegend zu verbessern, wurde LayerSplit entworfen und implementiert.
Bisher speicherte in einer Context-Parallelism-(CP)-Umgebung jede GPU den KV-Cache aller Layer redundant. Mit LayerSplit wird die Speicherung so verteilt, dass jede GPU nur einen Teil der Layer übernimmt, wodurch der Speicherverbrauch pro GPU deutlich sinkt.
Zur Laufzeit broadcastet der CP-Rank, der den KV-Cache des jeweiligen Layers besitzt, den Cache vor der Attention-Berechnung. Durch die überlappende Ausführung von Broadcast und Indexer-Berechnung wurde der Kommunikations-Overhead verborgen; da zusätzlich nur Daten des Indexer-Cache übertragen werden müssen (etwa 1/8 der Größe des KV-Cache), ist der gesamte Overhead vernachlässigbar.
Bei einer Cache-Hit-Rate von 90 % wurde für Anfragen mit 40K~120K Token ein um 10 % bis 132 % höherer Durchsatz erzielt; je länger der Kontext, desto größer die Verbesserung.
Fazit
> „Durchsatz, Latenz und Verfügbarkeit allein reichen nicht aus. Ein System muss hinter jeder Generierungsanfrage auch die Korrektheit des Modellzustands gewährleisten. Scaling Laws treiben die Fähigkeiten voran, aber dass diese Fähigkeiten im großen Maßstab verlässlich nutzbar werden, ist allein gründlichem System-Engineering zu verdanken.“
Quelle: Z.ai Research Blog (2026-04-30)
Noch keine Kommentare.