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.

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

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

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

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

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

Dlaczego on rośnie, a wagi nie

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

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

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

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

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

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

Jak go ścisnąć — trzy dźwignie

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

Kwantyzacja cache — najprostszy zysk

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

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

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

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

Flash attention — i warunek wstępny

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

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

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

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

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

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

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

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

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

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

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

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

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

Przypisy · źródła

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

Wzór na palcach

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

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

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

Skąd biorą się ułamkowe bity

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

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

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

Ile zważy „ten twój" model

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

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

Czego zapominasz: KV-cache i bufory

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

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

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

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

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

Jak zejść niżej, gdy nie wchodzi

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

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

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

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

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

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

Zrób to sam: rachunek w trzy sekundy

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

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

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

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

Przypisy · źródła

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

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