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

To wręcz podręcznikowy scenariusz — ktoś odpala 7B na karcie 8 GB, chwali się, że działa, a dwa dni później wraca z płaczem, że „przy dłuższym kontekście się sypie". I zawsze pada to samo pytanie w komentarzach: a ustawiłeś sobie cache? No właśnie. Bo obok wag, które raz się ładują i grzecznie leżą, siedzi drugi żłob na VRAM — taki, który rośnie z każdym słowem, jakie model przeczyta albo napisze. Nazywa się KV-cache i jest głównym podejrzanym w prawie każdej sprawie „mieściło się, a potem przestało".

Skąd w ogóle bierze się ten cache

Cofnijmy się o krok. Model generuje tekst token po tokenie — jeden na raz, a każdy kolejny patrzy wstecz na całą dotychczasową historię. Żeby policzyć uwagę (attention) dla nowego tokenu, potrzebuje wektorów K (key) i V (value) dla wszystkiego, co było wcześniej. I teraz klucz do zrozumienia: te wektory się nie zmieniają. K i V dla trzeciego tokenu są takie same, kiedy generujesz token dziesiąty, jak wtedy, gdy generowałeś czwarty.

Skoro się nie zmieniają — po co je liczyć od nowa przy każdym kroku? No i nie liczymy. KV-cache to dokładnie ten bufor, w którym model odkłada raz wyliczone wektory K i V dla każdego przetworzonego tokenu, w każdej warstwie, żeby przy generowaniu następnego nie przemielać całej historii od zera.¹ To sprytny handel: dokładasz pamięci, żeby oszczędzić obliczenia. Bez niego każdy nowy token oznaczałby przeliczanie całego kontekstu w kółko — decode zamieniłby się w mękę.

Cache jest więc dobry. Problem w tym, że za oszczędność obliczeń płacisz pamięcią. A ta pamięć nie jest stała.

Dlaczego on rośnie, a wagi nie

Tu jest sedno całej sprawy, więc rozłóżmy to powoli. Wagi modelu to wartość stała. Ładujesz plik GGUF raz, siada na karcie i tyle — czy generujesz jeden token, czy dziesięć tysięcy, wagi zajmują dokładnie tyle samo. KV-cache zachowuje się odwrotnie: puchnie z każdym tokenem, jaki wpadnie w okno kontekstu.¹

Ile dokładnie puchnie? Mechanizm da się złapać jednym wzorem, który krąży po całej scenie:

rozmiar_KV = 2 × n_layer × n_kv_heads × head_dim × długość_kontekstu × bajty_na_element

Rozbierzmy to na palcach. Dwójka na przedzie to osobno tensor K i osobno tensor V — trzymasz dwa, stąd współczynnik.¹ n_layer to liczba warstw transformera; cache odkłada się w każdej z osobna. n_kv_heads to liczba głów KV, head_dim to wymiar jednej głowy. A długość_kontekstu — no i tu jest pies pogrzebany: to jedyny człon, który rośnie w trakcie. Reszta to stałe architektury danego modelu.

Zauważ, co z tego wynika: rozmiar cache rośnie liniowo z długością kontekstu. Podwoisz kontekst — podwoisz cache. I liniowo z liczbą warstw oraz głów KV. Ani razu w tym wzorze nie pada rozmiar wag.¹ To dwa niezależne budżety pamięci.

Skoro cache rośnie z kontekstem, a wagi stoją w miejscu, to przy dostatecznie długim oknie następuje przecięcie: KV-cache zaczyna dominować zużycie VRAM, a przy naprawdę długim kontekście potrafi przerosnąć rozmiar samych wag.¹ I stąd twoje out of memory w połowie rozmowy — nie model spuchł, tylko jego pamięć krótkotrwała napęczniała do rozmiarów, których karta nie udźwignęła. Jeśli chcesz policzyć ten budżet z wyprzedzeniem, zamiast zgadywać, sam wzór na VRAM rozkładaliśmy krok po kroku tutaj.

