„Pobrałem model o 27 miliardach parametrów, plik waży 16 GB – czy to jeszcze ten sam model?” To pytanie pada zwykle po pierwszym pobraniu, kiedy liczby przestają się zgadzać. Nie jest ten sam. Plik, który uruchamiasz u siebie, jest wersją o obniżonej precyzji – i to jest powód, dla którego model o 27 miliardach parametrów waży u mnie 16 GB, a nie 54 GB. Różnicę da się policzyć z dwóch liczb, które masz pod ręką.
Wszystkie rozmiary poniżej pochodzą z jednej maszyny i z jednej serii pomiarów z września 2026: mini PC z procesorem AMD Ryzen AI 9 HX 470, zintegrowanym układem graficznym Radeon 890M i 32 GB pamięci dzielonej. Dwadzieścia trzy modele, każdy z rozmiarem pliku na dysku.
Ile bitów na wagę faktycznie wychodzi
Rozmiar pliku dzielony przez liczbę parametrów
Nie trzeba czytać opisu modelu, żeby wiedzieć, w jakiej precyzji jest. Wystarczy podzielić rozmiar pliku przez liczbę parametrów:
16 GB × 8 bitów ÷ 27 mld parametrów ≈ 4,7 bita na wagę
W pełnej precyzji, w jakiej model jest trenowany, jedna waga zajmuje 16 bitów. Czyli plik, który pobrałeś, trzyma każdą wagę na mniej niż jednej trzeciej tego miejsca.
To samo działanie na innych wierszach tej samej serii daje niemal identyczny wynik: model 9B o rozmiarze 5,4 GB to około 4,8 bita, model 35B-A3B o rozmiarze 21 GB – również około 4,8 bita. Prawie cała tabela mieści się w pasmie 4,7–5,2 bita na wagę, i to jest najważniejsza informacja w tym tekście, bo z niej wynika, że te wiersze wolno porównywać między sobą.
Jak nazywa się ta precyzja
Q4_K_M i pozostałe formaty z tej serii
Nazwy tych formatów pochodzą z llama.cpp, nie od autorów modeli. Dla wierszy Qwen w tej serii to Q4_K_M – nazwa formatu, w którym większość wag jest zapisana na 4 bitach, a część warstw, najbardziej wrażliwych na błąd, na większej liczbie bitów. Stąd wynik 4,7–4,8 zamiast równego 4: te nadliczbowe bity to właśnie warstwy, których nie opłaca się ścisnąć do końca.
Wagi są przy tym zapisane grupami, a każda grupa ma własny mnożnik skalujący. Dlatego kwantyzacja nie polega na przycięciu każdej liczby osobno – zmniejsza się dokładność w obrębie grupy, przy zachowanym zakresie wartości.
Pięć wierszy, które z tego pasma wypadają
Inne pochodzenie, nie mocniejsza kompresja
Zdanie, którego nie wolno napisać o tej tabeli, brzmi „wszystko jest Q4”. Pięć wierszy ma inne pochodzenie i mieszanie ich z resztą jest błędem:
| Model | Bity na wagę | Czym to właściwie jest |
|---|---|---|
| gpt-oss-20b, 11 GB | około 4,4 | natywny format MXFP4 – model jest w tej precyzji udostępniony, nie został skwantowany po treningu |
| gemma-4-26B-A4B-it-qat | nie liczyłem | trenowany z uwzględnieniem kwantyzacji (QAT) – 4 bity są wynikiem treningu, nie kompresji |
| SmallThinker-21B-A3B | nie liczyłem | również QAT |
| granite-4.2-8b, około 4 GB | około 4,0–4,3 | ściśnięty mocniej niż reszta tabeli |
| Moonlight-16B-A3B | około 6 | ściśnięty słabiej niż reszta tabeli |
Różnica między „skwantowany po treningu” a „trenowany na czterech bitach” jest merytoryczna, nie nazewnicza. W pierwszym przypadku model był uczony w pełnej precyzji i został ściśnięty na końcu; w drugim uczył się od razu w warunkach, w których ta precyzja go obowiązuje. Drugie wypada zwykle lepiej przy tej samej liczbie bitów.
Dlaczego to decyduje o porównywaniu prędkości
Aktywne parametry, nie nazwa modelu
Na tej maszynie model 30B-A3B robi 30,4 tokena na sekundę, a gęsty model 27B – 7,6. To czterokrotna różnica i pierwsze, co słusznie przychodzi do głowy, to pytanie, czy nie wynika ona z tego, że jeden plik jest ściśnięty mocniej od drugiego.
Nie wynika. Oba siedzą w tym samym pasmie 4,7–4,8 bita na wagę, policzonym z rozmiaru pliku i liczby parametrów. Czterokrotna różnica jest więc różnicą architektury – mieszanka ekspertów liczy w danym kroku tylko część wag – a nie artefaktem precyzji. Rozpisałem to na liczbach w tekście dlaczego model 30B potrafi być szybszy niż 12B.
Reguła praktyczna z tego jest jedna: zanim porównasz prędkość dwóch modeli, policz bity na wagę dla obu. Jeśli wyniki różnią się o więcej niż pół bita, porównujesz dwie różne rzeczy.
Dlaczego to w ogóle musi się dziać
Powód jest prosty: pełna precyzja się nie mieści. Model o 27 miliardach parametrów po 16 bitów na wagę to około 54 GB – więcej, niż ta maszyna ma pamięci w całości. Rozmiary poniżej odczytałem z plików ładowanych przez llama.cpp: w tej serii modele gęste od 27 do 32 miliardów parametrów zajmują 15–19 GB (pomiar), a największy plik, jaki na tej maszynie uruchomiłem, to 22,8 GB (pomiar). Kwantyzacja nie jest tu optymalizacją. Jest warunkiem uruchomienia. Co dokładnie zostaje na resztę, kiedy model już wejdzie w pamięć, rozpisałem w tekście 16 GB czy 32 GB do lokalnego AI.
Czego nie zmierzyłem
Kwantyzacja modelu AI mówi, ile zmieściłeś, a nie ile straciłeś. Najważniejszej rzeczy: ile ta kompresja kosztuje w jakości odpowiedzi. Nie przepuściłem tych modeli przez żaden zestaw testowy w dwóch precyzjach i nie porównałem wyników, więc nie mam na to liczby. Nie podam też cudzej, bo wynik zależy od modelu i od rodzaju zadania, a wartość przeniesiona z innej konfiguracji nie powiedziałaby nic o mojej.
Praktyczna strona tego ograniczenia jest taka: dzielenie rozmiaru pliku przez liczbę parametrów mówi, ile miejsca zajmuje jedna waga. Nie mówi, które warstwy dostały więcej bitów, a które mniej – a to jest element, który różni dobrą kwantyzację od złej przy tej samej liczbie na wyjściu. Dwa pliki o 4,8 bita na wagę mogą odpowiadać różnie i ta metoda tego nie wychwyci.
