Speculatief Decoderen: 20-50% Snellere LLM-inferentie

Een model van 70B (70 miljard parameters) genereert één token per forward pass, en bij elke pass worden de gewichten opnieuw van het VRAM geladen, wordt de attention berekend over de context en wordt het gehege synchroniseerd. Tussen tokens zit de GPU inactief terwijl hij wacht tot sequentiële afhankelijkheden zijn opgelost.

Op een H100 produceert een 70B-model één token om de 30-50 ms. De GPU heeft voldoende berekeningscapaciteit om meerdere tokens parallel te verwerken, maar de sequentiële afhankelijkheid verhindert dit — elk token is afhankelijk van het vorige, waardoor de pipeline stopt.

Speculatief decoderen doorbreekt deze bottleneck door u in staat te stellen meerdere tokens te genereren in de tijd die normaal gesproken nodig is voor het genereren van één token, zonder de outputverdeling te wijzigen. De tokens die u krijgt, zijn statistisch identiek aan wat u zou krijgen met standaard autoregressief decoderen; het enige verschil is hoe snel u ze krijgt.

Deze gids behandelt de werking, de varianten die in 2026 beschikbaar zijn, afwegingen rond acceptatiepercentages en praktische implementatie in llama.cpp, vLLM, SGLang en TensorRT-LLM.

Hoe autoregressief decoderen werkt (en waarom het traag is)

Voordat u speculatief decoderen kunt begrijpen, moet u de autoregressieve beperking begrijpen die het omzeilt. Standaard autoregressieve generatie verwerkt tokens sequentieel:

1. Voer een forward pass door het model met de huidige context.
2. Sample het volgende token uit de outputverdeling.
3. Voeg het token toe aan de context.
4. Herhaal.

Elke stap vereist een volledige forward pass — het laden van gewichten uit het VRAM, het berekenen van attention over de volledige context en het produceren van een enkel token. Voor een model met 70B parameters duurt dit ongeveer 30-50 ms per token op een H100. De GPU heeft berekeningscapaciteit over — hij kan meer werk parallel verwerken — maar de sequentiële afhankelijkheid verhindert dit.

De Compute-VRAM-kloof

Moderne GPUs hebben meer FLOPs dan nodig voor single-token generatie, dus de echte bottleneck is geheugenbandbreedte — gewichten moeten voor elke forward pass van VRAM naar de berekeningsunits worden gestreamd. Bij het genereren van één token per keer, brengt de GPU het grootste deel van zijn tijd door met wachten op geheugentransfers in plaats van nuttige berekeningen uit te voeren.

Speculatief decoderen lost dit op door de GPU meer werk te geven per geheugentransfer. In plaats van één token per forward pass, genereert het K tokens per forward pass, waardoor de geheugenkost wordt gespreid over meerdere outputs.

Het Draft-Verifieer-mechanisme

Speculatief decoderen werkt in herhaalde draft-verifieer cycli. Een snelle draft-mechanisme stelt K kandidaat-tokens voor — van een klein draft-model, een n-gram lookup of een predictiekop die aan het doelmodel is bevestigd — en het doelmodel verifieert alle K in één enkele forward pass. De draft-fase is goedkoop, typisch 5-20% van de forward pass-tijd van het doelmodel, terwijl verificatie elk gedrafte token vergelijkt met wat het doelmodel zou hebben gegenereerd, waarbij de langste overeenkomende prefix wordt geaccepteerd en vanaf de eerste afwijzing opnieuw wordt gesampled.

Het verifiëren van K tokens kost ongeveer hetzelfde als het autoregressief genereren van één token, dus wanneer de draft correct is, krijgt u K tokens voor de prijs van één verificatiestap.

Een concreet voorbeeld

Stel dat het draft-model 5 tokens voorstelt: ["Ik", " hou van", " koken", " en", " reizen"]. Het doelmodel verifieert ze in één enkele forward pass:

Het doelmodel accepteert tokens 1 en 2, en genereert vervolgens " spelen" voor token 3, waardoor er drie tokens in één cyclus worden geproduceerd in plaats van drie aparte forward passes. Als de draft tot en met token 5 correct was geweest, zou u vijf tokens krijgen voor de kosten van één verificatie — een 5x versnelling op die cyclus alleen.

