ROCm vs Vulkan pour l’hébergement local de LLM sur AMD : Guide 2026

Choisir le bon backend AMD pour chaque moteur

Sommaire

ROCm et Vulkan accélèrent tous deux les GPU AMD pour l’hébergement local de LLM, mais ils ne sont pas interchangeables. Le bon choix dépend du moteur, du GPU et de la charge de travail.

Dans l’hébergement local de LLM, les deux backends se situent à des couches différentes. ROCm est la plateforme de calcul d’AMD sous PyTorch, vLLM et SGLang, tandis que Vulkan est une API GPU portable que les moteurs de type llama.cpp utilisent pour exécuter des modèles quantifiés sur une large gamme de matériel.

Backends ROCm et Vulkan pour l’hébergement local de LLM sur AMD

Ce guide compare les deux moteurs un par un — llama.cpp, Ollama, LM Studio, vLLM, SGLang, TGI et LocalAI — avec des commandes de compilation, des vérifications de périphériques et des modes de défaillance qui se font passer pour des problèmes de performance. Si vous êtes novice dans le paysage de l’hébergement, commencez par l’Aperçu de l’hébergement de LLM, qui cartographie les familles d’outils approfondies dans cet article.

ROCm vs Vulkan : la réponse courte

Situation Point de départ recommandé Pourquoi
llama.cpp avec GGUF sur Linux Vulkan Surface d’installation réduite, couverture GPU étendue et rollback facile
llama.cpp sur un GPU RDNA 3 ou RDNA 4 pris en charge Évaluer les deux par benchmarks Les performances des noyaux changent avec la forme du modèle, la quantification, le contexte et la compilation
Ollama sur un GPU AMD listé ROCm d’abord, vérifier Vulkan aussi Ollama prend en charge les deux, mais le choix du backend est moins explicite que dans llama.cpp brut
LM Studio sur un GPU AMD de bureau Vulkan d’abord La bascule d’exécution facilite la comparaison et évite une pile de calcul système entière
vLLM ou SGLang ROCm, mais vérifier la couverture des noyaux par famille de GPU Ce sont des piles PyTorch/HIP ; Vulkan n’est pas un backend alternatif, et les architectures très récentes peuvent encore manquer de noyaux optimisés
TGI sur du matériel Instinct pris en charge ROCm La voie conteneur AMD publiée cible les familles MI210, MI250 et MI300
GPU Radeon ancien ou non listé Vulkan Les pilotes Vulkan couvrent généralement plus de matériel graphique que les bibliothèques ROCm
Serveur AMD Instinct ROCm Le calcul multi-GPU, RCCL, les noyaux de frameworks et les outils opérationnels vivent ici
Service local de GGUF sur Windows Vulkan C’est généralement la voie la moins restrictive pour les runtimes de type llama.cpp
APU Ryzen AI Max ou autre APU à grande mémoire Vulkan d’abord, puis ROCm si nécessaire Les deux peuvent fonctionner, mais la mémoire partagée et la prise en charge des noyaux nécessitent des tests spécifiques à la charge de travail

Ce tableau est une politique de départ, pas un résultat de benchmark. Un backend qui détecte le GPU mais laisse certaines opérations sur le CPU peut paraître sain tout en ayant de mauvaises performances, donc toute décision finale nécessite l’inspection des journaux et un test de bout en bout d’un prompt.

Ce que sont réellement ROCm et Vulkan

ROCm est une plateforme de calcul

ROCm inclut le runtime HIP, le compilateur, les bibliothèques mathématiques, la communication collective, les profilers et les paquets de frameworks nécessaires pour exécuter des charges de travail de calcul AMD. C’est le fondement du côté AMD sous les builds de PyTorch et des moteurs tels que vLLM et SGLang, et il peut également accélérer llama.cpp via son backend HIP.

Cette étendue est à la fois l’avantage et le coût de ROCm. Le pilote hôte, la cible GPU, les bibliothèques en espace utilisateur, la roue du framework, la version du noyau et l’image conteneur doivent former un ensemble compatible ; lorsque c’est le cas, ROCm offre bien plus que la génération de tokens via un exécutable local unique.

ROCm 10.0.0, sorti le 26 août 2026, est construit sur TheRock (le système de compilation et de publication d’AMD depuis ROCm 7.14), valide PyTorch 2.13, vLLM 0.27 et SGLang 0.5.15, et ajoute officiellement la prise en charge de RDNA 4 pour gfx1200 (RX 9060/9060 XT/9050) et gfx1201 (RX 9070/9070 XT/9070 GRE, série Radeon AI PRO R9700). La matrice de compatibilité ROCm reste l’autorité pour une combinaison exacte de GPU et système d’exploitation, pas un message de forum qui utilise par hasard la même famille marketing.

