Architecture-Aware LLM Inference Optimization on AMD Instinct GPUs: A Comprehensive Benchmark and Deployment Study

Cette étude présente une évaluation comparative de l'inférence de grands modèles de langage sur les GPU AMD Instinct MI325X, démontrant que l'optimisation adaptée à l'architecture est cruciale pour maximiser le débit et la stabilité, tout en validant des performances élevées et une fiabilité totale sur des modèles allant jusqu'à 1 trillion de paramètres.

L'essentiel

🏎️ Le Grand Défi : Faire courir des géants de l'IA sur des moteurs AMD

Imaginez que vous êtes le directeur d'une course automobile très spéciale. Vos voitures ne sont pas des bolides ordinaires, mais des géants de l'intelligence artificielle (des modèles de langage comme ceux qui écrivent des textes ou créent des images). Ces "voitures" sont immenses : certaines pèsent le poids de 1 000 milliards de pièces (paramètres) !

Le défi de ce rapport est de voir comment ces géants se comportent sur une nouvelle piste : les puces graphiques AMD Instinct MI325X. Jusqu'à présent, la plupart des courses se faisaient sur des puces NVIDIA. Ici, on teste si AMD peut tenir la route.

🚗 Les quatre concurrents (Les Modèles)

Pour l'épreuve, quatre modèles très différents ont été mis en ligne. On peut les comparer à quatre types de véhicules :

1. Llama-3.1-405B : Le "Camion de Déménagement". C'est un modèle dense. Il utilise toutes ses pièces (405 milliards) pour chaque mot qu'il génère. C'est lourd, mais très puissant.
2. DeepSeek V3.2 & Kimi-K2.5 : Les "Formules 1 à Expert". Ce sont des modèles MoE (Mixture of Experts). Imaginez une voiture avec 384 moteurs, mais qui n'en active que 8 à la fois selon le virage. Ils sont énormes (jusqu'à 1 000 milliards de pièces), mais très légers en fonctionnement car ils n'utilisent qu'une petite partie de leur cerveau à chaque instant.
   • Note : Kimi-K2.5 est le plus gros de tous (1 trillion de paramètres !).
3. Qwen3-VL-235B : Le "Camion de Livraison Multimodal". Il peut lire du texte ET voir des images. C'est aussi un modèle "Expert" (MoE), mais il utilise une technologie différente pour gérer ses yeux (vision).

🛣️ La Piste et les Règles (Le Matériel AMD)

La course se déroule sur un circuit de 8 puces AMD MI325X.

• La mémoire (HBM3e) : C'est le garage de la voiture. Chaque puce a un garage énorme de 256 Go. Avec 8 puces, vous avez un garage géant de 2 To (Téraoctets). C'est assez grand pour garer même le plus gros camion (Kimi-K2.5) sans avoir à le décharger sur le trottoir (la mémoire du CPU).
• La bande passante (6 TB/s) : C'est la vitesse à laquelle les pièces peuvent entrer et sortir du garage. C'est le goulot d'étranglement principal.

🔧 Les Découvertes Clés (Ce que les ingénieurs ont appris)

1. Une seule clé ne ouvre pas toutes les portes (Optimisation "Architecture-Aware")

C'est la découverte la plus importante. On ne peut pas utiliser les mêmes réglages pour tous les modèles. C'est comme essayer de mettre des pneus de Formule 1 sur un camion de pompiers : ça ne marche pas.

• Les modèles "Experts" (MoE) avec la technologie MLA : Ils sont très exigeants. Sur les puces AMD actuelles, ils doivent rouler très lentement (taille de bloc 1) et ne peuvent pas utiliser le "garage extérieur" (mémoire CPU). De plus, ils ont besoin d'un moteur spécial appelé AITER pour aller vite. Sans AITER, ils sont lents comme des tortues.
• Les modèles "Denses" (GQA) : Ils sont plus flexibles. Ils peuvent utiliser le garage extérieur et rouler avec des réglages standards.
• Le problème de Kimi-K2.5 : Ce modèle est si gros et utilise une technologie si récente (MXFP4) que le moteur spécial AITER ne fonctionne pas encore sur ces puces AMD. Il faut donc le désactiver et utiliser une méthode de secours plus lente.

2. Le mythe de la taille (Ce qui compte vraiment)

On pensait que plus la voiture est lourde (plus de paramètres totaux), plus elle est lente. Faux !
Ce qui compte, c'est le poids actif.