Jak go ścisnąć — trzy dźwignie

Dobra wiadomość: skoro wiesz, z czego składa się wzór, wiesz też, gdzie przyłożyć. Masz trzy dźwignie, każda ciągnie za inny człon.

Kwantyzacja cache — najprostszy zysk

Spójrz na ostatni człon wzoru: bajty_na_element. Domyślnie cache K i V w llama.cpp siedzą w f16, czyli po 2 bajty na element² — a czym f16 różni się od bf16, tłumaczymy tutaj. A nikt nie powiedział, że musi tak zostać. llama.cpp daje dwie flagi — -ctk (--cache-type-k) i -ctv (--cache-type-v) — którymi ustawiasz typ danych osobno dla cache K i cache V. Dozwolone wartości to f32, f16, bf16, q8_0, q4_0, q4_1, iq4_nl, q5_0, q5_1; domyślnie oba stoją na f16.²

Matematyka jest tu boleśnie prosta. q8_0 to 1 bajt na element zamiast dwóch — czyli z grubsza dwa razy mniej pamięci na cache. q4_0 to pół bajta — jakieś cztery razy mniej niż f16.³ Nie podam ci, ile to konkretnie megabajtów, bo to zależy od n_layer, n_kv_heads, head_dim i długości kontekstu twojego modelu — kto rzuca sztywnym „zaoszczędzisz 3 GB", ten zgaduje. Ale proporcja trzyma się zawsze: ścinasz typ, ścinasz cache w tym samym stosunku.

llama-server -m model-q4_k_m.gguf -c 8192 -fa on -ctk q8_0 -ctv q8_0

I tu ważne rozróżnienie, na którym potyka się pół forum: to nie jest to samo, co kwantyzacja wag. Wagi kwantyzujesz przy pakowaniu GGUF-a (te wszystkie Q4_K_M i spółka — nazewnictwo rozbieraliśmy tutaj). Cache kwantyzujesz flagami runtime, w locie. To dwa niezależne mechanizmy. Ściśnięcie wag do 4 bitów ani o bajt nie zmniejszy KV-cache, i odwrotnie. Ktoś odpala model w Q4_K_M i dziwi się, że kontekst dalej zjada pamięć — no bo cache dalej siedzi w f16, dopóki mu tego ręcznie nie zmienisz.

Flash attention — i warunek wstępny

Druga dźwignia to -fa (--flash-attn). Flaga przyjmuje on, off albo auto, domyślnie stoi na auto.² Co robi flash attention? To nie żadne przybliżenie uwagi — i tu kolejna pułapka do ominięcia. FlashAttention (Dao i in., NeurIPS 2022) to algorytm dokładny (exact): liczy dokładnie to samo, co naiwna uwaga, wynik liczbowy jest identyczny.⁴ Sztuczka jest gdzie indziej — jest „IO-aware", czyli ogranicza liczbę odczytów i zapisów między wolną pamięcią HBM karty a szybką pamięcią on-chip SRAM. Efekt: szybciej i z mniejszym narzutem pamięci pomocniczej niż naiwna implementacja uwagi.

Ale flash attention ma tu jeszcze jedną, praktyczną rolę — jest warunkiem wstępnym kwantyzacji cache V. W llama.cpp nie da się skwantyzować cache V bez włączonego flash attention; implementacja zwyczajnie odmawia startu, rzucając runtime error w rodzaju quantized V cache was requested, but this requires Flash Attention.⁵ Czyli jeśli chcesz -ctv q8_0, musisz najpierw dać -fa on. Bez tego dostaniesz błąd, nie oszczędność.

GQA — dźwignia, której nie przełączysz

Trzeci człon wzoru to n_kv_heads. Im mniej głów KV, tym mniejszy cache — wprost, liniowo. I dokładnie na to celuje Grouped-Query Attention (GQA, Ainslie i in., EMNLP 2023).⁶ Idea: zamiast tylu głów KV, ile jest głów zapytań (pełna uwaga wielogłowowa, MHA), albo tylko jednej wspólnej (multi-query attention, MQA), bierzesz liczbę pośrednią. Kilka głów zapytań dzieli jedną głowę KV. Skoro n_kv_heads w naszym wzorze spada — spada i cache, przy jakości bliskiej pełnemu MHA i szybkości bliskiej MQA.⁶

