Multi-Token Prediction-tutorial: zo versnel je LLM's

Wat is Multi-Token Prediction?

De meeste LLM’s genereren tekst één token per keer. Het model voorspelt het volgende token, voegt dat toe aan de context en herhaalt hetzelfde proces. Dit is betrouwbaar, maar kan traag zijn omdat elk nieuw token meestal een extra decodestap vereist.

Multi-Token Prediction verandert dit door het model vooruit te laten kijken en meerdere toekomstige tokens voor te stellen in plaats van slechts één. Deze voorgestelde tokens worden vervolgens gecontroleerd door het hoofddecoderen. Als de voorspellingen kloppen, kan het model meerdere tokens in één keer accepteren. Als één token fout is, valt het model vanaf dat punt terug op het normale pad.

In de praktijk werkt MTP als een ingebouwd draftsysteem. Het model schetst een paar waarschijnlijke volgende tokens, verifieert ze en behoudt de geldige. Hoe meer drafttokens worden geaccepteerd, hoe minder volledige decodestappen nodig zijn, wat het aantal tokens per seconde kan verhogen zonder de uiteindelijke outputkwaliteit te veranderen.

Eenvoudig gezegd:

• Zonder MTP: Genereer token 1 → genereer token 2 → genereer token 3
• Met MTP: Maak een draft van meerdere tokens → verifieer ze → accepteer geldige tokens samen

Daarom kan MTP lokale LLM-inferentie veel sneller laten aanvoelen. In plaats van het model te dwingen telkens een klein stapje te zetten, laat het het model veilig vooruit springen wanneer de draftvoorspellingen kloppen. 

In tools zoals llama.cpp en vLLM-achtige implementaties is dit nauw verwant aan speculatief decoderen, waarbij drafttokens alleen worden geaccepteerd als ze overeenkomen met de output van de verifiër. 

1. Zet een RunPod RTX 3090-machine op

Voor deze gids gebruikte ik een RunPod GPU-instance met een RTX 3090. Je kunt een andere CUDA-geschikte GPU gebruiken, maar de benchmarkresultaten in deze tutorial zijn gebaseerd op een RTX 3090-setup.

Maak eerst een nieuwe RunPod-pod aan en selecteer een RTX 3090 GPU.

Bewerk vóór het deployen van de pod de templatesettings:

• Vergroot de volumeschijfruimte naar 100 GB

• Voeg een extra HTTP-poort toe: 8910

• Voeg een omgevingsvariabele toe met de naam HF_TOKEN en zet de waarde op je Hugging Face-toegangstoken. 

De extra HTTP-poort laat je de llama.cpp-server en web-UI vanuit je browser benaderen. Het Hugging Face-token helpt bij het authenticeren van de download en kan de modelsnelheid verbeteren, vooral voor grote GGUF-bestanden.

Na het bijwerken van de template, deploy je de pod. Zodra deze draait, wacht je tot RunPod je toegang geeft tot de JupyterLab-instance. Open JupyterLab en start een nieuwe terminal.

Installeer in de terminal de vereiste systeempakketten:

apt update
apt install -y git cmake build-essential curl wget python3-pip

2. Clone en schakel over naar de MTP-branch

Ga vervolgens naar de workspace-directory waar we llama.cpp gaan installeren en bouwen:

cd /workspace

Clone de llama.cpp-repository:

git clone --depth 1 https://github.com/ggml-org/llama.cpp.git
cd llama.cpp

De MTP-wijzigingen worden nog getest via een aparte pull request in llama.cpp, dus we halen die branch op en schakelen ernaar over om de nieuwste MTP-implementatie te gebruiken voordat deze onderdeel wordt van de standaard main-build.

Haal de MTP-branch lokaal op:

git fetch origin pull/22673/head:mtp-pr
git checkout mtp-pr

Hiermee schakel je je lokale llama.cpp-build over naar de MTP-versie, die we voor de rest van de gids gebruiken.

3. Bouw llama.cpp met CUDA-ondersteuning

Nu je op de MTP-branch zit, bouw je llama.cpp met CUDA-ondersteuning. Hierdoor kan het model de RTX 3090 GPU gebruiken in plaats van op de CPU te infereren.

Voer de CMake-buildconfiguratie uit:

cmake -B build -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release

Compileer vervolgens de twee targets die we nodig hebben voor deze gids:

cmake --build build --target llama-cli llama-server -j

Dit bouwt:

• llama-cli voor snelle commandline-tests

• llama-server om een OpenAI-compatibele server te starten met browsertoegang

Zodra de build klaar is, kopieer je het binaire bestand llama-server naar de hoofdmap van llama.cpp:

cp ./build/bin/llama-server ./llama-server

Dit maakt het makkelijker om de server vanuit de projectroot te draaien in de volgende stappen.

4. Download het Qwen3.6-27B-MTP-model

Download vervolgens het Qwen3.6 27B MTP GGUF-model dat we voor de tests gaan gebruiken. Dit model draaien we eerst zonder MTP en daarna opnieuw met MTP ingeschakeld om het snelheidsverschil te vergelijken.

Installeer eerst de Hugging Face-downloadtools:

pip install -U "huggingface_hub[hf_xet]" hf-xet hf_transfer

Schakel daarna snellere Hugging Face-downloads in:

export HF_HUB_ENABLE_HF_TRANSFER=1

Dit helpt bij het versnellen van grote modeldownloads, vooral bij GGUF-bestanden.

Maak nu een aparte directory voor het model aan:

mkdir -p /workspace/models/qwen3.6-mtp

Download het Qwen3.6 27B MTP GGUF-model:

hf download froggeric/Qwen3.6-27B-MTP-GGUF \
 Qwen3.6-27B-Q4_K_M-mtp.gguf \
 --local-dir /workspace/models/qwen3.6-mtp

Als je geïnteresseerd bent in het fine-tunen van LLM’s, bekijk dan mijn tutorial over het fine-tunen van Qwen3.6 op een medische Q&A-dataset.

5. Draai Qwen3.6-27B zonder MTP ingeschakeld

Nu komen we bij het belangrijkste deel van de gids: de modelsnelheid testen vóór en na het inschakelen van MTP.

Eerst draaien we het model zonder MTP. Dit geeft ons een schone baseline zodat we het snelheidsverschil later kunnen vergelijken. We gebruiken hetzelfde model, dezelfde GPU, dezelfde contextgrootte en dezelfde serverinstellingen. De enige grote wijziging in de volgende stap is het inschakelen van MTP.

Ga terug naar de llama.cpp-directory:

cd /workspace/llama.cpp

Start de server zonder MTP:

./llama-server \
-m "/workspace/models/qwen3.6-mtp/Qwen3.6-27B-Q4_K_M-mtp.gguf" \
--alias qwen3.6-27b-no-mtp \
--host 0.0.0.0 \
--port 8910 \
-ngl 99 \
-c 100000 \
--cache-type-k q8_0 \
--cache-type-v q8_0 \
-np 1 \
-b 2048 \
-ub 512 \
-t 8 \
-fa on \
--temp 0.7 \
--top-k 20 \
--top-p 0.95 \
--repeat-penalty 1.1 \
--metrics

Dit start een OpenAI-compatibele llama.cpp-server op poort 8910.

Het kan even duren om te laden omdat de server de modelgewichten in het GPU-geheugen moet laden. Zodra alles klaar is, laat de terminal zien dat de server beschikbaar is op poort 8910.

Omdat we deze poort hebben blootgesteld bij het instellen van de RunPod-template, hoef je verder niets te configureren. Ga terug naar je RunPod-dashboard en klik op de link die hoort bij poort 8910. Dit opent de llama.cpp-web-UI in je browser, met het lokale model al geladen.

Vanaf daar kun je prompts direct in de browser testen, vergelijkbaar met hoe je een chatinterface zou gebruiken.

In mijn baseline-test genereerde het model reacties met ongeveer 38,86 tokens/sec zonder MTP. Zelfs met een complexere prompt bleef de snelheid ongeveer hetzelfde. 

Voor een 27B-model op een RTX 3090 is dit al bruikbaar, zeker gezien de GPU trager is en minder geheugen heeft dan nieuwere datacenterkaarten. 

6. Draai Qwen3.6-27B met MTP ingeschakeld

Nu draaien we hetzelfde model opnieuw, maar dit keer met MTP ingeschakeld.

Ga terug naar de terminal waar de server draait en stop deze met:

CTRL + C

Belangrijk is dat we het model, de GPU, de kwantisatie of de meeste runtime-instellingen niet wijzigen. We voegen alleen twee MTP-gerelateerde flags toe:

--spec-type mtp
--spec-draft-n-max 3

De eerste flag vertelt llama.cpp om MTP-achtig speculatief decoderen te gebruiken. De tweede flag zet het maximum aantal drafttokens op 3. Dit betekent dat het model tot drie toekomstige tokens kan proberen te schetsen vóór verificatie.

Start nu de server opnieuw met MTP ingeschakeld:

./llama-server \
-m "/workspace/models/qwen3.6-mtp/Qwen3.6-27B-Q4_K_M-mtp.gguf" \
--alias qwen3.6-27b-mtp \
--host 0.0.0.0 \
--port 8910 \
-ngl 99 \
-c 100000 \
--spec-type mtp \
--spec-draft-n-max 3 \
--cache-type-k q8_0 \
--cache-type-v q8_0 \
-np 1 \
-b 2048 \
-ub 512 \
-t 8 \
-fa on \
--temp 0.7 \
--top-k 20 \
--top-p 0.95 \
--repeat-penalty 1.1 \
--metrics

Zodra de server klaar is, ververs je de browserpagina. Als de pagina niet automatisch opnieuw verbinding maakt, sluit hem dan en open opnieuw de link van poort 8910 via je RunPod-dashboard. 

Test het model nu opnieuw met dezelfde soort prompts.

Met MTP ingeschakeld nam de snelheid duidelijk toe. Bij een simpele begroetingsprompt haalde het model ongeveer 65–67 tokens/sec. Vergeleken met de baseline van ongeveer 38,86 tokens/sec is dit een grote verbetering door slechts twee commandline-flags toe te voegen. 

Bij een complexere prompt, zoals het model vragen om een eenvoudig spel in Python te bouwen, was de snelheid iets lager maar nog steeds veel sneller dan de non-MTP-baseline. In die test genereerde het model rond de 56–61 tokens/sec, wat nog steeds sterk is voor een 27B-model op een RTX 3090. 

Al met al verbeterde MTP Qwen3.6 27B van ongeveer 38 tokens/sec naar 65 tokens/sec op de RunPod RTX 3090-setup. Dat levert een 1,71x versnelling op, of ongeveer 71% hogere doorvoer, zonder de hardware te veranderen of over te stappen op een kleiner model. 

7. Aanbeveling: verdere snelheidsoptimalisatie met TurboQuant

De benchmark in deze gids gebruikt de originele MTP-setup van llama.cpp, zonder TurboQuant, aangepaste patches of andere optimalisaties op runtime-niveau toe te voegen. Zo blijft de test eenvoudig, reproduceerbaar en gericht op de snelheidswinst door alleen MTP in te schakelen.

Om de prestaties verder op te voeren, is de volgende optimalisatie om te verkennen MTP en TurboQuant samen. MTP verhoogt de doorvoer door meerdere voorspelde tokens te laten accepteren, terwijl TurboQuant de KV-cachegeheugendruk tijdens inferentie helpt verminderen. 

Dit kan vooral nuttig zijn voor grotere modellen, prompts met lange context en GPU’s zoals de RTX 3090, waar geheugenbandbreedte en VRAM beperkende factoren kunnen worden.

Daarom rapporteren sommige resultaten uit de r/LocalLLaMA-community hogere tokens/sec dan in deze gids. Die setups combineren vaak MTP met TurboQuant, gepatchte builds, andere KV-cache-instellingen of snellere GPU’s. Aangezien deze tutorial zich richt op een schone MTP-only benchmark, moet TurboQuant worden gezien als het aanbevolen volgende experiment en niet als onderdeel van de huidige setup.

Tot slot 

Onlangs volg ik posts in de LocalLLaMA Reddit-community, en het is geweldig om te zien hoe ver lokale LLM-inferentie is gekomen. Mensen draaien nu modellen zoals Qwen3.6 27B als lokale coding agents, zelfs op oudere GPU’s met beperkt VRAM. Sommigen draaien vergelijkbare setups op Mac-systemen, en de resultaten zijn oprecht indrukwekkend.

Na MTP zelf te hebben getest, snap ik de opwinding. Met hetzelfde model en dezelfde RTX 3090-setup verbeterde het inschakelen van Multi-Token Prediction de genereersnelheid van ongeveer 38 tokens/sec naar 65 tokens/sec. Dat is bijna een 2x versnelling zonder de GPU te upgraden of over te stappen op een kleiner model.

Deze gids focuste op een eenvoudige en reproduceerbare MTP-setup met llama.cpp, maar dit voelt als pas het begin. De volgende stap is experimenteren met betere GGUF-kwantisatie, MTP, TurboQuant en meer getunede runtime-instellingen om te zien hoever we de lokale inferentiesnelheid nog kunnen opdrijven.

Het meest spannende vind ik wat dit betekent voor lokale coding agents. Je kunt krachtige modellen op je eigen hardware draaien, de kosten per query verlagen, je code privé houden en een AI-codingassistent gebruiken zonder volledig afhankelijk te zijn van internet-API’s. Lokale LLM’s worden sneller, praktischer en veel nuttiger dan tot voor kort.