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.

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

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