Spekulativ dekodering: 20–50 % snabbare LLM-inferens

Ett modell med 70 miljarder parametrar (70B) genererar en token per framåtriktad passering (forward pass), och vid varje passering laddas vikterna in från VRAM, uppmärksamheten beräknas över kontexten och minnet synkroniseras. Mellan tokenerna sitter GPU:n idle medan den väntar på att sekventiella beroenden ska lösas.

På en H100 producerar en 70B-modell en token var 30–50 ms. GPU:n har tillräckligt med beräkningskapacitet för att bearbeta flera tokener parallellt, men det sekventiella beroendet förhindrar detta – varje token beror på den föregående, och pipelinen stannar upp.

Spekulativ dekodering bryter denna flaskhals genom att låta dig generera flera tokener på den tid det normalt tar att generera en, utan att ändra utdatafördelningen. Tokenerna du får är statistiskt identiska med de du skulle få från standardautoregressiv dekodering; den enda skillnaden är hur snabbt du får dem.

Denna guide täcker mekaniken, de varianter som finns tillgängliga 2026, avvägningar gällande acceptansgrad och praktisk konfiguration i llama.cpp, vLLM, SGLang och TensorRT-LLM.

Hur autoregressiv dekodering fungerar (och varför den är långsam)

Innan du kan förstå spekulativ dekodering måste du förstå den autoregressiva begränsning den kringgår. Standardautoregressiv generation bearbetar tokener sekventiellt:

1. Kör en framåtriktad passering genom modellen med den aktuella kontexten.
2. Sampla nästa token från utdatafördelningen.
3. Lägg till token i kontexten.
4. Upprepa.

Varje steg kräver en fullständig framåtriktad passering – laddning av vikter från VRAM, beräkning av uppmärksamhet över hela kontexten och produktion av en enda token. För en modell med 70B parametrar tar detta cirka 30–50 ms per token på en H100. GPU:n har beräkningskapacitet att spara – den kunde bearbeta mer arbete parallellt – men det sekventiella beroendet förhindrar det.

Gapet mellan beräkning och VRAM

Moderna GPU:er har fler FLOPs (floating point operations per second) än de behöver för generation av en enda token, så den verkliga flaskhalsen är minnesbandbredd – vikterna måste strömmas från VRAM till beräkningsenheter vid varje framåtriktad passering. När man genererar en token i taget spenderar GPU:n mest av sin tid på att vänta på minnesöverföringar snarare än att göra användbar beräkningsarbete.

Spekulativ dekodering adresserar detta genom att ge GPU:n mer arbete per minnesöverföring. Istället för en token per framåtriktad passering genererar den K tokener per passering, vilket sprider minneskostnaden över flera utdata.

Draft-verify-mekanismen

Spekulativ dekodering fungerar i upprepade cykler av utkast (draft) och verifiering (verify). En snabb utkastmekanism föreslår K kandidat-token – från en liten utkastmodell, en n-gram-sökning eller ett prediktionshuvud kopplat till målmodellen – och målmodellen verifierar alla K i en enda framåtriktad passering. Utkastfasen är billig, typiskt 5–20 % av målmodellens tid för framåtriktad passering, medan verifieringen jämför varje utkastad token med vad målmodellen skulle ha genererat, accepterar den längsta matchande prefixet och omsamlar från första avvisningen och framåt.

Att verifiera K tokener kostar ungefär lika mycket som att generera en token autoregressivt, så när utkastet är korrekt får du K tokener till priset av ett enda verifieringssteg.

Ett konkret exempel

Antag att utkastmodellen föreslår 5 token: ["I", " like", " cooking", " and", " traveling"]. Målmodellen verifierar dem i en enda framåtriktad passering:

Målmodellen accepterar token 1 och 2, genererar sedan " playing" för token 3, vilket producerar tre token i en cykel istället för tre separata framåtriktade passeringar. Om utkastet hade varit korrekt fram till token 5, hade du fått fem token till priset av en verifiering – en 5-gångs hastighetsökning bara för den cykeln.

Verifieringsflaskhalsen

I praktiken dominerar verifieringen exekveringstiden – 42–95 % av cykeln, beroende på metod och modellstorlek. Målmodellens framåtriktade passering är flaskhalsen, och avvisade token representerar slöseri med beräkningsresurser.

