Pod nazwą świeżego modelu ciągnie się zwykle ten sam korowód skrótów, co zawsze: obok pliku .gguf leży katalog z dopiskiem GPTQ, kawałek niżej ktoś wrzucił wariant AWQ, a w komentarzach ktoś pyta „którą wersję brać na 3060?" i dostaje trzy sprzeczne odpowiedzi. To jeden z tych tematów, o które nowy człowiek rozbija się na starcie — pół tuzina akronimów, każdy obiecuje „ten sam model, tylko mniejszy", a człowiek stoi jak przed półką z mlekiem, gdzie każde jest „bez laktozy, light i wzbogacone", i nie wiadomo, czym się właściwie różnią.

A różnią się. I nie chodzi o to, że jeden jest „lepszy", tylko że to dwie zupełnie różne szkoły myślenia o tym samym problemie: jak zapisać miliardy wag ciaśniej i nie zepsuć modelu. GPTQ i AWQ podchodzą do tego z dwóch przeciwnych stron — jeden liczy matematyczną korekcję błędu, drugi pyta, które wagi są w ogóle ważne. A na dokładkę cały świat GGUF-a i k-quantów, który znasz z llama.cpp, to trzecia bajka, jeszcze inna. Rozłóżmy to na części.

Najpierw jedno rozróżnienie: to wszystko jest PO treningu

Zanim wejdziemy w szczegóły — jedna rzecz, na której wykłada się połowa dyskusji. GPTQ, AWQ, GGUF: to wszystko kwantyzacja po treningu (post-training quantization, PTQ). Bierzesz gotowy, wytrenowany model w FP16 i przerabiasz jego wagi na coś ciaśniejszego. Żadna z tych metod nie trenuje modelu od nowa. To nie jest quantization-aware training (QAT), gdzie model uczy się od początku z myślą o niskiej precyzji. Tu nikt niczego nie uczy — bierzemy skończone dzieło i pakujemy je do mniejszego pudełka.

Dlaczego to ważne? Bo cała sztuka PTQ polega na tym, żeby nie mieć dostępu do treningu, a i tak stracić jak najmniej. Nie przepuszczasz miliardów przykładów przez wsteczną propagację. Masz gotowe wagi i najwyżej garść tekstu do „kalibracji" — żeby zajrzeć, jak model się zachowuje, i dobrać kwantyzację mądrzej niż zwykłym zaokrągleniem. I właśnie w tym „mądrzej" GPTQ i AWQ idą w dwie różne strony.

GPTQ: kwantyzuj wagę, popraw resztę, powtórz

Pierwsza szkoła. GPTQ — z pracy Frantara, Ashkboosa, Hoeflera i Alistarha z 2022 roku1 — wywodzi się z klasycznej idei o nazwie Optimal Brain Quantization (OBQ). Pomysł jest zaskakująco ludzki: nie kwantyzuj wszystkiego naraz na oślep. Rób to po jednej wadze, a po każdym takim ruchu popraw pozostałe, jeszcze nietknięte wagi tak, żeby zrekompensować błąd, który właśnie wprowadziłeś.

Wyobraź sobie, że rozstawiasz meble w za małym pokoju. Wciskasz szafę w róg — i widzisz, że przez to stół musi się ciut przesunąć, a krzesło podjechać bliżej ściany. GPTQ robi dokładnie to: kwantyzuje kolumnę wag, patrzy, ile błędu przez to narobił, i „dosuwa" pozostałe kolumny, żeby wyjście warstwy zostało jak najbliżej oryginału. Formalnie każdą warstwę rozwiązuje osobno jako problem argmin ||WX − ŴX||₂² — czyli: znajdź skwantyzowane wagi Ŵ, które na tych samych wejściach X dają wyjście najbliższe oryginalnym wagom W.1

Skąd metoda wie, jak dosuwać? Z informacji drugiego rzędu — odwrotności Hessianu warstwy, czyli macierzy mówiącej, jak wrażliwe jest wyjście na zmianę każdej wagi.1 To nie jest zwykłe „zaokrąglij do najbliższej wartości" (round-to-nearest). Zaokrąglenie byłoby jak wciskanie mebli bez patrzenia. GPTQ za każdym krokiem konsultuje się z Hessianem i wie, którą resztę i o ile przesunąć.