Vulkan est une interface GPU portable

Vulkan est une API graphique et de calcul implémentée par un pilote GPU. Dans l’hébergement local de LLM, cela signifie normalement qu’un moteur d’inférence expédie ou compile des shaders de calcul qui s’exécutent via une implémentation Vulkan telle que Mesa RADV sur Linux ou le pilote du fournisseur sur Windows.

Vulkan ne fournit pas une plateforme PyTorch de substitution comparable à ROCm. Sa force pratique est plus étroite mais utile : un moteur de type llama.cpp peut utiliser la même conception de backend sur du matériel AMD, Intel, Nvidia et autres compatibles Vulkan sans installer une pile d’apprentissage automatique spécifique au fournisseur.

Cette distinction explique la plupart de la décision. Si l’application n’offre qu’une voie HIP ou PyTorch, Vulkan ne peut pas la sauver ; si l’application est déjà basée sur llama.cpp et GGUF, installer toute la pile ROCm peut résoudre un problème que vous n’aviez pas.

Matrice de prise en charge des moteurs en 2026

Moteur ROCm ou HIP Vulkan Format de modèle typique Note pratique
llama.cpp / llama-server Oui Oui GGUF Meilleure plateforme pour un test A/B contrôlé des backends
Ollama Oui Oui Modèles dérivés de GGUF gérés Pratique, mais la sélection du backend et l’emballage sont abstraits
LM Studio Oui Oui GGUF et formats gérés par le produit Les runtimes sélectionnables rendent les tests de bureau abordables
vLLM Oui Non Safetensors et quantifications prises en charge Utiliser l’image ROCm assortie d’AMD ou le jeu de roues ; vérifier d’abord la couverture des noyaux par famille de GPU
SGLang Oui Non Safetensors et quantifications prises en charge ROCm fait partie de l’architecture de déploiement
TGI Oui Non Safetensors et quantifications prises en charge La validation AMD publiée reste centrée sur Instinct
LocalAI Oui Oui Dépendant du backend, souvent GGUF Utilise des images conteneur ROCm et Vulkan différentes

ROCm n’implique pas Safetensors, et Vulkan n’implique pas formellement GGUF. L’association utile vient des moteurs : llama.cpp peut lire le même GGUF avec soit sa build HIP, soit sa build Vulkan, tandis que les serveurs natifs PyTorch utilisent ROCm et consomment généralement des dépôts de modèles Hugging Face.

Cela fait de l’inventaire des modèles une contrainte architecturale. Une bibliothèque de quantifications GGUF soigneusement sélectionnées oriente naturellement vers llama-server, Ollama, LM Studio ou LocalAI ; un déploiement construit autour du parallélisme de tenseurs, du batch continu et des poids natifs au framework oriente vers ROCm avec vLLM ou SGLang. Pour le paysage plus large des moteurs au-delà des backends AMD — maturité de l’API, appel d’outils et aptitude à la production sur une douzaine d’outils — consultez notre comparaison d’Ollama, vLLM, LM Studio, LocalAI et d’autres outils d’hébergement local de LLM.

llama.cpp : la comparaison ROCm vs Vulkan la plus claire

llama.cpp expose les deux backends sans changer le fichier de modèle ou le client HTTP. C’est l’endroit le plus équitable pour comparer ROCm et Vulkan car le tokenizer, les paramètres d’échantillonnage, le gabarit de discussion, la quantification et le comportement du serveur peuvent rester fixes.

La documentation de compilation actuelle de llama.cpp utilise GGML_HIP pour ROCm et GGML_VULKAN pour Vulkan. Les anciens articles qui recommandent GGML_ROCM ou les drapeaux Makefile supprimés ne doivent pas être crus sans vérifier les options CMake actuelles du projet.

Compiler le backend Vulkan sur Ubuntu

Installez les en-têtes Vulkan, le compilateur de shaders et les en-têtes SPIR-V, puis vérifiez que le pilote peut énumérer le GPU cible :

sudo apt-get update
sudo apt-get install -y libvulkan-dev glslc spirv-headers vulkan-tools

vulkaninfo --summary

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -S . -B build-vulkan \
  -DGGML_VULKAN=ON \
  -DCMAKE_BUILD_TYPE=Release
cmake --build build-vulkan --config Release -j

Sur un système mixte avec un iGPU et un GPU discret, l’ordre d’énumération mérite attention. GGML_VK_VISIBLE_DEVICES peut restreindre llama.cpp à un périphérique Vulkan spécifique, et le journal de démarrage doit nommer la carte sélectionnée plutôt que de simplement signaler qu’un périphérique Vulkan existe.

Compiler le backend ROCm ou HIP

