GGUF erklärt: Warum lokale KI-Modelle dieses Format nutzen

Wer heute ein lokales Sprachmodell auf einem Laptop, einem Consumer-PC oder einem Mac Studio startet, lädt fast garantiert eine GGUF-Datei. Das Format hat sich seit August 2023 durchgesetzt, obwohl es aus technischer Sicht weder besonders elegant noch besonders sauber dokumentiert ist. GGUF hat gewonnen, weil es pragmatisch ist, nicht weil es elegant ist. Drei banale Entscheidungen erklären die Dominanz: eine Datei statt zwölf Shards, Memory-Mapping statt vollständiges Laden in den RAM, und das CPU-first-Erbe von llama.cpp. Der Rest ist Community-Konvention. Dieser Text ordnet das Format ein, zeigt die wichtigsten Quantisierungsvarianten und beantwortet die eigentlich relevante Frage: Welches Q4_K_M-File soll man laden, und auf welcher Hardware läuft was.

Was GGUF technisch ist

Wofür das Akronym offiziell steht, ist nirgends belastbar definiert; die ggml-Spezifikation löst GGUF nicht auf. Eingeführt wurde GGUF im August 2023 von Georgi Gerganov als Nachfolger von GGML, GGMF und GGJT, den früheren Formaten der llama.cpp-Familie. Es ist ein binäres Single-File-Format, das Modellgewichte und Metadaten in einer strukturierten Key-Value-Sektion zusammenführt. Während GGJT noch mit einer untypisierten Liste arbeitete, definiert GGUF Tokenizer, Architektur, Kontextlänge, Prompt-Template und Quantisierungsschema explizit als Felder in der Datei selbst.

Der entscheidende Unterschied zu safetensors, dem heute dominierenden Format in Forschung und Training, liegt in der Zielgruppe. Safetensors speichert Tensoren, sonst nichts. Es ist ein sauberes Format der Forschung: reproduzierbar, verifizierbar, framework-agnostisch, aber nicht selbsttragend. Wer ein safetensors-Modell laden will, braucht ausserdem config.json, tokenizer.json, tokenizer_config.json, generation_config.json und typischerweise mehrere Shard-Dateien. GGUF packt all das in ein File. Es ist ein schmutziges Format der Praxis, gebaut für Deployment und nicht für Training.

Der zweite technische Kern ist Memory-Mapped Loading. Wenn Ollama oder LM Studio ein GGUF-Modell startet, wird die Datei per mmap in den Adressraum des Prozesses eingeblendet statt vollständig in den RAM kopiert. Das Betriebssystem lädt Seiten erst dann, wenn sie gebraucht werden. Der Nutzen liegt vor allem in schnellerem Start, effizientem Speicher-Sharing zwischen Prozessen und dem Wegfall einer expliziten Ladephase. Der oft zitierte Trick, dank mmap Modelle grösser als der verfügbare RAM zu betreiben, funktioniert bei autoregressiver LLM-Inferenz gerade nicht: die Gewichte werden Layer für Layer über jede Token-Generierung hinweg gelesen, faktisch berührt jede Inferenz alle Gewichte. Wer nicht genug RAM hat, landet im Swap-Thrashing. Nutzbar bleibt der Kniff nur in Randfällen wie sehr kurzen, gezielt geführten Abfragen an spezialisierten Modellen. Auf Apple Silicon mit Unified Memory ist der mmap-Pfad zudem besonders effizient, weil CPU und GPU auf denselben Adressraum zugreifen.

Die Quantisierungslandschaft

Ein GGUF-File beschreibt neben dem Modell auch, wie es quantisiert wurde. Die Formate zerfallen grob in drei Familien: Legacy-Formate (Q4_0, Q4_1, Q5_0, Q5_1, Q8_0), K-Quants (Q2_K bis Q6_K) und IQ-Quants (IQ2_XXS, IQ3_M, IQ4_NL und weitere). Legacy-Formate quantisieren blockweise mit fester Bitbreite, K-Quants arbeiten mit 256-Gewichte-Superblöcken und erreichen dadurch nicht-ganzzahlige effektive Bitbreiten. IQ-Quants sind eigene Formate; eine Importance-Matrix ist eine Kalibrierungsoption, die auch bei K-Quants genutzt werden kann.

Was das Paper «Which Quantization Should I Use?» tatsächlich zeigt

