MTP w llama.cpp – lokalne LLM nawet 2x szybciej dzięki multi-token prediction

Jeśli używasz właściwego modelu, lokalna generacja w llama.cpp mogła właśnie przyspieszyć nawet dwukrotnie. Wystarczy dopisać dwa parametry do komendy startowej. Mowa o MTP, czyli multi-token prediction. To technika, dzięki której kompatybilne modele takie jak Qwen3.6 czy DeepSeek V3 wypluwają na raz po kilka tokenów zamiast jednego, a llama.cpp tylko sprawdza, czy się zgadza. Eksperymentalne wsparcie pojawiło się w draft pull requeście numer 22673 do llama.cpp, więc dziś trzeba zbudować wersję z tej gałęzi albo użyć runtime’u, który już zawiera te zmiany. Społeczność i tak zdążyła zmierzyć, ile to naprawdę oszczędza.

Czym jest MTP i dlaczego daje szybkość

Klasyczny model językowy działa krok po kroku. Patrzy na tekst, decyduje o jednym kolejnym słowie, dopisuje je, znów patrzy, znów decyduje. Każdy taki cykl to osobne wywołanie procesora i przepustnice pamięci. Im dłuższa odpowiedź, tym więcej cykli i tym dłużej czekasz.

Modele wytrenowane z głowicami MTP idą na skróty. Razem z głównym tokenem przewidują też trzy lub cztery kolejne, używając tej samej pracy procesora. Następnie standardowy proces sprawdza, czy te zgadnięcia faktycznie pasują. Jeśli tak, model akceptuje cały blok i oszczędza kolejne wywołania. Jeśli nie, wraca do normalnego trybu i nic nie traci.

Przypomina to pisanie wiadomości na telefonie z dobrym autouzupełnianiem. Zamiast wstukiwać każdą literę, czasem klikasz całe podpowiedziane słowo, a tylko sprawdzasz wzrokiem czy się zgadza. Praca palców maleje, treść jest ta sama. Tak samo działa MTP w stosunku do generacji tokenów.

Co realnie dostajesz – liczby z ostatnich testów społeczności

Dla Qwen3.6 27B kwantyzowanego do 4 bitów na MacBooku z procesorem M4 Pro społeczność zmierzyła skok z około 15 do 23 tokenów na sekundę. Czyli półtora raza szybciej w pojedynczym strumieniu. Inne ekipy testujące Qwen3.6 z trzema draft tokenami raportują akceptację na poziomie 75 procent i ponad dwukrotne przyspieszenie. Apple w badaniu o MTP pokazuje od 2,5 raza więcej na typowych zapytaniach do prawie 5 razy więcej na zadaniach matematycznych, gdzie model często powtarza struktury liczbowe. Można to porównać do kasy samoobsługowej z losową kontrolą produktów. Większość pozycji przelatuje od razu, a kasjer zatrzymuje tylko te, które wymagają dodatkowego sprawdzenia. Tak samo MTP przyjmuje większość przewidzianych tokenów z marszu.

To wszystko brzmi pięknie, ale ma cenę. MTP zjada część pamięci na cache klucz-wartość. W standardowej konfiguracji praktyczny kontekst potrafi zejść w okolice połowy. Konkretna liczba zależy jednak od kwantyzacji KV, liczby draft tokens i ustawień kontekstu w komendzie. Jeśli wcześniej mieściłeś 100 tysięcy tokenów wejścia, po włączeniu MTP możesz mieć od 50 do 80 tysięcy. Dla większości codziennych rozmów to wciąż dużo, jednak przy dużych dokumentach albo audycie cudzego kodu warto zweryfikować limit u siebie.

Drugi haczyk pojawia się przy wybranych konfiguracjach MoE. Niezależny tester sprawdził architekturę Qwen3.6-35B-A3B na pojedynczej karcie RTX 3090. Żaden wariant spekulatywnego dekodowania w llama.cpp nie dał netto przyspieszenia względem zwykłego trybu. Wąskie gardło tej rodziny leży gdzie indziej niż liczba tokenów na cykl. Tymczasem dla dense’ów typu Qwen3.6 27B czy Gemma 4 zysk jest realny i powtarzalny.