Confirmez d’abord que ROCm identifie le GPU et rapporte la cible gfx attendue. La cible peut être omise pour compiler pour les GPU du système actuel, mais la fixer réduit le travail de compilation lorsque vous connaissez le matériel de déploiement.

rocminfo | grep -E 'Name:.*gfx' | head
hipconfig --full

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

HIPCXX="$(hipconfig -l)/clang" \
HIP_PATH="$(hipconfig -R)" \
cmake -S . -B build-rocm \
  -DGGML_HIP=ON \
  -DGPU_TARGETS=gfx1201 \
  -DCMAKE_BUILD_TYPE=Release
cmake --build build-rocm --config Release -j

Remplacez gfx1201 par la cible rapportée pour la carte réelle — cette valeur correspond à la famille RX 9070/9070 XT/9070 GRE et Radeon AI PRO R9700 en RDNA 4, tandis que gfx1200 couvre la série RX 9060 et gfx1100/gfx1101/gfx1102 couvrent les lignes RX 7900/7800/7700/7600 de RDNA 3. Ne copiez pas HSA_OVERRIDE_GFX_VERSION dans un service de production simplement parce que cela a aidé quelqu’un à démarrer un GPU non pris en charge ; une surcharge peut faire charger le code, mais cela ne transforme pas ce matériel en plateforme validée.

Benchmarker la même charge de travail, pas deux valeurs par défaut

Utilisez un seul fichier GGUF, le même réglage de flash-attention, le même déchargement de couches et des exécutions répétées. Le traitement du prompt (pp) et la génération de tokens (tg) sollicitent le système différemment, tandis qu’un serveur à long contexte ajoute également l’allocation de la cache KV et la pression mémoire qu’un benchmark synthétique court manquera.

MODEL=/srv/models/model.gguf

./build-vulkan/bin/llama-bench \
  -m "$MODEL" -ngl 999 -fa 1 -p 512 -n 128 -r 5

./build-rocm/bin/llama-bench \
  -m "$MODEL" -ngl 999 -fa 1 -p 512 -n 128 -r 5

Les résultats de la communauté illustrent pourquoi un gagnant universel est trompeur, et la cible gfx1201 de RDNA 4 en est l’exemple récent le plus clair. Dans une soumission sur une même machine RX 9070 XT, Vulkan a atteint environ 143 tokens/s contre 128 tokens/s de ROCm sur le test de génération 7B Q4_0, mais des soumissions ultérieures ont montré des écarts plus faibles à mesure que les builds changeaient ; les discussions Vulkan et ROCm contiennent également de grandes différences dans les résultats de traitement du prompt et les conditions de test. Une exécution séparée et plus détaillée d’OpenBenchmarking.org sur une RX 9070 XT avec llama.cpp b6401 a trouvé Vulkan en avance sur le décodage pour plusieurs modèles de classe 8B (Qwen3-8B-Q8_0, Llama-3.1-Tulu-3-8B-Q8_0) mais en retard sur le traitement du prompt pour des longueurs de prompt plus longues — les deux backends se relaient selon la phase mesurée.

L’écart peut aussi aller dans l’autre sens, et de beaucoup, pour des formes de modèles spécifiques. Une question ouverte de llama.cpp documente Vulkan sur gfx1201 devenant 4,7 à 6,7 fois plus lent que HIP sur la génération de tokens dès que la taille cachée d’un modèle atteint 4096 ou plus (la bande passante effective de décodage s’effondrant à environ 70–100 GB/s sur une carte de 640 GB/s), tandis qu’un plus petit modèle 4B avec une taille cachée de 2560 ne montre aucune régression sur l’un ou l’autre backend. Considérez chaque chiffre ici comme une instantanée d’un build, d’un pilote et d’une forme de modèle — pas comme une règle qui se généralise à travers le type de quantification, l’architecture du modèle, le flash attention, les tailles de batch, la version du pilote, l’état thermique ou le commit de llama.cpp.

Ollama sur AMD : pratique, mais vérifiez le backend

Ollama prend officiellement en charge les GPU AMD listés via ROCm et documente maintenant une couverture supplémentaire AMD via Vulkan sur Windows et Linux. Sa page de prise en charge du matériel actuelle indique que Vulkan est activé par défaut lorsque le backend est installé, prend en charge GGML_VK_VISIBLE_DEVICES pour la sélection du périphérique et peut désactiver Vulkan avec OLLAMA_VULKAN=0.

C’est une amélioration significative par rapport à la période où les conseils sur Vulkan dépendaient de builds expérimentaux. Cela rend également certains tutoriels plus anciens obsolètes : définir un interrupteur non documenté et supposer que le service a sélectionné Vulkan est une preuve plus faible que de lire le journal du serveur.

sudo systemctl edit ollama