Bis Anfang 2026 war die Frage, welches Quantisierungslevel man auf lokalen Modellen laden soll, weitgehend Reddit-Folklore. Uygar Kurt hat mit «Which Quantization Should I Use?» (arXiv:2601.14277v1, Januar 2026) erstmals eine unifizierte empirische Studie für llama.cpp-Quantisierungen auf Llama-3.1-8B-Instruct vorgelegt und damit die Debatte auf Daten gestellt. Externer Benchmark (arXiv:2601.14277, nicht AISyndicate-eigene Messung, nur eingeschränkt vergleichbar): Die F16-Baseline liegt bei Avg 69.47 und Perplexity 7.32. Q3_K_S komprimiert das Modell um 77.23 Prozent, verliert dabei aber deutlich Qualität (Avg 65.49, PPL 8.96). Q4_K_M erreicht bei effektiv knapp 5 bpw eine Avg von 69.15 und PPL 7.56 und bleibt damit sehr nah an FP16, Q6_K kommt bei 6.6 bpw auf Avg 69.23 und PPL 7.35, Q8_0 landet praktisch auf der Baseline.

Interessant ist ein Detail, das leicht überinterpretiert wird: Q5_0 und Q5_1 liegen im gemessenen Durchschnitt minimal über der F16-Baseline (69.92 beziehungsweise 69.73). Das ist als Rauschen der Benchmark-Aggregation zu lesen, nicht als tatsächliches Übertreffen einer voll präzisen Referenz. K-Quants schlagen legacy-Formate bei vergleichbarer nominaler Bitbreite konsistent. Die Bench-Hardware des Papers waren zwei Intel Xeon Platinum 8488C mit AVX-512 und BF16. Für Durchsatzangaben auf Consumer-Hardware, also RTX 3060, RTX 4090, RTX 5090 oder Apple-Silicon-Laptops, sind diese Werte nicht belastbar übertragbar. Für Qualitätsvergleiche zwischen Quantisierungsstufen sind sie es.

Der eine Satz, den man aus dem Paper mitnehmen sollte: Der Schritt unter Q4_K_M lohnt nur bei realem VRAM-Druck; der Schritt darüber bringt messbar wenig und kostet deutlich RAM. Genau hinschauen lohnt bei der 4-Bit-Wahl: Das Paper weist Q4_K_S als Pareto-optimal aus, weil es etwas stärker komprimiert und minimal besser abschneidet als Q4_K_M. In der Alltagspraxis bleibt der Unterschied klein; Q4_K_M ist Community-Default, nicht Paper-Empfehlung. Wer die Quantisierungslogik dahinter tiefer verstehen will, findet die Grundlagen im DeepDive zu Quantisierungslevels und Verlustprofilen.

Welche Hardware für welche Modellgrösse

Die zweite Entscheidungsdimension ist Hardware. Die Faustformeln sind einfach: BF16 verbraucht etwa 2 Bytes pro Parameter, Q4_K_M grob 0.6 Bytes pro Parameter plus KV-Cache-Overhead, der mit Kontextlänge und Batch-Grösse wächst. Konkrete Zahlen weichen im laufenden Betrieb je nach Prompt-Länge, Beam-Search und Framework um 5 bis 15 Prozent ab.

Zwei Details, die in dieser Matrix nicht mitkommen und leicht falsch interpretiert werden. Erstens: Apple-Silicon-Systeme mit Unified Memory sind kein 1:1-Ersatz für diskreten VRAM. Das gesamte System teilt sich denselben Speicher, das Betriebssystem und andere Anwendungen belegen einen Teil, und die tatsächlich für Modellgewichte plus KV-Cache verfügbare Menge liegt in der Praxis 20 bis 30 Prozent unter der nominalen RAM-Grösse. Ein 192-GB-Mac-Studio-Ultra ist trotzdem klar besser für 70B-Modelle geeignet als jedes Consumer-GPU-Setup, weil der grosse zusammenhängende Speicher die Notwendigkeit von Model-Sharding vermeidet. Zweitens: Dual-GPU-Setups ohne NVLink verlieren beim Tensor-Splitting spürbar Durchsatz, und die Zahlen dort hängen stark vom Framework und der PCIe-Konfiguration ab.

Warum llama.cpp und nicht vLLM

GGUF ist eng an llama.cpp gebunden. Ollama, LM Studio, GPT4All und die meisten Consumer-GUIs wrappen im Kern denselben Inferenzcode. llama.cpp startete als CPU-only-Projekt und läuft nativ auf x86 mit AVX2 oder AVX-512, auf ARM mit NEON und auf Apple Silicon mit ARM-NEON und Metal-Backend. GPU-Offloading für CUDA, Metal und Vulkan wurde später ergänzt. Dieses CPU-first-Erbe ist der Grund, warum GGUF auf so vielen Zielen läuft und warum es das Standardformat für «lokale KI auf dem eigenen Rechner» geworden ist.

vLLM ist eine andere Welt. vLLM adressiert Rechenzentrums-Inferenz mit Continuous Batching und PagedAttention und arbeitet nativ mit safetensors und in GPU-optimierten Quantisierungsformaten wie GPTQ, AWQ und zunehmend FP8 sowie FP4. GGUF-Unterstützung in vLLM ist auch 2026 vorhanden, laut Dokumentation aber hoch experimentell, wenig optimiert und inzwischen in ein Out-of-Tree-Plugin (vllm-gguf-plugin) ausgelagert. Wer vLLM produktiv betreibt, landet in der Praxis meistens bei safetensors-Modellen oder der zugehörigen Quantisierung. Wer den Framework-Vergleich in ganzer Breite braucht, findet ihn im Framework-Vergleich zu vLLM, llama.cpp, Ollama und TensorRT-LLM.

