I to jest jedno z tych przekonań, które żyje własnym życiem, choć z prawdą ma niewiele wspólnego. Bo llama.cpp — silnik, na którym stoi pół tego lokalnego światka — od samego początku był pisany pod jedną obietnicę: odpalać modele „na szerokim zakresie sprzętu", lokalnie i w chmurze, w czystym C/C++ bez ciężkich zależności.¹ CUDA jest w tym zestawie, jasne. Ale jest jedną z kilkunastu opcji, nie warunkiem wejścia.

Co to w ogóle jest „backend"

Zajrzyj pod maskę llama.cpp, a znajdziesz ggml — bibliotekę, która robi całą matematykę modelu. I tu wchodzi słowo klucz: backend. To po prostu moduł ggml, który wie, jak wykonać te wszystkie mnożenia macierzy na konkretnym rodzaju sprzętu. Jeden backend gada z układem NVIDIA. Inny z GPU Apple. Jeszcze inny z byle czym, co ma sterownik Vulkana.

Domyślnym, zawsze dostępnym backendem jest CPU. Zwykły procesor, ten sam, na którym odpalasz przeglądarkę. Zbudujesz llama.cpp bez ani jednej flagi akceleracji i model i tak ruszy — wolniej niż na GPU, ale ruszy.² To jest ta część, o której cała ta litania zapomina wspomnieć: żeby cokolwiek pogadało lokalnie, karta graficzna nie jest ci technicznie potrzebna. Jest ci potrzebna, żeby było szybko. A to już zupełnie inna rozmowa.

Ilu tych backendów w ogóle jest?

Więcej, niż podejrzewasz. Oficjalna tabela w README ciągnie się przez kilkanaście pozycji: Metal, BLAS, SYCL, CUDA, HIP, Vulkan, MUSA, CANN, OpenCL, ZenDNN, WebGPU, IBM zDNN, Hexagon i jeszcze parę egzotów.¹ Większości z nich w życiu nie dotkniesz — Ascend NPU czy IBM Z & LinuxONE to sprzęt, którego nie trzymasz pod biurkiem. Ale te, które realnie decydują o tym, czy twój sprzęt załapie się na zabawę, dają się policzyć na palcach:

Zanim pójdziemy dalej — jedna rzecz, która lubi umykać, a jest w tym wszystkim kluczowa. Te flagi z -D na przedzie to opcje budowania, czyli kompilacji. llama.cpp bierzesz w postaci kodu źródłowego i raz zamieniasz go w gotowy program — tym właśnie jest budowanie, a robi to cmake. I to na tym etapie, przed pierwszym uruchomieniem, mówisz, jakie backendy wkompilować. Nie podajesz -DGGML_CUDA=ON przy odpalaniu modelu — podajesz to raz, zanim plik wykonywalny w ogóle powstanie. Potem uruchamiasz już gotową binarkę, a ona z góry wie, na czym ma liczyć.

Przejdźmy tę listę tak, jak się ją czyta w praktyce — od strony pytania „a co ja mam w obudowie".

Masz NVIDIA? No to CUDA, ta zamknięta platforma obliczeniowa NVIDIA, która działa tylko na ich kartach. Włączasz ją flagą -DGGML_CUDA=ON przy budowaniu.² To ta najbardziej wydeptana ścieżka, o której wszyscy piszą — i faktycznie działa jak trzeba. Tylko że wydeptana nie znaczy jedyna.

Masz MacBooka na Apple Silicon? Tu jest najlepszy żart całej układanki: nie musisz robić absolutnie nic. Backend Metal — natywne API GPU Apple — jest na macOS włączony domyślnie. Budujesz llama.cpp normalnie i twój M2 czy M3 od razu liczy na GPU. Chcesz go z jakiegoś powodu wyłączyć? Musisz się wręcz postarać: -DGGML_METAL=OFF.² Zunifikowana pamięć w Makach robi tu robotę, o której właściciele osobnych kart mogą tylko pomarzyć.

Masz Radeona albo GPU Intela? I tu robi się najciekawiej, bo to dokładnie ci ludzie, których ta litania odprawia z kwitkiem. A mają aż dwie drogi.

Vulkan, czyli furtka dla całej reszty

