LLM für die NVIDIA RTX PRO 6000 Blackwell Server Edition nach NVFP4 oder FP8 quantisieren

Wann Sie ein Modell selbst quantisieren

Sie quantisieren ein Modell selbst, wenn es dafür keinen fertigen NVFP4- oder FP8-Checkpoint gibt: nach einem Fine-Tuning, für ein spezialisiertes oder regionales Modell oder wenn Sie ein anderes Rezept als das veröffentlichte wollen. Für FP8 braucht das dynamische Schema von llm-compressor keine Kalibrierungsdaten; für NVFP4 kalibrieren llm-compressor und NVIDIAs Model Optimizer auf einer kleinen Zahl von Beispielen. Der Server braucht vor allem CPU-Speicher für das 16-Bit-Modell, der GPU-Speicher ist zweitrangig.

Die Zahl der Beispiele reicht von 20 im Beispiel von llm-compressor bis 2.048 bei einem von NVIDIAs eigenen Checkpoints. Der Arbeitsspeicher steht an erster Stelle, weil die sequenzielle Pipeline von llm-compressor die meisten Gewichte dort hält, während sie das Modell Schicht für Schicht abarbeitet.

NVIDIA veröffentlicht NVFP4-Versionen vieler verbreiteter Modelle; unsere NVFP4-Checkpoint-Liste für die RTX PRO 6000 führt sie mit Größen und Kartenzahlen auf. Nutzen Sie einen davon, wenn es ihn gibt. Dieser Leitfaden behandelt die übrigen Fälle, mit der NVIDIA RTX PRO 6000 Blackwell Server Edition als Zielkarte für den Betrieb. Was die Formate sind und wie viele Bits sie kosten, steht in unserem Leitfaden zu FP8, NVFP4, MXFP4 und INT4; hier geht es um das Erzeugen des Checkpoints. Versionen und Dokumentation wurden am 24. Oktober 2026 gelesen.

FP8 oder NVFP4: welches Format Sie erzeugen

Die Wahl hängt von der GPU ab, auf der das Modell laufen wird.

vLLM-Dokumentation „FP8 W8A8“, Seite vom 24. September 2026 („FP8 computation is supported on NVIDIA GPUs with compute capability >= 8.9“); Dokumentation von llm-compressor zu den Kompressionsschemata und ihr NVFP4-Beispiel (unter SM100 „vLLM will not run activation“-Quantisierung). Gelesen am 24. Oktober 2026.

FP8 halbiert den Speicher eines BF16-Modells und läuft nativ auf jeder Karte, die wir für den LLM-Betrieb liefern. NVFP4 braucht etwa 56 Prozent des Speichers von FP8 und rechnet nur auf Blackwell nativ, unter unseren Karten also auf der Familie RTX PRO Blackwell und auf DGX Spark. Ein Modell, das auf H200 NVL ebenso wie auf RTX PRO 6000 laufen soll, ist als ein einziger FP8-Checkpoint einfacher zu betreiben. Ein Modell, das auf weniger Karten der RTX PRO 6000 passen oder mehr Speicher für den KV-Cache lassen soll, ist der Fall für NVFP4.

Der Unterschied beim Speicher ist groß genug, um den Server zu ändern. Unser Leitfaden zu Nutzern pro RTX PRO 6000 zeigt ihn für Llama 3.3 70B: 12 volle 8K-Sitzungen pro Karte mit FP8-Gewichten und FP8-Cache, 34 mit NVFP4-Gewichten.

Die zwei Werkzeuge: llm-compressor und Model Optimizer

Dokumentation von llm-compressor (Model Loading, Sequential Onloading, NVFP4-Beispiel) und Release-Seite von 0.13.0 (datiert 11. August, ohne Jahresangabe); README von Model Optimizer (Installation mit pip install -U nvidia-modelopt[all]) und README des Beispiels hf_ptq auf GitHub. Gelesen am 24. Oktober 2026.

