Kwantyzacja GGUF: jaki poziom wybrać?

Domyślnie bierz Q4_K_M; sięgaj po Q6_K albo Q8_0, gdy masz zapas VRAM i potrzebujesz ostatnich paru procent jakości. Kwantyzacja GGUF ściska wagi modelu z 16 bitów do mniej — Q4_K_M trzyma około 4,85 bita na wagę, więc model 7B schodzi z ~14 GB do ~4,1 GB, a perplexity jest typowo o niecały 1% gorsza od oryginału. Pytanie „którą kwantyzację gguf wybrać” ma nudno stabilną odpowiedź, którą większość internetowego teatru zaciemnia. Niżej: co kwantyzacja faktycznie robi wagom, ile jakości kosztuje każdy poziom, jak samemu policzyć rozmiar i jedna komenda, żeby zmierzyć szkody na własnym sprzęcie, zamiast wierzyć cudzemu benchmarkowi.

Co tak naprawdę robi kwantyzacja GGUF?

Model trenuje się w 16-bitowej arytmetyce zmiennoprzecinkowej (FP16 albo BF16): każda z jego miliardów wag to liczba 2-bajtowa. Kwantyzacja ściska każdą wagę do mniejszej liczby bitów. Naiwny sposób — zaokrąglić każdą wagę do 4-bitowej liczby całkowitej — zabija małe, ale ważne wartości, więc GGUF używa dwóch sztuczek:

1. Skalowanie blokowe. Wagi grupuje się w bloki (zwykle po 32) i każdy blok dostaje własny współczynnik skali. Wartości 4-bitowe są przesunięciami wewnątrz bloku, więc przetrwa szeroki zakres wielkości.
2. K-kwenty świadome ważności. „K” w Q4_K_M znaczy super-bloki skal, plus różne traktowanie warstw attention i feed-forward, bo kompresję znoszą nierówno.

Rodzina „I” (IQ4_XS i koledzy) idzie dalej z kodami książkowymi z teorii informacji, zapożyczonymi z kompresji obrazów. Ten sam pomysł, fantazyjniejsze kodowanie: mniej bitów na wagę przy podobnej jakości, kosztem trochę wolniejszej inferencji na niektórych backendach.

Jedno sprostowanie, które ucina większość zamieszania: kwantyzacja zmienia wyłącznie zapisane wagi. Architektura, tokenizer i obsługa kontekstu zostają nietknięte. Plik Q4 i plik Q8 tego samego modelu to ten sam model w innych płaszczach.

Q4 vs Q8: czy wyższa kwantyzacja jest lepsza?

Technicznie tak; odczuwalnie nie. Biorąc własne pomiary perplexity llama.cpp na modelach Llama jako punkt odniesienia: Q8_0 mieści się w ~0,02% od FP16 — do wszelkich praktycznych celów bezstratne. Q6_K ledwo odróżnialne. Q4_K_M kosztuje z grubsza 1–2% perplexity, Q4_0 trochę więcej, a Q2_K to moment, w którym spójne odpowiedzi małych modeli zaczynają się sypać.

Dwie reguły wynikające z tych liczb:

• Rozmiar modelu kupuje zapas na kwantyzację. Model 70B przeżywa Q2/Q3 dużo lepiej niż 7B, bo większe modele są bardziej redundantne. Kwantyzacja 7B do Q2 to amputacja; kwantyzacja 70B do Q3 to krawiectwo.
• Podłoga jakości przesuwa się z zadaniem. Czat znosi Q4. Dokładne generowanie kodu, matematyka i RAG po precyzyjnych dokumentach wykrywają szum kwantyzacji wcześniej. Jeśli model Q4 notorycznie pisze subtelnie zły kod, przetestuj ten sam model na Q6_K, zanim obwinisz model.

Poziom	Bitów/wagę	Rozmiar vs FP16	Utrata jakości	Kiedy użyć
Q2_K	~3.4	~21%	Poważna poniżej 13B	Gdy nic innego się nie mieści, tylko duże modele
Q3_K_M	~3.9	~25%	Wyczuwalna	Ciasny VRAM, modele ≥14B
Q4_K_S	~4.6	~29%	Mała	Gdy Q4_K_M się nie mieści, a jest blisko
Q4_K_M	~4.85	~30%	~1% perplexity	Domyślny. Najlepszy kompromis jakość/rozmiar
Q5_K_M	~5.7	~35%	~0.5%	VRAM dostępny, zadania wrażliwe na jakość
Q6_K	~6.6	~41%	Prawie zero	Kod/matematyka, jeszcze mieści się komfortowo
Q8_0	~8.5	~53%	Praktycznie żadna	Uruchomienia referencyjne, bazy pod fine-tune
IQ4_XS	~4.3	~27%	≈Q4_K_M	Gdy Q4_K_M trochę za duży, a backend wspiera i-kwenty

