To jeden z klasycznych sporów o dwie „szesnastki" — ktoś wrzuca skwantyzowany model, ktoś inny zaraz pyta, czemu baza jest w bf16, a nie f16, i rozkręca się wątek na sto odpowiedzi, z których połowa myli precyzję z zakresem. Bo to naprawdę nieoczywiste. Dwa formaty, oba po 16 bitów, oba po 2 bajty na liczbę — a jednak jeden wygrał trening wielkich modeli, a drugi został przy inferencji i grafice. Cała różnica siedzi w tym, jak te 16 bitów pokroić. No to pokrójmy.

Liczba zmiennoprzecinkowa to trzy szufladki

Każda liczba w tych formatach — czy to f32, czy f16, czy bf16 — składa się z trzech kawałków. Wyobraź sobie zapis naukowy z podstawówki: −1,5 × 10⁴. Masz tam znak (minus), masz cyfry znaczące (1,5) i masz potęgę, która mówi, gdzie postawić przecinek (10⁴). Komputer robi dokładnie to samo, tylko na potęgach dwójki, i pakuje to w trzy pola bitów:

• bit znaku (sign bit) — jeden bit, plus albo minus. Tu bez niespodzianek.
• wykładnik (exponent) — potęga dwójki, czyli skala liczby. To on decyduje, jak wielką albo jak małą liczbę w ogóle da się zapisać. Nazywamy to zakresem dynamicznym.
• mantysa (significand, po staremu mantissa) — cyfry znaczące, czyli dokładność. To ona decyduje, ile pozycji po przecinku odróżnisz od siebie. Nazywamy to precyzją.

I teraz sedno, które trzeba wbić do głowy jak mantrę: zakres bierze się z wykładnika, precyzja z mantysy. To dwie niezależne osie. Możesz mieć liczbę o gigantycznym zakresie i marnej dokładności — albo odwrotnie. Nie idą w parze. Cała gra w tych formatach polega na tym, ile z szesnastu (albo trzydziestu dwóch) dostępnych bitów oddasz jednemu, a ile drugiemu.

Jak to rozdzielono w praktyce? Tak — i to jest tabelka, którą warto zapamiętać:

f32, czyli single precision z normy IEEE 754, to 1 bit znaku, 8 bitów wykładnika i 23 bity mantysy.¹ To złoty standard „normalnego" liczenia na komputerze — szeroki zakres i siedem cyfr znaczących. Kosztuje 4 bajty na liczbę i przez lata nikt się nad tym nie zastanawiał.

Dwie szesnastki, dwa różne cięcia

I teraz robi się ciekawie, bo f16 i bf16 to obie „połówki" — po 16 bitów, po 2 bajty. Tyle że tort pokrojony zupełnie inaczej.

f16, czyli half precision, też z IEEE 754, tnie tak: 1 bit znaku, 5 bitów wykładnika, 10 bitów mantysy.² Zauważasz? Oddano dużo miejsca mantysie, mało wykładnikowi. Efekt: przyzwoita precyzja jak na 16 bitów, ale wąziutki zakres — największa skończona liczba, jaką f16 w ogóle potrafi zapisać, to 65 504. Przekroczysz to i masz overflow, liczba ucieka w nieskończoność. Zejdziesz za nisko — underflow, liczba znika do zera. Dla grafiki, skąd f16 się wywodzi, to bez znaczenia; kolory i tak siedzą w rozsądnym przedziale.

bf16 — brain floating point, dziecko Google Brain, i uwaga: nie jest częścią IEEE 754 — kroi zupełnie inaczej: 1 bit znaku, 8 bitów wykładnika, 7 bitów mantysy.³ Ten sam wykładnik co f32. Osiem bitów, ten sam bias 127, ta sama arytmetyka skali. A to znaczy, że bf16 ma dokładnie taki sam zakres dynamiczny jak f32 — od jakichś 10⁻³⁸ do 3,4 × 10³⁸. Google w dokumentacji TPU pisze to wprost, bez owijania: zakresy dynamiczne bfloat16 i float32 są równoważne, bfloat16 po prostu zjada połowę pamięci.⁴

Cena? Mantysa skurczona do siedmiu bitów. Czyli bf16 jest mniej dokładny liczbowo niż f16 — odróżnia mniej cyfr znaczących. I tu wielu ludzi się wykłada, bo intuicja podpowiada: skoro bf16 ma mniej precyzji, to jest gorszą szesnastką. A to nieprawda. To po prostu inny kompromis, zrobiony pod inny cel.

Czemu bf16 wygrał trening, choć jest mniej dokładny

To jest ta część, która zaskakuje każdego, kto pierwszy raz na to trafia. Bierzemy format o gorszej precyzji i to on stał się domyślnym wyborem do trenowania największych modeli świata. Jak to możliwe?

Bo w treningu sieci neuronowej najgroźniejszym wrogiem nie jest to, że liczba jest odrobinę niedokładna. Najgroźniejsze jest to, że liczba wypadnie poza zakres. Gradienty potrafią być malutkie jak 10⁻⁷, a aktywacje potrafią chwilowo strzelić wysoko. f16 ze swoim sufitem na 65 504 i płytką podłogą po prostu tego nie łapie — wartości albo overflowują do nieskończoności, albo underflowują do zera, a wyzerowany gradient to gradient, który nic już nie uczy. Dlatego trening w f16 wymagał sztuczek w rodzaju loss scalingu — ręcznego podbijania skali strat, żeby zmieścić gradienty w tym wąskim oknie.