Co ciekawe, model GQA nie powstaje od zera. Bierze się istniejący checkpoint MHA i „doucza" (uptraining) przy jakichś 5% oryginalnego budżetu treningu — tanio, bez budowania nowej architektury od podstaw.⁶

Jest tylko jeden haczyk, o którym musisz pamiętać: GQA to nie przełącznik. To cecha architektury zapieczona w modelu podczas treningu. Nie ma flagi CLI, która „włączy GQA" na dowolnym modelu. Możesz co najwyżej wybrać model, który już ma GQA — a większość nowszych 7B/8B ma — i taki z natury nosi mniejszy cache przy tej samej długości kontekstu co stary model z pełnym MHA. To kryterium przy pobieraniu, nie pokrętło w terminalu.

Zrób to sam: kolejność ratowania pamięci

No dobra, dość teorii — masz out of memory i chcesz uratować kontekst. Kolejność ma znaczenie, bo pierwsze ruchy kosztują cię grosze na jakości, a ostatnie bolą.

1. Najpierw -fa on. Ścina narzut pamięci samej operacji uwagi i — co równie ważne — odblokowuje kwantyzację cache V. To krok zero, nie negocjujemy.⁵
2. Potem skwantyzuj cache: -ctk q8_0 -ctv q8_0. q8_0 to bezpieczny wybór — połowa pamięci cache, strata jakości ledwo wyczuwalna. Dopiero gdy VRAM dalej piszczy, schodź do -ctk q4_0 -ctv q4_0 — ćwiartka pamięci, ale za to już płacisz odczuwalniej jakością.³
3. Wybierając model, celuj w te z GQA. Tego nie zrobisz flagą po fakcie — to decyzja przy pobieraniu. Model z GQA startuje z mniejszym cache, zanim jeszcze dotkniesz jakiegokolwiek przełącznika.⁶

# krok 1 + 2 razem — tak wygląda ratunek w praktyce
llama-server -m model-q4_k_m.gguf -c 16384 \
  -fa on -ctk q8_0 -ctv q8_0

Dopiero kiedy to wszystko wyczerpiesz, a i tak nie wchodzi — wtedy tnij samą długość kontekstu (-c) albo schodź z warstw na GPU (-ngl). Ale to już ostatnia deska ratunku, bo pierwsze odbiera modelowi pamięć, a drugie prędkość. Sam zestaw flag i to, co która robi, przeszliśmy po kolei w osobnym wpisie o flagach llama.cpp.

Pomyśl o tym tak. Wagi modelu to biblioteka — stoi w regale, zajmuje swoje półki i tyle, nieważne, ile razy do niej zajrzysz. KV-cache to biurko, na którym rozkładasz wszystko, co akurat czytasz. Im dłużej pracujesz nad jednym tematem, tym więcej kartek ląduje na blacie — i w pewnym momencie nie ma gdzie postawić kubka, choć regał ani drgnął. Kwantyzacja cache to składanie tych kartek na pół, flash attention to sprzątanie w locie, GQA to od razu mniejszy stos notatek na tę samą robotę.

Karta się nie skurczyła. To po prostu twoja rozmowa urosła — a teraz już wiesz, który człon wzoru za to odpowiada i za które pokrętło pociągnąć, zanim znów zobaczysz to out of memory.

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

I tu pojawia się pytanie, które w dyskusjach o lokalnych modelach wraca co tydzień jak bumerang: „to jak zrobić, żeby model gadał o MOICH danych?". Pierwszy odruch połowy internetu to „dotrenuj go". Zły odruch — o tym za chwilę. Odruch drugi, ten dobry, to trzy litery: RAG.

Co to właściwie jest ten RAG

