Gemma 4 dostała turbo: jak Multi-Token Prediction przyspiesza lokalne modele AI dwa razy

Mały drafter (500 milionów parametrów, plik około 939 MB) potrafi sprawić, że Twoja Gemma 4 31B na RTX 3090 wyskoczy z 22 tokenów na sekundę do 42. Plik nazywa się gemma-4-31B-it-assistant i jest oficjalnym drafterem Multi-Token Prediction (MTP), którego Google wypuścił 5 maja 2026 dla wszystkich czterech wariantów Gemma 4. To efekt techniki znanej jako speculative decoding, ale w wykonaniu Google wreszcie szeroko dostępnej publicznie. Wcześniej widoczna była głównie w runtime’ach i materiałach technicznych Google. Pokazujemy, czemu to ważne dla osób uruchamiających lokalne LLM, jakie konkretne liczby przyspieszenia zobaczysz na popularnym sprzęcie i jak to wpływa na sensowność lokalnego LLM jako endpointa dla Twojego workflow w n8n.

Co dokładnie Google wypuścił 5 maja

Google opublikował na Hugging Face cztery osobne modele drafter, każdy dopasowany do konkretnej wersji Gemma 4. Najmniejszy ma 78 milionów parametrów (gemma-4-E2B-it-assistant), natomiast największy 500 milionów (gemma-4-31B-it-assistant). Drafter dla wariantu MoE 26B-A4B waży z kolei 870 MB w BF16. Wszystkie są na licencji Apache 2.0 i kompatybilne z istniejącymi base modelami Gemma 4, które wyszły miesiąc wcześniej, 2 kwietnia 2026.

W praktyce to nie nowy model, tylko dodatek przyspieszający istniejące. Nazwa “drafter” bierze się stąd, że ten mały model “szkicuje” kilka tokenów do przodu, a duży target weryfikuje wszystkie naraz w jednym przejściu. Oficjalny wpis na blog Google opisuje rozwiązanie jako “specialized speculative decoding architecture” i deklaruje przyspieszenie do 3x bez utraty jakości lub logiki rozumowania.

Mały model przewiduje, duży weryfikuje. Jeśli zgadza się, akceptujemy kilka tokenów naraz. Jeśli nie, target i tak idzie swoją drogą. Zero kompromisu w jakości, nawet 2-3x boost w prędkości.

Tu dochodzimy do ważnej rzeczy: MTP w Gemma 4 nie powinno degradować jakości, ponieważ finalną decyzję nadal weryfikuje target model. Wynik zachowuje tę samą dystrybucję prawdopodobieństwa co klasyczny next-token prediction. To nie jest “przybliżenie” ani “kompresja”. Dlatego jeśli widzisz wyraźny spadek jakości, oznacza to błąd w implementacji, a nie w samej technice.

Multi-Token Prediction – czemu to nie jest po prostu “lepszy LLM”

Klasyczny model językowy generuje token po tokenie, jeden za drugim. Dla każdego nowego tokena model robi pełny przebieg przez wszystkie warstwy sieci neuronowej. Dlatego przy modelu 31B i 4096 tokenach na wyjściu mamy dosłownie tysiące przejść przez gigantyczną sieć, wykonywanych sekwencyjnie. To z kolei tłumaczy, czemu lokalne LLM zawsze były “działa, ale wolno”.

Speculative decoding (czyli rodzina, do której należy MTP) odwraca ten problem. Drafter to mały, szybki model, który proponuje N tokenów do przodu. Następnie target model robi jeden forward pass i w efekcie weryfikuje wszystkie N naraz w jednym wywołaniu. Jeśli tokeny pasują do tego, co duży model by sam wygenerował – akceptujemy je w całości. W przeciwnym razie wracamy do trybu klasycznego dla tej części.

Kluczowy szczegół Google’a: drafter dzieli KV-cache z target modelem. To znaczy, że nie musi przeliczać kontekstu od zera, tylko korzysta z już obliczonych aktywacji. Cytat z dokumentacji ai.google.dev: “draft models seamlessly utilize the target model’s activations”. Drafter ma 4 warstwy, target ma ich kilkadziesiąt – dlatego drafter generuje propozycje wielokrotnie szybciej.

