Handledning i Multi-Token Prediction: Så snabbar du upp LLM:er

Vad är Multi-Token Prediction?

De flesta LLM:er genererar text en token i taget. Modellen förutsäger nästa token, lägger till den i kontexten och upprepar samma process igen. Det är pålitligt, men kan vara långsamt eftersom varje ny token vanligtvis kräver ytterligare ett avkodningssteg.

Multi-Token Prediction ändrar detta genom att låta modellen se framåt och föreslå flera framtida token i stället för bara en. Dessa föreslagna token kontrolleras sedan av huvudavkodningsprocessen. Om förutsägelserna stämmer kan modellen acceptera flera token i ett svep. Om en token är fel återgår modellen till den normala vägen från den punkten.

I praktiken fungerar MTP som en inbyggd utkastsmekanism. Modellen skissar några troliga nästa token, verifierar dem och behåller de giltiga. Ju fler utkaststoken som accepteras, desto färre fullständiga avkodningssteg behövs, vilket kan öka tokens per sekund utan att ändra den slutliga utdata-kvaliteten.

Enkelt uttryckt:

• Utan MTP: Generera token 1 → generera token 2 → generera token 3
• Med MTP: Skissa flera token → verifiera dem → acceptera giltiga token tillsammans

Detta är anledningen till att MTP kan få lokal LLM-inferens att kännas mycket snabbare. I stället för att tvinga modellen att röra sig framåt ett litet steg i taget låter den modellen säkert hoppa framåt när dess utkastsprediktioner är korrekta. 

I verktyg som llama.cpp och vLLM-stil implementeringar är detta nära besläktat med spekulativ avkodning, där utkaststoken endast accepteras när de matchar verifierarens utdata. 

1. Ställ in en RunPod RTX 3090-maskin

För den här guiden använde jag en RunPod GPU-instans med en RTX 3090. Du kan använda ett annat CUDA-aktiverat GPU, men benchmarkresultaten i den här handledningen är baserade på en RTX 3090-setup.

Skapa först en ny RunPod-pod och välj ett RTX 3090 GPU.

Innan du distribuerar poden, redigera mallinställningarna:

• Öka volymdiskens storlek till 100 GB

• Lägg till en extra HTTP-port: 8910

• Lägg till en miljövariabel som heter HF_TOKEN och sätt dess värde till din Hugging Face-åtkomsttoken. 

Den extra HTTP-porten låter dig komma åt llama.cpp-servern och webbgränssnittet från din webbläsare. Hugging Face-tokenen hjälper till att autentisera nedladdningsförfrågan och kan förbättra modellens nedladdningshastighet, särskilt för stora GGUF-filer.

Efter att du uppdaterat mallen, distribuera poden. När den körs, vänta tills RunPod ger dig åtkomst till JupyterLab-instansen. Öppna JupyterLab och starta sedan en ny terminal.

Installera de nödvändiga systempaketen i terminalen:

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

2. Klona och byt till MTP-branchen

Gå sedan till arbetsytans katalog där vi ska installera och bygga llama.cpp:

cd /workspace

Klona repositoriet llama.cpp:

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

MTP-ändringarna testas fortfarande via en dedikerad pull request i llama.cpp, så vi hämtar och byter till den branchen för att använda den senaste MTP-implementeringen innan den blir en del av standardbygget på main.

Hämta MTP-branchen lokalt:

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

Detta växlar din lokala llama.cpp-build till versionen med MTP aktiverat, som vi kommer att använda i resten av guiden.

3. Bygg llama.cpp med CUDA-stöd

Nu när du är på MTP-branchen, bygg llama.cpp med CUDA-stöd. Detta låter modellen använda RTX 3090-GPU:n i stället för att köra inferens på CPU:n.

Kör CMake-byggekonfigurationen:

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

Kompilera sedan de två mål vi behöver för den här guiden:

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

Detta bygger:

• llama-cli för att köra snabba kommandoradstester

• llama-server för att starta en OpenAI-kompatibel server med åtkomst via webbläsare

När bygget är klart, kopiera den körbara filen llama-server till huvudkatalogen för llama.cpp:

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

Detta gör det enklare att köra servern från projektroten i nästa steg.

4. Ladda ner modellen Qwen3.6-27B-MTP

Ladda nu ner Qwen3.6 27B MTP GGUF-modellen som vi ska använda för testning. Det är modellen vi först kör utan MTP, och sedan igen med MTP aktiverat för att jämföra hastighetsskillnaden.

Installera först Hugging Face-nedladdningsverktygen:

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

Aktivera sedan snabbare Hugging Face-nedladdningar:

export HF_HUB_ENABLE_HF_TRANSFER=1

Detta hjälper till att snabba upp stora modellnedladdningar, särskilt när du arbetar med GGUF-filer.

Skapa nu en dedikerad katalog för modellen:

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

Ladda ner Qwen3.6 27B MTP GGUF-modellen:

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

Om du är intresserad av att finjustera LLM:er kan du kolla min handledning om finjustering av Qwen3.6 på en medicinsk Q&A-dataset.

5. Kör Qwen3.6-27B utan MTP aktiverat

Nu är vi vid huvudmomentet i guiden: att testa modellens hastighet före och efter att MTP aktiveras.

Först kör vi modellen utan MTP. Detta ger oss en ren baslinje så att vi kan jämföra hastighetsskillnaden senare. Vi använder samma modell, samma GPU, samma kontextstorlek och samma serverinställningar. Den enda större förändringen i nästa steg blir att aktivera MTP.

Gå tillbaka till llama.cpp-katalogen:

cd /workspace/llama.cpp

Starta servern utan 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

Detta startar en OpenAI-kompatibel llama.cpp-server på port 8910.