bf16 rozwiązuje to od strzału, bo ma zakres f32. Gradient rzędu 10⁻³⁰? Mieści się. Aktywacja, która na moment wystrzeliła? Też się mieści. Owszem, każda z tych liczb jest zapisana ciut mniej dokładnie — ale sieci neuronowe są na taki szum zdumiewająco odporne, a na wypadnięcie z zakresu już nie. Pokazało to twardo osobne badanie tego formatu — praca „A Study of BFLOAT16 for Deep Learning Training" z 2019 roku (zespół inżynierów Intela i Facebooka): trening w bf16 osiąga te same wyniki co f32, w tej samej liczbie iteracji, bez ruszania hiperparametrów, bez loss scalingu — czego f16 nigdy nie dawał za darmo.⁵

Jest jeszcze jeden bohater drugiego planu, o którym warto wiedzieć, żeby się nie pogubić: TF32 od NVIDIA. To nie jest format przechowywania danych — to wewnętrzny tryb obliczeniowy Tensor Core, z 8-bitowym wykładnikiem (zakres jak f32) i 10-bitową mantysą (precyzja jak f16).³ Dane w pamięci nadal leżą jako f32; karta tylko liczy na nich szybciej, po cichu przycinając mantysę w trakcie mnożenia. Nie pomyl go z bf16 jako typem tensora — to inna bajka, tryb liczenia, a nie etykieta na danych.

Po co ci to przy lokalnym LLM

„Fajnie, ale ja nic nie trenuję, tylko odpalam gotowca" — i słusznie, więc przełóżmy to na twoje podwórko.

Przy inferencji f16 albo bf16 to typowy compute dtype, czyli format, w którym faktycznie lecą obliczenia — 2 bajty na parametr, dwa razy taniej niż f32, przy jakości wyjścia praktycznie nie do odróżnienia. Ten sam podział bitów wraca też w KV-cache: bufor, w którym model trzyma przemielony kontekst, standardowo siedzi w f16 lub bf16, po 2 bajty na wartość — i przy długim oknie to właśnie on, a nie wagi, robi się największym żłobem na VRAM (rozgryzaliśmy to bliżej tutaj). Compute dtype pojawi ci się też, jak zajrzysz do QLoRA — tam wagi leżą w 4 bitach, ale liczenie i tak idzie w bf16.

A f32? Przy samej inferencji lokalnego LLM to zwykle przepłacanie pamięcią. Ładujesz dwa razy cięższy tensor, zżerasz dwa razy więcej VRAM-u, a jakości odpowiedzi i tak nie odróżnisz od f16. Pełne f32 ma sens tam, gdzie liczy się stabilność akumulacji — sumowanie tysięcy iloczynów cząstkowych, niektóre warstwy normalizacyjne, stany optymalizatora przy treningu. Nie przypadkiem TPU mnoży w bf16, ale sumy akumuluje w f32: to klasyka mixed precision — licz tanio, sumuj dokładnie.⁴ Ale to dzieje się pod maską frameworka, nie w twoim --outtype.

No i konkret, od którego zaczęliśmy — konwersja do GGUF. Gdy robisz bazę pod dalszą kwantyzację, --outtype f16 albo bf16 to punkt wyjścia: pełna szesnastka jako fundament, z którego dopiero schodzisz do Q4_K_M, Q5_K_M czy Q8_0 (o tych nazwach jest osobno tu). Prosta zasada kciuka:

# model wytrenowano w bf16 (dziś większość) -> zachowaj zakres, bierz bf16:
python convert_hf_to_gguf.py ./Meta-Llama-3-8B --outtype bf16 --outfile llama3-8b-bf16.gguf

# starszy model natywnie w f16 albo docelowy sprzęt bez akceleracji bf16 -> f16:
python convert_hf_to_gguf.py ./stary-model --outtype f16 --outfile model-f16.gguf

Skąd wiesz, w czym model żył oryginalnie? Zajrzyj do config.json na karcie modelu — pole torch_dtype. Jeśli stoi tam bfloat16 (a przy nowych modelach zwykle stoi), to konwersja do f16 po drodze przycięłaby zakres i mogłaby narobić drobnych przekłamań w skrajnych wartościach. Trzymaj bazę w tym, w czym model się urodził. Nazwy torch.float32, torch.float16 i torch.bfloat16 to zresztą dokładnie te trzy formaty z tabelki wyżej, tyle że w słowniku PyTorcha.⁶

Bo cała ta szarpanina o bity sprowadza się do jednej sceny: masz 16 kratek do wypełnienia i decydujesz, ile z nich pójdzie na „jak wielka może być liczba", a ile na „jak dokładnie ją znam". f16 upchnął dokładność i został z ciasnym balkonem zamiast horyzontu. bf16 odpuścił parę cyfr po przecinku i dostał w zamian cały zakres f32 w połowie miejsca — i właśnie dlatego, kiedy następnym razem zawahasz się nad --outtype, nie będziesz już zgadywał. Będziesz wiedział, że wybierasz nie „lepszą szesnastkę", tylko odpowiedni kształt tego samego pudełka.

