Ce moment, AMD l'attendait peut-être depuis longtemps.
Récemment, Wafer AI a déployé Kimi K3 sur des AMD MI355X. Le résultat est qu'un modèle qui nécessitait auparavant 16 cartes NVIDIA B200, réparties sur deux serveurs, peut désormais être déployé dans un seul serveur AMD équipé de 8 cartes MI355X.
Le plus important, ce n'est pas seulement qu'ils ont réussi à y installer le modèle.
Lors de tests avec une entrée de 1024 tokens et une sortie de 400 tokens, les MI355X ont atteint un débit total de 952 tokens/s, avec une vitesse de génération par utilisateur unique de 118 tokens/s.
Calculé par nœud unique, son débit est environ 3,8 fois supérieur à celui de la solution à 16 cartes B200, et son rapport performance/prix dépasse également celui des B200 et B300.
Et le plus surprenant, c'est que ROCm n'a pas été particulièrement problématique cette fois.
Les modèles sont trop grands, la mémoire vidéo devient plus importante que la puissance de calcul
Kimi K3 possède 2800 milliards de paramètres. Les poids du modèle nécessitent à eux seuls plus de 1,5 To de mémoire vidéo, sans compter le cache KV requis pour le contexte d'un million de tokens.
Un serveur à 8 cartes B200, avec 192 Go de mémoire par carte, offre une capacité totale d'environ 1,5 To. Autrement dit, il est déjà difficile d'y loger tous les poids du modèle, sans parler de l'espace nécessaire pour le cache KV. C'est pourquoi la solution B200 nécessite deux serveurs et 16 GPU.
La carte B300 possède 288 Go de mémoire, ce qui permet de contenir le modèle sur un seul nœud. Coïncidence, la AMD MI355X dispose également de 288 Go de mémoire. Huit MI355X totalisent environ 2,3 To, un seul serveur suffit donc.
Cela ne signifie pas seulement utiliser un serveur de moins. Lorsqu'un modèle s'exécute sur plusieurs nœuds, la génération de chaque token peut nécessiter une synchronisation des données via le réseau. Même avec un réseau RoCE v2 d'environ 195 Gb/s, la communication inter-nœuds ralentit le décodage.
Grâce à sa mémoire vidéo plus importante, la MI355X maintient l'intégralité du modèle sur un seul nœud.
Au final, le débit total de pointe des 8 MI355X atteint 952 tokens/s, avec une vitesse de génération par flux unique de 118 tokens/s.
En comparaison, le déploiement sur deux nœuds avec 16 B200 affiche un débit total de 498 tokens/s, soit environ 249 tokens/s par nœud en moyenne.
Ainsi, le débit par nœud unique des MI355X est environ 3,8 fois supérieur au débit moyen par nœud du déploiement double nœud des B200. En termes de vitesse de génération par utilisateur unique, les 118 tokens/s des MI355X dépassent également les 90 tokens/s des B200.
Le B300 reste la solution aux performances absolues les plus élevées. Le débit total par nœud de 8 B300 atteint 1568 tokens/s, avec une vitesse de génération par flux unique de 172 tokens/s, soit un débit global environ 1,65 fois supérieur à celui des MI355X.
Mais le prix change la donne. Wafer a effectué ses calculs en supposant un coût horaire de 2,5 dollars par carte pour la MI355X, 4,25 dollars pour la B200 et 6 dollars pour la B300.
Selon cette hypothèse tarifaire, la MI355X offre environ 48 tokens/s de débit de pointe par dollar dépensé ; la B200 environ 7 tokens/s ; et la B300 environ 33 tokens/s.
Le B300 est plus rapide, mais la MI355X offre une meilleure efficacité par unité de coût. Pour les centres de données qui doivent exécuter des modèles ouverts à grande échelle, cela pourrait être plus important que la simple course aux performances absolues.
Plus surprenant encore, ROCm était pratiquement prêt à l'emploi
Depuis longtemps, le plus gros problème des GPU AMD pour centres de données n'est souvent pas le matériel, mais le logiciel.
Un même modèle qui fonctionne directement sur CUDA peut nécessiter, sur ROCm, des modifications du framework, l'ajout d'opérateurs, voire une réécriture du noyau bas niveau.
Mais le cas de Kimi K3 est différent.
AMD a fourni un support presque simultané à sa sortie. Wafer indique que le modèle a pu fonctionner quasiment directement sur les MI355X, les travaux ultérieurs se concentrant sur quelques problèmes de compatibilité mineurs et l'optimisation des performances.
L'un de ces problèmes est apparu lors du décodage spéculatif. Kimi K3 lui-même ne fournit pas les paramètres du modèle de brouillon requis pour MTP ou EAGLE, donc Wafer a utilisé un modèle de brouillon par diffusion de blocs externe.
Cette solution fonctionnait directement sur CUDA, mais dans l'environnement ROCm, la première requête réelle provoquait une erreur du planificateur. La cause : une fonction nommée `top_k_renorm_prob` n'était pas définie dans la branche ROCm.
Cette fonction ne fait rien de très complexe : elle sélectionne les k valeurs les plus élevées d'une distribution de probabilité, met les autres probabilités à zéro, puis renormalise les probabilités conservées.
Wafer a finalement comblé cette logique en utilisant une fonction PyTorch standard, sans avoir à écrire de noyau GPU ni à redessiner le système de décodage spéculatif.
Après correction, le décodage spéculatif a amélioré les performances par flux unique d'environ 2,2 fois, les performances par flux unique sous concurrence moyenne d'environ 1,7 fois, et le débit total de pointe d'environ 18 %.
Plus important encore, le système a pu atteindre son débit de pointe sous une concurrence plus élevée.
Le premier mot trop lent, finalement ils n'ont ajouté que quatre zéros
Bien sûr, le débit n'est pas le seul indicateur d'un service d'inférence. Pour les utilisateurs réels, un autre indicateur qui impacte directement l'expérience est le TTFT, c'est-à-dire le temps d'attente entre l'envoi d'une requête et l'apparition du premier token.
Sur ce point, la performance initiale des MI355X n'était pas bonne. Face à une tâche de pré-remplissage à froid d'environ 172 000 tokens, les MI355X nécessitaient environ 51 secondes, contre seulement 23 secondes pour les B300.
Dans les modèles supportant un contexte d'un million de tokens, les tâches de pré-remplissage peuvent être très volumineuses. Si les utilisateurs doivent attendre des dizaines de secondes ou plus à chaque fois qu'ils traitent un long contexte, même la vitesse de décodage la plus élevée aura du mal à compenser cette mauvaise expérience.
Wafer a finalement découvert que l'écart de performance provenait presque entièrement d'un noyau d'attention. Dans une configuration de parallélisme tensoriel à 8 voies, Kimi K3 attribue 12 têtes d'attention à chaque GPU. Or, le noyau de pré-remplissage MLA plus rapide d'AMD AITER ne supporte que des formes correspondant à des multiples de 4, 8 ou 16.
Les 12 têtes ne correspondaient pas, ce qui a fait revenir le système à une implémentation Triton générique plus lente.
La solution était simple : compléter les 12 têtes d'attention avec des zéros pour arriver à 16, appeler le noyau haute vitesse existant, puis ne récupérer que les 12 têtes réellement nécessaires après calcul. Aucune modification de l'architecture du modèle, aucun nouveau noyau assembleur écrit, juste quatre zéros ajoutés.
Après optimisation, la vitesse stable de pré-remplissage du noyau AITER MLA atteint environ 13 000 tokens/s, contre seulement 4000 à 7000 tokens/s pour l'ancienne voie de repli Triton, réduisant ainsi le temps de pré-remplissage à froid d'environ deux à trois fois.
Cette optimisation ne modifie pas le débit final de décodage, mais réduit significativement le temps d'attente de l'utilisateur avant l'apparition du premier mot.
Cela montre également que l'écart logiciel apparent entre AMD et NVIDIA n'est parfois pas dû à un manque de capacités sous-jacentes, mais simplement au fait que les noyaux haute vitesse existants ne couvrent pas temporairement une nouvelle forme de modèle.
L'avantage de CUDA demeure, mais une brèche est apparue
Un seul test ne prouve évidemment pas qu'AMD a rattrapé NVIDIA sur tous les plans.
La B200, en manque de mémoire, a été forcée de s'exécuter sur plusieurs nœuds ; la B300 conserve des performances absolues supérieures ; la chaîne d'outils ROCm, le support des frameworks et l'écosystème développeur restent inférieurs à ceux de CUDA.
Mais les modèles ouverts entrent rapidement dans l'ère des milliers de milliards de paramètres. Lorsqu'un modèle est trop grand pour tenir sur un seul serveur, la capacité de mémoire vidéo n'est plus seulement un chiffre sur une fiche technique, elle impacte directement le coût de communication, la complexité du déploiement et le débit final.
La stratégie d'AMD consistant à doter chaque carte de plus de HBM devient un avantage système concret.
Si AMD peut continuer à améliorer la stabilité de ROCm, étendre le support des formes pour ses noyaux haute vitesse, et offrir une adaptation plus rapide aux nouveaux modèles dès leur sortie, alors les centres de données devront sérieusement considérer ces GPU. Moins chers, plus de mémoire, des performances suffisantes, et un logiciel qui ne nécessite plus des mois de bricolage.
Qu'en pensez-vous ?
Liens de référence :
https://x.com/wafer_ai/status/2083628389903315406
https://x.com/ChiragAsarpota/status/2083864019870634151
Cet article provient du compte WeChat officiel "机器之心" (ID : almosthuman2014), auteur : 关注LLM的
