Speculative decoding instellen voor snellere LLM-tokens

Wie lokale taalmodellen inzet, doorloopt doorgaans een vast traject van selectie naar inrichting, serveroptimalisatie en prestatietuning. Zodra de basisinstallatie operationeel is, stuit men bij grotere modellen van 32 miljard of 70 miljard parameters vrijwel direct op een fundamentele beperking van autoregressieve generatie: voor ieder afzonderlijk gegenereerd token moet het systeem de volledige set gewichten door de geheugenbus transporteren. Voordat er gestart wordt met geavanceerde inferentieversnelling, is het raadzaam om de fysieke systeemeisen te controleren via het overzicht over welke hardware nodig is voor lokale LLMs.

Speculative decoding biedt een beproefde methode om de wachttijd per token aanzienlijk terug te dringen zonder dat er concessies worden gedaan aan de uiteindelijke modelkwaliteit. In dit artikel behandelen we de werking van speculative decoding, de configuratie ervan in llama.cpp, vLLM en Ollama, het selecteren van compatibele draft-modellen en de wisselwerking tussen geheugenbudgetten en acceptatiegraden in uiteenlopende toepassingen.

De technische werking van speculative decoding

Tijdens standaard inferentie genereert een neuraal netwerk tekst token voor token. De rekenkernen van een videokaart (zoals CUDA-cores of Tensor Cores) moeten voor ieder token alle tientallen gigabytes aan modelparameters ophalen uit het werkgeheugen of VRAM. Omdat de feitelijke wiskundige bewerking per individueel token relatief licht is vergeleken met het enorme datavolume dat getransporteerd moet worden, werkt lokale inferentie bij een batchgrootte van 1 nagenoeg altijd op de limiet van de geheugenbandbreedte (memory-bandwidth bound). De processor brengt het grootste deel van de rekentijd door met wachten op datatransport.

Speculative decoding lost dit knelpunt op door twee modellen parallel in te zetten: een uiterst compact en snel draft model (bijvoorbeeld 0.5B tot 1.5B parameters) en het volwaardige target model (zoals een 32B of 70B variant). Het kleine draft-model voorspelt met minimale rekenlast een reeks van opeenvolgende kandidaat-tokens (vaak aangeduid met $K$, typisch tussen de 3 en 8 tokens). Vervolgens voert het grote target-model één enkele parallelle controle (forward pass) uit over die gehele reeks.

Omdat het parallel verifiëren van meerdere tokens voor de geheugenbus vrijwel evenveel tijd kost als het verwerken van één enkel token, kost deze controle nauwelijks extra bandbreedte. Tokens die overeenkomen met de waarschijnlijkheidsverdeling van het grote model worden direct geaccepteerd. Zodra een voorspeld token afwijkt, verwerpt het target-model dit token, genereert ter plekke het correcte alternatief en start de draft-cyclus opnieuw. De wiskundige onderbouwing bewijst dat de output statistisch identiek blijft aan een generatie die puur door het grote model is uitgevoerd. Wie de exacte formules en kansverdelingen wil bestuderen, vindt alle achtergronden in de uitleg over hoe speculatieve decoding de generatiesnelheid verhoogt.

VRAM-budgettering en modelkeuzes

De belangrijkste praktische afweging bij speculative decoding is het beschikbare videogeheugen. Beide modellen moeten gelijktijdig in het geheugen passen, inclusief hun respectievelijke KV-caches. Wanneer het VRAM-budget krap is, kan het toevoegen van een draft-model ertoe dwingen om het hoofdmodel sterker te comprimeren. Meer details over de impact van lagere bitprecisie op kwaliteit en geheugengebruik zijn te vinden in het overzicht over kwantisatie en compressie van grote modellen.

