Quantisierungsformate und die Hardware, die sie benötigen

Quantisierung tauscht Präzision gegen Größe und Geschwindigkeit, und sie hat zwei unabhängige Achsen: der Quantisierungsname (Q4_K_M, INT4, FP8 — wie viele Bits und wie sie gepackt sind, behandelt in Quantization explained) und das Quantisierungsformat (GGUF, AWQ, NVFP4 — das Dateiformat und der Kernel, durch den es läuft, der entscheidet, welche Hardware es tatsächlich laden kann). Diese Seite behandelt die zweite Achse: Wählen Sie eine Zeile unten, und Sie wissen, welche Hardware sie benötigt.

​

The matrix

† vLLMs eigene Hardware-Support-Tabelle listet AWQ mit x86/Arm-CPU-Unterstützung über einen separaten Code-Pfad auf, aber nicht GPTQ; behandeln Sie beide in der Praxis als GPU-first-Formate. ‡ vLLMs Kompatibilitätstabelle markiert AWQ und GPTQ als nicht unterstützt auf AMD-GPUs in vLLM speziell — dies ist eine vLLM-Laufzeit-Einschränkung, keine Aussage über jeden AWQ/GPTQ-Kernel überall. § Pre-Blackwell-NVIDIA-GPUs haben nicht die Tensor-Core-Unterstützung, die NVFP4 benötigt; es ist keine reine Treiber-Einschränkung. ** Das Kern-PyPI-Paket von MLX zielt auf Apple Silicon + macOS; das Projekt liefert auch ein experimentelles Linux-CUDA-Backend für das Framework selbst aus, aber MLX-quantierte Modelldateien, die Sie auf Hugging Face finden, sind für den Apple-Metal-Pfad gebaut. Quellen für jede Aussage oben sind in den Notizen unten zitiert.

​

Per-format notes

​

GGUF — the portable default

GGUF ist das Modellformat von llama.cpp, und es ist das, was Ollama und LM Studio unter der Haube verwenden. Es läuft auf CPU, Apple Metal, NVIDIA CUDA, AMD ROCm (über HIP) und Vulkan — llamas eigene Build-Dokumentation listet dedizierte Build-Ziele für all diese Backends, was GGUF zum portabelsten Format über Consumer-Hardware macht. Wenn Sie nicht sicher sind, was Ihre Hardware unterstützt, ist GGUF die sichere Standardwahl. Siehe llama.cpp und die GGUF spec.

​

bf16 / FP16 — the baseline

bf16 und FP16 speichern jeden Parameter in 2 Bytes ohne Kompression. Dies ist die Präzision, die quantisiert from — jede Q4-, AWQ- oder NVFP4-Datei ist eine kleinere, verlustreichere Version eines bf16/FP16-Originals. Behandeln Sie den Support als framework-abhängig: CUDA- und ROCm-Serving-Stacks unterstützen diese Präzision häufig, wenn Sie genug Speicher haben, während CPU-, Metal- und Vulkan-Pfade von der Laufzeit abhängen und für große Modelle oft unpraktisch sind. Bei etwa 4x dem Fußabdruck einer 4-Bit-Quantisierung ist bf16/FP16 selten das, was Sie lokal auf Consumer-Hardware betreiben. Siehe GPU-to-model fit für die Speicherberechnung.

​

AWQ and GPTQ — GPU-oriented, vLLM’s formats

AWQ und GPTQ sind 4-Bit-Quantisierungsformate, die für GPU-Inferenz gebaut sind, und vLLM ist die Laufzeit, die beide dokumentiert und unterstützt. Laut vLLMs Hardware-Kompatibilitätstabelle laufen beide auf NVIDIA-GPUs (Volta bis Hopper, wobei GPTQ zusätzlich auf Volta unterstützt wird); vLLMs Tabelle zeigt keines als auf AMD-GPU unterstützt. Behandeln Sie sie als NVIDIA/CUDA-first-Paar, außer Sie haben das Gegenteil für Ihre spezifische Laufzeit bestätigt. Siehe vLLM’s quantization docs.

​

