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 to jest jedno z tych przekonań, które żyje własnym życiem, choć z prawdą ma niewiele wspólnego. Bo llama.cpp — silnik, na którym stoi pół tego lokalnego światka — od samego początku był pisany pod jedną obietnicę: odpalać modele „na szerokim zakresie sprzętu", lokalnie i w chmurze, w czystym C/C++ bez ciężkich zależności.¹ CUDA jest w tym zestawie, jasne. Ale jest jedną z kilkunastu opcji, nie warunkiem wejścia.

Co to w ogóle jest „backend"

Zajrzyj pod maskę llama.cpp, a znajdziesz ggml — bibliotekę, która robi całą matematykę modelu. I tu wchodzi słowo klucz: backend. To po prostu moduł ggml, który wie, jak wykonać te wszystkie mnożenia macierzy na konkretnym rodzaju sprzętu. Jeden backend gada z układem NVIDIA. Inny z GPU Apple. Jeszcze inny z byle czym, co ma sterownik Vulkana.

Domyślnym, zawsze dostępnym backendem jest CPU. Zwykły procesor, ten sam, na którym odpalasz przeglądarkę. Zbudujesz llama.cpp bez ani jednej flagi akceleracji i model i tak ruszy — wolniej niż na GPU, ale ruszy.² To jest ta część, o której cała ta litania zapomina wspomnieć: żeby cokolwiek pogadało lokalnie, karta graficzna nie jest ci technicznie potrzebna. Jest ci potrzebna, żeby było szybko. A to już zupełnie inna rozmowa.

Ilu tych backendów w ogóle jest?

Więcej, niż podejrzewasz. Oficjalna tabela w README ciągnie się przez kilkanaście pozycji: Metal, BLAS, SYCL, CUDA, HIP, Vulkan, MUSA, CANN, OpenCL, ZenDNN, WebGPU, IBM zDNN, Hexagon i jeszcze parę egzotów.¹ Większości z nich w życiu nie dotkniesz — Ascend NPU czy IBM Z & LinuxONE to sprzęt, którego nie trzymasz pod biurkiem. Ale te, które realnie decydują o tym, czy twój sprzęt załapie się na zabawę, dają się policzyć na palcach:

Zanim pójdziemy dalej — jedna rzecz, która lubi umykać, a jest w tym wszystkim kluczowa. Te flagi z -D na przedzie to opcje budowania, czyli kompilacji. llama.cpp bierzesz w postaci kodu źródłowego i raz zamieniasz go w gotowy program — tym właśnie jest budowanie, a robi to cmake. I to na tym etapie, przed pierwszym uruchomieniem, mówisz, jakie backendy wkompilować. Nie podajesz -DGGML_CUDA=ON przy odpalaniu modelu — podajesz to raz, zanim plik wykonywalny w ogóle powstanie. Potem uruchamiasz już gotową binarkę, a ona z góry wie, na czym ma liczyć.

Przejdźmy tę listę tak, jak się ją czyta w praktyce — od strony pytania „a co ja mam w obudowie".

Masz NVIDIA? No to CUDA, ta zamknięta platforma obliczeniowa NVIDIA, która działa tylko na ich kartach. Włączasz ją flagą -DGGML_CUDA=ON przy budowaniu.² To ta najbardziej wydeptana ścieżka, o której wszyscy piszą — i faktycznie działa jak trzeba. Tylko że wydeptana nie znaczy jedyna.

Masz MacBooka na Apple Silicon? Tu jest najlepszy żart całej układanki: nie musisz robić absolutnie nic. Backend Metal — natywne API GPU Apple — jest na macOS włączony domyślnie. Budujesz llama.cpp normalnie i twój M2 czy M3 od razu liczy na GPU. Chcesz go z jakiegoś powodu wyłączyć? Musisz się wręcz postarać: -DGGML_METAL=OFF.² Zunifikowana pamięć w Makach robi tu robotę, o której właściciele osobnych kart mogą tylko pomarzyć.

Masz Radeona albo GPU Intela? I tu robi się najciekawiej, bo to dokładnie ci ludzie, których ta litania odprawia z kwitkiem. A mają aż dwie drogi.

Vulkan, czyli furtka dla całej reszty

Gdybym miał wskazać jeden backend, o którym za mało się mówi, to Vulkan. To otwarte, wieloplatformowe API graficzno-obliczeniowe (ta sama Khronos, co od OpenGL-a), które obsługuje mnóstwo sterowników GPU — NVIDIA, AMD, Intela. W llama.cpp włączasz je jedną flagą, -DGGML_VULKAN=ON, i dostajesz akcelerację GPU działającą cross-platform, na Windowsie, Linuksie i macOS naraz — bez instalowania dedykowanych, ciężkich stosów producenta.³

I to jest sedno. Bo alternatywą dla AMD jest HIP/ROCm — cały software’owy stos AMD do liczenia na GPU (HIP to interfejs w jego ramach, pozwalający pisać kod zbliżony do CUDA; to nie osobny produkt, tylko część tego samego ekosystemu). Bywa wydajniejszy od Vulkana, ale kosztuje cię więcej zachodu przy konfiguracji i samym budowaniu. Zobacz, jak to wygląda:

HIPCXX="$(hipconfig -l)/clang" HIP_PATH="$(hipconfig -R)" \
  cmake -S . -B build -DGGML_HIP=ON -DGPU_TARGETS=gfx1030 -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release

gfx1030 to nie ozdobnik — to kod architektury twojego konkretnego układu AMD, który musisz najpierw poznać i podać ręcznie.⁴ U Intela jest podobnie: backend SYCL (otwarty standard programowania heterogenicznego, którym Intel wozi swoje GPU przez oneAPI) ma na tyle osobną drogę budowania, że w repo doczekał się własnego pliku dokumentacji, obok głównego build.md.⁵ Nikt nie mówi, że to zabawa bez łzawienia. Ale że się da — da się.

A jeśli GPU w ogóle nie ma?

Zostaje CPU — i wcale nie jesteś skazany na gołą, referencyjną implementację. Masz BLAS (np. OpenBLAS), który przyspiesza obliczenia na procesorze i włącza się parą flag -DGGML_BLAS=ON -DGGML_BLAS_VENDOR=OpenBLAS.² A jak siedzisz na czymś bardziej konkretnym, llama.cpp ma nawet backendy skrojone pod rodzinę procesora: ZenDNN pod serwerowe CPU AMD EPYC i Arm KleidiAI pod układy Arm — obok generycznego CPU.² Mrówcza robota optymalizacyjna, o której mało kto wie, a która potrafi wycisnąć z krzemu, który już masz, zaskakująco dużo.

Zrób to sam

Powiedzmy, że budujesz llama.cpp sam (a warto — rozbieraliśmy jego flagi po kolei, bo to na nich jedzie pół ekosystemu, od Ollamy po LM Studio). Najprostszy build, sam CPU, bez żadnych ozdobników:

cmake -B build
cmake --build build --config Release

Chcesz akcelerację? Dokładasz jedną flagę pod swój sprzęt — -DGGML_CUDA=ON, -DGGML_VULKAN=ON, -DGGML_HIP=ON — i tyle. Co więcej, backendy da się łączyć w jednym buildzie (CUDA i Vulkan naraz to normalka), a którym urządzeniem policzysz, wybierasz już w locie, przy odpalaniu:

llama-cli --list-devices
llama-cli -m model.gguf --device Vulkan0
llama-cli -m model.gguf --device none

--list-devices pokaże ci wszystkie akceleratory, które build widzi, --device wskaże ten jeden, a --device none każe liczyć wyłącznie na CPU — wygodne, gdy chcesz zobaczyć, ile tracisz bez GPU.⁶ I jedno, co warto rozdzielić w głowie raz na zawsze: wybór backendu to nie to samo co kwantyzacja modelu. Format GGUF i to, czy bierzesz Q4 czy Q8 (nazwy rozbieraliśmy osobno), to jedna decyzja — na czym to policzysz to zupełnie druga. Ten sam plik .gguf pojedzie na CUDA, na Vulkanie i na gołym procesorze. Nie mieszaj tych dwóch pokręteł, bo to niezależne osie.

Cała aktualna prawda o budowaniu siedzi w jednym pliku: docs/build.md w repo ggml-org/llama.cpp. Sekcja po sekcji, backend po backendzie.

