NVFP4-KV-Cache auf der NVIDIA RTX PRO 6000 Blackwell Server Edition: Genauigkeit, Nutzer

Was ein NVFP4-KV-Cache auf der RTX PRO 6000 Server Edition ändert

Ein NVFP4-KV-Cache speichert Keys und Values jeder offenen Unterhaltung als 4-Bit-Gleitkommazahlen mit einer FP8-Skalierung je 16 Werte und braucht damit 56 Prozent des Speichers eines FP8-Caches. Auf der NVIDIA RTX PRO 6000 Blackwell Server Edition werden so nach unserer Nutzer-pro-Karte-Regel aus 12 gleichzeitigen 8K-Sitzungen von Llama 3.3 70B pro Karte 21. Die erste veröffentlichte Messung, deren Kapazitäts- und Geschwindigkeitstests auf dieser Karte liefen, zeigte Genauigkeitsverluste von Bruchteilen eines Punktes bis 1,6 Punkte; SGLang nennt die Funktion experimentell, und vLLM hat sie für diese Karten mit Release 0.32.0 vom 18. Oktober 2026 eingeführt.

Wie viele Nutzer auf eine Karte passen, entscheidet nach dem Laden des Modells der KV-Cache. Die Formate für Gewichte behandelt unser Leitfaden zu FP8, NVFP4, MXFP4 und INT4, das gesamte Speicherbudget der Beitrag wie viel VRAM ein LLM braucht. Dieser Artikel behandelt die eine Entscheidung, die dort offen bleibt: ob Sie den Datentyp des Caches auf Servern mit RTX PRO 6000 Server Edition von FP8 auf NVFP4 umstellen, was das bringt und was es kostet. Alle Versionen und Werte wurden am 24. Oktober 2026 gelesen.

Bytes pro Token: FP8 gegenüber NVFP4

NVFP4 hat für den Cache dasselbe Layout wie für Gewichte. Jeder Wert ist eine E2M1-Zahl mit einem Vorzeichenbit, zwei Exponentenbits und einem Mantissenbit. Je 16 Werte teilen sich eine FP8-Skalierung im Format E4M3, darüber liegt eine FP32-Skalierung pro Tensor. Der LMSYS-Beitrag, der das Format in SGLang vorstellte, rechnet pro Block: 8 Bytes gepackte Daten und 1 Byte Skalierung für 16 Werte, gegenüber 16 Bytes in FP8. Das ergibt ein Verhältnis von 0,5625, und LMSYS gibt den idealisierten Kapazitätsgewinn mit etwa dem 1,78-Fachen an, „before workspace and other overheads“.

Bei einem Modell mit voller Attention in jeder Schicht beträgt der Cache pro Token 2 × Schichten × KV-Heads × Head-Dimension × Bytes pro Wert. Llama 3.3 70B hat 80 Schichten, 8 KV-Heads und eine Head-Dimension von 128, das ergibt 163.840 Werte pro Token.

Geometrie von Llama 3.3 70B und die Werte für BF16 und FP8 wie in unserem VRAM-Leitfaden; NVFP4 = FP8 × 0,5625 nach unserer Rechnung aus dem Format, wie es der LMSYS-Beitrag vom 16. September 2026 beschreibt, gelesen am 24. Oktober 2026.

Die Spalte für 128K zeigt, wo das Format am meisten zählt. Eine einzige 128K-Unterhaltung braucht mit FP8-Cache 20 GiB, mehr als die 15,3 GiB, die auf einer Karte neben den FP8-Gewichten von Llama 3.3 70B frei bleiben. Mit NVFP4-Cache braucht sie 11,25 GiB und passt. Lange Kontexte, Agenten mit großen Tool-Ausgaben und Dokumentprüfung sind die Fälle, in denen der Cache und nicht die Zahl der Nutzer die Grenze setzt, wie unser Leitfaden zu Hardware für LLMs mit langem Kontext zeigt.

Ein Detail des Formats sollten Sie beim Lesen veröffentlichter Ergebnisse kennen. Die Versuche von LMSYS nutzten eine globale FP32-Skalierung von 1,0 ohne Kalibrierung, und die Autoren schreiben, dass eine richtige Kalibrierung den Abstand bei der Genauigkeit verringern kann. Die Dokumentation von vLLM beschreibt dieselbe Wahl für den FP8-Cache: Ohne Kalibrierung sind „all quantization scales … set to 1.0“, und sie empfiehlt für die höchste Qualität eine Kalibrierung auf einem Datensatz mit llm-compressor.

Sitzungen pro Karte nach unserer Nutzer-pro-Karte-Regel

