Cloudflare: Kleinere Modellbereitstellung senkt Speicherbedarf, doch Sicherheit wird zum Prüfstein
Cloudflares kleinere Modellbereitstellung fasst nun doppelt so viel Kimi-Kontext in den GPU-Speicher, nimmt dabei bei üblicher Parallelität jedoch eine etwas langsamere Verarbeitung in Kauf. Das Unternehmen komprimiert außerdem GLM-Gewichte und prüft gemeinsam genutzte Cache-Seiten, bevor unterstützte Decode-Vorgänge sie lesen. Zusammen machen diese Änderungen GPU-Speicher von einer festen Obergrenze zu einer Ressource, die Cloudflare aktiv verwalten kann.
Das ist bedeutsam, weil die Kimi-Modelle von Moonshot AI und die GLM-Modelle von Z.ai keine gewöhnlichen Ergänzungen eines Inferenzkatalogs sind. Sie vereinen hohe Parameterzahlen, lange Kontextfenster und Mixture-of-Experts-Architekturen. Ein Mixture-of-Experts-Modell aktiviert für jedes Token ausgewählte Teile seines Netzwerks, reduziert dadurch den Rechenaufwand, ohne seine gespeicherten Gewichte klein zu machen.
Der Konflikt besteht nicht einfach zwischen Cloudflare und einem anderen Inferenzanbieter. Es geht um hohe Auslastung gegenüber sicherer Isolation auf gemeinsam genutzter Hardware. Mehr Anfragen auf einer GPU zu bündeln, verbessert Wirtschaftlichkeit und Gesamtdurchsatz, erhöht jedoch auch die Folgen fehlerhafter Cache-Verwaltung.
Cloudflare erklärt, dass seine neue Konfiguration die Modellgenauigkeit bewahrt und zugleich die Kapazität steigert. Die meisten unterstützenden Messwerte stammen jedoch aus Cloudflares eigener Evaluierungssuite und Infrastruktur. Der nächste Test wird sein, ob diese Gewinne über Workloads, Hardwaregenerationen und wesentlich größere Produktionsvolumina hinweg stabil bleiben.
Was Cloudflare für Kimi und GLM geändert hat
Cloudflare kombiniert drei Speichertechniken, weil keine einzelne Optimierung die Bereitstellung von Modellen im Frontier-Maßstab löst.
Das Unternehmen erläuterte die Änderungen am 3. August in einem technischen Bericht. Es setzt FP8-Quantisierung für Kimis KV-Cache, INT4-Komprimierung für GLMs Gewichte und Integritäts-Tags für gemeinsam genutzte Cache-Seiten ein. Jede Technik adressiert eine andere Einschränkung im selben Inferenzsystem.
Ein KV-Cache speichert die Attention-Keys und -Values, die für bereits vom Modell verarbeitete Tokens erzeugt wurden. Er ermöglicht es einem Modell, ein Gespräch fortzusetzen, ohne vor jedem generierten Token den gesamten Prompt erneut berechnen zu müssen. Lange Prompts und parallele Anfragen lassen diesen Cache schnell anwachsen.
Cloudflare speichert die Cache-Daten von Kimi K2.6 in FP8 e4m3 statt in BF16. FP8 verwendet acht Bit für jeden Gleitkommawert, BF16 sechzehn. Diese Umwandlung halbiert den Speicherbedarf des Caches.
Laut Cloudflare steigt der verfügbare Kontext im Speicher von etwa 686.000 Tokens auf rund 1,37 Millionen Tokens. Dabei handelt es sich um die aggregierte Kapazität der getesteten Bereitstellung, nicht um ein neues Kontextfenster-Limit für einen einzelnen Nutzer. Diese Unterscheidung ist wichtig, weil die Optimierung vor allem die Parallelität erhöht.
Cloudflare nahm für GLM 5.2 eine separate Änderung vor. Das Unternehmen komprimierte Modellgewichte von FP8 auf INT4, eine vier Bit breite Ganzzahldarstellung. Der Checkpoint schrumpfte Berichten zufolge von 705 GB auf 421 GB, also um etwa 40 Prozent.
Eine Tensor-Parallel-Bereitstellung über acht GPUs verteilt das Modell auf acht GPUs. In dieser Konfiguration sank der Speicherverbrauch laut Cloudflare von ungefähr 88 GB auf 52 GB pro GPU. Der verbleibende Platz kann rund 1,18 Millionen KV-Cache-Tokens aufnehmen.
Die dritte Änderung schützt den gemeinsam genutzten Cache, der durch diese dichtere Packung entsteht. Jede physische Cache-Seite erhält ein Tag, das sich bei jeder Neuzuweisung der Seite ändert. Der Server erfasst die Seiten und Tags, die jede Anfrage erwartet.
Bevor unterstützte Decode-Vorgänge diese Seiten lesen, prüft Cloudflare die Zuordnungen. Bei einer Abweichung wird die betroffene Anfrage gestoppt. Das System soll somit sicher fehlschlagen, statt Daten zu lesen, die einer anderen Anfrage zugeordnet sind.
Diese Techniken ergänzen Cloudflares umfassendere Architektur für große Modelle. Das Unternehmen beschrieb zuvor Infire inference als Rust-basierte Engine für sein verteiltes GPU-Netzwerk. Zudem trennt es Prefill und Decode in unterschiedliche Ressourcenpools.
Prefill verarbeitet einen eingehenden Prompt und erstellt seinen anfänglichen Cache-Zustand. Decode erzeugt die Antwort Token für Token. Diese Phasen belasten GPUs unterschiedlich, wodurch Cloudflare jeden Pool separat optimieren kann.
Diese Trennung ist für das neue Design entscheidend. Cloudflare behält BF16-Caches und FP8-Gewichte dort bei, wo die Rechenleistung dominiert. Kleinere Darstellungen kommen dort zum Einsatz, wo Speicherkapazität oder Bandbreite zur begrenzenden Ressource werden.
Das Ergebnis ist keine universell komprimierte Modellkonfiguration. Es ist ein phasenbewusstes Bereitstellungssystem, das Formate je nach Workload verändert. Das schafft mehr operative Komplexität, verhindert jedoch, dass ein einzelner Kompromiss der gesamten Anfrage aufgezwungen wird.
Warum kleinere Cloudflare-Caches reine Geschwindigkeit schlagen
Die Quantisierung des Kimi-KV-Caches gewinnt, indem sie mehr Arbeit zulässt, nicht indem sie jede einzelne Anfrage schneller macht.
Cloudflare testete das Decoding von Kimi K2.6 auf einer disaggregierten H200-Bereitstellung. Bei einer parallelen Anfrage lieferte der BF16-Cache 137 Tokens pro Sekunde. Die FP8-Version erreichte 125 und machte den komprimierten Cache bei dieser Last langsamer.
Das Muster setzte sich mit steigender Parallelität fort. Bei acht Anfragen erreichte BF16 731 Tokens pro Sekunde, verglichen mit 689 bei FP8. Bei sechzehn Anfragen lagen die Messwerte bei 1.106 beziehungsweise 1.028 Tokens pro Sekunde.
BF16 erreichte bei 32 parallelen Anfragen 1.558 Tokens pro Sekunde. Anschließend war jedoch der verfügbare Speicher erschöpft. Laut Cloudflare lief der FP8-Cache mit bis zu 64 Anfragen weiter und lieferte 2.192 Tokens pro Sekunde.
Diese letzte Zahl liegt etwa 41 Prozent über dem höchsten gemessenen BF16-Durchsatz. Cloudflare berichtet zudem von ungefähr 30 Prozent niedrigeren Kosten pro Token. Der Gewinn entsteht dadurch, dass auf derselben Bereitstellung mehr Arbeit erledigt wird, nicht dadurch, dass jede Anfrage bei geringer Last beschleunigt wird.
Diese Unterscheidung verhindert eine einfache, aber irreführende Schlagzeile. Quantisierung verursacht Umwandlungsaufwand, wenn der Attention-Kernel gecachte Werte liest. Bei gleicher Parallelität blieben Cloudflares BF16-Ergebnisse um mehrere Prozentpunkte schneller.
Die Quantisierung des Kimi-KV-Caches wird erst wertvoll, wenn Speichergrenzen das größere Format daran hindern, weitere Anfragen anzunehmen. Sie tauscht eine geringfügig niedrigere Effizienz pro Anfrage gegen deutlich mehr Gesamtkapazität. Das ist ein sinnvoller Kompromiss, wenn die Nachfrage hoch genug bleibt, um den zusätzlichen Platz zu nutzen.
Bei geringem Traffic ist sie weniger wertvoll. Eine Bereitstellung, die nur wenige gleichzeitige Anfragen bedient, würde den Umwandlungsaufwand tragen, ohne die zusätzliche Kapazität zu nutzen. Cloudflares Ansatz hängt daher davon ab, genügend kompatible Arbeit zu jedem Decode-Pool zu leiten.
Hier wird globale Infrastruktur strategisch relevant. Große Anbieter können Traffic vieler Kunden bündeln und teure Beschleuniger ausgelastet halten. Kleinere Betreiber sehen sich oft mit sprunghafter Nachfrage konfrontiert und können dieselben Auslastungsgewinne daher nicht erzielen.
Cloudflare nutzt in Workers AI bereits Sitzungsaffinität und Prefix-Caching. Prefix-Caching verwendet den berechneten Zustand identischer Prompt-Anfänge erneut. Die Einführung großer Modelle machte die Nutzung gecachter Tokens sichtbar und führte einen Header für Sitzungsaffinität ein, um das Cache-Routing zu verbessern.
Die neuere Optimierung betrifft eine andere Ebene. Prefix-Caching vermeidet wiederholte Prefill-Arbeit, während FP8 die Decode-Kapazität erweitert. Beides zusammen kann doppelte Berechnungen reduzieren und mehr aktive Sequenzen zulassen.
Cloudflare verglich die Genauigkeit in mehreren Evaluierungen. Bei GSM8K erreichte BF16 94,24, FP8 94,09. Die MMLU-Ergebnisse lagen bei 89,11 beziehungsweise 89,04.
Der FP8-Cache erreichte bei ARC-Challenge 67,49, verglichen mit 66,72 für BF16. Bei MMLU-Pro erzielte FP8 79,29, während BF16 80,29 erreichte. Die Gültigkeit von Tool-Aufrufen betrug bei FP8 92,6 Prozent und bei BF16 92,2 Prozent.
Cloudflare bezeichnet diese Ergebnisse als nicht unterscheidbar. Diese Schlussfolgerung ist innerhalb der berichteten Suite plausibel, doch die Werte belegen keine universelle Gleichwertigkeit. Kleine numerische Veränderungen können seltene Prompts, lange Agenten-Traces oder Aufgaben außerhalb der ausgewählten Evaluierungen beeinflussen.
Mehrere Tests erzeugen zudem nichtdeterministische Ausgaben. Ein minimaler Punktunterschied kann auf Sampling, Evaluierungsrauschen oder Quantisierung zurückgehen. Um diese Ursachen zu trennen, wären wiederholte Versuche und Konfidenzintervalle nötig.
Der interne mcxams-Benchmark des Unternehmens lieferte identische Ergebnisse: Beide Konfigurationen bestanden 61 von 63 Tests. Interne Evaluierungen können Produktionsanforderungen gut widerspiegeln, doch Außenstehende können ihre Abdeckung nicht unabhängig prüfen.
Die Quantisierung des Kimi-KV-Caches sollte daher als operatives Ergebnis mit ermutigenden Qualitätsnachweisen bewertet werden. Sie ist keine allgemeine Erkenntnis, dass jedes Modell FP8-Cache-Werte sicher verwenden kann. Attention-Verteilungen und numerische Empfindlichkeit unterscheiden sich zwischen Architekturen.
Cloudflares eigentliche Leistung besteht darin, zu erkennen, wo sich der Formatwechsel auszahlt. Prefill bleibt rechengebunden, daher belässt das Unternehmen seinen Cache in BF16. Decode wird speichergebunden, wodurch die kleinere FP8-Darstellung bei höherer Parallelität nützlich wird.
Diese Entscheidung stützt die zentrale These. Bessere Inferenz bedeutet nicht immer, eine einzelne Anfrage schneller auszuführen. Im Maßstab bedeutet sie oft, mehr nützliche Arbeit abzuschließen, bevor Hardware ihre Speichergrenze erreicht.
Der eigentliche Wettbewerb dreht sich um Speicher pro nützlichem Token
Das Hosting von Frontier-Modellen hängt zunehmend von Speichereffizienz ab, nicht allein von herausgestellten Parameterzahlen.
Kimi K2.6 gehört zu einer Modellfamilie, die große gespeicherte Gewichte mit Langkontext- und agentischen Funktionen kombiniert. Cloudflares aktuelle Modelldokumentation nennt ein Kontextfenster von 262.144 Tokens, Bildeingaben, Tool-Calling und strukturierte Ausgaben.
Diese Fähigkeiten erzeugen überlappende Speicheranforderungen. Die Modellgewichte müssen während der Generierung zugänglich bleiben. Jede aktive Unterhaltung erstellt außerdem einen wachsenden KV-Cache, während Batching erfordert, dass der Server viele Sequenzen gleichzeitig nachverfolgt.
Ein Modell kann in den GPU-Speicher passen und dennoch unwirtschaftlich im Betrieb sein. Wenn seine Gewichte wenig Platz für Cache-Seiten lassen, unterstützt jede Bereitstellung weniger aktive Nutzer. Leerlaufende oder unzureichend gefüllte Batches verschwenden dann teure Beschleunigerkapazität.
Diesen Wettbewerb sollen kleinere Cloudflare-Darstellungen verändern. Die relevante Kennzahl wird zu nützlichen erzeugten Tokens pro Speichereinheit, innerhalb akzeptabler Latenz- und Qualitätsgrenzen. Die reine Geschwindigkeit bei einer Anfrage zeigt nur einen Teil dieses Systems.
Der Wandel setzt auch Anbieter unter Druck, die vor allem auf Standard-Inferenzstacks angewiesen sind. Wenn zwei Dienste ähnliche Hardware und Modellgewichte einsetzen, kann der Anbieter mit besserem Cache-Management mehr parallele Arbeit annehmen. Zudem kann er fixe Infrastrukturkosten auf mehr erzeugte Tokens verteilen.
Softwareverbesserungen beseitigen jedoch keine Hardwareunterschiede. H200-GPUs bieten erheblichen High-Bandwidth-Memory, während neuere Blackwell-Systeme andere Low-Precision-Funktionen hinzufügen. Ergebnisse einer Beschleunigerkonfiguration lassen sich nicht automatisch auf eine andere übertragen.
Die Traffic-Struktur ist ebenso wichtig. Coding-Agenten können große Prompts übermitteln, Präfixe wiederverwenden, Tools aufrufen und über viele Turns hinweg fortfahren. Chat-Sitzungen von Verbrauchern verwenden möglicherweise kürzere Prompts und weniger vorhersehbare Follow-up-Muster.
Ein agentischer Workload kann eine Sequenz länger im Speicher halten. Das erhöht den Wert der Cache-Kapazität, erschwert aber auch die Planung. Eine ungewöhnlich lange Anfrage kann Speicher belegen, während viele kleinere Anfragen warten.
Cloudflares disaggregiertes Prefill- und Decode-Design reagiert auf dieses Ungleichgewicht. Die rechenintensive Prompt-Aufnahme läuft in einem Pool. Die speichersensitive Generierung läuft in einem anderen, sodass jeder Pool separat skaliert werden und unterschiedliche Zahlenformate nutzen kann.
Dieses Design verursacht auch Koordinierungskosten. Der Cache-Zustand muss über die Phasengrenze hinweg verschoben werden oder zugänglich bleiben. Routing-Entscheidungen müssen verfügbaren Speicher, vorhandene Präfixe, Warteschlangentiefe und die erwartete Länge jeder Antwort berücksichtigen.
Das SGLang-Projekt stellt das Serving-Framework bereit, das in Cloudflares Experimenten und im Produktionsverkehr eingesetzt wird. Cloudflare erklärt, mit dem Projekt zusammenzuarbeiten, um Patches und Funktionen upstream einzubringen. Dadurch werden einige Verbesserungen über einen einzelnen Anbieter hinaus verfügbar.
Offene Infrastruktur kann die Softwarelücke zwischen großen Plattformen und unabhängigen Betreibern verkleinern. Dennoch bleibt Deployment-Erfahrung wichtig. Ein veröffentlichter Kernel oder Scheduler-Feature liefert nicht automatisch Cloudflares Verkehrsvolumen, Telemetrie oder Kapazitätsplanung.
Dieser Unterschied macht den Wettbewerbsdruck indirekt. Cloudflare beansprucht Kimi oder GLM nicht als exklusive Modelle. Das Unternehmen argumentiert vielmehr, dass seine Infrastruktur offene Frontier-Modelle effizient genug für gemeinsamen serverlosen Zugriff betreiben kann.
Auch Modellentwickler profitieren von dieser Konstellation. Moonshot AI und Z.ai können Nutzer erreichen, die keine Multi-GPU-Cluster bereitstellen möchten. Eine breitere Hosting-Unterstützung kann die Akzeptanz erhöhen und mehr Feedback zu realen Workloads erzeugen.
Im Gegenzug übernimmt der Anbieter eine schwierigere Verantwortung. Er muss das Modellverhalten beim Umwandeln numerischer Formate bewahren. Außerdem muss er verhindern, dass der Cache-Zustand eines Mandanten die Ausgabe eines anderen beeinflusst.
Die stärksten Betreiber werden daher drei Variablen gemeinsam optimieren: Speicherkapazität, Ausgabequalität und Isolation. Nur zwei davon zu verbessern, schafft einen instabilen Dienst. Höhere Dichte ohne Isolation wirft Sicherheitsbedenken auf, während Komprimierung ohne Qualitätstests stille Regressionen riskiert.
Für Käufer bleibt die Führung in Benchmarks relevant, aber unvollständig. Ein beeindruckendes Modell ist nur dann nützlich, wenn die Serving-Schicht vorhersehbare Latenz und korrekte Tool-Aufrufe liefert. Lange Warteschlangen können den praktischen Wert eines stärkeren Modells zunichtemachen.
Entwickler sollten außerdem Modellqualität und Anbieterqualität getrennt betrachten. Derselbe Kimi- oder GLM-Checkpoint kann sich je nach Host aufgrund von Quantisierung, Sampling-Standards, Cache-Richtlinien und Serving-Software unterschiedlich verhalten.
Eine Produktionsbewertung sollte vollständige Aufgaben messen, nicht isolierte Antworten. Nützliche Signale sind die Gültigkeit von Tool-Aufrufen, Timeout-Raten, Konsistenz in langen Sitzungen und Latenz unter realistischer Parallelität. Diese Metriken zeigen, ob Speicheroptimierung die Anwendung tatsächlich verbessert.
GLM-Gewichtskomprimierung verschiebt den Phasen-Trade-off
Die GLM-Gewichtskomprimierung beschleunigt Decode, weil kleinere Gewichte den Speicherverkehr reduzieren, verlangsamt jedoch die rechenintensive Prefill-Phase.
Cloudflare wandelte GLM-5.2-Gewichte von FP8 in INT4 um. Während Decode streamt das System wiederholt Modellgewichte aus dem GPU-Speicher mit hoher Bandbreite. Wenn Speicherbandbreite den Engpass bildet, kann das Übertragen weniger Bytes jedes Token schneller erzeugen.
Das Ergebnis bei geringer Parallelität war am deutlichsten. Bei einer Anfrage erzeugte FP8 60 Token pro Sekunde, während INT4 92 erreichte. Das entspricht einem berichteten Gewinn von 55 Prozent.
Bei acht gleichzeitigen Anfragen stieg der Durchsatz von 425 auf 513 Token pro Sekunde. Der Gewinn betrug 21 Prozent. Bei sechzehn Anfragen erzeugte INT4 825 Token pro Sekunde, gegenüber 683 bei FP8.
Die Verbesserung blieb auch bei höherer Last sichtbar. INT4 erreichte bei 32 Anfragen 1.267 Token pro Sekunde, gegenüber 994 bei FP8. Bei 64 Anfragen lagen die jeweiligen Ergebnisse bei 1.933 und 1.672.
Die GLM-Gewichtskomprimierung bringt während Prefill nicht denselben Vorteil. INT4-Gewichte müssen vor der Matrixmultiplikation erweitert werden. Cloudflare maß für INT4 ungefähr 8.660 Prefill-Token pro Sekunde, verglichen mit 10.160 für FP8.
INT4 überall einzusetzen, würde daher den Prompt-Verarbeitungsdurchsatz opfern. Cloudflare behält stattdessen FP8 für Prefill bei und weist INT4 Decode zu. Diese Aufteilung bewahrt das jeweils am besten gemessene Format für jede Phase.
Diese Erkenntnis knüpft an Cloudflares frühere Arbeit zur verlustfreien Gewichtskomprimierung an. Dieses Projekt untersuchte mehrere Ausführungspfade, weil Batch-Größen und Matrixformen das Gleichgewicht zwischen Dekomprimierung und Berechnung verändern.
Der aktuelle GLM-Ansatz verwendet verlustbehaftete Quantisierung statt dieser früheren verlustfreien Methode. Die Umwandlung von FP8-Gewichten in INT4 ordnet mehr Werte weniger darstellbaren Zuständen zu. Genauigkeitstests werden unverzichtbar, weil die ursprünglichen Gewichte nicht exakt rekonstruiert werden können.
Cloudflare berichtete Unterschiede von weniger als 0,8 Punkten über die bewerteten Benchmarks hinweg. MMLU erreichte durchschnittlich 86,60 für FP8 und 86,54 für INT4. Die exakten MMLU-Pro-Werte lagen bei 80,80 und 80,47.
Bei der ARC-Challenge-Genauigkeit erzielte FP8 64,93 Prozent und INT4 64,85 Prozent. Beide Formate bestanden 62 von 63 Fällen in Cloudflares internem mcxams-Benchmark.
GSM8K zeigte einen etwas größeren Unterschied. FP8 erreichte 94,39 Prozent Exact Match, während INT4 93,56 Prozent erzielte. Bei flexibler Bewertung lagen die Werte bei 94,24 beziehungsweise 93,48 Prozent.
Cloudflare erklärt, die Qualität des komprimierten Modells sei nicht unterscheidbar. Die öffentlichen Zahlen stützen einen kleinen durchschnittlichen Unterschied, lassen aber mehrere Fragen offen. Das Unternehmen veröffentlichte nicht für jedes agentische oder mehrsprachige Verhalten Ergebnisse.
GLM wird häufig für Programmierung, Tool-Nutzung und mehrsprachige Aufgaben verwendet. Allgemeine akademische Benchmarks erfassen nicht jeden Fehlermodus in diesen Szenarien. Ein fehlerhaftes Funktionsargument kann wichtiger sein als eine kleine Veränderung der durchschnittlichen Genauigkeit.
Seltene numerische Fehler sind besonders schwer zu erkennen. Ein Benchmark kann stabile aggregierte Qualität zeigen, während ein komprimiertes Modell sein Verhalten bei ungewöhnlichen Prompts verändert. Lange Reasoning-Traces können einen frühen Unterschied verstärken.
Das macht INT4 nicht ungeeignet. Es bedeutet, dass Deployment-Entscheidungen workload-spezifische Tests und fortlaufendes Monitoring benötigen. Anbieter sollten die exakte Modellkonfiguration vergleichen, die Nutzer erhalten, und nicht nur einen Referenz-Checkpoint.
Dieselbe Vorsicht gilt für Geschwindigkeitsangaben. Token pro Sekunde hängen von Eingabelänge, Ausgabelänge, Batching, Hardware, Kerneln und Scheduling ab. Cloudflares Messungen beschreiben das getestete System und kein universelles GLM-Leistungsniveau.
Dennoch bietet die Phasenaufteilung eine nützliche architektonische Lehre. Quantisierung sollte nicht als eine einzige statische Exportentscheidung betrachtet werden. Ein Anbieter kann mehrere Repräsentationen vorhalten und Berechnungen an das Format routen, das zu jeder Phase passt.
Diese Flexibilität hat Kosten. Mehrere Gewichtsformate verbrauchen Speicherplatz und verkomplizieren das Deployment. Ingenieure müssen Kompatibilität prüfen, die richtigen Kernel auswählen und Konfigurationsdrift zwischen GPU-Pools verhindern.
Operative Disziplin entscheidet darüber, ob sich die Komplexität auszahlt. Wenn eine Anfrage den falschen Pool erreicht oder eine Modellrevision das numerische Verhalten verändert, sind theoretische Durchsatzgewinne wenig wert. Automatisierung und Observability werden selbst Teil der Optimierung.
Cloudflares berichtete Ergebnisse zeigen, warum Anbieter diese Komplexität akzeptieren. Ein um 40 Prozent kleinerer Checkpoint lässt erheblichen Speicher für aktive Sequenzen frei. Schnelleres Decode verbessert dann die Latenz dort, wo Nutzer die Tokens eintreffen sehen.
Der Trade-off ist konkret und nicht abstrakt. Die GLM-Gewichtskomprimierung erkauft Decode-Kapazität und Geschwindigkeit durch zusätzliches numerisches Risiko und Prefill-Overhead. Cloudflare steuert diesen Tausch, indem es das Format auf die Phase beschränkt, in der es gewinnt.
Sicherheit gemeinsamer KV-Caches wird zum Produktionsthema
Höhere GPU-Dichte steigert den Wert jeder Cache-Seite und macht fehlerhafte Besitzverfolgung zugleich gefährlicher.
Paged Attention teilt den KV-Cache-Speicher in wiederverwendbare Blöcke auf, statt pro Anfrage eine durchgehende Zuweisung zu verlangen. Kontinuierliches Batching fügt anschließend Sequenzen hinzu und entfernt sie, während eine GPU ausgelastet bleibt. Zusammen reduzieren diese Methoden verschwendeten Speicher.
Sie schaffen jedoch auch ein anspruchsvolles Buchhaltungsproblem. Physische Cache-Seiten werden fortlaufend zugewiesen, gelesen, freigegeben und neu zugewiesen. Das Serving-System muss die korrekte Zuordnung zwischen jeder logischen Sequenz und ihren physischen Seiten bewahren.
Eine veraltete Zuordnung könnte dazu führen, dass eine Anfrage eine falsche Seite liest. Das könnte die Antwort verfälschen, den Vorgang zum Absturz bringen oder Zustand offenlegen, der einer anderen Sequenz zugeordnet ist. Die genaue Folge hängt vom Fehler und den umgebenden Kontrollen ab.
Cloudflare erklärt, dass selbst sehr seltene Fehler bei seinem Anfragevolumen operativ relevant werden. Der Artikel verwendet einen Fehler pro einer Milliarde als anschaulichen Schwellenwert. Diese Aussage beschreibt den Bedarf an Schutzmaßnahmen, nicht eine offengelegte Vorfallrate.
Der Integritätsmechanismus des Unternehmens verknüpft jede physische Seite mit einem sich ändernden Tag. Eine Anfrage speichert die erwarteten Tags. Unterstützte Decode-Operationen prüfen diese Werte, bevor sie den gemeinsamen Cache lesen.
Eine Tag-Abweichung bricht die betroffene Anfrage ab. Dieses Design bevorzugt einen expliziten Fehler gegenüber einer Ausgabe, die auf dem falschen Zustand basiert. Es ähnelt Generationszählern, die in anderen Speicherverwaltungssystemen eingesetzt werden.
Cloudflare bewertete die Prüfung auf einem mittelgroßen Produktionsmodell mit zwei Prefill- und zwei Decode-Workern. Die Tests verwendeten Eingaben mit 8.192 Tokens und Ausgaben mit 1.000 Tokens. Die berichtete Parallelität reichte von eins bis acht.
Der Durchsatz sank über diese Tests hinweg um 0,38 bis 0,79 Prozent. Der Anstieg der p95-Latenz lag zwischen 0,42 und 0,80 Prozent. Cloudflare erklärt, selbst die obere Konfidenzgrenze sei nahe einem Prozent geblieben.
Das Unternehmen führt die Validierung als separate Batch-Prüfung aus. Es vermied, die Operation in den Attention-Kernel zu integrieren, weil GPU-Thread-Gruppen eine Race Condition erzeugen könnten. Für Deployments, in denen die Prüfung deaktiviert ist, bleibt ein No-op-Tracker verfügbar.
Diese Ergebnisse lassen Integritätsprüfungen kostengünstig erscheinen. Die Bewertung deckte jedoch nicht jede Modellgröße, Sequenzform oder Parallelitätsstufe ab. Außerdem konzentrierte sie sich auf unterstützte Decode-Operationen – eine Einschränkung, die Beachtung verdient.
Leser sollten den Mechanismus nicht als vollständigen Beweis für Mandantenisolation interpretieren. Cache-Integrität ist eine Verteidigungsschicht innerhalb eines größeren Serving-Systems. Routing, Speicherzuweisung, Kernel-Korrektheit und Prozessisolation bleiben relevant.
Die Prüfung kann eine Seiten-Generationsabweichung erkennen, die ihr Tracker versteht. Sie kann nicht automatisch jeden numerischen Fehler oder Softwaredefekt identifizieren. Ein gültiger Tag beweist nicht, dass der Seiteninhalt semantisch korrekt ist.
Zwischen optionalem Deployment und universellem Schutz besteht zudem ein Spannungsverhältnis. Cloudflare erklärt, dass die Integritätsprüfung pro Deployment aktiviert wird. Das erklärte Ziel ist, das Feature günstig genug zu machen, um es überall aktiviert zu lassen.
Bis dies erreicht ist, können Kunden nicht davon ausgehen, dass jeder Modellpfad denselben Schutz nutzt. Klare Dokumentation zur Abdeckung würde Entwicklern helfen, das verbleibende Risiko einzuschätzen. Unabhängige Sicherheitstests würden stärkere Belege liefern als reine Leistungsmessungen.
Der Sicherheitsansatz spiegelt dennoch eine wichtige Veränderung im Inferenz-Engineering wider. Leistungsfunktionen erfordern nun explizites Nachdenken über anfrageübergreifenden Zustand. Speicheroptimierung kann nicht mehr allein anhand von Durchsatzdiagrammen bewertet werden.
Komprimierung verstärkt diesen Bedarf. FP8-Kimi-Caches ermöglichen, dass mehr Anfragen aktiv bleiben. INT4-GLM-Gewichte schaffen mehr Platz für Cache-Seiten. Beide Veränderungen erhöhen die Menge an gemeinsamem Zustand, die ein Deployment verarbeitet.
Der Hauptgegner in dieser Geschichte ist daher unsichere Dichte. Das Ziel ist nicht maximale Verdichtung um jeden Preis. Es ist höhere Auslastung bei gleichzeitiger Wahrung von Anfragegrenzen und akzeptablem Modellverhalten.
Cloudflares Ansatz platziert die Sicherheitsprüfung nahe an der gemeinsam genutzten Ressource. Dadurch können Zuweisungsfehler erkannt werden, bevor Cache-Daten in eine Attention-Operation gelangen. Eine frühe Beendigung begrenzt zudem die Ausbreitung korrumpierten Zustands.
Abgebrochene Anfragen beeinträchtigen dennoch die Zuverlässigkeit. Wenn Prüfungen häufig fehlschlagen, sehen Nutzer Fehler oder Wiederholungsversuche, selbst wenn die Isolation wie vorgesehen funktioniert. Betreiber müssen Abweichungsraten verfolgen, Ursachen untersuchen und Retry-Stürme verhindern.
Cloudflare hat in dem Artikel keine Abweichungsrate für den Produktionseinsatz offengelegt. Diese fehlende Kennzahl ist wichtiger als der synthetische Overhead allein. Eine kostengünstige Prüfung ist nützlich, doch ihr operativer Wert wird erst deutlich, wenn sie tatsächliche Erkennungen meldet.
Das Unternehmen hat zudem ein Interesse daran, die neue Dichte als sicher darzustellen. Seine Belege sollten als technische Offenlegung durch den Betreiber des Systems betrachtet werden. Sie sind aufschlussreich, entsprechen jedoch keiner unabhängigen Prüfung.
Für Entwickler ist die übergeordnete Lehre praktisch. Gemeinsame Inferenz verbirgt Infrastrukturkomplexität, beseitigt sie jedoch nicht. Bewertungen von Anbietern sollten neben Latenz und Modellqualität auch Isolierungskontrollen, Fehlerbehandlung und Transparenz bei Vorfällen berücksichtigen.
Worauf zu achten ist, wenn sich die Optimierungen verbreiten
Drei Signale werden zeigen, ob Cloudflares Bereitstellung kleinerer Modelle zu einem nachhaltigen Vorteil wird oder eine spezialisierte Konfiguration bleibt.
Das erste Signal ist ein breiterer Einsatz von FP8-Caches. Cloudflare erklärt, FP8-KV-Caches auf weitere Teile seiner Flotte auszuweiten. Eine Abdeckung zusätzlicher Modelle und Hardware würde zeigen, dass die Kimi-KV-Cache-Quantisierung über ein einzelnes gemessenes Setup hinaus verallgemeinerbar ist.
Nützliche Belege würden Daten zu Parallelität, Perzentil-Latenzen und Qualität für unterschiedliche Sequenzlängen umfassen. Stabile Ergebnisse über diese Dimensionen hinweg würden Cloudflares Argument zur Speichereffizienz stärken. Häufige modellspezifische Ausnahmen würden es schwächen.
Das zweite Signal ist die NVFP4-Validierung auf Blackwell-GPUs. NVFP4 ist Nvidias Vier-Bit-Gleitkommaformat für neuere Hardware. Cloudflare erklärt, diese Repräsentation als weiteren Weg zu kleineren Gewichten zu testen.
Ein erfolgreicher Rollout könnte die GLM-Gewichtskompression über INT4 hinaus erweitern und das Gleichgewicht zwischen Prefill und Decode erneut verändern. Er würde zudem prüfen, ob Cloudflare seine phasenbewusste Strategie über Accelerator-Generationen hinweg übertragen kann.
Das entscheidende Ergebnis ist nicht eine einzelne Spitzen-Durchsatzrate. Achten Sie auf Ende-zu-Ende-Latenz, Qualitätsbewertungen und Speicherkapazität unter Produktions-Batching. Diese Messungen würden zeigen, ob niedrigere Präzision auf Anwendungsebene nützliche Vorteile bringt.
Das dritte Signal ist eine universelle Abdeckung der Cache-Integrität. Cloudflare möchte Prüfungen überall zu vernachlässigbaren Kosten aktivieren. Das Erreichen dieses Ziels würde höhere Dichte mit einer konsistenten standardmäßigen Sicherheitskontrolle verbinden.
Offenlegungen zur Abdeckung sollten unterstützte Modelle, Vorgänge und Hardware nennen. Erkennungsmetriken würden noch mehr Wert schaffen, insbesondere wenn Cloudflare erklärt, wie häufig Abweichungen auftreten und wodurch sie verursacht werden.
Diese Signale sind wichtig, weil die aktuellen Belege des Unternehmens zwar stark, aber begrenzt sind. Sie zeigen bedeutende Gewinne bei ausgewählten Modellen und Bereitstellungen. Sie belegen nicht, dass jede Arbeitslast von denselben Formaten profitiert.
Entwickler sollten gehostete Kimi- und GLM-Systeme mit realistischen Prompts, Tool-Ketten und Parallelität testen. Verfolgen Sie die Zeit bis zum ersten Token, die Generierungsgeschwindigkeit, Timeout-Raten und den Erfolg vollständiger Aufgaben. Vergleichen Sie das Verhalten nach anbieterseitigen Modellupdates.
Teams sollten zudem ihre eigene Evaluierungshistorie bewahren. Eine durchsuchbare Engineering-Wissensdatenbank kann Benchmark-Ergebnisse, Vorfälle, Konfigurationsänderungen und Anbieterankündigungen miteinander verknüpfen. Dieser Kontext hilft dabei, eine Modellregression von einer Infrastrukturänderung zu unterscheiden.
Cloudflare hat die Diskussion über Frontier-Modelle von bloßer Verfügbarkeit weggeführt. Die schwierigere Frage lautet, ob ein Anbieter große Modelle unter realer Parallelität schnell, wirtschaftlich, präzise und isoliert betreiben kann. Beobachten Sie die drei Rollout-Signale und bewerten Sie das System dann anhand vollständiger Arbeitslasten statt anhand eines einzelnen Benchmarks oder Durchsatzdiagramms.