llm-compressor. Das NVFP4-Beispiel in der Dokumentation quantisiert alle linearen Schichten außer dem Ausgabe-Head mit einer Rezeptzeile: einem QuantizationModifier mit targets="Linear", scheme="NVFP4" und ignore=["lm_head"]. Danach läuft oneshot mit einem Kalibrierungs­datensatz, gespeichert wird mit save_compressed=True. NVFP4 speichert Gewichte mit einer lokalen FP8-Skalierung je Block von 16 Elementen und einer globalen Skalierung pro Tensor; Aktivierungen erhalten eine globale Skalierung aus der Kalibrierung und lokale Skalierungen, die bei der Inferenz berechnet werden. Für FP8 empfiehlt die Dokumentation von vLLM das Schema FP8_DYNAMIC auf allen linearen Schichten ohne den Ausgabe-Head und schreibt: „we do not need any calibration data for this quantization flow“. Release 0.13.0 brachte Gewichtskalibrierung parallel über verteilte Worker und verlegte die Auslagerung auf Datenträger in den Kontext zum Laden des Modells.

Model Optimizer. NVIDIAs Bibliothek enthält ein Skript für Post-Training-Quantisierung, hf_ptq.py, aufgerufen zum Beispiel mit --pyt_ckpt_path für das Quellmodell, --qformat fp8, --kv_cache_qformat fp8_cast und --export_path für das Ergebnis. Das README nennt nvfp4 unter den Formaten und empfiehlt nvfp4_mlp_only, nvfp4_experts_only oder nvfp4_omlp_only „for higher NVFP4 accuracy“. Das Format des KV-Caches ist standardmäßig fp8_cast, mit nvfp4 und none als Alternativen. Empfohlen ist als Ausgabe ein vereinheitlichter Hugging-Face-Checkpoint, den TensorRT-LLM direkt und vLLM und SGLang mit quantization="modelopt" laden. Das ist der Weg, den NVIDIA für seine eigenen NVFP4-Checkpoints nutzt; deren Karten nennen die Version von Model Optimizer, etwa 0.48.0 für Qwen3.8-27B.

Welches Werkzeug Sie nehmen, hängt vor allem von der Engine im Betrieb ab. Wer nur vLLM betreibt, kann beide nutzen. Für TensorRT-LLM oder um eines von NVIDIAs Rezepten auf einer feinabgestimmten Version desselben Modells nachzubauen, ist Model Optimizer der direkte Weg; sein README kennzeichnet die NVFP4-Unterstützung je Modellfamilie, etwa Llama 3.x und 4, Qwen 3, DeepSeek V3 bis V3.2, Kimi K2, GPT-OSS und Nemotron 3, und führt Gemma 3 und Phi-4 als nicht unterstützt.

Kalibrierungsdaten und Zahl der Beispiele

Bei der Kalibrierung läuft eine kleine Menge Prompts durch das Modell, um den Wertebereich der Aktivierungen zu messen, aus dem die Skalierungen bestimmt werden. Die veröffentlichten Beispielzahlen umfassen zwei Größenordnungen:

NVFP4-Beispiel von llm-compressor; README des Beispiels hf_ptq von Model Optimizer (Standard calib_set); Modellkarten von NVIDIA. Gelesen am 24. Oktober 2026.

Das Beispiel von llm-compressor nennt die wichtigere Regel: Die Kalibrierungsdaten sollen dem entsprechen, was das Modell im Einsatz sieht, bei einem feinabgestimmten Modell etwa Beispiele aus seinen Trainingsdaten. Ein auf deutsche Verträge feinabgestimmter Rechtsassistent sollte auf deutschen Verträgen kalibriert werden, nicht auf einem englischen Chat-Datensatz. Halten Sie die Kalibrierungsprompts in der Länge, mit der der Dienst laufen wird; ein Modell für Fragen mit langem Kontext braucht lange Kalibrierungsbeispiele, wie das Rezept von Lightning mit seinen Beispielen von 32K Tokens zeigt.