Pour le diagnostic, ajoutez un greffon plutôt que d’exporter des variables uniquement dans un shell interactif :

[Service]
Environment="OLLAMA_DEBUG=1"
Environment="GGML_VK_VISIBLE_DEVICES=0"

Puis rechargez, redémarrez et inspectez à la fois le placement des processus et les messages de découverte :

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -u ollama -b --no-pager | tail -n 200

ollama run qwen3:8b "Return exactly: backend test passed"
ollama ps

Cherchez le GPU nommé, la bibliothèque sélectionnée, l’allocation du modèle et le pourcentage GPU. Un journal qui montre un temps d’attente dépassé lors de la découverte suivi d’une réponse HTTP réussie peut signifier qu’Ollama est retombé silencieusement sur le CPU. Pour le jeu de commandes quotidien autour de ce service, l’Aide-mémoire CLI Ollama est la référence plus rapide.

Ollama est excellent lorsque l’acquisition de modèles et une API locale stable comptent plus que le contrôle du backend. Si le test répété ROCm-contre-Vulkan est l’objectif, llama-server brut est un meilleur instrument car le répertoire de build rend le backend explicite.

vLLM et SGLang font de ROCm la décision — mais vérifiez d’abord la couverture des noyaux par famille de GPU

vLLM et SGLang ne sont pas des applications Vulkan. Leurs voies AMD reposent sur ROCm, PyTorch et des noyaux HIP optimisés, donc choisir l’un de ces moteurs a déjà sélectionné la plateforme de calcul.

Le guide vLLM sur ROCm actuel d’AMD recommande un conteneur précompilé et publie des images assorties pour ROCm, PyTorch, Python et vLLM. Cette couplage est utile : il remplace un grand exercice de résolution de dépendances par une unité de déploiement versionnée.

Au moment de la rédaction, AMD documente cette image ROCm 10 pour vLLM 0.27 :

docker pull \
  rocm/vllm:rocm10.0.0_ubuntu24.04_py3.14_pytorch_2.12.0_vllm_0.27.0

docker run --rm -it \
  --device /dev/kfd \
  --device /dev/dri \
  --group-add video \
  --ipc=host \
  --network=host \
  --cap-add=SYS_PTRACE \
  --security-opt seccomp=unconfined \
  -v /srv/models:/app/models \
  -e HF_HOME=/app/models \
  rocm/vllm:rocm10.0.0_ubuntu24.04_py3.14_pytorch_2.12.0_vllm_0.27.0 \
  bash

Utilisez l’image sélectionnée pour la famille de GPU exacte dans la documentation d’AMD ; les images RDNA et CDNA n’ont pas toujours été interchangeables. Pour un serveur de production, fixez le tag ou le digest complet et validez le pilote hôte avant de blâmer vLLM pour une erreur d’initialisation.

Les générations de GPU tout juste sorties sont le cas limite le plus tranchant, et RDNA 4 est un exemple réel et documenté plutôt qu’un risque théorique. Des tests indépendants sur une RX 9070 XT (gfx1201) début 2026 ont trouvé vLLM sur ROCm 7.2 retombant silencieusement sur la déquantification FP32 pour les poids de modèle FP8 — parce que gfx1201 n’était pas encore reconnu dans la détection de plateforme de vLLM — ce qui contournait entièrement les accélérateurs matriciels du GPU et ne produisait que 48 tokens/s, contre 62 tokens/s de llama-server sur Vulkan exécutant une quantification GGUF d’un modèle comparable sur la même carte. La leçon se généralise : une pile ROCm/PyTorch peut charger avec succès sur une nouvelle architecture et tout de même exécuter une voie de repli non optimisée sans message d’erreur. Confirmez toujours quelle voie de noyau a réellement exécuté (via rocprof, les notes de profilage du fournisseur, ou un débit de référence connu pour le GPU) avant de faire confiance à un seul résultat « ça a bien démarré » sur un matériel sorti au cours des deux derniers cycles de publication.

La raison d’accepter la plus grande surface opérationnelle de ROCm, une fois la couverture des noyaux confirmée, est l’architecture de débit — pas seulement quelques tokens/s de plus dans un test utilisateur unique. Le batch continu, la quantification native au framework, le parallélisme de tenseurs, le comportement de l’ordonnanceur et les outils PyTorch environnants sont le véritable cas pour passer à vLLM, et si vous hésitez à savoir si ce passage est justifié, notre guide de migration d’Ollama à vLLM liste les signaux de charge de travail.

TGI : prise en charge ROCm avec une cible plus étroite

Hugging Face documente une image AMD pour Text Generation Inference, mais sa validation publiée est centrée sur le matériel Instinct MI210, MI250 et MI300. Le guide TGI AMD utilise l’image 3.3.5-rocm et liste les fonctionnalités ROCm non prises en charge, donc il ne devrait pas être généralisé en une promesse pour chaque carte Radeon. Notre guide d’installation TGI couvre cette configuration d’image ROCm en détail.