Detta är varför acceptansgraden är så viktig. Varje avvisad token efter den första är slöseri med verifieringsarbete. De bästa metoderna för spekulativ dekodering maximerar det förväntade antalet accepterade token per cykel, inte bara den råa acceptansgraden.

Den matematiska garantin

En av de viktigaste egenskaperna hos spekulativ dekodering är att den producerar token från exakt samma fördelning som standardautoregressiv sampling från målmodellen. Verifieringssteget använder avvisningssampling (rejection sampling) – när utkastet föreslår token x, beräknar målmodellen sin egen sannolikhet p(x) och utkastet beräknar p_draft(x). Acceptanssannolikheten är:

min(1, p(x) / p_draft(x))

När målmodellen instämmer (p(x) ≥ p_draft(x)), accepteras token alltid. När målmodellen inte instämmer, accepteras token med en sannolikhet proportionell mot förhållandet, och avvisade token omsamlas från en residualfördelning:

r(x) = max(0, p(x) - p_draft(x)) / Σ max(0, p(y) - p_draft(y))

Denna procedur garanterar att utdatasekvensen följer målmodellens fördelning exakt, vilket är varför spekulativ dekodering är förlustfri (lossless). Utkastmodellen påverkar hastighet, inte kvalitet – tokenerna du får är statistiskt oskiljbara från standarddekodering, med samma perplextitet och fördelning. Den enda skillnaden är latensen.

Strategier för utkastmodeller

Utkastmekanismen är den variabel som betyder mest. Olika ansätze har olika avvägningar mellan konfigurationskomplexitet, acceptansgrad och hastighetsökning.

Fristående utkastmodeller

Det enklaste tillvägagångssättet är att ladda en mindre modell alongside målmodellen – typiskt en 1B–3B-modell som utkastar för en 7B–70B-målmodell.

Fördelar:

• Konceptuellt rakt fram
• Fungerar med vilken målmodell som helst
• Utkastmodellen kan finjusteras för att matcha målmodellens fördelning

Nackdelar:

• Kräver laddning av en annan modell i VRAM (1–4 GB beroende på storlek)
• Utkastmodellens kvalitet bestämmer direkt acceptansgraden
• Utkast mellan olika familjer (t.ex. Qwen som utkastar för Llama) presterar typiskt dåligt

Tumregel: Använd modeller från samma familj. Gemma 2 2B utkastar bra för Gemma 2 27B. Llama 3.2 1B utkastar bra för Llama 3.1 70B. Utkast mellan familjer tenderar att ha låga acceptansgrader eftersom tokenfördelningarna divergerar.

Att hitta kompatibla utkastmodeller

Inte alla små modeller fungerar som utkastmodeller för en given målmodell. Den kritiska faktorn är distributionsjustering – hur väl utkastmodellens utdatasannolikheter matchar målmodellens.

Den gyllene regeln: om utkastmodellens acceptansgrad faller under 50 %, kan spekulativ dekodering faktiskt sänka din hastighet. Överhuvudet med att köra utkastmodellen plus verifiering väger tyngre än nyttan när de flesta förslag avvisas.

EAGLE och EAGLE-3: Prediktionshuvuden

EAGLE (Efficient Architecture Guided Language Model Estimation) eliminerar behovet av en separat utkastmodell. Istället fäster den lätta autoregressiva prediktionshuvuden på målmodellens interna lager.

Hur EAGLE fungerar

EAGLE tränar prediktionshuvuden som tar emot dolda tillstånd från målmodellens mellanliggande lager och förutsäger framtida token. Under inferens:

1. Målmodellen kör en framåtriktad passering genom sina lager.
2. Vid varje lager läser EAGLE-huvudet det dolda tillståndet och föreslår token för framtida positioner.
3. Flera huvuden arbetar parallellt, vardera förutsägande en annan framtida tidssteg.
4. Målmodellen verifierar alla förslag i en enda passering.

Fördelen: EAGLE-huvuden tränas specifikt för att matcha målmodellens fördelning. De ser målmodellens interna representationer direkt, vilket ger dem mycket bättre justering än en fristående utkastmodell.

Förbättringar i EAGLE-3

EAGLE-3 (2025) förfinar tillvägagångssättet med tre nyckelförändringar:

