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 roku¹ — 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.¹

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.¹ 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.¹ 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.¹

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.¹ 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.¹

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.¹

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 2024² — 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.²

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.² 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.² 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.² 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ś.²

AWQ wspiera warianty W4A16 i W3A16 (wagi 4- lub 3-bitowe, aktywacje 16-bitowe), z opcjonalnym grupowaniem kanałów, np. rozmiar grupy 128.³ 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ę.³

Dwie szkoły, jedna tabela

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

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.⁴ (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.⁴

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).⁴ 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