DeepSeek V3 też używał MTP, jednak w innej formie – jako pomocniczą głowicę wbudowaną w sam model podczas pre-trainingu (1.8x speedup). Gemma 4 idzie natomiast inną ścieżką: osobne, post-hoc trenowane draftery. W efekcie zyskujemy lepszą kompatybilność z istniejącym ekosystemem narzędzi, bo wystarczy dograć drafter, a nie trzeba retreningować bazy.

Twarde liczby – co zobaczysz na swoim sprzęcie

RTX 3090 (24 GB VRAM)

Najbardziej praktyczna konfiguracja dla deweloperów uruchamiających lokalne LLM. Dane z PR llama.cpp #22673, gdzie społeczność testuje implementację MTP dla Gemma 4. Bez MTP model osiąga 22.97 tokenów na sekundę. Z MTP wskakuje na 42.45 tokenów na sekundę, czyli daje przyspieszenie 1.85x.

Drafter dodaje ~2.5-10% narzutu VRAM, więc 31B w kwantyzacji 4-bit razem z drafterem wciąż mieści się na 24 GB. W praktyce zostaje też miejsce na kontekst 8-16k tokenów.

DGX Spark (GB10, 128 GB unified memory)

Dla osób z serwerami LLM ciekawe są dane z ai-muninn.com benchmark. Baseline FP8 bez MTP osiąga 40.85 tok/s. Z MTP przy parametrze γ=4 wynik rośnie do 108.78 tok/s, czyli przyspieszenie wynosi 2.66x.

Dla 8 użytkowników jednocześnie łącznie wychodzi 674 tok/s, czyli ~84 tok/s na osobę. Na pojedynczym serwerze obsługujesz produkcyjny ruch całego zespołu.

Apple Silicon (M3, M4)

Według oficjalnego claimu Google (potwierdzonego analizą lilting.ch): ~2.2x speedup przy batchu 4-8 dla 26B MoE. 31B Dense konsekwentnie ~3x. Dla Maca jako platformy LLM to dobra wiadomość, bo unified memory zawsze była wąskim gardłem.

Co z tańszym sprzętem

AMD iGPU w Ryzen 9 6900HX: z 6.6 do 11.6 tok/s (+75%). Dual AMD MI50 z kolei: z 20 do 50 tok/s (2.5x). Wniosek? MTP działa tym lepiej, im bardziej ograniczeni jesteśmy przepustowością pamięci. W rezultacie obejmuje to praktycznie każdy sprzęt konsumencki.

Wsparcie w narzędziach – co działa już teraz

To rzadki przypadek, gdy wsparcie ekosystemu jest natychmiastowe. Zwykle natomiast czekamy tygodniami na llama.cpp i Ollama. Tutaj Google najwyraźniej przygotował vLLM/MLX/Ollama jeszcze przed publikacją drafterów.

Co to znaczy dla osób budujących workflow w n8n

Tu dochodzimy do najważniejszej części dla naszej publiki. Jeśli budujesz automatyzacje w n8n i myślałeś o lokalnym LLM, dziś sytuacja zmienia się jakościowo. Dotychczas Gemma 3 27B na 24 GB GPU dawała ~22 tok/s, co przy workflow przetwarzającym 50 maili dziennie po 200-500 tokenów odpowiedzi oznaczało wąskie gardło – 10-15 sekund na mail. Frustrujące w produkcji. Po wyjściu MTP ten sam workflow zajmuje połowę tego czasu.

Konkretnie warto wskazać cztery use case’y w n8n, gdzie MTP w Gemma 4 ma sens już dziś:

1. Klasyfikacja maili i leadów. Krótkie wyniki (10-50 tokenów), wysokie tempo. Drafter zwiększa przepustowość przetwarzania paczkowego. Lokalny serwer obsługuje setki maili na godzinę bez wysyłania danych do OpenAI.

2. Agent z RAG (Vector Store + LLM Node). Długie konteksty 8-32k tokenów, długie odpowiedzi. Tu MTP błyszczy najmocniej, ponieważ prefill kontekstu się nie zmienia, a długi decode dostaje pełny boost 2-3x.