RAG — retrieval-augmented generation, czyli generowanie wspomagane wyszukiwaniem — to pomysł starszy, niż się wydaje. Opisali go Lewis i spółka w pracy z 2020 roku, jeszcze zanim „chatbot" wszedł pod strzechy.¹ Idea jest sprytnie prosta: zamiast upychać całą wiedzę świata w wagach modelu (to autorzy nazywają pamięcią parametryczną — wszystko, co model „umie z głowy"), doklejasz mu drugą pamięć — nieparametryczną. U Lewisa był to gęsty indeks wektorowy całej Wikipedii, przeszukiwany przez osobny model-wyszukiwarkę. Model najpierw pobiera pasujące fragmenty, a dopiero potem generuje odpowiedź, patrząc na to, co znalazł.

Przełóż to na twój folder z PDF-ami. Nie douczasz modelu, że kartę kupiłeś za tyle a tyle. Ty w momencie zadawania pytania podsuwasz mu odpowiedni kawałek faktury i mówisz: „odpowiedz na podstawie tego". Model dostaje ściągę tuż przed odpowiedzią. Cała sztuka w tym, żeby z trzystu PDF-ów wyłuskać akurat ten jeden akapit, który pasuje — i zrobić to w ułamku sekundy.

Jak to się spina, krok po kroku

No dobra, „wyłuskać pasujący akapit" brzmi ładnie, ale jak maszyna ma wiedzieć, co pasuje do „ile płaciłem za kartę"? Rozłóżmy łańcuch na części, bo on ma dokładnie cztery ogniwa i każde robi jedną robotę.

Raz — chunking. Dzielisz dokumenty na kawałki (chunki). Nie wrzucasz całego 40-stronicowego PDF-a jako jednej bryły, tylko tniesz na fragmenty po parę zdań. I tu pierwsza pułapka, w którą wpada każdy na starcie: cięcie na sztywno co X znaków. Utniesz w połowie zdania, w połowie tabelki z cenami — i fragment traci sens, a razem z nim traci sens jego reprezentacja. Podział semantyczny (po akapitach, sekcjach, zdaniach) jest nudniejszy w implementacji, ale retrieval potem dziękuje.

Dwa — embeddingi. Każdy chunk przepuszczasz przez model embeddingowy — osobny, mały model, który zamienia tekst w wektor liczb, czyli osadzenie (embedding). Sęk w tym, że te wektory układają się w przestrzeni tak, że teksty o podobnym znaczeniu lądują blisko siebie. „Zapłaciłem 1400 zł za RTX-a" i „koszt karty graficznej wyniósł" wylądują obok, mimo że nie mają wspólnego słowa. To jest serce całej zabawy.

Dwa modele, które na lokalnej scenie widać najczęściej:

nomic-embed-text-v1.5 ma jedną fajną sztuczkę — Matryoshka Representation Learning: natywnie robi wektor 768-wymiarowy, ale możesz go przyciąć w dół, choćby do 64 wymiarów, tracąc na jakości zaskakująco mało.² Mniejszy wektor to mniejsza baza i szybsze wyszukiwanie. bge-m3 gra w inną grę — ogarnia ponad sto języków (czyli i polski), a przy okazji jeden model daje ci trzy tryby wyszukiwania naraz: gęsty, leksykalny i wielowektorowy w stylu ColBERT.³ Do tego drugiego zaraz wrócimy.

Trzy — baza wektorowa. Te wszystkie wektory trzeba gdzieś trzymać i umieć szybko przeszukać. Tu masz dwa światy. Z jednej strony FAISS od Meta — biblioteka do wyszukiwania podobieństwa w gęstych wektorach, z całym menu typów indeksu: IndexFlatL2 (dokładne przeszukanie wszystkiego), IVF (partycjonowanie na kubełki), HNSW (grafy nawigacyjne) czy Product Quantization (stratna kompresja wektorów).⁴ Szybka i potężna, ale sama z siebie nie trzyma metadanych ani nie martwi się trwałością — to silnik, nie baza. Z drugiej strony Chroma — pełna baza wektorowa open source, która obok embeddingów przechowuje metadane, filtruje po nich, wspiera wyszukiwanie gęste, rzadkie i hybrydowe, i którą odpalisz lokalnie jednym importem.⁵ Mylenie tych dwóch to klasyk: FAISS da ci surową prędkość, Chroma da ci wygodę i „ten dokument jest z folderu faktury, rok 2025".

