Gdy klient pokazuje wymagania dotyczące lokalnego wdrożenia modelu 70B i dysponuje jednym serwerem z dwoma GPU, pierwsza reakcja jest zazwyczaj taka sama: „To się nie zmieści." W FP16 to prawda — taki model potrzebuje 140–168 GB VRAM, co nie jest powszechnie dostępną konfiguracją. Jednak po kwantyzacji 4-bitowej ten sam model schodzi do 35–40 GB, czyli dwóch kart o średniej wydajności. A strata jakości? Przy właściwym formacie jest mniejsza, niż większość ludzi się spodziewa.
Kwantyzacja jest dziś jedną z najważniejszych praktycznych umiejętności przy wdrażaniu LLM na własnym sprzęcie. Ten artykuł wyjaśni, co dzieje się z wagami modelu podczas kwantyzacji, jaka jest różnica między formatami GGUF, AWQ i GPTQ, ile jakości realnie tracisz na poszczególnych poziomach i jak to odróżnić od destylacji, którą ludzie często mylą z kwantyzacją.
Co kwantyzacja robi z wagami
Nowoczesne LLM trenowane są w formacie BF16 lub FP16 — każdy parametr zajmuje 16 bitów. Model z 7 miliardami parametrów potrzebuje zatem około 14 GB tylko na same wagi (plus pamięć KV cache i aktywacje).
Kwantyzacja reprezentuje te same wagi przy niższej precyzji numerycznej. Zamiast 16-bitowego float używasz 8-bitowego lub 4-bitowego integera. Wzór jest prosty: VRAM (GB) ≈ (liczba parametrów w miliardach × bity) / 8. Przy kwantyzacji 4-bitowej modelu 7B otrzymujesz 5–7 GB — mieści się na zwykłej stacji roboczej.
Ceną tej oszczędności jest utrata informacji. Precyzja numeryczna spada, niektóre drobne różnice między wagami „spłaszczają się" do tej samej reprezentowalnej wartości. Konsekwencją jest niewielki spadek jakości wyników — pytanie, jak duży.
Ważne, by zrozumieć, czym kwantyzacja nie jest: nie jest destylacją. Kwantyzacja zachowuje architekturę i liczbę parametrów oryginalnego modelu — zmienia tylko numeryczny format wag. Destylacja natomiast przenosi wiedzę do mniejszego modelu o innej architekturze — to transfer wiedzy, nie kompresja. Więcej o destylacji w artykule Destylacja modelu: jak zrobić mały, szybki model z dużego.
GGUF — format dla CPU i wdrożeń wieloplatformowych
GGUF to format binarny opracowany dla llama.cpp, dziś natywnie obsługiwany również przez Ollama. Jego kluczowa cecha: model może działać wyłącznie na CPU lub w hybrydowej konfiguracji CPU+GPU, gdzie część warstw uruchomiona jest na GPU, a reszta na CPU z wykorzystaniem RAM.
Dla firmowego wdrożenia oznacza to praktyczną zaletę: deweloper może uruchomić model 13B na stacji roboczej bez dedykowanego GPU albo na serwerze z mniejszą ilością VRAM, niż wymagałby model w FP16.
Poziomy kwantyzacji w GGUF
Oznaczenia wywodzą się ze schematu Q<bity>_<wariant>. Najważniejsze poziomy:
- Q8_0 — kwantyzacja 8-bitowa, najmniejsza strata jakości (~1–2 % względem FP16). Zalecane, gdy masz wystarczająco VRAM i zależy Ci na maksymalnej precyzji.
- Q4_K_M — 4-bitowy wariant „medium" z adaptacyjną kwantyzacją dla wrażliwych warstw. Zachowuje ~92–95 % jakości FP16. Standardowy sweet spot dla większości przypadków użycia.
- Q4_K_S — 4-bitowy wariant „small", nieco mniejszy niż K_M przy podobnej jakości.
- Q3_K_M — 3-bitowy, znacznie mniejszy ślad pamięciowy, zauważalna degradacja przy złożonym rozumowaniu.
- Q2_K — 2-bitowy, wyraźna degradacja. Użyteczne tylko przy skrajnie ograniczonym sprzęcie i prostych zadaniach.
Litera K w oznaczeniu oznacza „k-quants" — bardziej zaawansowaną metodę, która stosuje wyższą precyzję do warstw najbardziej wrażliwych na błędy kwantyzacji (typowo warstwy osadzeń i wyjściowe), a agresywniejszą kompresję do mniej krytycznych części. Rezultat to lepszy stosunek jakości do rozmiaru w porównaniu ze zwykłą jednorodną kwantyzacją.
AWQ — kalibrowana kwantyzacja dla GPU stack
AWQ (Activation-aware Weight Quantization) to metoda, która podczas kwantyzacji bierze pod uwagę statystykę aktywacji — czyli jakie wartości wejściowe model widzi w praktyce. Na podstawie tej statystyki identyfikuje „ważne" wagi i zachowuje im wyższą precyzję, a pozostałe kwantyzuje agresywniej.
Rezultat: format AWQ 4-bitowy zachowuje ~93–96 % jakości FP16, nieznacznie lepiej niż GPTQ przy tym samym rozmiarze. Różnica jest zauważalna zwłaszcza przy dłuższych generacjach tekstu i kodu, gdzie koherencja degraduje szybciej przy niekalibrowanej kwantyzacji.
AWQ wymaga GPU do inferencji — nie jest przeznaczony dla środowisk tylko-CPU. Natywnie obsługują go vLLM i TGI. Dla produkcyjnych wdrożeń NVIDIA jest to dziś jeden z preferowanych formatów.
GPTQ — maksymalny throughput na GPU NVIDIA
GPTQ (Generative Pre-trained Transformer Quantization) to starsza i ugruntowana metoda. Wykorzystuje drugie pochodne (Hessian) do minimalizacji błędu kwantyzacji przy danej kalibracji wsadowej. W praktyce GPTQ 4-bitowy nieznacznie ustępuje AWQ pod względem zachowania jakości (~90–93 % vs FP16), ale oferuje maksymalny throughput na GPU NVIDIA z wykorzystaniem fusowanych kerneli.
W scenariuszach, gdzie priorytetem jest jak największa liczba tokenów na sekundę (np. obsługa wielu równoczesnych użytkowników), GPTQ w połączeniu z vLLM daje mocne wyniki. Podobnie jak AWQ, wymaga GPU — inferencia na CPU nie jest natywnie obsługiwana.
Porównanie formatów — kiedy co stosować
- GGUF — gdy potrzebujesz wdrożenia wieloplatformowego, inferencji na CPU lub hybrydowego trybu CPU+GPU, albo gdy wdrażasz przez
Ollamana stacjach deweloperskich - AWQ — wyłącznie GPU stack (NVIDIA), wdrożenie produkcyjne przez
vLLMlubTGI, priorytetem jest koherencja wyjścia - GPTQ — wyłącznie GPU stack (NVIDIA), wdrożenie produkcyjne przez
vLLM, priorytetem jest maksymalny throughput przy obsłudze wielu użytkowników
Te formaty nie są wymienne ani wzajemnie kompatybilne — modelu skwantyzowanego w GPTQ nie można bezpośrednio załadować w llama.cpp i na odwrót. Przed wyborem formatu należy wiedzieć, jakiego serving stacku i sprzętu planujesz używać.
Realna utrata jakości — co mówią liczby
Pytanie, które klienci zadają najczęściej: „Ile jakości stracimy?"
Odpowiedź zależy od poziomu kwantyzacji i rodzaju zadania. Pomiary na różnych modelach (Qwen, DeepSeek, Mistral, Llama) pokazują spójny wzorzec:
- Q8_0 / 8-bit: różnica w perplexity poniżej 1–2 % względem FP16. W zwykłej konwersacji praktycznie nieodróżnialne.
- Q4_K_M / AWQ 4-bit: różnica w perplexity typowo poniżej 5–8 % względem BF16. W większości zadań — ekstrakcja informacji, streszczanie, klasyfikacja — różnica gołym okiem nie jest zauważalna. Przy złożonym wieloetapowym rozumowaniu (matematyka, kod, długie łańcuchy kroków) może być widoczny nieznaczny spadek.
- Q3 i niżej: degradacja jest zauważalna. Model zaczyna generować mniej koherentne wyniki, zwłaszcza przy długich generacjach lub przy zadaniach wymagających precyzji.
- Q2: wyraźna degradacja. Odpowiednie tylko przy ekstremalnie ograniczonym sprzęcie i niekrytycznych zadaniach.
Ważna uwaga: utrata jakości nie rozkłada się równomiernie. Modele z większą liczbą parametrów tolerują agresywniejszą kwantyzację lepiej — model 70B w Q4_K_M zazwyczaj zachowuje więcej możliwości niż model 7B w tej samej konfiguracji. Przy małych modelach (7B i mniej) różnica między Q8 a Q4 jest bardziej widoczna.
Druga uwaga: benchmarki mierzą średnią. Dla specyficznego przypadku użycia w konkretnej domenie (np. analiza dokumentacji technicznej) warto przeprowadzić własne porównanie FP16 vs Q4 na próbce rzeczywistych danych wejściowych — kilkadziesiąt przykładów zwykle wystarczy do orientacyjnego wniosku.
Oszczędność VRAM w praktyce
Konkretne liczby dla najczęstszych rozmiarów modeli:
- Model 7–9B: FP16 ~16–19 GB → Q8_0 ~8–13 GB → Q4_K_M ~5–7 GB
- Model 13B: FP16 ~26 GB → Q8_0 ~14 GB → Q4_K_M ~8 GB
- Model 27–34B: FP16 ~54–68 GB → Q8_0 ~30–34 GB → Q4_K_M ~17–20 GB
- Model 70B: FP16 ~140–168 GB → Q8_0 ~70–75 GB → Q4_K_M ~35–40 GB
Do tych liczb należy doliczyć KV cache, który rośnie wraz z długością kontekstu i liczbą równoczesnych żądań. Model 70B przy długim kontekście może zużyć dodatkowe 20–40 GB na KV cache przy kilku równoległych konwersacjach. Planując infrastrukturę, nie licz tylko wag — KV cache to równie ważna zmienna. Więcej na ten temat w artykule Jaki GPU do inferencji LLM.
Kwantyzacja a serving stack — co o tym wiedzą vLLM i Ollama
Ollama to doskonałe narzędzie do wdrożeń deweloperskich — model GGUF pobierasz jednym poleceniem, działa lokalnie bez konfiguracji. Pod maską jest llama.cpp. Kluczowe ograniczenie: Ollama nie jest produkcyjnym frameworkiem servingowym. Przy wielu równoczesnych użytkownikach można zaobserwować znacznie niższy throughput w porównaniu z vLLM — niezależnie od kwantyzacji.
vLLM z modelami AWQ lub GPTQ przeznaczony jest do środowisk produkcyjnych z wieloma równoczesnych żądaniami. Wykorzystuje PagedAttention do efektywnego zarządzania KV cache i continuous batching — wynikowy throughput może być przy wielu równoczesnych użytkownikach znacznie wyższy niż w Ollama. Ceną jest bardziej złożona konfiguracja i wymóg posiadania GPU.
Dla firmowego wdrożenia typowy schemat jest następujący: deweloperzy i testerzy pracują z modelami GGUF przez Ollama, produkcyjny serwer inferencyjny działa na vLLM z AWQ lub GPTQ. Oba podejścia funkcjonują równolegle — to nie jest wybór albo/albo. Szczegółowe porównanie tych narzędzi servingowych w artykule vLLM vs SGLang vs Ollama.
Kwantyzacja a destylacja — ważne rozróżnienie
Te dwa pojęcia są w praktyce mylone, ale chodzi o zasadniczo różne techniki.
Kwantyzacja zachowuje oryginalną architekturę modelu — zmieniasz tylko numeryczny format wag. Proces jest szybki, nie wymaga treningu, a istniejące narzędzia do kwantyzacji poradzą sobie z modelem 70B w ciągu kilku godzin na zwykłym serwerze. Tracisz informację w precyzji numerycznej.
Destylacja tworzy nowy, mniejszy model poprzez trenowanie na wynikach większego modelu (teacher). To pełnoprawny proces treningowy — wymaga danych, czasu obliczeniowego i dostrajania hiperparametrów. Rezultatem jest model z mniejszą liczbą parametrów i inną architekturą, który „nauczył się" naśladować teacher. Tracisz pojemność — mniejszy model po prostu nie ma tylu parametrów, ile potrzebuje do niektórych złożonych zadań.
W praktyce oba podejścia są komplementarne: zdestylowany model możesz następnie skwantyzować. Na przykład mały model stworzony przez destylację z modelu frontierowego możesz dystrybuować jako GGUF Q4 do wdrożeń edge.
Jak podejść do wyboru kwantyzacji w projekcie
Kilka praktycznych zaleceń z wdrożeń, które widzieliśmy:
- 1.Zacznij od Q4_K_M — dla większości firmowych przypadków użycia (ekstrakcja, klasyfikacja, Q&A na dokumentach) Q4_K_M zapewnia wystarczającą jakość przy rozsądnym zużyciu VRAM
- 2.Zweryfikuj na własnych danych — jeśli aplikacja ma specyficzne wymagania (np. precyzyjna ekstrakcja wartości liczbowych z raportów technicznych), porównaj FP16 i Q4 na próbce 50–100 rzeczywistych danych wejściowych przed ostateczną decyzją
- 3.Nie lekceważ KV cache — planując sprzęt, uwzględnij KV cache ponad rozmiar wag, szczególnie jeśli planujesz długie konteksty
- 4.Uwzględnij serving stack — jeśli idziesz na vLLM, AWQ to dobry wybór; jeśli idziesz na Ollama lub wieloplatformowo, GGUF; jeśli priorytetem jest throughput na NVIDIA, GPTQ
- 5.Q2 — raczej nie — degradacja jest wyraźna, lepiej użyć mniejszego modelu w Q4 niż większego w Q2
Najczęstsze pytania
Czy mogę samodzielnie skwantyzować dowolny model?
Tak, narzędzia takie jak llama.cpp (dla GGUF), AutoAWQ i AutoGPTQ są open-source i dostępne publicznie. Dla typowych rozmiarów (7–34B) kwantyzacja jest wykonalna nawet na zwykłym serwerze w ciągu kilku godzin. Dla modeli 70B i większych potrzebujesz znacznie więcej RAM (kwantyzacja odbywa się w FP16 przed konwersją). W praktyce dla większości zespołów prostszym wyjściem jest sięgnięcie po wstępnie skwantyzowane modele z Hugging Face — jakość jest zweryfikowana i oszczędzasz czas.
Czy różnica między Q4_K_M a Q4_K_S jest zauważalna?
W codziennej praktyce — minimalna. Q4_K_S to nieco mniejszy plik przy bardzo podobnej jakości. Q4_K_M to bardziej zachowawczy wybór, który zachowuje nieco więcej precyzji w wrażliwych warstwach. Dla większości przypadków użycia rekomendujemy Q4_K_M jako punkt wyjścia.
Kwantyzacja a RODO — czy jest tu coś do rozważenia?
Bezpośrednio nie — kwantyzacja nie zmienia zachowania modelu przy przetwarzaniu danych, tylko jego zużycie VRAM i szybkość. Implikacje RODO dotyczą tego, *gdzie* model działa i *kto* ma dostęp do danych. Wdrożenie on-prem skwantyzowanego modelu może pomóc w kwestii RODO w zakresie lokalizacji danych (dane nie opuszczają infrastruktury), ale zgodność wymaga znacznie więcej — logów audytowych, kontroli dostępu, udokumentowanego procesu DPA. Więcej w artykule On-prem LLM dla regulowanych branż.
Czy mogę fine-tunować skwantyzowany model?
Bezpośredni fine-tuning skwantyzowanego modelu (np. GGUF Q4) nie jest standardową procedurą — większość frameworków do fine-tuningu pracuje z wagami FP16 lub BF16. Wyjątkiem jest QLoRA: umożliwia trening z 4-bitowymi kwantyzowanymi wagami bazowymi, przy czym adaptery LoRA trenujesz przy wyższej precyzji. Szczegóły w artykule LoRA vs QLoRA vs full fine-tuning.
Jaka jest różnica między NVFP4 a standardową kwantyzacją 4-bitową?
NVFP4 to natywny sprzętowo format specyficzny dla najnowszych GPU NVIDIA z architekturą Blackwell. W przeciwieństwie do programowych metod 4-bitowych (GPTQ, AWQ, GGUF Q4) NVFP4 jest bezpośrednio akcelerowany w rdzeniach tensorowych układu. Rezultatem są wyższe throughputy w porównaniu z generycznymi formatami 4-bitowymi na tym samym sprzęcie. Jeśli nie posiadasz GPU Blackwell, ten format Cię nie dotyczy — standardowe AWQ lub GPTQ to właściwy wybór.
*Wybór właściwego formatu kwantyzacji i serving stacku to decyzja, która znacząco wpłynie na koszty i wydajność wdrożenia produkcyjnego. W MP Industrial Solutions pomagamy firmom przejść od pierwszego eksperymentu z lokalnym LLM po infrastrukturę produkcyjną — włącznie z oceną sprzętu, doborem modelu i formatu kwantyzacji dla konkretnego przypadku użycia. Jeśli rozważasz wdrożenie on-prem LLM, chętnie umówimy się na wstępną konsultację.*