Om te voorkomen dat de grafische kaart out-of-memory raakt, is een nauwkeurige geheugenberekening noodzakelijk. Gebruik hiervoor de VRAM-rekenhulp voor modelgeheugen en contextgrootte om vooraf te bepalen of het gewenste contextvenster voor beide modellen past binnen de hardwarecapaciteit.

Speculative decoding instellen in llama.cpp

Het open-source ecosysteem rondom llama.cpp biedt uitstekende en directe ondersteuning voor speculative decoding via zowel llama-cli als de zelfstandige llama-server binary. De configuratie rust op het specificeren van een primair model via -m en een secundair draft-model via -md (model draft).

Bij het fijnregelen van de parameters zijn de volgende instellingen bepalend voor de prestaties:

• --draft-max (of -draft): Het maximum aantal tokens dat het draft-model per cyclus vooruit mag speculeren (meestal ingesteld tussen 4 en 8).
• --draft-min: De minimale acceptatiedrempel voordat de speculatieve cyclus actief blijft.
• --draft-p-min: Een drempelwaarde op basis van tokenwaarschijnlijkheid om speculatie vroegtijdig af te breken wanneer het draft-model lage zekerheid vertoont.

Voorbeeld 1: Interactieve CLI-sessie

Het onderstaande commando illustreert hoe een CLI-sessie wordt gestart met een 32B hoofdmodel en een 0.5B draft-model, waarbij alle lagen naar de GPU worden verplaatst:

# Starten van llama-cli met hoofdmodel en draft-model
llama-cli \
  -m models/target-model-32b-q4_k_m.gguf \
  -md models/draft-model-0.5b-q8_0.gguf \
  -ngl 99 \
  -ngld 99 \
  -c 8192 \
  -cd 8192 \
  --draft-max 6 \
  --temp 0.0 \
  -p "Leg in heldere bewoordingen uit hoe caching werkt in moderne computerarchitectuur."

De vlag -ngl 99 draagt alle netwerklagen van het hoofdmodel over aan de grafische processor, terwijl -ngld 99 dezelfde instructie geeft voor het draft-model. Met -cd 8192 wordt het contextgeheugen van het hulpmodel exact afgestemd op de contextgrootte van het hoofdmodel.

Voorbeeld 2: Servermodus met OpenAI-compatibele API

Voor continue integratie met applicaties en web-interfaces kan llama-server als service worden gestart met ingeschakelde draft-functionaliteit:

llama-server \
  --host 127.0.0.1 \
  --port 8080 \
  -m models/target-model-32b-q4_k_m.gguf \
  -md models/draft-model-1.5b-q4_k_m.gguf \
  -ngl 99 -ngld 99 \
  -c 16384 -cd 16384 \
  --draft-max 8 \
  --draft-p-min 0.4

Speculative decoding configureren in vLLM

In professionele en multi-user omgevingen is vLLM een van de meest gebruikte frameworks voor hoge doorvoer. vLLM biedt ondersteuning voor zowel een volwaardig parallel draft-model als voor prompt lookup decoding via n-gram matching. Voor beheerders die een centrale Linux-server inrichten, biedt de handleiding over vLLM configureren voor hoge doorvoer op Linux waardevolle richtlijnen voor netwerk- en procesinrichting.

Bij het gebruik van een neuraal draft-model worden de argumenten --speculative-model en --num-speculative-tokens meegegeven bij het initialiseren van de vLLM OpenAI-server:

# Starten van vLLM met een complementair draft-model
python3 -m vllm.entrypoints.openai.api_server \
  --model /pad/naar/target-model-70b \
  --speculative-model /pad/naar/draft-model-1b \
  --num-speculative-tokens 5 \
  --use-v2-block-manager \
  --gpu-memory-utilization 0.92 \
  --max-model-len 8192 \
  --port 8000

Indien het VRAM-budget onvoldoende ruimte biedt voor een tweede model, kan n-gram matching worden geactiveerd. Deze methode zoekt naar herhalende tokenpatronen in de reeds aangeboden prompt en geschiedenis, wat uitstekend functioneert bij documentanalyse, code-aanpassingen en gestructureerde data-extractie:

# vLLM prompt lookup decoding zonder extra neuraal draft-model
python3 -m vllm.entrypoints.openai.api_server \
  --model /pad/naar/target-model-32b \
  --speculative-model [ngram] \
  --num-speculative-tokens 5 \
  --ngram-prompt-lookup-max 3 \
  --ngram-prompt-lookup-min 1

Speculative decoding in Ollama (Modelfile en CLI)

Binnen Ollama wordt de onderliggende runtime aangedreven door llama.cpp. Hoewel speculatieve afhandeling in sommige versies automatisch wordt aangestuurd wanneer compatibele architecturen worden gedetecteerd, kan dit ook expliciet worden vastgelegd in een op maat gemaakte Modelfile.

Hierin wordt het pad naar zowel het basismodel als het bijbehorende draft-model gedefinieerd:

# Modelfile met speculatieve configuratie
FROM ./target-model-32b.gguf

# Parameterinstellingen voor het draft-mechanisme
PARAMETER draft_model "./draft-model-0.5b.gguf"
PARAMETER num_draft 5
PARAMETER temperature 0.2
PARAMETER top_p 0.9

SYSTEM """Je bent een deskundige assistent die bondige, feitelijke antwoorden formuleert in het Nederlands."""

Nadat het bestand is opgeslagen, kan het model worden aangemaakt en gestart met de standaard CLI-commando's:

ollama create aangepast-speculatief-model -f Modelfile
ollama run aangepast-speculatief-model

De acceptatiegraad evalueren en optimaliseren

Het werkelijke rendement van speculative decoding staat of valt met de acceptatiegraad ($\alpha$). Dit is de verhouding tussen het aantal goedgekeurde speculatieve tokens en het totaal aantal voorspelde draft-tokens. Wanneer de acceptatiegraad hoog ligt (bijvoorbeeld 75% of meer), genereert het systeem in nagenoeg elke iteratie meerdere tokens parallel. Daalt deze graad echter tot onder circa 35% à 40%, dan kan de berekening trager worden dan standaard autoregressieve generatie vanwege de overhead van de draft-passes.

De belangrijkste variabelen die de acceptatiegraad beïnvloeden:

• Gedeelde vocabulaire en tokenizer: Het target-model en het draft-model moeten exact dezelfde tokenizerarchitectuur en token-ID-verdeling hanteren. Modellen uit verschillende families combineren leidt onherroepelijk tot mislukte verificaties.
• Type inhoud en voorspelbaarheid: Broncode, JSON-structuren en formele verslagen kennen veel herhalende syntactische patronen, wat leidt tot een aanzienlijk hogere acceptatiegraad dan poëzie of creatief proza.
• Sampling parameters: Een lage temperatuur (zoals temperature = 0.0) maximaliseert de overeenstemming tussen de modellen. Naarmate de temperatuur stijgt, neemt de entropie toe en daalt het aantal geaccepteerde tokens.

Om te controleren of een specifieke configuratie daadwerkelijk een versnelling oplevert, is het aan te raden een objectieve meetmethode te hanteren. Zie voor concrete meetprotocollen de gids over latency, doorvoer en tokens per seconde meten.

Eenvoudig benchmarkscript

Met behulp van een gestandaardiseerd Python-script kan de feitelijke doorvoer van een lokale OpenAI-compatibele API nauwkeurig worden vastgesteld:

import time
from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:8080/v1", api_key="lokaal")

test_prompt = """Schrijf een modulaire Python-klasse voor het beheren van een 
in-memory cache met een Time-To-Live (TTL) mechanisme. Voeg type hints toe."""

tijd_start = time.perf_counter()
respons = client.chat.completions.create(
    model="default",
    messages=[{"role": "user", "content": test_prompt}],
    temperature=0.0,
    max_tokens=400
)
totale_duur = time.perf_counter() - tijd_start