Il n’y a pas de voie Vulkan TGI à comparer. Si TGI est une exigence fixe, choisissez un matériel ROCm pris en charge et reproduisez le conteneur documenté ; si le moteur est négociable, la prise en charge actuelle de vLLM et SGLang mérite une évaluation avant de commencer un nouveau déploiement AMD.

LM Studio : basculer les runtimes plutôt que de recompiler

LM Studio empaquette plusieurs runtimes d’inférence et expose la gestion des runtimes via la commande lms. Sa documentation runtime prend en charge la liste, le téléchargement, la sélection, la mise à jour et la suppression des runtimes, ce qui rend les expériences ROCm-contre-Vulkan accessibles sans maintenir des arbres de sources séparés.

lms runtime ls
lms runtime get
lms runtime select

Exécutez le même GGUF avec la même longueur de contexte, le même déchargement GPU, le même réglage de flash-attention et le même prompt. Comparez le temps de premier token, le taux de génération, le temps de chargement et la mémoire de pointe plutôt que de juger un backend sur une seule courte réponse de discussion.

L’empaquetage des runtimes n’élimine pas les défauts spécifiques au backend. Par exemple, une question LM Studio sur R9700 de 2026 a signalé qu’un grand modèle se bloquait près de la fin d’un chargement ROCm tandis que le runtime Vulkan le chargeait, tandis qu’une autre question sur la marge mémoire Vulkan décrivait le résultat opposé près de la VRAM maximale. Ce sont des rapports individuels, mais ensemble ils font le bon point opérationnel : gardez un runtime de repli et laissez une marge mémoire.

LocalAI : choisir l’image ainsi que le backend

LocalAI fournit des variantes de conteneur ROCm ou hipblas et Vulkan séparées. Son guide d’accélération GPU documente les images gpu-hipblas pour le calcul AMD et les images gpu-vulkan pour la voie portable, donc un tag de conteneur copié d’un guide CUDA ne découvrira pas le bon backend par magie. Le démarrage rapide LocalAI couvre la configuration générale ; le choix du conteneur spécifique au backend est ce que cette section ajoute.

Le conteneur ROCm a besoin de /dev/kfd et /dev/dri, tandis que Vulkan a normalement besoin du périphérique de rendu approprié sous /dev/dri. Fixez un tag de version pour un service réel ; latest et master sont utiles pour le diagnostic, mais ils rendent le rollback et la comparaison des performances inutilement flous.

# Image ROCm ou HIP
docker run --rm -it \
  --device /dev/kfd \
  --device /dev/dri \
  -p 8080:8080 \
  quay.io/go-skynet/local-ai:v4.8.0-gpu-hipblas

# Image Vulkan
docker run --rm -it \
  --device /dev/dri \
  -p 8080:8080 \
  localai/localai:v4.8.0-gpu-vulkan

Les exemples de tags reflètent la documentation disponible au moment de la publication ; confirmez les noms du registre actuels avant d’automatiser un pull. Plus important, n’inférez pas l’accélération du seul nom du conteneur — inspectez le journal de débogage de LocalAI et surveillez l’utilisation du GPU pendant une requête.

Ce qui a changé dans l’empaquetage de ROCm 10

ROCm 10 n’est pas juste une autre mise à jour mineure de paquets. Le guide de transition TheRock d’AMD indique que les paquets du SDK Core ROCm utilisent maintenant le préfixe amdrocm-, la racine d’installation versionnée est /opt/rocm/core-10.0, et plusieurs paquets legacy ont été consolidés.

C’est pourquoi une commande d’un ancien article ROCm peut retourner « paquet introuvable » même sur un repository correctement configuré. Par exemple, HIPCC vient maintenant de amdrocm-llvm, les composants BLAS sont combinés dans amdrocm-blas, et une installation système complète peut utiliser un métapaquet Core SDK toutes architectures ou spécifique à une famille de GPU — les cartes RDNA 4 utilisent le tag de famille gfx120X-all (suffixe de paquet -gfx1200-gfx1201), ce qui est bon à savoir avant d’aller chercher un nom de paquet gfx1201-seul qui n’existe pas.

Le métapaquet amdrocm configure les alternatives et les liens symboliques de compatibilité sous /opt/rocm. Une installation minimale ou personnalisée peut ne pas fournir les mêmes chemins, donc les scripts de compilation qui codent en dur /opt/rocm/bin/hipcc devraient utiliser hipconfig ou définir ROCM_PATH explicitement.

