- Moteur d’inférence basé sur Docker pour exécuter de grands modèles de langage sur GPU AMD, destiné aux modèles Hugging Face et centré sur la famille LLaMA
- L’environnement d’exécution nécessite un GPU AMD compatible ROCm, Docker, ainsi que le pilote ROCm 5.4.2 ou une version compatible installé sur l’hôte
run-docker-amd.sh construit automatiquement l’image Docker et lance le conteneur avec les réglages nécessaires à l’accès au GPU AMD : /dev/kfd, /dev/dri, groupe video, SYS_PTRACE et seccomp=unconfined
- L’utilisateur peut changer de modèle en passant le nom du dépôt Hugging Face et le prompt en arguments ;
meta-llama/Llama-2-7b-chat-hf et facebook/opt-1.3b sont donnés en exemples
- Pour modifier le comportement de l’inférence, il faut modifier
run_inference.py puis reconstruire l’image Docker ; en cas de manque de mémoire, utiliser un modèle plus petit ou des longueurs d’entrée/sortie plus courtes
Objectif du projet et modèles ciblés
- Ce projet est un moteur d’inférence basé sur Docker pour exécuter des LLM sur GPU AMD
- Il est conçu pour utiliser des modèles Hugging Face, avec un accent particulier sur la famille de modèles LLaMA
- Il utilise la bibliothèque Hugging Face Transformers
Environnement requis
- Les prérequis avant l’exécution sont les suivants
- GPU AMD compatible ROCm
- Docker installé sur le système
- Pilote ROCm installé sur le système hôte
- La version 5.4.2 ou une version compatible est requise
Structure du projet
- La structure du dépôt se compose du répertoire
src/ et de fichiers d’exécution et de build
src/engine.py
src/model.py
src/utils.py
src/amd_setup.py
Dockerfile
requirements.txt
run_inference.py
run-docker-amd.sh
README.md
Démarrage rapide
- Après avoir cloné le dépôt, se placer dans le répertoire du projet
git clone https://github.com/slashml/amd-gpu-inference.git
cd amd-gpu-inference
- Donner les droits d’exécution au script
chmod +x run-docker-amd.sh
- Lancer le moteur d’inférence en passant le nom du modèle et le prompt
./run-docker-amd.sh "meta-llama/Llama-2-7b-chat-hf" "Translate the following English text to French: 'Hello, how are you?'"
"meta-llama/Llama-2-7b-chat-hf" peut être remplacé par le modèle Hugging Face à utiliser, et le prompt peut aussi être défini directement
Mode d’exécution avec Docker et ROCm
Aptfile liste les paquets ROCm à installer dans le conteneur Docker
- Il s’agit d’une configuration permettant d’utiliser les pilotes et bibliothèques ROCm nécessaires dans le conteneur
run-docker-amd.sh construit automatiquement l’image Docker
- Le build manuel est possible avec la commande suivante
docker build -t amd-gpu-inference .
- Lors du lancement manuel du conteneur, spécifier les périphériques et options de droits nécessaires à l’accès au GPU AMD
docker run --rm -it \
--device=/dev/kfd \
--device=/dev/dri \
--group-add=video \
--cap-add=SYS_PTRACE \
--security-opt seccomp=unconfined \
amd-gpu-inference "model_name" "your prompt here"
- Mettre le nom du modèle Hugging Face dans
"model_name" et le texte d’entrée dans "your prompt here"
Personnalisation et dépannage
- Le changement de modèle se fait en spécifiant le nom du dépôt Hugging Face lors de l’exécution
./run-docker-amd.sh "facebook/opt-1.3b" "Your prompt here"
- Pour modifier la logique d’inférence, éditer le fichier
run_inference.py
- Après modification, il faut reconstruire l’image Docker
- Les points de dépannage sont les suivants
- Vérifier que les pilotes GPU AMD et ROCm sont correctement installés et configurés sur le système hôte
- Si une erreur
"out of memory" se produit, utiliser un modèle plus petit ou réduire les longueurs d’entrée et de sortie
- Pour les problèmes propres à un modèle, consulter la documentation du modèle correspondant sur Hugging Face
Licence et références
- Le projet peut accepter des contributions sous forme de Pull Request
- ROCm est développé par AMD et fourni sous MIT License
- Les questions ou problèmes peuvent être ouverts dans les issues du dépôt GitHub
1 commentaires
Avis sur Hacker News
Pour l’inférence, si la carte est prise en charge ou si son architecture permet d’utiliser
HSA_OVERRIDE_GFX_VERSIONsous Linux, on peut presque tout faire tourner avec PyTorch upstream ettransformersllama.cppse compile aussi plutôt sans problème depuis au moins environ un an, et sous Windows il y a généralement des binaireswin-hipdans les releases, ou à défaut on peut contourner avec un build Vulkan, moins performantCela dit, le ROCm 5.4.2 de cet article date de près de deux ans et beaucoup de choses ont changé depuis ; je me demande pourquoi il a été publié seulement en octobre 2024
J’ai récemment mis à jour une documentation de compatibilité centrée sur RDNA3 pour ROCm 6.2, et même en quelques mois il y a eu beaucoup d’évolutions, comme
bitsandbytesupstream,xformersupstream et Flash Attention basé sur Triton : https://llm-tracker.info/howto/AMD-GPUsSi vous utilisez quelque chose comme
a1111, ne vous fiez pas aurequirements.txt: installez la version ROCm de torch en suivant les instructions du site de PyTorchObsidian est similaire, et HIP est assez simple au moins sur Arch et Ubuntu ; Fedora demande encore quelques ajustements
Je ne savais pas que
xformersfonctionnait aussi, c’est une bonne nouvelleLe seul qui a fonctionné directement était Ollama, avec un exemple : https://github.com/ollama/ollama/blob/main/docs/docker.md
llama.cppetkoboldcppont des images Docker, mais manquent d’exemples d’exécution, ettext-generation-webui-dockera cassé sur une 7800 XT sous RHEL9 : https://github.com/ggerganov/llama.cpp/blob/master/docs/dock..., https://github.com/LostRuins/koboldcpp?tab=readme-ov-file#do..., https://github.com/Atinoda/text-generation-webui-dockerEn résumé, ils font tourner Llama 405B en inférence pleine précision sur un nœud unique avec 8 GPU AMD MI300X, avec le récent ROCm 6.2
Je me demande à quel point ROCm 6.2 et la stack AMD sont considérés comme matures par rapport à Nvidia
La prolifération de bibliothèques de machine learning bricolées à la va-vite avec du génératif est assez étonnante
Cette bibliothèque est pour moitié composée d’instructions
print, et même les endroits où elle branche n’ont en réalité pas besoin de branchementElle se contente grosso modo de définir deux variables d’environnement et de régler deux flags
torchDans une équipe ou une organisation, je pense que la gestion des attentes est vraiment un élément majeur
Il n’y a effectivement presque rien dedans
On dirait qu’ils utilisent l’ancien ROCm 5.4.2 ; comme il date d’il y a deux ans, je doute qu’il prenne en charge ma RX 7900 XTX
Personnellement, le plus simple a été d’utiliser la dernière image
rocm/pytorchet d’exécuter ce dont j’avais besoin dedansgfx1100) a été activée pour la première fois dans des bibliothèques mathématiques commerocBLASavec ROCm 5.4, mais il me semble que les bibliothèques IA commeMIOpenne l’ont pas été avant ROCm 5.5Je pense que les performances se sont aussi nettement améliorées dans les versions suivantes
Sur Ubuntu 24.04 et Debian Unstable, avec les seuls paquets fournis par le système d’exploitation, on peut faire tourner
llama.cppavec ROCm sur presque tous les GPU AMD dédiés depuis VegaPas besoin de Docker ni de
HSA_OVERRIDE_GFX_VERSION: il suffit d’installerhipcc,libhipblas-dev,librocblas-dev,cmake, etc., d’accorder les droits aux groupesvideoetrender, puis de compiler avecGGML_HIPBLAS=ONPour les utilisateurs de RDNA 3, MI200 et MI300, les paquets ROCm fournis par AMD sont préférables pour les performances, et quand PyTorch est nécessaire, mieux vaut aussi utiliser les paquets AMD, car certaines dépendances ne sont pas dans les paquets système
Malgré tout, pour la facilité d’installation et la compatibilité avec du matériel ancien, les paquets du système d’exploitation sont difficiles à battre ; lien de référence : https://lists.debian.org/debian-ai/2024/07/msg00002.html
Cela fait environ 8 mois que j’ai acheté un Ryzen 8700G pour faire de l’inférence de réseaux neuronaux avec son NPU, mais jusqu’ici je n’obtiens de l’accélération qu’avec Vulkan sur l’iGPU, pas avec le NPU.
Je n’utilise que Linux, et le bon côté, c’est qu’avec 64 Go de RAM, j’ai pu essayer sans problème des modèles de plus de 32 Go.
llama.cpp, qui prend en charge le backend Vulkan, mérite des éloges.LLAMA_HIP_UMA=1lors de la compilation dellama.cpp.À voir https://github.com/amd/RyzenAI-SW, il y a pas mal de logiciels avec lesquels bricoler sur le NPU, mais Phoenix étant à 16 TOPS, je n’ai pas vraiment eu envie de tester moi-même.
Sur une station de travail NixOS, il m’a suffi d’ajouter à peu près ceci :
activer
hardware.graphics.enable = true;et définiracceleration = "rocm";,ROC_ENABLE_PRE_VEGA = "1";,HSA_OVERRIDE_GFX_VERSION = "11.0.0";dansservices.ollama.À une époque, en voyant la simplicité de
llamafile, j’ai failli installer AMD ROCm.Mais le résultat de
sudo apt install rocm, c’était 203 paquets à installer, environ 2,37 Go à télécharger, et 35,7 Go d’espace requis.Je ne comprends pas comment on peut justifier 36 Go pour quelque chose qui ressemble, en pratique, à un pilote GPU.
Il inclut plusieurs outils et bibliothèques.
Le CUDA toolkit, téléchargé en fichier unique, dépasse lui aussi 4 Go rien qu’au téléchargement ; dans les deux cas, on obtient donc quelque chose qui paraît déraisonnablement gros.
On dirait un wrapper généré par IA au-dessus d’un wrapper d’un wrapper d’un wrapper.
Il y a des commentaires comme
# Other AMD-specific optimizations can be added hereet# For example, you might want to set specific flags or use AMD-optimized libraries, et du coup je ne vois pas vraiment ce que ça fait ici.requirementset un Dockerfile ; le reste, ce sont surtout des scripts d’assistance.Quels sont les GPU AMD avec un bon rapport qualité-prix en ce moment ?
Je viens d’acheter deux 3090 d’occasion reconditionnées sur eBay, autour de 750 dollars chacune, et je me demande ce que les autres utilisent pour faire tourner des LLM en local.
Elle a 32 Go de HBM2 et, sur les benchmarks Flash Attention 2 de base, elle est environ 0 à 5 % plus rapide qu’une 3090, mais les performances en applications réelles sont très variables.
Beaucoup de projets ne sont pas optimisés pour les cœurs matriciels de CDNA, et même quand un travail existe pour RDNA, il ne se transpose souvent pas tel quel à CDNA.
C’est aussi frustrant que
llama.cppait fermé la PR Flash Attention pour AMD au motif qu’une bibliothèque header-only ajoutait une dépendance inutile : https://github.com/ggerganov/llama.cpp/pull/7011Avec
xformerssur les réglages par défaut de SDXL, j’obtiens environ 4,5 à 5 it/s, quelque part entre une 3090 et une 4090 ; avecexllamav2, Qwen 72B en 3 bpw tourne autour de 7 t/s, plus lentement qu’une 3090, mais une 3090 nécessiterait une précision plus basse pour le faire tenir.Je ne vois pas très bien ce que ce projet apporte de plus aux utilisateurs AMD par rapport aux options existantes comme
llama.cpp,exllamav2oumlc-ai, et aujourd’hui la plupart des projets fonctionnent relativement facilement.xformersou Ollama, donc ça ne valait pas grand-chose pour moi.Avec Nvidia, on dort plus tranquille la nuit.
Elle a de la HBM2 et une bande passante mémoire de 1 To/s, comme une 4090.
En revanche, elle n’a que 16 Go de VRAM.
24 Go de RAM pour 1 000 dollars.
Les gens disent souvent « basé sur Docker », mais ce que cela signifie en réalité, c’est que
$SOFTWAREest distribué sous forme d’image Docker.Dire « basé sur Docker » donne l’impression qu’on fait de l’inférence sur des cartes AMD grâce à Docker, ce qui me semble être une formulation absurde.
OpenAI fait aussi tourner ses clusters K8s de cette manière, et AMD a de la documentation à ce sujet.
Cela dit, côté IA chez AMD, il faut la bonne carte, la bonne version de ROCm, et une bonne dose de chance.
AMD fournit des images Docker avec prise en charge ROCm ; on peut donc les utiliser comme couche de base, y intégrer l’application et passer le GPU au conteneur, et ça peut fonctionner.
Au final, cela réduit d’une unité le nombre de variables dont il faut se soucier au déploiement ; on peut donc littéralement dire qu’on fait de l’inférence sur AMD avec Docker.
En regardant le script, on voit qu’il monte le GPU : https://github.com/slashml/amd_inference/blob/main/run-docke...