GGUF i kwantyzacja: Q4_K_M, Q6_K czy Q8_0? Test Bielika na RTX 4090

👁 123 przeczytań

GGUF to format pliku z modelem językowym dla llama.cpp, a dopisek w nazwie (Q4_K_M, Q6_K, Q8_0) mówi, jak mocno model ściśnięto. Krótko: Q4_K_M to rozsądne minimum, Q5_K_M i Q6_K są prawie nieodróżnialne od oryginału, a Q8_0 ma sens, gdy VRAM nie jest problemem. 17 października 2026 zmierzyłem to na polskim Bieliku (1.5B, 4.5B i 11B) na RTX 4090: perplexity na prozie Nałkowskiej, zgodność z pełną wersją, szybkość i VRAM. Więcej o uruchamianiu modeli u siebie znajdziesz w przewodniku lokalne AI.

Co wybrać: odpowiedź w punktach

• Q4_K_M - najmniejszy wariant, przy którym polski tekst nie cierpi wyraźnie. Bielik 11B w Q4_K_M ma 6,72 GB i trafia w ten sam najbardziej prawdopodobny token co Q8_0 w 94,1% przypadków.
• Q5_K_M i Q6_K - jeśli VRAM wystarcza, to najlepszy kompromis. Różnica perplexity względem Q8_0 mieści się w błędzie pomiaru.
• Q8_0 - praktycznie oryginał (96,7% zgodności z F16 w Bieliku 1.5B), ale prawie dwa razy większy od Q4_K_M i wolniejszy.
• Q3_K_M i niżej - tylko dla dużych modeli i w ostateczności. Bielik 1.5B w Q2_K przestaje sensownie odpowiadać (0 z 12 zadań).
• Większy model w Q4 jest lepszy niż mniejszy w Q8. Bielik 11B w Q3_K_M (5,40 GB) zrobił 11 z 12 zadań, Bielik 4.5B w Q8_0 (5,06 GB) zrobił 5.

Co to jest GGUF

GGUF to binarny format pliku opracowany przez zespół ggml-org (twórców llama.cpp) i używany od sierpnia 2023. Jeden plik zawiera wagi modelu i wszystkie metadane potrzebne do uruchomienia: architekturę, tokenizer, szablon czatu i maksymalny kontekst. Dzięki temu ten sam plik otworzysz w llama.cpp, w LM Studio i w Ollamie (która pod spodem korzysta z tego samego formatu).

Specyfikacja opisuje też konwencję nazw: Nazwa-Rozmiar-Dostrojenie-Wersja-Kodowanie.gguf. W pliku Bielik-11B-v3.0-Instruct.Q4_K_M.gguf ostatni człon to właśnie kwantyzacja.

Co to kwantyzacja i co znaczą Q4_K_M, Q6_K, Q8_0, F16, IQ

Kwantyzacja modelu to zapisanie wag mniejszą liczbą bitów. Oryginał trzyma każdą wagę w 16 bitach (F16 albo BF16). Q8_0 zapisuje ją w około 8,5 bita, Q4_K_M w niecałych 5. Plik robi się mniejszy, mieści się w mniejszej karcie i generuje szybciej, bo przy generowaniu wąskim gardłem jest przepustowość pamięci. Ceną jest drobny błąd w każdej wadze.

Bity na wagę pochodzą z dokumentacji llama-quantize (pomiar dla Llama 3.1 8B). Litera K oznacza k-quants: wagi dzielone są na superbloki po 256, a skale bloków też są kwantyzowane. Końcówka _S, _M, _L to mieszanka: w Q4_K_M część najwrażliwszych tensorów dostaje wyższą precyzję (Q6_K), w Q4_K_S wszystko idzie w Q4_K. IQ to nowsza rodzina z nieliniowym rozkładem poziomów, przydatna poniżej 4 bitów. imatrix (macierz ważności) to plik liczony na próbce tekstu, który mówi narzędziu, które wagi są ważniejsze, żeby tam zostawić mniejszy błąd.

