I działa — do momentu, w którym chcesz coś, czego domyślnie nie dostajesz. Więcej kontekstu. Model wciśnięty w kartę, która teoretycznie jest za mała. Serwer na całą sieć domową, bez wysyłania czegokolwiek na zewnątrz. Wtedy schodzisz piętro niżej, do llama.cpp — silnika w czystym C/C++, na którym pół tego lokalnego światka stoi (Ollama, LM Studio, KoboldCpp — wszystkie mają go gdzieś pod maską). A tam rządzą flagi. I dobra wiadomość jest taka: z tej setki na co dzień dotykasz może dziesięciu.

Zanim ruszysz: dwie binarki, nie jedna

Kiedyś było main. Dziś, po sprzątaniu w repo, masz dwa najważniejsze narzędzia: llama-cli (rozmowa w terminalu, testy, skrypty) i llama-server (serwer z web UI i API kompatybilnym z OpenAI). Flagi w dużej mierze się pokrywają, więc to, co niżej, działa w obu — chyba że zaznaczę inaczej.

Model podajesz jednym parametrem, -m (od model). Reszta to strojenie:

llama-cli -m qwen2.5-7b-instruct-q4_k_m.gguf -cnv

-cnv (od conversation) włącza tryb czatu, zamiast jednorazowego dokończenia promptu. Do tego -sys "jesteś zwięzłym asystentem" ustawia prompt systemowy, a -p "..." podaje zwykły prompt. Tyle wystarczy, żeby cokolwiek gadało. Tyle że domyślne ustawienia rzadko są skrojone pod twoją konkretną kartę — więc przechodzimy do sedna.

Żeby model wszedł do karty

Tu toczy się cała gra, bo VRAM (pamięć karty) to waluta, której nigdy nie masz dość. Cztery flagi, które robią 90% roboty:

• -ngl N (gpu-layers) — ile warstw modelu wrzucić na GPU. To najważniejsza flaga w całym zestawie. Przyjmuje liczbę albo słowo: auto (domyślnie — llama.cpp sam dobiera, ile się zmieści) oraz all (wrzuć wszystko, co się da). Chcesz maksimum na karcie? -ngl all. Za mało VRAM-u na cały model? Podaj mniejszą liczbę, np. -ngl 20 — reszta poleci na CPU. Mieszany offload jest wolniejszy, ale często to jedyny sposób, żeby większy model w ogóle ruszył.
• -c N (ctx-size) — okno kontekstu w tokenach. Domyślnie llama.cpp bierze rozsądną wartość, ale to właśnie kontekst potrafi po cichu zjeść ci pamięć. Podwoisz -c z 4096 na 8192 i nagle brakuje pół giga VRAM-u, którego przed chwilą było w sam raz. -c 0 mówi „weź maksimum z modelu" — kuszące, ale sprawdź wcześniej, czy masz na to pamięć.
• -fa on (flash attention) — zoptymalizowana uwaga: mniej pamięci na KV-cache (bufor, w którym model trzyma przetworzony kontekst) i zwykle ciut szybciej. Flaga przyjmuje on/off/auto, a domyślnie stoi na auto (to llama.cpp decyduje). Chcesz mieć pewność, że działa na nowszej karcie — wal -fa on.
• -ctk / -ctv (cache-type-k / -v) — kwantyzacja samego KV-cache, np. q8_0 albo q4_0. Przy długim kontekście to on, nie wagi, robi się największym żłobem na pamięć. Ściśnięcie go do q8_0 odzyskuje sporo VRAM-u niemal bez odczuwalnej straty. Najlepiej razem z -fa on.

Żeby było szybciej

Zmieściło się? To teraz o prędkość:

• -t N (threads) — ile wątków CPU. Ustaw na liczbę fizycznych rdzeni, nie logicznych. Więcej nie znaczy szybciej — powyżej liczby rdzeni zaczynasz sobie tylko przeszkadzać. Liczy się głównie wtedy, gdy część modelu (albo całość) siedzi na CPU.
• -b / -ub (batch-size / ubatch-size) — jak duże porcje tokenów przetwarza model naraz przy „czytaniu" promptu. Domyślne wartości są sensowne; ruszaj je, dopiero jak świadomie walczysz o przepustowość przy długich promptach.
• --mlock — przypnij model w RAM, żeby system nie wyrzucił go do swapu w najmniej odpowiednim momencie. --no-mmap ładuje cały plik do pamięci z góry (przydatne na dziwnych dyskach sieciowych). Na co dzień rzadko potrzebne, ale warto wiedzieć, że są.
• -ts / -sm (tensor-split / split-mode) — masz dwie karty? -ts 3,1 rozłoży model w proporcji 3:1, a -sm decyduje, jak dokładnie. Temat na osobny wpis, ale niech ci mignie, że wielo-GPU to nie czarna magia.

Żeby generacja miała ręce i nogi

Te flagi nie dotykają pamięci — sterują tym, jak model dobiera słowa:

Jak model gada od rzeczy — zbij --temp. Jak mieli w kółko to samo — podnieś --repeat-penalty o włos. Bez fanatyzmu, to pokrętła, nie wyrocznia.

Serwer, czyli twój prywatny endpoint

Najlepszy patent na co dzień: odpal llama-server raz i gadaj z modelem z przeglądarki albo z kodu, przez API w formacie OpenAI — wszystko lokalnie, offline.

llama-server -m qwen2.5-7b-instruct-q4_k_m.gguf \
  -ngl all -c 8192 -fa on \
  --host 0.0.0.0 --port 8080