Cztery — retrieval i wstrzyknięcie kontekstu. Użytkownik pyta. Ty liczysz embedding pytania (z prefiksem search_query: , pamiętasz?), baza zwraca ci top-k najbliższych chunków — powiedzmy trzy albo pięć najbardziej pasujących — a ty wklejasz je do promptu tuż przed pytaniem. To jest to całe context injection: „Oto fragmenty z dokumentów: […]. Na ich podstawie odpowiedz: ile płaciłem za kartę?". Model generuje odpowiedź warunkowaną na tym, co mu podsunąłeś. Koniec łańcucha.

I tu druga pułapka, na którą łapie się nawet ogarnięty ludek: „skoro więcej kontekstu = lepiej, to wezmę top-k równe 20". Nie. Nadmiar fragmentów rozmywa uwagę modelu, zapycha okno kontekstu i topi ten jeden trafny akapit w morzu luźno pasujących. Mniej, ale celniej. Stąd zresztą pomysł na re-ranking — najpierw baza wyławia dwadzieścia kandydatów, a osobny model-sędzia przestawia je i oddaje ci trzy najlepsze. Twórcy bge-m3 wprost zalecają łączyć jego tryby hybrydowo i dokładać re-ranker, jak zależy ci na maksymalnej jakości.³

Czego RAG NIE robi (i dlaczego to ważne)

Wróćmy do tego „złego odruchu" z początku. RAG nie douczy modelu. Nie dotyka jego wag, nie zaszywa wiedzy na stałe. Podaje kontekst w czasie inferencji — i tyle. Wywal dokument z bazy wektorowej, a model „zapomina" go w tej samej sekundzie, bo nigdy naprawdę go nie „zapamiętał". To zupełnie inna bajka niż fine-tuning, gdzie modyfikujesz parametry i żeby zaktualizować wiedzę, musisz przepuścić model przez kolejny trening — techniki pokroju QLoRA rozbieraliśmy tutaj. Prosta zasada na później: wiedza, która się zmienia albo jest prywatna → RAG. Zachowanie, styl, format odpowiedzi → fine-tuning.

I jeszcze jedno, żebyś nie wyszedł z fałszywym poczuciem bezpieczeństwa: RAG nie gwarantuje braku halucynacji. Podsuniesz modelowi trafny akapit, a on i tak potrafi go zignorować albo przekręcić. Redukujesz ryzyko, nie kasujesz go do zera. No i pamiętaj, że te embeddery mają okno 8192 tokenów — wrzucisz dłuższy dokument bez dzielenia, a końcówka po prostu zostanie obcięta i nigdy nie trafi do bazy.

Zrób to sam

Najfajniejsze w lokalnym RAG-u jest to, że embeddingi policzysz tym samym llama.cpp, którym odpalasz zwykły model — flagi rozbieraliśmy osobno. Ściągasz GGUF-a z nomikiem i odpalasz serwer z jedną dodatkową flagą:

llama-server -m nomic-embed-text-v1.5.Q8_0.gguf \
  --embeddings \
  --host 0.0.0.0 --port 8080

--embeddings przełącza llama-server w tryb liczenia wektorów.⁶ Potem strzelasz do niego jak do zwykłego API — i tu drobiazg, o który łatwo się potknąć: endpoint /embeddings obsługuje wszystkie tryby poolingu, łącznie z --pooling none (wektor per token), natomiast zgodny z OpenAI /v1/embeddings wymaga poolingu innego niż none.⁶

