Les performances par dollar deviennent plus rapides et moins chères

• Alors que la demande d’inférence dépasse l’offre et que les coûts des GPU NVIDIA et des tokens augmentent, l’AMD MI355X s’impose comme une alternative d’inférence à bas coût, avec un prix moyen par GPU environ 2,75 fois inférieur à celui du B300
• La gamme AMD Instinct MI350 rivalise avec Blackwell au niveau du silicium, mais l’avantage logiciel de NVIDIA et sa prise en charge day-0 déterminent la vitesse réelle de serving et la difficulté d’adoption
• Wafer a optimisé GLM-5.2 sur MI355X et atteint 2626 tok/s/node et 2,4 rps sur une charge de travail avec 20k tokens d’entrée/1k token de sortie et 60 % de taux de hit du cache, soit 80 % des performances mesurées sur B200
• En flux unique, il a enregistré 213 tok/s avec 10k tokens d’entrée/1,5k tokens de sortie ; ce n’est pas le sommet du leaderboard, mais il estime avoir l’avantage en coût par performance
• Ce résultat a été obtenu sans kernel custom, grâce à des corrections de bugs du framework, à la quantification, au speculative decode et au réglage du choix des kernels MoE ; pour AMD, le défi devient donc de plus en plus un problème de support plutôt qu’un problème purement logiciel

---

Coûts d’inférence AMD et écart logiciel avec NVIDIA

• La demande d’inférence croît rapidement et dépasse l’offre ; avec l’arrivée de modèles de pointe comme Claude Fable, GLM-5.2 et Minimax M3 presque toutes les deux semaines, la demande en tokens augmente aussi
• L’offre de Blackwell n’étant pas suffisante, les prix des GPU NVIDIA et les coûts des tokens suivent une tendance à la hausse
• L’AMD MI355X coûte en moyenne environ 2,75 fois moins cher par GPU que le B300, avec des caractéristiques matérielles comparables
• La gamme AMD Instinct MI350 rivalise avec Blackwell au niveau du silicium, mais NVIDIA peut servir l’inférence des modèles les plus récents plus vite et avec moins de friction grâce à sa prise en charge day-0 et à son écosystème logiciel
• Sur MI355X et la stack ROCm, il arrive souvent que les performances SOTA des modèles de pointe récents ne soient pas disponibles par défaut, et il peut même être difficile de trouver une image exécutable
• Sans prise en charge day-0, construire et optimiser les modèles les plus récents nécessite des semaines d’ingénierie et de calcul ; entre-temps, de nouveaux modèles sortent, ce qui place AMD dans une position permanente de rattrapage

Performances de GLM-5.2 sur MI355X

• Wafer estime que l’écart pratique entre AMD et NVIDIA se réduit à mesure que les agents améliorent les optimisations des kernels et des modèles
• Sur une charge de travail avec 20k tokens d’entrée/1k token de sortie et 60 % de taux de hit du cache, 2626 tok/s/node ont été atteints
  • Le RPS soutenu est de 2,4 rps
  • Le knee défini correspond à un TTFT de 5 secondes ou moins
  • Cela représente 80 % des performances mesurées sur B200
  • Le MI355X est plus de deux fois moins cher

RPS soutenu	tok/s/node agrégés	TTFT p50 / p95	Taux de réussite
0.5	449	0.59s / 0.60s	100%
1.0	974	0.60s / 0.81s	100%
1.5	1913	0.62s / 1.03s	100%
2.0	1944	0.62s / 1.05s	100%
2.25	2089	0.63s / 1.23s	100%
2.4 saturation	2626	0.81s / 2.22s	100%

• Selon la méthodologie d’Artificial Analysis, GLM-5.2 atteint 213 tok/s en flux unique avec 10k tokens d’entrée/1,5k tokens de sortie
• Ce chiffre n’est pas en tête du leaderboard d’Artificial Analysis, mais Wafer estime qu’il est avantageux en coût par performance
• Le test a été servi sur de la capacité AMD MI355X de TensorWave

