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

Trzy liczby, jeden trik

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

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

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

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

Skąd 47, a nie 56?

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

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

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

To czemu nie zajmuje tyle co trzynastka?

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

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

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

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

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

Zrób to sam (a przynajmniej zaplanuj)

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

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

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

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

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

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

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

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

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

Przypisy · źródła

Bo pod spodem dzieje się rzecz z pozoru absurdalnie rozrzutna. Żeby dołożyć jeden token, model o siedmiu czy siedemdziesięciu miliardach parametrów musi przepchnąć całe swoje wnętrze — pełny przebieg naprzód — po czym dokłada jedną literkę i zaczyna od nowa. Cały ten kolos rozgrzewa się do jednego słowa, potem znowu, i znowu. Trochę jak odpalać silnik ciężarówki za każdym razem, gdy chcesz przejechać metr.

Skąd w ogóle ten pomysł

W 2022 roku trójka badaczy z Google’a — Leviathan, Kalman i Matias — zadała pytanie, które brzmi jak sabotaż: a co, jeśli większość kolejnych tokenów jest tak oczywista, że nie trzeba do nich całego dużego modelu? Że „w dniu dzisiejszym" po słowie „w" i „dniu" da się zgadnąć czymś dużo tańszym? Opisali to w pracy Fast Inference from Transformers via Speculative Decoding i pokazali coś, co brzmi zbyt pięknie: 2–3 razy szybsza generacja na modelach klasy T5-XXL, bez douczania czegokolwiek i bez zmiany rozkładu wyjściowego — czyli model gada dokładnie to samo, co gadałby normalnie, tylko szybciej.¹ Papier poszedł na ICML 2023 jako prezentacja ustna, więc nie była to notka na marginesie.

Dwa miesiące później niezależnie tę samą ideę opisała ekipa z DeepMind — Chen, Borgeaud, Irving, Lespiau, Sifre i Jumper — pod nazwą speculative sampling, z lekko innym schematem matematycznym i przyspieszeniem 2–2,5x na Chinchilli (70B) w środowisku rozproszonym.² Dwa zespoły, ten sam pomysł, ta sama gwarancja: przyspieszamy, jakości nie ruszamy. Kiedy dwie niezależne grupy trafiają w to samo, to zwykle znak, że pod spodem siedzi coś prawdziwego.

Jak to działa krok po kroku

Dobra, ale jak to działa naprawdę? Bierzesz dwa modele. Jeden duży — ten, którego odpowiedzi chcesz — nazwijmy go docelowym (target). I jeden mały, szybki — szkicownik (draft) — najlepiej tej samej rodziny, żeby „myślał" podobnie. I teraz taniec w trzech krokach:

1. Szkicownik zgaduje. Mały model generuje autoregresywnie kilka kolejnych tokenów — powiedzmy K sztuk. Robi to szybko, bo jest mały. To są propozycje, brudnopis.
2. Duży weryfikuje — jednym przebiegiem. I tu jest cały myk: duży model dostaje te K proponowanych tokenów naraz i sprawdza je w jednym przebiegu naprzód, wsadowo. Nie K osobnych przejazdów ciężarówką — jeden.
3. Akceptuj albo popraw. Tam, gdzie duży model zgadza się ze szkicownikiem, tokeny wpadają za darmo. Przy pierwszym niezgodnym — odrzucamy resztę, duży dokłada swój token i cała zabawa rusza od nowa.

Jeśli szkicownik trafił w pięć tokenów z rzędu, to policzyłeś je jednym przebiegiem dużego modelu zamiast pięciu. Jeśli spudłował od razu — koszt jest praktycznie taki, jak przy zwykłym dekodowaniu. Downside prawie żaden, upside spory. Ta sama logika weryfikacji „licz wsad, nie sekwencję" siedzi zresztą u podstaw tego, czemu KV-cache w ogóle się opłaca — rozgryzaliśmy to tutaj.

Czemu to nie psuje jakości

W tym miejscu każdy rozsądny człowiek zapala czerwoną lampkę. „Mały model zgaduje za dużego? To brzmi jak destylacja na skróty, na pewno wychodzi gorsza jakość." Otóż nie — i to jest najładniejsza część całej sztuczki.

To nie jest kwantyzacja ani destylacja. Wag dużego modelu nikt nie dotyka, jego dokładność zostaje nietknięta. Sekret siedzi w tym, jak akceptowane są tokeny — używa się zmodyfikowanego rejection sampling (próbkowania odrzucającego). Token zaproponowany przez szkicownik przyjmujemy z prawdopodobieństwem min(1, p_target(x) / p_draft(x)) — czyli: jeśli duży model uważa dany token za co najmniej tak samo prawdopodobny jak szkicownik, bierzemy go w ciemno. Jeśli mniej — akceptujemy proporcjonalnie, a przy odrzuceniu dobieramy nowy token z rozkładu resztkowego (residual), tak dobranego, żeby wszystko się matematycznie spięło.¹

