AMD MI355X surpasse NVIDIA B200 dans le déploiement de Kimi K3

Cela pourrait être le moment attendu depuis longtemps par AMD.

Récemment, Wafer AI a déployé sur AMD MI355X Kimi K3. Le résultat est que le modèle, qui nécessitait initialement 16 NVIDIA B200 répartis sur deux serveurs, peut désormais être déployé sur un seul serveur AMD équipé de 8 MI355X.

Plus important encore, il ne s'agit pas simplement d'avoir intégré le modèle.

Lors du test avec 1024 tokens en entrée et 400 tokens en sortie, le MI355X a atteint un débit total de 952 tokens/s, avec une vitesse de génération par utilisateur de 118 tokens/s.

Calculé sur un seul nœud, son débit est environ 3,8 fois supérieur à celui de la solution B200, et son rapport performance/prix dépasse également celui du B200 et du B300.

Et le plus surprenant, c'est que ROCm n'a pas cette fois-ci créé de complications particulières.

Kimi K3 possède 2,8 billions de paramètres et nécessite plus de 1,5 To de mémoire GPU uniquement pour les poids du modèle, sans compter le KV Cache requis pour les contextes de millions de tokens.

Un serveur à 8 cartes B200, avec 192 Go de mémoire vidéo par carte, offre une capacité totale d'environ 1,5 To. Cela signifie qu'il est difficile de loger complètement les poids du modèle, encore moins de laisser de l'espace pour le KV Cache. Par conséquent, le B200 doit utiliser deux serveurs et 16 GPU.

Chaque carte B300 dispose de 288 Go de mémoire vidéo, permettant de loger le modèle au sein d’un seul nœud. Curieusement, la AMD MI355X possède également 288 Go de mémoire vidéo ; huit MI355X totalisent environ 2,3 To, suffisant pour une seule serveur.

Ce n'est pas seulement une machine de moins. Une fois que le modèle s'exécute à travers plusieurs nœuds, chaque token généré peut nécessiter une synchronisation de données via le réseau. Même avec un réseau RoCE v2 d'environ 195 Go/s, la communication entre nœuds ralentit toujours le décodage.

Le MI355X, grâce à sa mémoire vidéo plus importante, a conservé l'ensemble du modèle sur un seul nœud.

Au final, le débit total maximal de 8 MI355X atteint 952 tokens/s, avec une vitesse de génération par canal de 118 tokens/s.

Pour comparaison, le débit total d'un déploiement double nœud avec 16 B200 est de 498 tokens/s, ce qui équivaut à environ 249 tokens/s par nœud.

Autrement dit, le débit par nœud du MI355X est environ 3,8 fois supérieur à la moyenne du débit par nœud du déploiement dual nœud B200. En termes de vitesse de génération par utilisateur, les 118 tokens/s du MI355X dépassent également les 90 tokens/s du B200.

B300 reste toujours la solution offrant les meilleures performances absolues. Le débit total d'un nœud avec 8 B300 atteint 1568 tokens/s, avec une vitesse de génération par canal de 172 tokens/s, soit environ 1,65 fois le débit total du MI355X.

Mais le prix a modifié la conclusion. Wafer est calculé à 2,5 $ par carte et par heure pour MI355X, 4,25 $ pour B200 et 6 $ pour B300.

Sous cette hypothèse de prix, MI355X offre un débit maximal d'environ 48 Token/s par dollar ; B200 environ 7 Token/s ; B300 environ 33 Token/s.

B300 est plus rapide, mais le MI355X offre une efficacité coûts par unité supérieure. Pour les centres de données nécessitant l'exécution à grande échelle de modèles ouverts, cela peut être plus important que de simplement rivaliser pour le titre de performance maximale.

Pendant longtemps, le plus grand problème des GPU de centre de données AMD n'était pas tant le matériel que le logiciel.

Le même modèle peut s'exécuter directement sur CUDA, mais sur ROCm, il peut être nécessaire de modifier le cadre, d'ajouter des opérateurs, voire de réécrire les noyaux sous-jacents.

Mais Kimi La situation de K3 est différente.

AMD offre un support presque synchrone au lancement. Wafer indique que les modèles peuvent être exécutés directement sur le MI355X, et les travaux suivants se concentrent principalement sur quelques problèmes de compatibilité et d'optimisation des performances.

Un problème est survenu lors de l'étape de décodage supposé. Kimi K3 ne fournit pas les paramètres du modèle brouillon requis par MTP ou EAGLE, donc Wafer utilise un modèle brouillon de diffusion externe.

Ce scénario s'exécute directement sur CUDA, mais dans l'environnement ROCm, la première requête réelle déclenche une erreur du planificateur. La cause est l'absence de définition d'une fonction nommée top_k_renorm_prob dans la branche ROCm.