Mój test: Bielik na RTX 4090

Sprawdziłem 17 października 2026 na RTX 4090 24 GB (i9-14900KF, 64 GB RAM, Windows 11), llama.cpp CUDA, cały model na GPU.

• Pliki: oficjalne F16 i Q8_0 Bielika 1.5B v3.0 oraz Q8_0 Bielika 4.5B i 11B ze speakleash na Hugging Face (sumy sha256 zgodne z repozytorium). Pozostałe warianty zrobiłem sam przez llama-quantize: dla 1.5B z F16, dla 4.5B i 11B z Q8_0, bo większe oficjalne pliki przekraczały mój limit 5 GB na pobranie. Dla 11B dołożyłem też oficjalny Q4_K_M, który miałem już w Ollamie.
• Perplexity i zgodność: llama-perplexity, kontekst 2048, na początku „Romansu Teresy Hennert” Zofii Nałkowskiej (ok. 7900 słów, Wolne Lektury, domena publiczna od 2025). Zgodność to odsetek tokenów, przy których najbardziej prawdopodobny token jest ten sam co w wersji bazowej (F16 dla 1.5B, Q8_0 dla 4.5B i 11B).
• Szybkość: llama-bench, generowanie 128 tokenów, 3 powtórzenia.
• VRAM: przyrost w nvidia-smi przy działającym llama-server, kontekst 4096 (niższy z dwóch pomiarów).
• Zadania: 12 krótkich polskich zadań z jedną poprawną odpowiedzią (odmiana, korekta, procenty, JSON, liczebnik słownie, frazeologia), temperatura 0.

Bielik 1.5B: cała drabinka od F16 do Q2_K

Model 1.5B jest za mały na poważne zadania niezależnie od kwantyzacji: już w F16 przypisał „Lalkę” Witkacemu. W Q3_K_M autorem został Stanisław Lem, a Q2_K na pytanie o Konstytucję 3 maja w kółko powtarzał „1997”.

Bielik 11B: od Q8_0 do Q3_K_M

Wiersz Q4_K_M w drugiej tabeli to plik oficjalny. Mój Q4_K_M zrobiony z Q8_0 ma identyczny rozmiar, inną sumę sha256 i praktycznie te same wyniki (109,1 tok/s, 10/12).

Co z tego wynika

• Do Q5_K_M różnice w perplexity są mniejsze niż błąd pomiaru (dla 11B około ±0,10). Pierwszy wyraźny spadek zgodności to Q4_K_M w małym modelu i Q3_K_M w dużym.
• Im większy model, tym lepiej znosi kwantyzację. Q4_K_M w 11B zachował 94,1% zgodności, w 1.5B 83,6%, w 4.5B 82,7% (tu liczone względem Q8_0).
• imatrix pomaga za darmo: Q4_K_M z macierzą ważności (policzoną na innym fragmencie „Lalki”) ma ten sam rozmiar, a zgodność wzrosła z 83,6% do 88,1%.
• 12 zadań nie rozróżnia wariantów 11B: wyniki 9-11 na 12 to szum przy pojedynczych odpowiedziach (Q8_0 przy liczebniku podał tylko „osiemdziesiątego czwartego”). Zgodność i perplexity mierzą to dokładniej.
• Perplexity na „Lalce” Prusa wyszła dla Bielika 11B 1,20, czyli model zna ten tekst prawie na pamięć. Dlatego do porównań użyłem Nałkowskiej. Liczb nie porównuj między 1.5B a 11B: modele mają różne tokenizery (ten sam tekst to 14 767 albo 23 760 tokenów).

Co wybrać na 8, 12, 16 i 24 GB VRAM

Liczby VRAM z testu to sam model w llama-server, bez pulpitu Windows i przeglądarki, które zwykle zajmują dodatkowo 1-2 GB. Szersze tło znajdziesz w tekstach co to jest VRAM i ile VRAM potrzeba na model lokalnie.

