Nieuws
Onze experimentele configuratie: een model van ~83,6 GB dat lokaal draait op een budget RTX 3060
Qwen3.8-Flash-Next IQ3_S op een RTX 3060 12 GB met slechts 48 GB systeem-RAM. Geen cloud-gevolgtrekking. Gewoon betaalbare consumentenhardware.

Dit is ongelooflijk!
Qwen3.8-Flash-Next IQ3_S (~83,6 GB) lokaal draaiend op een budget RTX 3060 12 GB met slechts 48 GB systeem-RAM!
Tot 68 tokens/sec decodering, ~916 tokens/sec promptverwerking en een 30K-token prompt verwerkt in slechts 34 seconden.
Mogelijk gemaakt door Strata by coldniko. Geen cloud-gevolgtrekking. Gewoon betaalbare consumentenhardware!
Volledige benchmarks, hardwarespecificaties, optimalisaties en afwegingen hieronder.
In het laatste gedeelte kunt u direct naar de belangrijkste punten gaan.
De hardware achter deze resultaten
Geen datacenter-GPU, geen dure multi-GPU-server en geen enorme RAM-configuratie.
Het hele experiment werd uitgevoerd op een vrij gewone consumenten-/werkstation-pc.

CPU
- Intel Core Ultra 7 265 (Arrow Lake)
- 20 kernen / 20 draden
- Tot 5,3 GHz
- 30 MB L3-cache
- AVX-VNNI / BF16-ondersteuning; geen AVX-512
Moederbord
- ASUS Pro Q870I-C
- Intel Q870-chipset, LGA1851
- Mini-ITX-vormfactor
Geheugen
- 48 GB DDR5-5600 (2 × 24 GB Micron)
- Ongeveer 46 GiB bruikbaar
GPU
- NVIDIA GeForce RTX 3060 12 GB
- GA106, rekencapaciteit 8.6
- PCIe 4.0 ×16
- 170 W geconfigureerde vermogenslimiet
Opslag
- Lexar NM1090 PRO 2 TB
- PCIe 5.0 ×4 NVMe
OS
- Ubuntu 24.04.5 LTS
- Linux-kernel 7.0.0-38
- NVIDIA-stuurprogramma 615.71.10
Netwerk
- Intel 1 GbE Ethernet
Het cruciale detail: het model is veel groter dan het beschikbare VRAM en RAM samen.
Dat is precies wat dit experiment interessant maakt.
Model-, engine- en geheugenarchitectuur
Model
Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S
Twee GGUF-scherven:
- 54.82 GB
- 28.80 GB
- Totaal: 83,62 GB (77,87 GiB)
Extra componenten
- Dichte gewichten verpakt: ~1,5 GiB
- MTP-tekenaar voor speculatieve decodering
- BF16 vision-adapter: ~866 MB
- CPU-gebaseerde vision-encoder (12 threads)
Inferentie-engine
- Strata engine 0.1.52
- CUDA 13.0-backend
- CUDA-architectuur sm_86
Werkelijke geheugentoewijzing
- GPU VRAM: 11,14 GiB gebruikt
- Ingezeten experts in systeem-RAM: 24 GiB
- Resterende expertgegevens gestreamd vanuit NVMe
- Geen ruilactiviteit tijdens normale gevolgtrekking
Belangrijke configuratie-instellingen
--expert-cache auto
--prefill 4096
--spec 4
--spec-min-p 0.5
--mtp mtp/rt
--max-context 32768
--kv int8
--kv-grow
--kv-resident 32768
--vision
--vram-reserve-mib 960
--pool-workers 12
--conversation-cache-mib 1536
--prompt-cache-tail
--prompt-cache-spread
--resident-experts
--resident-budget-gib 24
Dit is geen conventionele opstelling om het hele model in het GPU-geheugen te laden.
Strata gebruikt GPU-geheugen, systeem-RAM, expertcaching en NVMe-opslag samen.
De belangrijke optimalisatie is het minimaliseren van dure expertoverdrachten terwijl de GPU productief blijft.
Echte benchmarkresultaten
Hetzelfde model, dezelfde hardware, twee routeringsconfiguraties.
Modus A: snelle, op residentie gerichte expertroutering (vooraf = 1,5)
| Context | Voorvullen | Koud decoderen | Warme decodering |
|---|---|---|---|
| 1K | 285 tok/s | 42 tok/s | 61 tok/s |
| 4K | 804 tok/s | 50 tok/s | 65 tok/s |
| 8K | 819 tok/s | 61 tok/s | 68 tok/s |
| 16K | 916 tok/s | 60 tok/s | 68 tok/s |
| 30K | 890 tok/s | 58 tok/s | 61 tok/s |
Koude tijd tot eerste token:
- 1K: 3.7 s
- 4K: 4.9 s
- 8K: 9.7 s
- 16K: 17.3 s
- 30K: 33.9 s
Ter vergelijking: Modus B schakelt residency-biased routing uit (vooraf = 0):
| Context | Voorvullen | Koud decoderen | Warme decodering |
|---|---|---|---|
| 1K | 282 tok/s | 24 tok/s | 27 tok/s |
| 4K | 781 tok/s | 29 tok/s | 26 tok/s |
| 8K | 789 tok/s | 30 tok/s | 32 tok/s |
| 16K | 889 tok/s | 30 tok/s | 29 tok/s |
| 30K | 878 tok/s | 26 tok/s | 27 tok/s |
Generatierun van 500 tokens:
- Snel: 62 tok/s, 7,1 s totaal
- Nauwkeurig: 21 tok/s, 20,8 s totaal
Snelheidsmetingen werden vergeleken met de streamingtijden aan de clientzijde.
Belangrijkste observatie:
Het uitschakelen van cache-biased routing kan de decoderingssnelheid met ongeveer 2 à 2,4× verlagen.
Maar er is een belangrijke reden om agressieve routering niet voor elke werklast ingeschakeld te laten. Daarover meer in de volgende sectie.
Snelheid versus modelkwaliteit: de verborgen afweging
Op deze Strata-engineversie gebruiken GPU's met ≤13 GB VRAM automatisch residency-biased routing:
STRATA_ROUTE_PRIOR=1.5
Dit bevoordeelt experts die al beschikbaar zijn in snel geheugen, in plaats van altijd de experts te selecteren die de oorspronkelijke router zou verkiezen.
Het voordeel is dramatisch:
- Expert cache-hitpercentage: 97,2% in snelle modus
- Zonder de vooringenomenheid: 65,3%
- Opslag leest tijdens de vergeleken werkbelasting: 5,5 GiB versus 46 GiB
- Decodeersnelheid: ongeveer 2× sneller
Maar dit is GEEN gratis optimalisatie.
Het veranderen van de expertselectie kan het gedrag van het model veranderen, de afwijking van het oorspronkelijke model vergroten en lange redeneringen of workflows van agenten beïnvloeden.
Volgens de evaluatie van de ontwikkelaar over 10 agenttaken:
- Routering vóór 1,5: 4,5/10
- Routering vóór 0: 5,6/10
De basislijnresultaten zelf varieerden tussen runs, dus dit is een richtinggevend resultaat en geen definitieve kwaliteitsmeting.
Mijn eigen zes korte agentcontroles zijn in beide modi geslaagd.
Echter, een afzonderlijke nadruk op uniciteit bracht herhaling bloot:
- Snelle modus: 205 regels, 96 duplicaten
- Nauwkeurige modus: 209 regels, 79 duplicaten
De conclusie is duidelijk:
- Snelle routering voor chat, interactief gebruik en korte taken.
- Originele routing voor langere, kwaliteitsgevoelige workflows voor agenten.
En benchmarksnelheid alleen mag nooit worden verward met modelkwaliteit.
Snelle caching verandert alles
Een van de meest indrukwekkende resultaten was niet de decodeersnelheid. Het was de responstijd voor herhaalde verzoeken met dezelfde prompt.
Met een volledig in de cache opgeslagen prompt:
| Context | Koude TTFT | TTFT in cache |
|---|---|---|
| 1K | 3.7 s | 0.08 s |
| 4K | 4.9 s | 0.08 s |
| 8K | 9.7 s | 0.27 s |
| 16K | 17.3 s | 0.34 s |
| 30K | 33.9 s | 0.44 s |
Dat is ongeveer 45-90× minder tijd tot het eerste token in deze runs.
De promptcache maakt een groot verschil bij het herhaaldelijk opvragen van hetzelfde lange document of bij het voeren van een gesprek met een stabiele context.
De engine is ook geconfigureerd voor het cachen van gesprekken:
- 1.536 MiB cachebudget
- Minimaal 4.096 tokens voor parkeren
- Minimale drempel voor vrij geheugen: 1.536 MiB
Er zit een addertje onder het gras: deze resultaten gelden voor identieke aanwijzingen met een volledig herbruikbare cache.
Ze betekenen niet dat willekeurige nieuwe 30K-token-prompts binnen een halve seconde worden verwerkt.
Maar voor interactieve lokale AI is een warme cache een gamechanger.
Het SSD-mysterie: PCIe 5.0 is niet het knelpunt
In eerste instantie leek de NVMe-schijf verdacht traag. We hebben de PCIe-koppeling, de opslagtopologie en het daadwerkelijke I/O-gedrag onderzocht.
De schijf: Lexar NM1090 PRO 2 TB, PCIe 5.0 ×4.
Geverifieerde PCIe-verbinding:
- Huidige link: 32,0 GT/s ×4
- Maximale koppeling: 32,0 GT/s ×4
- CPU-rootpoort: 32,0 GT/s ×4
De schijf draait dus op de volledige PCIe 5.0-verbindingssnelheid.
Directe, niet in de cache opgeslagen leesbenchmarks:
- Enkele stream, 1–4 MiB-blokken: 2,9–3,4 GB/s
- Vier parallelle streams: 10,94 GB/s
- Vier streams, 64 KiB-blokken: 2,25 GB/s
- Vier streams, 4 KiB-blokken: 0,26 GB/s (~63K IOPS)
Dat parallelle resultaat van 10,94 GB/s is bijzonder belangrijk: het overschrijdt de praktische bandbreedte van PCIe 4.0×4.
Waarom is de single-stream-doorvoer veel lager?
Omdat PCIe-bandbreedte niet hetzelfde is als doorvoer op applicatieniveau.
Wachtrijdiepte, I/O-grootte, parallellisme van verzoeken en latentie zijn allemaal van belang.
Het expert-laadpatroon van Strata ligt veel dichter bij het geval van lagere gelijktijdigheid dan bij een synthetische benchmark voor maximale doorvoer.
Waargenomen motoropslagcapaciteit:
- Snelle routering: ~0,3 GB/s
- Originele routering: ~2,4 GB/s
Het verschil komt voort uit het aantal experts dat moet worden opgehaald, niet uit een PCIe-downgrade.
Nog een handig detail: de RTX 3060 zelf is een PCIe 4.0-apparaat. Het zien van de link naar Gen1 terwijl deze niet actief is, is normaal gedrag bij energiebeheer.
Controleer altijd welk apparaat u meet voordat u een PCIe-probleem diagnosticeert.
Een belangrijke les: laat Linux een model van 83,6 GB niet in de cache opslaan op een machine van 48 GB
Tijdens de eerste keer opstarten zijn we op een ernstig probleem gestuit.
De eerste configuratie maakte gebufferd laden van de modelbestanden mogelijk.
Het model is ~83,6 GB, terwijl het systeem slechts 48 GB fysiek RAM heeft.
Onder die werklast kwam Linux onder zware druk te staan om het geheugen terug te winnen. De machine reageerde vrijwel niet meer, inclusief SSH-connectiviteit, en moest opnieuw worden opgestart.
De oplossing was om de laadstrategie te wijzigen en geheugenbeveiligingen in te voeren.
Huidige instellingen:
- STRATA_UNBUFFERED_LOAD=1
- STRATA_RESIDENT_HEADROOM_GIB=10
- 24 GiB bewonersexpertenbudget
- Beschikbaarheid van geheugen gecontroleerd vóór lancering
- 12 GiB extra veiligheidsmarge in het lanceerbeleid
Na deze wijzigingen:
- Geen ruilactiviteit tijdens normale gevolgtrekking
- Ongeveer 34,6 GiB RAM in gebruik op het waargenomen punt
- Ongeveer 12,7 GiB beschikbaar
- Stabiele opwekking onder belasting
De les:
Het is mogelijk om een model te gebruiken dat groter is dan uw fysieke geheugen, maar geheugenaccounting is absoluut cruciaal.
Paginacachedruk, vastgezette modelgegevens, lokale experts en KV-cache moeten samen worden beschouwd.
Kopieer niet blindelings vlaggen met maximale prestaties van machines met veel grotere RAM-configuraties.
Stroomverbruik, thermiek en inferentiekosten
Dit is opnieuw een aangename verrassing.
Gemeten componentvermogen:
Inactief met geladen model:
- CPU: ~5.8 W
- GPU: 15–18 W
Tijdens generatie:
- CPU: ~62.8 W
- GPU: 152–167 W
- Korte GPU-pieken rond 174 W
Geschat totaal systeemvermogen aan de muur (niet gemeten met een muurmeter):
- Inactief: ~54 W
- Generatie: ~280 W
Waargenomen temperaturen:
- GPU onder belasting: 62–68°C
- GPU bij inactiviteit: ~40°C
- NVMe: 38–47°C
Geen waargenomen thermische throttling.
Bij een veronderstelde elektriciteitsprijs van € 0,25/kWh:
- 24 uur inactief: ~€ 0,32
- 30 dagen continu inactief: ~€9,72
- Eén uur actieve generatie: ~€ 0,07
Dit maakt het volkomen realistisch om thuis een capabel, privacybeschermend lokaal AI-eindpunt te exploiteren.
Uiteraard zijn dit geschatte elektriciteitskosten, niet de totale eigendomskosten. Afschrijving, koeling en onderhoud van hardware zijn uitgesloten.
Waar de RTX 3060-opstelling niet meer logisch is
Deze configuratie is uitstekend geschikt voor korte interactieve verzoeken, maar heeft wel beperkingen.
Het allerbelangrijkste:
- Maximale context: 32.768 tokens
- Een prompt van bijna 32K laat onvoldoende ruimte over voor generatie
- Het praktische benchmarkplafond was ~30.165 invoertokens
- Denken/redeneren kan honderden extra gegenereerde tokens verbruiken
- Langdurige agentsessies raken snel beperkt
Ter vergelijking: ik heb hetzelfde model op een krachtiger lokaal systeem met een GPU van 24 GB uitgevoerd.
Gemeten prestaties op dat systeem:
- 4K-promptvoorvulling: 1.339 tok/s
- 4K-decodering: 94 tok/s
- 16K snelle voorvulling: 2.956 tok/s
- 16K-decodering: 125 tok/s
- Maximale context: 262.144 tokens
- 15 werkthreads
Het RTX 3060-systeem levert een veel lagere prefill-doorvoer en ongeveer de helft van de decoderingsdoorvoer in vergelijkbare gevallen, met een achtste van de beschikbare context.
De kaart van 12 GB is echter veel toegankelijker en blijft indrukwekkend nuttig.
Mijn huidige aanpak:
- Krachtigere hardware voor complexe, langlopende agents
- Betaalbare GPU's van 12 GB voor chat, korte workflows, experimenten en back-up-inferentie
Het gaat er niet om te doen alsof een goedkope GPU een high-end machine vervangt.
Het punt is hoeveel nuttige lokale AI al op goedkope hardware kan draaien.
Wat kan er nog geoptimaliseerd worden?
Het systeem presteert al goed, maar er zijn een paar interessante mogelijkheden voor verdere experimenten.
Gelijktijdige gevolgtrekking
De --slots 2 optie zou de totale doorvoer kunnen verbeteren met twee gelijktijdige gesprekken.
Een geschatte totale doorvoer van +10-12% is mogelijk voor deze werklast, maar deze moet worden gevalideerd.
Dit betekent niet dat een enkel gesprek 12% sneller wordt.
Grotere voorvulbatches
Huidig: --prefill 4096
Kandidaat: --prefill auto:16384
Grotere voorvulvensters kunnen de lange-promptverwerking verbeteren, maar het beschikbare VRAM is al krap.
Omdat ongeveer 11,14 GiB van de 12 GiB van de GPU bezet is, moet het geheugengedrag zorgvuldig worden gemeten.
Meer systeem-RAM
Het gebruik van --ple-io ram zou meer modelgegevens in het systeemgeheugen kunnen brengen en het aantal leesbewerkingen kunnen verminderen.
De documentatie van de ontwikkelaar suggereert:
- +16–31% prestatie bij vooraf vullen
- +3–11% decoderingsprestaties
Maar deze configuratie zou aanzienlijk meer RAM vereisen, ongeveer 72+ GiB voor de gemeten lay-out.
Het is niet praktisch met de huidige 48 GB-configuratie.
Speculatieve decodering
Speculatieve MTP-decodering is al ingeschakeld.
Waargenomen acceptatie: ~33–41 geaccepteerde tokens van de 50–60 opgestelde tokens, of ongeveer 65–70%.
Langere context
De huidige limiet van 32K is een operationele configuratielimiet en geen bewijs dat het model zelf slechts 32K ondersteunt.
Om dit te vergroten, moet de geheugencapaciteit, het KV-cachegedrag, de latentie en de stabiliteit opnieuw worden gecontroleerd.
Voor deze werklast kan het verminderen van dure leesbewerkingen door experts en het verbeteren van toegangspatronen belangrijker zijn dan het verhogen van de maximale sequentiële bandbreedte van de schijf.
Zoals altijd: benchmark de echte werklast, niet alleen hardwaremarketingcijfers.
Laatste gedachten
Dit is wat dit experiment laat zien.
Een gekwantiseerd MoE-model van ~83,6 GB kan lokaal draaien op:
- RTX 3060 12 GB
- 48 GB DDR5 RAM
- Consumenten Intel-CPU
- PCIe 5.0 NVMe SSD
- Ubuntu + Strata
Met meetresultaten tot:
- 68 tok/s warme decodering
- 916 tok/s snelle verwerking
- 30K-token koude prompt in ~34 seconden
- Volledig in de cache opgeslagen 30K-prompt: ~0,44 s tot eerste token
- Geen uitwisseling onder normale bedrijfsomstandigheden
Maar er zijn belangrijke kanttekeningen.
- De maximaal geconfigureerde context is 32 KB
- Snelle deskundige routering verandert het gedrag van het model
- De hoogste snelheid betekent niet noodzakelijkerwijs de hoogste kwaliteit
- Opslagprestaties zijn afhankelijk van toegangspatronen
- Geheugenbeheer vereist zorgvuldige afstemming
- Langdurige agents profiteren van krachtigere hardware
Ik ben vooral geïnteresseerd in de praktische economie van lokale AI.
Niet alleen de maximale benchmark op een systeem van € 10.000, maar ook de bruikbare prestaties die haalbaar zijn op consumentenmachines en betaalbare configuraties vanaf ongeveer € 1.000.
Privacy, onafhankelijkheid, gecontroleerde bedrijfskosten en bruikbaarheid in de praktijk zijn belangrijker dan alleen het najagen van indrukwekkende benchmarkcijfers.
Dit is nog steeds een experiment in ontwikkeling en ik zal de metingen, mislukkingen, configuratiewijzigingen en verbeteringen blijven delen.
De toekomst van lokale AI wordt nu al verrassend betaalbaar.
Latere toevoegingen
Oh, ik vergat te vermelden dat de GPU draait met NVIDIA Unlock, dat vorige week nog maar een paar dagen geleden werd uitgebracht.
Ik heb mijn AI-agent nu gevraagd om dezelfde benchmarks uit te voeren zonder ontgrendeling, zodat we de resultaten binnen ongeveer 15 tot 20 minuten kunnen vergelijken.
De komende dagen, maar niet vandaag, zal ik deze GPU installeren in een systeem dat minder dan $ 1.000 kost, en kijken hoe hij daar presteert.