Jak to włączyć w llama.cpp

Wymagania są dwa. Po pierwsze, build llama.cpp z PR 22673 lub nowszego. Po drugie, plik GGUF z głowicami MTP. Społeczność wrzuciła już kilka takich na Hugging Face, między innymi RDson/Qwen3.6-27B-MTP-Q4_K_M-GGUF i froggeric/Qwen3.6-27B-MTP-GGUF. Bez specjalnego pliku flaga MTP nic nie zmieni, bo standardowy GGUF nie zawiera dodatkowych głowic z treningu.

Komenda startowa wygląda tak (przykład dla serwera lokalnego):

llama-server \
  -m Qwen3.6-27B-Q5_K_M-mtp.gguf \
  --spec-type mtp \
  --spec-draft-n-max 3 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  -c 65536 \
  --temp 0.7 \
  --top-k 20 \
  -ngl 99 \
  --port 8081

Najważniejszy parametr to --spec-draft-n-max 3. Mówi modelowi, ile tokenów ma przewidywać do przodu. Trzy to optimum dla większości zastosowań – daje akceptację rzędu 75 do 83 procent. Wartości jeden i dwa są ostrożniejsze i marnują potencjał, a cztery i pięć tracą czas na odrzucone tokeny. Drugi parametr --spec-type mtp przełącza tryb spekulacji na tę zaszytą w samym modelu, zamiast osobnego małego modelu draftującego.

Na koniec warto wiedzieć, że tryb wizji obecnie nie działa razem z MTP. Jeśli wrzucasz obrazki do modelu z głowicami MTP, llama.cpp zwyczajnie się zawiesi. Społeczność wie o tym i pracuje nad łatką.

Jeśli interesowała Cię już wcześniej kwestia szybszej generacji na lokalnym sprzęcie, opisaliśmy podobny mechanizm w artykule o Luce DFlash i Qwen 3.6 27B na RTX 3090. Z kolei ogólny obraz tego, co się dzieje wokół Qwen3.6 i kart graficznych Blackwell, znajdziesz w naszym tekście o Qwen3.6 27B na RTX 5090 z NVFP4.

Kurs n8n 2.0 · Kodożercy

Naucz się n8n od zera, zacznij automatyzować

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

Zacznij naukę →

Które modele dostały już GGUFs z MTP

Modele wytrenowane z głowicami MTP można policzyć na palcach. Pierwsza grupa to rodzina DeepSeek – V3 i R1 mają je od premiery. Tu warunek: GGUF musi zawierać tensory MTP poprawnie spakowane. Sama architektura nie wystarczy, jeśli plik został wyeksportowany bez dodatkowych głowic. Druga grupa to nowsze wydania Qwena – 3.5 i 3.6 mają autorskie głowice MTP i wymagają specjalnie zbudowanego GGUFa, takiego jak RDson/Qwen3.6-27B-MTP-Q4_K_M-GGUF. Trzecia grupa wygląda inaczej: Gemma 4 od Google nie ma głowic MTP wbudowanych w sam model, tylko osobne drafters MTP – mniejsze modele asystujące, które działają obok target modelu w trybie spekulatywnego dekodowania. To inna architektura, ale efekt podobny.

Tymczasem klasyczne checkpointy Llama 3, Mistral 7B czy Phi-3 nie mają głowic MTP. Włączenie tej flagi nie da nic, bo silnik nie ma czego draftować. Dla tych rodzin trzeba użyć starego spekulatywnego dekodowania z osobnym, mniejszym modelem draftującym (--spec-type draft). Działa, ale zjada dodatkowe VRAM i jest wolniejsze niż MTP, które używa tych samych wag co model główny.

Czy w ogóle warto włączać u siebie

Po pierwsze, warto, jeśli używasz lokalnie jednego z modeli z głowicami MTP i robisz dłuższe rozmowy z prostym kontekstem. Generacja długiej odpowiedzi to dokładnie ten przypadek, w którym zysk z MTP się ujawnia. Asystent kodujący, który pisze całe pliki, ucinanie polskiego e-maila pisanego od zera, agent w n8n generujący raport – wszędzie tam każda zaoszczędzona minuta jest zauważalna.

