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

Skąd się bierze ten cały VRAM

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

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

Trzy sprytne rzeczy, które robi QLoRA

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

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

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

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

To nie jest to samo co GPTQ czy AWQ

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

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

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

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

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

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

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

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

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

from transformers import BitsAndBytesConfig
import torch

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Mnożenie? Jakie mnożenie

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

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

Haczyk: to działa dopiero od pewnego rozmiaru

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

AWQ: nie wszystkie wagi są równe

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

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

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

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

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

Dwie szkoły, jedna tabela

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

A gdzie w tym wszystkim GGUF i k-quanty?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Przypisy · źródła