3. Tłumaczenia produktowe dla e-commerce. Duża liczba krótkich tekstów, sumarycznie dziesiątki tysięcy tokenów dziennie. Lokalna Gemma 4 zamiast Google Translate API – pełna kontrola jakości plus zero kosztów per-request.

4. Lokalne podsumowania spotkań i transkrypcji. Dane wrażliwe, których nie chcesz w OpenAI. 31B Dense lokalnie + speedup 2-3x oznacza, że z eksperymentu staje się produkcją z akceptowalnym czasem reakcji. Więcej o wyborze między lokalnym LLM a chmurą pisaliśmy w lokalne LLM vs Claude Code w 2026.

Warunek techniczny: żeby to działało, n8n musi się komunikować z lokalnym serwerem (Ollama, vLLM, LM Studio) przez HTTP Request node lub OpenAI-kompatybilny endpoint, a nie przez wbudowany “Local LLM” węzeł, który ma swoje ograniczenia.

Lokalny LLM przestaje być kompromisem między prywatnością a tempem. Z MTP dostajesz oba – dane zostają na Twoim dysku, a workflow działa w czasie zbliżonym do chmurowego.

Lokalnie czy w chmurze – kiedy się opłaca

Twarde liczby ekonomiczne. RTX 3090 z rynku wtórnego ~2000 zł, działa w biurze przez kilka lat. Lokalna Gemma 4 31B + drafter daje 42 tok/s i darmowy unlimited inference. Gemini 2.5 Flash API kosztuje natomiast około 0,30 dolara za milion tokenów wyjściowych.

Break-even przy stałym workloadzie (np. agent generujący milion tokenów dziennie) wypada po ~3-6 miesiącach. Tylko jeśli sprzęt już masz. Jeśli kupujesz nowy GPU 4090/5090 dla lokalnego LLM, ekonomika robi się trudniejsza, bo amortyzacja sprzętu zjada większość oszczędności na API.

Główna przewaga lokalnego LLM nie jest więc cenowa, tylko strukturalna. Pierwsza zaleta to prywatność: dane wrażliwe nie wychodzą z biura. Druga to brak limitów na liczbę zapytań i niespodziewanych zmian cenników. Trzecia to praca offline, nawet w samolocie albo gdy padnie internet u dostawcy. Te trzy razem sprawiają, że lokalny LLM ma sens nawet wtedy, gdy chmura jest dostępna i tańsza.

Kurs n8n 2.0 · Kodożercy

Naucz się n8n od zera i zacznij automatyzować

Kurs n8n 2.0 od Kodożerców to praktyczny kurs bez teorii. Budujesz prawdziwe workflow od pierwszej lekcji: połączenia z API, webhooki, integracje. Żadnych suchych slajdów.

Zacznij naukę →

Podsumowanie

Multi-Token Prediction w Gemma 4 to nie nowy model, tylko mały dodatek. Drafter ma od 78 do 500 mln parametrów, a większe warianty ważą rzędu 870-939 MB. Dzięki niemu istniejące base modele działają 2-3 razy szybciej bez wyraźnego spadku jakości. Najmocniejszy efekt zobaczysz na typowym GPU konsumenckim (RTX 3090: 22 → 42 tok/s) oraz na Apple Silicon (~2.2x batch 4-8). Ekosystem narzędzi wspiera MTP od dnia premiery (vLLM, SGLang, MLX, Ollama, Hugging Face), llama.cpp jest w trakcie. Dla osób budujących workflow w n8n to konkretna zmiana statusu lokalnego LLM: z eksperymentu w produkcyjne narzędzie. Dane zostają na dysku, a tempo dogania chmurę. Jeśli odkładałeś lokalny LLM na “kiedyś”, teraz jest dobry moment, żeby go uruchomić.

Mateusz Wojdalski

Specjalista SEO i content marketingu w Devstock. Zajmuję się strategią treści, automatyzacją procesów marketingowych i wdrożeniami AI w codziennej pracy. Badam nowe narzędzia, adaptuję je do realnych zadań i piszę o tym, co faktycznie działa.