De verificatiebottleneck

In de praktijk domineert verificatie de uitvoeringstijd — 42-95% van de cyclus, afhankelijk van de methode en modelgrootte. De forward pass van het doelmodel is de bottleneck, en afgewezen tokens vertegenwoordigen verspilde berekeningen.

Daarom is het acceptatiepercentage zo belangrijk. Elk afgewezen token na het eerste is verspilde verificatiewerk. De beste methoden voor speculatief decoderen maximaliseren het verwachte aantal geaccepteerde tokens per cyclus, niet alleen het ruwe acceptatiepercentage.

De wiskundige garantie

Een van de belangrijkste eigenschappen van speculatief decoderen is dat het tokens produceert uit precies dezelfde verdeling als standaard autoregressief sampling van het doelmodel. De verificatiestap gebruikt rejectie-sampling — wanneer de draft token x voorstelt, berekent het doelmodel zijn eigen waarschijnlijkheid p(x) en de draft berekent p_draft(x). De acceptatiekans is:

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

Wanneer het doelmodel het eens is (p(x) ≥ p_draft(x)), wordt het token altijd geaccepteerd. Wanneer het doelmodel het oneens is, wordt het token geaccepteerd met een kans evenredig met de verhouding, en worden afgewezen tokens opnieuw gesampled uit een residuële verdeling:

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

Deze procedure garandeert dat de outputsequentie exact de verdeling van het doelmodel volgt, waardoor speculatief decoderen verliesvrij is. Het draft-model beïnvloedt snelheid, niet kwaliteit — de tokens die u krijgt, zijn statistisch ononderscheidbaar van standaard decoderen, met dezelfde perplexiteit en verdeling. Het enige verschil is latentie.

Draft-model strategieën

Het draft-mechanisme is de variabele die het meest telt. Verschillende benaderingen hebben verschillende afwegingen tussen complexiteit van opzet, acceptatiepercentage en versnelling.

Standaard draft-modellen

De eenvoudigste aanpak laadt een kleiner model naast het doelmodel — typisch een 1B-3B model dat drafteert voor een 7B-70B doel.

Voordelen:

• Conceptueel eenvoudig
• Werkt met elk doelmodel
• Draft-model kan worden afgestemd om de verdeling van het doelmodel te matchen

Nadelen:

• Vereist het laden van een tweede model in VRAM (1-4 GB, afhankelijk van de grootte)
• De kwaliteit van het draft-model bepaalt direct het acceptatiepercentage
• Cross-family drafts (bijv. Qwen die drafteert voor Llama) presteren doorgaans slecht

Vuistregel: Gebruik modellen uit dezelfde familie. Gemma 2 2B drafteert goed voor Gemma 2 27B. Llama 3.2 1B drafteert goed voor Llama 3.1 70B. Cross-family drafts hebben vaak lage acceptatiepercentages omdat de tokenverdelingen divergeren.

Compatibele draft-modellen vinden

Niet alle kleine modellen werken als draft-modellen voor een gegeven doel. De cruciale factor is verdelingsalignement — hoe nauwkeurig de outputkansen van het draft-model die van het doelmodel matchen.

De gouden regel: als het acceptatiepercentage van het draft-model onder de 50% daalt, kan speculatief decoderen u eigenlijk vertragen. De overhead van het uitvoeren van het draft-model plus verificatie weegt zwaarder dan het voordeel wanneer de meeste voorstellen worden afgewezen.

EAGLE en EAGLE-3: Predictiekoppen

EAGLE (Efficient Architecture Guided Language Model Estimation) elimineert de noodzaak voor een apart draft-model. In plaats daarvan bevestigt het lichtgewicht autoregressieve predictiekoppen aan de interne lagen van het doelmodel.

Hoe EAGLE werkt

EAGLE traint predictiekoppen die verborgen states nemen van de tussenvallende lagen van het doelmodel en toekomstige tokens voorspellen. Tijdens inferentie:

1. Het doelmodel voert een forward pass uit door zijn lagen.
2. Op elke laag leest de EAGLE-kop de verborgen state en stelt tokens voor voor toekomstige posities.
3. Meerdere koppen werken parallel, elk voorspellend voor een ander toekomstige tijdstip.
4. Het doelmodel verifieert alle voorstellen in één enkele pass.