Unsere Nutzer-pro-Karte-Regel nimmt 90 Prozent der 95,6 GiB, die der Treiber meldet, abzüglich 3 GiB pro Karte für Aktivierungen und Laufzeit, abzüglich der Gewichte. Auf einer RTX PRO 6000 Server Edition bleiben so 83,0 GiB für Gewichte und Cache. Eine Sitzung ist eine Anfrage mit vollem Kontext von 8.192 Tokens.

unsere Nutzer-pro-Karte-Regel (0,9 × 95,6 GiB, abzüglich 3 GiB pro Karte, abzüglich der Gewichte), Modell Llama 3.3 70B; Gewichte aus NVIDIAs Checkpoints, 67,7 GiB in FP8 und 39,8 GiB in NVFP4; 1,25 GiB pro 8K-Sitzung mit FP8-Cache, 0,70 GiB mit NVFP4. Die Werte mit FP8-Cache sind die unserer Leitfäden zu Nutzern und zum Server mit vier Karten.

Diese Zahlen sind eine Untergrenze, wie in unserem Leitfaden zu Nutzern pro RTX PRO 6000: PagedAttention belegt Blöcke nach Bedarf, und die meisten Sitzungen füllen ihren deklarierten Kontext nie. Sie setzen außerdem das volle 1,78-Fache voraus. Die einzige veröffentlichte Messung auf dieser Karte lag darunter. Bei Qwen3.8-27B mit 32K Kontext stieg die Parallelität auf einer Server-Edition-Karte von 44 Anfragen mit FP8-Cache auf 70 mit NVFP4, das 1,59-Fache, und bei 160K von 10 auf 15. LMSYS nennt das 1,78-Fache vor Arbeitsbereich und anderem Speicher-Overhead und schreibt, dass die real nutzbare Kapazität von Last und Konfiguration abhängt. Lesen Sie die Cache-Größe, die vLLM oder SGLang beim Start ausgibt, statt mit 1,78 zu multiplizieren; unser Leitfaden zu KV-Cache-Größe und maximaler Parallelität in vLLM erklärt diese Log-Zeilen.

Wir liefern Server mit zwei, vier oder acht Karten der RTX PRO 6000 Server Edition; senden Sie uns Modell, Kontextlänge und Zahl der Nutzer, und unser Team antwortet mit einer Konfiguration, ausgelegt für einen FP8-Cache und mit der Reserve, die ein NVFP4-Cache hinzufügen würde.

Veröffentlichte Genauigkeit: was LMSYS gemessen hat

Der Beitrag „Accelerating Long-Context and Agentic Inference with NVFP4 KV Cache“ erschien am 16. September 2026 im LMSYS-Blog, verfasst von den Teams von SGLang, Qwen und NVIDIA. Die Genauigkeitsläufe mit Qwen3.5-397B-A17B nutzten acht Karten der RTX PRO 6000 Blackwell Server Edition, die erste solche Messung auf dieser Karte, die wir gefunden haben; für die Genauigkeitsläufe mit Qwen3.8-27B nennt der Beitrag keine GPU, die Geschwindigkeitsläufe mit diesem Modell liefen auf einer Server-Edition-Karte. Beide Cache-Konfigurationen nutzten dieselben FP8-Gewichte; nur der Datentyp des Caches änderte sich.

LMSYS-Blog, 16. September 2026, FP8-Gewichte, globale FP32-Skalierung 1,0, GPU für diese Läufe im Beitrag nicht genannt; AIME 2025 im Thinking-Modus. Der Beitrag nennt die Ergebnisse für GSM8K und GPQA-Diamond als Differenzen. Gelesen am 24. Oktober 2026. Pp. = Prozentpunkte.

Das zweite Modell war Qwen3.5-397B-A17B in FP8 auf acht Server-Edition-Karten mit TP=8. Dort ergab der NVFP4-Cache bei GSM8K eine richtige Antwort weniger, etwa 0,08 Punkte, und bei GPQA-Diamond und AIME 2025 identische Summen. Die Autoren begrenzen ihre Schlussfolgerung selbst: Zwei Modelle und eine kleine Auswahl an Aufgaben ergeben keine allgemeine Regel, und sie empfehlen eine Prüfung je Aufgabe.

Der Pull Request 46963 von vLLM, der den NVFP4-Cache auf SM8x und SM12x brachte, liefert eine Warnung vom anderen Ende der Skala. Bei GSM8K über alle 1.319 Fragen erreichte Qwen3-0.6B mit BF16-Cache 0,384 und mit NVFP4 0,174. Qwen3-4B kam auf 100 Fragen in zwei BF16-Läufen auf 0,920 und 0,910 und in beiden NVFP4-Läufen auf 0,880. Ein Maintainer nannte den Rückgang beim 0.6B-Modell Quantisierungsrauschen bei einem sehr kleinen Modell. Das Muster in diesen Zahlen ist einheitlich: Die großen Modelle verloren wenig, das kleinste sehr viel. Ein Firmenassistent auf einem Modell der 70B-Klasse oder einem großen Mixture-of-Experts-Modell liegt näher am Fall von LMSYS; ein kleines Modell für Klassifikation oder Extraktion braucht einen eigenen Test, bevor sich der Datentyp des Caches ändert.