I najczęściej ktoś rzuca: „bierz Q4_K_M i się nie zastanawiaj". Dobra rada — ale zostawia cię z tym samym uczuciem, co „wlej 5W-40 i jedź". Działa, tylko dalej nie wiesz, co te znaczki znaczą. A one nie są przypadkowe. Każda litera i każda cyfra w Q4_K_M coś konkretnie mówi: ile bitów, jaka rodzina, ile precyzji odzyskujesz z powrotem. Jak raz to rozłożysz, ta tabela przestaje być loterią, a robi się listą z parametrami. Rozbierzmy ją.

Skąd w ogóle biorą się te nazwy

Zanim rozbierzemy nazwy, jedno pytanie: po co w ogóle tniemy? Model w oryginale trzyma każdą wagę na 16 bitach (format F16/BF16). Kwantyzacja to zwykłe upakowanie tych samych, już wytrenowanych liczb ciaśniej — nie douczanie, nie trening od nowa, tylko kompresja. To ważne rozróżnienie, bo ludzie mylą to z fine-tuningiem: tu nic się nie uczy, tylko chudnie.¹ O tym, jak liczby idą w dół i czemu jakość spada tak zaskakująco mało, rozgryzaliśmy szerzej przy okazji wyboru wersji modelu.

GGUF (GPT-Generated Unified Format — binarny format plików modeli spod llama.cpp) każdemu z tych sposobów cięcia daje nazwę. I ta nazwa nie jest marketingowa — to zapis, jak dokładnie wagi są zakodowane w pliku. Format jest zaskakująco regularny: QN_K_X. N to przybliżona liczba bitów na wagę, _K to nazwa rodziny (tak zwane k-quanty), a przyrostek X (S/M/L) mówi, ile tensorów w modelu dostaje podbitą precyzję.¹ Jak to raz przeczytasz jak zdanie, a nie jak szyfr, reszta wchodzi sama.

Q4_K_M — rozłóżmy to na trzy kawałki

Weźmy najsłynniejszy przykład i przejedźmy po nim znak po znaku.

Q — to po prostu „quantized". Standardowa kwantyzacja na liczbach całkowitych. Nic ciekawego, ozdobnik.

4 — przybliżona liczba bitów na wagę. I tu pierwsza pułapka, w którą wpada każdy: to przybliżenie, nie dokładna wartość. Wydaje się, że Q4 znaczy „równo 4 bity na liczbę". Nieprawda. Realnie, na modelu Llama-3.1-8B zmierzono, że Q4_K_M waży 4,89 bita na wagę, a nie 4.² Skąd ta nadwyżka? Właśnie z ostatniej litery — za chwilę.

_K — rodzina „k-quant". To był przełom z połowy 2023 roku (PR #1684 od ikawrakowa).³ Zamiast kodować każdy blok wag osobno i głupio, k-quanty pracują na super-blokach: większa grupa wag współdzieli metadane, a skala i minimum każdego mniejszego bloku są kodowane osobno, z własną precyzją. W praktyce: Q4_K i Q5_K mają super-bloki z 8 bloków po 32 wagi, a Q2_K, Q3_K i Q6_K — z 16 bloków po 16 wag.³ Dzięki temu ta sztuczka trzyma jakość dużo lepiej niż stare, proste cięcie.

M — i tu jest cała finezja, którą prawie wszyscy przegapiają. S/M/L (Small/Medium/Large) nie znaczą „mały/średni/duży model". Znaczą: ile tensorów w środku dostaje podniesioną precyzję.¹ Bo model to nie jednorodna zupa liczb — jedne tensory (np. te od atencji attention.wv albo feed_forward.w2) są dla jakości ważniejsze niż inne. Wariant M mówi: „te newralgiczne kawałki potnij łagodniej, resztę ostrzej".³ To dlatego Q4_K_M waży te 4,89 bita zamiast 4 — bo część wag siedzi wyżej niż na czterech bitach. To nie jest jedna globalna liczba bitów, to mieszanka.

Czyli Q4_K_M czytasz tak: „około czterobitowa, rodzina k-quant, ze średnim miksem podbitych tensorów". Trzy słowa, nie szyfr.

Ile realnie ważą — bo teoria kłamie o ułamek

Skoro cyfra po Q to przybliżenie, to najlepiej patrzeć na liczby zmierzone na prawdziwym modelu. Oto oficjalna tabela llama.cpp dla Llama-3.1-8B (dla porównania: oryginał w F16 to 14,96 GiB, a plik źródłowy waży 32,1 GB).²

Widać z tego dwie rzeczy. Raz — każdy kolejny bit kosztuje mniej więcej pół–jeden gigabajt na modelu tej klasy, więc skok z Q4_K_M na Q6_K to jakieś półtora giga VRAM-u więcej za coraz mniej odczuwalny zysk jakości (a ile pamięci realnie zeżre dany plik z kontekstem, wyliczasz osobnym wzorem). Dwa — Q8_0 to niemal bezstratna referencja; różnicy między nim a F16 w ślepym teście raczej nie wychwycisz, a plik jest o połowę lżejszy. Dlatego Q8_0, choć technicznie to stary „legacy" format, wciąż żyje i ma się świetnie.¹

A ile to daje na dużym modelu? Oficjalna tabela pokazuje Q4_K_M jako jedyny przykład: Llama 3.1 8B chudnie z 32,1 GB do 4,9 GB, 70B z 280,9 GB do 43,1 GB, a monstrualne 405B z 1625 GB do 249 GB.² Cztery bity zamiast szesnastu i nagle model, który potrzebował serwerowni, mieści się na jednej porządnej karcie.

Dlaczego akurat Q4_K_M jest tym „domyślnym"