Der Kontrast wird noch klarer, wenn man moderne Rechenzentrumsformate anschaut. NVFP4 auf Blackwell-GPUs bringt 4-Bit-Formate mit Hardware-Support für Tensor-Cores, integriert in vLLM und TensorRT-LLM. Der Gewinn ist Throughput, nicht Portabilität. Auf einem NVIDIA DGX Spark lässt sich mit NVFP4 ein 30-Milliarden-Parameter-Modell mit hoher Token-Rate bedienen, aber das Format führt aus dem Rechenzentrum nicht heraus. GGUF läuft auf einem MacBook Air ohne Zusatzsoftware. Das ist der eigentliche Unterschied, und er ist keine technische Überlegenheit von GGUF, er ist eine Konsequenz der Zielumgebung. Wer den Rechenzentrumsblick sucht, findet die Details unter FP4, Blackwell und NVFP4 für lokale KI.

Empfehlung

Ausgangspunkt für die praktische Auswahl ist immer die verfügbare VRAM- oder Unified-Memory-Menge. Die konkreten Hardware-Klassen und ihre passenden Modellgrössen stehen in der Matrix weiter oben. Die relevante Frage in der Praxis lautet weniger «was passt gerade noch rein» und mehr «wann lohnt sich ein Schritt weg vom Default».

Für Anwender ohne besondere Anforderungen ist Q4_K_M die richtige Default-Wahl. Sie hat sich als Community-Standard etabliert, weil der Qualitätsverlust gegenüber FP16 im Alltag meist nicht spürbar ist und der RAM-Bedarf drastisch sinkt. Das Paper 2601.14277 stützt die Nähe von Q4_K_M zur F16-Baseline mit Zahlen, empfiehlt aber eher Q4_K_S als Pareto-optimalen 4-Bit-Kompromiss und 5-Bit-Optionen wie Q5_0 als robustere Wahl, wenn genug Speicher vorhanden ist. Diese Aussage stützt sich auf Llama-3.1-8B-Instruct und gilt sauber vor allem für llama.cpp-Praxis mit 7B-8B-Modellen. Für kleinere Modelle unter 3B, sehr grosse Modelle jenseits von 34B und spezialisierte Aufgaben wie mathematisches Reasoning oder Multi-Turn-Coding ist Q4_K_M eine gute Ausgangshypothese, keine universelle Regel; hier lohnt ein eigener Vergleich gegen Q5_K_M oder Q6_K.

Über Q4_K_M hinausgehen sollte man dann, wenn eine Aufgabe entweder empfindlich auf feine Formulierungen reagiert oder wenn Fehler operativ teuer werden. Als Heuristik gilt: für sensitive Anwendungen wie Code-Generierung oder juristische Zusammenfassungen ist Q6_K der konservative Schritt nach oben. Belastbar validiert ist diese Faustregel nicht, sie kommt aus Praxiserfahrung und aus der Beobachtung, dass Q6_K in den vorliegenden Messungen praktisch auf FP16-Niveau liegt. Wer eigene Qualitätsanker hat, sollte Q5_K_M und Q6_K auf der konkreten Aufgabe gegeneinander stellen, statt sich auf Genrelabels zu verlassen.

Unterhalb von Q4_K_M ist der Schritt zu Q3_K_M oder IQ3_M nur sinnvoll, wenn das Modell sonst schlicht nicht lädt oder der KV-Cache sonst nicht in den Speicher passt. Der Qualitätsdrop im Paper (Q3_K_S auf Avg 65.49 gegenüber 69.47 für FP16) ist deutlich genug, dass die bessere Antwort in vielen Fällen ein kleineres Modell in höherer Quantisierung ist als dasselbe Modell in Q3.

Was bleibt, ist eine kritische Randnotiz. Das Format hinter Millionen lokaler Installationen hat weder eine offiziell aufgelöste Langform seines Akronyms noch eine vollständige offizielle Dokumentation seiner Quantisierungsverfahren. Die K-Quants, IQ-Formate und imatrix-Kalibrierungen sind primär in Quellcode und Community-Threads dokumentiert, weniger in einer belastbaren Referenz. Das erklärt, warum jede Diskussion über die richtige Quantisierung bis vor kurzem in Anekdoten endete. Genau deshalb ist arXiv:2601.14277 relevant. Nicht weil es das Format vollständig erklärt, sondern weil es die erste saubere Messung liefert, an der sich Empfehlungen orientieren können.