Tutorial Multi-Token Prediction: cum să accelerați LLM-urile

Ce este Multi-Token Prediction?

Majoritatea LLM-urilor generează text câte un token pe rând. Modelul prezice următorul token, îl adaugă în context și repetă procesul. Este fiabil, dar poate fi lent deoarece fiecare token nou necesită de obicei încă un pas de decodare.

Multi-Token Prediction schimbă acest lucru permițând modelului să privească înainte și să propună mai mulți tokeni viitori în loc de unul singur. Acești tokeni propuși sunt apoi verificați de procesul principal de decodare. Dacă predicțiile sunt corecte, modelul poate accepta mai mulți tokeni dintr-o dată. Dacă un token este greșit, modelul revine la calea normală din acel punct.

În practică, MTP funcționează ca un mecanism de schițare încorporat. Modelul schițează câțiva tokeni probabil următori, îi verifică și îi păstrează pe cei validați. Cu cât sunt acceptați mai mulți tokeni schițați, cu atât sunt necesari mai puțini pași compleți de decodare, ceea ce poate crește tokenii pe secundă fără a schimba calitatea rezultatului final.

Pe scurt:

• Fără MTP: Generează tokenul 1 → generează tokenul 2 → generează tokenul 3
• Cu MTP: Schițează mai mulți tokeni → îi verifică → acceptă tokenii valizi împreună

De aceea MTP poate face inferența locală a LLM-urilor să pară mult mai rapidă. În loc să oblige modelul să avanseze câte un pas mic, îi permite să sară în siguranță înainte ori de câte ori predicțiile sale de schiță sunt corecte. 

În instrumente precum llama.cpp și implementările de tip vLLM-style, acest lucru este strâns legat de speculative decoding, unde tokenii de schiță sunt acceptați doar când se potrivesc cu ieșirea verifikatorului. 

1. Configurați o mașină RunPod RTX 3090

Pentru acest ghid, am folosit o instanță GPU RunPod cu un RTX 3090. Puteți folosi un alt GPU cu suport CUDA, dar rezultatele benchmark-ului din acest tutorial se bazează pe o configurație cu RTX 3090.

Mai întâi, creați un pod RunPod nou și selectați un GPU RTX 3090.

Înainte de a-l lansa, editați setările șablonului:

• Măriți dimensiunea volumului de disc la 100 GB

• Adăugați un port HTTP suplimentar: 8910

• Adăugați o variabilă de mediu numită HF_TOKEN și setați valoarea la tokenul dumneavoastră de acces Hugging Face. 

Portul HTTP suplimentar vă va permite să accesați serverul și interfața web llama.cpp din browser. Tokenul Hugging Face ajută la autentificarea cererii de descărcare și poate îmbunătăți viteza de descărcare a modelului, mai ales pentru fișiere GGUF mari.

După actualizarea șablonului, lansați pod-ul. Odată ce rulează, așteptați ca RunPod să vă ofere acces la instanța JupyterLab. Deschideți JupyterLab, apoi lansați un terminal nou.

În terminal, instalați pachetele de sistem necesare:

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

2. Clonați și comutați la branch-ul MTP

În continuare, treceți în directorul workspace unde vom instala și compila llama.cpp:

cd /workspace

Clonați repository-ul llama.cpp:

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

Modificările MTP sunt încă testate printr-un pull request dedicat în llama.cpp, așa că vom aduce și comuta la acel branch pentru a folosi cea mai recentă implementare MTP înainte să devină parte din build-ul principal standard.

Aduceți local branch-ul MTP:

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

Acest lucru comută build-ul local llama.cpp la versiunea cu MTP activat, pe care o vom folosi în restul ghidului.

3. Compilați llama.cpp cu suport CUDA

Acum că sunteți pe branch-ul cu MTP activat, compilați llama.cpp cu suport CUDA. Astfel, modelul poate folosi GPU-ul RTX 3090 în loc să ruleze inferența pe CPU.

Rulați configurarea build-ului CMake:

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

Apoi compilați cele două ținte de care avem nevoie în acest ghid:

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

