Une AMD RX580 fait tourner un LLM à la maison : comment dompter ROCm et Ollama pour obtenir l'inférence sur GPU

Faire tourner un LLM sur une vieille AMD RX580 n'a pas été l'affaire d'une seule commande bien sentie, mais une véritable enquête d'ingénierie. L'auteur cherchait à obtenir une inférence GPU correcte avec ROCm et Ollama dans Kubernetes. Au lieu d'une génération stable, il a récolté de faux signes de réussite, des plantages liés à la mémoire et, par moments, du texte dénué de sens en sortie.

Symptômes et pièges

Au départ, tout semblait presque fonctionner. La carte graphique était détectée, les conteneurs démarraient, la VRAM se remplissait : le système paraissait donc bien utiliser le GPU. C'était un piège. De la mémoire occupée ne signifie pas que les calculs s'exécutent correctement sur le processeur graphique. Le vrai problème surgissait au moment de l'inférence proprement dite : les requêtes échouaient avec des erreurs hipMemGetInfo ou se terminaient par une génération étrange, qui ressemblait en apparence au travail du modèle sans produire le moindre résultat cohérent.

Le GPU était détecté, la VRAM se remplissait, les conteneurs

démarraient — mais l'inférence plantait avec des erreurs hipMemGetInfo.

Ce cas illustre une erreur classique lors de l'exécution locale d'un LLM : se fier uniquement aux « signes de vie » de l'infrastructure. Que Kubernetes ait lancé le conteneur, qu'Ollama ait vu le modèle et que le GPU ait occupé quelques gigaoctets ne prouve pas que la pile ROCm exécute réellement les opérations matricielles comme il faut. Sur des cartes anciennes comme la RX580, il est particulièrement important de vérifier non seulement la disponibilité du périphérique, mais aussi le chemin de calcul effectif, car la panne peut se loger sous le niveau de l'application elle-même.

Comment la cause a été trouvée

L'auteur a pu circonscrire l'origine du problème non pas en réinstallant une énième fois des paquets, mais en diagnostiquant la chaîne de calcul. Il a comparé les signes de fonctionnement dans les différentes couches du système et séparé les succès cosmétiques de l'exécution réelle de l'inférence. L'outil clé s'est révélé, de façon inattendue, être Vulkan : il a permis de vérifier si le GPU était tout simplement capable d'exécuter des tâches de calcul de manière stable, et a ainsi montré que le problème ne se résumait ni à Ollama seul, ni à la configuration du conteneur.

Concrètement, l'enquête est partie des symptômes pour aboutir à des hypothèses vérifiables. Plutôt que de deviner à partir des logs, l'auteur a écarté une à une les fausses explications et assemblé une configuration minimale fonctionnelle, en testant chaque couche séparément : du conteneur et du runtime jusqu'aux pilotes et au modèle lui-même. Cet ordre compte, car c'est lui qui permet de comprendre où s'arrête « l'infrastructure est en place » et où commence le véritable pipeline de calcul.

Dans l'analyse, la démarche se déroulait étape par étape :

• Vérification du calcul GPU réel, et pas seulement de l'utilisation de la VRAM
• Comparaison du comportement de ROCm et de Vulkan
• Élimination des problèmes liés au conteneur et à l'orchestration
• Recherche de versions compatibles du kernel et de ROCm
• Contrôle de la qualité de la sortie du modèle

Cette approche est importante, car un texte incohérent en sortie est lui aussi un signal de diagnostic. Si le modèle répond mais génère du charabia, la panne ne se situe pas forcément dans le chargement des poids : elle peut venir d'un calcul incorrect, d'une incompatibilité de pilotes ou d'un backend partiellement fonctionnel qui ne paraît vivant qu'en surface. Ce sont précisément ces états à moitié fonctionnels qui coûtent le plus souvent plus de temps qu'une panne franche, car ils se déguisent en bugs aléatoires de l'application.

La combinaison qui fonctionne sur RX580

L'expérience ne s'est pas conclue sur un « réglage magique », mais sur une combinaison de versions et de composants grâce à laquelle la vieille RX580 finit par donner un résultat stable. L'auteur indique que certaines versions de ROCm et du noyau Linux se sont révélées fonctionnelles : une fois les conflits résolus, l'inférence a cessé de planter et s'est mise à produire du texte normal. C'est un enseignement important pour quiconque tente de faire tourner des modèles locaux sur une carte graphique AMD qui n'est plus de première jeunesse : le succès dépend moins du support officiel du matériel que de l'alignement précis des couches pilote, système et runtime.

Le bilan pratique est convaincant : la RX580 atteint environ 42 tokens par seconde. Pour une carte grand public de génération précédente, ce n'est plus une simple démonstration, mais un mode de fonctionnement exploitable pour tester des assistants locaux, des prototypes de scénarios RAG et des services d'inférence personnels, sans passer obligatoirement par une mise à niveau vers une pile NVIDIA récente. Mais la principale leçon tient moins au chiffre de vitesse qu'à la méthode : un GPU qui « a l'air de fonctionner » ne suffit pas. Il faut vérifier précisément la stabilité des calculs, l'exactitude de la sortie et la reproductibilité du résultat.

Ce que cela signifie

L'histoire de la RX580 montre que l'inférence LLM locale sur du matériel AMD ancien est possible, mais qu'elle exige de la rigueur dans le diagnostic. Pour les développeurs, c'est un bon repère : ne pas confondre VRAM occupée et fonctionnement réel du modèle, vérifier toute la pile du kernel jusqu'au runtime, et traiter une sortie étrange comme une erreur à part entière plutôt que comme un incident mineur. Pour les homelabs, c'est presque une checklist toute prête pour éviter de perdre des jours sur de faux signes de réussite.