FP8, INT8, NVFP4 oder GGUF: Welches Modellformat zu deiner Grafikkarte passt

Darum geht es

Wer auf Hugging Face ein neues Bildmodell wie Krea 2, Z-Image, Qwen-Image oder MOSS-Image herunterladen will, steht vor einer Liste mit Dateien: bf16, fp8_scaled, mxfp8, int8_convrot, nvfp4, dazu GGUF-Varianten von Q3 bis Q8. Hinter jedem Kürzel steckt ein Speicherformat, also die Frage, mit wie vielen Bits und nach welchem Schema die Zahlen des Modells abgelegt werden. Kleinere Formate passen auf kleinere Grafikkarten, laufen manchmal schneller und verändern das Bild mehr oder weniger stark.

Hersteller-Dokumentation dazu, welches Format auf welcher Karte am besten ist, gibt es kaum. Dafür liegen inzwischen mehrere Messreihen aus der Community vor. Wir haben sie zusammengetragen und gegeneinander gestellt. Unsere These: Die Bitzahl allein sagt wenig. Entscheidend ist, ob die eigene Karte das Format in Hardware rechnen kann und wie empfindlich das jeweilige Modell reagiert.

Die Messreihen im Überblick

Ein Vorbehalt vorweg: Der große Reddit-Benchmark enthält laut seinem eigenen Test-Kit keine einzige RTX-40-Karte. Der Autor sucht ausdrücklich nach Ada-Besitzern. Aussagen zu Ada stützen sich deshalb vor allem auf die L40S-Messung bei Hugging Face und die RTX 4070 aus Japan.

Welche Karte welches Format wirklich rechnen kann

Ein Format spart immer Speicher. Schneller wird es nur, wenn die Grafikkarte passende Recheneinheiten hat. Sonst werden die Zahlen vor jeder Rechnung wieder in 16 Bit entpackt (dequantisiert), was Zeit kostet. Laut der Bibliothek comfy-kitchen, die ComfyUI für diese Formate nutzt, braucht FP8 mindestens die Ada-Generation (SM 8.9), NVFP4 und MXFP8 brauchen Blackwell. Comfy selbst nennt für NVFP4 nur RTX-50- und Blackwell-Pro-Karten und verlangt PyTorch mit CUDA 13.0. Ohne diese Version kann NVFP4 laut Comfy-Blog bis zu doppelt so langsam sein wie FP8.

INT8 ConvRot ist dabei der Neuling. Klassisches INT8 (8-Bit-Ganzzahlen) galt lange als ungeeignet, weil einzelne Ausreißerwerte die grobe Zahlenskala sprengen. ConvRot stammt aus einem Paper vom Dezember 2025 (arXiv 2512.03673). Es „verwirbelt“ die Werte gruppenweise mit einer Hadamard-Rotation, sodass Ausreißer sich auf viele Stellen verteilen. Laut japanischer Analyse ist das Format seit ComfyUI v0.27.0 (Juli 2026) direkt eingebaut. Die Autoren des Papers melden für W4A4 auf FLUX.1-dev einen 2,26-fachen Tempogewinn bei 4,05-mal weniger Speicher.

Tempo und Treue: was die Zahlen zeigen

Die sauberste Gegenüberstellung liefert die MOSS-Image-Messung auf Hugging Face: zwölf Prompts und Seeds, 1024×1024 Pixel, 25 Schritte. Gemessen wurde neben dem Tempo auch LPIPS, ein Maß dafür, wie stark sich ein Bild für das menschliche Auge vom BF16-Bild mit gleichem Seed unterscheidet (niedriger = näher am Original).

INT8 ConvRot ist auf Ampere und Ada schneller und näher am Original als FP8. Erst auf Blackwell überholt NVFP4 beim Tempo knapp, weicht aber am stärksten ab. Das deckt sich mit dem Reddit-Benchmark: INT8 ConvRot war dort „in jedem getesteten Modell das treueste Format“, auf einer 3090 etwa doppelt so schnell wie BF16. NVFP4 war auf RTX 50 am schnellsten, driftete aber am meisten. Auch Unsloth misst für Qwen-Image-2.1 bei INT8 einen mittleren LPIPS von 0,064, bei FP8 0,112.