Aceasta construiește:

• llama-cli pentru teste rapide în linia de comandă

• llama-server pentru a lansa un server compatibil OpenAI cu acces din browser

După finalizarea build-ului, copiați binarul llama-server în directorul principal llama.cpp:

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

Acest lucru face mai ușoară rularea serverului din rădăcina proiectului în pașii următori.

4. Descărcați modelul Qwen3.6-27B-MTP

În continuare, descărcați modelul Qwen3.6 27B MTP GGUF pe care îl vom folosi pentru testare. Acesta este modelul pe care îl vom rula mai întâi fără MTP, iar apoi din nou cu MTP activat pentru a compara diferența de viteză.

Mai întâi, instalați instrumentele de descărcare Hugging Face:

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

Apoi activați descărcări Hugging Face mai rapide:

export HF_HUB_ENABLE_HF_TRANSFER=1

Acest lucru ajută la accelerarea descărcărilor de modele mari, în special când lucrați cu fișiere GGUF.

Acum creați un director dedicat pentru model:

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

Descărcați modelul Qwen3.6 27B MTP GGUF:

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

Dacă vă interesează fine-tuning-ul LLM-urilor, consultați tutorialul meu despre fine-tuning pentru Qwen3.6 pe un set de date de întrebări și răspunsuri medicale.

5. Rulați Qwen3.6-27B fără MTP activat

Acum ajungem la partea principală a ghidului: testarea vitezei modelului înainte și după activarea MTP.

Mai întâi, vom rula modelul fără MTP. Acest lucru ne oferă o bază curată pentru a putea compara mai târziu diferența de viteză. Folosim același model, același GPU, aceeași dimensiune a contextului și aceleași setări ale serverului. Singura schimbare majoră în pasul următor va fi activarea MTP.

Întoarceți-vă în directorul llama.cpp:

cd /workspace/llama.cpp

Porniți serverul fără 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

Aceasta pornește un server llama.cpp compatibil cu OpenAI pe portul 8910.

Modelul poate avea nevoie de puțin timp pentru încărcare deoarece serverul trebuie să încarce greutățile în memoria GPU. Când totul este gata, în terminal va apărea că serverul este disponibil pe portul 8910.

Deoarece am expus acest port când am configurat șablonul RunPod, nu mai trebuie să configurați nimic. Întoarceți-vă la dashboard-ul RunPod și faceți clic pe linkul asociat cu portul 8910. Aceasta va deschide interfața web llama.cpp în browser, cu modelul local deja încărcat.

De acolo, puteți începe să testați prompturi direct în browser, similar cu utilizarea unei interfețe de chat.

În testul meu de bază, modelul a generat răspunsuri la aproximativ 38,86 tokeni/sec fără MTP. Chiar și cu un prompt mai complex, viteza a rămas în aceeași plajă. 

Pentru un model de 27B care rulează pe un RTX 3090, acesta este deja un rezultat utilizabil, mai ales având în vedere că GPU-ul este mai lent și are memorie limitată comparativ cu plăcile mai noi de tip data center. 

6. Rulați Qwen3.6-27B cu MTP activat

Acum vom rula același model din nou, dar de data aceasta cu MTP activat.

Reveniți la terminalul unde rulează serverul și opriți-l cu:

CTRL + C

Important este că nu schimbăm modelul, GPU-ul, cuantizarea sau majoritatea setărilor de runtime. Adăugăm doar două flaguri legate de MTP:

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

Primul flag îi spune lui llama.cpp să folosească speculative decoding în stil MTP. Al doilea setează numărul maxim de tokeni de schiță la 3. Asta înseamnă că modelul poate încerca să schițeze până la trei tokeni viitori înainte de verificare.

Acum porniți din nou serverul cu MTP activat:

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

După ce serverul este gata, reîmprospătați pagina din browser. Dacă pagina nu se reconectează automat, închideți-o și deschideți din nou linkul pentru portul 8910 din dashboard-ul RunPod. 

Acum testați din nou modelul folosind același tip de prompturi.