• L'analogie : Imaginez un restaurant avec 100 cuisiniers (paramètres totaux). Si le chef n'en active que 5 pour préparer un plat (paramètres actifs), le plat sera préparé aussi vite que si le restaurant n'avait que 5 cuisiniers au total.
• Résultat : Le modèle DeepSeek (qui n'active que 37 milliards de paramètres) va aussi vite que Llama (qui en active 405 milliards !). La taille totale du modèle n'est pas le frein, c'est le nombre de pièces utilisées à l'instant T.

3. Le goulot d'étranglement (La saturation)

Peu importe si vous avez un camion ou une F1, il y a un moment où tout le monde arrive au même point de saturation.

• L'analogie : Imaginez un péage. Peu importe la puissance de votre moteur, si vous avez 500 voitures qui arrivent en même temps, le péage ne peut en traiter qu'un certain nombre par minute.
• Le résultat : Sur ce circuit AMD, tous les modèles atteignent leur vitesse maximale vers 500 utilisateurs simultanés. Au-delà, on ajoute plus de voitures, mais le débit ne augmente pas. On obtient juste des files d'attente plus longues (plus de latence).
• Pourquoi ? Ce n'est pas le moteur (le calcul) qui est faible, c'est la route (la mémoire) qui est trop étroite pour faire passer autant de données à la fois.

4. La fiabilité (100% de succès)

Malgré la pression extrême (jusqu'à 1 000 utilisateurs en même temps), aucun modèle n'a planté. Le système a géré la foule en les faisant patienter dans une file d'attente intelligente, plutôt que de les rejeter. C'est comme un excellent gestionnaire de trafic qui évite les embouteillages totaux.

📝 En résumé pour le grand public

Ce rapport nous dit trois choses essentielles pour l'avenir de l'IA sur les puces AMD :

1. Il faut être sur mesure : On ne peut pas appliquer une solution unique à tous les modèles d'IA. Chaque architecture (MoE, Dense, MLA) a ses propres besoins en réglages.
2. La taille totale n'est pas tout : Un modèle "intelligent" qui n'active que ses meilleurs experts peut être aussi rapide qu'un géant lourd, même sur du matériel AMD.
3. La mémoire est le roi : Pour faire tourner ces géants, la vitesse à laquelle on peut lire les données (bande passante) est plus importante que la puissance brute de calcul. Les puces AMD MI325X sont excellentes pour cela, mais elles atteignent leurs limites quand on essaie de servir trop de monde en même temps.

Conclusion : AMD est maintenant un concurrent sérieux pour faire tourner les plus grands modèles d'IA du monde, à condition de bien connaître les spécificités de chaque modèle pour éviter les pièges techniques.

Résumé technique

Résumé Technique : Optimisation de l'Inférence des LLM sur les GPU AMD Instinct

1. Problématique et Contexte

Le déploiement de modèles de langage (LLM) à l'échelle frontalière (de plusieurs centaines de milliards à un trillion de paramètres) pose des défis majeurs en matière d'inférence. Bien que les études de benchmarking se soient concentrées sur les accélérateurs NVIDIA, les évaluations systématiques sur les accélérateurs AMD Instinct MI325X (architecture CDNA 3) restent rares.

Le problème central réside dans la diversité croissante des architectures de modèles (Dense, MoE, MLA, GQA) qui imposent des contraintes fondamentalement différentes sur la hiérarchie mémoire, le parallélisme et l'optimisation des noyaux (kernels). Une configuration de service optimale pour un modèle dense peut être inefficace, voire erronée, pour un modèle MoE utilisant une attention latente (MLA). De plus, l'écosystème logiciel ROCm et les bibliothèques d'accélération comme AITER (AMD AI Tensor Engine for ROCm) nécessitent une configuration spécifique selon l'architecture du modèle.

2. Méthodologie

Les auteurs ont mené une étude comparative systématique sur un cluster de 8 GPU AMD Instinct MI325X (2 To de mémoire HBM3e au total, 48 To/s de bande passante) utilisant le framework d'inférence vLLM v0.14.1.

• Modèles évalués : Quatre modèles de pointe couvrant trois familles architecturales :
  • Kimi-K2.5 (1T paramètres totaux, 32B actifs) : MoE + MLA.
  • DeepSeek V3.2 (685B totaux, 37B actifs) : MoE + MLA.
  • Llama-3.1-405B (405B totaux, 405B actifs) : Dense + GQA.
  • Qwen3-VL-235B (235B totaux, 22B actifs) : MoE + GQA (Multimodal).
• Charge de travail : Évaluation de la latence (1 requête) jusqu'à 1 000 utilisateurs concurrents, incluant des tests de stress (génération longue, contexte long, charge visuelle).
• Configuration logicielle : Utilisation de Docker, ROCm 6.4.2, et gestion fine des flags vLLM (taille de bloc, parallélisme tensoriel, quantification).
• Métriques : Débit (tokens/seconde), latence (p99), taux de réussite HTTP, et variabilité des mesures (coefficient de variation).

3. Contributions Clés

L'étude apporte cinq contributions majeures à la communauté :

1. Benchmark Trans-Architecture sur MI325X : Première évaluation académique couvrant des modèles denses, MoE+GQA et MoE+MLA sur du matériel AMD CDNA 3, avec une caractérisation des contraintes de configuration spécifiques.
2. Nécessité de l'Optimisation "Architecture-Aware" : Démonstration qu'une configuration unique ne fonctionne pas.
   • Les modèles MLA exigent une taille de bloc (block size) de 1 et sont incompatibles avec le déchargement (offloading) du cache KV sur CPU dans la pile ROCm actuelle.
   • Les modèles GQA bénéficient du déchargement du cache KV et de tailles de blocs standards.
   • AITER est indispensable pour un débit compétitif sur les modèles MLA, mais doit être désactivé pour certains (comme Kimi-K2.5) en raison de contraintes matérielles (MXFP4 non supporté sur CDNA 3) et de nombres de têtes d'attention incompatibles.
3. Déploiement d'un Modèle à 1 Trillion de Paramètres : Réalisation du premier benchmark d'inférence publié d'un modèle de 1T paramètres (Kimi-K2.5) sur MI325X, utilisant une quantification INT4 QAT et un parallélisme tensoriel (TP) de 4.
4. Validation du Rôle des Paramètres Actifs : Confirmation empirique que le nombre de paramètres actifs par token (et non le nombre total) est le facteur dominant du débit d'inférence, bien que confondu par d'autres variables (quantification, AITER).
5. Saturation Dépendante de la Charge : Identification d'un point de saturation commun pour tous les modèles au sein d'une même charge de travail, indiquant un goulot d'étranglement lié à la bande passante mémoire plutôt qu'à la puissance de calcul.

4. Résultats Principaux

• Performance de Pointe (Débit) :
  • Texte : Llama-3.1-405B (Dense+GQA) et DeepSeek V3.2 (MoE+MLA) atteignent des débits totaux comparables (~15 944 et ~15 343 tok/s respectivement) à 500 utilisateurs concurrents, malgré une différence d'un ordre de grandeur dans les paramètres actifs (405B vs 37B).
  • Vision : Qwen3-VL-235B (MoE+GQA) atteint un débit total de 47 873 tok/s (incluant les tokens d'images), soit 6,5 fois plus que Kimi-K2.5 (7 327 tok/s), malgré un nombre de paramètres actifs plus faible (22B vs 32B).
• Impact d'AITER :
  • Pour les modèles GQA (Llama), AITER apporte un gain modeste (3-5% à haute concurrence) mais augmente considérablement la variabilité des mesures (2 à 16 fois plus de variance).
  • Pour les modèles MLA, AITER est critique pour la production. L'ablation (désactivation) n'est pas possible de manière contrôlée car le fallback Triton est trop lent pour être pertinent.
  • Contrainte critique : Kimi-K2.5 doit désactiver AITER (erreur MXFP4 sur CDNA 3 et incompatibilité des têtes d'attention), ce qui limite son débit et force l'utilisation de TP=4 au lieu de TP=8.
• Saturation et Fiabilité :
  • Tous les modèles atteignent un point de saturation à environ 500 utilisateurs concurrents pour des séquences courtes (500 tokens d'entrée), et entre 100-200 pour des séquences longues. Au-delà, le débit stagne, confirmant que la bande passante mémoire (48 To/s) est le goulot d'étranglement.
  • Fiabilité : Taux de réussite HTTP de 100% jusqu'à 1 000 utilisateurs concurrents sur l'ensemble des modèles, sans échec de requête.
• Utilisation des Ressources :
  • L'utilisation des FLOPs reste faible (<15% même pour le modèle le plus dense), confirmant que l'inférence est limitée par la mémoire (Memory-Bound).
  • La capacité de 256 Go de HBM3e par GPU permet d'héberger tous les modèles (y compris Kimi-K2.5) sans nécessiter de déchargement vers la RAM CPU, simplifiant l'architecture.

5. Signification et Implications

Cette étude démontre que l'AMD Instinct MI325X est une plateforme viable pour l'inférence de modèles frontalières, capable de gérer des modèles jusqu'à 1 trillion de paramètres avec une fiabilité totale.

Cependant, les résultats soulignent que l'optimisation "one-size-fits-all" est obsolète. Les déploiements de production sur ROCm doivent implémenter une logique de détection d'architecture pour :

1. Ajuster dynamiquement la taille de bloc du cache KV (1 pour MLA, 16 pour GQA).
2. Gérer sélectivement l'activation d'AITER (nécessaire pour MLA, optionnel pour GQA, interdit pour Kimi-K2.5 sur CDNA 3).
3. Planifier le parallélisme tensoriel en fonction des contraintes de têtes d'attention.

L'étude met également en lumière que pour les charges de travail courtes, la bande passante mémoire est le facteur limitant principal, suggérant que les futures optimisations doivent se concentrer sur la réduction du trafic mémoire (via la quantification, la compression du cache KV ou la sparsité MoE) plutôt que sur l'augmentation brute de la puissance de calcul.

Enfin, l'étude identifie des axes d'amélioration pour les futures versions de ROCm et vLLM, notamment le support du déchargement du cache KV pour les modèles MLA et la résolution des incompatibilités de dimensions pour les encodeurs visuels en FP8.