Bo ta redditowa litania „NVIDIA albo nic" to trochę jak stać przed budynkiem z jednymi oszklonymi drzwiami frontowymi, na które wszyscy się pchają, i nie wiedzieć, że dookoła jest jeszcze pięć wejść — węższych, gorzej oznaczonych, część z lekko zacinającą się klamką, ale prowadzących do tego samego środka. Zielona karta to najwygodniejsze drzwi. Nie jedyne.

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

W maju 2023 czterech badaczy z University of Washington tę szybę stłukło. Praca nazywa się QLoRA: Efficient Finetuning of Quantized LLMs, a jej główna teza brzmi jak przechwałka z forum: da się dostroić model 65B na jednej karcie 48 GB i zachować jakość pełnego, 16-bitowego fine-tuningu.¹ Nie „prawie", nie „z gwiazdką na jakości". Tak blisko, że w benchmarku różnicy praktycznie nie widać. Jak? Rozłóżmy to na części, bo cały trik jest piękny i składa się z kilku osobnych sprytów, które dopiero razem zaskakują.

Skąd się bierze ten cały VRAM

Zanim rozbijemy QLoRA na części, trzeba wiedzieć, na co przy treningu schodzi pamięć — bo to nie tylko same wagi. Klasyczny fine-tuning musi trzymać na karcie cztery rzeczy naraz: wagi modelu, gradienty (po jednej liczbie na każdą wagę), stany optymalizatora (Adam trzyma ich dwa na wagę) i aktywacje. Przy pełnym treningu w 16 bitach to znaczy, że sama arytmetyka optymalizatora potrafi zająć więcej niż sam model. Dlatego dotrenowanie „całego" modelu 65B to zabawa nie na jedną kartę, a na małą serwerownię.

Pierwszy pomysł, żeby to obejść, jest starszy od QLoRA i nazywa się LoRA (Low-Rank Adapters). Zamiast ruszać wszystkie miliardy wag, zamrażasz je w całości, a obok doklejasz malutkie, niskorangowe macierze — adaptery — i trenujesz tylko je. Nagle gradienty i optymalizator dotyczą ułamka parametrów. To już był przełom. Ale został jeden gruby kamień w bucie: zamrożone wagi bazowe i tak muszą siedzieć na karcie, żeby przez nie puścić forward i backward. A dla modelu 65B te zamrożone wagi w 16 bitach to wciąż jakieś 130 GB. Adaptery są tanie, ale bilet wstępu — sam model — dalej jest za drogi.

Trzy sprytne rzeczy, które robi QLoRA

I tu wchodzi sedno pracy. Skoro te wagi bazowe są zamrożone — nikt ich w treningu nie zmienia — to po co trzymać je w pełnej precyzji? QLoRA mówi: skwantyzujmy je do 4 bitów, zamroźmy je w tej postaci, a gradient przepuśćmy wstecz przez ten zamrożony 4-bitowy model prosto do adapterów LoRA.¹ Trenujemy dalej tylko adaptery — ale bilet wstępu właśnie schudł czterokrotnie. Żeby to zagrało bez utraty jakości, autorzy dorzucili trzy osobne patenty.²

Raz — NF4, czyli 4-bit NormalFloat. Nie wszystkie 4-bitowe typy danych są sobie równe. Wagi wytrenowanej sieci nie są rozrzucone byle jak — układają się mniej więcej w rozkład normalny, taką dzwonową górkę wokół zera. NF4 to typ danych skrojony dokładnie pod ten kształt, teoretycznie optymalny informacyjnie dla wag o rozkładzie normalnym. To ważne: NF4 nie jest zwykłym zmiennoprzecinkowym FP4 z IEEE. To specjalny format, który „marnuje" mniej z tych czterech bitów, bo wie z góry, gdzie wagi się tłoczą.²

Dwa — double quantization (podwójna kwantyzacja). Kwantyzacja blokowa musi gdzieś zapisać stałe skalujące — po jednej na blok wag. To drobne liczby, ale jak masz ich miliony, robi się z tego zauważalny narzut. QLoRA kwantyzuje więc… same stałe kwantyzacji. Kwantyzacja kwantyzacji brzmi jak żart, a oszczędza realnie około 0,4 bita na parametr.² Przy modelu 65B te ułamki bitów zamieniają się w gigabajty.

Trzy — paged optimizers (optymalizatory stronicowane). Przy gradient checkpointingu zużycie pamięci potrafi nagle skoczyć — pojawia się pik i karta krztusi się „out of memory" w najmniej spodziewanym momencie. Paged optimizers używają NVIDIA unified memory, żeby te skoki obsłużyć: gdy na GPU robi się ciasno, stany optymalizatora są po cichu przerzucane do RAM-u i z powrotem, jak stronicowanie pamięci w systemie operacyjnym.¹ Dzięki temu pik nie wywala całego treningu.

To nie jest to samo co GPTQ czy AWQ

Tu łatwo o zamieszanie, więc warto postawić słup graniczny. Kiedy słyszysz „kwantyzacja", najczęściej chodzi o coś zupełnie innego niż QLoRA: o GPTQ albo AWQ, czyli metody, które biorą gotowy, wytrenowany model i ściskają go pod samą inferencję (post-training quantization). Rozgryzaliśmy ten drugi świat osobno tutaj — i to jest inna bajka.

QLoRA nie służy do odchudzania modelu pod odpalanie. QLoRA to metoda fine-tuningu — kwantyzacja 4-bitowa jest w niej tylko trikiem, który pozwala zmieścić trening na jednej karcie. Efekt końcowy to wytrenowane adaptery LoRA, które doklejasz do modelu. Zapamiętaj prostą regułę: GPTQ/AWQ to „jak taniej uruchomić cudzy model", QLoRA to „jak tanio dostroić model pod siebie". Mylenie tych dwóch to klasyk początkującego na forach.

Guanaco, czyli dowód, że to działa

Teoria teorią, ale autorzy poszli na całość: tą metodą dostroili ponad 1000 modeli — różne architektury (LLaMA, T5), różne skale (7B, 13B, 33B, 65B), osiem zestawów danych instrukcyjnych. Skale, których zwykłym fine-tuningiem nikt by na tym sprzęcie nie ruszył.¹

Najlepsza rodzina dostała nazwę Guanaco (tak, po tej andyjskiej kuzynce lamy — w tym świecie wszystko jest lamą). Trenowana na danych OpenAssistant, w benchmarku Vicuna przebiła wszystkie wcześniej publicznie wydane modele i osiągnęła 99,3% poziomu ChatGPT — przy zaledwie 24 godzinach fine-tuningu na jednej karcie.¹

Tu tylko jedna uczciwa gwiazdka, którą stawiają sami autorzy: te 99,3% to wynik z konkretnego benchmarku Vicuna, ocenianego przez GPT-4 — nie jakaś uniwersalna miara „model jest w 99% tak dobry jak ChatGPT do wszystkiego". Praca wprost pokazuje, że ocena GPT-4 to tania i sensowna alternatywa dla oceny ludzkiej, ale zastrzega, że ówczesne benchmarki chatbotów nie były w pełni wiarygodne do precyzyjnego rankingowania modeli.¹ Liczba robi wrażenie — traktuj ją jednak jako „zaskakująco blisko", a nie jako wyrok.

Zrób to sam (a przynajmniej wiedz, gdzie klikać)

Najlepsze jest to, że QLoRA nie została na papierze jako ciekawostka. Kod referencyjny i modele Guanaco wylądowały na licencji MIT w repo artidoro/qlora, razem z jądrami CUDA do treningu 4-bitowego.³ A w praktyce prawie nikt nie pisze tego od zera — całość jest wpięta w ekosystem Hugging Face. Kwantyzację robi biblioteka bitsandbytes, adaptery dokłada PEFT, a spina to wszystko transformers.

Sercem konfiguracji jest BitsAndBytesConfig — i to w nim odnajdziesz jak żywe wszystkie trzy patenty z papieru:⁴

from transformers import BitsAndBytesConfig
import torch

bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,                    # wagi bazowe w 4 bitach
    bnb_4bit_quant_type="nf4",            # patent nr 1: NF4, nie zwykły FP4
    bnb_4bit_use_double_quant=True,       # patent nr 2: podwójna kwantyzacja
    bnb_4bit_compute_dtype=torch.bfloat16 # obliczenia w bf16, nie w 4 bitach!
)

Popatrz na ostatnią linijkę — compute_dtype to bf16 (a czym bf16 różni się od f16, rozbieramy osobno), dokładnie ta wyższa precyzja obliczeń, o której gadaliśmy wyżej. Wagi leżą w 4 bitach, ale liczy się porządnie.