curl http://localhost:8080/v1/embeddings \
  -H "Content-Type: application/json" \
  -d '{"input": "search_document: RTX 4070, faktura, 2799 zł"}'

Widzisz ten search_document: wklejony w treść? To nie ozdoba — to ten prefiks, bez którego nomic liczy nie to, co trzeba. Dostajesz z powrotem wektor 768 liczb, wsadzasz go do Chromy albo FAISS-a razem z oryginalnym tekstem i metadanymi, i powtarzasz dla każdego chunka. Zapytanie liczysz identycznie, tylko z prefiksem search_query: . Cały lokalny RAG to te cztery ogniwa spięte skryptem na sto linijek — reszta to strojenie.

Kończąc, wyobraź to sobie tak: fine-tuning jest jak wysłanie modelu z powrotem do szkoły, żeby na nowo wykuł materiał. RAG to podanie mu otwartej książki tuż przed egzaminem — z zakładką na właściwej stronie. Model dalej jest tym samym modelem, wagi ani drgną. Zmienia się tylko to, że tym razem nie musi zgadywać, ile płaciłeś za tę kartę. Ma to czarno na białym, w akapicie, który sam mu podsunąłeś.

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

No i tu jest cały myk: prośba w prompcie to prośba. Model może ją spełnić albo nie, bo prompt to tylko sugestia w tekście. A gramatyka GBNF to coś zupełnie innego — to kaganiec założony na sampler. Nie mówisz modelowi „bądź tak miły i zwróć JSON". Ty mu fizycznie nie pozwalasz wygenerować tokenu, który by JSON-a psuł. Różnica jak między „proszę, nie wychodź poza linie" a kartką do kolorowania, w której poza liniami po prostu nie ma gdzie pociągnąć kredką.

O co chodzi z GBNF

GBNF (GGML BNF) to format gramatyki formalnej, którym llama.cpp ogranicza — po angielsku constrain — to, co model może wygenerować.¹ Nazwa zdradza rodowód: to wariant BNF-a, tej samej notacji, którą od dekad opisuje się składnię języków programowania. Piszesz zestaw reguł „co po czym może stać", a silnik pilnuje, żeby wyjście trzymało się tych reguł znak po znaku, token po tokenie.

W praktyce masz dwie drogi do tego samego celu. Albo piszesz gramatykę GBNF ręcznie i podajesz ją flagą --grammar (wprost jako string) lub --grammar-file (z pliku).² Albo, jeśli myślisz kategoriami JSON Schema, podajesz schemat flagą -j / --json-schema — a llama.cpp sam przemieli go wewnętrznie na GBNF funkcją json_schema_to_grammar.² Do tego jest bliźniacza para -jf / --json-schema-file, gdy schemat wolisz trzymać w pliku. Efekt końcowy ten sam: pod spodem i tak rządzi gramatyka.

Jak to w ogóle działa pod maską?

Skoro model niczego nie widzi w prompcie, to skąd wie, że ma trzymać się formatu? Nie wie. I to jest piękne. Cała robota dzieje się piętro niżej, w samplerze — komponencie, który po każdym przejściu przez sieć wybiera następny token z rozkładu prawdopodobieństw.

Przypomnij sobie, jak model generuje. Sieć wypluwa logity — po jednej liczbie na każdy token ze słownika, im wyższa, tym „chętniej" model by go postawił. Normalnie sampler bierze tę tablicę kandydatów (llama_token_data_array) i losuje z niej według reguł temperatury, top-p i reszty pokręteł, które rozgryzaliśmy tutaj. Gramatyka wciska się dokładnie w to miejsce, tuż przed losowaniem. Funkcja llama_grammar_apply_impl przechodzi po całej tablicy kandydatów i każdemu tokenowi, który nie pasuje do gramatyki, ustawia logit na -inf.³ Minus nieskończoność to wyrok: taki token ma po softmaksie prawdopodobieństwo zero, więc sampler nie ma prawa go wybrać, choćby model bardzo chciał. To właśnie maskowanie logitów — zerowanie szans tokenów niezgodnych z regułami.