Wchodzisz na http://localhost:8080 i masz web UI od strzału. --host 0.0.0.0 wystawia serwer na całą sieć domową (laptop w kuchni gada z kartą w gabinecie — klasyk domowego setupu). -np N (parallel) obsłuży kilka rozmów naraz, a -cb (continuous batching) sensownie je poupycha. --jinja każe użyć szablonu czatu wbudowanego w model — przydaje się, gdy odpowiedzi wyglądają, jakby model nie wiedział, że rozmawia.

Zrób to sam

Masz kartę 8 GB i model 7B w Q4? Zacznij od tego i patrz na zużycie VRAM:

llama-cli -m qwen2.5-7b-instruct-q4_k_m.gguf -ngl all -c 4096 -fa on -cnv

Nie wchodzi? Dorzuć ściśnięty cache i przytnij okno:

llama-cli -m qwen2.5-7b-instruct-q4_k_m.gguf \
  -ngl all -c 4096 -fa on -ctk q8_0 -ctv q8_0 -cnv

Modele w formacie GGUF ściągniesz z Hugging Face (szukaj wariantów Q4_K_M — dobry kompromis rozmiar/jakość). Kod, aktualne flagi i instrukcje budowania są w oficjalnym repo: github.com/ggml-org/llama.cpp. A pełną, zawsze aktualną listę wywołasz tym, od czego zaczęliśmy — llama-cli --help. Tylko teraz ta ściana nie będzie już ścianą, a tablicą z pokrętłami, z których wiesz, które przekręcić.

Wartości domyślne w llama.cpp bywają dobre, ale zmieniają się z wersją. Jak coś zaczyna działać dziwnie po aktualizacji — najpierw zajrzyj, czy flaga, na której polegasz, nie dostała nowego domyślnego zachowania.

Bo cała zabawa w lokalnym AI sprowadza się właśnie do tego jednego uczucia: siedzisz przed własnym sprzętem, przekręcasz pokrętło o jeden klik i patrzysz, jak model, który „się nie mieścił", nagle mruczy pod biurkiem jak trzeba. Nikt ci nie dyktuje, ile masz mu dać kontekstu ani na czym go odpalić. Ty, karta i garść flag.

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

Dobra wiadomość: nie musisz zgadywać. VRAM da się policzyć na palcach, z grubsza, w głowie, zanim cokolwiek ściągniesz. Nie do grama — do grama policzy ci llama.cpp przy starcie — ale na tyle dokładnie, żeby wiedzieć, czy w ogóle podchodzić. O to cała sztuka: zamiast wróżyć z rozmiaru pliku, umieć powiedzieć „7B w Q4 to jakieś pięć giga plus zapas, wejdzie" — i mieć rację.

Wzór na palcach

Cały fundament mieści się w jednej linijce:

rozmiar wag (GB) ≈ liczba parametrów (mld) × bity na wagę / 8

I tyle. Bierzesz, ile model ma miliardów parametrów, mnożysz przez to, ile bitów zajmuje jedna waga w danym formacie, dzielisz przez osiem (bo bajt ma osiem bitów) i masz gramaturę samych wag w gigabajtach. Model 8B w kwantyzacji Q4, gdzie na wagę schodzi jakieś 4,5 bita? 8 × 4,5 / 8 ≈ 4,5 GB. I to nie jest teoretyczna wróżba — realny plik Q4_K_M dla Llamy 3.1 8B waży 4,92 GB.¹ Zgadza się co do joty, a właściwie co do paru setek megabajtów.

Skąd biorą się ułamkowe bity

Tu pierwsza pułapka, na którą łapie się każdy początkujący: „Q4 to przecież cztery bity, nie?". No właśnie nie do końca. Gdyby świat był prosty, Q4_0 (stary, prościutki typ) brałby równe 4,5 bita na wagę — bo pakuje 32 wagi w blok i dokłada do nich trochę metadanych o skali.² Ale nowsze formaty, tak zwane K-quanty (Q2_K do Q6_K, z dopiskami _S, _M, _L), są sprytniejsze: mieszają precyzję między różnymi warstwami modelu. Te tensory, od których jakość naprawdę zależy, dostają więcej bitów, reszcie się skąpi. Efekt? Liczba bitów na wagę wychodzi ułamkowa.

Konkretnie, dla Llamy 3.1 8B według oficjalnej tabeli llama.cpp:²

Widzisz tę drobną rozbieżność między kolumnami? Jedna to GiB (liczone po 1024), druga GB (po 1000), plus K-quant miesza precyzję tensorów — stąd Q4_K_M ma prawie 4,9 bita, a nie równe 4,5.¹ Do liczenia na palcach nic to nie zmienia: bierzesz „mniej więcej 4,5–5 bita dla Q4" i tak trafiasz w wynik z dokładnością do zapasu, który i tak musisz zostawić. Jest jeszcze cała rodzina IQ-quantów (IQ2_XXS, IQ3_S i spółka), które schodzą poniżej trzech bitów, ważąc jakość specjalną macierzą istotności — ale to temat na osobny wieczór.²

Ile zważy „ten twój" model

Przełóżmy wzór na cztery rozmiary, które realnie krążą po lokalnym światku. To są same wagi, bez narzutu — o narzucie za chwilę:

Popatrz na to przez chwilę, bo tu widać całą matematykę życia lokalnego LLM-owca. Masz kartę 8 GB? Ósemka w Q4 wchodzi na luzie, w Q5 już z zadyszką, a Q8 nawet nie podchodź. Dwunastka w Q4 to 7,5 GB samych wag — teoretycznie „się mieści", tylko że na sam narzut nie zostaje już nic. A czternastka w Q4 to prawie dziewięć giga — twoje 8 GB kończy się, zanim się zaczęło. Dlatego „te swoje 8 GB" znika tak szybko: liczysz gramaturę wag, cieszysz się, że wchodzi, a potem uruchamiasz i okazuje się, że o czymś zapomniałeś.

Czego zapominasz: KV-cache i bufory

