GGUF Quantisierung im Test: Q4_K_M vs Q6_K vs Q8_0 gemessen

👁 123 Aufrufe

Das Dateiformat GGUF bündelt Gewichte und Metadaten lokaler Sprachmodelle für llama.cpp, während Kürzel wie Q4_K_M, Q6_K oder Q8_0 den Grad der Kompression angeben. Die GGUF Quantisierung bestimmt maßgeblich, wie viel Grafikspeicher ein Modell belegt und wie schnell es antwortet: Q4_K_M markiert das solide Minimum für den Alltag, Q5_K_M und Q6_K agieren nahezu verlustfrei, und Q8_0 lohnt sich primär bei üppigem VRAM. Wer seinen PC vorbereiten will, findet im Überblick zu lokale KI-Modelle die passenden Grundlagen.

Was Sie wählen sollten: Die wichtigsten Empfehlungen

• Q4_K_M: Die schlankste Variante, bei der Textqualität und Grammatik nicht spürbar einbrechen. Das Modell Bielik 11B belegt in Q4_K_M exakt 6,72 GB und trifft in 94,1 % aller Fälle denselben Top-1-Token wie die unkomprimiertere Version Q8_0.
• Q5_K_M und Q6_K: Sofern der VRAM ausreicht, bildet diese Stufe den idealen Sweet Spot. Der Unterschied in der Perplexity gegenüber Q8_0 bewegt sich im Bereich der normalen Messungenauigkeit.
• Q8_0: Entspricht praktisch dem Original (96,7 % Übereinstimmung mit F16 bei Bielik 1.5B), benötigt jedoch beinahe das doppelte Speichervolumen im Vergleich zu Q4_K_M und generiert langsamer.
• Q3_K_M und kleinere Stufen: Nur für sehr große Parameterzahlen und als Notlösung empfehlenswert. Kleinere Modelle wie Bielik 1.5B brechen in Q2_K komplett ein (0 von 12 Testaufgaben korrekt).
• Modellgröße schlägt Quantisierungsgrad: Ein größeres Modell in Q4 schneidet besser ab als ein kompaktes Modell in Q8. Bielik 11B in Q3_K_M (5,40 GB) löste 11 von 12 Aufgaben korrekt, während Bielik 4.5B in Q8_0 (5,06 GB) nur 5 von 12 schaffte.

Was ist das GGUF-Format?

GGUF steht für ein binäres Dateiformat, das vom Team hinter ggml-org für llama.cpp entwickelt wurde und seit August 2023 den Standard für CPU- und GPU-Inferenz auf Endgeräten darstellt. Eine einzige Datei beinhaltet sowohl die Modellgewichte als auch sämtliche notwendigen Metadaten: Netzwerkarchitektur, Tokenizer-Vokabular, Chatformate und Kontextgrößen. Aus diesem Grund lässt sich dieselbe GGUF-Datei ohne zusätzliche Konfigurationsdateien in llama.cpp, in LM Studio oder Ollama sowie in Systemen wie Open WebUI laden.

Die GGUF-Spezifikation folgt dabei einem klaren Benennungsschema nach dem Muster Name-Größe-Tuning-Version-Kodierung.gguf. Im Dateinamen Bielik-11B-v3.0-Instruct.Q4_K_M.gguf signalisiert das letzte Kürzel direkt die verwendete Quantisierungsstufe.

GGUF Quantisierung erklärt: Von F16 bis Q4_K_M

Quantisierung bedeutet schlicht, die numerischen Gewichte eines neuronalen Netzes mit weniger Bits abzuspeichern. Das Originalmodell speichert jedes Gewicht üblicherweise in 16 Bit (F16 oder BF16). Die Stufe Q8_0 reduziert diesen Wert auf rund 8,5 Bit pro Gewicht, während Q4_K_M mit weniger als 5 Bit auskommt. Die resultierende Datei ist deutlich kleiner, passt vollständig in den Videospeicher gängiger Grafikkarten und erzeugt Textausgaben spürbar schneller, da bei der autoregressiven Textgenerierung die Speicherbandbreite den limitierenden Faktor darstellt.

Die Angaben der Bits pro Gewicht stammen aus der Dokumentation von llama-quantize (gemessen anhand von Llama 3.1 8B). Der Buchstabe K steht für k-quants: Hierbei werden Gewichte in 256er-Superblöcke unterteilt, wobei auch die Skalierungsfaktoren selbst quantisiert werden. Zusätze wie _S, _M, _L kennzeichnen gezielte Mischungen: Bei Q4_K_M erhalten besonders fehleranfällige Tensoren eine höhere Rechengenauigkeit (Q6_K), während Q4_K_S alle Tensoren rein in Q4_K belässt. IQ bezeichnet neuere Quantisierungen mit nichtlinearer Verteilung. Eine imatrix (Importance Matrix) analysiert Textbeispiele vorab, um signifikante Gewichte zu identifizieren und dort Rundungsfehler gezielt zu minimieren.

