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