Ce que fait cette fonction n'est pas compliqué : sélectionner les k valeurs les plus élevées à partir d'une distribution de probabilité, mettre les autres probabilités à zéro, puis rééquilibrer les probabilités conservées.

Wafer a fini par utiliser une fonction PyTorch standard pour compléter cette logique, sans avoir besoin d'écrire de noyau GPU manuellement ni de redessiner le système de décodage par prédiction.

Après correction, le décodage estimé améliore les performances en mode unidirectionnel d'environ 2,2 fois, les performances en flux unique sous charge moyenne d'environ 1,7 fois, et le débit total maximal d'environ 18 %.

Plus important, le système peut atteindre un débit maximal sous une charge concurrente plus élevée.

Bien sûr, le débit n'est pas tout pour les services d'inférence. Pour les utilisateurs réels, un autre indicateur qui influence directement l'expérience est le TTFT, soit le temps d'attente entre l'envoi de la requête et l'affichage du premier token.

Sur ce point, les performances initiales du MI355X n'étaient pas bonnes. Face à une tâche de pré-remplissage de démarrage à froid d'environ 172 000 tokens, le MI355X nécessitait environ 51 secondes, tandis que le B300 n'en nécessitait que environ 23 secondes.

Dans les modèles prenant en charge des contextes de millions de tokens, les tâches de pré-remplissage peuvent être extrêmement volumineuses. Si les utilisateurs doivent attendre plusieurs dizaines de secondes, voire plus, à chaque fois qu'ils traitent un long contexte, aucune vitesse de décodage, aussi élevée soit-elle, ne peut compenser cette dégradation de l'expérience.

Wafer a finalement découvert que l'écart de performance provenait presque entièrement d'un noyau d'attention. Kimi K3, dans une configuration de parallélisme tensoriel à 8 voies, attribue 12 têtes d'attention à chaque GPU. Or, le noyau de pré-remplissage MLA le plus rapide d'AMD AITER ne prend en charge que des formes multiples de 4, 8 ou 16.

12 têtes n'ont pas pu être appariées, donc le système a reverté vers l'implémentation générique Triton plus lente.

La solution est simple : compléter les 12 têtes d'attention par des zéros pour en obtenir 16, utiliser le noyau rapide existant, puis récupérer les 12 têtes réellement nécessaires après calcul. Aucune modification de la structure du modèle ni écriture d'un nouveau noyau en assembleur n'a été nécessaire — il suffit d'ajouter quatre zéros.

Après optimisation, la vitesse de pré-remplissage stable du noyau AITER MLA atteint environ 13 000 tokens/s, tandis que l'ancien chemin de repli Triton n'était que de 4 000 à 7 000 tokens/s, 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 considérablement le temps d'attente de l'utilisateur pour voir le premier caractère apparaître.

Cela montre également que l'écart logiciel apparemment important entre AMD et NVIDIA n'est parfois pas dû à un manque de capacité sous-jacente, mais simplement au fait que les noyaux rapides existants ne couvrent pas encore certaines nouvelles formes de modèles.

Un seul test ne prouve évidemment pas qu'AMD a rattrapé NVIDIA dans son ensemble.

B200 est contraint de s'exécuter sur plusieurs nœuds en raison d'une mémoire vidéo insuffisante ; les performances absolues du B300 restent en tête ; la chaîne d'outils, le support des frameworks et l'écosystème développeur ROCm sont toujours inférieurs à ceux de CUDA.

Mais les modèles ouverts entrent rapidement dans l'ère des mille milliards de paramètres. Lorsque les modèles deviennent trop grands pour tenir sur un seul serveur, la capacité de mémoire vidéo ne reste plus simplement un chiffre sur une table de paramètres, mais influence directement le coût de communication, la complexité du déploiement et le débit final.

La stratégie d'AMD consistant à fournir plus de HBM par carte graphique devient un avantage système réel.

Si AMD parvient à améliorer la stabilité de ROCm, à élargir la prise en charge des formes de cœurs haute vitesse et à offrir une compatibilité plus rapide dès le jour de la sortie pour les nouveaux modèles, alors les centres de données devront sérieusement envisager ces GPU. Moins chers, avec une mémoire plus importante, des performances suffisantes et un logiciel qui ne nécessite plus des mois d’ajustements.

Que pensez-vous de cela ?

Lien de référence :

https://x.com/wafer_ai/status/2083628389903315406

https://x.com/ChiragAsarpota/status/2083864019870634151

Cet article provient du compte officiel WeChat « Machine Heart » (ID : almosthuman2014), auteur :關注LLM的