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

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

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

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

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

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

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

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

Jak YaRN dzieli częstotliwości na pasma

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

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

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

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

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

Drugi bezpiecznik: temperatura uwagi

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

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

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

Tanio, czyli ile to naprawdę kosztuje

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

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

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

Zrób to sam: YaRN w llama.cpp

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

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

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

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

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

Większa tarcza, ten sam sekundnik

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

Bo entuzjazm sceny jest szczery, ale scena nie odpala tego modelu na twojej karcie. Ty odpalasz. I między „premiera na Hugging Face" a „gada u ciebie w terminalu tak, jak powinno" leży kilka pułapek, które regularnie kosztują ludzi wieczór. Dobra wiadomość: da się je odhaczyć w pięć minut, jeszcze zanim cokolwiek pobierzesz. Zrobimy z tego listę — taką, którą przejdziesz przy każdym kolejnym „SOTA", bo modeli będzie jeszcze wysyp.

Karta modelu, czyli tabliczka znamionowa

Zanim cokolwiek zrobisz — otwórz kartę modelu. Na Hugging Face to nie żaden osobny dokument, tylko plik README.md w repo, a na jego górze siedzi kawałek metadanych w YAML-u.¹ To jest tabliczka znamionowa: licencja, model bazowy, czasem gotowe wyniki ewaluacji. Cała ta lista, którą zaraz przejdziemy, w dużej mierze czyta się właśnie stamtąd. Nauczysz się rzucać okiem na te kilka pól i połowa niespodzianek znika, zanim się wydarzy.

Ile ten model waży i w jakim wariancie?

Pierwsze pytanie brutalnie praktyczne: czy to w ogóle wejdzie? Liczba parametrów (te 7B, 8B, 70B w nazwie) to grube przybliżenie apetytu na pamięć, ale w pełnej precyzji nawet „mały" 8B to kilkanaście giga. Dlatego naprawdę interesuje cię, czy istnieje wersja skwantyzowana — a konkretnie, czy ktoś zrobił już pliki GGUF, format, którego używają llama.cpp i Ollama.²

Kwantyzacja to nic innego jak zapisanie tych miliardów wag ciaśniej: mniej bitów na liczbę, mniejszy plik, mniejszy apetyt na VRAM, a jakość spada zaskakująco mało. Dokumentacja llama.cpp podaje wprost skalę: Llama-3.1-8B w formacie F16 waży jakieś 14,96 GiB, a ta sama w Q4_K_M — około 4,58 GiB.³ Trzy razy mniej, a Q4_K_M to poziom, który regularnie pada jako rozsądny kompromis rozmiar-jakość. Co znaczą wszystkie te literki i cyferki po Q, rozgryzaliśmy osobno tutaj.

Jedno małe ostrzeżenie, żeby nie pomylić pojęć: kwantyzacja po treningu (to, co dostajesz w GGUF-ie) to nie to samo, co trenowanie modelu od zera w niskiej precyzji. Dwie różne rzeczy, różny wpływ na jakość. Ktoś na scenie zawsze je pomiesza — nie bądź tym kimś.

Czy w ogóle wolno ci go użyć?

To pole, które ludzie przewijają najszybciej, a które potrafi najbardziej zaboleć. W metadanych karty jest license: — identyfikator licencji, po którym Hub nawet pozwala filtrować modele.¹ I tu jest haczyk: samo to, że repo jest otwarte i pliki leżą do pobrania, nie znaczy, że wolno ci na tym modelu zbudować cokolwiek komercyjnego.

Część modeli jedzie na licencjach „społecznościowych" albo „research only", które uśmiechają się otwarcie, a w treści ograniczają użycie. Gdy w polu widzisz license: other, to sygnał, żeby kliknąć w license_link i faktycznie przeczytać, na co się piszesz — bo identyfikator sam z siebie nic ci nie gwarantuje.¹ Nudne? Nudne. Ale to jedyny punkt z tej listy, który może się skończyć rozmową z prawnikiem, a nie z terminalem.

Jak długi kontekst realnie dostaniesz?

Model w karcie chwali się 128k kontekstu, więc bierzesz go do przełykania całych PDF-ów — i tu wpadasz w klasyczne nieporozumienie. Deklarowane maksimum modelu to jedno, a okno, które faktycznie ustawi ci runtime, to drugie.

Ollama na przykład sama dobiera domyślną długość kontekstu do tego, ile masz VRAM-u: przy mniej niż 24 GiB da ci 4k, a dopiero przy 48 GiB i więcej sięga nawet po 256k.⁴ Czyli twój wypasiony 128k model może po cichu chodzić na czterech tysiącach tokenów, a ty się dziwisz, czemu „zapomina" początek dokumentu. Wymusisz to zmienną OLLAMA_CONTEXT_LENGTH albo parametrem num_ctx:

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