Wurde das Modell mit LoRA feinabgestimmt, führen Sie zuerst den Adapter zusammen. merge_and_unload() von PEFT führt die Adaptergewichte mit dem Basismodell zusammen und gibt ein eigenständiges Modell zurück. Die Dokumentation von PEFT weist außerdem darauf hin, dass bei einem quantisierten Modell „merging re-quantizes the base weight“; führen Sie also in die BF16-Gewichte zusammen und quantisieren Sie das zusammengeführte Modell, nicht umgekehrt. Unser Leitfaden zum GPU-Speicher für Fine-Tuning behandelt die Trainingsseite.

Wir bauen Server mit Karten der RTX PRO 6000 Server Edition, die das quantisierte Modell betreiben und genug Arbeitsspeicher haben, um es zu erzeugen; senden Sie uns Basismodell, Größe und gewünschtes Format, und unser Team antwortet mit einer Konfiguration für beide Aufgaben.

Was der Server braucht: Arbeitsspeicher, GPU und Laufwerke

Die sequenzielle Pipeline verschiebt, wo Speicher gebraucht wird. Die Dokumentation von llm-compressor beschreibt sie so: „only a fraction of the model weights are moved to GPU memory for calibration“, während „the rest of the weights remain offloaded to CPU or disk“; der Kalibrierungs­datensatz liegt auf der CPU und wird Batch für Batch auf die GPU geholt. Standardmäßig wird je eine Decoder-Schicht verschoben; sequential_targets="Linear" verschiebt stattdessen einzelne lineare Schichten, was „will result in lower VRAM usage, but a longer runtime“. Für Modelle, die nicht in den CPU-Speicher passen, empfiehlt der Leitfaden zum Laden von Modellen device_map="auto_offload", das zuerst die CPU versucht und dann auf den Datenträger ausweicht, mit offload_folder auf „a file system with lots of storage“; er warnt, dass „some operations may be slower due to disk offloading“.

Nach unserer Schätzung brauchen BF16-Gewichte zwei Bytes pro Parameter. Gegenüber dem Arbeitsspeicher unserer Referenz­konfigurationen auf der Seite KI-Server ergibt das:

unsere Rechnung, 2 Bytes pro Parameter; Llama 3.3 70B mit etwa 141 GB wie in unserem VRAM-Leitfaden; Arbeitsspeicher der Einstiegs- und der Inferenzkonfiguration auf unserer Seite KI-Server. Ein Server mit acht Karten der RTX PRO 6000 Server Edition, den wir mit 1.536 GB anbieten, hält das 397B-Modell im Speicher.

Betriebssystem, Kalibrierungsdaten und der erzeugte Checkpoint brauchen ebenfalls Platz, für die Zeile mit 128B ist es auf dem Einstiegsserver also enger, als die Spalte nahelegt. Auf der GPU-Seite hat eine Decoder-Schicht eines dichten 70B-Modells nach unserer Schätzung etwa 1,8 GB in BF16 (141 GB über 80 Schichten), weit unter den 96 GB einer RTX PRO 6000; bei den großen MoE-Schichten der größten Modelle hilft sequential_targets="Linear". Model Optimizer hat eigene Stellschrauben: --use_seq_device_map nutzt „up to 80% of each GPU's memory“ über die GPUs hinweg, und --low_memory_mode komprimiert die Gewichte vor der Kalibrierung auf niedrige Genauigkeit, unterstützt nur für FP8 und NVFP4 mit Max-Kalibrierung.

Der dritte Punkt ist der Platz auf den Laufwerken. Die BF16-Quelle, ein eventueller Auslagerungsordner und das Ergebnis müssen gleichzeitig auf schnellem lokalem Speicher liegen; bei einem 397B-Modell sind das deutlich über ein Terabyte. Unser Leitfaden zu NVMe-Speicher für einen LLM-Server dimensioniert die Laufwerke, und unser Leitfaden zum Arbeitsspeicher eines GPU-Servers erklärt, warum wir als Ausgangspunkt das Doppelte des GPU-Speichers anbieten.

Ein Ablauf, der im Betrieb trägt