Eigene Messungen auf der RTX 4090

Ich habe am 17. Oktober 2026 auf meinem Testsystem (Nvidia GeForce RTX 4090 24 GB, Intel Core i9-14900KF, 64 GB RAM, Windows 11) alle Varianten mit llama.cpp unter CUDA getestet. Alle Schichten lagen dabei vollständig auf der GPU.

• Dateibasis: Offizielle F16- und Q8_0-Releases von Bielik 1.5B v3.0 sowie Q8_0 von Bielik 4.5B und 11B aus dem Hugging-Face-Repository von SpeakLeash (verifiziert über SHA256-Prüfsummen). Fehlende Zwischenstufen habe ich über llama-quantize selbst erzeugt. Für 11B kam zusätzlich die offizielle Q4_K_M-Fassung aus Ollama zum Einsatz.
• Perplexity und Token-Übereinstimmung: Gemessen mit llama-perplexity bei Kontext 2048 auf dem Beginn von „Romans Teresy Hennert“ von Zofia Nałkowska (ca. 7900 Wörter, Wolne Lektury, Gemeinfreiheit seit 2025). Die Übereinstimmung beschreibt den Anteil der Tokens, bei denen der Top-1-Kandidat identisch mit der Baseline ist (F16 bei 1.5B, Q8_0 bei 4.5B und 11B).
• Geschwindigkeit: Ermittelt über llama-bench bei einer Generierung von 128 Tokens (Mittelwert aus 3 Durchläufen).
• VRAM-Bedarf: Zuwachs in nvidia-smi bei aktivem llama-server und Kontextgröße 4096.
• Aufgabentest: 12 kurze Kontrollfragen mit exakt einer validen Antwort (Deklination, Textkorrektur, Prozentrechnung, JSON-Generierung, Zahlen als Text, Phraseologie) bei Temperatur 0.

Bielik 1.5B: Von F16 bis Q2_K im Detail

Das kompakte 1.5B-Modell stößt unabhängig von der Kompression an harte Grenzen: Selbst in nativer F16-Genauigkeit ordnete das Modell den Roman „Lalka“ fälschlicherweise Stanisław Ignacy Witkiewicz zu. In Q3_K_M wurde Stanisław Lem als Urheber genannt, und in Q2_K verfiel das System bei einer Frage zur Verfassung vom 3. Mai 1791 in eine Endlosschleife mit der Jahreszahl „1997“.

Bielik 11B: Vergleich der Leistungsdaten

Die Messwerte von Q4_K_M in der zweiten Tabelle basieren auf der offiziellen Datei. Meine selbst konvertierte Q4_K_M-Fassung aus Q8_0 wies ein identisches Speichervolumen auf und lieferte bei 109,1 tok/s sowie 10 von 12 gelösten Aufgaben praktisch dieselben Resultate.

Erkenntnisse aus der Messreihe

• Bis hinauf zu Q5_K_M bleiben Abweichungen in der Perplexity kleiner als die übliche Messschwankung (bei 11B ca. ±0,10). Erste signifikante Einbußen zeigen sich bei Q4_K_M in kleinen Modellen sowie ab Q3_K_M bei größeren Modellen.
• Je größer die Basisarchitektur ausfällt, desto robuster verhält sie sich gegenüber Kompression: Q4_K_M behielt bei 11B eine Token-Übereinstimmung von 94,1 %, sank bei 1.5B auf 83,6 % und erreichte bei 4.5B einen Wert von 82,7 % (jeweils relativ zu Q8_0 gemessen).
• Der Einsatz einer Importance Matrix (imatrix) steigert die Qualität ohne Speicheraufschlag: Q4_K_M mit imatrix kletterte bei identischer Dateigröße von 83,6 % auf 88,1 % Übereinstimmung.
• Die synthetische Aufgabenserie zeigte bei 11B keine praxisrelevanten Unterschiede: 9 bis 11 Punkte sind statistisches Rauschen einzelner Antwortformate. Token-Match und Perplexity liefern ein deutlich feineres Bild.
• Auf dem Werk „Lalka“ von Prus ergab die Perplexity für Bielik 11B einen Extremwert von 1,20, was auf ein fast vollständiges Auswendiglernen dieses Trainingsabschnitts hinweist. Deshalb diente der Nałkowska-Text als neutralere Basis. Absolute Werte zwischen 1.5B und 11B lassen sich aufgrund abweichender Tokenizer nicht direkt gleichsetzen (14.767 gegenüber 23.760 Tokens für denselben Textabschnitt). Wer größere Modelle mit ähnlicher Effizienz betreiben will, findet im Test zu Gemma 4 31B lokal auf der RTX 4090 praxisnahe Werte.

