Kategoria: Lokalne AI
„Co to jest GGUF i dlaczego ten sam model jest na Hugging Face w dwóch zupełnie różnych postaciach?” Te dwie postacie nie są dwoma wydaniami tej samej rzeczy. Jedna z nich w ogóle nie uruchomi się na moim silniku.
Wszystkie rozmiary i prędkości poniżej pochodzą z jednej maszyny i z serii pomiarów z września 2026: mini PC z procesorem AMD Ryzen AI 9 HX 470, zintegrowaną grafiką Radeon 890M i 32 GB pamięci współdzielonej, z llama.cpp jako silnikiem. Dwadzieścia trzy modele, każdy z rozmiarem pliku na dysku.
Co siedzi w pliku GGUF
GGUF to format pojedynczego pliku, z którego silnik potrafi uruchomić model bez niczego obok. Nazwa jest skrótem, ale praktyczne znaczenie ma to, co w tym pliku leży.
Jeden plik, w którym jest komplet
W jednym pliku GGUF są wagi modelu, tokenizer, szablon rozmowy i metadane opisujące architekturę. To jest cała różnica użytkowa: pobierasz jedną rzecz i silnik wie, co z nią zrobić. Format jest następcą starszego GGML i stąd biorą się dwa zapytania, które ludzie wpisują wymiennie; w praktyce dziś pobiera się GGUF, a GGML spotyka się już tylko w starych opisach. Jak wygląda cała warstwa pod spodem, czyli system, silnik i brama API, opisałem w tekście o tym, jak uruchomić lokalny model AI na Ubuntu Server.
Czym to się różni od safetensors
Safetensors to format, w którym autorzy modeli publikują wagi najczęściej. GGUF to format, w którym te wagi trafiają do domowej maszyny. Poniższe zestawienie opisuje przeznaczenie obu formatów, czyli rzecz z ich specyfikacji, a nie z mojego pomiaru.
Dwa formaty, dwa różne zadania
| safetensors | GGUF | |
|---|---|---|
| Kto go zwykle ładuje | biblioteki uczenia maszynowego w Pythonie | silniki z rodziny llama.cpp i narzędzia na nich oparte |
| Co jest w pliku | same tensory i ich opis | wagi, tokenizer, szablon rozmowy i metadane architektury |
| Typowa postać publikacji | wagi w pełnej precyzji, rozbite na kilka plików | jeden plik o obniżonej precyzji, w kilku wariantach do wyboru |
| Do czego służy | trenowanie, dostrajanie, konwersja | uruchomienie modelu na gotowej maszynie |
Praktyczny wniosek jest jeden i nie wymaga znajomości żadnego z tych formatów od środka: jeżeli silnikiem jest llama.cpp, pobierasz GGUF, bo innego formatu ten silnik nie ładuje. Dlatego wszystkie dwadzieścia trzy pliki, które mam zmierzone, są plikami GGUF.
Dlaczego pełna precyzja się u mnie nie mieści
To jest powód, dla którego ta konwersja w ogóle istnieje, i da się go pokazać na jednym działaniu.
Dwadzieścia siedem miliardów parametrów po szesnaście bitów
W pełnej precyzji, w jakiej model jest trenowany, jedna waga zajmuje 16 bitów. Dla modelu o 27 miliardach parametrów daje to około 54 GB:
27 mld parametrów × 16 bitów ÷ 8 ≈ 54 GB
Ta maszyna miała wtedy 32 GB pamięci w całości, więc taki plik nie miał gdzie wejść. Wersja GGUF tego samego modelu waży u mnie 16 GB (pomiar, wrzesień 2026). Pliki w mojej serii mają od około 4 GB do 22,8 GB, a ten największy to jednocześnie największy model, jaki na tej maszynie uruchomiłem. Kwantyzacja nie jest tu więc optymalizacją, tylko warunkiem uruchomienia, a samo liczenie bitów na wagę rozpisałem osobno w tekście o tym, ile bitów na wagę ma plik, który pobrałeś.
Co mówi nazwa pliku GGUF
Nazwy wariantów pochodzą z llama.cpp, a nie od autorów modeli, i to jest pierwsza rzecz, która przy tym formacie myli.
Q4_K_M, i co jeszcze bywa w nazwie
Q4_K_M oznacza wariant, w którym większość wag jest zapisana na czterech bitach, a część warstw najbardziej wrażliwych na błąd na większej ich liczbie. Dlatego podzielenie rozmiaru pliku przez liczbę parametrów daje wynik nieco powyżej czterech, a nie równe cztery. W moich sześciu wierszach Qwen wychodzi z tego 4,7-5,1 bita na wagę, a prędkości tych samych sześciu modeli idą od 30,4 do około 3,5 tokena na sekundę (pomiar, wrzesień 2026). Ta sama rodzina, ten sam poziom kompresji, rząd wielkości różnicy: czyli o prędkości decyduje architektura, a nie wariant pliku.
W nazwie bywa jeszcze coś, co zmienia zachowanie silnika. Pliki z głowicami MTP mają zwykle MTP w nazwie i tylko one pozwalają włączyć szybsze generowanie przełącznikiem w llama.cpp. Zebrałem te metody osobno w tekście o tym, jak przyspieszyć lokalny model AI bez zmiany sprzętu.
Dwa pliki GGUF tego samego modelu, dwa różne wyniki
Tu kończy się teoria formatu i zaczyna powód, dla którego warto o nim wiedzieć.
22,8 GB kontra 22,4 GB
Model Nail-35B-A3B mam zmierzony w dwóch wydaniach pliku. Rozmiarem różnią się one o 0,4 GB, czyli o niecałe dwa procent, a wynikiem znacznie mocniej: wydanie 22,8 GB osiąga 24,17 tokena na sekundę, wydanie 22,4 GB zatrzymuje się na 17,86 (pomiar, wrzesień 2026).
Tę parę podawałem już wcześniej jako przykład, ale bez odpowiedzi na pytanie, skąd ta różnica się bierze. Odpowiedź siedzi dokładnie w tym, o czym jest ten tekst, czyli w nazwie pliku: szybsze wydanie ma w niej MTP, wolniejsze nie. Nazwa modelu, liczba parametrów i poziom kompresji są w obu takie same, a różni je zawartość pliku. Praktyczny wniosek dla pobierającego jest jeden: wariant GGUF wybiera się u siebie i sprawdza u siebie, a nie przepisuje z cudzego wpisu na forum. Pełną tabelę prędkości dla tej maszyny, model po modelu, zebrałem w tekście o tym, jaki model AI uruchomisz lokalnie na mini PC.
Nie uruchamiałem safetensors i nie zmierzyłem jakości
Nie uruchomiłem u siebie ani jednego pliku safetensors, bo silnik, którego używam, ich nie ładuje. Wszystko, co napisałem powyżej o przeznaczeniu obu formatów, pochodzi z ich opisu, a nie z mojego pomiaru, i tak należy to czytać.
Nie porównałem też GGUF z innymi formatami tej klasy. Żadnego z nich nie uruchamiałem na tej maszynie, więc liczby obok siebie z cudzych testów byłyby zestawieniem, nie pomiarem.
Najważniejsze zastrzeżenie dotyczy jakości. Rozmiar pliku mówi, ile zmieściłeś, a nie ile straciłeś. 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 liczby na koszt tej kompresji. Dwa pliki o tej samej liczbie bitów na wagę mogą odpowiadać różnie, a ta metoda tego nie wychwyci.