• 8 GB: Bielik 11B w Q3_K_M (6,3 GB przy kontekście 4096) albo Bielik 4.5B w Q8_0 (5,3 GB). Q4_K_M 11B zajmuje 7,5 GB, więc na 8 GB jest na styk.
• 12 GB: Bielik 11B w Q4_K_M albo Q5_K_M (7,5-8,6 GB) z zapasem na dłuższy kontekst.
• 16 GB: Bielik 11B w Q6_K (9,7 GB) albo Q4_K_M z pełnym kontekstem 32 768 tokenów (13,0 GB).
• 24 GB: Bielik 11B w Q8_0 nawet z kontekstem 32 768 (17,7 GB) albo większy model w Q4_K_M. Porównanie modeli znajdziesz w tekście najlepszy lokalny model AI po polsku.

Jak samemu porównać kwantyzacje krok po kroku

1. Pobierz llama.cpp z GitHuba ggml-org (dla kart NVIDIA paczka z CUDA) i rozpakuj do folderu, np. D:\llama-cuda.
2. Pobierz 2-3 kwantyzacje jednego modelu z oficjalnego repozytorium do jednego folderu, np. hf download speakleash/Bielik-11B-v3.0-Instruct-GGUF Bielik-11B-v3.0-Instruct.Q4_K_M.gguf --local-dir D:\modele.
3. Sprawdź sumę: Get-FileHash D:\modele\*.gguf i porównaj z SHA256 na stronie pliku w Hugging Face.
4. Przygotuj plik .txt po polsku (UTF-8, kilka tysięcy słów, najlepiej tekst, którego model nie zna na pamięć).
5. Uruchom skrypt poniżej. Dostaniesz tabelę z rozmiarem, szybkością i perplexity oraz plik CSV.

Gotowy skrypt: porownaj-kwantyzacje.ps1

Przetestowałem go 17 października na czystym folderze z dwoma plikami Bielika 1.5B. Na samym procesorze (-Warstwy 0) Q4_K_M dał perplexity 54,31, na GPU w głównym teście 54,27. Pobierz porownaj-kwantyzacje.ps1.

# porownaj-kwantyzacje.ps1 - porównanie kwantyzacji GGUF w llama.cpp (promptowy.com/gguf/)
# Dla każdego pliku .gguf w folderze: rozmiar, szybkość (llama-bench: prompt 512 i generowanie 128 tokenów, 3 powtórzenia)
# i opcjonalnie perplexity na Twoim pliku tekstowym (llama-perplexity, kontekst 2048). Wynik: tabela + plik CSV.
#
# Użycie (PowerShell):
#   powershell -ExecutionPolicy Bypass -File .\porownaj-kwantyzacje.ps1 -Modele D:\modele -Llama D:\llama-cuda -Tekst D:\tekst.txt
# -Modele  folder z plikami .gguf (różne kwantyzacje tego samego modelu)
# -Llama   folder z llama-bench.exe i llama-perplexity.exe (paczka llama.cpp z GitHuba ggml-org, wersja CUDA dla kart NVIDIA)
# -Tekst   (opcjonalnie) plik .txt w UTF-8, najlepiej 5-20 tysięcy słów po polsku; bez niego tylko szybkość
# -Warstwy (opcjonalnie) ile warstw na GPU, domyślnie 99 = wszystkie
param(
    [Parameter(Mandatory = $true)][string]$Modele,
    [Parameter(Mandatory = $true)][string]$Llama,
    [string]$Tekst = "",
    [int]$Warstwy = 99
)
$ErrorActionPreference = "Continue"   # llama.cpp pisze logi na stderr - "Stop" w PowerShell 5.1 przerwałby skrypt
$bench = Join-Path $Llama "llama-bench.exe"
$ppl = Join-Path $Llama "llama-perplexity.exe"
if (-not (Test-Path $bench)) { throw "Nie ma $bench - podaj folder z rozpakowanym llama.cpp w -Llama" }
$pliki = Get-ChildItem -Path $Modele -Filter *.gguf | Sort-Object Length -Descending
if ($pliki.Count -eq 0) { throw "W folderze $Modele nie ma plików .gguf" }
if ($Tekst -and -not (Test-Path $Tekst)) { throw "Nie ma pliku tekstowego $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. Szybkość: llama-bench zwraca JSON (jedna pozycja dla pp512, druga dla tg128)
    $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 nie zwrócił wyniku (za mało VRAM? spróbuj -Warstwy 20)" -ForegroundColor Yellow }

    # 2. Perplexity (im niżej, tym lepiej; porównuj tylko pliki tego samego modelu na tym samym tekście)
    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: brak wyniku (tekst za krótki? potrzeba min. ok. 4100 tokenów)" -ForegroundColor Yellow }
    }
    $wyniki += [pscustomobject]$w
    Write-Host ("   {0} GB | prompt {1} tok/s | generowanie {2} tok/s | PPL {3}" -f $w.GB, $w.Prompt_tok_s, $w.Generowanie_tok_s, $w.Perplexity)
}