Het voordeel: EAGLE-koppen zijn specifiek getraind om de verdeling van het doelmodel te matchen. Ze zien de interne representaties van het doel direct, wat hen een veel betere alignement geeft dan een standalone draft-model.

EAGLE-3 verbeteringen

EAGLE-3 (2025) verfijnt de aanpak met drie belangrijke wijzigingen:

1. Lagenselectie: In plaats van koppen aan elke laag te bevestigen, gebruikt EAGLE-3 Bayesiaanse optimalisatie om de optimale exit-laag te selecteren, wat overhead vermindert.
2. Multi-token voorspelling: Elke kop voorspelt meerdere tokens tegelijkertijd, waardoor de diepte van de draft toeneemt zonder evenredige berekeningskosten.
3. Trainingsefficiëntie: EAGLE-3 traint op de eigen generatiedata van het doelmodel, wat acceptatiepercentages verbetert bij in-distribution workloads.

Acceptatiepercentages: EAGLE-3 bereikt typisch 60-80% acceptatiepercentages bij in-distribution workloads, vergeleken met 40-60% voor standalone draft-modellen. Bij code-generatie workloads met hoge herhaling kan het acceptatiepercentage 85% overschrijden.

Opzet: EAGLE-3 vereist voorgetrainde koppen voor uw doelmodel. NVIDIA biedt EAGLE-3 koppen voor verschillende populaire modellen via TensorRT-LLM en de Speculative Decoding Modules collectie op HuggingFace. Derde-party implementaties bestaan voor vLLM en SGLang.

P-EAGLE: Parallelle drafting (maart 2026)

De belangrijkste beperking van EAGLE-3 is autoregressieve drafting — elk draft-token is afhankelijk van het vorige, dus het genereren van K draft-tokens vereist K sequentiële forward passes door de draft-kop, en de overhead van de draft groeit lineair met K. P-EAGLE verhaalt dit plafond door alle K draft-tokens in één enkele forward pass door een lichtgewicht 4-laags drafter te genereren, getraind om tot 10 tokens parallel te voorspellen.

Het resultaat: P-EAGLE levert tot 1,69x versnelling ten opzichte van vanilla EAGLE-3 op echte workloads op NVIDIA B200. Het voordeel wordt groter bij hogere K-waarden — waar de sequentiële drafting van EAGLE-3 een bottleneck wordt, incurseert P-EAGLE’s parallelle drafting geen extra kosten.

Opzet in vLLM: Download een voorgetrainde P-EAGLE kop van HuggingFace, stel "parallel_drafting": true in uw vLLM-configuratie in, en gebruik dezelfde --speculative-model vlag — vLLM handelt de rest af. P-EAGLE is de huidige state-of-the-art voor EAGLE-gebaseerd speculatief decoderen, en als u EAGLE in 2026 implementeert, is P-EAGLE de variant die u moet gebruiken.

n-gram speculatief decoderen

n-gram speculatief decoderen vervangt een neurale draft door patroonmatching tegen promptgeschiedenis. Het algoritme zoekt naar herhaalde n-gram sequenties in de context, en wanneer de huidige tokensequentie overeenkomt met een eerder gezien patroon, stelt het de tokens voor die eerder op dat patroon volgden — bijvoorbeeld, als het model al def calculate_total(items): heeft gegenereerd en def calculate_total( opnieuw tegenkomt, weet het dat de volgende tokens waarschijnlijk items): zullen zijn op basis van de vorige voorkomst.

De n-gram map varianten (ngram-map-k, ngram-map-k4v) gebruiken hash-tabellen voor snellere lookups in plaats van lineair scannen, met de hash-sleutel als de huidige n-gram van grootte N en de waarde als de tokensequentie die volgde.

Voordelen:

• Geen VRAM overhead — geen extra model om te laden (~16 MB voor de hash-tabel)
• Extreem snel voor herhalende workloads (code bewerken, refactoring, templategeneratie)
• Acceptatiepercentages kunnen 90%+ bereiken bij workloads met hoge zelfgelijkenis

Nadelen:

