AMD RX580 a fait tourner un LLM en local : comment venir à bout de ROCm, d'Ollama et obtenir une inférence sur GPU

Exécuter une LLM sur une ancienne AMD RX580 s'est avéré être non une question d'une seule commande chanceuse, mais une véritable enquête d'ingénierie. L'auteur tentait d'obtenir une inférence GPU appropriée via ROCm et Ollama dans Kubernetes, mais au lieu d'une génération stable, il a reçu de faux signes de succès, des défaillances mémoire et parfois du texte dénué de sens en sortie.

Symptômes et Pièges

Au début, tout semblait pratiquement fonctionnel. La carte graphique était détectée, les conteneurs se levaient, la VRAM se remplissait, ce qui signifiait que le système semblait bien utiliser le GPU. Mais c'était un piège : la mémoire occupée ne signifie pas nécessairement que les calculs se déroulent correctement sur le processeur graphique.

Le principal problème s'est manifesté au moment de l'inférence réelle — les requêtes échouaient avec des erreurs hipMemGetInfo ou se terminaient par une génération étrange qui superficiellement ressemblait au fonctionnement du modèle, mais ne produisait en réalité aucun résultat significatif.

Le GPU était détecté, la VRAM était occupée, les conteneurs

s'exécutaient — mais l'inférence échouait avec des erreurs hipMemGetInfo.

Ce cas illustre bien une erreur typique lors de l'exécution de LLM localement : regarder uniquement l'« apparence de vie » de l'infrastructure. Si Kubernetes a lancé le conteneur, Ollama a vu le modèle, et le GPU a occupé plusieurs gigabytes, cela ne confirme pas encore que la pile ROCm exécute réellement les opérations matricielles correctement. Pour les anciennes cartes comme la RX580, il est particulièrement important de vérifier non seulement la disponibilité de l'appareil, mais aussi le compute-path réel, car la défaillance peut se cacher sous le niveau de l'application elle-même.

Comment Ils Ont Trouvé la Cause

La racine du problème a pu être réduite non pas par une énième réinstallation de paquets, mais par le diagnostic du circuit computationnel. L'auteur comparait les signes de fonctionnement à différentes couches du système et séparait les succès cosmétiques de l'exécution réelle de l'inférence. Vulkan s'est avéré être inopinément l'outil clé ici : il a aidé à vérifier si le GPU pouvait de manière stable accomplir des tâches computationnelles, et ainsi a mis en évidence que le problème ne se réduisait pas uniquement à Ollama ou à la configuration du conteneur.

Essentiellement, l'enquête a procédé des symptômes aux hypothèses testables. Au lieu de deviner à partir des journaux, l'auteur a systématiquement éliminé les fausses explications et assemblé une configuration minimalement fonctionnelle, en vérifiant chaque couche séparément : des conteneurs et du runtime aux drivers et au modèle lui-même. Cet ordre est important car il permet de comprendre où s'arrête « l'infrastructure s'est levée » et où commence le véritable pipeline computationnel.

Dans l'analyse, cela ressemblait étape par étape à ceci :

• Vérification du compute GPU réel, pas seulement utilisation de VRAM
• Comparaison du comportement de ROCm et Vulkan
• Filtrage des problèmes de conteneur et d'orchestration
• Recherche de versions compatibles du kernel et de ROCm
• Contrôle de la qualité de la sortie du modèle lui-même

Cette approche est importante car le texte dénué de sens en sortie est aussi un signal de diagnostic. Si le modèle répond mais génère du charabia, la défaillance peut ne pas être dans le chargement des poids, mais dans le fonctionnement incorrect des calculs, une incompatibilité de drivers ou un backend partiellement fonctionnel qui ne semble vivant qu'en surface. Ces états semi-fonctionnels consomment typiquement plus de temps qu'une défaillance complète car ils se déguisent en bugs aléatoires de l'application.

Configuration Fonctionnelle sur RX580

L'expérience s'est conclue non par un « réglage magique », mais par une combinaison trouvée de versions et de composants sous laquelle la vieille RX580 produit bel et bien des résultats stables. L'auteur écrit que certaines versions spécifiques de ROCm et du kernel Linux se sont avérées fonctionnelles, et après avoir résolu les conflits, l'inférence a cessé de s'écrouler et a commencé à produire un texte normal. C'est une conclusion importante pour quiconque essaie d'exécuter des modèles locaux sur des graphiques AMD non si nouveaux : le succès dépend ici bien moins du support matériel nominal que de l'alignement exact des couches driver, système et runtime.

Le résultat pratique semble convaincant : sur la RX580, ils ont réussi à obtenir environ 42 tokens par seconde. Pour une carte graphique domestique de la génération précédente, ce n'est plus simplement une démonstration mais un mode opérationnel dans lequel on peut tester des assistants locaux, des prototypes de scénarios RAG et des services d'inférence personnels sans nécessairement mettre à jour vers une pile NVIDIA fraîche. Mais la leçon principale ne réside pas dans le chiffre de la vitesse, mais dans la méthode : si le GPU « semble fonctionner », ce n'est pas suffisant. Ce qui doit être vérifié, c'est la stabilité des calculs, la correction de la sortie et la reproductibilité des résultats.

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 elle requiert de la discipline dans le diagnostic. Pour les développeurs, c'est une bonne ligne directrice : ne pas confondre VRAM occupée avec fonctionnement réel du modèle, vérifier la pile entière du kernel au runtime, et traiter une sortie étrange comme une erreur à part entière, non comme un léger problème. Pour les laboratoires domestiques, c'est pratiquement une liste de contrôle prête à l'emploi pour ne pas gaspiller des jours à chasser de faux signes de succès.