Kategoria: Lokalne AI
Ten spis zbiera pojęcia, które wracają w moich tekstach o lokalnym AI i o autonomii, i daje przy każdym jedno zdanie definicji. Przy pojęciach, które da się zmierzyć, dopisuję liczbę i odsyłam do tekstu, w którym ją liczę.
Liczby pochodzą z jednej maszyny: AMD Ryzen AI 9 HX 470, 24 rdzenie, zintegrowana grafika Radeon 890M, dysk NVMe 1 TB. Prędkości generowania to seria pomiarów z września 2026, wykonana przy 32 GB pamięci współdzielonej; odczyty po rozbudowie do 64 GB pochodzą z października 2026. W każdym tekście liczba jest oznaczona jako pomiar, odczyt albo rachunek i tak należy ją czytać.
Architektura modelu
LLM
Model generujący tekst token po tokenie, od lewej do prawej. Kiedy ktoś mówi „model AI”, prawie zawsze ma na myśli właśnie to. Dwie inne rodziny z otwartymi wagami, JEPA i LLaDA, działają na innej zasadzie.
Model gęsty (dense)
Model, który do wygenerowania każdego tokena wykorzystuje wszystkie swoje parametry. Model o 30 miliardach parametrów przepuszcza przez siebie całe 30 miliardów, token po tokenie, i dlatego gęsta dwunastka bywa wolniejsza od MoE o rozmiarze 30B.
MoE (mieszanka ekspertów)
Model, który ma łącznie tyle samo parametrów co model gęsty tej samej nominalnej wielkości, ale na jeden token aktywuje tylko ich ułamek, zwykle 3-4 miliardy. Pozostałe zajmują pamięć, a w danym kroku nie liczą. Rozpisałem to na czterech pomiarach.
Parametry aktywne
Liczba parametrów, którą trzeba odczytać z pamięci na jeden token. To ona decyduje o prędkości, a nie rozmiar pliku ani liczba w nazwie. Oznaczenie „A3B” w nazwie Qwen3-Coder 30B-A3B znaczy: trzydzieści miliardów łącznie, trzy miliardy aktywne na token.
JEPA
Architektura zaproponowana przez Yanna LeCuna w 2022 roku, która przewiduje reprezentację zasłoniętego fragmentu, a nie następny token. Nie pisze tekstu, nie rysuje obrazów i nie prowadzi rozmowy; na wyjściu daje wektory do dalszego użycia. Wersje z otwartymi wagami zestawiłem osobno.
Dyfuzyjny model tekstowy (LLaDA)
Model językowy, który nie pisze od lewej do prawej, tylko odsłania cały blok tokenów naraz, od pozycji najpewniejszych. LLaDA to skrót od „large language diffusion with masking”. Odsłanianie bloku nie znaczy, że jest szybszy: jeden blok to kilka pełnych przejść sieci.
Rozmiar pliku i precyzja
Kwantyzacja
Zapis wag modelu w obniżonej precyzji, żeby plik zmieścił się w pamięci. Na domowej maszynie nie jest optymalizacją, a warunkiem uruchomienia: model o 27 miliardach parametrów po 16 bitów na wagę to około 54 GB, czyli więcej, niż ta maszyna ma pamięci w całości. Liczby i formaty zebrałem tutaj.
Bity na wagę
Rozmiar pliku razy osiem, podzielony przez liczbę parametrów. Dla pliku 16 GB i modelu 27 mld wychodzi około 4,7 bita na wagę. To działanie zastępuje czytanie opisu modelu i pozwala sprawdzić, czy dwa modele wolno porównywać między sobą.
Q4_K_M
Nazwa formatu z llama.cpp, w którym większość wag jest zapisana na 4 bitach, a warstwy najbardziej wrażliwe na błąd na większej liczbie bitów. Dla wierszy Qwen w mojej serii wychodzą z tego wyniki w rodzaju 4,7 czy 4,8 bita na wagę, a nie równe 4. Nie jest to format całej tabeli, ponieważ pięć wierszy ma inne pochodzenie.
QAT (trening z uwzględnieniem kwantyzacji)
Model uczony od razu w niskiej precyzji, więc jego 4 bity są wynikiem treningu, a nie kompresji po treningu. Różnica jest merytoryczna, nie nazewnicza, i dlatego takiego wiersza nie wolno wrzucać do jednego worka z modelem skwantowanym na końcu.
Pamięć
Pamięć współdzielona
W mini PC ze zintegrowaną grafiką procesor i grafika korzystają z tej samej pamięci systemowej. Przepustowość wynosi tu około 50-70 GB/s, podczas gdy RTX 4090 przekracza 1 TB/s, i to jest wąskie gardło, a nie moc obliczeniowa.
Okno pamięci zintegrowanej grafiki
Wycięty z pamięci systemowej kawałek o stałym rozmiarze, w którym grafika może trzymać wagi modelu. U mnie firmware wystawia około 19 GB (odczyt, październik 2026) i po przejściu z 32 na 64 GB ta liczba nie drgnęła.
Okno kontekstu
Maksymalny rozmiar notatnika rozmowy: tyle tokenów prompt i odpowiedź mogą zająć razem. Kiedy limit jest ciasny, pierwsze tury wypadają i wygląda to tak, jakby model zignorował instrukcję, choć to nie halucynacja, tylko limit.
Bufor klucz-wartość (cache KV)
Przeliczona postać całej dotychczasowej rozmowy, trzymana w pamięci obok wag modelu, żeby nie liczyć tego samego od początku. Rośnie z każdym tokenem: okno 128 tys. tokenów zajmuje u mnie około 4 GB ponad wagę modelu (pomiar, październik 2026), czyli w przybliżeniu 1 GB na każde 32 tys. tokenów. Tego kosztu nie widać w rozmiarze pliku.
Cache prefiksu
Pominięcie ponownego liczenia tej samej początkowej części promptu, jeśli każda tura zaczyna się od tego samego długiego polecenia systemowego. W moim teście z promptu liczącego 45 066 tokenów ponad 45 tys. zostało odczytane z cache (pomiar, październik 2026), razem z dwoma innymi sposobami na dłuższy kontekst.
Wzór na pamięć
Rozmiar pliku modelu plus 1 GB na każde 32 tys. tokenów kontekstu plus 4-6 GB na system i aplikacje. Dla modelu 21 GB z oknem 64 tys. tokenów wychodzi 27-29 GB (rachunek, nie pomiar); trzy progi pamięci wyprowadzam z tego samego rachunku.
Zapas na system
To, co zostaje w pamięci po wejściu modelu: miejsce dla serwera inferencji, notatnika rozmowy i reszty procesów. Przy 32 GB i modelu zajmującym 15-19 GB zostaje 13-17 GB, ale nie na drugi model tej wielkości. Przy 16 GB ten zapas schodzi do 1,6-4,6 GB.
Prędkość
Tokeny na sekundę (tok/s)
Tempo generowania tekstu, mierzone w jednym strumieniu. Człowiek czyta w tempie około 4-5 tokenów na sekundę, a powyżej 10 tekst pojawia się szybciej, niż można go przeczytać, i to jest cała definicja „wystarczająco szybko”.
Sufit prędkości
Najwyższy wynik, jaki na danej maszynie osiąga którykolwiek model. W mojej serii jest to 45,7 tokena na sekundę na małym modelu gęstym, i jest to górna granica całej tabeli, a nie jej środek. Każdy model gęsty od 27 miliardów parametrów w górę jest poniżej progu 10.
Przedział MoE
Modele MoE utrzymują w tej serii zwykle 21-33 tokenów na sekundę: jedenaście z trzynastu wpisów MoE mieści się w tym przedziale, a dwa pozostałe osiągają 16,3 i 17,86 i oba mają w nazwie „35B”. Rozmiar w nazwie nie przesądza o wyniku.
Offload warstw na grafikę
Przeniesienie warstw modelu z procesora na zintegrowaną grafikę, w llama.cpp parametrem -ngl. Dopóki wagi mieszczą się w oknie pamięci grafiki, przyspiesza odpowiedź około 3-6 razy (pomiar z mojej maszyny); po rozbudowie pamięci to nadal ono decyduje o prędkości, nie liczba gigabajtów.
Spekulatywne generowanie tokenów
Rodzina metod, w których coś mniejszego zgaduje kilka tokenów naprzód, a duży model je weryfikuje. Należą do niej klasyczne speculative decoding, MTP, EAGLE-3 i DFlash; różnią się tym, kto zgaduje i czego do tego potrzebuje.
MTP (multi-token prediction)
Wariant, w którym zgaduje sam model, przy użyciu dodatkowych głowic albo dołączonego draftera. Obsługa weszła do llama.cpp 16 maja 2026 i działa tylko z plikiem GGUF zawierającym głowice MTP. Przełączniki i warunki opisałem osobno.
DFlash
Metoda z 2026 roku, w której tokeny proponuje mały model dyfuzyjny, a duży LLM je weryfikuje. Integracje serwerowe są w toku, w llama.cpp jej nie ma, więc na domowej maszynie z plikami GGUF dziś jej nie uruchomisz.
Czytanie promptu
Czas, w którym model czyta cały prompt, zanim napisze pierwszy token. W rozmowach powyżej 50 tys. tokenów to czytanie zaczyna dominować i w pętlach z narzędziami odpowiada u mnie za większość oczekiwania (obserwacja z pracy, nie benchmark). Wszystkie prędkości, które podaję, to generowanie.
Stos i rachunek
Silnik inferencji
Warstwa, która ładuje plik modelu, rozkłada jego warstwy na sprzęt i generuje tokeny. U mnie jest to llama.cpp, druga z trzech warstw stosu na Ubuntu Server.
Brama API
Warstwa przed silnikiem, która wystawia jeden adres zgodny z API OpenAI, żeby klientów nie trzeba było przestawiać przy każdej zmianie modelu. U mnie jest to LiteLLM i najłatwiej ją pominąć na starcie, a najdrożej dodać później.
Tryb routera (jeden model naraz)
Ustawienie, w którym silnik trzyma w pamięci jeden model i przełącza go na żądanie. Przełączenie kosztuje 30-60 sekund, więc dwa modele naraz na jednej takiej maszynie nie działają.
Stan jałowy
Pobór mocy maszyny, która jest włączona i nie wykonuje pracy. U mnie 3-8 W, przy obciążeniu szczytowym około 130 W (pomiar własny). O rachunku decyduje pierwsza liczba, bo domowy serwer AI przez większość doby nic nie liczy.
Próg zwrotu
Liczba miesięcy, po której koszt maszyny zrównuje się z kosztem abonamentu: cena sprzętu podzielona przez różnicę między abonamentem a rachunkiem za prąd. Kwota abonamentu jest założeniem, nie pomiarem, a jeśli po kupieniu maszyny nadal płacisz abonament, oszczędność wynosi zero.
Offline
Odcięcie modelu od sieci, które jest zmianą łańcucha dostaw, a nie ustawieniem zapory. Co się przez to realnie zmienia w danych klienta, opisałem osobno, razem z tym, czego offline nie rozwiązuje.
Automatyzacja i autonomia
Poziomy autonomii
Pięć poziomów opisanych jednym pytaniem: czy system ma działać sam, czy ma pytać. Poziomy 1-3 to telemetria, prognoza i raport, poziom 4 to propozycja wykonawcza z człowiekiem w pętli, poziom 5 to pełna władza. Awans o poziom jest decyzją, nie efektem działania.
Agent AI
Model, który sam decyduje, co zrobić: dostaje cel, sam planuje kroki, sam dobiera narzędzia i sam wykonuje. Dlaczego nie zbudowałem swojego systemu w ten sposób, rozpisałem na czterech warstwach architektury.
Cyfrowy bliźniak
Układ, w którym decyzje są zapisane w przepływach danych, a nie podejmowane przez model. Układ jest rozdzielony na części, z jasnymi drogami danych i bez agentów w środku. To nie jest agent AI i to jest cała różnica.
Licznik zaufania
Miara na pojedynczą operację, a nie na cały system: po pięciu zgodach z rzędu bez korekty system przestawia tę jedną operację z trybu „zapytaj” na tryb „wykonaj i pokaż wynik”. Miesiąc, w którym mój system przestał pytać, zaczął się właśnie od tego licznika.
Tryb wycofania
Przetestowana droga powrotu, którą musi mieć każda automatyzacja dotykająca pieniędzy, zdrowia lub rzeczy prywatnych, i sprawdzona zanim włączę ją na stałe. Automatyzacje, które u mnie zostały, i te, które wycofałem.
Promień rażenia
Zasięg szkody, jaką może zrobić jeden błędny skrypt albo jeden wyciek. Osiem baz danych nie przyspiesza u mnie niczego, ponieważ są podzielone dla izolacji, nie dla szybkości.
Jedna droga dostępu
Reguła, że żaden skrypt nie łączy się z bazą sam. Jest ważniejsza niż sam podział na bazy i to ona trzyma ten układ w całości.
Punkt odniesienia
Zmierzony ręczny wariant czynności, bez którego nie da się podać, ile czasu oszczędza automatyzacja. Nie mam go dla automatyzacji z ostatnich lat, więc nie wiem, ile czasu oszczędza mój system. Reguła na przyszłość jest jedna: zmierz ręczny wariant, zanim go zautomatyzujesz.
Konwencja nazewnictwa
Schemat nazw encji, w którym kolejne człony oznaczają urządzenie, numer węzła, numer dziecka i typ wartości. Jest jedną z tych rzeczy, które decydują o tym, że po siedmiu latach Home Assistant w domu to bardziej problem konfiguracji niż sprzętu.
Cztery liczby, których tu nie ma
Nie ma tu kosztu kwantyzacji w jakości odpowiedzi: nie przepuściłem tych modeli przez zestaw testowy w dwóch precyzjach. Nie ma czasu czytania promptu z benchmarku, ponieważ wszystkie prędkości to generowanie. Nie ma liczby oszczędzonych minut, bo brakuje punktu odniesienia. I nie ma zużycia prądu zmierzonego na gniazdku; watty to pomiar maszyny, a koszt roczny to rachunek z tych wattów.
Wszystkie liczby opisują jedną konfigurację. Okno pamięci grafiki na innej płycie może być konfigurowalne, zużycie notatnika zależy od architektury modelu, a prędkości zależą od przepustowości pamięci. Definicje są ogólne, a liczby przy nich już nie.
Liczby, do których odwołują się te definicje, pochodzą z jednego zestawu pomiarów. Opublikowałem go w całości: 23 wiersze w pliku CSV oraz skrypt, którym je zebrałem, w repozytorium local-llm-speed-igpu na GitHubie. Repozytorium jest w języku angielskim.