Quantification et choix du framework d’inférence

• La première étape a consisté à choisir la quantification et le framework ; Wafer a quantifié GLM-5.2 en bf16 en MXFP4 avec AMD Quark
• Comparé à la quantification FP8 officielle de z-ai, MXFP4 est évalué comme pratiquement sans perte sur GPQA-Diamond, tau2 et GSM8K

Évaluation	Référence FP8	MXFP4	Δ
GSM8K, 200 questions, 5-shot, greedy	0.965 ± 0.013	0.955 ± 0.014	−0.010
GPQA-Diamond, 198 questions × 2 seeds, temp 1.0	0.9217 ± 0.027	0.9026 ± 0.029	−0.019
tau2 macro	0.819	0.834	+0.015

• Les trois frameworks d’inférence candidats étaient vLLM, ATOM et sglang
  • vLLM ne parvient pas à faire fonctionner le chemin MXFP4 + GlmMoeDsa, et ne peut donc pas tirer parti des poids MXFP4
  • ATOM dégrade la qualité de sortie sur les longs contextes
  • sglang présente le moins de friction jusqu’au support natif, tout en utilisant la quantification et en maintenant des sorties cohérentes

Deux problèmes qui bloquaient le speculative decode

• Pour améliorer le débit, Wafer a tenté d’activer le speculative decode dans sglang, mais l’image ROCm de sglang ne le prenait pas en charge par défaut
• Pour que MTP fonctionne correctement, deux correctifs étaient nécessaires
• Le premier problème venait du fait que le shared expert du MTP head est stocké en bf16, mais que la recherche de quantification de sglang tentait de le construire en MXFP4 à cause d’une incohérence de préfixe de module
  • Quark nomme le shared expert bf16 model.layers.78.mlp.shared_experts.*
  • Le préfixe réel de la couche MTP est model.decoder.*
  • À cause de cette incohérence, au chargement, le système essayait de lire des poids bf16 pleine largeur dans des slots 4-bit demi-largeur, ce qui faisait échouer l’initialisation avec un shape mismatch
  • Wafer a copié une seconde fois les entrées de la couche 78 sous les noms decoder réellement utilisés par sglang, ce qui a débloqué le speculative decode et presque triplé le débit en flux unique
• Le second problème était que le speculative decode profond, comme la configuration 5/1/6 proposée par z-ai, était bloqué
  • Le kernel fused multi-step metadata requis pour un draft depth de 4 ou plus écrivait #include <cuda_runtime.h> sans guard ROCm
  • Un simple guard #ifdef USE_ROCM a permis de corriger cela
• Une fois le speculative decode opérationnel, des optimisations de configuration comme --kv-cache-dtype fp8_e4m3 et --enable-aiter-allreduce-fusion ont permis d’atteindre 213 tok/s en décodage flux unique

Goulot d’étranglement du débit agrégé et réglage MoE

• Pour la charge de travail définie, l’optimisation du décodage seule ne suffisait pas ; avec 20k tokens d’entrée et 60 % de cache, le principal goulot d’étranglement était le prefill
• Dans une configuration TP8 adaptée au décodage en flux unique, le MI355X exécute GLM-5.2-MXFP4 à 1461 tok/s/node
• En passant à TP4×DP2, la même charge de travail atteint 1944 tok/s/node et 2,0 RPS
• Toutefois, les performances Blackwell mesurées par Wafer étaient de 3192 tok/s/node à 3,0 RPS, et les performances de prefill du MI355X étaient relativement plus lentes
• L’une des principales raisons était que, dans l’image sglang, le MoE fp4 de GLM-5.2 basculait silencieusement vers un fallback heuristique FlyDSL plus lent
  • aiter ne fournit des configurations réglées que pour les chemins a8w8/fp8
  • Wafer a réglé directement la sélection des kernels MoE pour l’adapter aux shapes fp4 de GLM
  • Les shapes cibles étaient model_dim 6144, moe_inter 2048, E=256, topk=8