Problem: liczenie odwrotności Hessianu dla każdej wagi z osobna jest morderczo drogie. I tu wchodzi kluczowy myk GPTQ względem starego OBQ. Autorzy zauważyli, że jeśli kwantyzować kolumny w ustalonej, stałej kolejności — a nie „zawsze tę najmniej wrażliwą" — to odwrotność Hessianu można policzyć i współdzielić raz na całą warstwę, zamiast przeliczać w kółko.1 To dało ponad trzy rzędy wielkości przyspieszenia i nagle metoda przestała się dławić na dużych modelach. Do tego doszła tzw. Cholesky Reformulation — prekomputacja przez rozkład Choleskiego, żeby przy skali setek miliardów parametrów nie rozjechała się numeryka.1

Efekt? OPT-175B skwantyzowany do 3–4 bitów na wagę w jakieś 4,2 godziny na pojedynczym GPU — i gotowy do generatywnej inferencji na jednej karcie, co wcześniej było poza zasięgiem.1 Przy 4 bitach strata perplexity względem FP16 to według pracy raptem około 0,03, a raportowane przyspieszenia inferencji siedzą w okolicach 3,25x–4,5x, zależnie od sprzętu.1

Kalibracja? Skromna — 128 losowych kawałków po 2048 tokenów ze zbioru C4, czyli ogólnego tekstu z sieci. Bez danych zadaniowych. Autorzy podkreślają, że wynik pozostaje „zero-shot", bo metoda nigdy nie widzi danych spod konkretnego zadania — patrzy tylko na to, jak wagi reagują na w miarę losowy tekst.1

AWQ: nie wszystkie wagi są równe

Druga szkoła podchodzi z zupełnie innej strony. AWQ — Activation-aware Weight Quantization, praca Lina, Tanga, Tanga, Yanga i spółki, wyróżniona nagrodą Best Paper na MLSys 20242 — startuje od obserwacji, która brzmi wręcz banalnie: nie wszystkie wagi są tak samo ważne. Okazuje się, że wystarczy ochronić jakiś 1% najistotniejszych wag, żeby błąd kwantyzacji spadł drastycznie.2

Ale — i tu jest cały smaczek — jak poznać, które wagi są „istotne"? Intuicja podpowiada: te największe co do wartości. AWQ mówi: nie. Istotność wagi wyznacza się z rozkładu aktywacji, a nie z samej wartości wagi.2 Stąd „activation-aware" w nazwie: patrzysz, przez które kanały płynie najwięcej „sygnału" na wejściu, i to one decydują, które wagi trzeba traktować z czułością. Waga może być mała, ale jeśli mnoży aktywację, która regularnie strzela w górę — jest ważna.

I teraz najczęstsze nieporozumienie w internetach. Ludzie mówią: „AWQ trzyma ten 1% w FP16". Nieprawda — a przynajmniej nie w wersji podstawowej. Trzymanie garstki wag w wyższej precyzji to mixed precision, osobny nurt, który psuje jednolitość i utrudnia szybkie jądra obliczeniowe. AWQ robi coś sprytniejszego: matematycznie skaluje w górę kanały wag odpowiadające istotnym aktywacjom, jeszcze przed kwantyzacją, i kompensuje to odwrotnym skalowaniem po drugiej stronie.2 Efekt jest taki, jakbyś dał tym ważnym wagom więcej „rozdzielczości" w siatce kwantyzacji — ale precyzja zostaje jednolita, bez wysepek FP16.

Co z tego wynika dla ciebie w praktyce: AWQ nie robi wstecznej propagacji przez model i nie robi rekonstrukcji opartej na regresji.2 To ją odróżnia od GPTQ, która musi przejść przez warstwy z rachunkiem Hessianu. Skutkiem ubocznym braku dopasowywania „na siłę" jest większa odporność na przeuczenie się na konkretnych danych kalibracyjnych — metoda nie uczy się zbytnio pod ten akurat tekst, który jej pokazałeś.2