• Nutteloos voor nieuwe generatie — als het patroon eerder niet is voorgekomen, heeft n-gram niets om voor te stellen
• Acceptatiepercentage daalt naar bijna nul bij creatieve of diverse workloads
• Beperkte draft-diepte (typisch 2-4 tokens per match)

Beste voor: Code refactoring, templatevulling, herhalende documentatie en elke workload waar het model vergelijkbare patronen opnieuw bezoekt. Slechtste voor: creatief schrijven, open-ended chat en redeneringstaken.

Parameter tuning

De n-gram parameters zijn belangrijker dan u zou verwachten. De standaardwaarden werken voor code, maar tekst workloads hebben aanpassing nodig:

Voor tekst workloads, verlaag size-n naar 8-10 en verhoog min-hits naar 2. Dit wisselt matchfrequentie in voor hogere acceptatiepercentages per match.

Zelf-speculatief decoderen

Zelf-speculatief decoderen (ook wel LayerSkip of self-speculation genoemd) gebruikt de eigen partiële berekening van het model als de draft, zodat geen apart model nodig is.

Hoe het werkt

In plaats van het volledige model te draaien voor elk token, voert zelf-speculatief decoderen een afgekorte versie uit — waarbij sommige transformerlagen worden overgeslagen — om draft-tokens goedkoop te genereren, en het volledige model verifieert vervolgens de voorstellen.

Bijvoorbeeld, een 32-laags model kan met slechts 16 lagen draaien voor drafting, en vervolgens verifiëren met alle 32 lagen. De afgekorte forward pass is sneller omdat hij minder lagen verwerkt, en de draft-tokens profiteren ervan dezelfde initiële lagen te zien als het doel.

Voordelen:

• Geen extra modelgewichten om te laden
• Natuurlijk gealigneerd met de doelverdeling (zelfde architectuur, partiële lagen)
• Werkt goed voor modellen met significante redundantie in diepere lagen

Nadelen:

• Vereist modificatie van de inference engine om partiële forward passes te ondersteunen
• KV cache complicaties — de draft gebruikt partiële KV cache die moet worden verzoend met de cache van het volledige model
• Acceptatiepercentages zijn typisch lager dan EAGLE of goed afgestemde draft-modellen

llama.cpp implementatie: PR #18471 introduceerde zelf-speculatief decoderen met behulp van contextgeschiedenis als draft. Het model hergebruikt tokens uit zijn eigen generatiegeschiedenis om voortzettingen voor te stellen, met name effectief voor code workloads waar patronen binnen hetzelfde contextvenster herhalen.

MTP (Multi-Token Prediction)

MTP is een gespecialiseerde vorm van speculatief decoderen die direct is ingebouwd in bepaalde model checkpoints. Qwen 3.6 levert zowel standaard als MTP-geactiveerde GGUF varianten.

Hoe het verschilt: MTP koppen zijn tijdens het training in de modelarchitectuur gebakken. Het model draagt extra predictiekoppen die meerdere toekomstige tokens in één enkele forward pass voorstellen. Er is geen apart draft-model — de MTP koppen zijn onderdeel van het doelmodel zelf.

Afwegingen:

• Geen draft-model om te beheren — MTP wordt geactiveerd met --spec-type draft-mtp --spec-draft-n-max N
• MTP koppen voegen ~1-2 GB VRAM overhead toe
• Werkt het beste op MoE architecturen (Qwen 3.6 35B-A3B) waar sparse routing MTP koppen goedkoop houdt

Voor gedetailleerde benchmarks van MTP vs standaard decoderen over Qwen 3.6 27B en 35B, zie Qwen 3.6 MTP vs Standaard op 16GB GPU.

Acceptatiepercentages: Wat ze in de praktijk betekenen

Acceptatiepercentage (α) is de belangrijkste metric voor prestaties van speculatief decoderen. Het bepaalt of u een versnelling krijgt of overhead betaalt.

De versnellingsformule

Verwachte geaccepteerde tokens per verificatie pass:

E[geaccepteerd] = α × K

Waar K het aantal draft-tokens is dat per cyclus wordt voorgesteld. Als α = 0,7 en K = 5, accepteert u 3,5 tokens per pass — een 3,5x versnelling ten opzichte van standaard decoderen (wat 1 token per pass produceert).