Modellen kan ta en kort stund att ladda eftersom servern behöver läsa in modellvikterna i GPU-minnet. När allt är redo visar terminalen att servern är tillgänglig på port 8910.

Eftersom vi exponerade den här porten när vi satte upp RunPod-mallen behöver du inte konfigurera något mer. Gå tillbaka till din RunPod-panel och klicka på länken som är kopplad till port 8910. Detta öppnar llama.cpp:s webbgränssnitt i din webbläsare, med den lokala modellen redan inläst.

Därifrån kan du börja testa uppmaningar direkt i webbläsaren, ungefär som i ett chattgränssnitt.

I mitt baslinjetest genererade modellen svar i cirka 38,86 tokens/sek utan MTP. Även med en mer komplex uppmaning höll sig hastigheten ungefär i samma intervall. 

För en 27B-modell som körs på en RTX 3090 är detta redan ett användbart resultat, särskilt med tanke på att GPU:n är långsammare och har begränsat minne jämfört med nyare datacenterkort. 

6. Kör Qwen3.6-27B med MTP aktiverat

Nu kör vi samma modell igen, men den här gången med MTP aktiverat.

Gå tillbaka till terminalen där servern körs och stoppa den med:

CTRL + C

Det viktiga här är att vi inte ändrar modellen, GPU:n, kvantiseringen eller de flesta körningsinställningar. Vi lägger bara till två MTP-relaterade flaggor:

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

Den första flaggan talar om för llama.cpp att använda spekulativ avkodning i MTP-stil. Den andra flaggan sätter max antal utkaststoken till 3. Det betyder att modellen kan försöka skissa upp till tre framtida token innan verifiering.

Starta nu servern igen med MTP aktiverat:

./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

När servern är redo, uppdatera sidan i webbläsaren. Om sidan inte återansluter automatiskt, stäng den och öppna länken för port 8910 igen från din RunPod-panel. 

Testa nu modellen igen med samma typ av uppmaningar.

Med MTP aktiverat ökade hastigheten markant. För en enkel hälsningsprompt nådde modellen cirka 65–67 tokens/sek. Jämfört med baslinjehastigheten på omkring 38,86 tokens/sek är detta en stor förbättring från att bara lägga till två kommandoradsflaggor. 

För en mer komplex uppmaning, som att be modellen bygga ett enkelt spel i Python, var hastigheten något lägre men ändå mycket snabbare än baslinjen utan MTP. I det testet genererade modellen omkring 56–61 tokens/sek, vilket fortfarande är ett starkt resultat för en 27B-modell på en RTX 3090. 

Sammanlagt förbättrade aktiveringen av MTP Qwen3.6 27B från cirka 38 tokens/sek till 65 tokens/sek på RunPod RTX 3090-setupen. Det ger en 1,71x hastighetsökning, eller omkring 71% högre genomströmning, utan att byta hårdvara eller gå över till en mindre modell. 

7. Rekommendation: Ytterligare hastighetsoptimering med TurboQuant

Benchmarken i den här guiden använder den ursprungliga MTP-uppsättningen i llama.cpp, utan att lägga till TurboQuant, egna patchar eller andra optimeringar på körnivå. Detta håller testet enkelt, reproducerbart och fokuserat på hastighetsvinsten från att enbart aktivera MTP.

För att pressa prestandan ytterligare är nästa optimering att utforska MTP och TurboQuant tillsammans. MTP förbättrar genomströmningen genom att låta modellen acceptera flera förutsagda token, medan TurboQuant hjälper till att minska KV-cachebelastningen i minnet under inferens. 

Detta kan vara särskilt användbart för större modeller, långkontextuppmaningar och GPU:er som RTX 3090, där minnesbandbredd och VRAM kan bli begränsande faktorer.

Det är därför vissa resultat i r/LocalLLaMA-communityn rapporterar högre tokens/sek än den här guiden. De uppsättningarna kombinerar ofta MTP med TurboQuant, patchade byggen, andra KV-cacheinställningar eller snabbare GPU:er. Eftersom denna handledning fokuserar på ett rent MTP-benchmark bör TurboQuant ses som nästa rekommenderade experiment snarare än en del av den nuvarande uppsättningen.

Avslutande tankar 

På sistone har jag följt inlägg i Reddit-communityn LocalLLaMA, och det är fantastiskt att se hur långt lokal LLM-inferens har kommit. Folk kör nu modeller som Qwen3.6 27B som lokala kodningsagenter, till och med på äldre GPU:er med begränsat VRAM. Vissa kör liknande uppsättningar på Mac-system, och resultaten är verkligen imponerande.

Efter att ha testat MTP själv förstår jag varför det väcker så stor entusiasm. Med samma modell och samma RTX 3090-setup förbättrade aktivering av Multi-Token Prediction genereringshastigheten från cirka 38 tokens/sek till 65 tokens/sek. Det är nästan en 2x hastighetsökning utan att uppgradera GPU:n eller byta till en mindre modell.

Den här guiden fokuserade på en enkel och reproducerbar MTP-uppsättning med llama.cpp, men det känns som bara början. Nästa steg är att experimentera med bättre GGUF-kvantisering, MTP, TurboQuant och mer fintrimmade körningsinställningar för att se hur mycket längre den lokala inferenshastigheten kan pressas.

För mig är det mest spännande vad detta innebär för lokala kodningsagenter. Du kan köra kraftfulla modeller på din egen hårdvara, sänka kostnaden per förfrågan, hålla din kod privat och använda en AI-kodassistent utan att vara helt beroende av internetbaserade API:er. Lokala LLM:er blir snabbare, mer praktiska och betydligt mer användbara än de var för inte så länge sedan.