Geschwindigkeit: Decode, Prefill und Agenten-Last

Der Gewinn an Kapazität zeigt sich auch im Durchsatz, weil ein größerer residenter Cache der Engine mehr Anfragen pro Batch erlaubt. LMSYS hat Qwen3.8-27B mit 1.024 Ausgabe-Tokens pro Anfrage auf einer Server-Edition-Karte gemessen.

LMSYS-Blog, 16. September 2026, Qwen3.8-27B, FP8-Gewichte, eine RTX PRO 6000 Blackwell Server Edition; der Beitrag gibt den Gewinn bei gleicher Parallelität als Spanne über die drei Längen an; bei 1M nutzte der NVFP4-Lauf einen statischen Speicheranteil von 0,75 gegenüber 0,90 bei FP8. Gelesen am 24. Oktober 2026.

Bei gleicher Parallelität decodierte NVFP4 schneller, obwohl jeder Wert umgewandelt werden muss. Der im Beitrag beschriebene Decode-Kernel für SM120 nimmt BF16-Queries und NVFP4-Keys und -Values und multipliziert in BF16, liest also pro Token weniger Speicher. Beim Prefill war es knapp umgekehrt: Die mittlere Zeit bis zum ersten Token war bei gleicher Parallelität 0,20 bis 0,40 Prozent länger, was die Autoren vor allem dem Aufwand für Quantisierung und Dequantisierung zuschreiben, und unter kapazitätsgetriebener Last 0,74 bis 10,72 Prozent kürzer. Dieser Wert enthält, wie sie anmerken, Zulassungs- und Wartezeit und geht nicht allein auf schnelleren Prefill zurück. Die Autoren weisen darauf hin, dass Gewinne beim Decode nicht dasselbe sind wie Beschleunigung von Ende zu Ende.

Der Beitrag enthält außerdem einen Agenten-Benchmark, AgentX, mit Qwen3.5-397B-A17B: vergleichbare Ergebnisse bis zu einer Parallelität von 8, und oberhalb von 12 verlor der FP8-Lauf an Durchsatz, während NVFP4 weiter stieg. Dieser Durchlauf lief auf acht Karten RTX 6000D, einer anderen GPU als der Server Edition; nehmen Sie ihn als Hinweis für Agenten-Last, nicht als Wert für unsere Server.

Unterstützung in den Engines im Oktober 2026

LMSYS-Blog vom 16. September 2026; Release Notes von vLLM v0.32.0 vom 18. Oktober 2026 (Pull Requests 46963 und 60452) und Pull Request 46963; Quantisierungsmatrix von TensorRT-LLM, Dokumentation 1.4.0rc1, zuletzt aktualisiert am 19. Oktober 2026. Alles gelesen am 24. Oktober 2026.

SGLang. Der LMSYS-Beitrag nennt SM12x und SM100/SM103 als unterstützt und weitere Architekturen als geplant. Auf der Modellseite unterstützt er Grouped-Query Attention und Sparse MLA, Sparse GQA ist in Arbeit. Der Beispielserver kombiniert den Cache mit --prefill-attention-backend flashinfer und --decode-attention-backend trtllm_mha, und die FP8-Basis lief mit --kv-cache-dtype fp8_e4m3. Gemessen wurde auf einem festgelegten Commit von SGLang; ein Release, das den Code enthält, ist die sicherere Grundlage für den Betrieb.

vLLM. Der Pull Request 46963, am 7. Oktober 2026 übernommen, schaltet --kv-cache-dtype nvfp4 auf SM8x und SM12x über FlashInfer frei; vorher, schreibt sein Autor, ließ sich der Datentyp auf diesen GPUs gar nicht nutzen, während SM100 bereits einen Pfad hatte. Release 0.32.0 lieferte ihn mit XQA-Decode auf SM12x aus. Der Pull Request nennt, was er ablehnt: Head-Größe 64, Attention Sinks und Decode Context Parallelism. Ein Nutzer meldete außerdem deutlich langsameres Decodieren mit MTP-Speculative-Decoding auf SM120; der Autor antwortete mit Pull Request 60452, dem XQA-Decode-Pfad für SM120, der mit 0.32.0 ausgeliefert wurde und MTP wieder in vollen CUDA Graphs laufen lassen soll. Ob das die Verlangsamung bei Ihrem Modell behebt, zeigt nur Ihre eigene Messung. Prüfen Sie Head-Größe und Attention-Aufbau Ihres Modells gegen diese Liste und messen Sie mit Ihren Einstellungen für Speculative Decoding, bevor Sie umstellen.