1. Lagerurval: Istället för att fästa huvuden på varje lager använder EAGLE-3 Bayesiansk optimering för att välja det optimala utgångslagret, vilket minskar overhead.
2. Multi-token-prediktion: Varje huvud förutsäger flera token samtidigt, vilket ökar utkastdjupet utan proportionell beräkningskostnad.
3. Tränings effektivitet: EAGLE-3 tränas på målmodellens egen generationsdata, vilket förbättrar acceptansgraden för arbetsbelastningar inom fördelningen (in-distribution).

Acceptansgrader: EAGLE-3 uppnår typiskt 60–80 % acceptansgrad för arbetsbelastningar inom fördelningen, jämfört med 40–60 % för fristående utkastmodeller. Vid kodgenereringsarbetsbelastningar med hög repetition kan acceptansen överstiga 85 %.

Konfiguration: EAGLE-3 kräver förtränade huvuden för din målmodell. NVIDIA tillhandahåller EAGLE-3-huvuden för flera populära modeller via TensorRT-LLM och samlingen Speculative Decoding Modules på HuggingFace. Tredjepartsimplementeringar finns för vLLM och SGLang.

P-EAGLE: Parallellt utkast (mars 2026)

EAGLE-3:s huvudbegränsning är autoregressivt utkast – varje utkasttoken beror på den föregående, så att generera K utkasttoken kräver K sekventiella framåtriktade passeringar genom utkasthuvudet, och utkastoverhead växer linjärt med K. P-EAGLE tar bort detta tak genom att generera alla K utkasttoken i en enda framåtriktad passering genom ett lättskift 4-lagers utkastare som tränats för att förutsäga upp till 10 token parallellt.

Resultatet: P-EAGLE levererar upp till 1,69-gångs hastighetsökning jämfört med vanilla EAGLE-3 på verkliga arbetsbelastningar på NVIDIA B200. Fördelen vidgas vid högre K-värden – där EAGLE-3:s sekventiella utkast blir en flaskhals, incurre P-EAGLE:s parallella utkast ingen ytterligare kostnad.

Konfiguration i vLLM: Ladda ner ett förtränat P-EAGLE-huvud från HuggingFace, sätt "parallel_drafting": true i din vLLM-konfiguration, och använd samma --speculative-model-flagga – vLLM hanterar resten. P-EAGLE är nuvarande state-of-the-art för EAGLE-baserad spekulativ dekodering, och om du implementerar EAGLE 2026 är P-EAGLE varianten att använda.

n-gram-spekulativ dekodering

n-gram-spekulativ dekodering ersätter ett neuralt utkast med mönstermatchning mot prompthistorik. Algoritmen letar efter upprepade n-gram-sekvenser i kontexten, och när den aktuella tokensekvensen matchar ett tidigare sett mönster, föreslår den de token som följde det mönstret tidigare – till exempel, om modellen redan har genererat def calculate_total(items): och möter def calculate_total( igen, vet den att nästa token sannolikt kommer att vara items): baserat på den tidigare förekomsten.

n-gram-map-varianterna (ngram-map-k, ngram-map-k4v) använder hashtabeller för snabbare sökningar istället för linjär skanning, med nyckeln som den aktuella n-gram av storlek N och värdet som tokensekvensen som följde.

Fördelar:

• Noll VRAM-overhead – ingen extra modell att ladda (~16 MB för hashtabellen)
• Extremt snabbt för repetitiva arbetsbelastningar (kodredigering, refaktorisering, mallgenerering)
• Acceptansgrader kan nå 90 %+ för arbetsbelastningar med hög självlikhet

Nackdelar:

• Användslöst för ny generation – om mönstret inte har förekommit tidigare, har n-gram inget att föreslå
• Acceptansgraden faller till nära noll för kreativa eller varierade arbetsbelastningar
• Begränsat utkastdjup (typiskt 2–4 token per match)

Bäst för: Kodrefaktorisering, mallfyllning, repetitiv dokumentation och alla arbetsbelastningar där modellen besöker liknande mönster. Sämst för: kreativt skrivande, öppen chatt och resonemangsuppgifter.

Parametertuning

n-gram-parametrarna betyder mer än du kanske tror. Standardvärdena fungerar för kod, men textarbetsbelastningar behöver justering:

För textarbetsbelastningar, minska size-n till 8–10 och öka min-hits till 2. Detta byter ut matchfrekvens mot högre acceptansgrader per match.