A ile realnie karty to zjada? Zależy od modelu, długości sekwencji, batcha i checkpointingu — liczby 65B/48 GB z papieru to konkretny eksperyment, nie uniwersalna tabelka. Ale skala robi wrażenie z drugiej strony też: dzięki nested quantization dokumentacja Hugging Face pokazuje dostrojenie Llama-13B na jednej karcie T4 16 GB — sekwencja 1024 tokeny, batch 1, gradient accumulation na 4 kroki.⁴ T4 to karta, którą dostajesz za darmo w Google Colab.

Jeśli martwi cię, czy w ogóle zmieścisz coś na swojej karcie, to osobna rachunkowość — zbieraliśmy wzory na VRAM tutaj. Ale morał QLoRA jest prosty: bilet wstępu spadł tak, że fine-tuning przestał być salą VIP.

Przez lata fine-tuning działał jak wędkarstwo z burty jachtu — niby każdy może, tylko najpierw kup jacht. QLoRA wsadziła ci w rękę wędkę i pokazała, że ryba bierze tak samo z pomostu za pięć złotych. Zamrożone wagi ściśnięte do czterech bitów, garść adapterów do dotrenowania, jedna karta pod biurkiem — i model, który jeszcze wczoraj wymagał serwerowni, uczy się twojego żargonu przez noc. Nie dlatego, że ktoś dołożył ci pamięci. Dlatego, że ktoś w końcu zapytał, czy naprawdę trzeba trzymać w pełnej precyzji coś, czego i tak nikt w treningu nie rusza.

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

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

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

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

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

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

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

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

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

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

Mnożenie? Jakie mnożenie

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

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

Haczyk: to działa dopiero od pewnego rozmiaru

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

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

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

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

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

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

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

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

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

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

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

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

A pod maską siedzi jedna z ładniejszych prac ostatnich lat — FlashAttention, Tri Dao i spółka ze Stanfordu, maj 2022.¹ Ładna nie dlatego, że wymyśliła nowy rodzaj uwagi. Wręcz przeciwnie — wynik matematyczny wychodzi co do liczby taki sam jak w zwykłej uwadze. Cały myk polega na czymś, co brzmi jak herezja dla kogoś, kto liczył złożoność na studiach: żeby przyspieszyć obliczenia, zamiast liczyć mniej, autorzy kazali karcie mniej biegać po pamięci. I to załatwiło sprawę.

Skąd w ogóle ten głód pamięci