Deux changements de diagnostic sont faciles à manquer. ROCm SMI a été supprimé au profit d’AMD SMI, et le test de bande passante ROCm a atteint sa fin de vie ; les scripts qui appellent rocm-smi ou rocm-bandwidth-test doivent passer à amd-smi et aux outils de remplacement d’AMD plutôt que de réinstaller des paquets legacy arbitraires.

Les conteneurs dépendent toujours de l’hôte

Un conteneur ROCm porte les bibliothèques en espace utilisateur, pas un pilote de noyau de remplacement. L’hôte doit exposer /dev/kfd et /dev/dri, son pilote doit être compatible avec la pile du conteneur, et l’utilisateur du service a besoin de l’autorisation d’ouvrir ces périphériques.

Les conteneurs Vulkan ont une limite similaire autour du pilote Vulkan hôte et du nœud de rendu. L’empaquetage est plus léger, mais une ICD incorrecte, l’absence d’appartenance à un groupe de rendu, ou un iGPU sélectionné par accident peuvent toujours transformer une image de conteneur fonctionnelle en un service lié au CPU ou instable.

GPU discrets, APUs et cartes Radeon plus anciennes

GPU discrets RDNA 3 et RDNA 4

Les modèles actuels Radeon RX 7000, RX 9000 et Radeon AI Pro ont le cas le plus fort pour tester les deux backends de llama.cpp. La prise en charge ROCm est maintenant explicite pour de nombreuses cibles gfx110x et gfx120x, tandis que Vulkan via un Mesa RADV actuel ou un pilote fournisseur Windows est assez mûr pour être une voie principale plutôt qu’un repli désespéré. Pour le côté matériel de cette décision — VRAM, bande passante, puissance et prix entre les fabricants — consultez notre comparaison de GPU pour les charges de travail IA en 2026.

Ne convertissez pas un benchmark 7B en règle pour un modèle dense 27B ou un modèle mixture-of-experts. Les formes matricielles, les paramètres actifs, les noyaux quantifiés, la longueur du prompt et la pression mémoire peuvent changer l’ordre, et les performances du backend ont considérablement évolué entre les révisions de llama.cpp — la régression de taille cachée gfx1201 mentionnée ci-dessus est un cas concret de ce type de changement.

APUs Ryzen et mémoire partagée

Les systèmes Ryzen AI Max à grande mémoire sont exceptionnellement intéressants car le GPU peut accéder à un pool de mémoire partagée beaucoup plus large qu’une carte consommateur discrete normale n’offre. ROCm 10 liste les familles Ryzen AI actuelles, tandis que les runtimes llama.cpp capables de Vulkan peuvent également utiliser l’iGPU sans construire un environnement PyTorch.

La capacité n’est pas la bande passante. Un modèle qui tient dans 64 GB ou 96 GB de mémoire partagée allouée ne signifie pas qu’il décodera comme une carte discrete de 32 GB, et une allocation agressive du contexte peut asphyxier le système d’exploitation même lorsqu’une application rapporte une mémoire GPU abondante. La même discipline de budget VRAM qui s’applique aux cartes NVIDIA et AMD discrètes s’applique ici aussi — voir Cache KV sur GPU 16 GB pour le calcul de budget sous-jacent, qui est indépendant du backend.

Les machines mixtes iGPU et dGPU ont besoin d’une sélection de périphérique explicite. Un rapport récent de llama.cpp a décrit une réservation excessive de mémoire système lorsque un iGPU inutilisé restait visible à côté d’une R9700 ; c’est une question non confirmée, mais c’est une bonne raison d’exposer uniquement le périphérique que le service est censé utiliser.

Matériel Radeon ancien et non pris en charge

Vulkan est généralement la première voie pour un Radeon plus ancien car la couverture des pilotes graphiques est plus large que l’ensemble des cibles de calcul prises en charge par ROCm. Les projets basés sur ROCm notent également que les nouvelles versions de rocBLAS ont supprimé les noyaux pour certaines cibles plus anciennes, donc forcer une valeur gfx proche ne peut pas restaurer du code qui n’est plus expédié.

Une surcharge est acceptable pour une expérience de laboratoire avec des attentes de défaillance claires. C’est une mauvaise base pour une API non supervisée, car la prochaine mise à jour ROCm ou application peut remplacer un désaccord toléré par une erreur de démarrage ou un résultat incorrect.

Linux vs Windows pour les backends LLM AMD

Linux est l’hôte ROCm naturel pour l’inférence de production. Il offre la prise en charge la plus large des moteurs, un mapping de périphériques conteneur établi, des pilotes Vulkan Mesa actuels et les outils opérationnels attendus par les déploiements vLLM et SGLang.