Drugi przypadek, w którym warto, to praca z dłuższymi narracjami albo dokumentami, które rozkładasz na fragmenty. Przy krótszych zapytaniach typu “policz mi sumę” albo “jaki dziś dzień” zysk i tak będzie niewidoczny, bo cała odpowiedź ma trzy słowa.

Z drugiej strony, MTP przestaje się opłacać, gdy potrzebujesz pełnego kontekstu i nie chcesz go tracić. Dla audytu kodu na 200 tysięcy tokenów albo długiego e-bookowego draftu w pamięci wybór padnie raczej na wariant bez MTP. Trzeci scenariusz, w którym lepiej odpuścić, to architektury MoE typu A3B, gdzie testy społeczności pokazują brak realnego przyspieszenia. Lepiej wtedy zostać przy zwykłym dekodowaniu.

FAQ – najczęstsze pytania o MTP w llama.cpp

Czy MTP zadziała na moim Llama 3 70B?

Niestety nie. Llama 3 nie była trenowana z głowicami MTP, więc llama.cpp nie ma czego draftować z samego modelu. Możesz natomiast użyć klasycznego spekulatywnego dekodowania z osobnym, dużo mniejszym modelem draftującym (--spec-type draft -md draft-model.gguf). Wymaga to drugiego pliku w VRAM-ie i daje słabsze przyspieszenie niż MTP, jednak działa na każdej rodzinie modeli.

Ile dokładnie tracę kontekstu po włączeniu MTP?

W okolicach połowy w standardowej konfiguracji, jednak da się ten koszt zredukować. Pamięć klucz-wartość musi pomieścić nie tylko historię rozmowy, ale też draft tokeny i ich sprawdzenie. Jeśli na danym sprzęcie miałeś 128 tysięcy tokenów kontekstu, po włączeniu MTP zostaje od 64 do 100 tysięcy. Pomaga kwantyzacja KV: --cache-type-k q8_0 ratuje sporo pamięci wobec domyślnego f16. Drugi czynnik to liczba draft tokens i rozmiar kontekstu w komendzie.

Czy MTP jest stabilne na produkcji?

Status to nadal beta i są znane błędy. Najpoważniejszy: tryb wizji (image input) zawiesza llama.cpp z włączonym MTP. Drugi: niektóre warianty MoE typu Qwen3.6-35B-A3B na kartach Ampere nie pokazują netto przyspieszenia. Dla pojedynczego użytkownika z dense modelami i tekstowym wejściem MTP działa wiarygodnie. Tymczasem dla agenta produkcyjnego obsługującego dziesiątki sesji wciąż lepiej poczekać na kolejną iterację. Alternatywą zostaje vLLM, który MTP ma od dłuższego czasu w stabilnym torze.

Podsumowanie

Co zmieniła ostatnia aktualizacja llama.cpp? Pojedynczy parametr w komendzie startowej potrafi teraz przyspieszyć generację Twoich lokalnych modeli AI nawet dwukrotnie, jeśli używasz odpowiedniej rodziny i akceptujesz mniejszy kontekst. Co dokładnie zyskasz? Krótszy czas oczekiwania na odpowiedź, mniejszy rachunek za prąd przy długich sesjach i komfort pracy z lokalnym asystentem porównywalny z chmurą. Co stracisz? Część pamięci na kontekst, zwykle w okolicach połowy. Kwantyzacja KV potrafi ten koszt ograniczyć. Tracisz też wsparcie wizji do czasu kolejnej łatki. Liczby ze społeczności są wymowne: 1,5 do 2 razy szybciej w pojedynczym strumieniu, 75 procent akceptacji draftów, do 5 razy szybciej w zadaniach matematycznych. Dla większości codziennych zastosowań to czysty zysk. Beta wsparcie MTP w głównym nurcie llama.cpp zmienia ekonomię pracy z lokalnymi LLM-ami na korzyść każdego, kto już ma sprzęt i nie chce wrócić do chmury.

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.