Beaucoup de tours de PC en Hauts-de-France embarquent une Radeon plutôt qu’une carte NVIDIA. Bonne nouvelle : l’IA locale n’est pas réservée au camp vert. Moins bonne : la compatibilité dépend du modèle de GPU, de l’OS et du backend (ROCm ou Vulkan). Ce tutoriel pose une méthode honnête pour faire tourner Ollama ou llama.cpp sur AMD, sans inventer de palmarès face à NVIDIA. L’objectif : savoir si votre machine de Valenciennes, Lille ou Beauvais peut servir — et comment le prouver.
Compatibilité : commencer par le nom exact du GPU
Dans un terminal Linux, `lspci` ou les outils AMD affichent le nom de puce. Sous Windows, le Gestionnaire de périphériques ou Adrenalin suffisent. Notez le nom commercial et, si possible, le code GPU. Ensuite seulement, ouvrez la documentation ROCm courante et la FAQ du runtime que vous visez (Ollama, llama.cpp). Une fiche forum de 2024 peut être fausse en septembre 2026.
Les gammes « grand public » récentes sont mieux couvertes qu’il y a quelques années, mais des exceptions existent. Si votre carte n’apparaît nulle part, Vulkan ou le CPU seront plus réalistes que d’insister sur ROCm. Pour dimensionner le modèle, quel modèle selon la machine reste valide : la mémoire GPU compte autant que la marque.
ROCm ou Vulkan : comment trancher
ROCm est la pile AMD orientée calcul, historiquement plus aboutie sous Linux. Quand votre GPU est supporté et que les paquets s’installent proprement, Ollama ou d’autres runtimes peuvent s’appuyer dessus. Vulkan est une API graphique largement présente : llama.cpp et d’autres projets s’en servent pour offloader sur des GPU variés, parfois au prix de performances moins prévisibles.
ROCm (Linux)
À viser si votre GPU est listé et que vous maîtrisez l’admin Linux.
- Meilleure intégration calcul quand supporté
- Installation parfois exigeante
- Windows : support plus limité / différent
Vulkan
Plan B pragmatique, surtout via llama.cpp.
- Couverture GPU plus large
- Perf et maturité variables
- Bon pour débloquer une machine
CPU / petit modèle
Filet de sécurité pédagogique.
- Toujours utile pour smoke test
- Lent sur gros LLM
- Évite de culpabiliser la « mauvaise marque »
Pas à pas : valider une Radeon pour le LLM
Inventorier GPU, OS et mémoire
Notez le modèle exact, la quantité de mémoire GPU, l’OS (Ubuntu LTS, autre distribution, Windows). Sur un PC d’occasion acheté à Roubaix, la carte peut être plus modeste que le sticker du boîtier. Vérifiez aussi l’alimentation : un GPU qui throttle faute de watts donne l’illusion d’un mauvais backend. Si quelque chose échoue, arrêtez-vous et notez le message exact avant de retenter. Une capture d’écran des logs vaut mieux qu’une reformulation de mémoire, surtout quand un collègue de Douai ou Arras reprendra le dossier le lendemain.
Décider ROCm, Vulkan ou les deux en séquence
Si la doc ROCm liste votre GPU pour votre OS cible, tentez ROCm d’abord sur une machine jetable ou un dual-boot. Sinon, passez à Vulkan via llama.cpp. Évitez d’installer dix piles en parallèle le même soir : les conflits de pilotes sont réels. Une feuille de route écrite évite le chaos. Gardez un bloc-notes ouvert : commande tapée, résultat attendu, résultat obtenu. Cette trace courte accélère le dépannage et évite de croire qu’« on a déjà essayé » sans preuve.
Installer les pilotes / ROCm selon la doc officielle
Suivez la documentation AMD et celle du runtime pour votre version d’OS. Les commandes de dépôt apt ou zypper changent : copiez celles du guide actuel, pas d’un vieux gist. Après install, vérifiez les outils utilisateur ROCm (noms variables selon versions) avant d’accuser Ollama. Un reboot est souvent nécessaire. Vérifiez aussi l’environnement : VPN, proxy, antivirus, espace disque. Beaucoup d’échecs attribués au modèle viennent d’un réseau d’entreprise à Lille ou d’un disque plein après plusieurs pulls.
Smoke test avec un tout petit modèle
Installez Ollama ou compilez llama.cpp avec le backend choisi. Tirez un petit tag exact depuis la library. Si le petit modèle échoue, le gros échouera. Validez qu’une réponse française revient. Chronométrez subjectivement. Sur un club info de Maubeuge, ce smoke test est le critère « on continue ou on bascule Vulkan ». Quand l’étape réussit, marquez-la explicitement dans votre checklist. Les bascules trop rapides vers l’étape suivante masquent des configs demi-installées qui cassent plus tard en démo publique.
Monter en taille et noter les plafonds
Augmentez progressivement la taille / quantification. Observez les erreurs mémoire, les falls-back CPU silencieux (lenteur soudaine), les crashes pilote. Documentez le plus gros modèle confortable. Ce plafond local vaut mieux qu’un rêve de 27B pour une démo publique. Si vous travaillez à deux, faites reformuler le geste par la personne la moins technique. Ce qui n’est pas dit clairement maintenant reviendra en ticket flou après l’atelier. Complétez par un test de non-régression : refaites le même geste après avoir fermé puis rouvert l’outil, afin de confirmer que la configuration survit au redémarrage et reste compréhensible pour un collègue qui n’a pas suivi toute la session.
Figer la stack et la procédure de reprise
Écrivez OS, version pilote/ROCm, runtime, tag de modèle, date. En cas de mise à jour qui casse tout, vous saurez quoi restaurer. Gardez un utilisateur non admin pour Open WebUI si vous exposez une UI (Open WebUI). La reprise documentée est ce qui transforme un hack perso en service d’équipe. Testez une fois « à froid » après redémarrage de la machine. Un service qui ne survit pas au reboot n’est pas prêt pour une permanence à Valenciennes ou Amiens.
ROCm sous Linux : gestes concrets
Linux reste le terrain le plus prévisible pour ROCm. Choisissez une distribution explicitement citée par la doc AMD pour la version ROCm visée. Les « rolling » récentes peuvent marcher, mais le support entreprise et associatif préfère souvent une LTS. Réservez un utilisateur dans le bon groupe périphérique selon la doc (le nom du groupe a déjà varié).
Après installation, un échec fréquent est le runtime qui continue d’utiliser le CPU sans message clair. Surveillez les logs Ollama ou llama.cpp, et l’outil de monitoring GPU AMD. Si l’utilisation GPU reste à zéro pendant l’inférence, vous n’êtes pas accéléré — même si une réponse finit par arriver.
# Identifier le GPU (Linux) lspci | grep -i vga # Puis : suivre EXACTEMENT le guide ROCm officiel pour votre OS/version # Vérifier que les outils utilisateur ROCm répondent (noms selon version) # Ensuite seulement : ollama --version ollama pull TAG_PETIT_MODELE ollama run TAG_PETIT_MODELE
Plan B Vulkan avec llama.cpp
Quand ROCm est absent ou capricieux, compilez llama.cpp avec Vulkan (tutoriel llama.cpp). Le geste : backend Vulkan activé, GGUF adapté à la mémoire, `llama-server` en localhost. Vulkan débloque des machines « impossibles » en ROCm. La contrepartie : vous devrez peaufiner offload et vivre avec une maturité parfois inférieure.
Ne comparez pas mentalement à la RTX du collègue sur des souvenirs de tokens/s. Comparez à votre besoin : un chat utilisable pour rédiger des comptes rendus d’association à Abbeville vaut mieux qu’un podium imaginaire.
Et sous Windows ?
Windows + AMD + LLM a progressé, mais reste plus chaotique selon les versions d’Adrenalin et des runtimes. Certaines apps (LM Studio, builds Vulkan, préviews Ollama) peuvent fonctionner sur votre configuration précise — la seule preuve est l’essai. Pour un service semi-prod d’une TPE de Tourcoing, un Linux dédié ou un Mac peut réduire la charge mentale, même si le PC Windows reste le poste bureautique.
Si vous restez sous Windows faute de choix, isolez un utilisateur local « llm », documentez la version Adrenalin, et refusez les mises à jour automatiques le matin d’une démo. Testez après chaque update GPU avec le même petit tag. Cette discipline simple évite la moitié des paniques observées en clubs info entre Roubaix et Wattrelos. Gardez une clé USB avec le GGUF de secours et le runbook imprimé : quand le pilote casse, le réseau de la salle est rarement votre ami. Ajoutez sur la clé un second tag encore plus petit pour dépanner devant un public impatient à Tourcoing ou Wattrelos.
Conseils d’achat prudents
Si vous achetez pour l’IA locale : priorisez la quantité de mémoire GPU et la compatibilité logicielle documentée, pas seulement le marketing gaming. Vérifiez la dispo ROCm/Vulkan pour la génération ciblée. Prévoyez alimentation et boîtier qui ventilent. Un achat d’occasion en métropole lilloise peut être excellent — à condition de tester la carte avant de compter dessus pour un atelier.
Pour une collectivité, ajoutez la contrainte support : qui maintiendra les pilotes dans six mois ? Parfois, standardiser sur une stack déjà maîtrisée dans le coin (même si ce n’est pas le GPU théorique le plus rapide) est la décision rationnelle.
Dépannage AMD fréquent
Installation ROCm cassée après upgrade noyau : pinnez versions ou suivez la matrice de support. Ollama lent comme le CPU : backend non engagé. Crash noir d’écran : pilote ; reboot et baissez la charge. Mémoire insuffisante : quantification plus basse ou modèle plus petit. Discordances WSL : le GPU dans WSL est un sujet à part, documentez-le ou évitez-le pour un premier déploiement.
| Symptôme | Action |
|---|---|
| GPU à 0 % pendant le chat | Vérifier backend / ROCm / Vulkan réellement liés |
| Marche après reboot seulement | Versions noyau/pilote ; notes de mise à jour |
| OK petit modèle, KO gros | Mémoire GPU / quantification ([[ta03]]) |
| OK Linux, KO Windows | Normaliser sur Linux pour le service LLM |
Un cas sous-estimé : plusieurs utilisateurs graphiques sur la même machine Linux font planter une session quand le LLM sature la VRAM. Sur un PC de club à Maubeuge, dédiez une session ou un utilisateur « llm » et évitez Chrome avec vingt onglets WebGL pendant l’inférence. La coexistence bureau + LLM est un sujet d’exploitation, pas seulement de compile.
Animer un atelier « ma Radeon peut-elle ? »
Préparez trois machines si possible : une NVIDIA de référence (pour rassurer), une AMD ROCm OK, une AMD Vulkan only. Le récit pédagogique n’est pas « AMD = impossible », c’est « voici comment on vérifie ». Faites exécuter le smoke test par un participant. À Lille ou Amiens, cette mise en geste réduit les freins d’achat d’occasion et les idées reçues de forum.
Distribuez une checklist papier : nom GPU, OS, doc de support consultée, petit modèle OK/KO, gros modèle OK/KO, décision. Les participants repartent avec un artefact, pas seulement une impression. Reliez ensuite vers Open WebUI si le GPU est validé, pour transformer le test en outil d’équipe.
Passer du hack au petit service
Une fois le GPU AMD stable, traitez-le comme un service : sauvegarde des configs, compte rendu des versions, fenêtre de maintenance, personne de réserve. Une association de Boulogne qui dépend d’un seul bénévole « qui connaît ROCm » prend un risque. Documentez assez pour qu’un sysadmin généraliste puisse redémarrer la stack et relancer un modèle connu.
Surveillez les mises à jour Adrenalin / noyau / Ollama séparément : n’upgez pas tout le même jour. Cette hygiène, banale en IT, est encore plus critique quand la matrice de support GPU est étroite.
Exemple de runbook court à coller près de la machine : (1) vérifier que le service Ollama répond, (2) lancer le tag documenté, (3) ouvrir Open WebUI, (4) smoke test en français, (5) si échec, basculer Vulkan / petit modèle, (6) contacter le référent. À Dunkerque comme à Beauvais, ce runbook transforme une expertise individuelle en continuité de service. Reliez-le à Open WebUI et llama.cpp selon votre pile réelle. Relisez-le à voix haute une fois avec un collègue non spécialiste : s’il bloque, clarifiez la phrase avant la prochaine panne.
Questions fréquentes
Mon Radeon peut-il faire tourner une IA ?
Souvent oui pour découvrir et pour des modèles adaptés à sa mémoire, parfois oui pour des usages sérieux si le backend est supporté, parfois non pour le gros modèle à la mode. La réponse se joue sur le trio GPU + OS + runtime, pas sur le slogan de la boîte. Faites le smoke test petit modèle avant d’annoncer quoi que ce soit à votre équipe. Pour trancher chez vous, reproduisez le scénario sur la machine réelle avec un protocole court écrit à l’avance. Une conclusion d’atelier à Roubaix ne se transfère pas telle quelle sur un portable différent.
Ollama officiellement « AMD ready » chez moi ?
Cela dépend de la version Ollama et de votre matériel. Lisez les notes de version du jour et testez. Si Ollama ne voit pas l’accélération, basculez sur llama.cpp Vulkan pour confirmer que le GPU peut servir. L’outil n’est pas en cause à 100 % : la matrice de support l’est. Gardez une fiche datée : question, hypothèse, test, résultat. Cette hygiène évite les débats sans fin et construit une mémoire utile pour la prochaine personne référente. Ajoutez une vérification métier : demandez à une personne du terrain de reformuler le besoin en une phrase, puis vérifiez que votre réglage répond vraiment à cette phrase, pas seulement au scénario technique imaginé au départ.
Faut-il vendre mon GPU AMD pour une NVIDIA ?
Pas automatiquement. Si votre Radeon couvre vos besoins documentés, gardez-la. Si vous passez vos week-ends à battre les pilotes pour un usage critique, un changement de stack matériel peut coûter moins cher en temps. Décidez sur des faits locaux, pas sur la pression sociale des forums. Si deux camps s’opposent dans l’équipe, imposez un A/B sur la même batterie de prompts plutôt qu’un vote d’opinion. Le terrain tranche plus vite que les digressions de salon.
ROCm sur un portable AMD ?
Possible sur certaines configurations Linux, mais thermiques et versions de GPU mobiles compliquent l’affaire. Attendez-vous à du throttling. Pour une démo mobile à Boulogne, un petit modèle stable bat un gros modèle qui coupe après cinq minutes. Méfiez-vous des captures hors contexte trouvées en ligne. Sans connaître quantification, contexte et charge machine, un chiffre spectaculaire ne dit rien de votre poste à Beauvais. Documentez le contournement éventuel (petit modèle, localhost, hors VPN) pour ne pas rester bloqué en démonstration publique : un plan B écrit vaut mieux qu’une improvisation sous le regard d’un public à Lille ou Amiens.
Où enchaîner après un GPU validé ?
Branchez une UI (Open WebUI), puis éventuellement un RAG (Qwen + RAG). Le GPU n’est qu’une brique. La valeur pour une structure HdF arrive quand l’outil est documenté, sauvegardé et compris par plus d’une personne. Quand le problème semble intermittent, journalisez l’heure, la température perçue et les autres apps ouvertes. Les coïncidences thermiques et mémoire sont fréquentes sur machines partagées. Mesurez aussi le confort subjectif (bruit, chaleur, temps d’attente ressenti) : un réglage « correct » sur le papier mais pénible au quotidien ne sera pas adopté par une équipe de collectivité ou d’association.