Efekt? Łączny rozkład tokenów na wyjściu jest identyczny z tym, co dałoby zwykłe, niespekulacyjne próbkowanie samego dużego modelu. Nie „prawie taki sam", nie „w granicach błędu" — dokładnie taki sam, z dowodem.

Skąd się bierze przyspieszenie

Skoro nic nie tniemy, to gdzie ten darmowy obiad się chowa? W wąskim gardle, o którym lokalny LLM-owiec i tak wie w kościach: inferencja jednego tokena naraz jest ograniczona pamięcią (bandwidth-bound), nie liczeniem. Karta większość czasu nie liczy, tylko czeka, aż wagi modelu przemaszerują z VRAM-u do rdzeni. Przepchnięcie przez ten sam kanał jednego tokena a pięciu naraz kosztuje prawie tyle samo — bo i tak głównie czekasz na pamięć, a nie na arytmetykę.

Stąd cały zysk: policzenie K+1 tokenów w jednym wsadowym przebiegu jest znacznie tańsze niż K+1 osobnych, sekwencyjnych kroków. Im więcej propozycji szkicownika duży model akceptuje, tym mocniej wygrywasz.³ I tu ważne zastrzeżenie, bo to nie jest magiczne pokrętło „więcej = szybciej": przyspieszenie nie rośnie liniowo z liczbą draftowanych tokenów. Wszystko wisi na współczynniku akceptacji — jak często szkicownik trafia. Każąc mu zgadywać dwadzieścia tokenów naprzód przy kiepskiej trafności, generujesz górę brudnopisu, który duży model i tak wyrzuci do kosza. Bywa, że wtedy jest wolniej niż bez całej zabawy.

Zrób to sam w llama.cpp

Teoria teorią, ale llama.cpp (repo ggml-org/llama.cpp) obsługuje to od dawna — i w llama-server, i w osobnym narzędziu llama-speculative-simple. Cały wjazd na klasyczny wariant to jedna flaga: --spec-draft-model (krócej -md), która wskazuje plik GGUF modelu szkicowego.⁴ Bierzesz duży model, dokładasz mały z tej samej rodziny i lecisz:

llama-server -m qwen3-14b-q4_k_m.gguf \
  -md qwen3-0.6b-q4_k_m.gguf \
  --spec-draft-n-max 4 \
  -ngl all -c 8192 -fa on

--spec-draft-n-max N (domyślnie 3) ustawia maksymalną liczbę tokenów szkicowanych na krok, a --spec-draft-n-min N (domyślnie 0) dolną granicę.⁴ Progi akceptacji stroisz przez --spec-draft-p-min (domyślnie 0.00) i --spec-draft-p-split (domyślnie 0.10). Do reszty flag llama-server — -ngl, -c, -fa i spółka — wracaliśmy osobno tutaj.

Strategię wybiera --spec-type, i tu robi się ciekawie, bo klasyczny draft model to dopiero początek:

Warianty n-gramowe to osobny gatunek: nie potrzebują żadnego drugiego modelu, tylko zgadują kolejne tokeny na podstawie tego, co już się w tekście pojawiło (świetne, gdy model dużo cytuje sam siebie albo klepie strukturę). Mechanizm weryfikacji jest ten sam — po prostu brudnopis powstaje inaczej.³ A na drugim biegunie EAGLE-3 (draft-eagle3) to lekka, jednotransformerowa głowica, która podgląda stany ukryte dużego modelu i przez to trafia częściej niż samodzielny mały model tej samej wagi. Uruchomienie z dokumentacji wygląda tak:

llama-server -m Qwen3-4B.gguf \
  -md Qwen3-4B-eagle3.gguf \
  --spec-type draft-eagle3

Jedna pułapka na koniec, żebyś nie stracił wieczora na kopiowanie starych poradników: dawne flagi --draft, --draft-max, --draft-min zostały usunięte. Aktualna składnia to --spec-draft-n-max i pochodne --spec-*.⁴ Jak przepiszesz przykład sprzed roku i llama-server prycha, że nie zna flagi — to nie ty zwariowałeś, to repo poszło naprzód.

Najładniejsze w tym wszystkim jest to, że speculative decoding nie jest żadnym oszustwem na jakości — jest raczej jak dobry sekretarz. Ktoś szybki i tani pisze pod dyktando pierwszy szkic, przewidując, dokąd zmierza zdanie, a szef tylko przelatuje wzrokiem i skreśla to, co się nie zgadza. Reszta zostaje, jak stała. Szef odpowiada za każde słowo tak samo jak wtedy, gdy pisał sam — tyle że nie musi już maczać pióra w kałamarzu przy każdej literce.

I to jest ten moment, w którym twoja drukarka igłowa spod biurka nagle łapie zryw — te same słowa, ten sam rozkład, ta sama karta. Tylko kursor przestaje w końcu dyktować ci tempo.

Przypisy · źródła

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