Im Oktober 2026 veröffentlichte Cloudflare einen Vorfall, bei dem KV-Cache-Daten zwischen Anfragen auf Workers AI mit GLM-5.3 offengelegt wurden. Laut Bericht lag das Vorfallfenster zwischen dem 27. August und dem 9. September. 155 Antworten waren betroffen; die zugehörigen Prompts waren jeweils länger als 681,280 Tokens. Die Gesamtzahl der Anfragen im selben Zeitraum wurde nicht genannt. Aus den veröffentlichten Angaben lässt sich daher keine Betroffenheitsquote berechnen. Cloudflare-Vorfallbericht · Koordinierte Offenlegung durch SGLang.

Zunächst die Einordnung für Leser, die keinen Inferenz-Cluster betreiben: Das ist kein allgemeines Risiko sämtlicher KI-APIs. Cloudflare zufolge waren andere Workers-AI-Modelle nicht betroffen; GLM-5.3 wurde am 9. September repariert und der Dienst wiederhergestellt. Der ausdrücklich genannte Umfang betrifft GLM-5.3-Anfragen mit mehr als 681,280 Eingabe-Tokens während des Vorfallfensters. Wer nur eine API aufruft, sollte zuerst prüfen, ob die eigene Nutzung in dieses Szenario fällt. Wer einen eigenen SGLang-Cluster mit getrenntem Prefill und Decode betreibt, kann direkt zu den vier Abnahmekriterien am Ende springen.

Die interessante Frage lautet nicht allgemein „Wie kann ein Modell Daten leaken?“, sondern konkreter: Warum konnte eine bereits zur Ablehnung vorgesehene Anfrage mit einem Platzhalter aus nur einem Token noch in den Prefill-/Decode-Handoff gelangen? Abgelehnt, aber trotzdem weiterverarbeitet – genau das ist der ungewöhnliche Punkt. Hier kamen zwei Probleme zusammen: Das deklarierte Context-Limit war größer als die tatsächlich vom KV-Pool aufnehmbare Länge, und der Ablehnungsstatus beendete die Anfrage am damaligen Einstieg in die disaggregierte Inferenz nicht rechtzeitig. Das erste Problem löste die Ablehnung aus; das zweite ließ die abgelehnte Anfrage auf einem unzulässigen Pfad weiterlaufen.