• Ce réglage a porté le débit agrégé à 2626 tok/s/node et 2,4 RPS

Ce qu’il faut pour obtenir des performances SOTA sur AMD

• Le processus pour atteindre le meilleur coût par performance sur MI355X comportait une certaine friction, mais il n’a pas été jugé particulièrement difficile
• Contrairement au travail sur Qwen3.5 397B, aucun kernel custom n’a été écrit cette fois
• Cette étude ne prend pas en compte les performances multi-nœuds, mais les déploiements mono-nœud restent largement utilisés en environnement réel
• Obtenir des performances SOTA sur AMD devient de plus en plus un problème de support plutôt qu’un problème logiciel en soi
• La conclusion est que le moat CUDA s’affaiblit en temps réel

[GN⁺]

Avis Hacker News

• J’aimerais que ce genre de comparaison inclue aussi la performance par watt comme métrique. Je voudrais savoir où se situe AMD en coût rapporté aux performances réelles.
  Quand on parle avec des entreprises qui veulent construire des datacenters hors des États-Unis, elles disent qu’il est difficile d’obtenir des volumes suffisants de matériel Nvidia.
  Si AMD est compétitif en performance par watt et que le support logiciel est globalement fiable, c’est assez important, car l’électricité est souvent relativement plus chère hors des États-Unis.
  Si cela permet de construire de petits datacenters à un prix raisonnable, AMD pourrait devenir une partie de la stack dans les régions où l’approvisionnement en Nvidia est limité.
  Cela dit, je ne sais pas vraiment ce qu’il en est de l’approvisionnement en GPU AMD, et à part Wafer aux États-Unis et quelques entreprises, j’ai rarement vu des sociétés utiliser AMD ; peut-être que je suis simplement enfermé dans la bulle Nvidia.

  • Le DGX B200 coûte environ 500 000 dollars et consomme autour de 14 kW.
    En supposant qu’il tourne à 100 % pendant 8 ans, cela représente environ 1 GWh ; même dans un pays où l’électricité est chère comme l’Allemagne, on est autour de 100 000 euros, ce qui n’est pas énorme sur 8 ans comparé au coût initial de 500 000 dollars de l’équipement.
    Le vrai problème d’une forte consommation n’est pas tant la facture d’électricité que la limite d’alimentation électrique qu’on peut amener dans un datacenter. Une configuration plus efficace signifie qu’on peut mettre plus de machines dans la même capacité électrique disponible.
  • Quelques acteurs utilisent AMD, et davantage ont commencé des expérimentations. Mais AMD a déçu pendant longtemps dans ce domaine, donc je resterais prudent avant d’être optimiste sur l’arrivée enfin d’une vraie concurrence.
    Le marché a vraiment besoin d’un concurrent sérieux à Nvidia, en particulier sur la performance/watt.
  • Meta utilise AMD : https://www.amd.com/en/newsroom/press-releases/2026-2-24-amd...
    OpenAI aussi : https://www.amd.com/en/newsroom/press-releases/2025-10-6-amd...
  • Il vaut aussi la peine de rappeler qu’AMD domine de fait le matériel des consoles de jeux vidéo depuis de nombreuses années. Et rien n’indique que cela va s’arrêter prochainement.
  • En général, si une entreprise ne parvient pas à obtenir toutes les commandes qu’elle voudrait chez Nvidia, elle possède au moins quelques GPU AMD.

