4 points par GN⁺ 2024-10-04 | 1 commentaires | Partager sur WhatsApp
  • 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

 
GN⁺ 2024-10-04
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_VERSION sous Linux, on peut presque tout faire tourner avec PyTorch upstream et transformers
    llama.cpp se compile aussi plutôt sans problème depuis au moins environ un an, et sous Windows il y a généralement des binaires win-hip dans les releases, ou à défaut on peut contourner avec un build Vulkan, moins performant
    Cela 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 bitsandbytes upstream, xformers upstream et Flash Attention basé sur Triton : https://llm-tracker.info/howto/AMD-GPUs

  • 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 branchement
    Elle se contente grosso modo de définir deux variables d’environnement et de régler deux flags torch

    • J’ai même dû suivre une thérapie pour arrêter de prendre les data scientists et les gens du machine learning pour des ingénieurs logiciel et d’attendre d’eux les mêmes livrables
      Dans une équipe ou une organisation, je pense que la gestion des attentes est vraiment un élément majeur
    • Je me suis demandé si c’était trop harsh, mais en regardant le dépôt, non
      Il n’y a effectivement presque rien dedans
    • Je vois ce que vous voulez dire, mais ce genre de commentaire décourage les gens de partager leur code, de contribuer à l’open source ou de continuer à programmer
  • 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/pytorch et d’exécuter ce dont j’avais besoin dedans

    • La RX 7900 XTX (gfx1100) a été activée pour la première fois dans des bibliothèques mathématiques comme rocBLAS avec ROCm 5.4, mais il me semble que les bibliothèques IA comme MIOpen ne l’ont pas été avant ROCm 5.5
      Je 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.cpp avec ROCm sur presque tous les GPU AMD dédiés depuis Vega
    Pas besoin de Docker ni de HSA_OVERRIDE_GFX_VERSION : il suffit d’installer hipcc, libhipblas-dev, librocblas-dev, cmake, etc., d’accorder les droits aux groupes video et render, puis de compiler avec GGML_HIPBLAS=ON
    Pour 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

    • Sur Ubuntu 22.04.5 avec une RX 7900 XTX, j’ai installé sans gros problème ROCm et Ollama fournis par AMD, et les LLM basés sur ROCm fonctionnent bien avec Ollama
    • Existe-t-il aujourd’hui sur le marché une carte AMD avec plus de 24 Go de VRAM à un prix grand public ?
  • 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.

    • Il devrait aussi être possible d’obtenir la prise en charge ROCm/HIP sur l’iGPU, et il suffit d’essayer d’ajouter le flag LLAMA_HIP_UMA=1 lors de la compilation de llama.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éfinir acceleration = "rocm";, ROC_ENABLE_PRE_VEGA = "1";, HSA_OVERRIDE_GFX_VERSION = "11.0.0"; dans services.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.

    • Certes, les logiciels d’aujourd’hui sont devenus absurdement énormes, mais ROCm n’est pas un simple 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.
    • Ce problème est en cours de résolution dans https://github.com/zml/zml.
    • Désormais, les pilotes CPU qui tournent sur GPU sont presque des systèmes d’exploitation complets.
    • AMD en est au point de salir complètement le noyau Linux avec ses pilotes : https://www.phoronix.com/news/AMD-5-Million-Lines
  • 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 here et # 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.

    • En pratique, c’est un gros fichier requirements et 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.

    • J’ai récemment acheté une MI100 pour 650 dollars.
      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.cpp ait 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/7011
      Avec xformers sur les réglages par défaut de SDXL, j’obtiens environ 4,5 à 5 it/s, quelque part entre une 3090 et une 4090 ; avec exllamav2, 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, exllamav2 ou mlc-ai, et aujourd’hui la plupart des projets fonctionnent relativement facilement.
    • Personnellement, les iGPU/GPU AMD se cassaient à chaque mise à jour de PyTorch, ROCm, xformers ou Ollama, donc ça ne valait pas grand-chose pour moi.
      Avec Nvidia, on dort plus tranquille la nuit.
    • J’ai acheté une Radeon Pro VII neuve pour 300 euros, et ce n’était pas une mauvaise affaire.
      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.
    • La réponse est probablement la 7900 XTX.
      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 $SOFTWARE est 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.

    • On peut faire de l’inférence dans un conteneur Docker, comme on le fait avec Nvidia.
      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.
    • Si Docker est devenu un outil standard en machine learning, c’est parce que les distributions Python liées aux bibliothèques système deviennent un bazar si l’on n’embarque pas aussi cette couche.
    • On peut monter des périphériques spécifiques dans Docker.
      En regardant le script, on voit qu’il monte le GPU : https://github.com/slashml/amd_inference/blob/main/run-docke...
    • ZML travaille à résoudre ce problème : https://github.com/zml/zml
    • En quoi est-ce absurde ? Même dans un conteneur Docker, on peut communiquer avec des périphériques ; il suffit de les attacher.