Windows a une prise en charge ROCm réelle pour le matériel listé, mais l’écosystème applicatif reste plus étroit. Pour l’inférence GGUF de bureau via llama.cpp, Ollama ou LM Studio, Vulkan est généralement le point de départ plus calme ; utilisez ROCm lorsque l’application fournit une voie Windows prise en charge et qu’une fonctionnalité concrète ou un benchmark le justifie.

WSL2 devrait être traité comme une troisième plateforme, pas comme un synonyme de Linux natif. Assurez-vous que le pilote Windows documenté par AMD, la distribution WSL, la version ROCm et le paquet framework forment une combinaison prise en charge.

Liste de vérification avant de servir du trafic

Commencez en dessous de l’application. Si le pilote ne peut pas énumérer le périphérique correct, changer les drapeaux du modèle ne fait que réarranger le symptôme.

lspci -nnk | grep -A3 -E 'VGA|Display'
ls -l /dev/kfd /dev/dri/renderD* 2>/dev/null
id

# Voie ROCm
rocminfo | grep -E 'Marketing Name:|Name:.*gfx' | head -n 20
amd-smi list

# Voie Vulkan
vulkaninfo --summary

Puis vérifiez le moteur. La sortie de démarrage doit nommer ROCm ou Vulkan, nommer le GPU cible et rapporter que les couches du modèle ou les tenseurs ont été placés dessus ; enfin, la mémoire GPU et l’utilisation doivent augmenter pendant qu’une requête s’exécute.

# Observer un GPU AMD pendant qu'un autre terminal envoie des requêtes
watch -n1 amd-smi monitor

# Vérification de l'API compatible OpenAI de base pour llama-server
curl -s http://127.0.0.1:8080/v1/models
curl -s http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "local-model",
    "messages": [{"role": "user", "content": "Return exactly: ready"}],
    "max_tokens": 8,
    "temperature": 0
  }'

Enregistrez le pilote, le runtime, le commit ou le digest de l’image du moteur, le checksum du fichier de modèle, le contexte, les réglages de batch et la ligne de commande avec chaque benchmark. Sans ces métadonnées, un chiffre de tokens par seconde est une anecdote qui ne peut pas survivre à la prochaine mise à niveau — et comme le repli vLLM-sur-gfx1201 et la régression de taille cachée Vulkan ci-dessus le montrent tous deux, un chiffre qui a l’air plausible peut cacher une voie de code non optimisée silencieusement.

Modes de défaillance qui ressemblent à des performances de backend

Repli CPU silencieux

Le serveur démarre et répond correctement, mais la génération est inattendement lente et l’utilisation du GPU reste plate. Vérifiez les journaux de découverte, les permissions du périphérique, le déchargement du modèle et les périphériques du conteneur avant d’ajuster les threads ou les paramètres d’échantillonnage.

Repli de précision silencieux (nouveau matériel, nouveaux noyaux)

Le serveur démarre, l’utilisation du GPU semble raisonnable, et il n’y a pas d’erreur — mais le framework est silencieusement retombé sur une voie numérique non optimisée parce que la capacité de calcul ou la chaîne d’architecture du GPU n’était pas encore reconnue. C’est exactement ce qui s’est passé avec les noyaux FP8 de vLLM sur gfx1201 ; la correction est de vérifier le code de détection de plateforme propre au framework ou son traceur de problèmes pour votre chaîne de GPU exacte avant de faire confiance à un seul chiffre de débit sur une génération de GPU sortie au cours des deux derniers cycles de publication.

Le mauvais GPU est sélectionné

Un bureau Ryzen peut exposer un iGPU comme périphérique Vulkan 0 et un Radeon discrete comme périphérique 1. Restreignez les périphériques visibles et confirmez le nom complet du périphérique dans le journal ; ne supposez pas que la numérotation est stable après un changement de pilote ou de BIOS.

Désaccord de cible ROCm

rocminfo rapporte une cible gfx tandis que l’image de l’application contient des noyaux pour un autre ensemble. Utilisez une image correspondante ou recompilez pour la cible exacte ; réservez HSA_OVERRIDE_GFX_VERSION pour des expériences explicitement non prises en charge.

Désaccord pilote et espace utilisateur

Le conteneur a des bibliothèques ROCm actuelles mais le pilote hôte appartient à un flux de versions plus ancien. Les temps d’attente dépassés lors de la découverte, les erreurs de lancement de noyau, ou un repli sur le CPU sont plus probables qu’un message propre expliquant la limite de version.

Confusion d’ICD Vulkan

Plusieurs implémentations Vulkan sont installées, et le chargeur sélectionne une ICD inattendue. Inspectez vulkaninfo, supprimez les doublons accidentels, ou sélectionnez explicitement l’ICD et le périphérique intentionnels plutôt que d’empiler un autre SDK sur le problème.

