Dit artikel analyseert de technische redenen waarom lokale implementaties van Large Language Models (LLM's) vaak minder presteren dan de referentie-implementaties van de makers. De auteur voert diverse experimenten uit om aan te tonen dat 'token flips' — het kiezen van een ander volgend token — worden veroorzaakt door factoren zoals de keuze van de attention backend (bijv. FlashAttention 2 versus Triton) en de complexiteit van de softwarestack (zoals vLLM).
Daarnaast wordt de impact van quantisatie onderzocht. Het blijkt dat quantisatie van de KV-cache (met name INT4) en bepaalde weight-quantisaties (zoals NVFP4 en AWQ) de intelligentie en nauwkeurigheid bij complexe technische taken en lange contexten drastisch kunnen verlagen. Ook wordt vastgesteld dat 'abliterated' of 'uncensored' modellen soms significante schade toebrengen aan de technische precisie van de output.
De conclusie is dat de perceptie van een 'dommer' model meestal het gevolg is van de cumulatieve effecten van de inference-omgeving en hardware-specifieke wiskundige divergenties, en niet van het model zelf.
Waarom je lokale LLM dommer aanvoelt dan hij is
Inleiding
Dit artikel is een technische reeks experimenten om de impact aan te tonen van implementatie-specifieke risico's bij inference. In deze context wordt de term "referentie-implementatie" gebruikt voor het laboratorium dat het model heeft gepubliceerd, de first-party hosting aanbiedt en de oorspronkelijke benchmark-claims publiceert. De hardware en software van zo'n laboratorium verschillen fundamenteel van die van de gemiddelde lokale gebruiker.
De kern van het probleem is dat elke lokale implementatie in zekere mate tekortschiet. Elke hardware- en softwarecombinatie die vandaag een LLM draait, is anders. Een gemiddelde home-lab gebruiker kan verschillende generaties GPU's combineren. De chips op deze GPU's hebben verschillende instructiesets, waardoor de wiskunde voor het berekenen van het volgende token verschilt van die van een ander, zelfs wanneer exact dezelfde weights worden gebruikt.
Het meten van prestaties: Praktisch versus Mathematisch
Er zijn verschillende manieren om te bepalen in hoeverre een specifieke setup tekortschiet.
De praktische aanpak
De meest directe methode is het draaien van standaard benchmarks (zoals Terminal Bench, HLE, SWE-bench, MMLU). Het is essentieel dat deze representatief zijn voor de daadwerkelijke workload. Het is onvoldoende om de temperatuur naar nul te zetten, drie test-prompts in te voeren en een oordeel te vellen. Zero-shot tests zijn geen goede analogie voor agentische taken; daarvoor zijn evaluaties van long-context tool-calling en domeinspecifieke kennis nodig.
De mathematische aanpak
De focus ligt hier op de wiskunde. "Logits" zijn de scores van het model voor elk mogelijk volgend token. Deze worden genormaliseerd tot kansen, door een geconfigureerde sampler geleid en door de detokenizer teruggezet naar tekst.
Belangrijk over sampler-instellingen: De modelkaart op Hugging Face specificeert meestal welke instellingen (zoals temperatuur 1.0, top-p 0.95) en welke chat template gebruikt moeten worden. Een te lage temperatuur kan er bijvoorbeeld voor zorgen dat een model zoals Qwen vastloopt in een loop in de THINK-output.
KL Divergentie (KLD)
Een cruciale maatstaf is de KL Divergentie (KLD). In eenvoudige termen: men zet de output-logits om in een kansverdeling en meet hoe ver deze verdeling is verschoven ten opzichte van een gekozen basislijn. Een lagere KLD betekent dat het model dichter bij de basislijn ligt, maar niet automatisch dat het "slimmer" is.
Waarschuwing: Let op bij claims van extreem lage KLD op modelkaarten van gekwantiseerde modellen. Een getal is oninterpreteerbaar tenzij de auteur de referentie-checkpoints, de volledige runtime-omgeving, evaluatieteksten, kalibratiedata, contextlengtes, bemonsterde posities, KL-richting en vocabulaire-truncatie openbaart.
De complexiteit van de softwarestack (vLLM)
Om te begrijpen waar divergentie ontstaat, moeten we kijken naar de softwarestack. Een nightly VLLM container-image bevat bijvoorbeeld meer dan 700 packages. Dit zijn 734 verschillende codebases, elk met eigen bugs en undocumented eigenaardigheden. De weg die een specifieke implementatie door deze berg code aflegt, is uniek.
Test 1: Precisie van Attention Backends
Tijdens de prefill (prompt-verwerking) selecteert de inference-engine een attention backend. Dit beïnvloedt zowel de snelheid als de precisie.
Methodologie
- Model: Qwen3.6-27B (BF16 checkpoint).
- Hardware: RTX PRO 6000 Blackwell GPU (tensor parallelism 1).
- Configuratie: BF16 KV-cache, geen quantisatie van weights of activaties, eager execution, CUDA-graphs uitgeschakeld, 2k-token chunked prefill.
- Workload: Een context van ongeveer 100k tokens uit een echte werkstroom met meerdere tool-aanroepen (geen synthetische tests).
Er werd vergeleken tussen drie backends: FlashAttention 2, Flash Inference en Triton Attention.
Resultaten
Er werd gekeken naar "Top-1 agreement": of het token met de hoogste logit (de greedy argmax) hetzelfde was. Een "top-1 flip" betekent dat een backend een ander volgend token zou hebben gekozen.
De resultaten toonden aan dat de backends bij de eerste duizenden tokens overeenstemden, maar later in de prompt begonnen te divergeren. Deze divergentie komt exclusief voort uit de matrix-vermenigvuldigingen en optellingen tijdens de prefill binnen de verschillende backends.
Test 2: KV-Cache Quantisatie
Wat gebeurt er als de weights en activaties ongewijzigd blijven (BF16), maar alleen de KV-cache wordt gekwantiseerd?
Resultaat: Er treedt significante divergentie op. Bij tool-aanroepen bleek dat BF16 correct functioneerde en INT8 uiteindelijk kon herstellen, maar dat INT4 faalde. Dit suggereert dat de effectieve intelligentie van een LLM drastisch kan dalen na bijvoorbeeld 40k tokens bij gebruik van een gekwantiseerde KV-cache.
Test 3: Weight Quantisatie
In dit experiment bleef de KV-cache op BF16, maar werden verschillende quantisaties van de weights vergeleken:
- BF16 referentie: Qwen3.6-27B
- Official FP8: Qwen3.6-27B-FP8
- INT8 W8A16: TheHouseOfTheDude/Qwen3.6-27B-INT8
- NVIDIA NVFP4: nvidia/Qwen3.6-27B-NVFP4
- AWQ W4A16: cyankiwi/Qwen3.6-27B-AWQ-BF16-INT4
Technische details van de implementaties
- BF16: Referentie-checkpoint.
- FP8: E4M3 FP8 weights; dynamische FP8 activatie-quantisatie.
- INT8: Statische, symmetrische, channel-wise INT8 weights; BF16 activaties (W8A16).
- NVFP4: Mixed checkpoint met FP8 en NVFP4 targets.
- AWQ: Statische asymmetrische INT4 weights, group size 32.
Resultaten van de "Bake-off"
De INT8 versie (TheHouseOfTheDude) presteerde het beste. De NVIDIA NVFP4-release kwam op de laatste plaats uit, met ongeveer 50% token-flips bij een context van 88k.
Zowel NVFP4 als AWQ W4A16 faalden bij het correct afsluiten van tool-aanroepen en maakten fouten in Cisco command-line syntax (bijv. show run in plaats van show arp), terwijl FP8 en INT8 de aanroepen correct voltooiden.
Diepere analyse van Token Flips
Wanneer een token-flip optreedt, kan dit leiden tot een volledig andere output-stroom. In een testcase waarbij een tool-aanroep werd gedaan voor een Cisco-router interface (GigabitEthernet0/0/1.201), gebeurde het volgende:
- Referentie: Correcte uitvoering.
- Flash Attention 2: Verkeerd token gekozen → targette
GigabitEthernet0/1/4 → probeerde de fout te herstellen met het verkeerde commando (show run in plaats van show mac address table).
Dit bewijst dat een eenvoudige runtime-keuze in CUDA-kernels in een productieomgeving kan leiden tot kritieke netwerkstoringen.
Tensor Parallelisme (TP)
Er is ook divergentie zichtbaar bij Tensor Parallelisme:
- TP1: Acceptabele tool-aanroep.
- TP2: Faalt.
- TP4: Slaagt weer.
Dit wijst vaak op problemen binnen NCCL (Nvidia Collective Communications Library).
Analyse van "Uncensored" en "Abliterated" Modellen
Er is een trend om modellen te gebruiken die gelabeld zijn als "HERETIC", "UNCENSORED" of "ABLITERATED". Er is onderzocht wat de impact hiervan is op de technische capaciteiten van Qwen 3.8.
Vergeleken modellen:
- Stock Qwen 3.8 (BF16)
- Heretic-ARA
- Huihui Abliterated
- Blackfrost Abliterated
- AEON Ultimate Uncensored
Bevindingen
| Model | Top-1 flips (SP06) | Impact op technische output |
|---|
| Heretic-ARA | 1.337% | Zeer functioneel, minimale destabilisatie. |
| Huihui | 1.406% | Verrassend goed, behoudt technische workload. |
| Blackfrost | 4.978% | Significante wijzigingen, blijft meestal coherent. |
| AEON Ultimate | 5.831% | Disruptief, produceert structureel ongeldige outputs. |
Specifiek falen van AEON: In een PostgreSQL-context koos het model bij een port-nummer (5432) het token ql in plaats van 2, resulterend in 543ql. Ook werden hostnames gecorrumpeerd en API-argumenten (page_size=100 werd size=100) ongeldig gemaakt.
Conclusies over determinisme en precisie
Waarom niet alles in integers (INT) berekenen?
Men zou kunnen denken dat het gebruik van integers zonder afronding (zoals INT64 accumulatoren) non-determinisme zou oplossen. Echter:
- Computationele kosten: INT64-berekeningen miljarden keren uitvoeren in MMA-operaties is prohibitief duur.
- Hardware: De meeste GPU-hardware heeft geen native INT64 accumulatoren.
- Emergentie: Er is een theorie dat de lichte randomheid van floating-point berekeningen juist bijdraagt aan de "vonk" van LLM's; een volledig deterministisch model zou mogelijk minder creatief of intelligent zijn.
Samenvatting
De perceptie dat een lokaal model "dommer" is, komt vaak niet door het model zelf, maar door de cumulatieve effecten van:
- De keuze van de Attention Backend (bijv. FA2 vs Triton).
- Quantisatie van de KV-cache (vooral bij lange contexten).
- De gekozen weight-quantisatie (sommige FP4/INT4 implementaties zijn instabieler dan anderen).
- De impact van "abliteration" (het verwijderen van censuur), wat in sommige gevallen de precisie van technische output ernstig beschadigt.
Waarom je lokale LLM dommer aanvoelt dan hij is
Inleiding
Dit artikel is een technische reeks experimenten om de impact aan te tonen van implementatie-specifieke risico's bij inference. In deze context wordt de term "referentie-implementatie" gebruikt voor het laboratorium dat het model heeft gepubliceerd, de first-party hosting aanbiedt en de oorspronkelijke benchmark-claims publiceert. De hardware en software van zo'n laboratorium verschillen fundamenteel van die van de gemiddelde lokale gebruiker.
De kern van het probleem is dat elke lokale implementatie in zekere mate tekortschiet. Elke hardware- en softwarecombinatie die vandaag een LLM draait, is anders. Een gemiddelde home-lab gebruiker kan verschillende generaties GPU's combineren. De chips op deze GPU's hebben verschillende instructiesets, waardoor de wiskunde voor het berekenen van het volgende token verschilt van die van een ander, zelfs wanneer exact dezelfde weights worden gebruikt.
Het meten van prestaties: Praktisch versus Mathematisch
Er zijn verschillende manieren om te bepalen in hoeverre een specifieke setup tekortschiet.
De praktische aanpak
De meest directe methode is het draaien van standaard benchmarks (zoals Terminal Bench, HLE, SWE-bench, MMLU). Het is essentieel dat deze representatief zijn voor de daadwerkelijke workload. Het is onvoldoende om de temperatuur naar nul te zetten, drie test-prompts in te voeren en een oordeel te vellen. Zero-shot tests zijn geen goede analogie voor agentische taken; daarvoor zijn evaluaties van long-context tool-calling en domeinspecifieke kennis nodig.
De mathematische aanpak
De focus ligt hier op de wiskunde. "Logits" zijn de scores van het model voor elk mogelijk volgend token. Deze worden genormaliseerd tot kansen, door een geconfigureerde sampler geleid en door de detokenizer teruggezet naar tekst.
Belangrijk over sampler-instellingen: De modelkaart op Hugging Face specificeert meestal welke instellingen (zoals temperatuur 1.0, top-p 0.95) en welke chat template gebruikt moeten worden. Een te lage temperatuur kan er bijvoorbeeld voor zorgen dat een model zoals Qwen vastloopt in een loop in de THINK-output.
KL Divergentie (KLD)
Een cruciale maatstaf is de KL Divergentie (KLD). In eenvoudige termen: men zet de output-logits om in een kansverdeling en meet hoe ver deze verdeling is verschoven ten opzichte van een gekozen basislijn. Een lagere KLD betekent dat het model dichter bij de basislijn ligt, maar niet automatisch dat het "slimmer" is.
Waarschuwing: Let op bij claims van extreem lage KLD op modelkaarten van gekwantiseerde modellen. Een getal is oninterpreteerbaar tenzij de auteur de referentie-checkpoints, de volledige runtime-omgeving, evaluatieteksten, kalibratiedata, contextlengtes, bemonsterde posities, KL-richting en vocabulaire-truncatie openbaart.
De complexiteit van de softwarestack (vLLM)
Om te begrijpen waar divergentie ontstaat, moeten we kijken naar de softwarestack. Een nightly VLLM container-image bevat bijvoorbeeld meer dan 700 packages. Dit zijn 734 verschillende codebases, elk met eigen bugs en undocumented eigenaardigheden. De weg die een specifieke implementatie door deze berg code aflegt, is uniek.
Test 1: Precisie van Attention Backends
Tijdens de prefill (prompt-verwerking) selecteert de inference-engine een attention backend. Dit beïnvloedt zowel de snelheid als de precisie.
Methodologie
- Model: Qwen3.6-27B (BF16 checkpoint).
- Hardware: RTX PRO 6000 Blackwell GPU (tensor parallelism 1).
- Configuratie: BF16 KV-cache, geen quantisatie van weights of activaties, eager execution, CUDA-graphs uitgeschakeld, 2k-token chunked prefill.
- Workload: Een context van ongeveer 100k tokens uit een echte werkstroom met meerdere tool-aanroepen (geen synthetische tests).
Er werd vergeleken tussen drie backends: FlashAttention 2, Flash Inference en Triton Attention.
Resultaten
Er werd gekeken naar "Top-1 agreement": of het token met de hoogste logit (de greedy argmax) hetzelfde was. Een "top-1 flip" betekent dat een backend een ander volgend token zou hebben gekozen.
De resultaten toonden aan dat de backends bij de eerste duizenden tokens overeenstemden, maar later in de prompt begonnen te divergeren. Deze divergentie komt exclusief voort uit de matrix-vermenigvuldigingen en optellingen tijdens de prefill binnen de verschillende backends.
Test 2: KV-Cache Quantisatie
Wat gebeurt er als de weights en activaties ongewijzigd blijven (BF16), maar alleen de KV-cache wordt gekwantiseerd?
Resultaat: Er treedt significante divergentie op. Bij tool-aanroepen bleek dat BF16 correct functioneerde en INT8 uiteindelijk kon herstellen, maar dat INT4 faalde. Dit suggereert dat de effectieve intelligentie van een LLM drastisch kan dalen na bijvoorbeeld 40k tokens bij gebruik van een gekwantiseerde KV-cache.
Test 3: Weight Quantisatie
In dit experiment bleef de KV-cache op BF16, maar werden verschillende quantisaties van de weights vergeleken:
- BF16 referentie: Qwen3.6-27B
- Official FP8: Qwen3.6-27B-FP8
- INT8 W8A16: TheHouseOfTheDude/Qwen3.6-27B-INT8
- NVIDIA NVFP4: nvidia/Qwen3.6-27B-NVFP4
- AWQ W4A16: cyankiwi/Qwen3.6-27B-AWQ-BF16-INT4
Technische details van de implementaties
- BF16: Referentie-checkpoint.
- FP8: E4M3 FP8 weights; dynamische FP8 activatie-quantisatie.
- INT8: Statische, symmetrische, channel-wise INT8 weights; BF16 activaties (W8A16).
- NVFP4: Mixed checkpoint met FP8 en NVFP4 targets.
- AWQ: Statische asymmetrische INT4 weights, group size 32.
Resultaten van de "Bake-off"
De INT8 versie (TheHouseOfTheDude) presteerde het beste. De NVIDIA NVFP4-release kwam op de laatste plaats uit, met ongeveer 50% token-flips bij een context van 88k.
Zowel NVFP4 als AWQ W4A16 faalden bij het correct afsluiten van tool-aanroepen en maakten fouten in Cisco command-line syntax (bijv. show run in plaats van show arp), terwijl FP8 en INT8 de aanroepen correct voltooiden.
Diepere analyse van Token Flips
Wanneer een token-flip optreedt, kan dit leiden tot een volledig andere output-stroom. In een testcase waarbij een tool-aanroep werd gedaan voor een Cisco-router interface (GigabitEthernet0/0/1.201), gebeurde het volgende:
- Referentie: Correcte uitvoering.
- Flash Attention 2: Verkeerd token gekozen → targette
GigabitEthernet0/1/4 → probeerde de fout te herstellen met het verkeerde commando (show run in plaats van show mac address table).
Dit bewijst dat een eenvoudige runtime-keuze in CUDA-kernels in een productieomgeving kan leiden tot kritieke netwerkstoringen.
Tensor Parallelisme (TP)
Er is ook divergentie zichtbaar bij Tensor Parallelisme:
- TP1: Acceptabele tool-aanroep.
- TP2: Faalt.
- TP4: Slaagt weer.
Dit wijst vaak op problemen binnen NCCL (Nvidia Collective Communications Library).
Analyse van "Uncensored" en "Abliterated" Modellen
Er is een trend om modellen te gebruiken die gelabeld zijn als "HERETIC", "UNCENSORED" of "ABLITERATED". Er is onderzocht wat de impact hiervan is op de technische capaciteiten van Qwen 3.8.
Vergeleken modellen:
- Stock Qwen 3.8 (BF16)
- Heretic-ARA
- Huihui Abliterated
- Blackfrost Abliterated
- AEON Ultimate Uncensored
Bevindingen
| Model | Top-1 flips (SP06) | Impact op technische output |
|---|
| Heretic-ARA | 1.337% | Zeer functioneel, minimale destabilisatie. |
| Huihui | 1.406% | Verrassend goed, behoudt technische workload. |
| Blackfrost | 4.978% | Significante wijzigingen, blijft meestal coherent. |
| AEON Ultimate | 5.831% | Disruptief, produceert structureel ongeldige outputs. |
Specifiek falen van AEON: In een PostgreSQL-context koos het model bij een port-nummer (5432) het token ql in plaats van 2, resulterend in 543ql. Ook werden hostnames gecorrumpeerd en API-argumenten (page_size=100 werd size=100) ongeldig gemaakt.
Conclusies over determinisme en precisie
Waarom niet alles in integers (INT) berekenen?
Men zou kunnen denken dat het gebruik van integers zonder afronding (zoals INT64 accumulatoren) non-determinisme zou oplossen. Echter:
- Computationele kosten: INT64-berekeningen miljarden keren uitvoeren in MMA-operaties is prohibitief duur.
- Hardware: De meeste GPU-hardware heeft geen native INT64 accumulatoren.
- Emergentie: Er is een theorie dat de lichte randomheid van floating-point berekeningen juist bijdraagt aan de "vonk" van LLM's; een volledig deterministisch model zou mogelijk minder creatief of intelligent zijn.
Samenvatting
De perceptie dat een lokaal model "dommer" is, komt vaak niet door het model zelf, maar door de cumulatieve effecten van:
- De keuze van de Attention Backend (bijv. FA2 vs Triton).
- Quantisatie van de KV-cache (vooral bij lange contexten).
- De gekozen weight-quantisatie (sommige FP4/INT4 implementaties zijn instabieler dan anderen).
- De impact van "abliteration" (het verwijderen van censuur), wat in sommige gevallen de precisie van technische output ernstig beschadigt.
Groetjes,