Gdybym miał wskazać jeden backend, o którym za mało się mówi, to Vulkan. To otwarte, wieloplatformowe API graficzno-obliczeniowe (ta sama Khronos, co od OpenGL-a), które obsługuje mnóstwo sterowników GPU — NVIDIA, AMD, Intela. W llama.cpp włączasz je jedną flagą, -DGGML_VULKAN=ON, i dostajesz akcelerację GPU działającą cross-platform, na Windowsie, Linuksie i macOS naraz — bez instalowania dedykowanych, ciężkich stosów producenta.³

I to jest sedno. Bo alternatywą dla AMD jest HIP/ROCm — cały software’owy stos AMD do liczenia na GPU (HIP to interfejs w jego ramach, pozwalający pisać kod zbliżony do CUDA; to nie osobny produkt, tylko część tego samego ekosystemu). Bywa wydajniejszy od Vulkana, ale kosztuje cię więcej zachodu przy konfiguracji i samym budowaniu. Zobacz, jak to wygląda:

HIPCXX="$(hipconfig -l)/clang" HIP_PATH="$(hipconfig -R)" \
  cmake -S . -B build -DGGML_HIP=ON -DGPU_TARGETS=gfx1030 -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release

gfx1030 to nie ozdobnik — to kod architektury twojego konkretnego układu AMD, który musisz najpierw poznać i podać ręcznie.⁴ U Intela jest podobnie: backend SYCL (otwarty standard programowania heterogenicznego, którym Intel wozi swoje GPU przez oneAPI) ma na tyle osobną drogę budowania, że w repo doczekał się własnego pliku dokumentacji, obok głównego build.md.⁵ Nikt nie mówi, że to zabawa bez łzawienia. Ale że się da — da się.

A jeśli GPU w ogóle nie ma?

Zostaje CPU — i wcale nie jesteś skazany na gołą, referencyjną implementację. Masz BLAS (np. OpenBLAS), który przyspiesza obliczenia na procesorze i włącza się parą flag -DGGML_BLAS=ON -DGGML_BLAS_VENDOR=OpenBLAS.² A jak siedzisz na czymś bardziej konkretnym, llama.cpp ma nawet backendy skrojone pod rodzinę procesora: ZenDNN pod serwerowe CPU AMD EPYC i Arm KleidiAI pod układy Arm — obok generycznego CPU.² Mrówcza robota optymalizacyjna, o której mało kto wie, a która potrafi wycisnąć z krzemu, który już masz, zaskakująco dużo.

Zrób to sam

Powiedzmy, że budujesz llama.cpp sam (a warto — rozbieraliśmy jego flagi po kolei, bo to na nich jedzie pół ekosystemu, od Ollamy po LM Studio). Najprostszy build, sam CPU, bez żadnych ozdobników:

cmake -B build
cmake --build build --config Release

Chcesz akcelerację? Dokładasz jedną flagę pod swój sprzęt — -DGGML_CUDA=ON, -DGGML_VULKAN=ON, -DGGML_HIP=ON — i tyle. Co więcej, backendy da się łączyć w jednym buildzie (CUDA i Vulkan naraz to normalka), a którym urządzeniem policzysz, wybierasz już w locie, przy odpalaniu:

llama-cli --list-devices
llama-cli -m model.gguf --device Vulkan0
llama-cli -m model.gguf --device none

--list-devices pokaże ci wszystkie akceleratory, które build widzi, --device wskaże ten jeden, a --device none każe liczyć wyłącznie na CPU — wygodne, gdy chcesz zobaczyć, ile tracisz bez GPU.⁶ I jedno, co warto rozdzielić w głowie raz na zawsze: wybór backendu to nie to samo co kwantyzacja modelu. Format GGUF i to, czy bierzesz Q4 czy Q8 (nazwy rozbieraliśmy osobno), to jedna decyzja — na czym to policzysz to zupełnie druga. Ten sam plik .gguf pojedzie na CUDA, na Vulkanie i na gołym procesorze. Nie mieszaj tych dwóch pokręteł, bo to niezależne osie.

Cała aktualna prawda o budowaniu siedzi w jednym pliku: docs/build.md w repo ggml-org/llama.cpp. Sekcja po sekcji, backend po backendzie.

Bo ta redditowa litania „NVIDIA albo nic" to trochę jak stać przed budynkiem z jednymi oszklonymi drzwiami frontowymi, na które wszyscy się pchają, i nie wiedzieć, że dookoła jest jeszcze pięć wejść — węższych, gorzej oznaczonych, część z lekko zacinającą się klamką, ale prowadzących do tego samego środka. Zielona karta to najwygodniejsze drzwi. Nie jedyne.

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

