Maszyneria modelu

Plik z wagami jest martwy. Nie ma w nim pętli, nie ma decyzji, nie ma niczego, co samo się uruchomi. Żeby powstała odpowiedź, ktoś musi ten plik wczytać, rozłożyć na operacje, rozdzielić je na sprzęt i policzyć — token po tokenie, od nowa przy każdym słowie.

Ta warstwa nazywa się runtime i to ona decyduje o wszystkim, co użytkownik naprawdę odczuwa: ile czeka na pierwsze słowo, ile go to kosztuje, gdzie kończy się kontekst i dlaczego ten sam model raz odpowiada natychmiast, a raz stoi w kolejce.

Te same wagi żyją dziś w trzech zupełnie różnych maszyneriach. Na dysku użytkownika, gdzie widać wszystko. Za HTTP, gdzie nie widać niczego. I w oknie czatu, gdzie między człowiekiem a modelem stoi jeszcze cały produkt. Prawie wszystko, co przypisujemy modelowi, robi jedna z tych trzech.

Ta seria jest o nich.

Dwanaście artykułów w trzech torach — od tego, co runtime robi z plikiem wag, przez kwantyzację, pamięć i dwie fazy generowania, po kolejki, batching i cache po stronie dostawcy, aż po to, co okno czatu dokłada od siebie. Każdy artykuł jest samodzielny. Razem odpowiadają na jedno pytanie: ile z tego, co widzisz, to naprawdę model.

Tor lokalny jest tu grupą kontrolną, nie tematem. Nie chodzi o uruchamianie modeli u siebie — chodzi o to, że jest to jedyne miejsce, w którym mechanizm da się zobaczyć, zanim wytłumaczymy ten sam mechanizm tam, gdzie jest schowany za cudzym serwerem.

Dlatego w tej serii nie ma kodu do wklejenia. Jest kod, który już działa: część artykułów ma widget, w którym mechanizm wykonuje się na urządzeniu czytelnika, na jego danych, w trakcie czytania. Tekst i widget da się czytać osobno.

Jeśli czytałeś Anatomię LLM — tamta mówi, z czego model jest zbudowany, ta mówi, co go wykonuje. Jeśli czytałeś Maszynerię agenta — tamta idzie od granicy modelu w górę, ta schodzi od niej w dół. Jeśli zaczynasz tutaj, zacznij od artykułu pierwszego. Bez benchmarków, bez „odpal sobie LLM w pięć minut", z linkami do słownika przy każdym nowym pojęciu.

Ta seria jest dla osób, które chcą rozumieć, dlaczego ten sam model raz odpowiada natychmiast, a raz stoi w kolejce; dlaczego kontekst urywa się szybciej niż cierpliwość; i ile z tego, co widzisz w czacie, to naprawdę model, a ile runtime i produkt.

Tor 1 - Na twoim urządzeniu

Jedyne miejsce, w którym widać wszystko.

Plik z wagami leży na dysku i wiesz, który to plik. Runtime działa w twoim procesie, pamięć jest twoja i kończy się w sposób, który widać. Nic nie jest ukryte, nic nie jest współdzielone, nic nie zależy od cudzych decyzji.

Pięć artykułów o mechanizmie oglądanym z bliska: rozmiar wag, przepustowość pamięci, kwantyzacja, rosnąca historia rozmowy i dwie fazy generowania. Ten tor nie jest o uruchamianiu modeli u siebie — jest po to, żeby zobaczyć mechanizm, zanim spotkasz go tam, gdzie jest schowany.

Tor 2 - Za API

Ten sam mechanizm, tylko na cudzym serwerze.

Wysyłasz prośbę, dostajesz odpowiedź. Pomiędzy jest maszyna, na której twoja prośba stoi w kolejce razem z dwustoma innymi, jest przetwarzana partiami i podlega optymalizacjom, o których nie wiesz. Zmierzyć możesz dwie rzeczy: czas i rachunek.

Cztery artykuły o tym, jak z mechanizmu z pierwszego toru wynika wszystko, co odczuwasz jako dziwactwa API — kolejki, limity, zmienne opóźnienie i dwie kolumny w cenniku. Ten tor czyta się najlepiej, jeśli wiesz już, dlaczego generowanie marnuje kartę w dziewięćdziesięciu ośmiu procentach.

Tor 3 - W oknie czatu

Między tobą a modelem stoi jeszcze produkt.

Nad wszystkim powyżej siedzi warstwa, której nikt nie pokazuje: instrukcja systemowa, historia przepisywana od zera przy każdej turze, wyszukiwarka, pamięć, narzędzia, moderacja. Rozmawiasz z modelem mniej więcej w takim stopniu, w jakim rozmawiasz z kuchnią, składając zamówienie u kelnera.

Dwa artykuły, celowo wąskie — wyłącznie o tym, co w oknie czatu nie jest modelem. Jak zbudować własną pętlę, opisuje osobna seria; ta pokazuje pętlę, którą ktoś napisał za ciebie i sprzedaje jako produkt.