O to zapominasz. Rozmiar pliku GGUF to tylko wagi. Do tego dochodzi KV-cache — pamięć, w której model trzyma przetworzone klucze i wartości dla każdego tokena, który model już wygenerował lub wczytał z promptu. I to jest ten cichy złodziej VRAM-u, bo rośnie liniowo z długością kontekstu. Im dłuższa rozmowa, tym większy żłób na pamięć.

Ile dokładnie? Też się liczy na palcach. Na jeden token przypada:

KV na token = 2 (klucz + wartość) × liczba_warstw × n_head_kv × head_dim × bajty_na_element

Dla Llamy 3.1 8B te liczby to: 32 warstwy, n_head_kv = 8, head_dim = 128, a KV-cache domyślnie leci w f16, czyli 2 bajty na element⁵ (co to za f16 i czemu nie bf16 — tu). Wrzuć to do wzoru: 2 × 32 × 8 × 128 × 2 bajty = 128 KiB na token. Przy kontekście 8192 tokenów robi się z tego równiutki 1 GiB — tyle dokłada sam cache do tego, co już zjadły wagi. Rozbieramy ten mechanizm dokładniej tutaj, ale zasada do zapamiętania jest prosta: dłuższy kontekst = więcej VRAM-u, po prostu.

Zwróć uwagę na n_head_kv = 8 — pełna liczba głów uwagi w tym modelu jest większa, ale dzięki GQA (grouped-query attention, mechanizm współdzielenia głów klucza/wartości) do cache liczy się tylko ta zredukowana ósemka. Bez GQA, na starej architekturze, ten narzut potrafił być wielokrotnie większy. Do tego dochodzą jeszcze bufory obliczeniowe samego procesu inferencji. Dlatego świętą zasadą jest: zostaw 1–2 GB zapasu ponad rozmiar wag. Kto liczy VRAM tylko z gramatury pliku GGUF, ten regularnie ląduje na „out of memory" przy trzecim akapicie rozmowy.

Jak zejść niżej, gdy nie wchodzi

Powiedzmy, że policzyłeś i wychodzi za dużo. Masz trzy dźwignie, w tej właśnie kolejności.

Raz — kwantyzacja niżej. To najprostszy ruch: zamiast Q8 bierzesz Q5, zamiast Q5 bierzesz Q4. Czternastka w Q8 to 15,7 GB, a w Q4 już tylko 8,99 GB⁴ — prawie połowa mniej, a jakość spada zaskakująco mało, bo K-quanty oszczędzają mądrze. Q4_K_M to nie bez powodu domyślny wybór połowy internetu.

Dwa — kwantyzacja KV-cache. Skoro cache potrafi dołożyć giga przy dłuższym kontekście, to jego też można ścisnąć. llama-server ma na to flagi -ctk / --cache-type-k i -ctv / --cache-type-v, osobno dla kluczy i wartości; domyślnie oba stoją na f16, ale przyjmują też q8_0, q4_0 i całą listę innych typów.⁶ Ściśnięcie cache z f16 do q8_0 to znów zejście z jego rozmiaru mniej więcej o połowę.

llama-server -m qwen2.5-14b-instruct-q4_k_m.gguf \
  -ngl all -c 8192 -fa on \
  -ctk q8_0 -ctv q8_0

Widzisz to -fa on? To nie ozdoba. Flaga -fa / --flash-attn (przyjmuje on/off/auto, domyślnie auto) włącza Flash Attention — a kwantyzacja KV-cache do typów poniżej f16 praktycznie wymaga włączonej Flash Attention.⁶ Ustawisz -ctk q4_0 bez -fa on i w najlepszym razie nic nie zyskasz, w najgorszym nie ruszy. Więc: najpierw Flash Attention, potem duś cache.