Grafikkarten-Empfehlungen: 8, 12, 16 und 24 GB VRAM

Die im Test gemessenen VRAM-Werte beziehen sich ausschließlich auf den Prozess von llama-server. Betriebssystem und Browser belegen unter Windows 11 typischerweise zusätzliche 1 bis 2 GB Grafikspeicher.

• 8 GB VRAM: Bielik 11B in Q3_K_M (belegt 6,3 GB bei 4096 Kontext) oder Bielik 4.5B in Q8_0 (5,3 GB). Die Variante Q4_K_M von 11B benötigt 7,5 GB und sitzt auf 8-GB-Karten hart an der Absturzkante.
• 12 GB VRAM: Bielik 11B in Q4_K_M oder Q5_K_M (7,5 bis 8,6 GB) lässt ausreichend Spielraum für mittlere Kontextpuffer.
• 16 GB VRAM: Bielik 11B in Q6_K (9,7 GB) oder alternativ Q4_K_M mit vollem 32k-Kontextfenster (13,0 GB).
• 24 GB VRAM: Bielik 11B in Q8_0 selbst bei voller Auslastung von 32.768 Tokens (17,7 GB) oder deutlich mächtigere Architekturen in Q4_K_M.

So vergleichen Sie Quantisierungen auf dem eigenen PC

1. Laden Sie llama.cpp aus dem offiziellen GitHub-Repository von ggml-org herunter (für NVIDIA-Grafikkarten das vorbereitete CUDA-Archiv) und entpacken Sie es, beispielsweise nach D:\llama-cuda.
2. Laden Sie zwei bis drei Quantisierungsstufen eines Modells in einen Zielordner herunter: hf download speakleash/Bielik-11B-v3.0-Instruct-GGUF Bielik-11B-v3.0-Instruct.Q4_K_M.gguf --local-dir D:\modele.
3. Überprüfen Sie die Datenintegrität in der PowerShell via Get-FileHash D:\modele\*.gguf und gleichen Sie den SHA256-Hashwert mit der Hugging-Face-Quelle ab.
4. Erstellen Sie eine Textdatei im Format UTF-8 mit einigen tausend Wörtern Fließtext, den das Modell möglichst nicht vorab memoriert hat.
5. Führen Sie das nachfolgende Skript aus, um eine tabellarische Auswertung zu Speicherauslastung, Durchsatz und Perplexity sowie eine CSV-Datei zu generieren.

Automatisierung via PowerShell: porownaj-kwantyzacje.ps1

Ich habe das Skript am 17. Oktober in einer separaten Umgebung mit zwei Varianten von Bielik 1.5B verifiziert. Auf der CPU allein (über den Parameter -Warstwy 0) lag die Perplexity für Q4_K_M bei 54,31, während der GPU-Lauf exakt 54,27 ergab.

# porownaj-kwantyzacje.ps1 - Vergleich von GGUF-Quantisierungen in llama.cpp
# Fuer jede .gguf-Datei im Ordner: Dateigroesse, Tempo (llama-bench: Prompt 512, Generierung 128 Tokens, 3 Durchlaeufe)
# und optional Perplexity anhand einer Textdatei (llama-perplexity, Kontext 2048). Ausgabe: Konsole + CSV.
#
# Nutzung (PowerShell):
#   powershell -ExecutionPolicy Bypass -File .\porownaj-kwantyzacje.ps1 -Modele D:\modele -Llama D:\llama-cuda -Tekst D:\tekst.txt
# -Modele  Ordner mit GGUF-Dateien
# -Llama   Ordner mit llama-bench.exe und llama-perplexity.exe (llama.cpp mit CUDA)
# -Tekst   (optional) UTF-8-Textdatei mit Fliesstext; ohne Parameter wird nur die Geschwindigkeit gemessen
# -Warstwy (optional) Anzahl der Schichten auf der GPU, Standard: 99 = vollstaendig
param(
    [Parameter(Mandatory = $true)][string]$Modele,
    [Parameter(Mandatory = $true)][string]$Llama,
    [string]$Tekst = "",
    [int]$Warstwy = 99
)
$ErrorActionPreference = "Continue"   # llama.cpp schreibt Logs auf stderr - Stop in PowerShell wuerde abbrechen
$bench = Join-Path $Llama "llama-bench.exe"
$ppl = Join-Path $Llama "llama-perplexity.exe"
if (-not (Test-Path $bench)) { throw "Nicht gefunden: $bench - bitte Pfad in -Llama pruefen" }
$pliki = Get-ChildItem -Path $Modele -Filter *.gguf | Sort-Object Length -Descending
if ($pliki.Count -eq 0) { throw "Im Ordner $Modele wurden keine .gguf-Dateien gefunden" }
if ($Tekst -and -not (Test-Path $Tekst)) { throw "Textdatei nicht gefunden: $Tekst" }