• C’est impressionnant, mais en usage réel, la quantification FP4 est rarement pratiquement sans perte. Beaucoup de fournisseurs mettent en avant des débits élevés en tokens par seconde avec Kimi et GLM, mais le modèle se retrouve fonctionnellement bridé et n’est plus vraiment proche de la qualité de pointe.
  J’aimerais que ce ne soit pas vrai.

  • Kimi utilise INT4 comme format de base ; pour ce modèle, la notion de « mieux qu’une précision 4 bits » n’existe donc pas vraiment.
    C’est différent de GLM, dont la précision de base est 16 bits, avec le 8 bits également couramment utilisé.
  • Le MI355X peut exécuter des opérations FP6 à la même vitesse que FP4. C’est une particularité d’AMD.
    Les gens devraient donc créer une quantification MXFP6, qui serait presque sans perte et beaucoup plus proche des performances FP4 que FP8.
  • Nvidia ne prétend-il pas aussi que NVFP4 est sans perte ?
    Je n’ai pas beaucoup testé les modèles convertis par Nvidia en NVFP4, à part GLM 5.2, mais cela m’a semblé correct.
    D’après mes essais, les résultats variaient beaucoup selon le modèle.
  • C’est aussi la première chose qui m’a sauté aux yeux.
  • De mémoire, c’était quelque chose comme 96 à 98 % de la précision.

• Je pensais qu’il allait être question d’une trajectoire d’amélioration vers quelque chose de plus rapide et moins cher, mais dans cet article il semble que la version quantifiée soit proposée au même prix que la version complète, tandis que la version rapide est vendue beaucoup plus cher.

• N’est-ce pas presque évident ? La performance par dollar devrait s’améliorer dans un seul sens, comme un cliquet. Comment un produit plus cher pourrait-il remplacer un produit moins cher ?

• À mon avis, il devrait être illégal de publier ce genre de titre sans préciser la méthode de quantification.

  • C’est du MXFP4.
  • J’aimerais aussi qu’on interdise les titres avec « Why this matters ».
  • Un bon filtre consiste à vérifier si le domaine se termine par .ai. Si c’est le cas, il y a de fortes chances que ce soit un contenu à faible effort, putaclic, superficiel, inutile ou trompeur.

• Le calcul en mémoire et les paradigmes neuromorphiques pourraient pousser cette tendance beaucoup plus loin au cours de la prochaine décennie.
  À mesure que des améliorations plus radicales sortiront des laboratoires, elles finiront par intégrer de nouveaux matériaux et des nano-dispositifs, et l’efficacité pourrait progresser de plusieurs ordres de grandeur.
  Il existe déjà une marge de progression rien qu’en faisant monter en puissance des technologies existantes comme la MRAM.

• Le passage de fp8 à mxfp4 entraîne une baisse de précision perceptible.

  • Wafer a arrêté son propre forfait phare de codage, Wafer Pass, quelques semaines seulement après son lancement, et a même dû procéder à des remboursements au prorata.
    Et malgré cela, ils se vantent d’avoir encore réduit les coûts par quantification alors que l’implémentation est manifestement insuffisante.
    [1] https://www.ycombinator.com/launches/Q9i-wafer-pass-flat-rat...
  • Et pourtant, ils ont quand même réussi à affirmer que c’était « sans perte ».

• Ce n’est pas un phénomène nouveau. La performance par dollar s’améliore de façon exponentielle assez régulière depuis environ 1900.
  1900–2010 : https://www.thekurzweillibrary.com/exponential-growth-of-com...
  1939–2023 : https://medium.com/@timventura/kurzweils-law-for-the-ai-age-...

• Il n’est pas surprenant que cela rivalise avec Blackwell. Rubin est 5 fois plus rapide que Blackwell en inférence, et Blackwell est la dernière génération que Nvidia n’a pas optimisée spécifiquement pour l’inférence.
  Si quelque chose m’échappe, dites-le-moi.

  • On ne voit vraiment pas clairement ce qui, dans Rubin, serait spécialement optimisé pour l’inférence.
    On voit bien une configuration désagrégée qui sépare les nœuds de prefill et de décodage, mais à part ça, je ne sais pas ce qu’il y a.
  • Si l’inférence est limitée par la bande passante mémoire, comment peut-on la rendre 5 fois plus rapide ? Obtenir 5 fois la bande passante mémoire du H100 semble physiquement difficile.

• Surtout dans un contexte où plusieurs monnaies s’affaiblissent.