TensorRT-LLM. NVIDIAs Quantisierungsmatrix gibt sm120 eine eigene Zeile. Sie nennt den FP8-KV-Cache, aber keinen NVFP4-KV-Cache, den sie für die Klasse sm100/103 führt. Wer TensorRT-LLM einsetzt, bleibt auf diesen Karten beim FP8-Cache. Unser Leitfaden zur Software-Unterstützung für SM120 zeigt den Versionsstand aller drei Engines.

H200 NVL und die anderen Karten

Die H200 NVL ist Hopper mit Compute Capability 9.0 und hat keine FP4-Tensor-Cores. vLLM akzeptiert dort trotzdem einen NVFP4-Cache: Der Pull Request 60620, am 8. Oktober 2026 übernommen und bei den Cache-Änderungen von 0.32.0 aufgeführt, nimmt SM90 in die Architekturen auf, die NVFP4 über den fa2-Pfad von FlashInfer lesen. Sein Autor schreibt, dass SM90 keine FP4-Umwandlungsbefehle hat und FlashInfer deshalb in Software dequantisiert, wie auf SM8x, und dass die Änderung nicht auf SM90-Hardware lief. Ein Reviewer prüfte sie auf einer H200: Prefill und Decode lagen bei Head-Größe 128 innerhalb von 0,3 Prozent einer dequantisierten BF16-Referenz, die GSM8K-Ergebnisse meist nahe an BF16, ein Five-Shot-Lauf deutlich niedriger. Durchsatz wurde nicht gemessen. Der LMSYS-Beitrag behandelt Hopper nicht.

Für die H200 NVL ist die Speicherersparnis dasselbe Verhältnis von 0,5625, und mit 141 GB pro Karte ist der Cache selten die erste Grenze: Unsere Regel ergibt auf einer Karte 44 Sitzungen von Llama 3.3 70B mit FP8-Gewichten und FP8-Cache. Ob die Umwandlung in Software Geschwindigkeit kostet, ist nicht veröffentlicht. Auf L40S und L4 (Ada, 8.9) gilt der SM8x-Pfad von vLLM; die ursprüngliche Beschreibung des Pull Requests 46963 führte SM89 als ungetestet. Unser Vergleich von RTX PRO 6000 und H200 NVL für LLM-Inferenz wägt die beiden Karten in allen anderen Punkten ab.

So führen Sie einen NVFP4-Cache im Betrieb ein

Die Schritte folgen aus den veröffentlichten Ergebnissen und den Hinweisen der Engines oben.

1. Den Server für FP8 auslegen. Planen Sie Kartenzahl und Kontextlänge mit FP8-Cache, wie es unsere Seiten zur Dimensionierung tun. Behandeln Sie den NVFP4-Cache als Reserve, die Sie nach dem Test einschalten, und sagen Sie sie den Nutzern nicht als Kapazität zu.
2. Die Engine festlegen. vLLM 0.32.0 oder neuer oder ein Release von SGLang, das den Code für den NVFP4-Cache enthält. Notieren Sie die FlashInfer-Version im Image.
3. Modellmerkmale prüfen. Head-Größe, Attention Sinks, Sliding Windows, MLA und Speculative Decoding entscheiden, ob die Engine den Datentyp annimmt und wie schnell sie decodiert.
4. Den Evaluierungsdatensatz zweimal laufen lassen. Gleiche Gewichte, gleiche Prompts, FP8-Cache gegen NVFP4-Cache, mit den Metriken, auf die es Ihren Nutzern ankommt. Unser Leitfaden zur LLM-Evaluierung vor Modell-Upgrades beschreibt das Vorgehen. Achten Sie besonders auf kleine Modelle und Aufgaben mit langem Kontext.
5. Das Start-Log lesen. Vergleichen Sie die GPU-KV-Cache-Größe in Tokens zwischen beiden Läufen; das Verhältnis für Ihr Modell ist der Gewinn, mit dem Sie planen.
6. Lasttest bei Ihrer Kontextlänge. Messen Sie Zeit bis zum ersten Token und Decode-Geschwindigkeit bei der erwarteten Parallelität und halten Sie die FP8-Einstellung als dokumentierten Rückfall bereit.

Unser Engineering-Partner Vixen.UNO richtet vLLM und das Modell auf den Servern, die wir liefern, im Rahmen unseres Private-AI/ML-Service ein; nennen Sie uns Modell und geplante Kontextlänge, und wir prüfen Engine-Version und Cache-Einstellungen gegen die Release Notes, bevor Sie bestellen.

FAQ