To jest ten moment, w którym większość ludzi bierze na chybił trafił ten Q4_K_M, bo tak radzą na Reddicie, odpala i idzie dalej. I słusznie — działa. Ale pod tym jednym plikiem stoi cała cicha fabryka: ludzie, narzędzia, konwersje i format, który ktoś kiedyś usiadł i zaprojektował, żebyś ty mógł zrobić dwuklik. Warto wiedzieć, co tam mruczy pod maską — bo dzięki temu przestajesz zgadywać, a zaczynasz wybierać świadomie.

Co to w ogóle jest, ten GGUF

Zacznijmy od rozczarowania, bo lepiej od razu: GGUF to nie jest model. To nie nowa architektura, nie nowy sposób trenowania, nie magiczny AI od ggerganova. To pojemnik. Format pliku — dosłownie „GGML Universal File” — do trzymania modelu na dysku tak, żeby silnik inferencyjny mógł go szybko wczytać i zacząć gadać.¹ Model (Llama, Qwen, Mistral — cokolwiek) rodzi się gdzie indziej, w treningu na klastrze, którego rachunku za prąd żaden z nas nie chciałby zobaczyć. GGUF to dopiero opakowanie, w które ten wytrenowany model się przepakowuje na koniec, pod kątem tego, że odpalisz go u siebie na jednej karcie.

Format wymyślił Georgi Gerganov, ten sam, który stoi za llama.cpp i biblioteką ggml.² GGUF jest następcą kilku starszych formatów o równie uroczych nazwach — GGML, GGMF, GGJT — które po drodze się wykruszyły. I tu pierwsza pułapka, w którą łatwo wdepnąć: GGML i GGUF to nie synonimy. GGML to ten stary, w dużej mierze wyparty format pliku (i przy okazji wciąż nazwa biblioteki tensorowej pod spodem), a GGUF to jego młodszy, mądrzejszy brat z porządnymi metadanymi.¹

Co siedzi w tym jednym pliku

To jest właśnie sedno, dla którego GGUF wygrał. Otwórz sobie w głowie taki plik jak pudełko z przegródkami:

• Nagłówek — na samym początku cztery bajty GGUF (magic number, bajt po bajcie 0x47 0x47 0x55 0x46), zaraz za nimi numer wersji formatu, liczba tensorów i sterta metadanych.¹
• Metadane klucz-wartość — i tu robi się ciekawie. Zamiast beztypowej listy liczb jak w starych formatach, GGUF trzyma nazwane pola w hierarchii z kropkami: general.architecture, llama.context_length, general.quantization_version. Klucz general.architecture (czym ten model właściwie jest) musi być zawsze, a jak model jest skwantowany, to musi być też general.quantization_version.¹
• Tokenizer — w środku, w tym samym pliku. To jest ten myk, którego naprawdę brakowało wcześniej. GGUF potrafi wnieść cały tokenizer: natywne tablice tokenów, scores i merges, albo pełny tokenizer.json prosto z Hugging Face, albo szablony czatu w Jinja.¹ Dlatego jeden .gguf wystarcza — nie musisz dociągać pięciu plików obok.
• Same wagi — na końcu surowe dane tensorów, wyrównane do granicy (domyślnie co 32 bajty, klucz general.alignment), żeby silnik mógł je wczytać przez mmap bez mielenia całego pliku.¹

Skąd biorą się wszystkie te warianty

No dobra, a czemu tego samego modelu jest dwadzieścia sztuk? Bo GGUF wspiera całą tęczę typów tensorów: pełną precyzję (F32, F16, BF16), serię K (Q2_K do Q6_K), stare legacy (Q4_0, Q8_0), nowszą serię IQ opartą na macierzy istotności (IQ4_XS, IQ2_XXS) i egzotykę w stylu ternarnego TQ1_0.¹ Każdy z tych Q-ów to inny schemat ściśnięcia wag. Q4_K upycha wagę w jakichś 4,5 bita, Q6_K w 6,56, Q2_K w 2,63 — i to są dokładnie te przegródki, w których leży cały kompromis rozmiar/jakość/szybkość.²