Les estimations VRAM ne laissent pas de marge d’exploitation

Le modèle semble tenir mais échoue pendant le réchauffement, la configuration du flash-attention, ou le premier long prompt. Laissez plusieurs gigaoctets de marge sur un grand modèle, puis réduisez le contexte ou la taille du batch avant de conclure que le backend ne peut pas exécuter la quantification.

Une procédure pratique de sélection du backend

Étape 1 : choisir le comportement de service

Si l’objectif est un ou deux utilisateurs locaux, des fichiers GGUF et un point de terminaison OpenAI compatible simple, commencez avec llama-server, Ollama ou LM Studio. Si l’objectif est le batch continu, une forte concurrence, des modèles natifs au framework ou le parallélisme de tenseurs, commencez avec vLLM ou SGLang et acceptez ROCm comme partie de la conception.

Étape 2 : vérifier la prise en charge officielle du matériel

Assurez-vous que la cible GPU exacte, la version du système d’exploitation, le noyau et le pilote correspondent dans la matrice ROCm actuelle. Pour Vulkan, confirmez le GPU intentionnel via vulkaninfo et utilisez un pilote actuel plutôt que de supposer que la présence de libvulkan.so prouve une prise en charge utile du calcul. Si le GPU est de la génération d’architecture la plus récente, vérifiez également le code de détection de plateforme spécifique du framework ou les questions ouvertes pour cette cible gfx exacte — la prise en charge officielle et la prise en charge des noyaux optimisés ne sont pas toujours publiées ensemble.

Étape 3 : établir la base de fonctionnement la plus simple

Pour GGUF, Vulkan est normalement cette base car il modifie moins de composants système. Pour un moteur PyTorch, utilisez le conteneur ROCm fixé par AMD plutôt que d’assembler torch, Triton, AITER et vLLM à partir de versions « latest » non liées.

Étape 4 : benchmarker des prompts de forme de production

Mesurez le traitement du prompt, le temps de premier token, le taux de décodage, la mémoire de pointe et le comportement des requêtes concurrentes. Incluez le contexte et le motif d’appel d’outils que le service réel utilisera ; un micro-benchmark de 128 tokens ne prédit pas une session d’agent de 100 000 tokens.

Étape 5 : garder le repli déployable

Deux répertoires de build de llama.cpp coûtent peu par rapport à une journée perdue à cause d’une régression de pilote. Gardez le dernier digest de conteneur connu bon ou le runtime installé, et ne passez en avant que lorsque le candidat passe le même ensemble de tests.

La même procédure comme flux de décision :

flowchart LR A["Choisir le moteur de service"] --> B{"Moteur PyTorch/HIP ?"} B -- Oui --> C["ROCm : conteneur fixé
+ vérification de la couverture des noyaux"] B -- Non --> D{"GGUF sur GPU AMD ?"} D -- Oui --> E["Base Vulkan"] E --> F{"Benchmark : ROCm gagne
par une marge mesurable ?"} F -- Oui --> G["Passer à ROCm"] F -- Non --> H["Garder Vulkan,
garder le build ROCm comme repli"]

Verdict final : ROCm ou Vulkan pour l’hébergement de LLM AMD ?

Vulkan est le meilleur paramètre par défaut pour l’inférence locale GGUF lorsque la portabilité, la vitesse de configuration, la prise en charge Windows ou la couverture des Radeon plus anciens comptent. Il n’est plus raisonnable de le décrire comme intrinsèquement lent ; sur certaines combinaisons récentes de Radeon et llama.cpp, c’est le backend le plus rapide, et sur d’autres il est assez proche pour que la friction opérationnelle plus faible gagne.

ROCm est le bon choix lorsque le moteur est construit autour de PyTorch, lorsque l’AMD Instinct et le calcul multi-GPU sont centraux, ou lorsque une build HIP testée gagne la charge de travail du modèle réelle. Son écosystème est beaucoup plus fort en 2026, mais le nouvel empaquetage et les couches de compatibilité strictes récompensent encore les versions fixées et la vérification disciplinée — et sur la génération RDNA la plus récente spécifiquement, vérifier que la voie de noyau optimisé a réellement exécuté n’est pas optionnel.

Pour une station de travail Radeon prise en charge, ma recommandation est délibérément non romantique : installer Vulkan d’abord, ajouter ROCm lorsqu’un moteur ou un benchmark mérite la complexité, et garder les deux builds de llama.cpp si la machine sert régulièrement des formes de modèles différentes. Le meilleur backend AMD n’est pas une propriété permanente de la carte ; c’est une propriété de la carte, du moteur, du modèle, du pilote et de la charge de travail ensemble.

Références

S'abonner

Recevez de nouveaux articles sur les systèmes, l'infrastructure et l'ingénierie IA.