Self-spekulativ dekodering

Self-spekulativ dekodering (också kallad LayerSkip eller self-speculation) använder modellens egen partiella beräkning som utkast, så ingen separat modell behövs.

Hur det fungerar

Istället för att köra hela modellen för varje token, kör self-spekulativ dekodering en avkortad version – genom att hoppa över vissa transformer-lager – för att generera utkasttoken billigt, och den fulla modellen verifierar sedan förslagen.

Till exempel, en 32-lagers modell kanske körs med endast 16 lager för utkast, och verifieras sedan med alla 32 lager. Den avkortade framåtriktade passeringen är snabbare eftersom den bearbetar färre lager, och utkasttoken drar nytta av att se samma initiala lager som målmodellen.

Fördelar:

• Inga ytterligare modellvikter att ladda
• Naturligt justerad med målmodellens fördelning (samma arkitektur, partiella lager)
• Fungerar bra för modeller med signifikant redundans i djupare lager

Nackdelar:

• Kräver modifiering av inferensemotorn för att stödja partiella framåtriktade passeringar
• KV-cache-komplicationer – utkastet använder partiell KV-cache som måste reconcileras med den fulla modellens cache
• Acceptansgrader är typiskt lägre än EAGLE eller väljusterade utkastmodeller

llama.cpp-implementering: PR #18471 introducerade self-spekulativ dekodering med kontexthistorik som utkast. Modellen återanvänder token från sin egen generationshistorik för att föreslå fortsättningar, särskilt effektivt för kodarbetsbelastningar där mönster upprepas inom samma kontextfönster.

MTP (Multi-Token Prediction)

MTP är en specialiserad form av spekulativ dekodering som är inbyggd direkt i vissa modellcheckpoints. Qwen 3.6 levereras med både standard- och MTP-aktiverade GGUF-varianten.

Hur det skiljer sig: MTP-huvuden är inbakade i modellarkitekturen under träning. Modellen bär extra prediktionshuvuden som föreslår flera framtida token i en enda framåtriktad passering. Det finns ingen separat utkastmodell – MTP-huvudena är en del av själva målmodellen.

Avvägningar:

• Ingen utkastmodell att hantera – MTP aktiveras med --spec-type draft-mtp --spec-draft-n-max N
• MTP-huvuden lägger till ~1–2 GB VRAM-overhead
• Fungerar bäst på MoE-arkitekturer (Qwen 3.6 35B-A3B) där spars routing håller MTP-huvudena billiga

För detaljerade benchmarkar av MTP vs standarddekodering över Qwen 3.6 27B och 35B, se Qwen 3.6 MTP vs Standard on 16GB GPU.

Acceptansgrader: Vad de betyder i praktiken

Acceptansgrad (α) är den enskilt viktigaste metrik för spekulativ dekoderingsprestation. Den avgör om du får en hastighetsökning eller betalar overhead.

Hastighetsformeln

Förväntat antal accepterade token per verifieringspass:

E[accepted] = α × K

Där K är antalet utkasttoken som föreslås per cykel. Om α = 0,7 och K = 5, accepterar du 3,5 token per pass – en 3,5-gångs hastighetsökning jämfört med standarddekodering (som producerar 1 token per pass).

Acceptansgrad per metod

När acceptansgraden faller

Acceptansgraden är inte konstant över en generation. Den varierar beroende på:

• Tokenposition: Tidiga token tenderar att ha högre acceptans (mer kontext, mindre osäkerhet). Senare token faller som modellen utforskar mer varierade fortsättningar.
• Arbetsbelastningstyp: Kodredigering med upprepade mönster ser α > 80 %. Öppen kreativ skrivning ser α < 40 %.
• Temperatur: Högre temperatur ökar divergens mellan utkast och mål, vilket sänker acceptansen. Spekulativ dekodering fungerar bäst vid låg temperatur (0,0–0,7).

Kritisk tröskel: Om din effektiva acceptansgrad (α × K) faller under 1,0, är spekulativ dekodering långsammare än standarddekodering. Utkastoverhead plus verifieringstid överstiger kostnaden för ett enda autoregressivt steg.

Spekulativ dekodering i produktion: Vad som faktiskt händer