A skąd gramatyka wie, co „pasuje" akurat teraz? Trzyma stan. I to nie jeden stan, tylko cały zbiór jednoczesnych stosów — klasyczny automat ze stosem (pushdown automaton). Każdy stos to jedna możliwa ścieżka przez gramatykę, zgodna z tym, co model wygenerował do tej pory. Token przeżywa tylko wtedy, gdy pasuje do terminala na szczycie któregokolwiek z aktywnych stosów — jeśli nie pasuje do żadnego, dostaje -inf i wypada.³ Kiedy token już zostanie wybrany, llama_grammar_accept przesuwa stan gramatyki po zaakceptowanych znakach, stosy się aktualizują, część ścieżek umiera, część zostaje — i cała zabawa leci od nowa przy następnym tokenie.³

Wyobraź sobie to jak korytarz z bramkami. Model na każdym kroku pcha się we wszystkie drzwi naraz, a gramatyka trzyma przy każdych strażnika, który przepuszcza tylko wtedy, gdy za drzwiami jest legalna kontynuacja. Model nie musi znać planu budynku — i tak nie skręci w ślepy zaułek, bo tamtędy fizycznie nie da się przejść.

Składnia w pigułce

GBNF wygląda znajomo dla każdego, kto liznął kiedyś opis gramatyki. Reguła to nonterminal ::= sekwencja. Klocki, z których się to składa:¹