Acceptatiepercentage per methode

Wanneer acceptatiepercentage daalt

Acceptatiepercentage is niet constant over een generatie. Het varieert per:

• Tokenpositie: Vroege tokens hebben neiging tot hoger acceptatie (meer context, minder onzekerheid). Latere tokens dalen naarmate het model diversere voortzettingen verkent.
• Workload type: Code bewerken met herhaalde patronen ziet α > 80%. Open-ended creatief schrijven ziet α < 40%.
• Temperatuur: Hogere temperatuur verhoogt divergentie tussen draft en doel, wat acceptatie verlaagt. Speculatief decoderen werkt het beste bij lage temperatuur (0,0-0,7).

Kritieke drempel: Als uw effectieve acceptatiepercentage (α × K) daalt onder 1,0, is speculatief decoderen langzamer dan standaard decoderen. De overhead van de draft plus verificatietijd overschrijdt de kosten van een enkele autoregressieve stap.

Speculatief decoderen in productie: Wat er echt gebeurt

Onderzoeksrapporten rapporteren 2-4x versnellingen, maar productie benchmarks vertellen een genuanceerder verhaal — versnellingen krimpen met batchgrootte, verificatie domineert cyclustijd, en geen enkele methode wint op elke workload.

SpecDecode-Bench bevindingen (2026)

Een systematische evaluatie van vijf SD varianten (n-gram, EAGLE, EAGLE-3, Draft-Model, MTP) op vLLM over vier modellen en zes workloads onthulde:

1. SD werkt, maar versnellingen krimpen met batchgrootte. Bij batchgrootte 1, bereikt EAGLE tot 1,96x op Llama-3-70B. Bij batchgrootte 128, daalt dit naar 1,21x. Het systeem wordt compute-gebonden bij hoge concurrentie, en de GPU heeft minder inactieve capaciteit over voor speculatie.

2. Verificatie domineert uitvoeringstijd (42-95%). De forward pass van het doelmodel is de bottleneck. Het verminderen van verspilde verificatie op afgewezen tokens is de meest veelbelovende weg voor verbetering.

3. Geen enkele methode wint overal. EAGLE-3 is de beste all-around keuze. Draft-model methoden excelleren wanneer het doelmodel groot is (70B+). n-gram is optimaal voor code bewerken en taken met hoge overlap.

4. Oracle analyse onthult een kloof. De theoretische bovenste grens voor gecombineerde n-gram + EAGLE strategieën bereikt ~4,9x op code bewerking workloads, maar huidige implementaties bereiken 2-3x. Er is ruimte voor optimalisatie.

Praktische versnellingsverwachtingen

Het batchgrootte effect is cruciaal. Bij kleine batches heeft de GPU inactieve compute over voor speculatie. Bij grote batches is het systeem al verzadigd, en speculatief decoderen voegt overhead toe zonder evenredig voordeel.

Monitoring in productie

U moet acceptatiepercentage in productie bijhouden. Een dalend acceptatiepercentage signaleert dat uw draft-model divergeert van het doel — of omdat de workload is veranderd, of omdat het draft-model opnieuw training nodig heeft.

Belangrijke metrics om te monitoren:

• Acceptatiepercentage per request (moet stabiel zijn rond uw baseline)
• Tokens per seconde met en zonder speculatief decoderen (de daadwerkelijke versnelling)
• Verificatietijd als percentage van cyclustijd (moet 42-95% zijn)
• Draft-model forward pass tijd (moet < 20% van doelmodel tijd zijn)

Als uw acceptatiepercentage daalt onder 40%, schakel speculatief decoderen uit voor die request. De overhead is niet de moeite waard.

Praktische opzet

Engine keuze is net zo belangrijk als draft strategie — zie Ollama vs vLLM vs LM Studio en andere lokale runtimes voor hoe elke runtime batching, API compatibiliteit en throughput afhandelt voordat u een speculatief decoderen pad kiest.

llama.cpp

Voor algemene server opzet en GGUF laden, begin met de llama.cpp quickstart; de vlaggen hieronder voegen speculatief decoderen toe.

llama.cpp ondersteunt meerdere speculatieve decoderen methoden via de --spec-type vlag:

# Draft-model (standalone)
llama-server \
  --model target-model.gguf \
  --draft-model draft-model.gguf \
  --spec-draft-n-max 4 \
  --parallel 1  # Verplicht: --parallel 1 voor speculatief decoderen

# 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 (tekst workload tuning)
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

# Zelf-speculatief (code workloads)
llama-server \
  --model target-model.gguf \
  --spec-type draft-self

Kritieke vlaggen:

• --parallel 1 — Speculatief decoderen in llama.cpp vereist single-batch mode. Dit is een huidige beperking.
• --spec-draft-n-max — Aantal draft-tokens per cyclus. Begin met 3-5; hogere waarden verhogen VRAM-druk.
• --spec-ngram-simple-size-n — Lookup n-gram lengte. Standaard 12 werkt goed voor code; verlaag naar 8 voor tekst.

Veelgemaakte fouten:

• Vergeten --parallel 1 — de server zal speculatief decoderen stil negeren.
• Gebruik van cross-family draft-modellen — acceptatiepercentages storten, waardoor elke versnelling wordt tenietgedaan.
• --spec-draft-n-max te hoog instellen — elk extra draft-token kost VRAM voor de draft buffer. Afnemende opbrengsten komen in beeld rond 5-8.

vLLM

De vLLM quickstart dekt basis deployment; de vlaggen hieronder schakelen speculatief decoderen in op een bestaande vLLM server.

vLLM ondersteunt speculatief decoderen via de --speculative-model en --speculative-num-steps vlaggen:

# Draft-model
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 (parallelle drafting)
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 speculatief decoderen is geïntegreerd met continue batching, dus het werkt onder concurrente workloads. De scheduler handelt meerdere token slots binnen een enkele forward pass af, en de memory manager handlt KV cache voor zowel draft als doelmodellen.

SGLang

SGLang ondersteunt speculatief decoderen via zijn --speculative-algorithm vlag:

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

SGLang’s RadixAttention architectuur gaat goed samen met speculatief decoderen omdat prefix caching de verificatiekosten vermindert — het doelmodel hergebruikt gecachte attention voor gedeelde prefixes, waardoor elke verificatie pass goedkoper is dan een koude forward pass.

TensorRT-LLM

TensorRT-LLM biedt production-grade speculatief decoderen met Triton Inference Server. De opzet is complexer maar biedt de beste prestaties op NVIDIA hardware:

1. Bouw de TensorRT engine voor zowel doel- als draft-modellen.
2. Configureer de model repository met model.yaml die de speculatieve decoderen configuratie specificeert.
3. Start Triton met de LLM API / PyTorch backend.

TensorRT-LLM ondersteunt zowel draft-model als EAGLE-3 varianten. Voor code-generatie workloads heeft TensorRT-LLM met n-gram speculatief decoderen 2-3x latentie reductie aangetoond in productie deployments.

Wanneer speculatief decoderen te gebruiken

Gebruik het wanneer

• Grote doelmodellen (7B+): De overhead van het draft-mechanisme wordt gespreid over de compute van het doel. Speculatief decoderen blinkt uit wanneer het doelmodel traag is — hoe groter het doel, hoe waardevoller de versnelling.
• Lage-temperatuur workloads: Speculatief decoderen werkt het beste bij temperatuur 0,0-0,7, waar de verdeling van het doelmodel geconcentreerd is en de draft een betere kans heeft om te matchen.
• Interactieve applicaties: Latentie-gevoelige workloads (chat, code completion, agent tool calls) profiteren het meest. Batch processing waarbij u de GPU al verzadigt, ziet minder voordeel.
• Code-generatie en bewerking: Hoge herhaling in code patronen maakt n-gram en zelf-speculatief decoderen bijzonder effectief.

Sla het over wanneer

• Kleine doelmodellen (< 3B): De overhead van het draft-model nadert de forward pass tijd van het doel. De versnelling is marginaal of negatief.
• Hoge-temperatuur sampling: Bij temperatuur > 0,7 is de verdeling van het doelmodel te breed voor de draft om betrouwbaar te matchen.
• Creatief schrijven en open-ended generatie: Lage acceptatiepercentages op nieuwe content maken de overhead niet de moeite waard.
• Hoge batchgroottes (> 32): Het systeem wordt compute-gebonden, en speculatief decoderen voegt overhead toe zonder evenredig voordeel. SpecDecode-Bench toont versnelling dalend van 1,96x naar 1,21x naarmate batchgrootte van 1 naar 128 gaat.

