Waarom herkent Ollama je AMD GPU niet?

Lokale AI-tools zoals Ollama en LM Studio zijn gebouwd met Nvidia in gedachten. AMD-ondersteuning is er wel, maar vraagt meer handwerk. De kern van het probleem: ROCm, de software-laag die AMD-GPU’s laat praten met AI-frameworks, herkent niet elke GPU-architectuur automatisch. Nieuwere of minder gangbare AMD-chips krijgen een foutmelding, terwijl de hardware zelf prima modellen kan draaien.

ROCm staat voor Radeon Open Compute. Het is AMD’s antwoord op CUDA, de technologie van Nvidia waarmee GPU’s rekentaken uitvoeren zoals AI. Het probleem: ROCm heeft een lijst van officieel ondersteunde GPU-architecturen. Valt jouw kaart er net buiten, dan crasht de software of negeert hij je GPU gewoon.

De workaround die al jaren de ronde doet op forums: stel de omgevingsvariabele HSA_OVERRIDE_GFX_VERSION handmatig in. Hiermee vertel je ROCm dat jouw GPU zich moet gedragen als een andere, wel ondersteunde architectuur. Werkt prima, maar je moet weten welke waarde je invult. Verkeerde waarde? Crashes, trage output, of een model dat helemaal niet laadt.

Ik heb dit zelf verkeerd ingeschat toen ik voor het eerst een lokaal model probeerde te draaien op een AMD-systeem. Ik dacht dat het een driver-probleem was en heb een uur gezocht in de verkeerde richting. Het was gewoon die ene omgevingsvariabele. Sindsdien check ik dit altijd als eerste bij AMD-hardware.

Meer weten over hoe AI-tools en hardware samenwerken in een development-setup? In dit overzicht over AI code editors vergelijken in 2026 bespreek ik ook hoe de onderliggende hardware je workflow beïnvloedt.

ROCmFix: één commando, GPU herkend

ROCmFix is een Python-script dat de HSA_OVERRIDE_GFX_VERSION-instelling automatisch bepaalt en instelt. Het leest je GPU-informatie uit het Windows-register of via lspci op Linux, zoekt de juiste architectuurwaarde op, en schrijft de variabele permanent weg. Je hoeft geen forumdraden door te spitten voor de juiste waarde.

De tool werkt op zowel Windows als Linux. Op Windows leest hij de PCI-ID van je GPU uit het register. Op Linux gebruikt hij lspci, het standaardcommando om hardware-informatie op te vragen. Op basis van die ID zoekt ROCmFix de juiste GFX-versie op en stelt die in.

Draaien doe je zo:

python rocmfix.py

Wil je eerst checken wat er allemaal geïnstalleerd is? Gebruik dan:

python rocmfix.py doctor

Dat geeft een overzicht van je geïnstalleerde HIP SDK en Vulkan-componenten. Handig als startpunt voordat je begint met modellen laden.

ROCmFix werkt met CMD, PowerShell, Bash, Zsh en Fish. Je stelt de variabele permanent in of alleen voor de huidige sessie, afhankelijk van wat je kiest. Permanent is handig als je altijd met dezelfde GPU werkt. Sessie-instelling is beter als je wisselt tussen systemen of GPU’s.

Let op: ROCmFix is een community-tool, geen officieel AMD-product. Controleer altijd de broncode voordat je een onbekend script uitvoert met systeemtoegang.

ROCm of Vulkan: welke backend is sneller op jouw GPU?

Als je GPU eenmaal herkend is, komt de volgende vraag: draai je je modellen via de ROCm/HIP-backend of via Vulkan? Vulkan is een grafische API die je ook voor compute-taken inzet. ROCm is specifiek gebouwd voor GPU-rekentaken. Welke sneller is, verschilt per GPU-generatie. InferBench meet dit automatisch op jouw systeem.

Vulkan en ROCm/HIP geven op papier andere prestaties. In de praktijk hangt het af van je specifieke GPU, het model dat je draait, en de hoeveelheid VRAM die je tot je beschikking hebt.

InferBench automatiseert het vergelijken. Het werkt zo:

1. Eerst stuurt het een warm-up query, zodat het model volledig in VRAM geladen is.
2. Dan dwingt het een VRAM-unload tussen elke testrun, zodat caching de resultaten niet vertekent.
3. Het berekent de mediaan van tokens per seconde (tok/s) en de TTFT (Time-to-First-Token, de tijd tot het eerste woord verschijnt).

Die twee getallen zeggen je alles. Tok/s bepaalt hoe snel een lang antwoord gegenereerd wordt. TTFT bepaalt hoe snel de tool voelt voor de gebruiker. Een hoge tok/s met een hoge TTFT is frustrerend in gebruik, ook al is de totaalsnelheid goed.

Naar mijn idee is InferBench de ontbrekende schakel die mensen altijd overslaan. Ze draaien een model, het lijkt te werken, en ze stoppen daar. Maar zonder meting weet je niet of je 40% snelheid laat liggen omdat je de verkeerde backend gebruikt. Dat is zonde als je toch al de moeite hebt genomen om alles lokaal op te zetten.

Zie ook hoe lokale AI-tools passen in een bredere developer-workflow in dit artikel over de rol van developers in het AI-tijdperk.

Wanneer kies je voor een lokale LLM-setup op AMD?

Lokaal draaien van een AI-model heeft voordelen: geen API-kosten, geen data die de deur uitgaat, en je kunt offline werken. Maar het vraagt meer technische kennis dan een cloud-API aanroepen. Op AMD-hardware vraagt het nog wat extra stappen. Dit is mijn eerlijke afweging van wanneer het de moeite waard is.

Ik zou een lokale AMD-setup overwegen als je aan drie van de volgende vier punten voldoet:

• Je hebt een AMD GPU met minimaal 8 GB VRAM (minder werkt, maar dan draai je alleen kleine modellen).
• Je verwerkt gevoelige data die je niet naar een externe API wilt sturen.
• Je maakt intensief gebruik van AI en de API-kosten lopen op.
• Je hebt een half uur om de setup te doen en wil geen cloudafhankelijkheid.

Heb je een Nvidia GPU? Dan is de setup aanzienlijk eenvoudiger. CUDA werkt zonder gedoe, en Ollama herkent de meeste Nvidia-kaarten direct. AMD vraagt die extra ROCmFix-stap.

Heb je geen eigen GPU of wil je niet sleutelen? Dan is een cloud-API gewoon sneller en goedkoper voor de meeste use cases. De tools die hier besproken worden zijn voor developers die bewust kiezen voor lokaal draaien en de technische overhead accepteren.

Als je al werkt met lokale AI in je projecten, bekijk dan ook hoe je van het ene LLM-model naar het andere migreert zonder dat je applicatie omvalt.