No dobra, ale skąd się wziął ten konsensus, że Q4_K_M to bezpieczny strzał? Tu muszę cię uczciwie zderzyć z rzeczywistością: llama.cpp nigdzie formalnie nie ogłasza żadnego „oficjalnego domyślnego" kwantu.² To mit, który sam sobie chodzi po forach. Ale nie wziął się znikąd.

Po pierwsze, Q4_K_M ląduje w dokumentacji jako przykładowa komenda — kiedy README pokazuje, jak w ogóle uruchomić llama-quantize, robi to właśnie na nim:²

./build/bin/llama-quantize model-bf16.gguf model-Q4_K_M.gguf Q4_K_M

Po drugie — i ważniejsze — cztery bity to punkt, w którym krzywa „rozmiar kontra jakość" ma najładniejsze kolano. Poniżej zaczynasz tracić jakość szybciej, niż zyskujesz na rozmiarze. Powyżej płacisz gigabajtami za coraz mniejszy zysk. Q4_K_M siedzi dokładnie w tym słodkim punkcie, dlatego społeczność go pokochała. Ale to konsensus praktyczny, nie dekret ze specyfikacji — i warto to trzymać w głowie, zanim ktoś ci powie, że „tak trzeba".

A te dziwne IQ z wieloma iksami?

Zjeżdżasz w tabeli niżej i trafiasz na drugą rodzinę: IQ2_XXS, IQ3_XS, IQ4_NL. Wyglądają jak k-quanty, które napiły się kawy. To i-quanty (i-quants) — nowsza rodzina, zaprojektowana pod jeden cel: wycisnąć sensowną jakość z naprawdę niskich bitów, tam gdzie zwykłe k-quanty się już sypią.¹

Sekret jest w dwóch rzeczach. I-quanty operują na większych super-blokach po 256 wag i — to kluczowe — wyliczają wagi z pomocą tak zwanej importance matrix, w skrócie imatrix.¹ Co to jest? Wyobraź sobie, że przed kompresją przepuszczasz model przez zestaw tekstów kalibracyjnych i patrzysz, które wagi naprawdę się aktywują, a które ledwo drgają. Imatrix to per-tensor tablica, która to zapamiętuje — dla każdej pozycji notuje, jak mocno ta waga „pracowała".⁴ Potem, przy cięciu, algorytm chroni ważne wagi kosztem tych mało istotnych. Zamiast tłuc wszystko po równo, oszczędza tam, gdzie boli najmniej.

Litery za IQ układają się od najostrzejszego cięcia w górę: XXS (extra-extra-small), XS, S, M. Oto co to daje w liczbach, znów na Llama-3.1-8B:²

Zauważ jedno: IQ4_XS waży 4,17 GiB, czyli mniej niż Q4_K_S (4,36 GiB) przy porównywalnej klasie. To właśnie ta magia imatrixa — więcej jakości na bit. Cena? I-quanty bywają wolniejsze w inferencji na słabszym sprzęcie, bo używają tablic przeglądowych, i mają sens głównie wtedy, gdy walczysz o każdy gigabajt — na przykład wciskasz model 70B na kartę, która teoretycznie go nie uniesie.

Legacy, czyli dziadkowie formatu

Zanim były k-quanty, były proste cięcia: Q4_0, Q4_1, Q5_0, Q5_1, Q8_0. Dzielą wagi na płaskie bloki po 32 i kodują je najprościej jak się da — warianty _0 wzorem waga = q × skala, a _1 dokładają jeszcze minimum bloku (+ block_minimum).¹ Bez super-bloków, bez finezji. Dokumentacja GGUF opisuje je wprost jako „metodę przestarzałą, dziś rzadko używaną" — z jednym wyjątkiem. Q8_0 przeżył wszystkich, bo na ośmiu bitach kompresja i tak niczego istotnego nie gubi, więc służy jako wygodna, niemal bezstratna referencja.¹ Reszta to eksponaty muzealne — jeśli widzisz świeży model wypuszczony tylko w Q4_0, to znak, że coś jest nie tak z tym uploadem.

Dla porządku: świat GGUF ma jeszcze kilka egzotów, na które możesz się natknąć. Q8_K to nie format do dystrybucji, tylko typ roboczy do liczenia iloczynów skalarnych wewnątrz kwantów 2–6 bit.¹ A z najnowszych — TQ1_0/TQ2_0 (kwantyzacja ternarna) i MXFP4 (4-bitowy microscaling float) to zupełnie młodsze rodziny niż klasyczne k- i i-quanty.¹ Ale to już inna bajka.

Zrób to sam — i nie strzel sobie w stopę

Jak sam chcesz coś skwantyzować, narzędzie to llama-quantize z repo ggml-org/llama.cpp. Podstawa jest banalna — podajesz źródło, cel i typ. Ale są trzy grabie, na które warto uważać.

Po pierwsze — tnij zawsze z oryginału (F16/BF16/F32), nie z już skwantyzowanego pliku. Requantyzacja (flaga --allow-requantize) potrafi „poważnie obniżyć jakość", ostrzega o tym sama dokumentacja.² To jak przegrywanie MP3 z MP3 — za każdym razem gorzej.