• Terminale — literały w cudzysłowach ("1", "true") albo zakresy znaków w nawiasach kwadratowych ([0-9], [a-zA-Z]), z negacją przez ^ ([^"] = cokolwiek poza cudzysłowem).
• Operatory powtórzeń — * (zero lub więcej), + (jeden lub więcej), ? (opcjonalnie), oraz precyzyjne {m}, {m,}, {m,n} (dokładnie / co najmniej / od–do).
• Alternatywy przez | i grupowanie przez ( ) — dokładnie jak w regexpach.
• Unicode w komplecie, z ucieczkami \xXX (8-bit), \uXXXX (16-bit) i \UXXXXXXXX (32-bit), więc polskie znaki czy emoji nie są problemem.

Jest też smaczek, którego regexp nie ma: GBNF potrafi dopasowywać po konkretnych tokenach tokenizera, nie po znakach. <[1000]> to token o ID 1000, <think> to token o dokładnym tekście think, a !<...> to negacja.¹ Przydaje się, gdy chcesz np. sterować sekcjami <think>...</think> u modeli rozumujących — operujesz wtedy na realnych tokenach, a nie zgadujesz, jak model potnie tekst.

Jedna pułapka na start: nazwy nieterminali piszemy małymi literami z myślnikami (item-name-kv), nie camelCase i nie z podkreślnikami. Tak jest w oficjalnych przykładach i tego się trzymaj.¹

Mały przykład od zera

Powiedzmy, że chcesz z modelu wyciągnąć obiekt z polem name (tekst) i age (liczba). Minimalna gramatyka, w duchu przykładu z oficjalnego README:¹

root   ::= "{" ws "\"name\":" ws string "," ws "\"age\":" ws number ws "}"
string ::= "\"" char{1,100} "\""
char   ::= [^"\\]
number ::= [0-9]+
ws     ::= [ \t\n]*

Czyta się to prawie jak zdanie: korzeń to klamra, w środku pole name ze stringiem od 1 do 100 znaków, przecinek, pole age z liczbą, klamra zamykająca — a ws to opcjonalne białe znaki, żeby model mógł sobie ładnie wciąć. Podajesz to modelowi i już na poziomie samplera nie ma opcji, żeby zaczął od „Oto JSON:". Pierwszy token, który wolno postawić, to {. Kropka. Cała reszta korytarza jest zamknięta.

Odpalasz to najprościej tak — gramatyka wprost w linii poleceń:

llama-cli -m qwen2.5-7b-instruct-q4_k_m.gguf \
  --grammar 'root ::= "{" "\"ok\":" ("true" | "false") "}"' \
  -p "Czy 7 jest liczbą pierwszą? Odpowiedz." -no-cnv

Albo, gdy myślisz schematami, oddajesz robotę konwerterowi. --json-schema '{}' przyjmie dowolny JSON, a węższy schemat zawęzi wyjście:²

llama-cli -m qwen2.5-7b-instruct-q4_k_m.gguf \
  --json-schema '{"type":"object","properties":{"pierwsza":{"type":"boolean"}},"required":["pierwsza"]}' \
  -p "Czy 7 jest liczbą pierwszą?" -no-cnv

--grammar czy --json-schema? To nie to samo

Łatwo je pomylić, bo cel jest jeden, ale wejście zupełnie inne. Ściągawka:

Mechanizm wykonawczy w obu wypadkach ten sam: pod spodem i tak powstaje GBNF, który maskuje logity. To dwa różne wejścia do tej samej maszyny.

I ten haczyk z $ref: jeśli twój schemat JSON Schema wciąga zewnętrzne referencje ($ref do innych plików), --json-schema może się na tym wyłożyć. Oficjalna dokumentacja radzi wtedy wygenerować GBNF offline skryptem examples/json_schema_to_grammar.py, zapisać do pliku i podać go przez --grammar-file.⁴ Rozdzielasz konwersję od inferencji — najpierw w spokoju robisz gramatykę, potem karmisz nią model.

Gramatyka pilnuje składni, nie sensu

Zanim uwierzysz, że rozwiązałeś wszystkie problemy świata — jedno trzeźwiące zastrzeżenie. Gramatyka gwarantuje ci poprawną składnię, nie semantykę. Wymusisz, że age to liczba — ale nic nie broni modelowi wpisać tam 999, jeśli akurat tak mu wyjdzie z rozkładu. Wymusisz strukturę odpowiedzi RAG-owej — ale nie to, że treść w polach będzie prawdziwa; o samym łączeniu wyszukiwania z generacją pisaliśmy tutaj. GBNF ogranicza dopuszczalne sekwencje tokenów, a nie sens tego, co w nich siedzi. To kaganiec na formę, nie na głupoty. Walidację wartości i logikę trzymaj po swojej stronie, tak jak trzymałeś ją zawsze.

Zrób to sam: przez serwer

Na co dzień najwygodniej pchać to przez llama-server. Endpoint /completion przyjmuje w body te same dwa parametry co CLI: grammar (tekst GBNF) oraz json_schema (schemat JSON), oba domyślnie puste.⁵ Odpalasz serwer raz:

llama-server -m qwen2.5-7b-instruct-q4_k_m.gguf -ngl all -c 8192 --port 8080

i strzelasz do niego z gramatyką w środku:

curl -s http://localhost:8080/completion -d '{
  "prompt": "Wygeneruj kartę postaci.",
  "grammar": "root ::= \"{\" \"\\\"imie\\\":\" \"\\\"\" [a-zA-Z]+ \"\\\"\" \"}\""
}'

Jak wsadzisz gramatykę z błędem składni, serwer nie udaje, że jest dobrze — odbija żądanie z HTTP 400 i komunikatem Failed to parse grammar.⁵ To dobra wiadomość: literówkę w regule wyłapiesz od razu, na etapie parsowania, a nie po godzinie zastanawiania się, czemu wyjście wygląda dziwnie. Gotowe przykłady GBNF — w tym pełną gramatykę dla tablicy obiektów JSON — znajdziesz w katalogu grammars/ w repo ggml-org/llama.cpp.¹

Bo cała ta zabawa sprowadza się do jednej zmiany perspektywy. Przestajesz błagać model o dobry format i zaczynasz mu ten format wytyczać — nie słowami w prompcie, których i tak może nie usłuchać, tylko ścianami korytarza, którymi go prowadzisz. Model dalej myśli, co chce. Po prostu wyjściem z tego myślenia jest już tylko ta jedna furtka, którą sam mu zostawiłeś otwartą.

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