Ile VRAM potrzebuje każdy poziom?

Policz sam zamiast wykładać tabele na pamięć — to jedna linijka:

size_GB ≈ (bits_per_weight × params) / 8
# model 8B @ Q4_K_M: 4.85 × 8 / 8 ≈ 4.9 GB
# model 8B @ Q8_0:   8.50 × 8 / 8 ≈ 8.5 GB

Potem dodaj to, czego wzór nie uwzględnia: KV cache (rośnie z długością kontekstu — od kilkuset MB do wielu GB), aktywacje i bufory obliczeń. Praktyczny margines: model „4.9 GB” chce karty 6 GB przy kontekście 4k, plus flash-attention i kwantyzację KV-cache, żeby tam zostać przy 16k. Wagi to nagłówek, nie cały rachunek.

Którą kwantyzację GGUF wybrać?

Kolejność decyzji, bez wyjątków warte memorowania:

1. Najpierw policz budżet kontekstu + KV, potem wag. Kontekst, którego nie mieścisz, szkodzi bardziej niż jakość, której nie umiesz zmierzyć.
2. Domyślnie Q4_K_M. Jest społecznościowym domyślnym nie bez powodu — w przybliżeniu 1% perplexity za 70% rozmiaru. Każdy rejestr, włącznie z Ollamą, wysyła go jako bazę.
3. Skocz na Q6_K, gdy zadanie karze szum: kod, matematyka, ekstrakcja, cokolwiek wpuszczasz do pipeline’a bez nadzoru.
4. Q8_0 tylko do referencji — testy A/B, pomiar szkód kwantyzacji albo baza pod fine-tune. Na co dzień kupuje głównie ciepło na czujnikach VRAM.
5. Poniżej Q4 tylko pod przymusem i tylko na dużych modelach. Przetestuj znanym trudnym promptem, zanim zaufasz.

Jeśli wybierasz, który plik pobrać z Hugging Face, przedkładaj pojedynczy Q4_K_M.gguf nad dzielone shardy, chyba że uploader wysyła tylko te drugie — mniej ruchomych części. A jeśli wybierasz gdzie go odpalić, wybór silnika to osobna oś: patrz llama.cpp vs Ollama.

Jak samemu zmierzyć szkody kwantyzacji?

Benchmarki się różnią; twój prompt jest stały. Zbuduj raz llama.cpp, pobierz dwa poziomy tego samego modelu i zmierz zarówno perplexity (niżej = lepiej), jak i tokeny/sekundę:

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build && cmake --build build --config Release -j

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf Meta-Llama-3.1-8B-Instruct-Q8_0.gguf 
  --local-dir models

# perplexity na kawałku wiki-text (niżej = bliżej modelu oryginalnego)
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q8_0.gguf  -ngl 99

# a szybkość na tym samym sprzęcie
./build/bin/llama-bench -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99

Wynik Q4_K_M będzie o parę setnych punktu gorszy od Q8_0, a plik o ~40% mniejszy. Jeśli twoje zadanie downstream nie odróżni ich — a dla większości nie odróżnia — masz odpowiedź bez czytania cudzych leaderboardów.

Czy kwantyzacja podważa prywatność i deklaracje „działa lokalnie”?

Nie — to arytmetyka na wagach, w całości offline, a skwantyzowany plik to tylko mniejszy pojemnik na te same parametry. Lokalne odpalenie Q4_K_M wycieka dokładnie tyle (czyli: nic), co lokalne odpalenie modelu w pełnej precyzji: nic nie opuszcza maszyny. Prywatnościową zmienną jest miejsce, gdzie biegnie inferencja, nie szerokość bitowa. Zwykłe zastrzeżenia o pochodzeniu modelu dotyczą równo każdego poziomu kwantu: „uncensored” fine-tune na skradzionej bazie w Q8 nie jest bezpieczniejszy niż te same wagi w Q4. O samej stronie formatu pliku pisze jak uruchamiać modele GGUF lokalnie.

Który poziom ostatecznie wybrać?

Q4_K_M i przestań czytać o tym fora. Przesuń się na Q6_K do pracy głodnej precyzji, jeśli VRAM pozwala, trzymaj jeden Q8_0 pod testy A/B i traktuj wszystko poniżej Q4 jako rację głodową wyłącznie dla dużych modeli. Jedyny błąd wart uniknięcia jest symetryczny: zamartwianie się Q4-versus-Q5 przy ignorowaniu długości kontekstu, która wysypała więcej lokalnych setupów niż jakikolwiek kwant.