Methoden combineren

Geavanceerde opzets combineren meerdere speculatieve decoderen strategieën. De SpecDecode-Bench oracle analyse toonde aan dat adaptief combineren van n-gram en EAGLE versnelling kan duwen naar 4,9x op code bewerking workloads.

Het idee is om n-gram te gebruiken voor patronen die eerder zijn voorgekomen, waar acceptatie hoog is en overhead bijna nul, en terug te vallen op EAGLE voor nieuwe tokens. In de praktijk vereist dit engine-ondersteuning voor multi-method speculatie — vLLM en TensorRT-LLM hebben experimentele ondersteuning, maar production-grade implementaties zijn nog in ontwikkeling.

Voor nu is de meest praktische combinatie MTP + n-gram in llama.cpp. MTP handlt de neurale speculatie, terwijl n-gram herhalende patronen vangt die MTP mist. Op Qwen 3 27B, bereikt deze combinatie 120 tokens/sec vergeleken met 67 tokens/sec standaard — een 1,8x versnelling.

Kostenoverwegingen

Speculatief decoderen wisselt compute in voor latentie. De totale compute per token is ongeveer hetzelfde — u doet gewoon meer werk parallel in plaats van sequentieel.

GPU-kosten impact:

• Single-request latentie verbetert met 20-50%, wat belangrijk is voor interactieve applicaties.
• Throughput (tokens/sec over veel requests) verbetert minder — de GPU is al verzadigd bij hoge batchgroottes.
• VRAM-gebruik neemt toe met de footprint van het draft-model (1-4 GB voor standalone drafts, minimaal voor n-gram/EAGLE).

Cloud-inferentie: Bij $2-4/uur per H100, vermindert speculatief decoderen per-request latentie zonder per-token kosten te verhogen. Voor batch processing waarbij u de GPU al verzadigt, is het kostenvoordeel minimaal — u betaalt voor dezelfde GPU tijd hoe dan ook.

Wanneer speculatief decoderen geld bespaart: Interactieve applicaties waarbij u per request factureert en time-to-first-token wilt verlagen. Een 2x versnelling betekent dat uw gebruikers half zo lang wachten, en u meer requests per seconde kunt serveren op dezelfde hardware.

Wanneer het niet doet: Batch processing waarbij u GPU-utilisatie al maximaliseert. De extra compute van speculatief decoderen verhoogt throughput niet — het verandert alleen het latentieprofiel.

Wat komt er nog

Speculatief decoderen evolueert van onderzoeksnieuwheid naar productiestandaard. De voorfront duwt verder dan de huidige beperkingen:

• Speculatief Speculatief Decoderen (SSD): Paralleliseert de drafting en verificatie fasen over separate hardware. Het draft-model draait asynchroon, pre-speculerend voor meerdere waarschijnlijke verificatie-uitkomsten. Vroege resultaten tonen tot 2x versnelling ten opzichte van geoptimaliseerd speculatief decoderen, en 5x ten opzichte van autoregressief decoderen. Nog niet production-ready, maar de richting is duidelijk.

• SpecSA (Sparse Speculative Verification): Combineert speculatief decoderen met dynamische sparse attention. Maakt sparse attention tot een verificatie-georiënteerde workload, bereikend tot 3,49x end-to-end throughput ten opzichte van autoregressief sparse decoderen. Relevant voor long-context modellen waar sparse attention al in gebruik is.

• Adaptieve speculatie: Automatisch schakelen tussen n-gram, EAGLE en draft-model methoden op basis van workload kenmerken. De oracle analyse toont significante ongebruikte potentieel — huidige implementaties bereiken 2-3x, maar de theoretische grens is 4,9x.

• Multimodaal speculatief decoderen: Uitbreiden van draft-verifieer naar vision-language modellen en videogeneratie. Vroege surveys tonen dat dezelfde principes van toepassing zijn, maar verificatiestrategieën aanpassing nodig hebben voor niet-tekst modaliteiten.

Beslisframework