Die Messungen aus Japan bestätigen das auf Mittelklasse-Karten (Krea 2, 768×768):

Zusätzlich sank der Arbeitsspeicherbedarf beim Raw-Modell um rund 14 GB. Bei den aktuellen RAM-Preisen ist das ein echtes Argument. Auf der RTX 5090 maß der zweite japanische Autor bei Krea 2 Turbo (1024², 8 Schritte): INT8 ConvRot 2,56 s, NVFP4 3,29 s, FP8 scaled 3,91 s, BF16 4,84 s. NVFP4 ist also selbst auf Blackwell nicht automatisch am schnellsten. Bei Z-Image Turbo lag NVFP4 dort mit 1,24 s gegenüber 1,46 s für INT8 allerdings vorn.

Wo es nicht funktioniert

Die Gegenbeispiele sind wichtig, weil sie zeigen, wie stark das Ergebnis vom System abhängt:

• A100: Im ComfyUI-Issue #14824 lief INT8 ConvRot nur mit 33 bis 50 Prozent der FP8-Geschwindigkeit. Comfy-Entwickler comfyanonymous erklärte, die INT8-Einheiten der A100 seien nur etwa doppelt so schnell wie FP16, auf RTX 30/40/50 dagegen etwa viermal. Das Issue wurde ohne Lösung geschlossen. Ein Nutzer kam mit einer frischen Installation (CUDA 13, ohne zusätzliche Attention-Pakete) aber auf etwa 1,4-fache Geschwindigkeit.
• T4: Ein Nutzer meldete, ConvRot sei bei ihm „immer langsamer als GGUF“. Geklärt wurde das nicht.
• AMD: Auch hier gibt es Berichte in beide Richtungen. Auf einer RX 7900 XTX war INT8 zwei- bis dreimal langsamer als FP8, auf Strix Halo dagegen leicht schneller.
• Mac: Auf einem M1 Max war die INT8-Variante von Anima langsamer als BF16 (47,2 s gegenüber 42,2 s), weil Apples MPS keine INT8-Matrixrechnung kennt.
• Videomodelle: Bei Wan 2.2 meldeten Nutzer auf RTX 5090 und 4060 Ti nur 5 bis 10 Prozent Gewinn gegenüber FP8, die Bewegung sei etwas weniger flüssig.

4 Bit: dasselbe Format, völlig andere Ergebnisse

Bei 4 Bit zeigt sich am deutlichsten, dass die Bitzahl wenig verrät. W4A4 bedeutet: Sowohl die gespeicherten Gewichte (W) als auch die Zwischenwerte beim Rechnen, die Aktivierungen (A), werden auf 4 Bit gerundet. Bei W4A8 bleiben die Aktivierungen bei 8 Bit. Das comfy-quant-bench-Repo hat beides auf einer RTX 3090 durchgemessen:

Die Aktivierungen machen den Unterschied. Der mittlere Fehler pro Schicht lag bei HunyuanVideo mit W4A8 bei 0,0695, mit W4A4 bei 0,2136. Der Autor nennt als Faustregel: Über 0,21 geht es kaputt, unter 0,15 funktioniert es. Er betont aber selbst, dass das keine geeichte Schwelle ist. Auch „Z-Image läuft“ ist nicht unumstritten: Der japanische Test fand bei INT4 auf Z-Image Turbo sichtbar verschlechterte Haut und ein leicht verändertes Gesicht. Bei sehr kleinen Modellen wie Anima (2B) lieferten die ersten INT4-Konvertierungen gar keine brauchbaren Bilder.

Für LTX 2.5 kommt der Ton hinzu: Das offizielle INT8 von Lightricks liegt beim Bild 1,9-mal, beim Ton 2,9-mal näher am Original als W4A8. Auf der 3090 war W4A8 bei Krea 2 laut einem weiteren Benchmark etwa 15 Prozent langsamer als INT8, sparte aber 39 Prozent Speicher. 4 Bit ist auf älteren Karten also vor allem eine Speicherlösung.