Forskningspapper rapporterar 2–4-gångs hastighetsökningar, men produktionsbenchmarkar berättar en nyanserad historia – hastighetsökningar krymper med batchstorlek, verifiering dominerar cykeltid, och ingen enda metod vinner på varje arbetsbelastning.

SpecDecode-Bench-resultat (2026)

En systematisk utvärdering av fem SD-varianten (n-gram, EAGLE, EAGLE-3, Draft-Model, MTP) på vLLM över fyra modeller och sex arbetsbelastningar avslöjade:

1. SD fungerar, men hastighetsökningar krymper med batchstorlek. Vid batchstorlek 1 uppnår EAGLE upp till 1,96x på Llama-3-70B. Vid batchstorlek 128 faller detta till 1,21x. Systemet blir beräkningsbunden vid hög konkurrens, och GPU:n har mindre idle kapacitet att spara för spekulation.

2. Verifiering dominerar exekveringstid (42–95 %). Målmodellens framåtriktade passering är flaskhalsen. Att minska slöseri med verifiering på avvisade token är den mest lovande vägen för förbättring.

3. Ingen enda metod vinner överallt. EAGLE-3 är det bästa allround-vallet. Draft-model-metoder excellerar när målmodellen är stor (70B+). n-gram är optimalt för kodredigering och uppgifter med hög överlappning.

4. Oracle-analys avslöjar ett gap. Den teoretiska övre gränsen för kombinerade n-gram + EAGLE-strategier når ~4,9x på kodredigeringsarbetsbelastningar, men nuvarande implementeringar uppnår 2–3x. Det finns utrymme för optimering.

Praktiska förväntningar på hastighetsökning

Batchstorlekseffekten är kritisk. Vid små batchar har GPU:n idle beräkning att spara för spekulation. Vid stora batchar är systemet redan mättat, och spekulativ dekodering lägger till overhead utan proportionell nytta.

Övervakning i produktion

Du bör spåra acceptansgraden i produktion. En minskande acceptansgrad signalerar att din utkastmodell divergerar från målmodellen – antingen eftersom arbetsbelastningen ändrades, eller eftersom utkastmodellen behöver omträning.

Viktiga metrik att övervaka:

• Acceptansgrad per begäran (ska vara stabil runt din baslinje)
• Token per sekund med vs utan spekulativ dekodering (den faktiska hastighetsökningen)
• Verifieringstid som procent av cykeltid (ska vara 42–95 %)
• Utkastmodellens framåtriktade passeringstid (ska vara < 20 % av målmodellens tid)

Om din acceptansgrad faller under 40 %, inaktivera spekulativ dekodering för den begäran. Overhead är inte värt det.

Praktisk konfiguration

Valet av motor är lika viktigt som utkaststrategin – se Ollama vs vLLM vs LM Studio and other local runtimes för hur varje runtime hanterar batching, API-kompatibilitet och genomströmning innan du väljer en spekulativ dekoderingsväg.

llama.cpp

För allmän serverkonfiguration och GGUF-laddning, börja med llama.cpp quickstart; flaggorna nedan lägger till spekulativ dekodering ovanpå.

llama.cpp stöder flera metoder för spekulativ dekodering genom --spec-type-flaggan:

# Utkastmodell (fristående)
llama-server \
  --model target-model.gguf \
  --draft-model draft-model.gguf \
  --spec-draft-n-max 4 \
  --parallel 1  # Obligatorisk: --parallel 1 för spekulativ dekodering

# n-gram
llama-server \
  --model target-model.gguf \
  --spec-type ngram-simple \
  --spec-ngram-simple-size-n 12 \
  --spec-ngram-simple-size-m 48

# n-gram (justering för textarbetsbelastning)
llama-server \
  --model target-model.gguf \
  --spec-type ngram-simple \
  --spec-ngram-simple-size-n 8 \
  --spec-ngram-simple-size-m 32 \
  --spec-ngram-simple-min-hits 2

# MTP (Qwen 3.6)
llama-server \
  --model Qwen3.6-27B-MTP.gguf \
  --spec-type draft-mtp \
  --spec-draft-n-max 2

# Self-spekulativ (kodarbetsbelastningar)
llama-server \
  --model target-model.gguf \
  --spec-type draft-self

Kritiska flaggor:

• --parallel 1 – Spekulativ dekodering i llama.cpp kräver single-batch-läge. Detta är en nuvarande begränsning.
• --spec-draft-n-max – Antal utkasttoken per cykel. Börja med 3–5; högre värden ökar VRAM-pressure.
• --spec-ngram-simple-size-n – Längd på n-gram-sökning. Standard 12 fungerar bra för kod; minska till 8 för text.

Vanliga fallgropar:

• Glömmer --parallel 1 – servern kommer tyst att ignorera spekulativ dekodering.
• Använder utkastmodeller mellan familjer – acceptansgrader kraschar, vilket negaterar all hastighetsökning.
• Sätter --spec-draft-n-max för högt – varje extra utkasttoken kostar VRAM för utkastbufferten. Avtagande avkastning kickar in vid 5–8.

vLLM

vLLM quickstart täcker basdeployment; flaggorna nedan aktiverar spekulativ dekodering på en befintlig vLLM-server.

vLLM stöder spekulativ dekodering genom --speculative-model och --speculative-num-steps-flaggorna:

# Utkastmodell
vllm serve target-model \
  --speculative-model draft-model \
  --speculative-num-steps 5 \
  --speculative-accept-length 5

# EAGLE-3
vllm serve target-model \
  --speculative-model EAGLE-target-model/ \
  --speculative-num-steps 7 \
  --speculative-draft-tensor-parallel-size 1

# P-EAGLE (parallellt utkast)
vllm serve target-model \
  --speculative-model P-EAGLE-target-model/ \
  --speculative-num-steps 7 \
  --speculative-parallel-drafting true

# n-gram
vllm serve target-model \
  --speculative-method ngram \
  --speculative-num-steps 5 \
  --ngram-context-size 12

vLLM:s spekulativa dekodering är integrerad med kontinuerlig batching, så den fungerar under konkurrerande arbetsbelastningar. Schedulern hanterar flera tokenslots inom en enda framåtriktad passering, och minneshanteraren hanterar KV-cache för både utkast- och målmodeller.

SGLang

SGLang stöder spekulativ dekodering genom sin --speculative-algorithm-flagga:

python -m sglang.launch_server \
  --model-path target-model \
  --speculative-algorithm ngram \
  --ngram-context-size 12 \
  --ngram-max-candidate-tokens 6

SGLang:s RadixAttention-arkitektur passar bra med spekulativ dekodering eftersom prefix-caching minskar verifieringskostnaden – målmodellen återanvänder cachad uppmärksamhet för delade prefix, vilket gör varje verifieringspass billigare än en kall framåtriktad passering.

TensorRT-LLM

TensorRT-LLM tillhandahåller produktionsgrad spekulativ dekodering med Triton Inference Server. Konfigurationen är mer involverad men erbjuder bäst prestanda på NVIDIA-hårdvara:

1. Bygg TensorRT-motorn för både mål- och utkastmodeller.
2. Konfigurera modellrepot med model.yaml som specificerar konfigurationen för spekulativ dekodering.
3. Starta Triton med LLM API / PyTorch backend.

TensorRT-LLM stöder både draft-model och EAGLE-3-varianten. För kodgenereringsarbetsbelastningar har TensorRT-LLM med n-gram-spekulativ dekodering visat 2–3-gångs latensreduktion i produktionsdeploymentar.

När man ska använda spekulativ dekodering

Använd den när

• Stora målmodeller (7B+): Overhead från utkastmekanismen sprids över målmodellens beräkning. Spekulativ dekodering skiner när målmodellen är långsam – ju större målmodellen, desto värdefullare är hastighetsökningen.
• Arbetsbelastningar med låg temperatur: Spekulativ dekodering fungerar bäst vid temperatur 0,0–0,7, där målmodellens fördelning är koncentrerad och utkastet har bättre chans att matcha.
• Interaktiva applikationer: Latenssensitiva arbetsbelastningar (chatt, kodkomplettering, agentverktygsanrop) drar mest nytta. Batchbearbetning där du redan mättar GPU:n ser mindre nytta.
• Kodgenerering och redigering: Hög repetition i kodmönster gör n-gram och self-spekulativ dekodering särskilt effektiva.

Hoppa över den när

