Masz lokalny model, który odpowiada z prędkością siedmiu tokenów na sekundę, a chcesz, żeby generował dwadzieścia. Metod jest kilkanaście i mają skrótowe nazwy (MTP, DFlash, EAGLE, speculative decoding), więc łatwo się w nich pogubić. W rzeczywistości dzielą się na trzy grupy, a każda atakuje inne miejsce.
Dwie uwagi o liczbach w tym tekście. Wartości opisane jako pomiar z września 2026 pochodzą z mojej maszyny: AMD Ryzen AI 9 HX 470, zintegrowana grafika Radeon 890M, 32 GB pamięci współdzielonej z procesorem, llama.cpp jako silnik inferencji i modele Qwen w kwantyzacji Q4_K_M. Wszystkie pozostałe liczby pochodzą z cudzych testów i zawsze podaję, z czyich. Nie mierzyłem ich u siebie.
Dlaczego lokalny model jest wolny
Czytanie pamięci, nie moc obliczeniowa
Powodem nie jest brak mocy obliczeniowej. Na każdy wygenerowany token trzeba odczytać z pamięci wszystkie aktywne parametry modelu. W maszynie, w której procesor i grafika współdzielą pamięć systemową, przepustowość wynosi około 50–70 GB/s, podczas gdy RTX 4090 ma ponad 1 TB/s.
Z tego wynika prosty sposób czytania każdej metody przyspieszania. Albo zmniejsza ona liczbę parametrów odczytywanych na token, albo wyciąga więcej tokenów z jednego odczytu, albo nie liczy drugi raz tego, co już policzone. Czwartej możliwości nie ma.
Grupa pierwsza: mniej parametrów na token
Kwantyzacja zmniejsza objętość, nie czas
Kwantyzacja. To ten sam model w mniejszej precyzji. Modele Qwen na mojej maszynie działają w Q4_K_M, czyli przy około 4,7–5,2 bita na wagę: Qwen3.8 9B zajmuje 5,4 GB, a Qwen3.8 27B 16 GB. To pierwsza rzecz, którą robi każdy, kto uruchamia model lokalnie, i zwykle jedyna potrzebna. Poniżej czterech bitów jakość zaczyna wyraźnie spadać, a zysk na prędkości jest już niewielki.
Nie każdy plik jest jednak kwantyzowany po treningu, i warto to rozróżniać. Model gpt-oss-20b jest natywnie w formacie MXFP4, a część modeli, na przykład Gemma 4 26B-A4B QAT, jest trenowana z uwzględnieniem kwantyzacji od początku (quantization-aware training). Efekt na dysku bywa podobny, ale droga do niego jest inna.
Model MoE zamiast gęstego. Model mixture of experts ma pełny rozmiar na dysku, ale na jeden token aktywuje tylko ułamek parametrów. Qwen3-Coder 30B-A3B aktywuje trzy miliardy z trzydziestu i osiąga 30,4 tokena na sekundę, a gęsty Qwen3.8 27B osiąga 7,6 (pomiar z września 2026). To czterokrotna różnica. Nie jest to ustawienie do włączenia, tylko wybór modelu przy pobieraniu.
Mniejszy model. Najszybszy model na mojej maszynie jest gęsty i mały: granite 4.2 8B osiąga 45,7 tokena na sekundę (pomiar z września 2026). Ma jednak wiedzę modelu 8B, co widać przy trudniejszych zadaniach. To wymiana prędkości na jakość, całkowicie jawna.
Destylacja i przycinanie. Mniejszy model trenuje się na odpowiedziach większego albo z większego modelu usuwa się fragmenty. Dla osoby uruchamiającej model w domu nie jest to metoda do zastosowania, tylko gotowy plik do pobrania. Z jej efektów i tak już korzystasz, bo znaczna część małych modeli powstała w ten sposób.
Grupa druga: więcej tokenów z jednego przejścia
Spekulatywne generowanie tokenów
To jest cały nowy ruch z 2026 roku i warto zrozumieć jego mechanizm, bo wszystkie te metody odpowiadają na to samo pytanie: jak przyspieszyć lokalny model AI bez nowej karty graficznej. Serwerowa implementacja jest w vLLM.
Odczyt parametrów z pamięci jest drogi, a sprawdzenie poprawności tokena jest tanie, więc można zgadywać. Mały, szybki mechanizm proponuje kilka kolejnych tokenów, a duży model weryfikuje je wszystkie w jednym przejściu i zatwierdza tyle, ile zostało odgadniętych poprawnie. Jeśli trafiły cztery, dostajesz cztery tokeny za cenę jednego odczytu. Jeśli trafił jeden, nie tracisz prawie nic.
Dlatego te metody nazywa się bezstratnymi (lossless): weryfikuje je duży model, więc wynik jest dokładnie taki, jaki dałby on sam. Warto rozumieć to słowo wąsko, bo bezstratność oznacza identyczny tekst, a nie mądrzejszy model.
| Metoda | Kto zgaduje | Gdzie działa | Czego wymaga |
|---|---|---|---|
| Speculative decoding (klasyczne) | osobny mały model | llama.cpp, vLLM, LM Studio | drugi plik w pamięci |
| MTP (multi-token prediction) | dodatkowe głowice w samym modelu lub dołączony drafter | llama.cpp od maja 2026, LM Studio, vLLM | model wytrenowany z MTP |
| EAGLE-3 | mała sieć pomocnicza | stosy serwerowe (vLLM, SGLang) | wytrenowany drafter do modelu |
| DFlash | mały model dyfuzyjny | stosy serwerowe, integracje w toku | wytrenowany drafter, GPU |
MTP: metoda, która dotarła do domowych maszyn
Jak przyspieszyć lokalny model AI głowicami w modelu
MTP (multi-token prediction) w najprostszej postaci nie wymaga drugiego, osobnego modelu. Głowice zgadujące są wtrenowane w model podczas jego powstawania, więc proponuje on tokeny sam sobie. Mają je między innymi DeepSeek-V3 i nowsze modele Qwen. Gemma 4 ma własne drafery MTP udostępnione przez Google, więc przy niej mechanizm jest nieco inny niż w Qwen.
Dla osoby uruchamiającej model w domu najważniejsza jest data 16 maja 2026, kiedy obsługa MTP weszła do llama.cpp (zgłoszenie 22673). Włącza się ją przełącznikami --spec-type draft-mtp i --spec-draft-n-max 3. LM Studio i Ollama korzystają z llama.cpp, więc obsługa trafia tam razem z aktualizacją silnika (w LM Studio jako przełącznik w sekcji Speculative decoding). Działa tylko z plikiem GGUF zawierającym głowice MTP, a takie pliki zwykle mają MTP w nazwie.
Poniższe liczby pochodzą z testów autora zgłoszenia do llama.cpp, a nie z mojej maszyny: akceptacja około 75% przy trzech zgadywanych tokenach i przyspieszenie generowania 1,85–1,90× na modelach Qwen3.6 27B i 35B-A3B. W tym samym zgłoszeniu opisano też koszty: około 2,5 GB dodatkowej pamięci, wolniejsze przetwarzanie samego zapytania, obsługę tylko jednego równoległego zapytania oraz błędne odpowiedzi na backendzie Vulkan w momencie scalania. To nie jest przełącznik, który włącza się raz i zapomina.
DFlash: nowsza metoda, na razie nie dla domu
Drafter dyfuzyjny zamiast autoregresyjnego
DFlash to praca z 2026 roku z UC San Diego. Odpowiedź na pytanie, jak przyspieszyć lokalny model AI bez zmiany sprzętu, zaczyna się właśnie tutaj. Zmienia ona sposób zgadywania: zamiast małego modelu generującego tokeny jeden po drugim używa małego modelu dyfuzyjnego, który proponuje cały blok tokenów w jednym przejściu. Koszt zgadywania przestaje więc rosnąć wraz z długością bloku.
Autorzy raportują średnio 4,86× przyspieszenia na siedmiu zadaniach i 6,08× na zbiorze Math500 dla modelu Qwen3-8B, przy najlepszym wyniku EAGLE-3 wynoszącym 2,05×. W dyskusji pod pracą pojawia się zastrzeżenie, że po doliczeniu czasu przetwarzania zapytania przewaga nad EAGLE-3 maleje. Integracje z vLLM i SGLang są w toku, a w llama.cpp DFlash jeszcze nie ma, więc na domowej maszynie z GGUF dziś go nie uruchomisz.
Warto jednak zapamiętać mechanizm, bo to ten sam pomysł, na którym opierają się dyfuzyjne modele tekstowe. Opisałem je osobno: JEPA i LLaDA, czyli modele działające inaczej niż LLM.
Grupa trzecia: nie licz drugi raz tego samego
Pamięć podręczna KV
Pamięć podręczna KV jest domyślnie włączona i dzięki niej model nie przelicza całej rozmowy przy każdym słowie. Poza jednym nie trzeba nic robić: należy pilnować długości kontekstu, bo ta pamięć rośnie razem z nim i zabiera miejsce modelowi.
Pamięć podręczna początku zapytania (prompt caching) opłaca się wtedy, gdy wiele zapytań zaczyna się tym samym długim wstępem, na przykład tym samym promptem systemowym lub dokumentem. Pierwsze przejście kosztuje, kolejne już nie.
Krótszy kontekst. To najbardziej niedoceniana metoda i jedna z najskuteczniejszych na mojej maszynie. Gęsta Gemma 4 12B potrafi na krótkim zapytaniu po rozgrzaniu osiągnąć 34 tokeny na sekundę, a przy długim kontekście spada do 11,3 (pomiar z września 2026). Na tym samym modelu to trzykrotna różnica, bez żadnego przełącznika.
Przetwarzanie wsadowe (batching) zwiększa łączną przepustowość, ale nie skraca czasu oczekiwania na jedną odpowiedź. Przy pracy z jednego okna czatu nie daje niczego, a przy przetwarzaniu dwustu plików w tle daje bardzo dużo.
Co z tego sprawdzam u siebie
Gęsty Qwen3.8 27B i 7,6 tokena na sekundę
Oczywistym kandydatem z mojej tabeli jest gęsty Qwen3.8 27B z wynikiem 7,6 tokena na sekundę – mój punkt wyjścia przy każdym pytaniu, jak przyspieszyć lokalny model AI. Prawie go nie używam, bo przy tej prędkości czeka się zbyt długo. Pliki GGUF z głowicami MTP dla tego modelu już istnieją, więc test da się wykonać i mam go w planach.
Mam też powód do ostrożności i wolę go zapisać, zanim zmierzę. MTP przenosi koszt z odczytu pamięci na moc obliczeniową, której zintegrowana grafika ma niewiele. Dochodzi do tego wolniejszy start zapytania, opisany przez autorów. Zysk na maszynie z pamięcią współdzieloną może więc być wyraźnie mniejszy niż 1,85× z karty dedykowanej. Własny pomiar dopiszę po jego wykonaniu, razem z ustawieniami, bo bez nich sama liczba nic nie znaczy.
Czego te metody nie zrobią
- Nie zwiększą przepustowości pamięci. To ograniczenie sprzętowe. Metody z grupy drugiej pozwalają je lepiej wykorzystać, ale go nie przesuwają.
- Nie dają stałego przyspieszenia. Zysk zależy od tego, jak często zgadujący trafia, a to zależy od zadania. Dlatego autorzy DFlash podają 4,86× średnio i 6,08× na jednym zbiorze. Rozrzut jest częścią wyniku.
- Bezstratne nie znaczy lepsze. Dostajesz ten sam tekst szybciej, a model nie zaczyna rozumieć więcej.
- MTP nie włączysz w dowolnym modelu. Głowice muszą być wtrenowane. W zwykłym pliku GGUF ich nie ma i nie da się ich dodać przełącznikiem.
- Metody nie sumują się wprost. Kwantyzacja, MoE i zgadywanie poprawiają ten sam odczyt pamięci, więc trzy dwukrotne przyspieszenia nie dają ośmiokrotnego.
Kolejność, której trzymałbym się na własnej maszynie, jest nudna i wynika z tej listy: najpierw dobry model MoE i rozsądna kwantyzacja, potem krótszy kontekst, a dopiero na końcu zgadywanie tokenów. Dlaczego sam wybór modelu robi największą różnicę, policzyłem osobno: dlaczego model 30B jest szybszy niż 12B.
Jak cała ta maszyna jest zbudowana (system, silnik i brama API), opisałem krok po kroku tutaj: jak uruchomić lokalny model AI na Ubuntu Server.