AWQ wspiera warianty W4A16 i W3A16 (wagi 4- lub 3-bitowe, aktywacje 16-bitowe), z opcjonalnym grupowaniem kanałów, np. rozmiar grupy 128.3 A towarzyszący jej framework inferencyjny TinyChat osiąga ponad 3x przyspieszenie względem FP16 z Hugging Face na kartach desktopowych i mobilnych; w nowszych benchmarkach na RTX 4090 z LLaMA-3-8B raportowano 2,7x, a na NVIDIA Jetson Orin 2,9x i okolice 38 tokenów na sekundę.3

Dwie szkoły, jedna tabela

Zestawmy to na chłodno, bo gdy leżą obok siebie, różnica robi się oczywista:

GPTQAWQ
RodowódOBQ — korekcja błędu drugim rzędemobserwacja o 1% istotnych wag
Co napędza decyzjęodwrotność Hessianu warstwyrozkład aktywacji
Mechanizmkwantyzacja kolumna po kolumnie + korekcja resztyskalowanie kanałów wag przed kwantyzacją
Wsteczna propagacja / regresjarachunek Hessianu przez warstwybrak, czysta matematyka skalowania
Kalibracja128 × 2048 tokenów z C4statystyki aktywacji z garści tekstu
Precyzjajednolita, sekwencyjna korekcjajednolita, bez wysepek FP16
Typowe warianty3–4 bity (badane też 2-bit i ternarne)W4A16 / W3A16, group size np. 128
Dlaczego to ważne dla lokalnego LLM

Dla ciebie, odpalającego model pod biurkiem, praktyczny wniosek jest prosty: obie metody celują w to samo — 4-bitowe wagi, aktywacje w 16 bitach, żeby model klasy 7B–13B wszedł na kartę, na której FP16 nie miało prawa się zmieścić. GPTQ ma dłuższy staż i pełno gotowych checkpointów; AWQ bywa odporniejsze na to, że dane kalibracyjne odbiegają od tego, do czego faktycznie użyjesz modelu. Jak masz obie wersje tego samego modelu — bierzesz tę, którą lepiej wspiera twój silnik inferencyjny, i sprawdzasz jakość na SWOICH promptach, nie na cudzym benchmarku.

A gdzie w tym wszystkim GGUF i k-quanty?

Tu trzeba postawić granicę na czerwono, bo to najczęstsze pomieszanie z poplątaniem. GGUF i k-quanty z llama.cpp (te wszystkie Q4_K_M, Q5_K_S i spółka, o których nazwach rozpisaliśmy się osobno tutaj) to trzeci, odrębny nurt. Owszem, technicznie też PTQ — ale filozofia zupełnie inna.