$wyniki = @()
foreach ($p in $pliki) {
    Write-Host "== $($p.Name)" -ForegroundColor Cyan
    $w = [ordered]@{ Plik = $p.Name; GB = [math]::Round($p.Length / 1e9, 2); Prompt_tok_s = ""; Generowanie_tok_s = ""; Perplexity = "" }

    # 1. Geschwindigkeit via llama-bench (JSON-Auswertung)
    $json = & $bench -m $p.FullName -p 512 -n 128 -r 3 -ngl $Warstwy -o json 2>$null | Out-String
    $start = $json.IndexOf("[")
    if ($start -ge 0) {
        foreach ($e in ($json.Substring($start) | ConvertFrom-Json)) {
            if ($e.n_prompt -gt 0) { $w.Prompt_tok_s = [math]::Round($e.avg_ts, 1) } else { $w.Generowanie_tok_s = [math]::Round($e.avg_ts, 1) }
        }
    } else { Write-Host "llama-bench lieferte keine Daten (zu wenig VRAM? -Warstwy 20 testen)" -ForegroundColor Yellow }

    # 2. Perplexity (niedriger ist besser; nur identische Modelle auf demselben Text vergleichen)
    if ($Tekst) {
        $log = & $ppl -m $p.FullName -f $Tekst -c 2048 -ngl $Warstwy 2>&1 | Out-String
        $m = [regex]::Match($log, "Final estimate: PPL = ([\d.]+)")
        if ($m.Success) { $w.Perplexity = [double]::Parse($m.Groups[1].Value, [Globalization.CultureInfo]::InvariantCulture) }
        else { Write-Host "llama-perplexity ohne Ergebnis (Text zu kurz? mind. 4100 Tokens noetig)" -ForegroundColor Yellow }
    }
    $wyniki += [pscustomobject]$w
    Write-Output ($w | Format-Table -AutoSize | Out-String)
}
$wyniki | Export-Csv -Path (Join-Path $Modele "benchmark_ergebnisse.csv") -NoTypeInformation -Encoding utf8
Write-Host "Fertig. CSV-Datei gespeichert." -ForegroundColor Green

In Ollama entfällt jeder manuelle Konvertierungsschritt: Der Aufruf ollama run SpeakLeash/bielik-11b-v3.0-instruct:Q4_K_M lädt die identische Byte-Struktur herunter, die auch auf Hugging Face liegt. Die Schichten-Hashes im internen Ollama-Manifest stimmen exakt mit den Upstream-Dateien überein.

Häufig gestellte Fragen

Quellen und Überprüfung

• ggml-org: Offizielle GGUF-Spezifikation auf GitHub
• llama.cpp: Dokumentation zu llama-quantize und Bits pro Gewicht
• llama.cpp Pull Request 1684: Technische Spezifikation der k-quants
• Hugging Face: speakleash/Bielik-11B-v3.0-Instruct-GGUF
• Hugging Face: speakleash/Bielik-4.5B-v3.0-Instruct-GGUF
• Hugging Face: speakleash/Bielik-1.5B-v3.0-Instruct-GGUF
• Ollama Library: Modell-Manifest SpeakLeash/bielik-11b-v3.0-instruct
• llama.cpp GitHub Releases
• Eigene Benchmark-Messungen vom 17. Oktober 2026: RTX 4090, llama.cpp CUDA Build 11194, 17 GGUF-Varianten

Überprüft am 17. Oktober 2026.

// weiterlesenKI für Anwälte: Tools, Datenschutz und EU AI ActAnleitungenLadelimit auf 80 Prozent: So schützen Sie Ihren AkkuAnleitungenSchrittweise Belohnungen für KI-Reasoning ohne externe AnnotationAnleitungen

Kinetyra