Zwei Fallen: Textencoder und Turbo-LoRAs

Textencoder (das Sprachmodell, das den Prompt übersetzt) lassen sich ebenfalls auf 4 Bit bringen, etwa Gemma 3 12B von 22,70 auf 8,31 GiB. Im normalen ComfyUI werden sie laut comfy-quant-bench aber vor dem Rechnen entpackt. Das spart Speicher, aber keine Zeit. Mit einem speziellen Node, der das umgeht, sank die Prompt-Verarbeitung bei Gemma von 2,354 auf 0,539 Sekunden. Ein Wan-Nutzer bestätigt, dass der INT8-Textencoder bei ihm nichts beschleunigte.

Turbo-LoRAs, also kleine Zusatzmodule, mit denen ein Modell in 4 bis 8 statt 20 bis 50 Schritten fertig wird, vertragen sich schlecht mit fertigen Quants. Wird so ein LoRA erst beim Laden auf ein quantisiertes Modell gelegt, rundet sich laut Reddit-Benchmark der Großteil seiner Wirkung weg. Die Empfehlung lautet: erst in BF16 einbacken, dann quantisieren.

Und GGUF?

GGUF, bekannt von Sprachmodellen, ist in ComfyUI nur ein Speicherformat. Der Entwickler city96 schreibt dazu, man entpacke die Gewichte „on the fly“ und rechne mit ComfyUIs normalem Code. Comfy-Entwickler Kijai nennt GGUF daher „ein unnötig langsames Format für Diffusionsmodelle“ und schätzt es auf INT8-fähiger Hardware mehr als doppelt so langsam. Bei der Treue ist GGUF Q8 dagegen stark: In einer Reddit-Messreihe lag Q8 bei Qwen-Image 2512 und Z-Image Turbo vor INT8 ConvRot, lief aber ohne Auslagerung etwa so langsam wie BF16. Bei Q4_K_M brach die Qualität bei Qwen-Image 2512 auf 13,78 dB ein, schlechter als FP8. Für MOSS-Image ließ sich das GGUF in ComfyUI zudem gar nicht laden. Sinnvoll bleibt GGUF mit stable-diffusion.cpp und bei sehr knappem Speicher.

Was auf welche Karte passt

Wichtig vorab: Laut Reddit-Benchmark lief nichts gar nicht. Passt ein Modell nicht in den Grafikspeicher, lagert ComfyUI Teile in den Arbeitsspeicher aus und holt sie bei jedem Schritt zurück. Das ist langsam, aber es funktioniert. Die folgende Tabelle ist unsere Einschätzung aus den Messungen. Wo keine Messung vorliegt, steht das dabei. Dateigrößen nach den Quellen, teils in GiB.

Unser Fazit

Für die meisten Besitzer von RTX-20- bis RTX-50-Karten ist INT8 ConvRot im aktuellen ComfyUI die beste Standardwahl. Es kommt dem Original am nächsten und ist auf Ampere und Ada schneller als FP8. Auf einer 3060 mit 12 GB macht das bei Krea 2 den Unterschied zwischen zehn und dreieinhalb Minuten pro Bild. FP8 ist auf RTX 40 nicht falsch, aber in keiner der vorliegenden Messungen besser. NVFP4 lohnt sich nur auf Blackwell mit CUDA 13, und auch dort nur, wenn man Tempo oder Speicher über Bildtreue stellt. 4 Bit ist eine Speicherlösung mit Risiko: W4A8 hat sich bisher als robust erwiesen, W4A4 muss man Modell für Modell prüfen.

Offen bleibt einiges. Die größte Messreihe hat keine RTX-40-Karte, die Fehlermaße zeigen Abweichung vom Original, nicht Schönheit, und A100, AMD, T4 und Mac zeigen, dass Treiber, PyTorch-Version und Installation das Ergebnis umdrehen können. Wer umsteigt, sollte deshalb ein festes Prompt-und-Seed-Paar in BF16 und im neuen Format vergleichen, bevor er die große Datei löscht.