GGUF to przede wszystkim format pliku ekosystemu ggml-org/llama.cpp, a k-quanty to rodzina schematów kwantyzacji w środku. Zamiast kalibrowanej korekcji błędu opartej na Hessianie czy aktywacjach, k-quanty grupują wagi w superbloki po 256 wartości, z osobnymi (często też skwantyzowanymi) skalami i minimami dla podbloków oraz skalowaniem superbloku w fp16.4 (Sama „szesnastka" fp16 — i czemu w treningu ML częściej widuje się bf16 — to osobny temat.) Stąd bierze się niecałkowita „efektywna" liczba bitów na wagę — Q4_K_M to w praktyce jakieś 4,5 bita na wagę, nie równe 4.4

Warianty z dopiskami _S, _M, _L różnią się kompromisem rozmiar/jakość — _M selektywnie trzyma wrażliwsze warstwy w wyższej precyzji, a Q4_K_M społeczność od dawna uznaje za praktyczny „sweet spot" (jakieś 75% redukcji rozmiaru przy minimalnej odczuwalnej stracie).4 To inżynierski nurt zorientowany na inferencję na CPU i mieszaną CPU–GPU, nie na kartę wypchaną VRAM-em.

Kluczowe: nie utożsamiaj tych trzech. Wszystkie to PTQ, ale:

  • GPTQ = sekwencyjna korekcja błędu przez odwrotność Hessianu,
  • AWQ = skalowanie kanałów wag wg aktywacji,
  • GGUF/k-quanty = superbloki z mieszaną precyzją per warstwa i osobnymi skalami.

GGUF może korzystać z danych kalibracyjnych (tzw. importance matrix), ale mechanizm jest inny niż w tamtych dwóch. To trzy różne odpowiedzi na to samo pytanie, nie trzy nazwy tej samej rzeczy.

Zrób to sam: jak to rozpoznać w praniu

Nie musisz liczyć żadnego Hessianu ręcznie — ale warto umieć rozpoznać, na co patrzysz. Katalog z GPTQ albo AWQ na Hugging Face zwykle trzyma wagi w formacie safetensors plus plik quantize_config.json, gdzie stoi jak byk liczba bitów i rozmiar grupy:

# GPTQ/AWQ zwykle: katalog safetensors + config kwantyzacji
ls TheModel-AWQ/
# config.json  model.safetensors  quantize_config.json  ...

# GGUF to jeden plik z całą kwantyzacją zaszytą w nazwie
ls TheModel-GGUF/
# the-model-q4_k_m.gguf

Reguła kciuka na dziś: jeśli odpalasz na karcie NVIDII przez silnik pokroju vLLM albo TinyChat i chcesz maksimum przepustowości z 4-bitowych wag — patrzysz na GPTQ albo AWQ. Jeśli grasz na CPU, Apple Silicon albo mieszance CPU–GPU i chcesz jeden plik, który „po prostu działa" w llama.cpp czy Ollamie — bierzesz GGUF, najpewniej Q4_K_M. Ta sama walka o VRAM, którą liczyliśmy we wzorze na pamięć, tylko rozegrana trzema różnymi szkołami.

I jeszcze jedno, żeby domknąć układankę: kwantyzacja po treningu to nie to samo, co 4-bitowy fine-tuning spod znaku QLoRA — tam ciśniemy model po to, żeby go doszkolić na skromnym VRAM-ie, a rozgryzaliśmy to osobno tutaj. Tu nikt niczego nie douczy. Tu tylko pakujemy skończony model do mniejszego pudełka.

Bo o to w tym całym zoo skrótów chodzi. Masz jeden wytrenowany mózg zapisany w FP16 i trzy ekipy, które przyszły go spakować na wyjazd. GPTQ pakuje pedantycznie, walizka po walizce, za każdym razem dosuwając resztę, żeby nic się nie pogniotło. AWQ najpierw pyta, co jest naprawdę cenne, owija ten 1% w folię bąbelkową i resztę wciska bez ceregieli. A ekipa GGUF-a nawet nie próbuje być elegancka — tnie na superbloki, pakuje w jeden plik i wrzuca do bagażnika starego kombi, byle ruszyło z miejsca na tym, co masz pod ręką.

Trzy szkoły, jeden model, ten sam cel: żeby coś, co „się nie mieściło", w końcu odpaliło u ciebie na biurku. Reszta to spór o to, jak elegancko go do tej walizki włożyć.

Przypisy · źródła


  1. Frantar, Ashkboos, Hoefler, Alistarh, GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformersabstrakt, arXiv:2210.17323; szczegóły metody (layer-wise problem argmin ||WX − ŴX||₂², OBQ, stała kolejność kolumn i współdzielony Hessian, Cholesky Reformulation, kalibracja 128 × 2048 tokenów z C4, ~4,2 h dla OPT-175B, ~0,03 perplexity dla 4-bit, przyspieszenia 3,25x–4,5x) w pełnym tekście HTML na ar5iv↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  2. Lin, J. Tang, H. Tang, Yang, W.-M. Chen, W.-C. Wang, Xiao, Dang, Gan, Han, AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration (MLSys 2024, Best Paper) — abstrakt, arXiv:2306.00978: ochrona ~1% istotnych wag, wybór wg rozkładu aktywacji, skalowanie kanałów zamiast mieszanej precyzji, brak backpropagation i rekonstrukcji regresyjnej. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  3. Oficjalne repozytorium AWQ, mit-han-lab/llm-awq — implementacja W4A16 / W3A16, group size, framework TinyChat oraz benchmarki przyspieszenia (RTX 4090 z LLaMA-3-8B: 2,7x; Jetson Orin: 2,9x / ~38 tok/s). ↩︎ ↩︎

  4. ggml-org/llama.cpp, Tensor Encoding Schemes (Wiki) — opis GGUF i rodziny k-quantów: superbloki po 256 wag, skwantyzowane skale/minima per podblok, ~4,5 bpw dla Q4_K_M, warianty _S/_M/_L; dokumentacja narzędzia w tools/quantize/README.md↩︎ ↩︎ ↩︎