1. Die Quelle festlegen. Halten Sie den genauen BF16-Checkpoint fest und bei einem Fine-Tuning das zusammengeführte Modell. Notieren Sie die Werkzeugversion, hier llm-compressor 0.13.0 oder die Version von Model Optimizer, im Ausgabeordner.
2. Das Format nach der GPU im Betrieb wählen. FP8 für eine gemischte Flotte mit H200 NVL oder L40S; NVFP4 für Server mit RTX PRO 6000 Server Edition, bei denen der Speicher pro Karte die Grenze ist.
3. Mit dem Standardrezept beginnen. Ausgabe-Head ausgenommen, alle anderen linearen Schichten quantisiert; bei Mixture-of-Experts-Modellen ein Rezept nur für die Experten versuchen, wie NVIDIA es bei mehreren eigenen Checkpoints tut.
4. Auf eigenen Daten kalibrieren. Einige Hundert Beispiele aus dem Einsatzbereich in realistischer Länge.
5. In der Engine laden. Lesen Sie in vLLM das Start-Log auf Fallback-Warnungen und die KV-Cache-Größe, wie unser Leitfaden zu KV-Cache-Größe und maximaler Parallelität in vLLM erklärt. Auf Karten der RTX PRO 6000 bedeutet eine Zeile mit W4A16 oder Marlin, dass der native NVFP4-Pfad nicht genommen wurde.
6. Gegen BF16 evaluieren. Die FP8-Dokumentation von vLLM evaluiert mit lm_eval, etwa auf 250 Beispielen von GSM8K, und weist darauf hin, dass quantisierte Modelle empfindlich auf das Token am Sequenzanfang reagieren können. Ergänzen Sie Ihre eigenen Aufgaben, wie in unserem Leitfaden zur LLM-Evaluierung vor Modell-Upgrades.
7. Die BF16- oder FP8-Version behalten. Scheitert das NVFP4-Modell an einer Aufgabe, steht der Rückfall ohne zweiten Quantisierungslauf bereit.

Feinabgestimmte Modelle brauchen jeden dieser Schritte: Das Fine-Tuning verändert die Wertebereiche der Gewichte, ein veröffentlichtes NVFP4-Rezept für das Basismodell ist also nur ein Ausgangspunkt.

Auf welchem Server Sie quantisieren

Quantisierung ist ein Batch-Job und braucht keinen eigenen Server. Der Server mit RTX PRO 6000 Server Edition, der das Modell betreiben wird, kann es auch erzeugen, solange Arbeitsspeicher und Laufwerke zum Quellmodell passen. Nach der Tabelle oben deckt die Einstiegskonfiguration mit zwei Karten und 384 GB dichte Modelle bis etwa 128B in BF16 ab, der Inferenzknoten mit vier Karten und 768 GB bietet mehr Reserve. Für die größten Mixture-of-Experts-Modelle heißt die Wahl Auslagerung auf den Datenträger mit längerer Laufzeit oder ein Server mit mehr Speicher, etwa ein Server mit acht Karten der RTX PRO 6000 Server Edition und den 1.536 GB, die wir dafür anbieten. Unsere Seiten zum Server mit vier Karten der RTX PRO 6000 Server Edition und zu CPU, RAM und Storage für einen Server mit vier GPUs liefern die Details zu den Komponenten.

Den quantisierten Checkpoint betreibt dann dieselbe Engine wie jeden veröffentlichten. Ein feinabgestimmtes 70B-Modell in NVFP4, bei gleichem Rezept etwa so groß wie NVIDIAs Checkpoint von Llama 3.3 70B mit 42,7 GB, läuft nach unserer Nutzer-pro-Karte-Regel auf einer Karte mit Platz für 34 volle 8K-Sitzungen mit FP8-Cache.

Unser Engineering-Partner Vixen.UNO richtet im Rahmen unseres Private-AI/ML-Service offene Modelle mit vLLM auf den Servern ein, die wir liefern; beschreiben Sie Modell und gewünschtes Format, und wir prüfen Werkzeug- und Engine-Versionen dafür, bevor Sie bestellen.

FAQ