Die sieben Schritte des von Cloudflare beschriebenen Produktionspfads (PR #36988 war am 6. September bereits gemergt, aber noch nicht in Cloudflares Produktion ausgerollt, als am 9. September die Engine-Korrektur live ging): ① Bootstrap: Der Router übermittelt die ursprüngliche Prompt-Länge an Decode; Decode reserviert die entsprechenden KV-Seiten. ② Prefill admission: Admission prüft req.finished(). Der Ablehnungsgrund steht jedoch in to_finish und nicht in finished_reason. Deshalb kann die Anfrage weiterhin als nicht beendet gelten und zugelassen werden. ③ Prefill forward: Die Prefill-Eingabe wird durch einen Platzhalter aus einem Token ersetzt. ④ KV transfer: Prefill sendet nur die zu diesem Platzhalter gehörende KV-Seite, signalisiert aber transfer-complete. ⑤ Decode admission: Auch die entsprechende Prüfung des Endzustands auf Decode akzeptiert den Handoff. ⑥ Decode attention: Decode liest KV-Seiten bis zur reservierten Länge, obwohl nur die erste Seite von der aktuellen Anfrage beschrieben wurde; auf den übrigen Seiten können Daten einer früheren Anfrage liegen. ⑦ Response: Cloudflare berichtete, dass der Client HTTP 200 statt des erwarteten HTTP 400 erhielt und die Antwort Inhalte aus einer anderen Benutzersitzung enthielt. Cloudflares Bericht beschreibt diesen Ablauf Schritt für Schritt. SGLang issue #30233 und PR #38935 liefern weitere Anhaltspunkte zum Statusfehler und zur Admission-Korrektur.

Jeder Schritt für sich sieht zunächst normal aus. Erst zusammengenommen wird der Fehler sichtbar: Der Ablehnungsstatus wurde nicht rechtzeitig wirksam, während die nachfolgenden Schritte die Anfrage weiter wie eine reguläre Anfrage behandelten.

681,280 und 1,048,576 stehen für unterschiedliche Kapazitäten

In der von Cloudflare beschriebenen Bereitstellung war die Context-Länge des Modells auf 1,048,576 Tokens gesetzt. Der KV-Pool auf der Prefill-GPU fasste zum Vorfallzeitpunkt dagegen 681,280 Tokens. Später erhöhte Cloudflare den Pool auf etwa 2.04 Millionen Tokens und ergänzte eine Engine-seitige Sicherheitsprüfung für Ablehnungen. Cloudflares Angaben zur Kapazität und Fehlerbehebung.

Die Zahl 681,280 bezeichnet im selben Bericht zwei verschiedene Dinge: die Prompt-Längenschwelle der betroffenen Anfragen und die damalige Kapazität des KV-Pools auf der Prefill-GPU. Die Zahl ist identisch, ihre Bedeutung nicht. Der erste Wert beschreibt, welche Anfragen betroffen waren; der zweite, wie viel der laufende Worker tatsächlich halten konnte.

Diese beiden Größen regeln unterschiedliche Grenzen. Die Context-Länge ist das konfigurierte Limit für den Kontext einer Anfrage. Der KV-Pool ist der Speicherpool, der zur Laufzeit Key-/Value-Zustände für Tokens tatsächlich zuweisen und halten kann. Ein höheres Context-Limit vergrößert den KV-Pool nicht automatisch auf dieselbe Kapazität. Eine Anfrage kann daher unter dem deklarierten Context-Limit bleiben und trotzdem mehr KV-Zustand benötigen, als der aktuelle Worker aufnehmen kann.

Ein zu kleiner Pool sollte eine Ablehnung auslösen. Das eigentliche Problem war, dass dieser Ablehnungsstatus den späteren Handoff nicht stoppte. Sowohl Cloudflares Bericht als auch der Upstream-Code verweisen auf eine Lücke bei der Weitergabe des Abort-Status im disaggregierten Inferenzpfad.

Ein protokollierter Ablehnungsgrund bedeutet nicht, dass Admission die Anfrage beendet hat

Im betreffenden SGLang-Pfad schreibt Req.set_finish_with_abort() den Ablehnungsgrund in to_finish und ersetzt zugleich den Eingabe-Prompt durch einen Platzhalter aus einem Token. Die damalige Prüfung finished() las jedoch finished_reason. Der Ablehnungsgrund war also im Anfrageobjekt vorhanden, während die für „Ist die Anfrage beendet?“ verwendete Prüfung die Anfrage weiterhin als regulär planbar behandeln konnte. Siehe die Ursachenbeschreibung in SGLang PR #38935.

Die Zustandsabweichung lässt sich direkt im Quellcode prüfen. Die folgenden nicht zusammenhängenden Auszüge stammen aus dem fixierten Commit; ausgelassene Zeilen sind markiert. Den vollständigen Kontext zeigen set_finish_with_abort() (L2053–2072), finished() (L1479–1481) und update_finish_state() (L1842–1848):

# Req.set_finish_with_abort() — excerpt
self.origin_input_ids = array(
    "q", [0]
)  # set it to one token to skip the long prefill
# ... omitted ...
self.to_finish = FINISH_ABORT(error_msg, status_code, err_type)

# Req.finished()
return self.finished_reason is not None

# Req.update_finish_state()
if self.to_finish:
    self.finished_reason = self.to_finish
    self.to_finish = None

Das bedeutet nicht, dass to_finish nie angewendet wird: update_finish_state() überträgt es später nach finished_reason. Der Fehler besteht darin, dass Admission finished() prüft, bevor dieser Übergang erfolgt.

Bevor Cloudflare am 9. September die Engine-Korrektur ausrollte, konnte sich diese Zustandsabweichung durch den getrennten Prefill-/Decode-Pfad fortsetzen. Admission ließ die Anfrage zu; Decode reservierte genügend KV-Seiten; Prefill verarbeitete aber nur den Ein-Token-Platzhalter und erzeugte beziehungsweise übertrug zu wenig KV-Zustand. Decode konnte anschließend Seiten lesen, die von der aktuellen Anfrage gar nicht überschrieben worden waren. Cloudflare führte die tatsächliche Offenlegung auf KV-Daten zurück, die von früheren Anfragen zurückgeblieben waren. Cloudflare-Bericht · Zugehöriges Upstream-Issue #30233.

Drei Arten von „Abschluss“-Signalen werden hier leicht verwechselt:

• HTTP 200 bedeutet, dass der Client einen erfolgreichen HTTP-Status erhalten hat. Das beweist weder die semantische Richtigkeit der Antwort noch, dass die KV-Seiten zur aktuellen Anfrage gehören.
• Prefill completion / transfer-complete zeigt an, dass ein Verarbeitungsschritt oder Handoff ein Abschlusssignal ausgegeben hat. Es garantiert nicht automatisch, dass die Zahl der übertragenen Tokens alle von Decode reservierten Seiten abdeckt.
• Decode liest vollständige und gültige KV-Seiten kommt der entscheidenden Datenbedingung näher. Wer nur prüft, ob der Ablauf abgeschlossen wurde, aber nicht den tatsächlichen Schreibbereich und die Seitenzugehörigkeit, kann „Transfer beendet“ fälschlich mit „Daten vollständig und dieser Anfrage zugehörig“ gleichsetzen.

Ein abgeschlossener Ablauf bedeutet nicht automatisch korrekte Daten.

#36988, #38935 und #38704 waren nicht dieselbe Korrektur

Zeitliche Reihenfolge und Zuständigkeit der Upstream-Einträge sind wichtig.

Datum / Eintrag	Status	Was tatsächlich behoben wurde
2026-07-06, issue #30233	Geschlossen	Früher Bericht über ein ähnliches Problem in PD Disaggregation, bei dem von einem langen Prompt nur ein Token weitergegeben wurde. Keine unabhängige Reproduktion des vollständigen Cloudflare-Produktionsvorfalls.
2026-09-06, PR #36988	Gemergt; Cloudflare ordnete die Veröffentlichung v0.5.20 zu	Korrigiert die Beendigung und Bereinigung abgebrochener Prefill-Ergebnisse: ausstehende Chunk-Zustände löschen, Abort-Ergebnisse nicht erneut in die Queue für unfertige Anfragen legen, Ressourcen wie metadata/KV/HiCache/Mamba freigeben und verspätete Ergebnisse bereits ausgemusterter Anfragen ignorieren. Das adressiert einen Korrektheitsfehler.
2026-09-16, PR #38935	Gemergt; Cloudflare ordnete die Veröffentlichung v0.5.21 zu	Lehnt noch nicht zugelassene Anfragen früher an den Prefill- und Decode-Admission-Einstiegen ab und vermeidet unnötiges Bootstrap, metadata buffer, Sender-/Receiver-Initialisierung und Forward-Pass. Der PR-Autor stellte klar, dass es um Ressourcenverschwendung und Latenz geht, nicht um eine zweite unabhängige Korrektheitskorrektur nach #36988.
Erstellt 2026-09-09, geschlossen 2026-10-10, PR #38704	Geschlossen, nicht gemergt; keine Veröffentlichung	Ein anderer von Cloudflare vorgeschlagener Schutzmechanismus. Er darf nicht als Teil des Upstream-Mainline-Fixes dargestellt werden.

Die Beschreibung von #38935 liefert einen wichtigen zeitlichen Anhaltspunkt: Auf einem Main-Stand mit #36988 wurde der unzureichende Handoff von Decode nicht mehr eingereicht. Der Upstream-PR enthält außerdem einen Vorher-nachher-Vergleich für 1P1D (2×H200): Nach dem Merge von #38935 änderte sich Decode von einem Timeout nach 300 Sekunden zu einer sofortigen Antwort HTTP 400; Bootstrap und metadata buffer wurden nicht mehr erstellt, und der Stub-Batch sank von 1 auf 0. Das ist ein vom Upstream dokumentierter Vergleich, kein eigener Performance-Test dieses Artikels.

Deshalb darf die Eingangssperre nicht vereinfacht werden zu „Wenn to_finish nicht leer ist, Anfrage beenden“. #38935 verwendet is_unadmitted_reject, um eine abgelehnte Anfrage zu erkennen, die noch nicht zugelassen wurde und noch keine Ressourcenverantwortung übernommen hat. Eine erneut eintretende oder präemptierte Anfrage kann bereits KV- oder metadata-Ressourcen halten; sie darf nicht allein wegen eines Abort-Markers vorzeitig verworfen werden. Auch Decode muss Re-Entry berücksichtigen, weil ein Teil des Ressourcenstatus nicht unbedingt im Req-Objekt verbleibt. Ein zu frühes Beenden könnte Cleanup überspringen, das normalerweise der Scheduler übernimmt, etwa das active slot detach einer Streaming-Session (die Freigabe des von der Sitzung belegten aktiven Slots). SGLang PR #38935.

Später kamen weitere Schutzmechanismen hinzu, die zwar verwandt sind, aber andere Probleme adressieren. PR #39500 ergänzte eine optionale Handoff-KV-Prüfsumme. Cloudflare beschrieb außerdem KV Canary, das mögliche Beschädigungen erkennt und protokolliert, sowie Read-Time Page Tagging. Letzteres war ein im Sommer 2026 getesteter Prototyp, der auf GLM-5.2 ausprobiert und später wegen Zuverlässigkeitsproblemen deaktiviert wurde. Er hängt von bestimmten Attention-Backends und Modellarchitekturen ab und ist kein allgemein ausgerollter Schutz. Cloudflare erklärte, dass Prüfsumme und Canary noch nicht alle Architekturen abdeckten und die Unterstützung für GLM-5.3 erweitert wurde. Eine Handoff-Prüfsumme validiert den Transfer von Prefill zu Decode, nicht jeden späteren Decode-Lesezugriff.

PR #40645 und PR #41402 beheben gemeinsam verlorene Drain-Bestätigungen beziehungsweise eine unvollständige Abdeckung aller Decode-Peers. PR #41404 erweitert Deferred Release auf weitere Transferfehler, nicht nur auf von Decode ausgelöste Abbrüche. So sollen Seiten nicht freigegeben oder wiederverwendet werden, solange laufende RDMA-Schreibvorgänge sie noch berühren könnten. Diese Korrekturen betreffen KV-Page-Lifetime-Races und sind ein anderer Fehlerpfad als der deterministische Handoff einer abgelehnten Anfrage. Cloudflares Schutzmaßnahmen und Versionsübersicht.

CPU-Validierung mit fixierter Version: Codepfade bestätigt, kein Mandantenleck reproduziert

Ich habe nicht nur den Vorfallbericht und die PRs gelesen. Die Validierung besteht aus drei Ebenen, die jeweils unterschiedliche Aussagen stützen.

Evidenz	Beobachtung	Was sich daraus ableiten lässt
Eigene synthetische Python-Zustandsautomaten	Handoff-Modell 6/6; Admission-/Re-Entry-Modell 9/9	Die Guards in den selbst konstruierten Zustandsmodellen verhalten sich wie erwartet; das belegt kein SGLang-Laufzeitverhalten.
Upstream-SGLang-CPU-Unit-Tests mit fixiertem Commit (P1)	Insgesamt 19 passed über zwei Testdateien; der Admission-Test hat zusätzlich 12 bestandene Subtests	Tatsächlicher Upstream-Code für Mixin, Queue und Retirement wurde ausgeführt. Teile der Transport-/Cache-/Scheduler-Kollaborateure waren weiterhin Mocks. Kein echter Prefill-/Decode-Cluster wurde gestartet.
Vorher-nachher-Differenz (P2)	Verhaltensänderungen sowohl für den #38935-Admission-Diff als auch für das #36988-Prefill-Cleanup beobachtet	Fixierte Eingaben durchliefen in den beiden Versionen unterschiedliche Codepfade. Die Ergebnisse beschränken sich auf CPU-Code und Probe-Verhalten.

P1 ist auf den SGLang-Commit 8f3d6944b76c428d884582cb6c82a39db1465360 fixiert (fixierter Quellcode). Ausgeführt wurden die Upstream-Tests test_prefill_abort_result_cleanup.py (11 passed) und test_admission_abort_not_enqueued.py (8 passed plus 12 Subtests), insgesamt 19 passed. Die Umgebung war eine Linux-CPU-only-VM mit Python 3.12.3, pytest 9.2.0 und CPU-Torch. Es gab keine GPU, Modellgewichte, RDMA oder Mandantendaten.

P2 isoliert die Vorher- und Nachher-Version jedes PRs, damit mehrere Fixes nicht in einem Vergleich vermischt werden:

• Experiment A: #38935 Admission-Einstieg (Base 17ba2c2e → Head 8f3d6944). Vor dem Fix gelangten am Eingang abgelehnte Anfragen weiterhin in die Queue und lösten die Erstellung von Sender/Receiver aus. Danach wurden sie am Eingang beendet, ohne diese Handoff-Objekte zu erzeugen. Gültige Anfragen und Re-Entry-Anfragen mit metadata buffer blieben in beiden Codebäumen erhalten; eine fälschliche Ausmusterung dieser beiden Typen wurde nicht beobachtet.
• Experiment B: #36988 Prefill-Ergebnisbereinigung (Base 9c254df8 → Head 2ee5742a). Vor dem Fix konnte ein finales Abort-Ergebnis als unfertiger Cache behandelt und erneut in die Inflight-Queue aufgenommen werden; verspätete Ergebnisse bereits beendeter Anfragen konnten noch KV-Chunks senden. Nach dem Fix wurde die Bereinigung wie erwartet abgeschlossen, und verspätete Ergebnisse lösten diese Nebenwirkungen nicht mehr aus.

Die 7/7 aus P2 und die 11 passed aus P1 stammen aus unterschiedlichen Versionen. P2 verwendete die sieben Testfälle, die beim #36988-Head 2ee5742a vorhanden waren. In der später fixierten Version 8f3d6944 kamen parametrisierte Sampling-Mask-Tests hinzu, wodurch diese Datei elf Fälle enthielt. 0/7 → 7/7 ist deshalb ein Vorher-nachher-Vergleich derselben sieben Fälle und darf nicht mit den elf P1-Pässen zusammengerechnet werden. Die sieben Pre-Fix-Fehler in P2 waren sechs AttributeError-Ausnahmen und ein ValueError, ausgelöst, weil der Code in den normalen Transferpfad fiel, den der Test-Stub nicht modellierte. Das waren keine sieben fehlgeschlagenen fachlichen Assertions. Aussagekräftiger sind die beobachteten Effekte: erneutes Einreihen, Bereinigung und verzögertes Senden.

Öffentliche Prüfartefakte

Die beiden Differential-Probes, vier unveränderten JSON-Ausgaben, der P2-Beleg und eine SHA-256-Prüfliste sind im öffentlichen Evidenzpaket verfügbar. Beide Base-/Head-Commit-Paare sowie die Mock-Grenzen und der reine CPU-Umfang sind dokumentiert. Das Pre-Fix-Ergebnis 0/7 entstand durch Stub-Fall-through (sechs AttributeError, ein ValueError), nicht durch sieben fehlgeschlagene Assertions. Die Artefakte belegen beobachtete Codepfad-Unterschiede in fixierten Versionen, keine GPU/RDMA- oder reale Cross-Tenant-Leak-Reproduktion.

Vier Abnahmekriterien für den Betrieb

Wer einen Inferenzdienst mit mehreren Mandanten oder eine SGLang-Architektur mit getrenntem Prefill und Decode betreibt, könnte versucht sein zu sagen: „Auf v0.5.22 aktualisieren, einen langen Prompt schicken, HTTP 400 sehen, fertig.“ Darauf sollte man sich nicht verlassen. Konfiguration und Ressourcenlebenszyklus haben viele Wege, die eine reine Versionsprüfung nicht abdeckt. Ich würde vier unabhängige Gates prüfen:

1. Pool-/Context-Gate: Stimmen Konfiguration und Laufzeitkapazität überein? Nach dem Worker-Start die im Startprotokoll tatsächlich ausgegebene KV-Pool-Kapazität mit dem Context-Limit vergleichen. Nach Änderungen an Konfiguration, GPU-Aufteilung oder Parallelisierungsstrategie das Protokoll erneut prüfen. Ein Negativfall sollte eine Eingabe enthalten, die unter dem Context-Limit liegt, aber die aktuelle KV-Pool-Kapazität überschreitet. Das System muss sie ausdrücklich ablehnen, statt einen Handoff fortzusetzen.
2. Reject-/Admission-Gate: Wird die Ablehnung bereits am Eingang wirksam? Prüfen, ob eine abgelehnte Anfrage vor Bootstrap, Queue Admission, metadata-buffer-Zuweisung und Sender-/Receiver-Initialisierung beendet wird. Nicht nur neue Anfragen testen, sondern auch gültige Anfragen, Re-Entry, präemptierte Anfragen und Anfragen, die weiterhin KV-, Mamba- oder metadata-Ressourcen halten. Nicht jede Anfrage mit Abort-Status pauschal verwerfen; sonst kann die Zuständigkeit für die Ressourcenbereinigung verletzt werden.
3. Transfer-/Read-Gate: Deckt der tatsächlich übertragene Bereich den tatsächlich gelesenen Bereich ab? Reservierte Token-/Page-Zahlen mit dem real geschriebenen und übertragenen gültigen Bereich vergleichen. HTTP 200 und transfer-complete ersetzen weder Längen- noch Eigentumsprüfung. Vor dem Einsatz von —disaggregation-enable-kv-checksum oder —kv-canary zuerst prüfen, ob das aktuelle Modell und Backend unterstützt werden, und anschließend anhand der Logs bestätigen, dass die Validierung tatsächlich ausgeführt wurde. Zum Zeitpunkt der Cloudflare-Offenlegung deckten diese Mechanismen nicht alle Architekturen einschließlich GLM-5.3 ab. Nicht unterstützte Optionen dürfen nicht als wirksame Schutzmaßnahmen zählen. Der Handoff-Checksum deckt außerdem nicht jeden Decode-Lesezugriff ab.
4. Lifetime-/Ownership-Gate: Wann dürfen Seiten nach einem Fehler freigegeben oder wiederverwendet werden? Negative Tests für Abort, verzögerte Ergebnisse und laufende RDMA-Schreibvorgänge durchführen. Sicherstellen, dass nicht abgeschlossene Schreibvorgänge neu zugewiesene Seiten nicht beschädigen, verspätete Ergebnisse ausgemusterter Anfragen keine weiteren Chunks senden und Ressourcen nur einmal freigegeben werden. Deferred KV Release muss sowohl auf Prefill als auch auf Decode aktiviert sein. Bei Mooncake außerdem prüfen, ob Transfer-Batch-Limit und Release-Timeout zusammenpassen, damit nach einem Timeout keine überlange Folge laufender Schreibvorgänge bleibt. Versionen mit PR #41023 aktivieren Deferred Release standardmäßig für unterstützte Backends; maßgeblich bleiben die tatsächlich laufende Version und Konfiguration. #40645 und #41402 betreffen Drain-Bestätigungen, #41404 die verzögerte Freigabe bei weiteren Transferfehlern. Diese Lebenszyklusrisiken müssen getrennt vom ursprünglichen deterministischen Handoff-Fehler geprüft werden.

SGLang v0.5.22 wurde am 19. Oktober 2026 veröffentlicht. Cloudflare empfahl v0.5.22 oder neuer beziehungsweise bei Bedarf einen Backport der betreffenden Fixes. Ein Versionsupgrade bedeutet aber nicht automatisch, dass die Bereitstellung die Isolationstests bestanden hat. Zu prüfen sind die tatsächlich laufende Codeversion, Pool-/Context-Konfiguration, negative Admission-Fälle und der Seitenlebenszyklus. Ist eine Funktion wie Checksum nicht aktiviert, darf sie nicht als aktive Schutzmaßnahme gezählt werden.

Die wichtigste Lehre ist nicht, dass ein einzelner Boolean falsch war. Ablehnungsstatus, Datenintegrität und Ressourceneigentum sind getrennte Grenzen. Ein auf der Anfrage gespeicherter Ablehnungsgrund bedeutet nicht, dass Admission ihn zwingend erkennt. Ein abgeschlossener Transfer bedeutet nicht, dass jede von Decode gelesene Seite von der aktuellen Anfrage beschrieben wurde. Ein ausgelöstes Abort bedeutet nicht, dass alle laufenden Schreibvorgänge beendet sind. Nur wenn diese Grenzen getrennt geprüft werden, wird ein erfolgreich aussehender Request-Pfad nicht fälschlich als Beleg für echte Datenisolation gewertet.

Testdatum: 28. Oktober 2026.

SGLang: sieben Schritte des Vorfalls

Verfolge, wie eine abgelehnte Anfrage Admission, KV-Transfer und Decode durchlaufen konnte. Dies ist eine Lesehilfe zu Cloudflares Offenlegung, keine SGLang-Ausführung im Browser.

Alle sieben Schritte bleiben ohne JavaScript lesbar.

1. Von Cloudflare offengelegter Vorfall

   1. Bootstrap: KV-Seiten reservieren

   Der Router übermittelt Decode die Prompt-Länge; Decode reserviert die KV-Seiten.

   Die Reservierung folgt dem Prompt; sie beweist nicht, dass der spätere Transfer die volle Länge abdeckt.

   Fixierter Quellcode · 8f3d6944b76c · L2053-L2072

2. CPU-Differenztest mit fixiertem Quellcode

   2. Prefill admission: Ablehnung stoppt die Zulassung nicht

   Die Prüfung las finished_reason, während der Ablehnungsgrund in to_finish stand; der alte Pfad konnte die Anfrage als unfertig behandeln.

   Im CPU-Differenztest gelangte die abgelehnte Anfrage vor dem Fix in die Queue und erzeugte einen Sender; der Fix beendet sie am Admission-Eingang.

   Fixierter Quellcode · 8f3d6944b76c · L1479-L1481Lokale Belege: probe-admission-pre-20261028.jsonLokale Belege: probe-admission-post-20261028.json

3. Von Cloudflare offengelegter Vorfall

   3. Prefill forward: Eingabe wird zu einem Token

   Um langes Prefill zu überspringen, wurde die Eingabe durch einen Ein-Token-Platzhalter ersetzt; der ursprüngliche KV-Zustand war damit nicht vollständig.

   Der Platzhalter ist ein Steuersignal, kein Nachweis vollständiger KV-Daten.

   Fixierter Quellcode · 8f3d6944b76c · L2053-L2072

4. Von Cloudflare offengelegter Vorfall

   4. KV-Transfer: eine Seite, aber Abschluss gemeldet

   Prefill übertrug nur die KV-Seite des Platzhalters, meldete aber Abschluss; das Signal prüfte den Umfang nicht.

   Dieser Schritt stammt aus Cloudflares Offenlegung; GPU/RDMA wurde nicht unabhängig reproduziert.

   Fixierter Quellcode · 8f3d6944b76c · L2053-L2072Lokale Belege: sglang-cpu-p2-receipt.json

5. CPU-Differenztest mit fixiertem Quellcode

   5. Decode admission: dieselbe Statusprüfung lässt erneut zu

   Auch Decode akzeptierte den Handoff; der CPU-Differenztest zeigt einen Receiver im alten und ein Beenden am Eingang im korrigierten Stand.

   Der CPU-Differenztest zeigt einen Receiver im alten und ein Beenden am Admission-Eingang im korrigierten Stand.

   Fixierter Quellcode · 8f3d6944b76c · L1479-L1481Lokale Belege: probe-admission-pre-20261028.jsonLokale Belege: probe-admission-post-20261028.json

6. Von Cloudflare offengelegter Vorfall

   6. Decode-Attention: Lesen über gültige Schreibdaten hinaus

   Decode las bis zur reservierten Länge, obwohl im offengelegten Ablauf nur die erste Seite von der aktuellen Anfrage geschrieben wurde.

   Offengelegter Ablauf; CPU-Differenztests prüfen Abort-, Queue- und Bereinigungspfade, nicht GPU-Attention.

   Fixierter Quellcode · 8f3d6944b76c · L1479-L1481Lokale Belege: probe-prefill-pre-20261028.jsonLokale Belege: probe-prefill-post-20261028.json

7. Von Cloudflare offengelegter Vorfall

   7. Response: HTTP 200 bedeutet keine korrekten Daten

   Cloudflare meldete HTTP 200 statt des erwarteten HTTP 400 mit Inhalten einer anderen Sitzung.

   Dieses Ergebnis stammt vom Anbieter; eine reale mandantenübergreifende Antwort wurde nicht reproduziert.

   Fixierter Quellcode · 8f3d6944b76c · L1479-L1481Lokale Belege: sglang-cpu-p2-receipt.json