I tu druga pułapka: te warianty to nie są różne modele. Q4_K_M, Q5_K_S, Q8_0 tego samego modelu to te same wagi bazowe, tylko skompresowane innym sitem. Grubszy plik = bliżej oryginału i wolniej, chudszy = mniej VRAM-u i szybciej, ale z lekkim ubytkiem jakości. Co ważne, to jest kwantyzacja post-training — bierzesz gotowy, wytrenowany model i ściskasz go po fakcie. Nie mylić z trenowaniem od zera w niskiej precyzji. W nazewnictwo tych literek zagłębialiśmy się osobno tutaj, bo to temat na własny wpis.

Kto to wszystko właściwie robi

Teraz najlepsze. Ten Q4_K_M, który ściągasz — bardzo często nie zrobił go autor modelu. Autor wrzuca zwykle wagi w safetensors i może jedną-dwie wersje GGUF, a resztę tego bufetu produkują ludzie z boku: community-quantizerzy. Konta jak bartowski czy mradermacher (dawniej głośny TheBloke) siedzą i masowo mielą cudze modele na wszystkie możliwe warianty, dzień po dniu, jak taka lokalna piekarnia GGUF-ów.

Jak to robią bez klastra? Dwiema drogami. Pierwsza to skrypt convert_hf_to_gguf.py prosto z repo llama.cpp — łyka wagi z Hugging Face i wypluwa GGUF, obsługuje kupę architektur (w tym multimodalne i MoE), ma opcje --outtype (bierzesz f16, bf16, q8_0… — czym te „szesnastki" różnią się od siebie, jest tu), --vocab-only, --split-max-size do krojenia wielkich plików, a nawet --remote, żeby konwertować prosto z Huba.³ Druga droga jest jeszcze leniwsza: ggml-org/gguf-my-repo, gotowy Space na Hugging Face, gdzie wklejasz repo, klikasz i dostajesz komplet kwantyzacji bez kompilowania czegokolwiek u siebie.⁴

# klasyczna droga: własny build llama.cpp
python convert_hf_to_gguf.py ./Qwen2.5-7B-Instruct \
  --outtype f16 --outfile qwen2.5-7b-f16.gguf
# a potem osobno kwantyzacja narzędziem llama-quantize do Q4_K_M itd.

Sam Hugging Face traktuje ten format jak pełnoprawnego obywatela: masz filtr library=gguf, który pokazuje wszystko, co gęgnięte (hf.co/models?library=gguf), a na stronie konkretnego pliku podejrzysz metadane i listę tensorów wprost z przeglądarki, bez ściągania.² Praktyczny wniosek: skoro warianty sypie kto chce, sprawdzaj, czyje repo bierzesz. Zerknij na autora, na to, czy imatrix był użyty, czy karta modelu ma ręce i nogi. Na co patrzeć przy świeżym modelu rozkładaliśmy w osobnej notce.

GGUF kontra safetensors: to nie jest ranking

Skoro autor wrzuca safetensors, a ty odpalasz GGUF — który jest lepszy? Źle postawione pytanie. To dwa pojemniki do dwóch różnych rzeczy.

Safetensors narodził się z zupełnie innej potrzeby: żeby nie ładować cudzych wag przez pickle (który potrafi odpalić dowolny kod przy wczytaniu) i żeby robić to szybko, bez kopiowania w pamięci.⁵ To rekomendowany format wag na Hugging Face — ale trzyma wyłącznie tensory. Chcesz z niego odpalić model, musisz dorzucić config i tokenizer obok. GGUF ten cały komplet nosi w sobie i dokłada kwantyzację. Nie „lepszy/gorszy” — inne zadanie. Jak chcesz to potem faktycznie uruchomić garścią flag, jest o tym osobny poradnik.

Wróć do tego menu

Wróć teraz do tego menu na Hugging Face, do listy dwudziestu plików kończących się na .gguf. Już nie wygląda jak bar mleczny, w którym wszystko nazywa się tak samo. Widzisz teraz, że ktoś wziął model wytrenowany na drugim końcu świata, przepuścił go przez convert_hf_to_gguf.py, upchał wagi, architekturę i tokenizer do jednego pudełka z przegródkami, ścisnął sitem Q4_K_M i wrzucił na Huba, żebyś ty mógł go zassać jednym plikiem i usłyszeć, jak mruczy pod biurkiem. Cała ta cicha fabryka — od klastra treningowego, przez konto bartowskiego, po twój dysk — sprowadza się do jednego czterobajtowego napisu na początku pliku: GGUF. Reszta to już tylko ty i pytanie, który wariant dziś bierzesz.