Najpierw ustalmy, czego uwaga potrzebuje, bo tu leży cały problem. Uwaga (ta z „Attention Is All You Need", z 2017 — inna praca, inni ludzie, nie mylić) dla sekwencji o długości N tokenów porównuje każdy token z każdym. Każdy z każdym to macierz N × N. Masz 4 tysiące tokenów kontekstu? To 16 milionów liczb w jednej tablicy. Osiem tysięcy? Już 64 miliony. Pamięć rośnie z kwadratem długości — podwajasz kontekst, płacisz czterokrotnie.¹

I teraz najważniejsze, co ludzie przeoczają: nie chodzi o to, że tych mnożeń jest dużo. GPU uwielbia mnożyć, od tego jest. Problem w tym, gdzie ta wielka macierz ląduje. Karta ma dwa rodzaje pamięci. Jest HBM — ta duża, te twoje 8, 12 czy 24 giga, wolna jak poranny ruch na obwodnicy. I jest SRAM — malutka pamięć tuż przy rdzeniach obliczeniowych, błyskawiczna, ale mieści tyle co nic. Zwykła uwaga liczy całą macierz N × N, zapisuje ją w HBM, potem odczytuje z powrotem, żeby policzyć softmax, znowu zapisuje, znowu czyta… i to bieganie tam i z powrotem — nie samo mnożenie — jest tym, co zżera czas i pamięć.

„IO-aware", czyli licz tam, gdzie blisko

Tu wchodzi pomysł, od którego cała praca dostała podtytuł: IO-awareness, świadomość operacji wejścia-wyjścia.¹ Brzmi korporacyjnie, a znaczy rzecz prostą jak drut: przestań optymalizować liczbę mnożeń, zacznij optymalizować liczbę podróży do wolnej pamięci. Bo to one są wąskim gardłem.

Jak to zrobić, skoro macierz N × N z definicji jest ogromna i nie zmieści się w tej malutkiej szybkiej SRAM? No właśnie — nie zmieści się w całości. Ale w kawałkach już tak. I to jest sedno.

• Tiling (kafelkowanie). Zamiast liczyć naraz całą macierz, tniesz Q, K i V na bloki i przerabiasz je kafelek po kafelku. Każdy kafelek jest na tyle mały, że wjeżdża do SRAM, tam się go przemiela, wypluwa wynik i bierze następny. Wielka macierz N × N jako całość nigdy nie powstaje w wolnej pamięci — istnieje tylko przelotnie, we fragmentach, w tej szybkiej pamięci przy rdzeniach.²
• Online softmax. Tu jest haczyk, bo softmax klasycznie potrzebuje całego wiersza naraz — musi znormalizować po wszystkich elementach. FlashAttention liczy go „w locie", z bieżącą normalizacją: przerabia kolejne bloki i na bieżąco koryguje wynik, tak jakby sumował rachunek pozycja po pozycji, poprawiając napiwek za każdym razem, gdy dojdzie nowa pozycja. Efekt końcowy identyczny, a pełnego wiersza nigdy nie trzeba trzymać.²
• Rekomputacja. Przy uczeniu (backward pass) normalnie trzymasz w pamięci wszystkie pośrednie wyniki, żeby policzyć gradienty. FlashAttention mówi: po co je trzymać, skoro taniej je policzyć jeszcze raz z tego, co już mamy w szybkiej pamięci? Dokłada trochę mnożenia, żeby oszczędzić na pamięci i na tym przeklętym bieganiu do HBM. I na tym akurat wychodzi na plus.¹

Zbierz to razem i dostajesz uwagę, w której zużycie pamięci rośnie liniowo z długością sekwencji, O(N), zamiast kwadratowo, O(N²).¹ Ta sama matematyka, ta sama odpowiedź co do ostatniej cyfry — tylko poukładana tak sprytnie, że wielka tablica pośrednia nigdy nie musi się zmaterializować tam, gdzie jest wolno.

Czy to na pewno działało? Liczby z pracy

Bo można sobie opowiadać o eleganckim algorytmie do rana, ale papier bez liczb to wróżenie z fusów. Autorzy zmierzyli i pokazali czarno na białym.¹

I najciekawsze na koniec — nie samo „szybciej", ale „w ogóle się dało". Skoro pamięć przestała rosnąć kwadratowo, można było pchać modele na kontekst, na którym wcześniejsze Transformery po prostu się poddawały. Na Path-X (sekwencja 16 tysięcy) FlashAttention wyciągnął 61,4% dokładności, a na Path-256 (64 tysiące!) — 63,1%.¹ To zadania, na których wcześniej model radził sobie nie lepiej niż rzut monetą. Dłuższy kontekst, który dziś traktujesz jak coś oczywistego, częściowo wziął się właśnie stąd.

Zrób to sam — i nie pomyl tego z KV-cache

Nie musisz nic implementować, cały ten mechanizm masz w jednej fladze. W llama.cpp to -fa, --flash-attn, przyjmuje on/off/auto, domyślnie stoi na auto.³

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

Jedna rzecz, którą warto tu dorzucić, bo ludzie się na niej wykładają: w llama.cpp flash attention jest twardym wymogiem dla kwantyzacji KV-cache. Chcesz ścisnąć cache do q8_0, żeby odzyskać VRAM przy długim kontekście? Bez -fa on się nie da — kwantyzacja V-cache wymaga flash attention wprost, kod ucina to jednym komunikatem błędu.⁴ Więc te dwie sztuczki chodzą w parze:

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

I tu ostrzeżenie, żebyś nie wpadł w częstą pułapkę pojęciową. FlashAttention to nie jest KV-cache — to dwie różne rzeczy, które akurat obie oszczędzają pamięć. KV-cache dotyczy tego, że model przechowuje przeliczony kontekst między kolejnymi tokenami generacji (rozgryzaliśmy to bliżej tutaj). FlashAttention dotyczy tego, jak liczysz uwagę w jednym przejściu — kolejności obliczeń, nie przechowywania stanu. Oszczędność bierze się wyłącznie z tilingu i rekomputacji, a nie z jakiejkolwiek utraty precyzji — nikt tu niczego nie kwantyzuje ani nie zaokrągla.

Dwa zastrzeżenia od siebie, żeby cię to potem nie zaskoczyło. Raz — wsparcie nie jest uniwersalne: na backendzie CUDA jest jak znalazł, ale na Vulkanie czy SYCL dla części kart flaga bywała kapryśna, więc nie traktuj jej jak działającej wszędzie i zawsze (więcej o tym, czym różnią się backendy). Dwa — jak zwykle w llama.cpp, resztę flag, które chodzą obok tej, ogarnialiśmy osobno.

Historia nie skończyła się w 2022. Rok później przyszedł FlashAttention-2 — już samego Tri Dao — który poprzestawiał podział pracy między wątkami GPU i wycisnął jeszcze z grubsza dwukrotne przyspieszenie względem jedynki, dobijając do 50–73% teoretycznego maksimum kart A100.⁵ Kod jednego i drugiego (plus wersji trzeciej) siedzi w oficjalnym repo Dao-AILab/flash-attention, na licencji BSD-3.²

Ale najfajniejsze w tej całej historii jest to, jak przewrotnie brzmi jej morał. Przez lata uczono nas, że żeby program był szybszy, trzeba go zmusić do liczenia mniej. A tu przyszli ludzie, którzy kazali karcie policzyć część rzeczy dwa razy — i wyszło szybciej. Bo okazało się, że najdroższa rzecz na GPU to nie mnożenie liczb, tylko chodzenie po nie na drugi koniec pamięci. Trochę jak z tym kolegą, który zamiast nosić zakupy po jednej siatce z auta pod blok, woli obładować się wszystkim naraz i przejść ten dystans raz. Nie jest leniwy. Po prostu wie, że najgorszy jest sam spacer tam i z powrotem.

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

To nie literówka i nie marketing. To Mixtral 8x7B¹ — i cała ta trójca liczb bierze się z jednego pomysłu architektonicznego, który nazywa się Mixture of Experts. Jak go raz zrozumiesz, przestaniesz się dziwić, czemu model „na 13B" i tak każe ci kupić kartę pod model „na 47B". Rozłóżmy to na części.

Trzy liczby, jeden trik

Klasyczny model językowy jest gęsty (dense): na każdy token przepycha wszystkie swoje wagi. Wrzucasz słowo, przechodzi przez każdą warstwę, w każdej warstwie dotyka każdego neuronu. Prosto, uczciwie, drogo — bo im więcej parametrów, tym więcej roboty na literkę.

Mixtral robi inaczej. Bierze architekturę zwykłego Mistrala 7B, ale w każdej warstwie podmienia jeden blok — ten feedforwardowy (FFN), czyli tę część, która „przetwarza" token po tym, jak uwaga (attention) już popatrzyła na kontekst. Zamiast jednego takiego bloku wstawia osiem równoległych. To są właśnie „eksperci".¹ Osiem kopii tej samej maszynerii, każda wytrenowana ciut inaczej.

I teraz clou: dla danego tokena nie odpalają się wszyscy. Przed blokiem eksperckim stoi mały router (sieć bramkująca, gating network), który patrzy na token i wybiera z ósemki tylko dwóch ekspertów — top-2.¹ Ich wyjścia miesza ważoną sumą (wagi bierze z softmaxu) i jedzie dalej. Sześciu pozostałych w tej warstwie, dla tego tokena, w ogóle nie rusza. Śpią.

Stąd rozjazd liczb. Parametrów całkowitych (total) jest 46,7 miliarda — potocznie ~47B. Ale na przejście jednego tokena aktywnych (active) jest tylko 12,9 miliarda, czyli ~13B.² Płacisz obliczeniami za trzynastkę, a nosisz na barana czterdziestkę siódemkę.

Skąd 47, a nie 56?

No dobra, ale skoro to „8x7B", to czemu nie wychodzi 56 miliardów? Bo mnożenie „osiem razy siedem" jest po prostu błędne. Powielona jest tylko ta część FFN. Cała reszta — warstwy uwagi, embeddingi, normalizacje — siedzi w modelu raz i jest współdzielona przez wszystkich ekspertów i wszystkie tokeny.² Nie mnożysz jej przez osiem ani w sumie, ani w liczbie aktywnej. Dlatego total ląduje na 46,7B (a nie 56B), a active na 12,9B (a nie na jednej ósmej z 56).

Zajrzyj zresztą do config.json na karcie modelu — tam to stoi czarno na białym: num_local_experts: 8, num_experts_per_tok: 2, przy hidden_size: 4096 i num_hidden_layers: 32.³ Osiem ekspertów na warstwę, dwóch na token, trzydzieści dwie warstwy. Mnożenie odpala się w każdej z tych 32 warstw z osobna.

I tu druga rzecz, która ludziom umyka: wybór ekspertów nie jest stały. Router decyduje oddzielnie dla każdego tokena i dla każdej warstwy.¹ Słowo „kot" w warstwie 3 może trafić do ekspertów 1 i 5, a to samo „kot" w warstwie 4 — do 2 i 7. A następne słowo w tym samym zdaniu pojedzie zupełnie inną trasą. To nie jest tak, że model „wybiera dwóch specjalistów na cały prompt" i tyle. To osiem tysięcy mikro-decyzji na akapit, każda robiona w locie.

To czemu nie zajmuje tyle co trzynastka?

I tu dochodzimy do pułapki, na którą łapie się pół internetu. Skoro na token aktywne jest tylko ~13B, to model „zajmuje tyle co trzynastka", nie? Odpalę na karcie pod 13B i będzie grało?

Nie będzie. I to jest najważniejsze zdanie w całym tym wpisie.

Router wybiera ekspertów dopiero w trakcie przejścia przez daną warstwę, osobno dla każdego tokena. Znaczy: z góry nie wiesz, którzy eksperci będą potrzebni. Następne słowo może chcieć dowolnej pary z ósemki, w dowolnej z 32 warstw. Więc żeby model w ogóle mógł ruszyć, wszystkie 47 miliardów wag musi siedzieć w pamięci naraz — cała ósemka ekspertów w każdej warstwie, gotowa do wezwania.⁴ Oszczędność z MoE dotyczy obliczeń (compute, latencji), nie pamięci. Mistral mówi to wprost: model „przetwarza wejście i generuje wyjście z taką samą szybkością i kosztem jak model 12,9B".² Szybkością i kosztem obliczeń — nie apetytem na VRAM.

Zbierzmy to w tabelce, bo dwie kolumny mówią więcej niż akapit:

Po co ten cały cyrk, skoro pamięć i tak trzeba mieć całą? Bo za cenę pamięci klasy 47B dostajesz jakość, która w benchmarkach dorównuje albo bije Llamę 2 70B i GPT-3.5 — przy koszcie obliczeniowym trzynastki.¹ To jest ten deal: płacisz VRAM-em jak za dużego, liczysz jak za małego, a mądrość dostajesz bliżej tego dużego. Dla kogoś, kto ma dość RAM-u, ale mało cierpliwości do tokenów na sekundę — świetny interes.

Zrób to sam (a przynajmniej zaplanuj)

MoE to architektura, nie kompresja. Łatwo pomylić to z kwantyzacją czy pruningiem, ale to inna bajka: MoE od początku trenuje się jako rzadko aktywowaną sieć, a kwantyzacja ściska wagi już po treningu — i spokojnie łączysz jedno z drugim (kwantyzowany GGUF Mixtrala to codzienność). Jak działają same nazwy kwantyzacji, rozgryzaliśmy tu — ta sama logika oszczędzania pamięci działa i na kwantyzowanym Mixtralu, tyle że na innym piętrze niż samo MoE.

W praktyce llama.cpp daje ci pod to dedykowaną flagę. Skoro attention i embeddingi są „zawsze aktywne", a bloki eksperckie odpalają się wybiórczo, to najwięcej ugrasz, trzymając te zawsze-aktywne komponenty na GPU, a same wagi ekspertów spychając do RAM-u. Od tego jest --n-cpu-moe N — „trzymaj wagi MoE z pierwszych N warstw na CPU" — albo --cpu-moe, które przenosi wszystkie.⁴ Kroisz VRAM kosztem szybkości — właśnie dlatego, że pamięć musi pomieścić całość, a nie tylko aktywną ścieżkę.

Najprościej — cały model na kartę, jak wejdzie:

llama-cli -m mixtral-8x7b-instruct-v0.1.Q4_K_M.gguf -ngl all -c 8192 -fa on -cnv

Nie wchodzi (a przy 47B na przeciętnej karcie do gier nie wejdzie)? Zostaw wszystkie warstwy na GPU, ale wypchnij eksperckie FFN-y z części z nich do RAM-u:

llama-cli -m mixtral-8x7b-instruct-v0.1.Q4_K_M.gguf \
  -ngl all --n-cpu-moe 12 -c 8192 -fa on -ctk q8_0 -ctv q8_0 -cnv

Które flagi co robią i w jakiej kolejności się nimi ratować przy „out of memory", rozpisaliśmy w poradniku o flagach llama.cpp. Sam Mixtral 8x7B (base i Instruct) jest na licencji Apache 2.0¹ — ściągasz, odpalasz, kombinujesz bez proszenia nikogo o zgodę.

Jedno ostrzeżenie na koniec, żebyś nie wpadł w drugą pułapkę. To „liczy jak 13B" obowiązuje, gdy generujesz jeden strumień token po tokenie. Gdy walisz batchem — wiele sekwencji naraz — różne tokeny w paczce wybierają różnych ekspertów, więc w danej warstwie i tak zwykle rozgrzewa się większość albo cała ósemka jednocześnie. Teoretyczne przyspieszenie topnieje. MoE lubi pojedynczego użytkownika przy biurku bardziej niż zatłoczony serwer.

Wyobraź sobie warsztat z ośmioma fachowcami przy każdym stanowisku. Do każdej śrubki brygadzista woła tylko dwóch — akurat tych, co się na niej znają. Reszta stoi i pije kawę. Robota idzie szybko, jakbyś płacił za dwóch. Ale wypłatę i tak wystawiasz całej ósemce, bo nigdy nie wiesz, która śrubka przyjdzie następna i kogo do niej trzeba będzie zawołać. I to jest cały Mixtral: tempo dwójki, lista płac ósemki. Twoja karta nie płaci za tych, co pracują — płaci za tych, co czekają w gotowości.

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

I przez lata żyliśmy z tym jak z hałaśliwym sąsiadem: da się, tylko trzeba akceptować. Aż w grudniu 2023 Albert Gu i Tri Dao wrzucili na arXiv pracę o wdzięcznej nazwie Mamba, w której powiedzieli coś w stylu „a gdyby tak w ogóle wyrzucić attention?".¹ Nie ograniczyć, nie zoptymalizować — wyrzucić. Cały mechanizm uwagi, a przy okazji i bloki MLP, i zastąpić je czymś, co skaluje się liniowo, a przy generowaniu trzyma stan o stałym rozmiarze. Brzmi jak sprzedażowa bajka. A jednak papier ma liczby.

Skąd w ogóle ten kwadrat w attention

Zanim zachwycimy się Mambą, warto wiedzieć, od czego ona ucieka. Uwaga w transformerze działa tak, że każdy token patrzy na każdy inny token w sekwencji. Masz 1000 tokenów? To milion par do policzenia. Masz 10 000? Sto milionów. Rośnie z kwadratem długości — stąd to słynne O(n²), które przy długim kontekście robi się głównym żłobem na pamięć i czas.

Do tego dochodzi druga rzecz, boleśnie znajoma każdemu, kto odpala model lokalnie: KV-cache. Żeby przy generowaniu nie liczyć uwagi od zera dla każdego nowego tokenu, transformer trzyma w pamięci klucze i wartości wszystkich dotychczasowych tokenów. I ten bufor rośnie liniowo z długością rozmowy — im dłużej gadasz, tym więcej VRAM-u zjada sam cache, niezależnie od wag modelu. Rozgryzaliśmy ten mechanizm bliżej tutaj, ale sedno jest proste: transformer ma pamięć, która puchnie. Zawsze puchnie.

Mamba wychodzi z zupełnie innej rodziny — z modeli przestrzeni stanów (SSM, state space models).¹ To pomysł stary jak teoria sterowania: zamiast patrzeć na wszystko naraz, przesuwasz się przez sekwencję krok po kroku i utrzymujesz jeden stan — wektor o stałym rozmiarze, który streszcza wszystko, co do tej pory widziałeś. Nowy token wpada, aktualizuje stan, idziesz dalej. Trochę jak RNN, tylko policzony sprytniej.

Dlaczego wcześniejsze SSM nie zabiły transformera

Bo miały jedną wadę, przez którą były głupsze niż attention. Klasyczny SSM — jak S4, poprzednik Mamby od tych samych autorów — ma stałe parametry. Te same macierze przetwarzają każdy token identycznie, bez względu na to, co ten token właściwie mówi. To pozwala policzyć całość jako jeden wielki splot (konwolucję), błyskawicznie i równolegle — ale odbiera modelowi zdolność, którą attention ma za darmo: rozumowanie oparte na treści.

Wyobraź sobie zdanie, w którym ważne jest jedno słowo gdzieś na początku, a reszta to wypełniacz. Attention po prostu skupi się na tym jednym słowie. Stary SSM nie umie — traktuje wypełniacz tak samo poważnie jak sedno, bo nie potrafi wybrać. Nie umie powiedzieć „to zapamiętaj, a tamto olej".

Na czym polega „selekcja", cały myk Mamby

I tu wchodzi jedna zmiana, która robi całą różnicę — selekcja. Gu i Dao uzależnili parametry SSM od wejścia. Krok dyskretyzacji Δ oraz macierze B i C przestają być stałe i stają się funkcjami aktualnego tokenu.¹ Innymi słowy: model przy każdym kroku sam decyduje, ile z nowej informacji wpuścić do stanu, a ile ze starego stanu zapomnieć — w zależności od tego, co właśnie czyta.

To jest ten moment „aha". Selektywny SSM potrafi zrobić to, czego stary nie umiał: przepuścić ważny token dalej wzdłuż sekwencji, a nieważny wygasić. Dostaje content-based reasoning, którym attention się chwalił — tylko bez płacenia kwadratem.

Cena selekcji: znika droga na skróty

Tyle że za wszystko się płaci. Uzależnienie parametrów od wejścia ma paskudny efekt uboczny: zabija formę splotową. Skoro macierze zmieniają się z każdym tokenem, nie policzysz już całości jednym szybkim splotem, jak w S4. Musisz wrócić do trybu rekurencyjnego — krok po kroku — a to na GPU brzmi jak przepis na wolny, sekwencyjny dramat.

Autorzy rozwiązali to algorytmem, który nazwali selective scan, i zaprojektowali go „świadomie sprzętowo" (hardware-aware), czerpiąc wprost z pomysłów, które znasz z FlashAttention.¹ Cały trik siedzi w tym, gdzie na GPU lądują dane. Karta graficzna ma pamięć szybką i małą (SRAM) oraz wolną i dużą (HBM) — a wąskim gardłem prawie zawsze jest przepychanie danych między nimi, nie samo liczenie.

Selective scan robi trzy rzeczy, żeby to obejść:¹

• Nie materializuje rozdmuchanego stanu w wolnej pamięci HBM — dyskretyzację i rekurencję liczy w szybkim SRAM.
• Zlepia operacje w jeden kernel (kernel fusion), zamiast latać z wynikami tam i z powrotem.
• Przy propagacji wstecznej przelicza stany od nowa, zamiast trzymać je w pamięci (recomputation) — bo na nowoczesnym GPU policzyć jest taniej niż odczytać.

Efekt? Model, który w teorii jest rekurencyjny i „powinien" być wolny, w praktyce śmiga. To ta sama filozofia, co przy flash attention: nie zmieniaj matematyki, zmień to, jak dane wędrują przez poziomy pamięci karty.

Co z tego wychodzi w liczbach

Papier nie owija w bawełnę. Kilka twardych wyników:¹

To „5× higher throughput" to nie chochlik — Mamba generuje tokeny pięć razy szybciej niż transformer podobnej klasy, właśnie dzięki temu, że nie musi za każdym krokiem przemielać rosnącego cache’u.¹ A jakościowo Mamba-3B dorównuje transformerom dwukrotnie większym i bije te swojej wielkości — zarówno w pretreningu, jak i w ewaluacji downstream.

I jedna rzecz, która dla długiego kontekstu jest najsmaczniejsza: wydajność na realnych danych poprawia się aż do sekwencji rzędu milionów tokenów.¹ Nie „nie psuje się" — poprawia. Tam, gdzie transformer się dusi, Mamba dopiero się rozkręca. Do tego papier pokazuje wyniki state-of-the-art nie tylko dla języka, ale i dla audio oraz genomiki — jako ogólny backbone sekwencyjny, nie wąska sztuczka do jednej modalności.

Zrób to sam (a przynajmniej dotknij)

To nie jest zamknięty papier z ładnym wykresem. Kod i checkpointy leżą w oficjalnym repo state-spaces/mamba — z gotowymi modelami od 130M do 2.8B parametrów, trenowanymi między innymi na 300 miliardach tokenów (wariant SlimPajama na 600 mld).² Model z abstraktu opisywany jako „Mamba-3B" to na Hugging Face ten sam checkpoint co mamba-2.8b — nazewnictwo się rozjeżdża, liczba parametrów ta sama.³

Jak chcesz zajrzeć pod maskę bloku Mamba, warto znać trzy pokrętła z implementacji:²

# kluczowe hiperparametry modułu Mamba (Mamba-1)
d_state = 16   # rozmiar stanu SSM — ile "pamięci" trzyma ukryty wektor
d_conv  = 4    # szerokość lokalnej konwolucji przed SSM
expand  = 2    # o ile blok rozszerza wymiar wewnętrzny

d_state to wielkość tego stałego stanu, o którym cała gadka — domyślnie 16 dla Mamby-1. d_conv to szerokość krótkiej lokalnej konwolucji (Mamba wciąż lubi lokalny kontekst tuż-tuż), a expand mówi, o ile blok pompuje wymiar wewnętrzny. Trzy liczby, a definiują charakter całej architektury.

Jedno zastrzeżenie na koniec, żeby nie wpaść w hype: Mamba nie wysyła transformerów na emeryturę. Papier pokazuje przewagę na modelowaniu języka, audio i genomice — nie ogłasza, że uwaga jest bezużyteczna wszędzie. Późniejsze prace tych samych autorów (Mamba-2 i tak zwane structured state space duality) pokazują wręcz, że SSM i attention są matematycznie spokrewnione bliżej, niż się na pierwszy rzut oka wydaje — to nie dwa wrogie plemiona, raczej dwie gałęzie tego samego drzewa.

I może właśnie o to chodzi. Przez kilka lat myśleliśmy, że długi kontekst to podatek, który płaci się kwadratem i pęczniejącym cache’em — po prostu prawo natury lokalnego LLM-owania. Mamba przyszła i pokazała, że to była tylko jedna droga przez las, nie jedyna. Ten sam worek, do którego dorzucałeś kamień za każdym tokenem, nagle okazał się plecakiem o stałej wadze — i można iść dalej, aż po horyzont milionów tokenów, bez zaciskania zębów przy liczniku VRAM-u.

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

To nie jest pytanie z gatunku czepialstwa. Sam pewnie nieraz widziałeś, jak model z „długim kontekstem” pięknie streszcza pierwsze pięć stron, a od dziesiątej zaczyna zmyślać, mieszać imiona i gubić wątek — dokładnie w miejscu, w którym teoretycznie miał błyszczeć. Bo rozciąganie okna kontekstu to nie jest przesunięcie suwaka. To operacja na sercu tego, jak model w ogóle rozumie „gdzie” jest dany token. I tu wchodzi YaRN — metoda z pracy grupy z Nous Research, która robi to tanio i, co ważniejsze, robi to dobrze.¹

Skąd model w ogóle wie, który token jest który

Zacznijmy od tego, że transformer sam z siebie nie ma pojęcia o kolejności. Wrzuć mu „pies goni kota” i „kota goni pies” — bez informacji o pozycji to dla niego ta sama torba słów. Trzeba mu jakoś powiedzieć, że ten token jest pierwszy, tamten setny.

Współczesne modele — LLaMA, Mistral, Qwen — robią to przez RoPE (rotary position embeddings, rotacyjne osadzenia pozycyjne) z pracy Su i innych.² Pomysł jest elegancki: zamiast doklejać pozycję jako osobny wektor, RoPE obraca wektory zapytań i kluczy o kąt proporcjonalny do pozycji tokena. Każdy wymiar embeddingu kręci się z inną częstotliwością — jedne szybko, jak wskazówka sekundowa, inne wolno, jak godzinowa. Token na pozycji 5 jest obrócony trochę, token na pozycji 5000 — dużo. Model uczy się czytać te kąty i z różnicy obrotów między dwoma tokenami wnioskuje, jak daleko od siebie leżą.

I teraz clou problemu: model widział te wskazówki tykające tylko do pozycji 4096. Dalej jest terra incognita. Kąty, które w treningu nigdy się nie pojawiły. Puść go na token 50 000, a wskazówka sekundowa zakręci się tyle razy, że model nie ma bladego pojęcia, co z tym zrobić — to jak pokazać komuś zegar, który obrócił się poza tarczę, w miejsce, którego nigdy nie oznaczono.

Dlaczego „po prostu ściśnij pozycje” psuje robotę

Pierwszy odruch jest oczywisty. Skoro model zna zakres do 4096, a chcemy 64k, to przeskalujmy pozycje liniowo — token 64 000 udawaj, że jesteś tokenem 4000. Ściśnij całą oś czasu tak, żeby zmieściła się w znanym zakresie. To jest Position Interpolation (PI, interpolacja pozycji) z pracy Chena i innych — i na papierze brzmi rozsądnie.

Problem w tym, że PI traktuje wszystkie częstotliwości RoPE jednakowo — zwalnia i sekundnik, i wskazówkę godzinową o ten sam czynnik.³ A to katastrofa dla tych najszybszych wymiarów. To właśnie one odpowiadają za rozróżnianie tokenów leżących tuż obok siebie — „czy słowo A jest bezpośrednio przed B, czy jest między nimi jeszcze jedno”. Ściśnij je razem z resztą, a model traci rozdzielczość na najdrobniejszym poziomie. Efekt? Jakość spada nawet na krótkim kontekście, który przecież działał bez zarzutu. Rozciągnąłeś okno i po drodze rozmyłeś to, co model umiał od początku. Klasyczny handel, w którym oddajesz więcej, niż dostajesz.

Jak YaRN dzieli częstotliwości na pasma

No to jak zrobić to mądrzej? Skoro problem jest w tym, że traktujemy wszystkie częstotliwości jednakowo — to przestańmy. To jest cała intuicja YaRN.

Zanim doszli do wersji finalnej, po drodze była NTK-aware interpolation (interpolacja świadoma NTK) — zamiast liniowo ściskać pozycje, zmienia się podstawę RoPE z b na b * s^(|D|/(|D|-2)), przez co „nacisk” interpolacji rozkłada się nierówno po wymiarach.³ Lepiej, ale wciąż z grubsza jednym pociągnięciem po wszystkim.

YaRN idzie krok dalej z podejściem NTK-by-parts (interpolacja pasmowa) — i to jest serce metody. Dzielisz wymiary częstotliwości na pasma za pomocą funkcji rampy γ(r):³

• wysokie częstotliwości (te lokalne, szybkie wskazówki — sąsiad przy sąsiedzie) zostawiasz w spokoju, bez interpolacji. Ekstrapolujesz. Niech tykają jak tykały.
• niskie częstotliwości (te globalne, wolne — gruby zarys „to jest gdzieś na końcu dokumentu”) interpolujesz normalnie, bo to one muszą pomieścić nowy, większy zakres.
• pasmo pośrodku rampa miesza płynnie, żeby nie było skoku na styku.

Sedno: nie ruszasz tego, co model umie najlepiej (drobna rozdzielczość lokalna), a rozciągasz tylko to, co i tak opisuje wielką skalę. Zegar dostaje większą tarczę, ale sekundnik dalej odmierza sekundy tak samo dokładnie.

Drugi bezpiecznik: temperatura uwagi

I tu jest smaczek, który łatwo przegapić, bo nie ma nic wspólnego ze skalowaniem częstotliwości. YaRN dorzuca attention temperature scaling — skalowanie temperatury w softmaxie uwagi.³ Kiedy rozciągasz kontekst, rozkład uwagi robi się „płaski”, model rozprasza się na tysiące tokenów zamiast celować. Więc mnożysz logity uwagi przez stały współczynnik, wyliczony z prostego, empirycznego wzoru:

sqrt(1/t) = 0.1 * ln(s) + 1

gdzie s to współczynnik skalowania kontekstu (dla 4096 → 64k mamy s = 16). Piękne w tym jest to, że działa jak zwykły mnożnik na logitach — nie dotyka wag modelu, nie wymaga dodatkowego treningu, wchodzi za darmo. Osobne pokrętło, doklejone z boku, a robi sporo dobrego dla ostrości. Nie pomyl go ze skalowaniem samego RoPE — to dwa różne mechanizmy, które YaRN łączy w jedno.

Tanio, czyli ile to naprawdę kosztuje

Teraz najlepsze — bo tu YaRN naprawdę błyszczy. To nie jest trening od zera. To nawet nie jest porządny fine-tuning na górze danych. To krótkie douczenie już gotowego modelu, żeby oswoił się z nowymi kątami.

Ile krótkie? W pracy LLaMA-2 7B i 13B douczono jakieś 400 kroków przy s = 16 (4096 → 64k), plus dodatkowe ~200 kroków przy s = 32, żeby dobić do 128k — razem około 600 kroków, na danych PG19 w segmentach po 64k, przy batchu 64.³ Objętościowo to szacunkowo ~0,1% oryginalnego korpusu pretreningowego. Jedna dziesiąta procenta. W liczbach z abstraktu: YaRN potrzebuje około 10x mniej tokenów douczenia i 2,5x mniej kroków treningowych niż wcześniejsze metody.¹

I jeszcze jedna rzecz, która robi wrażenie: modele ekstrapolują poza długość, na której je douczono. Serię Mistral 7B rozciągnięto z 8k do 64k i 128k tą samą metodą — a trening na segmentach 64k dawał poprawne działanie aż do 128k.³ Model, który w douczeniu nie widział nic dłuższego niż 64k, radzi sobie dwa razy dalej. To już nie jest tylko „nauczyliśmy go nowego zakresu” — to „nauczyliśmy go reguły, którą sam rozciąga dalej”.

Zrób to sam: YaRN w llama.cpp

I teraz uwaga na rozróżnienie, na którym łatwo się wyłożyć. Wszystko powyżej — kroki douczenia, dane PG19 — to warstwa treningu opisana w papierze. Ale jest druga warstwa: inferencja. llama.cpp implementuje skalowanie YaRN jako parametry runtime, które przekręcasz przy uruchomieniu, bez żadnego douczania:⁴

llama-server -m model-yarn-128k.gguf \
  -c 65536 \
  --yarn-orig-ctx 8192 \
  --yarn-ext-factor 1.0 \
  -fa on

• --yarn-orig-ctx — oryginalny kontekst treningowy modelu (domyślnie 0, czyli „wczytaj z metadanych GGUF”). To punkt odniesienia, względem którego liczy się s.
• --yarn-ext-factor — współczynnik mieszania ekstrapolacji (domyślnie -1.00; 0.0 to pełna interpolacja).

Jeśli model został wypuszczony jako wariant YaRN, metadane zwykle same podpowiedzą sensowne wartości — wtedy w ogóle nie musisz w to grzebać. A jak flagi w llama.cpp w ogóle działają i które z tej setki naprawdę musisz znać, rozbieraliśmy w osobnym wpisie. Jest jeszcze wariant Dynamic NTK — aktualizuje współczynnik skalowania s = max(1, l'/L) w locie, per krok inferencji, zamiast trzymać stałą wartość ustaloną raz.³ Sprytne, bo krótkie prompty nie płacą podatku za rozciągnięcie, którego akurat nie potrzebują.

Cała ta rodzina metod, swoją drogą, ładnie zazębia się z tym, jak w ogóle liczy się uwaga — a to temat, który drążyliśmy przy FlashAttention.

Większa tarcza, ten sam sekundnik

Wróćmy na koniec do tego zegara. Naiwna interpolacja bierze tarczę i ściska ją tak, że sekundnik zlewa się z minutową — niby zmieściłeś więcej godzin, ale nie odczytasz już, czy jest 12:01, czy 12:02. YaRN robi odwrotnie: zostawia sekundnik w spokoju, a rozciąga tylko wolne wskazówki, które i tak odmierzają grube kawałki. Dokładasz kilkaset kroków douczenia — tyle, ile trzeba, żeby model oswoił nowe kąty — i nagle patrzy na sto dwadzieścia osiem tysięcy tokenów tak, jakby zawsze umiał. Nie dlatego, że zobaczył każdą nową pozycję. Dlatego, że ktoś mądrze przekręcił mu zegar, nie tłukąc szkł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ć.

A różnią się. I nie chodzi o to, że jeden jest „lepszy", tylko że to dwie zupełnie różne szkoły myślenia o tym samym problemie: jak zapisać miliardy wag ciaśniej i nie zepsuć modelu. GPTQ i AWQ podchodzą do tego z dwóch przeciwnych stron — jeden liczy matematyczną korekcję błędu, drugi pyta, które wagi są w ogóle ważne. A na dokładkę cały świat GGUF-a i k-quantów, który znasz z llama.cpp, to trzecia bajka, jeszcze inna. Rozłóżmy to na części.

Najpierw jedno rozróżnienie: to wszystko jest PO treningu

Zanim wejdziemy w szczegóły — jedna rzecz, na której wykłada się połowa dyskusji. GPTQ, AWQ, GGUF: to wszystko kwantyzacja po treningu (post-training quantization, PTQ). Bierzesz gotowy, wytrenowany model w FP16 i przerabiasz jego wagi na coś ciaśniejszego. Żadna z tych metod nie trenuje modelu od nowa. To nie jest quantization-aware training (QAT), gdzie model uczy się od początku z myślą o niskiej precyzji. Tu nikt niczego nie uczy — bierzemy skończone dzieło i pakujemy je do mniejszego pudełka.

Dlaczego to ważne? Bo cała sztuka PTQ polega na tym, żeby nie mieć dostępu do treningu, a i tak stracić jak najmniej. Nie przepuszczasz miliardów przykładów przez wsteczną propagację. Masz gotowe wagi i najwyżej garść tekstu do „kalibracji" — żeby zajrzeć, jak model się zachowuje, i dobrać kwantyzację mądrzej niż zwykłym zaokrągleniem. I właśnie w tym „mądrzej" GPTQ i AWQ idą w dwie różne strony.

GPTQ: kwantyzuj wagę, popraw resztę, powtórz

Pierwsza szkoła. GPTQ — z pracy Frantara, Ashkboosa, Hoeflera i Alistarha z 2022 roku¹ — wywodzi się z klasycznej idei o nazwie Optimal Brain Quantization (OBQ). Pomysł jest zaskakująco ludzki: nie kwantyzuj wszystkiego naraz na oślep. Rób to po jednej wadze, a po każdym takim ruchu popraw pozostałe, jeszcze nietknięte wagi tak, żeby zrekompensować błąd, który właśnie wprowadziłeś.

Wyobraź sobie, że rozstawiasz meble w za małym pokoju. Wciskasz szafę w róg — i widzisz, że przez to stół musi się ciut przesunąć, a krzesło podjechać bliżej ściany. GPTQ robi dokładnie to: kwantyzuje kolumnę wag, patrzy, ile błędu przez to narobił, i „dosuwa" pozostałe kolumny, żeby wyjście warstwy zostało jak najbliżej oryginału. Formalnie każdą warstwę rozwiązuje osobno jako problem argmin ||WX − ŴX||₂² — czyli: znajdź skwantyzowane wagi Ŵ, które na tych samych wejściach X dają wyjście najbliższe oryginalnym wagom W.¹

Skąd metoda wie, jak dosuwać? Z informacji drugiego rzędu — odwrotności Hessianu warstwy, czyli macierzy mówiącej, jak wrażliwe jest wyjście na zmianę każdej wagi.¹ To nie jest zwykłe „zaokrąglij do najbliższej wartości" (round-to-nearest). Zaokrąglenie byłoby jak wciskanie mebli bez patrzenia. GPTQ za każdym krokiem konsultuje się z Hessianem i wie, którą resztę i o ile przesunąć.

Problem: liczenie odwrotności Hessianu dla każdej wagi z osobna jest morderczo drogie. I tu wchodzi kluczowy myk GPTQ względem starego OBQ. Autorzy zauważyli, że jeśli kwantyzować kolumny w ustalonej, stałej kolejności — a nie „zawsze tę najmniej wrażliwą" — to odwrotność Hessianu można policzyć i współdzielić raz na całą warstwę, zamiast przeliczać w kółko.¹ To dało ponad trzy rzędy wielkości przyspieszenia i nagle metoda przestała się dławić na dużych modelach. Do tego doszła tzw. Cholesky Reformulation — prekomputacja przez rozkład Choleskiego, żeby przy skali setek miliardów parametrów nie rozjechała się numeryka.¹

Efekt? OPT-175B skwantyzowany do 3–4 bitów na wagę w jakieś 4,2 godziny na pojedynczym GPU — i gotowy do generatywnej inferencji na jednej karcie, co wcześniej było poza zasięgiem.¹ Przy 4 bitach strata perplexity względem FP16 to według pracy raptem około 0,03, a raportowane przyspieszenia inferencji siedzą w okolicach 3,25x–4,5x, zależnie od sprzętu.¹

Kalibracja? Skromna — 128 losowych kawałków po 2048 tokenów ze zbioru C4, czyli ogólnego tekstu z sieci. Bez danych zadaniowych. Autorzy podkreślają, że wynik pozostaje „zero-shot", bo metoda nigdy nie widzi danych spod konkretnego zadania — patrzy tylko na to, jak wagi reagują na w miarę losowy tekst.¹

AWQ: nie wszystkie wagi są równe

Druga szkoła podchodzi z zupełnie innej strony. AWQ — Activation-aware Weight Quantization, praca Lina, Tanga, Tanga, Yanga i spółki, wyróżniona nagrodą Best Paper na MLSys 2024² — startuje od obserwacji, która brzmi wręcz banalnie: nie wszystkie wagi są tak samo ważne. Okazuje się, że wystarczy ochronić jakiś 1% najistotniejszych wag, żeby błąd kwantyzacji spadł drastycznie.²

Ale — i tu jest cały smaczek — jak poznać, które wagi są „istotne"? Intuicja podpowiada: te największe co do wartości. AWQ mówi: nie. Istotność wagi wyznacza się z rozkładu aktywacji, a nie z samej wartości wagi.² Stąd „activation-aware" w nazwie: patrzysz, przez które kanały płynie najwięcej „sygnału" na wejściu, i to one decydują, które wagi trzeba traktować z czułością. Waga może być mała, ale jeśli mnoży aktywację, która regularnie strzela w górę — jest ważna.

I teraz najczęstsze nieporozumienie w internetach. Ludzie mówią: „AWQ trzyma ten 1% w FP16". Nieprawda — a przynajmniej nie w wersji podstawowej. Trzymanie garstki wag w wyższej precyzji to mixed precision, osobny nurt, który psuje jednolitość i utrudnia szybkie jądra obliczeniowe. AWQ robi coś sprytniejszego: matematycznie skaluje w górę kanały wag odpowiadające istotnym aktywacjom, jeszcze przed kwantyzacją, i kompensuje to odwrotnym skalowaniem po drugiej stronie.² Efekt jest taki, jakbyś dał tym ważnym wagom więcej „rozdzielczości" w siatce kwantyzacji — ale precyzja zostaje jednolita, bez wysepek FP16.

Co z tego wynika dla ciebie w praktyce: AWQ nie robi wstecznej propagacji przez model i nie robi rekonstrukcji opartej na regresji.² To ją odróżnia od GPTQ, która musi przejść przez warstwy z rachunkiem Hessianu. Skutkiem ubocznym braku dopasowywania „na siłę" jest większa odporność na przeuczenie się na konkretnych danych kalibracyjnych — metoda nie uczy się zbytnio pod ten akurat tekst, który jej pokazałeś.²

AWQ wspiera warianty W4A16 i W3A16 (wagi 4- lub 3-bitowe, aktywacje 16-bitowe), z opcjonalnym grupowaniem kanałów, np. rozmiar grupy 128.³ A towarzyszący jej framework inferencyjny TinyChat osiąga ponad 3x przyspieszenie względem FP16 z Hugging Face na kartach desktopowych i mobilnych; w nowszych benchmarkach na RTX 4090 z LLaMA-3-8B raportowano 2,7x, a na NVIDIA Jetson Orin 2,9x i okolice 38 tokenów na sekundę.³

Dwie szkoły, jedna tabela

Zestawmy to na chłodno, bo gdy leżą obok siebie, różnica robi się oczywista:

A gdzie w tym wszystkim GGUF i k-quanty?

Tu trzeba postawić granicę na czerwono, bo to najczęstsze pomieszanie z poplątaniem. GGUF i k-quanty z llama.cpp (te wszystkie Q4_K_M, Q5_K_S i spółka, o których nazwach rozpisaliśmy się osobno tutaj) to trzeci, odrębny nurt. Owszem, technicznie też PTQ — ale filozofia zupełnie inna.

GGUF to przede wszystkim format pliku ekosystemu ggml-org/llama.cpp, a k-quanty to rodzina schematów kwantyzacji w środku. Zamiast kalibrowanej korekcji błędu opartej na Hessianie czy aktywacjach, k-quanty grupują wagi w superbloki po 256 wartości, z osobnymi (często też skwantyzowanymi) skalami i minimami dla podbloków oraz skalowaniem superbloku w fp16.⁴ (Sama „szesnastka" fp16 — i czemu w treningu ML częściej widuje się bf16 — to osobny temat.) Stąd bierze się niecałkowita „efektywna" liczba bitów na wagę — Q4_K_M to w praktyce jakieś 4,5 bita na wagę, nie równe 4.⁴

Warianty z dopiskami _S, _M, _L różnią się kompromisem rozmiar/jakość — _M selektywnie trzyma wrażliwsze warstwy w wyższej precyzji, a Q4_K_M społeczność od dawna uznaje za praktyczny „sweet spot" (jakieś 75% redukcji rozmiaru przy minimalnej odczuwalnej stracie).⁴ To inżynierski nurt zorientowany na inferencję na CPU i mieszaną CPU–GPU, nie na kartę wypchaną VRAM-em.

Kluczowe: nie utożsamiaj tych trzech. Wszystkie to PTQ, ale:

• GPTQ = sekwencyjna korekcja błędu przez odwrotność Hessianu,
• AWQ = skalowanie kanałów wag wg aktywacji,
• GGUF/k-quanty = superbloki z mieszaną precyzją per warstwa i osobnymi skalami.

GGUF może korzystać z danych kalibracyjnych (tzw. importance matrix), ale mechanizm jest inny niż w tamtych dwóch. To trzy różne odpowiedzi na to samo pytanie, nie trzy nazwy tej samej rzeczy.

Zrób to sam: jak to rozpoznać w praniu

Nie musisz liczyć żadnego Hessianu ręcznie — ale warto umieć rozpoznać, na co patrzysz. Katalog z GPTQ albo AWQ na Hugging Face zwykle trzyma wagi w formacie safetensors plus plik quantize_config.json, gdzie stoi jak byk liczba bitów i rozmiar grupy:

# GPTQ/AWQ zwykle: katalog safetensors + config kwantyzacji
ls TheModel-AWQ/
# config.json  model.safetensors  quantize_config.json  ...

# GGUF to jeden plik z całą kwantyzacją zaszytą w nazwie
ls TheModel-GGUF/
# the-model-q4_k_m.gguf

Reguła kciuka na dziś: jeśli odpalasz na karcie NVIDII przez silnik pokroju vLLM albo TinyChat i chcesz maksimum przepustowości z 4-bitowych wag — patrzysz na GPTQ albo AWQ. Jeśli grasz na CPU, Apple Silicon albo mieszance CPU–GPU i chcesz jeden plik, który „po prostu działa" w llama.cpp czy Ollamie — bierzesz GGUF, najpewniej Q4_K_M. Ta sama walka o VRAM, którą liczyliśmy we wzorze na pamięć, tylko rozegrana trzema różnymi szkołami.

I jeszcze jedno, żeby domknąć układankę: kwantyzacja po treningu to nie to samo, co 4-bitowy fine-tuning spod znaku QLoRA — tam ciśniemy model po to, żeby go doszkolić na skromnym VRAM-ie, a rozgryzaliśmy to osobno tutaj. Tu nikt niczego nie douczy. Tu tylko pakujemy skończony model do mniejszego pudełka.

Bo o to w tym całym zoo skrótów chodzi. Masz jeden wytrenowany mózg zapisany w FP16 i trzy ekipy, które przyszły go spakować na wyjazd. GPTQ pakuje pedantycznie, walizka po walizce, za każdym razem dosuwając resztę, żeby nic się nie pogniotło. AWQ najpierw pyta, co jest naprawdę cenne, owija ten 1% w folię bąbelkową i resztę wciska bez ceregieli. A ekipa GGUF-a nawet nie próbuje być elegancka — tnie na superbloki, pakuje w jeden plik i wrzuca do bagażnika starego kombi, byle ruszyło z miejsca na tym, co masz pod ręką.

Trzy szkoły, jeden model, ten sam cel: żeby coś, co „się nie mieściło", w końcu odpaliło u ciebie na biurku. Reszta to spór o to, jak elegancko go do tej walizki włożyć.

Przypisy · źródła

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.