Konwertujesz model do GGUF-a, widzisz --outtype f16 i --outtype bf16, i przez sekundę udajesz przed samym sobą, że wiesz, którego wybrać. Rozbieramy te formaty na bity — znak, wykładnik, mantysa — i tłumaczymy, czemu bf16 wygrał trening ML, choć jest mniej dokładny niż f16.
Wpisujesz llama-cli --help i dostajesz ścianą flag prosto w twarz. Rozbieramy te, które realnie decydują, czy model wejdzie na twój sprzęt i jak szybko będzie gadał.
Wchodzisz na kartę modelu na Hugging Face, a tam kolumna pełna szyfrów: Q4_K_M, Q5_K_S, IQ2_XXS. Rozbieramy te nazwy litera po literze — żebyś wiedział, który plik pobrać, a nie zgadywał.
Wagi się załadowały, model wszedł na kartę z zapasem — a po dłuższej rozmowie znów wyskakuje out of memory. Winny nie jest model. Winny jest bufor, który puchnie z każdym tokenem.
Nowy model, ładna karta modelu, a na dole jedno zdanie: 16 GB VRAM. Ty masz te swoje 8. Zamiast wróżyć z fusów, policzmy na palcach, ile naprawdę zważy — i jak zejść niżej.
Chcesz, żeby lokalny model gadał o twoich notatkach, a nie o Wikipedii sprzed treningu. Rozbieramy RAG na części: chunking, embeddingi, baza wektorowa, retrieval — i tłumaczymy, czego on NIE załatwia.
Duży model musi robić pełny przebieg dla każdego pojedynczego tokena — stąd ten mielący rytm generacji. Speculative decoding łamie ten rytm: mały model zgaduje kilka tokenów naprzód, duży sprawdza je hurtem. I najlepsze: bez utraty jakości.
Prosisz model o czysty JSON, a dostajesz esej, blok w markdownie i przecinek w złym miejscu. Gramatyki GBNF w llama.cpp odbierają mu wybór: model może wypluć tylko te tokeny, które pasują do reguł. Rozbieramy, jak to działa na poziomie samplera.
Instalujesz Ollamę, model gada od strzału i myślisz: magia. A pod tym ładnym `ollama run` siedzi ten sam silnik, co pod resztą. Rozbieramy, kto tu jest maszyną, a kto tylko obudową.