A ustawić to okno możesz na kilka sposobów i jest wśród nich hierarchia: PARAMETER num_ctx w Modelfile ustala okno na stałe dla danego modelu, a opcje podane w locie w wywołaniu API nadpisują to, co siedzi w Modelfile.⁵ Tylko pamiętaj o dwóch kosztach: większe okno to znacznie więcej pamięci — dokumentacja Ollamy mówi to wprost — a siłą rzeczy także wolniejsze liczenie.⁴ Do tego rozciąganie okna ponad długość, na jakiej model trenowano, potrafi pogorszyć jakość odpowiedzi; dokładnie ten problem rozbraja mechanizm YaRN, który rozłożyliśmy na części tu. W llama.cpp tym samym oknem steruje flaga -c.

Czy narzędzie w ogóle to obsłuży?

Najboleśniejsza pułapka premierowa: model jest na Hugging Face, więc zakładasz, że od razu odpalisz go w llama.cpp czy Ollamie. A to wcale nie jest automatyczne. llama.cpp wymaga formatu GGUF, a jak model przychodzi w innym formacie, ktoś musi go najpierw skonwertować skryptami convert_*.py z repo (Hugging Face udostępnia do tego nawet przestrzeń „GGUF-my-repo").²

Gorzej, gdy model przynosi nową architekturę. Wtedy wsparcia po prostu nie ma, dopóki ktoś go nie dopisze — a to nie jest jedna linijka. Trzeba ruszyć skrypty konwersji w Pythonie (mapowanie tensorów, constants.py, tensor_mapping.py), potem kod C++ (llama-arch, llama-model-loader, llama-model, obsługa RoPE), a na koniec przetestować to na CPU, CUDA i Metalu.⁶ Dlatego dzień premiery modelu i dzień pierwszego działającego GGUF-a to często dwie różne daty. Jak śledzisz świeżynkę, sprawdź najpierw, czy w issues repo ktoś już nie ogarnia integracji — o tym, jak w ogóle działa ten cały ekosystem wokół GGUF-a, pisaliśmy osobno.

Instruct czy base? Sprawdź, zanim się zdziwisz

Widzisz w nazwie samo „Llama-3-8B" bez dopisku i myślisz, że pogadasz. Odpalasz, piszesz pytanie, a model zamiast odpowiedzieć — dopisuje kolejne pytania. Nie zepsuł się. Wziąłeś wersję base, która tylko kontynuuje sekwencję tokenów, zamiast wersji instruct/chat, douczonej do podążania za poleceniami i dialogiem.⁷

Różnica jest fundamentalna, a diabeł siedzi w formacie. Model czatowy oczekuje wiadomości opakowanych w konkretne tokeny kontrolne — u jednego to [INST]...[/INST], u innego <|user|> i <|assistant|> — i co gorsza, dwa modele dotrenowane z tej samej bazy mogą mieć zupełnie różny format czatu.⁷ Podasz zły — i instruct-model, który powinien świecić, nagle gada od rzeczy. W bibliotece transformers załatwia to apply_chat_template, który sam skleja wiadomości w format właściwy dla danego modelu.⁷ W llama.cpp odpowiada za to --jinja. Morał krótki: zajrzyj do karty i upewnij się, który to wariant, zanim ogłosisz, że „model jest słaby".

Benchmarki? Tak, ale z ręką na sercu

I na koniec ta tabelka, przez którą w ogóle klikasz „Download" — słupki, w których nowy model bije wszystko dookoła. Model card może nawet nieść ustrukturyzowane wyniki w polu model-index, z zadaniem, datasetem, metryką i źródłem.¹ Fajnie. Tylko traktuj to jak deklarację producenta, nie jak wyrok.

Jest udokumentowany problem zwany benchmark data contamination: dane testowe benchmarku wyciekają do zbioru treningowego modelu, przez co wynik na tym teście rośnie bez realnej poprawy jakości.⁸ Model po prostu „widział odpowiedzi" na egzaminie. To nie teoria spiskowa — poświęcono temu prace przeglądowe. Dlatego liczba w tabelce mówi ci co najwyżej, że warto sprawdzić samemu na swoim zastosowaniu, a nie że sprawa zamknięta. Najlepszy benchmark i tak jest jeden: twój własny prompt, którego nikt nie mógł wcześniej wkuć.

Zrób to sam: lista na lodówkę

Cała ta gadka sprowadza się do sześciu spojrzeń w kartę modelu, zanim ruszysz pobieranie:

Wydrukuj, przyklej nad biurkiem, albo po prostu zapamiętaj rytm: waga, licencja, kontekst, wsparcie, wariant, benchmarki. Przy trzecim nowym modelu przejdziesz to odruchowo.

Bo świeży model to trochę jak używane auto z ogłoszenia: zdjęcia lśnią, opis zachwala, scena piszczy z zachwytu. Ale to ty siadasz za kierownicą i to ty potem stoisz na poboczu, jak się okaże, że pod maską nie ma silnika pasującego do twojej karty. Pięć minut zaglądania pod maskę — kartę modelu — kosztuje mniej niż wieczór klikania w „czemu to nie działa".