• Små målmodeller (< 3B): Utkastmodellens overhead närmar sig målmodellens tid för framåtriktad passering. Hastighetsökningen är marginell eller negativ.
• Sampling med hög temperatur: Vid temperatur > 0,7 är målmodellens fördelning för bred för att utkastet ska matcha pålitligt.
• Kreativt skrivande och öppen generation: Låga acceptansgrader på nytt innehåll gör overhead inte värd det.
• Höga batchstorlekar (> 32): Systemet blir beräkningsbunden, och spekulativ dekodering lägger till overhead utan proportionell nytta. SpecDecode-Bench visar hastighetsökning som faller från 1,96x till 1,21x när batchstorlek går från 1 till 128.

Kombinera metoder

Avancerade setup kombinerar flera strategier för spekulativ dekodering. SpecDecode-Bench:s oracle-analys visade att adaptivt kombinera n-gram och EAGLE kan pusha hastighetsökning till 4,9x på kodredigeringsarbetsbelastningar.

Idén är att använda n-gram för mönster som har förekommit tidigare, där acceptansen är hög och overhead är nära noll, och falla tillbaka till EAGLE för nya token. I praktiken kräver detta motorstöd för multi-metod-spekulation – vLLM och TensorRT-LLM har experimentellt stöd, men produktionsgrad implementeringar är fortfarande i utveckling.

För nu är den mest praktiska kombinationen MTP + n-gram i llama.cpp. MTP hanterar den neurala spekulationen, medan n-gram fångar repetitiva mönster som MTP missar. På Qwen 3 27B uppnår denna kombination 120 token/sek jämfört med 67 token/sek standard – en 1,8-gångs hastighetsökning.

Kostnadsöverväganden

Spekulativ dekodering byter ut beräkning mot latens. Den totala beräkningen per token är ungefär densamma – du gör bara mer arbete parallellt snarare än sekventiellt.

Påverkan på GPU-kostnad:

• Latens för enstaka begäran förbättras med 20–50 %, vilket betyder något för interaktiva applikationer.
• Genomströmning (token/sek över många begäran) förbättras mindre – GPU:n är redan mättad vid höga batchstorlekar.
• VRAM-användning ökar med utkastmodellens fotavtryck (1–4 GB för fristående utkast, minimalt för n-gram/EAGLE).

Cloud-inferens: Vid $2–4/tim per H100 minskar spekulativ dekodering latens per begäran utan att öka kostnad per token. För batchbearbetning där du redan mättar GPU:n är kostnadsfördelen minimal – du betalar för samma GPU-tid ändå.

När spekulativ dekodering sparar pengar: Interaktiva applikationer där du debiterar per begäran och vill minska tid till första token. En 2-gångs hastighetsökning betyder att dina användare väntar hälften så länge, och du kan servera fler begäran per sekund på samma hårdvara.

När det inte gör det: Batchbearbetning där du redan maximerar GPU-utnyttjande. Den extra beräkningen från spekulativ dekodering ökar inte genomströmningen – den ändrar bara latensprofilen.

Vad som kommer härnäst

Spekulativ dekodering mognar från forskningsnyhet till produktionsstandard. Fronten pushar bort nuvarande begränsningar:

• Spekulativ Spekulativ Dekodering (SSD): Parallelliserar utkast- och verifieringsstegen över separat hårdvara. Utkastmodellen körs asynkront, för-spekulerar för flera sannolika verifieringsutfall. Tidiga resultat visar upp till 2-gångs hastighetsökning jämfört med optimerad spekulativ dekodering, och 5-gångs jämfört med autoregressiv dekodering. Inte produktionsredo än, men riktningen är klar.

• SpecSA (Sparse Speculative Verification): Kombinerar spekulativ dekodering med dynamisk spars uppmärksamhet. Gör spars uppmärksamhet till en verifieringsorienterad arbetsbelastning, vilket uppnår upp till 3,49-gångs end-to-end genomströmning jämfört med autoregressiv spars dekodering. Relevant för långkontextmodeller där spars uppmärksamhet redan används.

• Adaptiv spekulation: Automatiskt växla mellan n-gram, EAGLE och draft-model-metoder baserat på arbetsbelastningsegenskaper. Oracle-analysen visar betydande outnyttjad potential – nuvarande implementeringar uppnår 2–3x, men den teoretiska gränsen är 4,9x.

• Multimodal spekulativ dekodering: Utvidgar draft-verify till vision-language-modeller och videogenerering. Tidiga översikter visar att samma principer gäller, men verifieringsstrategier behöver anpassning för icke-text-modaliteter.

Beslutsramverk