MXFP4 — gpt-oss’s native format

MXFP4 ist das Microscaling-4-Bit-Floating-Point-Format des Open Compute Project, und es ist das Format, in dem OpenAI gpt-oss nativ ausgeliefert hat — sowohl gpt-oss-120b als auch gpt-oss-20b werden auf Hugging Face vorab in MXFP4 quantisiert verteilt, was 120b bei etwa 80 GB und 20b bei etwa 16 GB laufen lässt. llama.cpp hat native MXFP4-Unterstützung für gpt-oss hinzugefügt, und vLLM unterstützt es ebenfalls. Siehe OpenAI — Introducing gpt-oss und die llama.cpp gpt-oss support notes.

​

NVFP4 — Blackwell only

NVFP4 ist NVIDIAs eigenes 4-Bit-Floating-Point-Format, maßgeschneidert für die Tensor Cores der fünften Generation in der Blackwell-Architektur (RTX 50-Serie Consumer-Karten und Blackwell-Generation Datacenter-GPUs). NVIDIAs eigener technischer Blog beschreibt NVFP4 als Blackwell-Tensor-Core-Format mit einem zweistufigen Skalierungsschema und positioniert es neben MXFP4 und FP4 als die drei 4-Bit-Formate, die Blackwells Tensor Cores nativ unterstützen. Wenn Ihre GPU vor Blackwell stammt, ist NVFP4 nicht das richtige Format — suchen Sie stattdessen nach einem GGUF-, AWQ- oder GPTQ-Build desselben Modells. Siehe NVIDIA — Introducing NVFP4.

​

MLX — Apple Silicon

MLX ist Apples Array-Framework, gebaut um ein einheitliches Speichermodell, bei dem Arrays im gemeinsamen Speicher über CPU und GPU leben. MLX-quantierte Modelle — das Format, das LM Studio und andere Mac-first Tools neben GGUF anbieten — zielen auf Apple Silicon unter macOS 14 oder später. Die eigenen Installationsdokumente des Projekts listen Apple Silicon + macOS als primär unterstützten Pfad auf (mit einem experimentellen Linux/CUDA-Backend für das Framework selbst, getrennt von den Modelldateien, die Sie im MLX-Format verteilt finden). Wenn Sie nicht auf einem Mac sind, ist MLX keine Option — verwenden Sie stattdessen GGUF. Siehe MLX on GitHub und die MLX install docs.

​

Which should you pick?

Ordnen Sie das Format der Hardware zu, die Sie bereits haben, nicht umgekehrt:

• NVIDIA, Consumer-Karte (RTX 40/30-Serie oder ältere Blackwell-lose Karten) — GGUF für den einfachsten Pfad (Ollama, LM Studio) oder AWQ/GPTQ, wenn Sie vLLM betreiben und den zusätzlichen Durchsatz eines GPU-nativen Kernels wollen.
• NVIDIA Blackwell (RTX 50-Serie oder Blackwell-Datacenter-GPUs) — alles oben genannte funktioniert weiterhin, aber suchen Sie nach einem NVFP4-Build, wenn das Modell einen veröffentlicht; es ist das Format, das für Ihre Tensor Cores gebaut ist.
• Apple Silicon — GGUF (über Metal) ist der einfachste und häufigste Pfad; MLX ist eine Mac-native Alternative, die einige Tools (wie LM Studio) Seite an Seite mit GGUF anbieten.
• AMD-GPU — GGUF über ROCm oder Vulkan. AWQ/GPTQ-Support auf AMD ist über Laufzeiten inkonsistent, planen Sie also nicht darum herum.
• Nur CPU — GGUF. Es ist das einzige Format in dieser Matrix mit echtem CPU-Inferenz-Support, und es ist das, worauf llama.cpp, Ollama und LM Studio aufbauen.

Für den Quantisierungs-Namen, den Sie innerhalb des gewählten Formats wählen sollten (Q4_K_M vs Q8_0 zum Beispiel), siehe Quantization explained. Für die Größenanpassung eines bestimmten Modells an Ihren VRAM siehe GPU-to-model fit.