aantal_tokens = respons.usage.completion_tokens
doorvoer_tps = aantal_tokens / totale_duur

print(f"Gegenereerde tokens: {aantal_tokens}")
print(f"Totale tijdsduur: {totale_duur:.2f} seconden")
print(f"Berekende snelheid: {doorvoer_tps:.2f} tokens/seconde")

Invloed van de Nederlandse taal op de acceptatiegraad

Bij het verwerken van Nederlandstalige teksten kan de acceptatiegraad enigszins afwijken van Engelstalige referentiewaarden. Veel kleinere draft-modellen (in de orde van 0.5B tot 1B parameters) beschikken over een minder diepe representatie van de Nederlandse grammatica, zinsstructuur en samengestelde naamwoorden dan van het Engels. Hierdoor maakt het hulpmodel vaker een voorspellingsfout bij specifieke vervoegingen of minder frequente woorden.

Hoewel het grote doelmodel dergelijke afwijkingen naadloos corrigeert, kan dit de effectieve acceptatiegraad met enkele procentpunten verlagen ten opzichte van identieke taken in het Engels. In de praktijk blijft de algehele snelheidswinst bij taken zoals samenvatten, analyseren en programmeren desalniettemin aanzienlijk. Aanvullende technieken om de taalkwaliteit en instructieopvolging te optimaliseren worden behandeld in het artikel over AI beter laten presteren in het Nederlands.

Privacy en gegevensbescherming

Een wezenlijk fundament van lokale LLM-infrastructuur is dat alle verwerking binnen de eigen machine of het lokale netwerk blijft. Dit geldt onverminderd voor speculative decoding: zowel het draft-model als het doelmodel draaien lokaal op de grafische kaart of het gedeelde systeemgeheugen. Er worden geen tussenstappen, logits of prompts naar externe servers verzonden.

Hierdoor blijft de verwerking volledig in lijn met de AVG-vereisten en interne compliance-richtlijnen voor gevoelige data. Uitgebreide informatie over het inrichten van een veilige lokale verwerkingsomgeving is te vinden in de handleiding over privacyvriendelijk AI gebruiken.

Wanneer speculative decoding niet de juiste keuze is

Ondanks de duidelijke voordelen kent speculative decoding specifieke situaties waarin inschakeling juist contraproductief werkt:

• Hoge gelijktijdige serverbelasting: Wanneer een inferentieserver continu tientallen verzoeken tegelijk verwerkt met grote batches, verschuift het knelpunt van geheugenbandbreedte naar pure rekenkracht (compute bound). Het uitvoeren van extra draft-berekeningen verlaagt in dat geval de algehele doorvoer van het systeem.
• Sterk creatieve taken met hoge temperatuur: Bij een hoge instelling voor willekeur (zoals temperature > 0.85) daalt de statistische overlap tussen draft- en hoofdmodel drastisch, waardoor de acceptatiegraad onder het rendabele niveau kan zakken.
• Onvoldoende fysiek geheugen: Indien het toevoegen van een draft-model forceert om het hoofdmodel extreem zwaar te kwantiseren (bijvoorbeeld naar 2-bit of 3-bit), weegt de eventuele snelheidswinst zelden op tegen het verlies aan redeneervermogen en nauwkeurigheid.

Aanbevelingen voor de praktijk

Voor individuele interactie op een lokaal werkstation — zoals bij programmeren, documenten samenvatten en interactieve chat — vormt speculative decoding een bijzonder effectieve optimalisatie om de reactietijd van zware modellen merkbaar te verbeteren. Door een 0.5B of 1.5B hulpmodel toe te voegen aan een 32B of 70B hoofdmodel kan de wachttijd aanzienlijk worden gereduceerd, op voorwaarde dat het geheugen vooraf zorgvuldig is gebudgetteerd en beide modellen dezelfde tokenizer delen.