Trzy — przytnij kontekst albo zrzuć część warstw na CPU. To ostateczność, bo krótszy kontekst to mniejsza pamięć modelu, a offload na CPU (flaga -ngl z liczbą mniejszą niż „wszystko") spowalnia generację. Ale gdy 12B w Q4 nie chce wejść na 8 GB nawet po ściśnięciu cache — czasem to jedyny sposób, żeby w ogóle ruszyło. Cała ta chirurgia flagami to osobny rozdział, który rozpisaliśmy tu.

Zrób to sam: rachunek w trzy sekundy

Następnym razem, gdy staniesz przed nowym modelem, przelicz go w głowie, zanim klikniesz pobieranie:

1. Wagi: parametry × bity / 8. Ósemka w Q4 → 8 × 4,5 / 8 ≈ 4,5 GB. Albo zerknij na realny plik na Hugging Face i weź gotową liczbę.
2. Cache: przy zwykłym kontekście (4–8k) dorzuć z grubsza 0,5–1 GB dla modelu klasy 7–14B z GQA. Planujesz 32k albo więcej? Licz się z kilkoma gigabajtami i od razu myśl o -fa on plus -ctk q8_0.
3. Zapas: dorzuć 1–2 GB na bufory i oddech.

Suma większa niż twój VRAM? Schodzisz z kwantyzacją albo duszisz cache — w tej kolejności. Suma mniejsza? Ściągaj śmiało, wejdzie.

Bo cała sztuka z VRAM-em nie polega na wróżeniu, tylko na tym jednym prostym mnożeniu na palcach — parametry razy bity, przez osiem, plus zapas. Kiedy raz je poczujesz, folder models przestaje być loterią, a zaczyna być tym, czym powinien: półką, na której z góry wiesz, co się zmieści, a co poleży, aż dokupisz kartę „na później". A dokupisz. Wszyscy dokupujemy.

Przypisy · źródła

Bo pod spodem dzieje się rzecz z pozoru absurdalnie rozrzutna. Żeby dołożyć jeden token, model o siedmiu czy siedemdziesięciu miliardach parametrów musi przepchnąć całe swoje wnętrze — pełny przebieg naprzód — po czym dokłada jedną literkę i zaczyna od nowa. Cały ten kolos rozgrzewa się do jednego słowa, potem znowu, i znowu. Trochę jak odpalać silnik ciężarówki za każdym razem, gdy chcesz przejechać metr.

Skąd w ogóle ten pomysł

W 2022 roku trójka badaczy z Google’a — Leviathan, Kalman i Matias — zadała pytanie, które brzmi jak sabotaż: a co, jeśli większość kolejnych tokenów jest tak oczywista, że nie trzeba do nich całego dużego modelu? Że „w dniu dzisiejszym" po słowie „w" i „dniu" da się zgadnąć czymś dużo tańszym? Opisali to w pracy Fast Inference from Transformers via Speculative Decoding i pokazali coś, co brzmi zbyt pięknie: 2–3 razy szybsza generacja na modelach klasy T5-XXL, bez douczania czegokolwiek i bez zmiany rozkładu wyjściowego — czyli model gada dokładnie to samo, co gadałby normalnie, tylko szybciej.¹ Papier poszedł na ICML 2023 jako prezentacja ustna, więc nie była to notka na marginesie.

Dwa miesiące później niezależnie tę samą ideę opisała ekipa z DeepMind — Chen, Borgeaud, Irving, Lespiau, Sifre i Jumper — pod nazwą speculative sampling, z lekko innym schematem matematycznym i przyspieszeniem 2–2,5x na Chinchilli (70B) w środowisku rozproszonym.² Dwa zespoły, ten sam pomysł, ta sama gwarancja: przyspieszamy, jakości nie ruszamy. Kiedy dwie niezależne grupy trafiają w to samo, to zwykle znak, że pod spodem siedzi coś prawdziwego.

Jak to działa krok po kroku

Dobra, ale jak to działa naprawdę? Bierzesz dwa modele. Jeden duży — ten, którego odpowiedzi chcesz — nazwijmy go docelowym (target). I jeden mały, szybki — szkicownik (draft) — najlepiej tej samej rodziny, żeby „myślał" podobnie. I teraz taniec w trzech krokach:

1. Szkicownik zgaduje. Mały model generuje autoregresywnie kilka kolejnych tokenów — powiedzmy K sztuk. Robi to szybko, bo jest mały. To są propozycje, brudnopis.
2. Duży weryfikuje — jednym przebiegiem. I tu jest cały myk: duży model dostaje te K proponowanych tokenów naraz i sprawdza je w jednym przebiegu naprzód, wsadowo. Nie K osobnych przejazdów ciężarówką — jeden.
3. Akceptuj albo popraw. Tam, gdzie duży model zgadza się ze szkicownikiem, tokeny wpadają za darmo. Przy pierwszym niezgodnym — odrzucamy resztę, duży dokłada swój token i cała zabawa rusza od nowa.

Jeśli szkicownik trafił w pięć tokenów z rzędu, to policzyłeś je jednym przebiegiem dużego modelu zamiast pięciu. Jeśli spudłował od razu — koszt jest praktycznie taki, jak przy zwykłym dekodowaniu. Downside prawie żaden, upside spory. Ta sama logika weryfikacji „licz wsad, nie sekwencję" siedzi zresztą u podstaw tego, czemu KV-cache w ogóle się opłaca — rozgryzaliśmy to tutaj.

Czemu to nie psuje jakości

W tym miejscu każdy rozsądny człowiek zapala czerwoną lampkę. „Mały model zgaduje za dużego? To brzmi jak destylacja na skróty, na pewno wychodzi gorsza jakość." Otóż nie — i to jest najładniejsza część całej sztuczki.

To nie jest kwantyzacja ani destylacja. Wag dużego modelu nikt nie dotyka, jego dokładność zostaje nietknięta. Sekret siedzi w tym, jak akceptowane są tokeny — używa się zmodyfikowanego rejection sampling (próbkowania odrzucającego). Token zaproponowany przez szkicownik przyjmujemy z prawdopodobieństwem min(1, p_target(x) / p_draft(x)) — czyli: jeśli duży model uważa dany token za co najmniej tak samo prawdopodobny jak szkicownik, bierzemy go w ciemno. Jeśli mniej — akceptujemy proporcjonalnie, a przy odrzuceniu dobieramy nowy token z rozkładu resztkowego (residual), tak dobranego, żeby wszystko się matematycznie spięło.¹

Efekt? Łączny rozkład tokenów na wyjściu jest identyczny z tym, co dałoby zwykłe, niespekulacyjne próbkowanie samego dużego modelu. Nie „prawie taki sam", nie „w granicach błędu" — dokładnie taki sam, z dowodem.

Skąd się bierze przyspieszenie

Skoro nic nie tniemy, to gdzie ten darmowy obiad się chowa? W wąskim gardle, o którym lokalny LLM-owiec i tak wie w kościach: inferencja jednego tokena naraz jest ograniczona pamięcią (bandwidth-bound), nie liczeniem. Karta większość czasu nie liczy, tylko czeka, aż wagi modelu przemaszerują z VRAM-u do rdzeni. Przepchnięcie przez ten sam kanał jednego tokena a pięciu naraz kosztuje prawie tyle samo — bo i tak głównie czekasz na pamięć, a nie na arytmetykę.

Stąd cały zysk: policzenie K+1 tokenów w jednym wsadowym przebiegu jest znacznie tańsze niż K+1 osobnych, sekwencyjnych kroków. Im więcej propozycji szkicownika duży model akceptuje, tym mocniej wygrywasz.³ I tu ważne zastrzeżenie, bo to nie jest magiczne pokrętło „więcej = szybciej": przyspieszenie nie rośnie liniowo z liczbą draftowanych tokenów. Wszystko wisi na współczynniku akceptacji — jak często szkicownik trafia. Każąc mu zgadywać dwadzieścia tokenów naprzód przy kiepskiej trafności, generujesz górę brudnopisu, który duży model i tak wyrzuci do kosza. Bywa, że wtedy jest wolniej niż bez całej zabawy.

Zrób to sam w llama.cpp

Teoria teorią, ale llama.cpp (repo ggml-org/llama.cpp) obsługuje to od dawna — i w llama-server, i w osobnym narzędziu llama-speculative-simple. Cały wjazd na klasyczny wariant to jedna flaga: --spec-draft-model (krócej -md), która wskazuje plik GGUF modelu szkicowego.⁴ Bierzesz duży model, dokładasz mały z tej samej rodziny i lecisz:

llama-server -m qwen3-14b-q4_k_m.gguf \
  -md qwen3-0.6b-q4_k_m.gguf \
  --spec-draft-n-max 4 \
  -ngl all -c 8192 -fa on

--spec-draft-n-max N (domyślnie 3) ustawia maksymalną liczbę tokenów szkicowanych na krok, a --spec-draft-n-min N (domyślnie 0) dolną granicę.⁴ Progi akceptacji stroisz przez --spec-draft-p-min (domyślnie 0.00) i --spec-draft-p-split (domyślnie 0.10). Do reszty flag llama-server — -ngl, -c, -fa i spółka — wracaliśmy osobno tutaj.

Strategię wybiera --spec-type, i tu robi się ciekawie, bo klasyczny draft model to dopiero początek:

Warianty n-gramowe to osobny gatunek: nie potrzebują żadnego drugiego modelu, tylko zgadują kolejne tokeny na podstawie tego, co już się w tekście pojawiło (świetne, gdy model dużo cytuje sam siebie albo klepie strukturę). Mechanizm weryfikacji jest ten sam — po prostu brudnopis powstaje inaczej.³ A na drugim biegunie EAGLE-3 (draft-eagle3) to lekka, jednotransformerowa głowica, która podgląda stany ukryte dużego modelu i przez to trafia częściej niż samodzielny mały model tej samej wagi. Uruchomienie z dokumentacji wygląda tak:

llama-server -m Qwen3-4B.gguf \
  -md Qwen3-4B-eagle3.gguf \
  --spec-type draft-eagle3

Jedna pułapka na koniec, żebyś nie stracił wieczora na kopiowanie starych poradników: dawne flagi --draft, --draft-max, --draft-min zostały usunięte. Aktualna składnia to --spec-draft-n-max i pochodne --spec-*.⁴ Jak przepiszesz przykład sprzed roku i llama-server prycha, że nie zna flagi — to nie ty zwariowałeś, to repo poszło naprzód.

Najładniejsze w tym wszystkim jest to, że speculative decoding nie jest żadnym oszustwem na jakości — jest raczej jak dobry sekretarz. Ktoś szybki i tani pisze pod dyktando pierwszy szkic, przewidując, dokąd zmierza zdanie, a szef tylko przelatuje wzrokiem i skreśla to, co się nie zgadza. Reszta zostaje, jak stała. Szef odpowiada za każde słowo tak samo jak wtedy, gdy pisał sam — tyle że nie musi już maczać pióra w kałamarzu przy każdej literce.

I to jest ten moment, w którym twoja drukarka igłowa spod biurka nagle łapie zryw — te same słowa, ten sam rozkład, ta sama karta. Tylko kursor przestaje w końcu dyktować ci tempo.

Przypisy · źródła

Bo lokalny LLM to nie jedno pudełko. To silnik i obudowa. I zanim wybierzesz, w czym odpalać modele, warto wiedzieć, kto tu jest maszyną, a kto tylko ładnie polakierowanym panelem z pokrętłami. Nie po to, żeby wybierać strony w kolejnej wojnie plemiennej — po to, żeby wiedzieć, kiedy nakładka ci wystarczy, a kiedy trzeba zejść piętro niżej.

Silnik, którego nie widać: llama.cpp i ggml

Zacznijmy od dna, bo tam mieszka bohater tej historii. llama.cpp (repo ggml-org/llama.cpp) to biblioteka i silnik inferencji LLM napisane w czystym C/C++, z minimalnymi zależnościami, na licencji MIT.¹ Nie ma ładnego okienka. Nie ma listy modeli do kliknięcia. To surowy kod, który bierze wagi modelu i liczy — a liczy na bibliotece tensorowej niższego poziomu o nazwie ggml, i to ona jest właściwym mięśniem, który mnoży macierze pod całą tą konstrukcją.

To właśnie tu żyją rzeczy, które w codziennym „odpal i gadaj" są niewidzialne. Kwantyzacja po treningu (post-training quantization — ściskanie gotowych wag, nie trenowanie modelu od zera w niskiej precyzji, bo to dwie różne bajki) w formacie GGUF, z poziomami od 1.5-bitowego po 8-bitowy.¹ Akceleracja na Metal (Apple Silicon), CUDA (NVIDIA), HIP (AMD), Vulkan, SYCL (Intel), plus optymalizacje CPU (AVX/AVX2/AVX512).¹ Zestaw narzędzi z linii komend: llama-cli do rozmowy, llama-server z API, llama-bench do mierzenia wydajności, llama-quantize do ściskania modeli.¹ Rozbieraliśmy te flagi na czynniki pierwsze tutaj, a nazwy kwantyzacji GGUF (Q4_K_M i cała ta rodzina) tutaj.

Zapamiętaj jedno: kiedy Ollama, LM Studio albo KoboldCpp „uruchamia model", to w przytłaczającej większości przypadków pod spodem kręci się właśnie ten silnik. Reszta to obudowa. Świetna, wygodna, oszczędzająca ci godzin — ale obudowa.

Ollama: nakładka, która po cichu wyhodowała własny silnik

Ollama to najpopularniejszy sposób, w jaki ludzie wchodzą w lokalne LLM-y, i przez długi czas najkrótszy opis brzmiał: „llama.cpp z ładnym zarządzaniem modelami". Sama dokumentacja projektu mówi, że Ollama jest oparta na llama.cpp założonym przez Georgiego Gerganova i historycznie korzystała z niego jako silnika wykonawczego pod spodem; licencja MIT.²

Do tego dokłada rzeczy, których gołe llama.cpp ci nie da od strzału. Modelfile — format konfiguracyjny w duchu Dockerfile, który opisuje parametry, prompt systemowy i wagi, żeby zbudować z tego gotowy „obraz" modelu.² Rejestr ollama.com/library, z którego ściągasz modele jednym ollama pull, jak obrazy z Docker Huba. I własne REST API na porcie 11434 (http://localhost:11434/api/), odrębne od tego, co wystawia llama-server.² To jest właśnie ta wygoda, za którą się Ollamę kocha: nie myślisz o plikach GGUF, o ścieżkach, o flagach. Wpisujesz nazwę i działa.

Ale tu jest zwrot akcji, o którym połowa internetu wciąż nie wie. Od maja 2025, wraz z ogłoszeniem „Ollama’s new engine for multimodal models", Ollama dla części modeli — między innymi Meta Llama 4, Google Gemma 3, Qwen 2.5 VL czy Mistral Small 3.1 — przeszła na własny silnik napisany w Go, który korzysta bezpośrednio z biblioteki ggml, z pominięciem llama.cpp.³ llama.cpp i ggml zostają dla wstecznej kompatybilności na CPU i dla pozostałych modeli, ale samo hasło „Ollama to po prostu llama.cpp w ładnym opakowaniu" zrobiło się nieaktualne. Ciekawostka, ale ważna: nawet gdy nakładka odcina się od llama.cpp, i tak stoi na tym samym fundamencie — ggml. Mięsień został ten sam, zmieniło się tylko, kto go obsługuje.

LM Studio: okno, dwa silniki i zamknięte drzwi

A co, jeśli w ogóle nie chcesz terminala? Wtedy wchodzi LM Studio — aplikacja desktopowa na Windows, Linux i macOS, z prawdziwym GUI: przeglądasz modele, klikasz, pobierasz, gadasz. Pod spodem uruchamia modele przez llama.cpp w formacie GGUF, a na Apple Silicon dorzuca dodatkowo silnik MLX — inferencyjny framework Apple — jako alternatywę dla llama.cpp.⁴ Czyli znów: ten sam silnik u podstaw, tylko schowany za oknem, w które można klikać.

Dla programisty LM Studio wystawia dwie rzeczy naraz: OpenAI Compatibility API (żeby podpiąć się jak do OpenAI, tylko lokalnie) oraz własne LM Studio REST API (w wersji beta), a do tego CLI o nazwie lms do zarządzania modelami, serwerem i pobieraniem.⁴ Wygodne? Bardzo. Jest jednak jeden haczyk, który łatwo przeoczyć: to, że LM Studio stoi na otwartoźródłowych silnikach (llama.cpp, MLX), nie czyni z niego projektu open source. Sama aplikacja jest zamkniętym oprogramowaniem. Silnik w środku możesz obejrzeć do ostatniej linijki; obudowę wokół niego — już nie.

KoboldCpp: nie osobny silnik, tylko llama.cpp w jednym pliku

Na koniec przypadek, który najłatwiej źle zaszufladkować. KoboldCpp (LostRuins/koboldcpp) wygląda jak osobne narzędzie — jeden plik wykonywalny, który odpalasz i masz gotowy interfejs. Ale to nie konkurencyjny silnik wobec llama.cpp. To fork i nakładka bazująca bezpośrednio na jego kodzie, spakowana w pojedynczą binarkę i rozszerzona o dodatkowe funkcje. Sam KoboldCpp jest na licencji AGPL v3.0, przy czym zależność llama.cpp w środku pozostaje na MIT.⁵

Obsługuje modele GGUF (z kompatybilnością wsteczną dla starszego GGML — o czym za chwilę) i wystawia równolegle dwa API: własne KoboldAI/KoboldCpp oraz endpoint kompatybilny z OpenAI pod ścieżką /v1. Do tego dorzuca interfejs KoboldAI Lite z trybami chat, adventure, instruct i storywriter.⁵ Innymi słowy: bierze ten sam silnik, co reszta, i buduje wokół niego inny zestaw wygód — mocno wychylony w stronę pisania i grania. Nazwanie tego „rywalem llama.cpp" to jak nazwanie karoserii rywalem silnika.

To którego w końcu wziąć?

Teraz konkret, bo o to naprawdę chodzi. Nie o to, który silnik „lepszy" — bo silnik u podstaw (ggml) jest w dużej mierze wspólny — tylko o to, ile wygody wymieniasz za ile kontroli.

Nakładka wystarczy — i to z nawiązką — kiedy chcesz po prostu ściągać modele jednym poleceniem, przełączać się między nimi bez myślenia o ścieżkach i mieć endpoint, do którego podepniesz swój kod. To codzienność dziewięciu na dziesięciu lokalnych LLM-owców. Ollama do szybkiego pull i run, LM Studio jak wolisz klikać w okno, KoboldCpp jak siedzisz w pisaniu i przygodówkach.

Do gołego llama.cpp schodzisz, gdy zaczyna ci brakować pokręteł. Chcesz wycisnąć konkretny offload warstw na kartę, ustawić dokładny typ kwantyzacji KV-cache, złapać najświeższą flagę, która w repo pojawiła się wczoraj, a do nakładki dojdzie za dwa wydania. Albo chcesz llama-server z równoległym dekodowaniem (parallel decoding), serwujący do tego modele embeddingowe i rerankingowe pod twojego RAG-a.¹ Wtedy obudowa zaczyna przeszkadzać, a ty otwierasz maskę i grzebiesz przy silniku sam.

Zrób to sam: zejdź o piętro

Chcesz na własne oczy zobaczyć, że pod spodem siedzi jeden i ten sam mechanizm? Weź dowolny model GGUF, którego już używasz w Ollamie, i odpal go bezpośrednio w llama.cpp:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
# zbuduj wg instrukcji z README pod swój backend (Metal/CUDA/Vulkan/CPU)

llama-server -m twoj-model-q4_k_m.gguf -c 8192 -fa on

Wchodzisz na http://localhost:8080, dostajesz web UI i OpenAI-kompatybilne API — to samo, co daje ci nakładka, tylko bez pośrednika i z pełnym dostępem do każdej flagi. Kod, aktualne narzędzia i instrukcje budowania są w repo: github.com/ggml-org/llama.cpp. Jak zechcesz wrócić do wygody — Ollama, LM Studio i KoboldCpp czekają tam, gdzie je zostawiłeś. Nic nie tracisz, bo pliki GGUF działają wszędzie tak samo.

Bo cała ta scena — Ollama, LM Studio, KoboldCpp — to w gruncie rzeczy różne obudowy przykręcone do wspólnego silnika. Jedni lubią jeździć autem, nie otwierając nigdy maski, i to jest w porządku — dojedziesz, gdzie chcesz. Inni muszą wiedzieć, co tam warczy, i co jakiś czas zaglądają, czy wszystko na swoim miejscu. Lokalne AI ma miejsce dla obu. Ważne tylko, żeby wiedzieć, że pod każdą z tych błyszczących karoserii bije mniej więcej to samo serce — i że w każdej chwili możesz podnieść klapę i mu się przyjrzeć.

Bo entuzjazm sceny jest szczery, ale scena nie odpala tego modelu na twojej karcie. Ty odpalasz. I między „premiera na Hugging Face" a „gada u ciebie w terminalu tak, jak powinno" leży kilka pułapek, które regularnie kosztują ludzi wieczór. Dobra wiadomość: da się je odhaczyć w pięć minut, jeszcze zanim cokolwiek pobierzesz. Zrobimy z tego listę — taką, którą przejdziesz przy każdym kolejnym „SOTA", bo modeli będzie jeszcze wysyp.

Karta modelu, czyli tabliczka znamionowa

Zanim cokolwiek zrobisz — otwórz kartę modelu. Na Hugging Face to nie żaden osobny dokument, tylko plik README.md w repo, a na jego górze siedzi kawałek metadanych w YAML-u.¹ To jest tabliczka znamionowa: licencja, model bazowy, czasem gotowe wyniki ewaluacji. Cała ta lista, którą zaraz przejdziemy, w dużej mierze czyta się właśnie stamtąd. Nauczysz się rzucać okiem na te kilka pól i połowa niespodzianek znika, zanim się wydarzy.

Ile ten model waży i w jakim wariancie?

Pierwsze pytanie brutalnie praktyczne: czy to w ogóle wejdzie? Liczba parametrów (te 7B, 8B, 70B w nazwie) to grube przybliżenie apetytu na pamięć, ale w pełnej precyzji nawet „mały" 8B to kilkanaście giga. Dlatego naprawdę interesuje cię, czy istnieje wersja skwantyzowana — a konkretnie, czy ktoś zrobił już pliki GGUF, format, którego używają llama.cpp i Ollama.²

Kwantyzacja to nic innego jak zapisanie tych miliardów wag ciaśniej: mniej bitów na liczbę, mniejszy plik, mniejszy apetyt na VRAM, a jakość spada zaskakująco mało. Dokumentacja llama.cpp podaje wprost skalę: Llama-3.1-8B w formacie F16 waży jakieś 14,96 GiB, a ta sama w Q4_K_M — około 4,58 GiB.³ Trzy razy mniej, a Q4_K_M to poziom, który regularnie pada jako rozsądny kompromis rozmiar-jakość. Co znaczą wszystkie te literki i cyferki po Q, rozgryzaliśmy osobno tutaj.

Jedno małe ostrzeżenie, żeby nie pomylić pojęć: kwantyzacja po treningu (to, co dostajesz w GGUF-ie) to nie to samo, co trenowanie modelu od zera w niskiej precyzji. Dwie różne rzeczy, różny wpływ na jakość. Ktoś na scenie zawsze je pomiesza — nie bądź tym kimś.

Czy w ogóle wolno ci go użyć?

To pole, które ludzie przewijają najszybciej, a które potrafi najbardziej zaboleć. W metadanych karty jest license: — identyfikator licencji, po którym Hub nawet pozwala filtrować modele.¹ I tu jest haczyk: samo to, że repo jest otwarte i pliki leżą do pobrania, nie znaczy, że wolno ci na tym modelu zbudować cokolwiek komercyjnego.

Część modeli jedzie na licencjach „społecznościowych" albo „research only", które uśmiechają się otwarcie, a w treści ograniczają użycie. Gdy w polu widzisz license: other, to sygnał, żeby kliknąć w license_link i faktycznie przeczytać, na co się piszesz — bo identyfikator sam z siebie nic ci nie gwarantuje.¹ Nudne? Nudne. Ale to jedyny punkt z tej listy, który może się skończyć rozmową z prawnikiem, a nie z terminalem.

Jak długi kontekst realnie dostaniesz?

Model w karcie chwali się 128k kontekstu, więc bierzesz go do przełykania całych PDF-ów — i tu wpadasz w klasyczne nieporozumienie. Deklarowane maksimum modelu to jedno, a okno, które faktycznie ustawi ci runtime, to drugie.

Ollama na przykład sama dobiera domyślną długość kontekstu do tego, ile masz VRAM-u: przy mniej niż 24 GiB da ci 4k, a dopiero przy 48 GiB i więcej sięga nawet po 256k.⁴ Czyli twój wypasiony 128k model może po cichu chodzić na czterech tysiącach tokenów, a ty się dziwisz, czemu „zapomina" początek dokumentu. Wymusisz to zmienną OLLAMA_CONTEXT_LENGTH albo parametrem num_ctx:

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

A ustawić to okno możesz na kilka sposobów i jest wśród nich hierarchia: PARAMETER num_ctx w Modelfile ustala okno na stałe dla danego modelu, a opcje podane w locie w wywołaniu API nadpisują to, co siedzi w Modelfile.⁵ Tylko pamiętaj o dwóch kosztach: większe okno to znacznie więcej pamięci — dokumentacja Ollamy mówi to wprost — a siłą rzeczy także wolniejsze liczenie.⁴ Do tego rozciąganie okna ponad długość, na jakiej model trenowano, potrafi pogorszyć jakość odpowiedzi; dokładnie ten problem rozbraja mechanizm YaRN, który rozłożyliśmy na części tu. W llama.cpp tym samym oknem steruje flaga -c.

Czy narzędzie w ogóle to obsłuży?

Najboleśniejsza pułapka premierowa: model jest na Hugging Face, więc zakładasz, że od razu odpalisz go w llama.cpp czy Ollamie. A to wcale nie jest automatyczne. llama.cpp wymaga formatu GGUF, a jak model przychodzi w innym formacie, ktoś musi go najpierw skonwertować skryptami convert_*.py z repo (Hugging Face udostępnia do tego nawet przestrzeń „GGUF-my-repo").²

Gorzej, gdy model przynosi nową architekturę. Wtedy wsparcia po prostu nie ma, dopóki ktoś go nie dopisze — a to nie jest jedna linijka. Trzeba ruszyć skrypty konwersji w Pythonie (mapowanie tensorów, constants.py, tensor_mapping.py), potem kod C++ (llama-arch, llama-model-loader, llama-model, obsługa RoPE), a na koniec przetestować to na CPU, CUDA i Metalu.⁶ Dlatego dzień premiery modelu i dzień pierwszego działającego GGUF-a to często dwie różne daty. Jak śledzisz świeżynkę, sprawdź najpierw, czy w issues repo ktoś już nie ogarnia integracji — o tym, jak w ogóle działa ten cały ekosystem wokół GGUF-a, pisaliśmy osobno.

Instruct czy base? Sprawdź, zanim się zdziwisz

Widzisz w nazwie samo „Llama-3-8B" bez dopisku i myślisz, że pogadasz. Odpalasz, piszesz pytanie, a model zamiast odpowiedzieć — dopisuje kolejne pytania. Nie zepsuł się. Wziąłeś wersję base, która tylko kontynuuje sekwencję tokenów, zamiast wersji instruct/chat, douczonej do podążania za poleceniami i dialogiem.⁷

Różnica jest fundamentalna, a diabeł siedzi w formacie. Model czatowy oczekuje wiadomości opakowanych w konkretne tokeny kontrolne — u jednego to [INST]...[/INST], u innego <|user|> i <|assistant|> — i co gorsza, dwa modele dotrenowane z tej samej bazy mogą mieć zupełnie różny format czatu.⁷ Podasz zły — i instruct-model, który powinien świecić, nagle gada od rzeczy. W bibliotece transformers załatwia to apply_chat_template, który sam skleja wiadomości w format właściwy dla danego modelu.⁷ W llama.cpp odpowiada za to --jinja. Morał krótki: zajrzyj do karty i upewnij się, który to wariant, zanim ogłosisz, że „model jest słaby".

Benchmarki? Tak, ale z ręką na sercu

I na koniec ta tabelka, przez którą w ogóle klikasz „Download" — słupki, w których nowy model bije wszystko dookoła. Model card może nawet nieść ustrukturyzowane wyniki w polu model-index, z zadaniem, datasetem, metryką i źródłem.¹ Fajnie. Tylko traktuj to jak deklarację producenta, nie jak wyrok.

Jest udokumentowany problem zwany benchmark data contamination: dane testowe benchmarku wyciekają do zbioru treningowego modelu, przez co wynik na tym teście rośnie bez realnej poprawy jakości.⁸ Model po prostu „widział odpowiedzi" na egzaminie. To nie teoria spiskowa — poświęcono temu prace przeglądowe. Dlatego liczba w tabelce mówi ci co najwyżej, że warto sprawdzić samemu na swoim zastosowaniu, a nie że sprawa zamknięta. Najlepszy benchmark i tak jest jeden: twój własny prompt, którego nikt nie mógł wcześniej wkuć.

Zrób to sam: lista na lodówkę

Cała ta gadka sprowadza się do sześciu spojrzeń w kartę modelu, zanim ruszysz pobieranie:

Wydrukuj, przyklej nad biurkiem, albo po prostu zapamiętaj rytm: waga, licencja, kontekst, wsparcie, wariant, benchmarki. Przy trzecim nowym modelu przejdziesz to odruchowo.

Bo świeży model to trochę jak używane auto z ogłoszenia: zdjęcia lśnią, opis zachwala, scena piszczy z zachwytu. Ale to ty siadasz za kierownicą i to ty potem stoisz na poboczu, jak się okaże, że pod maską nie ma silnika pasującego do twojej karty. Pięć minut zaglądania pod maskę — kartę modelu — kosztuje mniej niż wieczór klikania w „czemu to nie dział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.