Geschreven op 31 juli 2026, bijgewerkt op 24 augustus. De opstelling draait nu llama.cpp met Qwen3.6-35B-A3B in plaats van vLLM met Qwen3-14B. De cijfers in de tabel komen van die eerste opzet.
Wie thuis een taalmodel wil draaien, krijgt overal hetzelfde advies: koop NVIDIA. Ik koos voor een Intel Arc Pro B70 en zou die keuze zo weer maken. Wat de kaart je geeft is 30,3 GiB bruikbaar VRAM, en dat is het verschil tussen een model dat er net in past en een model met ruimte voor context erbovenop. Er is wel leergeld te betalen. Dit stuk gaat over hoeveel.
De kaart zit in een privileged LXC-container op Proxmox met 16 GiB systeemgeheugen, acht CPU’s en 250 GB schijfruimte. Voor inferentie is dat ruim voldoende. Om zelf dingen te compileren is het dat niet, en dat bleek uit te maken.
Wat het kost om te beginnen
Drie dingen hielden me langer op dan ik had verwacht. Ik zet ze hier neer omdat je ze alle drie in een middag oplost als iemand je erover vertelt, en anders ben je een week kwijt.
Ten eerste wordt de kaart alleen herkend door een recent genoeg compute runtime. Meldt clinfo nul platforms, dan is je NEO-driver te oud voor PCI-id e223. Er is niets mis met je configuratie, en de foutmelding stuurt je nergens zinnigs naartoe. Werk hem bij en de kaart verschijnt.
Dan is er de cpuset van de container, die op mijn machine geen nette 0 tot en met 7 was maar 5-6, 8, 11-12, 18, 20, 22. oneCCL wil een affinity-CPU die echt in die set bestaat. Noem je er een die dat niet doet, dan struikelt vLLM over failed to start worker # 0, wat leest als een rechtenprobleem terwijl het daar helemaal niets mee te maken heeft. Erger nog: de set verschuift als je de host herstart, dus een configuratie die maandag werkte kan dinsdag stuk zijn. Uiteindelijk heb ik het geheel in een script gestopt dat de affinity bij elke start opnieuw berekent.
En tot slot: vLLM zelf bouwen gaat niet met 16 GiB, omdat de linker zonder geheugen komt te zitten. Gebruik de eigen container van Intel, intel/llm-scaler-vllm:latest. De documentatie raadt :latest af, en toch is dat de weg die je er brengt.
Kies je model zorgvuldig en het draait gewoon
Dit is de echte beperking van het Intel-platform, en een waar je omheen kunt werken zodra je ervan weet. De XPU-kernels van Intel zijn betrouwbaar voor architecturen die Intel expliciet heeft gevalideerd. Bij nieuwere modellen gaat het mis op kernelniveau, en dat gebeurt na het laden, bij de eerste echte inferentie. Daardoor lijkt het alsof je iets verkeerd hebt ingesteld.
De vuistregel die ik eraan overhield: dense architectuur, AWQ of GPTQ, en minstens zes maanden oud. Alles wat aan die beschrijving voldoet, draait.
| Configuratie | Resultaat |
|---|---|
| Qwen3-14B-AWQ | 55 tok/s bij 131k context, destijds het hoofdmodel |
| Qwen3-32B-AWQ | 20.6 tok/s bij 72k context |
| gpt-oss-20b MXFP4 | 61 tok/s, zwak in agentisch toolgebruik |
| Qwen3.5-9B FP8 | kapotte Gated Delta Network-kernel |
| gemma-4-12B w4a16 | faalt op elke attention-backend |
| llama.cpp via Vulkan | 34 tok/s, werkt zonder oneAPI |
Twee van de zes vielen om op een kapotte kernel. Dat klinkt slecht, tot je bedenkt dat de vier die wel werken al mijn workloads afdekken, en dat de beste 55 tokens per seconde haalt met de volledige 131k context beschikbaar. Dit is geen noodoplossing waar je mee leert leven. Je gaat gewoon aan het werk.
De onderste rij verdient een eigen vermelding. llama.cpp op Vulkan draait zonder oneAPI, zonder de container van Intel, zonder al het SYCL-steigerwerk. Langzamer, ja. Wil je aan de slag zonder eerst een dag aan drivers te besteden, dan draai je hiermee binnen een uur. Het is inmiddels mijn standaard geworden, en er draait nu een model met 35 miljard parameters op deze kaart.
Beeldanalyse blijft op de processor
Dat lijkt zonde van de GPU, tot je de koude start timet. Een vLLM-instantie heeft 130 seconden nodig voordat hij zijn eerste token produceert. Voor foto’s die af en toe langskomen, overheerst dat wachten de hele ervaring. Via llama.cpp op de processor kost het 4,1 GB RAM, helemaal geen VRAM, en het hoofdmodel blijft op volle kracht. Per afbeelding duurt het langer. In de praktijk is het sneller.
De 32B bleek overbodig
Ik heb beide modellen op schijf gezet met een commando om ertussen te wisselen, omdat ze niet samen in het VRAM passen. Over veertig agentische tests scoorden ze allebei veertig op veertig. Het grotere model kost je de helft van je context, 72k tegenover 131k, en een flink deel van je concurrency, 1.17x tegenover 1.93x.
Voor deze workload voegt de 32B dus niets toe. Dat is het soort antwoord waarvoor ik aan dit project begon: ik had het kunnen raden, nu weet ik het, en het heeft me de aankoop van iets zwaarders bespaard.
Zou ik het aanraden?
Ja, met één kanttekening. Als je het leukste aan de hobby vindt om gloednieuwe modellen uit te proberen, koop dan NVIDIA, want daar draait alles vanaf dag één. Wil je een stabiele machine met een goed model en volop context, en vind je het niet erg om een paar avonden aan drivers en containers te besteden, dan krijg je bij Intel meer geheugen voor je geld dan waar ook.
Sinds die drie hobbels achter me liggen, heb ik er nauwelijks meer naar hoeven kijken. De kaart doet gewoon zijn werk, en dat is het hoogste compliment dat je een stuk hardware kunt geven.