$wyniki | Format-Table -AutoSize
$csv = Join-Path $Modele ("porownanie-kwantyzacji-{0}.csv" -f (Get-Date -Format "yyyyMMdd-HHmm"))
$wyniki | Export-Csv -Path $csv -NoTypeInformation -Encoding UTF8 -Delimiter ";"
Write-Host "Zapisano: $csv" -ForegroundColor Green

W Ollamie nie musisz niczego konwertować: ollama run SpeakLeash/bielik-11b-v3.0-instruct:Q4_K_M pobiera dokładnie ten sam plik co Hugging Face (sprawdziłem sha256 warstwy modelu w rejestrze Ollamy). Szczegóły uruchamiania Bielika opisałem w tekstach Bielik i Bielik AI lokalnie.

Najczęstsze pytania

Co to jest GGUF?

Format pliku z modelem językowym dla llama.cpp i programów na nim opartych (LM Studio, Ollama, KoboldCpp, Jan). Jeden plik zawiera wagi, tokenizer, szablon czatu i metadane, więc nie potrzebujesz dodatkowych plików konfiguracyjnych.

Co to jest kwantyzacja modelu?

Zapisanie wag mniejszą liczbą bitów, np. 4-5 zamiast 16. Model zajmuje 2-4 razy mniej miejsca i VRAM, generuje szybciej, a traci trochę dokładności. W moim teście Bielik 11B w Q4_K_M generował 108,0 tok/s, a w Q8_0 67,0 tok/s.

Q4_K_M czy Q8_0?

Jeśli model w Q8_0 mieści się w VRAM razem z kontekstem, którego potrzebujesz, wybierz Q6_K albo Q8_0. Jeśli nie, Q4_K_M dużego modelu da więcej niż Q8_0 małego. Różnica jakości między Q4_K_M a Q8_0 w Bieliku 11B to 4,76 wobec 4,74 perplexity.

Czy kwantyzacja psuje polski?

Do Q4_K_M w modelu 11B nie zauważyłem pogorszenia w zadaniach, a perplexity wzrosła tylko w granicach błędu (4,76 wobec 4,74). W modelu 1.5B od Q3_K_M widać błędy w faktach i odmianie, a Q2_K generuje pętle i nieistniejące słowa.

Gdzie pobrać GGUF Bielika?

Tylko z oficjalnej organizacji speakleash na Hugging Face albo z konta SpeakLeash w bibliotece Ollamy. W wyszukiwarce obu serwisów jest wiele kopii od osób prywatnych z podobnymi nazwami, nie zawsze aktualnych i nie zawsze z tym samym szablonem czatu. Po pobraniu porównaj sumę sha256 z repozytorium.