Cu MTP activat, viteza a crescut vizibil. Pentru un prompt simplu de salut, modelul a ajuns la aproximativ 65–67 tokeni/sec. Comparativ cu viteza de bază de aproximativ 38,86 tokeni/sec, aceasta este o îmbunătățire majoră obținută prin adăugarea a doar două flaguri în linia de comandă. 

Pentru un prompt mai complex, cum ar fi solicitarea de a construi un joc simplu în Python, viteza a fost puțin mai mică, dar tot mult mai mare decât baza fără MTP. În acel test, modelul a generat la aproximativ 56–61 tokeni/sec, ceea ce rămâne un rezultat solid pentru un model de 27B pe un RTX 3090. 

Per total, activarea MTP a îmbunătățit Qwen3.6 27B de la aproximativ 38 tokeni/sec la 65 tokeni/sec pe configurația RunPod RTX 3090. Asta înseamnă o accelerare de 1,71x, sau aproximativ 71% debit mai mare, fără a schimba hardware-ul sau a trece la un model mai mic. 

7. Recomandare: optimizare suplimentară a vitezei cu TurboQuant

Benchmark-ul din acest ghid folosește configurarea MTP originală din llama.cpp, fără a adăuga TurboQuant, patch-uri personalizate sau alte optimizări la nivel de runtime. Astfel, testul rămâne simplu, reproductibil și concentrat pe câștigul de viteză din activarea MTP, separat.

Pentru a împinge performanța mai departe, următoarea optimizare de explorat este MTP împreună cu TurboQuant. MTP îmbunătățește debitul permițând modelului să accepte mai mulți tokeni prezisi, în timp ce TurboQuant reduce presiunea pe memoria KV-cache în timpul inferenței. 

Acest lucru poate fi deosebit de util pentru modele mai mari, prompturi cu context lung și GPU-uri precum RTX 3090, unde lățimea de bandă a memoriei și VRAM-ul pot deveni factori limitativi.

De aceea unele rezultate din comunitatea r/LocalLLaMA raportează mai mulți tokeni/sec decât în acest ghid. Acolo se combină adesea MTP cu TurboQuant, build-uri patch-uite, setări diferite pentru KV-cache sau GPU-uri mai rapide. Deoarece acest tutorial se concentrează pe un benchmark curat doar cu MTP, TurboQuant ar trebui tratat ca următorul experiment recomandat, nu ca parte a configurației curente.

Concluzii finale 

Recent am urmărit postările din comunitatea LocalLLaMA de pe Reddit și este uimitor cât de mult a evoluat inferența locală pentru LLM-uri. Oamenii rulează acum modele precum Qwen3.6 27B ca agenți locali pentru programare, chiar și pe GPU-uri mai vechi cu VRAM limitat. Unii rulează configurații similare pe sisteme Mac, iar rezultatele sunt cu adevărat impresionante.

După ce am testat eu însumi MTP, înțeleg de ce există atâta entuziasm. Cu același model și aceeași configurație RTX 3090, activarea Multi-Token Prediction a îmbunătățit viteza de generare de la aproximativ 38 tokeni/sec la 65 tokeni/sec. Asta înseamnă aproape o dublare a vitezei fără a actualiza GPU-ul sau a trece la un model mai mic.

Acest ghid s-a concentrat pe o configurare MTP simplă și reproductibilă folosind llama.cpp, dar simt că este doar începutul. Următorul pas este să experimentați cu o cuantizare GGUF mai bună, MTP, TurboQuant și setări de runtime mai ajustate pentru a vedea cât de mult poate fi împinsă viteza de inferență locală.

Pentru mine, partea cea mai incitantă este ce înseamnă asta pentru agenții locali de programare. Puteți rula modele puternice pe propriul hardware, reduce costul per interogare, vă puteți păstra codul privat și puteți folosi un asistent AI pentru programare fără a depinde complet de API-uri bazate pe internet. LLM-urile locale devin mai rapide, mai practice și mult mai utile decât erau acum puțin timp.