Po drugie — flaga --pure wyłącza całą tę inteligentną mieszankę k-quantów i tnie wszystkie tensory do jednego typu.² Brzmi kusząco („czysto!"), ale odbierasz sobie właśnie to, za co _M jest dobre. Zostaw domyślny miks.

Po trzecie — jak kwantyzujesz model multimodalny, nie tnij komponentów mmproj (enkoder obrazu/dźwięku i projektory) tak agresywnie jak reszty. Dokumentacja zaleca trzymać je w bf16 albo q8 (czym bf16 różni się od zwykłej „szesnastki" f16, jest tutaj), bo mają bezpośredni wpływ na jakość tego, co trafia do modelu, a oszczędność pamięci przy niższym kwancie i tak jest znikoma.²

# z importance matrix, dla i-quantów i lepszych niskobitowych k-quantów:
./build/bin/llama-quantize --imatrix model.imatrix \
  model-f16.gguf model-IQ3_M.gguf IQ3_M

Cała lista pokręteł — --tensor-type (regex per tensor), --output-tensor-type, --token-embedding-type, --leave-output-tensor, --prune-layers — czeka w dokumentacji narzędzia.² Ale szczerze? Na co dzień pobierasz gotowca z Hugging Face i cała ta zabawa sprowadza się do jednego pytania: który wiersz w tabeli kliknąć.

I tu wracamy do tej półki z olejami. Bo kiedy już wiesz, że Q4_K_M to „czterobitowa, k-quant, średni miks", Q6_K to „szóstka bez wariantów, bo i po co", a IQ2_XXS to „dwa bity ratowane imatrixem na modelu, który normalnie by się nie zmieścił" — ta tabela na Hugging Face przestaje być ścianą szyfrów. Robi się listą z jasnymi parametrami, gdzie każdy znaczek mówi, ile zapłacisz pamięcią i ile odzyskasz jakości.

Bierz Q4_K_M, jak masz miejsce i nie chcesz myśleć. Schodź do IQ, jak walczysz o ostatni gigabajt. Idź w Q6_K albo Q8_0, jak karta ci pozwala i chcesz mieć pewność. Ale już nie zgadujesz — czytasz. A to jest dokładnie ta różnica między człowiekiem, który wlewa „ten niebieski olej, bo ładny", a takim, co spojrzał na spód i wie, po co sięga.

Przypisy · źródła

Okazuje się, że to nie żart. W lutym 2024 grupa z Microsoft Research położyła na arXiv pracę o wdzięcznym tytule „The Era of 1-bit LLMs" i pokazała coś, co na pierwszy rzut oka wygląda na herezję: model, w którym każda waga przyjmuje jedną z trzech wartości — minus jeden, zero albo plus jeden — a mimo to od pewnego rozmiaru dorównuje pełnoprecyzyjnej LLaMie.¹ Nazwali go BitNet b1.58. I zanim złapiesz się na tym „1.58 bita" jak na literówce — spokojnie, to nie literówka. To rozłóżmy na części.

Skąd te 1,58 bita — czyli dlaczego nie okrągła jedynka

Najpierw sama nazwa, bo ona zdradza cały pomysł. Skoro waga może być tylko jedną z trzech rzeczy — -1, 0 albo +1 — to ile informacji trzeba, żeby taki stan zapisać? Logarytm przy podstawie dwa z trzech. A log2(3) to jakieś 1,58.¹ Stąd b1.58: nie dlatego, że ktoś w pamięci trzyma ułamki bitów, tylko dlatego, że tyle wynosi teoretyczny koszt informacyjny wyboru jednego z trzech wariantów.

I tu pierwsza pułapka, w którą łatwo wdepnąć: 1,58 bita to nie jest dosłowna liczba bitów, jaką waga zajmuje na dysku. To granica informacyjna, nie format zapisu. W praktycznych implementacjach — kiedy ktoś pakuje taki model do GGUF-a — wartość ternarna i tak ląduje zwykle na dwóch bitach plus trochę struktury dookoła. Więc jak zobaczysz „1.58-bit" na karcie modelu, czytaj to jako „trzy stany na wagę", a nie jako obietnicę, że plik jest fizycznie pięciokrotnie mniejszy niż czterobitowy. To dwa różne piętra: ile musisz zapamiętać, a jak akurat to zapakowałeś.

Dlaczego akurat ternarne, a nie czyste zero-jeden? Bo to zero pośrodku robi robotę. Waga równa zeru to po ludzku „to połączenie mnie nie obchodzi" — model dostaje wbudowaną możliwość wycięcia neuronu z równania. Oryginalny BitNet, wcześniejsza praca tej samej ekipy z 2023 roku, jechał na czystych wagach binarnych, tylko -1 i +1.² Dorzucenie zera to właśnie ten skok od BitNetu do BitNetu b1.58 — z pozoru drobny, a robi całą różnicę w jakości.

„Trenowany od zera" — i czemu to nie jest zwykła kwantyzacja

Teraz sedno, bo tu większość ludzi przy pierwszym czytaniu odruchowo myśli o złym torze. Kiedy słyszysz „model na trzech wartościach", w głowie zapala się „aha, czyli kolejna kwantyzacja" — bierzemy gotową, wytrenowaną w FP16 sieć i po fakcie zaokrąglamy jej wagi. Tak działa GGUF-owe Q4_K_M, tak działają GPTQ czy AWQ — rozgryzaliśmy te potreningowe sztuczki tutaj. Model istnieje najpierw w pełnej precyzji, a dopiero potem go ściskasz i modlisz się, że nie zgłupieje.

BitNet b1.58 działa dokładnie odwrotnie. Nikt tu niczego nie kwantyzuje po fakcie. Model jest trenowany od zera z wagami zamkniętymi w tych trzech wartościach — sieć od pierwszego kroku uczy się żyć w ternarnym świecie i sama układa sobie wagi tak, żeby jej to nie przeszkadzało.¹ To fundamentalna różnica: taki model nigdy nie istniał w FP16. Nie ma oryginału, z którego zszedłeś w dół i coś po drodze zgubiłeś. Ternarność nie jest stratą nałożoną na koniec — jest warunkiem brzegowym od startu.

Skąd model wie, na którą z trzech wartości zaokrąglić daną wagę podczas treningu? Robi to funkcja o ładnej nazwie absmean. Cała macierz wag jest najpierw skalowana przez swoją średnią wartość bezwzględną, a potem każda liczba idzie do najbliższej całkowitej ze zbioru {-1, 0, +1}.³ Proste jak konstrukcja cepa i o to chodzi — im mniej fikuśne, tym lepiej się liczy.

Mnożenie? Jakie mnożenie

Tu wchodzi część, dla której cały ten cyrk się opłaca. Serce każdego LLM-a to mnożenie macierzy — miliardy mnożeń liczby przez liczbę, i to właśnie one zżerają prąd i czas. A teraz policz na palcach, co się dzieje, kiedy jeden z czynników może być tylko -1, 0 albo +1. Mnożenie przez +1? To po prostu dodaj tę drugą liczbę. Przez -1? Odejmij. Przez 0? Pomiń, nic nie rób.

I nagle znika mnożenie. Zostają same dodawania i odejmowania — a te są dla krzemu dużo tańsze. Praca podaje twardą liczbę: dla samej operacji mnożenia macierzy to około 71 razy mniej energii na chipie 7nm w porównaniu z odpowiednikiem w FP16.³ Nie o kilka procent — o rząd wielkości i to z hakiem. To nie jest „lepsza kompresja", to zmiana tego, jaką operację w ogóle wykonuje procesor.

Haczyk: to działa dopiero od pewnego rozmiaru

Zanim pobiegniesz ogłaszać koniec FP16, jedna trzeźwa uwaga — i to taka, którą sami autorzy kładą na stół, bez chowania pod dywan. Ta cudowna „jakość jak w pełnej precyzji" nie pojawia się na małych modelach. Przy 700M czy 1,3B parametrów między BitNetem b1.58 a pełną LLaMą wciąż widać zauważalną lukę — ternarny model gada wyraźnie gorzej.³

Magia zaczyna się gdzieś od 3 miliardów parametrów w górę. Dopiero od tego progu BitNet b1.58 dogania pełnoprecyzyjną LLaMę zarówno pod względem perplexity (miary tego, jak model „dziwi się" tekstowi), jak i na zadaniach końcowych.³ Model 3,9B potrafi już przebić 3B LLaMę — i to przy mniejszym zużyciu pamięci oraz niższej latencji.³ Reszta liczb z pracy jest w tym samym duchu: redukcja pamięci 2,6–3,55×, przyspieszenie generacji 1,23–4,1× (rośnie z rozmiarem), a dla modelu 70B przepustowość wyższa 8,9× przy jedenastokrotnie większym batchu.³

Stąd bierze się najciekawszy wniosek pracy — nowe „prawo skalowania". Autorzy pokazują, że 13-miliardowy BitNet b1.58 potrafi być bardziej efektywny — pamięciowo, energetycznie i czasowo — niż zwykły model 3B w FP16.³ Innymi słowy: przestań patrzeć na samą liczbę parametrów. Przy ternarnych wagach większy model może być lżejszy w użyciu od mniejszego pełnoprecyzyjnego. To wywraca do góry nogami intuicję, którą wszyscy nosimy — że więcej parametrów zawsze znaczy cięższy plik.

Zrób to sam — Microsoft wypuścił konkretny model

To nie zostało teorią na papierze. Microsoft wydał gotowy, produkcyjny model: microsoft/bitnet-b1.58-2B-4T — około 2 miliardów parametrów, wytrenowany na 4 bilionach tokenów, na licencji MIT.⁴ Pod maską to transformer z warstwami BitLinear (to w nich siedzą te ternarne wagi), z RoPE, z aktywacją squared ReLU w FFN, normalizacją subln i bez biasów.⁴ Schemat, który już znasz z tego wpisu: W1.58A8 — wagi 1,58-bitowe, aktywacje ośmiobitowe.

I teraz najważniejsza pułapka praktyczna, bo tu połowa ludzi się nabiera. Jeśli odpalisz ten model przez zwykłą bibliotekę transformers z Hugging Face — nie zobaczysz żadnych oszczędności. Karta modelu mówi to wprost: efektywność pamięci i energii ujawnia się wyłącznie z dedykowaną implementacją.⁴ transformers policzy ci ten model jak każdy inny, gęsto i drogo — bo nie umie skorzystać z tego, że mnożenia są zbędne. To trochę jak kupić samochód na prąd i tankować go benzyną z kanistra.

Tą dedykowaną implementacją jest bitnet.cpp — framework inferencyjny z repozytorium microsoft/BitNet na GitHubie.⁵ I tu druga pułapka, tym razem dla porządkowych: to nie jest część ggml-org, mimo że stoi na llama.cpp i pachnie tym samym ekosystemem. To osobny projekt utrzymywany przez Microsoft, opisany we własnej pracy na arXiv.⁶ Dostarcza dedykowane kernele — I2_S na x86 i ARM, TL1 na ARM, TL2 na x86 — i to one robią tę robotę z zamianą mnożeń na dodawania.⁵

git clone --recursive https://github.com/microsoft/BitNet.git
cd BitNet
# dokładne kroki (setup_env.py, wybór kernela, pobranie GGUF-a)
# są w README repozytorium — trzymaj się ich, bo się zmieniają

Liczby z bitnet.cpp są równie soczyste jak z papieru: na ARM-owym CPU przyspieszenia 1,37–5,07× i redukcja energii 55–70%, na x86 przyspieszenia 2,37–6,17× i redukcja energii 72–82%.⁵ Wisienka na torcie: framework pozwala uruchomić model klasy 100B na pojedynczym CPU z prędkością rzędu 5–7 tokenów na sekundę.⁵ Sto miliardów parametrów. Na procesorze. Bez karty. Przeczytaj to zdanie jeszcze raz i przypomnij sobie, ile kosztuje GPU zdolne udźwignąć taki model po staremu.

Cała droga lokalnego LLM-owca to jedno długie schodzenie po drabinie precyzji. Szesnaście bitów, osiem, cztery — i za każdym razem ktoś na forum wróżył, że niżej już się nie da, że na dole tej drabiny model rozpłynie się w bełkocie. BitNet b1.58 nie tyle zszedł o kolejny szczebel, co zauważył, że drabina od początku stała nie tam. Zamiast ściskać gotowe liczby coraz mocniej — nauczył sieć od urodzenia myśleć trzema stanami i wyrzucił mnożenie za burtę.

Czy to już koniec ery zmiennoprzecinkowej? Nie dziś — dopóki krzem pod biurkiem woli mnożyć niż dodawać, pełnia tej obietnicy leży zapakowana i czeka na sprzęt, który ją rozpakuje. Ale kierunek jest wytyczony, model do ściągnięcia leży na Hugging Face, a bitnet.cpp już liczy. Czasem nie zmieniasz odpowiedzi na stare pytanie — zmieniasz pytanie. Nie „ile bitów damy radę utrzymać", tylko „po co nam w ogóle mnożenie".

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

To jest ten moment, w którym większość ludzi bierze na chybił trafił ten Q4_K_M, bo tak radzą na Reddicie, odpala i idzie dalej. I słusznie — działa. Ale pod tym jednym plikiem stoi cała cicha fabryka: ludzie, narzędzia, konwersje i format, który ktoś kiedyś usiadł i zaprojektował, żebyś ty mógł zrobić dwuklik. Warto wiedzieć, co tam mruczy pod maską — bo dzięki temu przestajesz zgadywać, a zaczynasz wybierać świadomie.

Co to w ogóle jest, ten GGUF

Zacznijmy od rozczarowania, bo lepiej od razu: GGUF to nie jest model. To nie nowa architektura, nie nowy sposób trenowania, nie magiczny AI od ggerganova. To pojemnik. Format pliku — dosłownie „GGML Universal File” — do trzymania modelu na dysku tak, żeby silnik inferencyjny mógł go szybko wczytać i zacząć gadać.¹ Model (Llama, Qwen, Mistral — cokolwiek) rodzi się gdzie indziej, w treningu na klastrze, którego rachunku za prąd żaden z nas nie chciałby zobaczyć. GGUF to dopiero opakowanie, w które ten wytrenowany model się przepakowuje na koniec, pod kątem tego, że odpalisz go u siebie na jednej karcie.

Format wymyślił Georgi Gerganov, ten sam, który stoi za llama.cpp i biblioteką ggml.² GGUF jest następcą kilku starszych formatów o równie uroczych nazwach — GGML, GGMF, GGJT — które po drodze się wykruszyły. I tu pierwsza pułapka, w którą łatwo wdepnąć: GGML i GGUF to nie synonimy. GGML to ten stary, w dużej mierze wyparty format pliku (i przy okazji wciąż nazwa biblioteki tensorowej pod spodem), a GGUF to jego młodszy, mądrzejszy brat z porządnymi metadanymi.¹

Co siedzi w tym jednym pliku

To jest właśnie sedno, dla którego GGUF wygrał. Otwórz sobie w głowie taki plik jak pudełko z przegródkami:

• Nagłówek — na samym początku cztery bajty GGUF (magic number, bajt po bajcie 0x47 0x47 0x55 0x46), zaraz za nimi numer wersji formatu, liczba tensorów i sterta metadanych.¹
• Metadane klucz-wartość — i tu robi się ciekawie. Zamiast beztypowej listy liczb jak w starych formatach, GGUF trzyma nazwane pola w hierarchii z kropkami: general.architecture, llama.context_length, general.quantization_version. Klucz general.architecture (czym ten model właściwie jest) musi być zawsze, a jak model jest skwantowany, to musi być też general.quantization_version.¹
• Tokenizer — w środku, w tym samym pliku. To jest ten myk, którego naprawdę brakowało wcześniej. GGUF potrafi wnieść cały tokenizer: natywne tablice tokenów, scores i merges, albo pełny tokenizer.json prosto z Hugging Face, albo szablony czatu w Jinja.¹ Dlatego jeden .gguf wystarcza — nie musisz dociągać pięciu plików obok.
• Same wagi — na końcu surowe dane tensorów, wyrównane do granicy (domyślnie co 32 bajty, klucz general.alignment), żeby silnik mógł je wczytać przez mmap bez mielenia całego pliku.¹

Skąd biorą się wszystkie te warianty

No dobra, a czemu tego samego modelu jest dwadzieścia sztuk? Bo GGUF wspiera całą tęczę typów tensorów: pełną precyzję (F32, F16, BF16), serię K (Q2_K do Q6_K), stare legacy (Q4_0, Q8_0), nowszą serię IQ opartą na macierzy istotności (IQ4_XS, IQ2_XXS) i egzotykę w stylu ternarnego TQ1_0.¹ Każdy z tych Q-ów to inny schemat ściśnięcia wag. Q4_K upycha wagę w jakichś 4,5 bita, Q6_K w 6,56, Q2_K w 2,63 — i to są dokładnie te przegródki, w których leży cały kompromis rozmiar/jakość/szybkość.²

I tu druga pułapka: te warianty to nie są różne modele. Q4_K_M, Q5_K_S, Q8_0 tego samego modelu to te same wagi bazowe, tylko skompresowane innym sitem. Grubszy plik = bliżej oryginału i wolniej, chudszy = mniej VRAM-u i szybciej, ale z lekkim ubytkiem jakości. Co ważne, to jest kwantyzacja post-training — bierzesz gotowy, wytrenowany model i ściskasz go po fakcie. Nie mylić z trenowaniem od zera w niskiej precyzji. W nazewnictwo tych literek zagłębialiśmy się osobno tutaj, bo to temat na własny wpis.

Kto to wszystko właściwie robi

Teraz najlepsze. Ten Q4_K_M, który ściągasz — bardzo często nie zrobił go autor modelu. Autor wrzuca zwykle wagi w safetensors i może jedną-dwie wersje GGUF, a resztę tego bufetu produkują ludzie z boku: community-quantizerzy. Konta jak bartowski czy mradermacher (dawniej głośny TheBloke) siedzą i masowo mielą cudze modele na wszystkie możliwe warianty, dzień po dniu, jak taka lokalna piekarnia GGUF-ów.

Jak to robią bez klastra? Dwiema drogami. Pierwsza to skrypt convert_hf_to_gguf.py prosto z repo llama.cpp — łyka wagi z Hugging Face i wypluwa GGUF, obsługuje kupę architektur (w tym multimodalne i MoE), ma opcje --outtype (bierzesz f16, bf16, q8_0… — czym te „szesnastki" różnią się od siebie, jest tu), --vocab-only, --split-max-size do krojenia wielkich plików, a nawet --remote, żeby konwertować prosto z Huba.³ Druga droga jest jeszcze leniwsza: ggml-org/gguf-my-repo, gotowy Space na Hugging Face, gdzie wklejasz repo, klikasz i dostajesz komplet kwantyzacji bez kompilowania czegokolwiek u siebie.⁴

# klasyczna droga: własny build llama.cpp
python convert_hf_to_gguf.py ./Qwen2.5-7B-Instruct \
  --outtype f16 --outfile qwen2.5-7b-f16.gguf
# a potem osobno kwantyzacja narzędziem llama-quantize do Q4_K_M itd.

Sam Hugging Face traktuje ten format jak pełnoprawnego obywatela: masz filtr library=gguf, który pokazuje wszystko, co gęgnięte (hf.co/models?library=gguf), a na stronie konkretnego pliku podejrzysz metadane i listę tensorów wprost z przeglądarki, bez ściągania.² Praktyczny wniosek: skoro warianty sypie kto chce, sprawdzaj, czyje repo bierzesz. Zerknij na autora, na to, czy imatrix był użyty, czy karta modelu ma ręce i nogi. Na co patrzeć przy świeżym modelu rozkładaliśmy w osobnej notce.

GGUF kontra safetensors: to nie jest ranking

Skoro autor wrzuca safetensors, a ty odpalasz GGUF — który jest lepszy? Źle postawione pytanie. To dwa pojemniki do dwóch różnych rzeczy.

Safetensors narodził się z zupełnie innej potrzeby: żeby nie ładować cudzych wag przez pickle (który potrafi odpalić dowolny kod przy wczytaniu) i żeby robić to szybko, bez kopiowania w pamięci.⁵ To rekomendowany format wag na Hugging Face — ale trzyma wyłącznie tensory. Chcesz z niego odpalić model, musisz dorzucić config i tokenizer obok. GGUF ten cały komplet nosi w sobie i dokłada kwantyzację. Nie „lepszy/gorszy” — inne zadanie. Jak chcesz to potem faktycznie uruchomić garścią flag, jest o tym osobny poradnik.

Wróć do tego menu

Wróć teraz do tego menu na Hugging Face, do listy dwudziestu plików kończących się na .gguf. Już nie wygląda jak bar mleczny, w którym wszystko nazywa się tak samo. Widzisz teraz, że ktoś wziął model wytrenowany na drugim końcu świata, przepuścił go przez convert_hf_to_gguf.py, upchał wagi, architekturę i tokenizer do jednego pudełka z przegródkami, ścisnął sitem Q4_K_M i wrzucił na Huba, żebyś ty mógł go zassać jednym plikiem i usłyszeć, jak mruczy pod biurkiem. Cała ta cicha fabryka — od klastra treningowego, przez konto bartowskiego, po twój dysk — sprowadza się do jednego czterobajtowego napisu na początku pliku: GGUF. Reszta to już tylko ty i pytanie, który wariant dziś bierzesz.