Kimi K3 a fait sensation sur Hacker News après que MI355X a devancé B300 en performances par dollar

Kimi K3 a fait sensation sur Hacker News après que Wafer a indiqué que huit GPU AMD MI355X servaient le modèle à environ 952 tokens de sortie par seconde. Le système restait derrière un nœud Nvidia B300 à huit GPU en débit global. Toutefois, les hypothèses de location de Wafer donnaient à AMD un meilleur rapport performances-prix.

Cette distinction importe, car Kimi K3 est particulièrement exigeant. Le modèle à poids ouverts de Moonshot AI compte environ 2,8 billions de paramètres, dont quelque 104 milliards sont activés pour chaque token. Son checkpoint occupe plus de 1,5 téraoctet avant même que le système de serving ne réserve de la mémoire pour l’état d’exécution et les longs prompts.

Un nœud B200 standard à huit GPU ne peut pas accueillir confortablement ce déploiement dans cette configuration. Wafer a donc comparé un nœud MI355X avec un nœud B300 et une configuration B200 à deux nœuds. Le résultat remet en cause l’avantage de Nvidia sous un angle étroit mais commercialement important : quelle plateforme fournit une inférence Kimi K3 acceptable au coût d’infrastructure le plus bas ?

L’affirmation sur Hacker News porte sur l’économie, pas sur une victoire absolue en vitesse

Wafer n’a pas indiqué que MI355X était plus rapide que B300. L’entreprise a indiqué que MI355X produisait davantage de débit pour chaque unité de dépense horaire d’infrastructure.

La nuance est facile à perdre dans un titre. Selon le billet de benchmark de Wafer, son nœud MI355X à huit GPU a atteint 952 tokens de sortie agrégés par seconde. Le même test a enregistré 1 568 tokens par seconde avec une configuration B300 à huit GPU.

Cela donne à Nvidia un avantage substantiel en débit brut. Le nœud B300 a également délivré 172 tokens par seconde sur un flux unique, contre 118 pour MI355X. Un acheteur optimisant exclusivement la sortie maximale d’un seul nœud privilégierait donc toujours B300 selon ces résultats.

Wafer est arrivé à une conclusion différente après avoir appliqué ses estimations de location horaire. Son calcul plaçait MI355X en tête en matière de débit agrégé par unité de dépense. L’entreprise a décrit l’accélérateur AMD comme le vainqueur du rapport performances-prix, et non comme le vainqueur des performances globales.

Le benchmark utilisait des prompts comprenant 1 024 tokens d’entrée et demandait 400 tokens de sortie. Cette charge de travail est utile, car elle reflète un comportement ordinaire de génération de texte sans devenir un test de résistance en contexte long. Elle ne représente pas toutes les charges de travail en production.

La comparaison avec B200 ajoute une autre dimension. Kimi K3 nécessitait 16 GPU B200 répartis sur deux nœuds dans la configuration de Wafer. Ce déploiement a produit 498 tokens agrégés par seconde, soit environ 249 par nœud.

La communication inter-nœuds a imposé une pénalité, car les GPU devaient coordonner l’exécution du modèle sur un réseau. Wafer a indiqué que cette connexion fonctionnait via RoCE v2, un protocole basé sur Ethernet permettant le transfert direct de données entre systèmes avec une faible implication du CPU.

Le résultat défavorable pour B200 reflète donc la topologie autant que le silicium. Le modèle ne tenait pas dans un seul nœud B200 à huit GPU avec l’allocation mémoire requise par Wafer. Sa répartition sur deux nœuds a introduit des communications dans le chemin de décodage.

Cette contrainte est au cœur de l’histoire. Kimi K3 transforme la capacité mémoire en avantage architectural avant même que l’optimisation logicielle ne commence. MI355X comme B300 fournissent 288 Go de mémoire à haute bande passante par GPU, ce qui rend viable un seul nœud à huit GPU.

La discussion sur Hacker News s’est concentrée sur la question de savoir si ce résultat affaiblit le fossé logiciel de Nvidia. Un benchmark unique réalisé par un fournisseur ne peut pas trancher cette question plus vaste. Il montre néanmoins que la capacité mémoire et l’économie de location peuvent supplanter les classements GPU conventionnels pour un modèle spécifique.

Il modifie également la manière dont les acheteurs devraient interpréter les comparaisons d’accélérateurs. Les performances arithmétiques de pointe comptent, mais elles ne sont qu’un élément parmi d’autres. La taille du modèle, la quantification, le placement mémoire, la prise en charge des frameworks, la concurrence, la latence, le réseau et le taux d’utilisation peuvent déterminer la facture réelle.

Pour Kimi K3, la première victoire revient à la plateforme capable d’héberger le modèle sans une répartition multi-nœuds maladroite. AMD franchit ce seuil avec un nœud MI355X. Nvidia le franchit avec B300, tandis que B200 devient moins attrayant pour cette configuration précise.

Le résultat est donc plus limité et plus utile qu’une déclaration générale selon laquelle AMD aurait rattrapé Nvidia. Il identifie une charge de travail où les choix de conception d’AMD deviennent financièrement significatifs.

Kimi K3 fait de la capacité mémoire la contrainte décisive

Kimi K3 fait de la mémoire d’accélérateur une exigence de déploiement, et non une spécification que les acheteurs peuvent traiter comme secondaire.

Moonshot AI décrit Kimi K3 comme un modèle mixture-of-experts de 2,8 billions de paramètres. Un modèle mixture-of-experts achemine chaque token à travers une partie seulement de son réseau, réduisant le calcul actif tout en conservant un pool beaucoup plus vaste de paramètres appris.

Le papier technique K3 indique que le modèle active environ 104 milliards de paramètres par token. Il sélectionne 16 experts routés dans un pool de 896. Cette parcimonie limite le calcul, mais elle n’élimine pas la nécessité de stocker l’ensemble des poids des experts.

Chaque requête peut router les tokens vers différents experts. Le système de serving doit donc maintenir le checkpoint plus large accessible à travers le groupe de GPU. Ce checkpoint crée l’exigence mémoire qui façonne la comparaison de Wafer.

Le propre guide de déploiement d’AMD estime la taille du checkpoint, en tenant compte du chargeur, à environ 1,56 To. Avec un parallélisme tensoriel à huit voies, chaque MI355X héberge environ 191 Gio de poids du modèle.

Le parallélisme tensoriel répartit les grandes opérations du modèle sur plusieurs GPU. Chaque accélérateur calcule une partie, puis échange des résultats intermédiaires avec ses pairs. Garder les huit GPU dans un seul serveur réduit généralement la pénalité de communication par rapport à une répartition sur plusieurs machines.

AMD estime que l’état d’exécution connu pour une séquence au contexte maximal du modèle ajoute environ 14,4 Gio par GPU. L’allocation connue combinée atteint environ 205,4 Gio, laissant environ 82,6 Gio sur chaque MI355X avant les autres surcoûts.

Cette mémoire restante doit absorber les buffers de communication, les espaces de travail temporaires, la fragmentation de l’allocateur, l’état du framework et les autres coûts de production. Elle peut également prendre en charge le batching, qui regroupe les requêtes afin que les GPU effectuent davantage de travail utile ensemble.

Moonshot attribue à Kimi K3 une fenêtre de contexte d’un million de tokens. Une fenêtre de contexte correspond à la quantité maximale de texte et d’autres entrées tokenisées que le modèle peut prendre en compte au cours d’une interaction. Prendre en charge ce maximum théorique nécessite plus de mémoire que de servir des prompts courts.

Kimi Delta Attention contribue à contenir cette croissance. Il utilise un état récurrent de taille fixe pour de nombreuses couches au lieu de maintenir partout un cache clé-valeur conventionnel. Un cache clé-valeur stocke les données d’attention antérieures afin que le modèle ne recalcule pas l’intégralité de la séquence pour chaque token généré.

Kimi K3 comprend toujours des couches qui maintiennent un état de cache dépendant des tokens. Les longs prompts continuent donc de consommer une quantité significative de mémoire. L’architecture réduit la charge sans rendre le contexte long gratuit.

MI355X d’AMD et B300 de Nvidia offrent tous deux 288 Go de HBM par GPU dans leurs plateformes standard à huit GPU. L’architecture B300 de Nvidia indique 2,3 To de mémoire à l’échelle du nœud, soit une capacité globale comparable à celle de la plateforme AMD.

B200 offre moins de mémoire par GPU. Huit appareils peuvent suffire à de nombreux modèles, mais Wafer affirme que cette configuration ne pouvait pas accueillir Kimi K3 avec le pool mémoire prévu pour les contextes longs. Passer à 16 GPU résout le problème de capacité tout en ajoutant des coûts de réseau et de la complexité opérationnelle.

C’est le renversement plus profond à l’origine de l’intérêt sur Hacker News. B200 de Nvidia reste un accélérateur haut de gamme, mais Kimi K3 peut rendre la topologie du système environnant plus importante que la position familière de la puce sur le marché.

Le même principe s’applique au-delà de ce modèle. Les modèles à poids ouverts permettent aux opérateurs de choisir leur propre matériel, framework de serving, quantification et ordonnanceur de requêtes. Les checkpoints plus grands rendent ces choix de plus en plus dépendants de la capacité mémoire.

Une entreprise qui prévoit des agents de codage internes, de l’analyse documentaire ou de l’automatisation de la recherche peut s’attendre à de longs prompts et à une génération soutenue. Ces équipes devraient modéliser la demande mémoire avant de comparer le débit des accélérateurs.

Maintenir une base de connaissances d’ingénierie consultable peut également faciliter la reproduction de ces évaluations. Les notes de configuration, résultats de profilage, changements de déploiement et rapports d’échec se dispersent autrement dans des documents locaux et des fils de discussion.

Kimi K3 ne prouve pas que la mémoire est le seul fossé défensif. Il montre que la mémoire peut déterminer quelles plateformes entrent dans la compétition.

Le décodage spéculatif a réduit une partie de l’écart logiciel d’AMD

Le résultat de MI355X dépendait de corrections logicielles et d’optimisations de serving, même si Wafer n’a pas eu besoin d’écrire un nouveau kernel GPU pour sa principale amélioration de décodage.

Wafer est parti de la prise en charge de Kimi K3 par AMD dès le premier jour. Cette base chargeait déjà le modèle sur huit GPU MI355X et l’exposait via un serveur d’inférence compatible. Passer d’un déploiement fonctionnel à un débit compétitif nécessitait encore un travail d’ingénierie.

La plus grande amélioration du décodage est venue du décodage spéculatif. Cette technique utilise un modèle de brouillon plus petit pour prédire plusieurs tokens futurs. Le modèle principal vérifie ensuite ces candidats ensemble, réduisant le nombre d’étapes coûteuses de décodage séquentiel.

Kimi K3 n’était pas livré avec ses propres tenseurs de brouillon pour les méthodes spéculatives couramment intégrées aux modèles de pointe. Wafer a plutôt utilisé Kimi-K3-DSpark, un modèle de brouillon externe de diffusion par blocs publié par RadixArk.

La version CUDA aurait fonctionné sans la même interruption. Sur ROCm, la plateforme logicielle d’AMD pour le calcul GPU, la première requête de production a déclenché une erreur de fonction manquante dans le chemin de vérification des tokens de SGLang.

SGLang est un framework de serving open source qui planifie les requêtes de modèles, gère la mémoire et exécute des kernels optimisés. Sa version CUDA importait une fonction de renormalisation des probabilités top-k. La branche ROCm ne fournissait pas de définition équivalente pour le chemin testé.

L’échantillonnage top-k ne conserve que les candidats tokens les plus probables avant de sélectionner la sortie suivante. La renormalisation redimensionne leurs probabilités restantes afin que leur somme soit égale à un. L’opération manquante était mathématiquement simple, mais son absence faisait planter l’ordonnanceur de requêtes.

Wafer a implémenté l’opération avec des primitives PyTorch standard. La fonction triait les probabilités, conservait les candidats les mieux classés, masquait les autres et redimensionnait les valeurs restantes.

Cette correction aurait augmenté les performances sur un flux unique d’environ 2,2 fois. À charge modérée, les performances par flux se seraient améliorées d’environ 1,7 fois. Le débit agrégé de pointe a augmenté de 18 %.

Ces gains illustrent pourquoi les spécifications matérielles ne prédisent pas directement l’inférence en production. L’accélérateur exécute les opérations, mais la pile de serving décide si les requêtes atteignent des chemins de code efficaces.

La plateforme CUDA de Nvidia bénéficie de plusieurs années d’intégration aux frameworks et d’attention de la part des développeurs. Les nouvelles techniques d’inférence y apparaissent souvent en premier. Les bugs y sont davantage exposés, tandis que les bibliothèques ont tendance à supposer le comportement de CUDA avant d’ajouter d’autres backends.

AMD a investi massivement dans ROCm et ses bibliothèques associées. Le déploiement de Kimi K3 montre des progrès, car la fonctionnalité manquante nécessitait une correction logicielle ciblée plutôt que des mois de travail sur des kernels bas niveau.

Pour autant, le bug reste important. Un chemin de requête qui plante sous un trafic réel n’est pas un simple désagrément esthétique. Il représente un risque en matière de tests, de maintenance et d’exploitation que les équipes d’infrastructure doivent intégrer dans leurs décisions de déploiement.

Le résultat de Wafer dépendait également d’un niveau élevé de concurrence. La concurrence mesure le nombre de séquences que le serveur traite simultanément. Un plus grand nombre de requêtes concurrentes peut augmenter le débit total en occupant l’accélérateur avec du travail utile.

Le décodage spéculatif a déplacé le débit maximal du système vers un réglage de concurrence plus élevé. Ce résultat convient à un service partagé recevant de nombreuses requêtes. Il peut être moins pertinent pour une application qui doit fournir immédiatement une réponse unique.

Cette différence distingue le débit agrégé de l’interactivité. Le débit agrégé mesure le nombre total de tokens produits pour l’ensemble des utilisateurs. L’interactivité mesure la vitesse de progression de chaque flux individuel.

Le résultat agrégé de 952 tokens du nœud MI355X est précieux pour un service très sollicité. Ses 118 tokens sur un flux unique racontent une autre histoire. B300 est resté plus rapide pour un flux unique comme pour le nœud dans son ensemble.

Le mécanisme conduit donc à une conclusion pratique, et non universelle. Le matériel AMD a offert une économie favorable après que Wafer a comblé une lacune du framework et configuré le décodage spéculatif autour d’un modèle de brouillon externe.

Les autres équipes doivent déterminer si elles peuvent reproduire cette pile. Elles ont besoin de versions de framework compatibles, de la même représentation du modèle, d’un comportement d’échantillonnage stable et d’un volume de requêtes suffisant.

Elles ont également besoin d’ingénieurs capables de diagnostiquer des défaillances propres à un backend. Une fonction manquante peut être facile à corriger une fois identifiée. Découvrir la défaillance précise sous charge de production peut prendre bien plus de temps.

C’est pourquoi l’affirmation de Hacker News ne doit pas être réduite à un score matériel. Elle montre que le désavantage logiciel d’AMD peut parfois être circonscrit et corrigé. Elle ne montre pas que ce désavantage a disparu.

B300 reste en tête là où la latence et la densité comptent le plus

Nvidia’s B300 est resté le choix le plus solide lorsque l’objectif passait de l’efficacité de l’infrastructure au débit maximal ou au temps d’attente minimal.

Wafer a mesuré 1 568 tokens de sortie agrégés par seconde pour le nœud B300. C’était environ 65 % de plus que le résultat de 952 tokens du nœud MI355X dans la configuration testée.

Le B300 a également atteint 172 tokens par seconde sur un flux unique. Le MI355X a atteint 118. Pour le codage interactif, les agents en direct ou le chat destiné aux clients, cette différence peut influencer la réactivité perçue du produit.

La comparaison devient plus difficile pendant le préremplissage. Le préremplissage est la phase durant laquelle le modèle traite le prompt existant de l’utilisateur avant de générer son premier token de sortie. Les longs documents et les grands dépôts de code rendent cette étape particulièrement importante.

Wafer a testé un prompt à froid identique contenant environ 172 000 tokens. La configuration MI355X a initialement nécessité environ 51 secondes pour le traiter, contre environ 23 secondes sur B300.

Cet écart dépasse la différence observée durant le décodage ordinaire. Un utilisateur peut accepter un flux légèrement plus lent une fois que le texte commence à s’afficher. Attendre beaucoup plus longtemps avant le premier token peut donner l’impression qu’une application est bloquée.

Wafer a attribué l’essentiel de l’écart de préremplissage d’AMD à un repli vers un kernel d’attention. Kimi K3 attribuait 12 têtes d’attention à chaque GPU dans un parallélisme tensoriel à huit voies. Le kernel AITER plus rapide d’AMD prenait en charge d’autres formes de nombre de têtes, de sorte que le framework a sélectionné du code Triton générique plus lent.

AITER est la bibliothèque d’opérateurs IA optimisés d’AMD. Triton est un langage et un compilateur utilisés pour écrire des kernels GPU portables. Un chemin Triton générique peut simplifier la compatibilité, mais il peut ne pas égaler une implémentation en assembleur spécifique au matériel.

Wafer a complété l’entrée à 12 têtes jusqu’à 16 têtes, exécuté le kernel optimisé, puis supprimé les sorties artificielles. Cet ajustement de forme aurait porté le débit de préremplissage en régime établi à environ 13 000 tokens par seconde.

Le repli précédent se situait entre environ 4 000 et 7 000 tokens par seconde. Wafer a décrit la correction comme une amélioration du préremplissage de deux à trois fois.

Fait important, cette optimisation n’a pas augmenté le résultat phare du décodage. Elle ciblait le temps jusqu’au premier token, ou TTFT, qui mesure combien de temps les utilisateurs attendent avant le début de la génération.

Cet épisode montre les deux facettes de la position d’AMD. Le matériel disposait d’un kernel efficace capable de performances bien supérieures. Le framework n’a pas réussi à le sélectionner parce que Kimi K3 produisait une forme non prise en charge.

Nvidia bénéficie lorsque ces incompatibilités ont déjà été anticipées dans les bibliothèques CUDA. AMD en bénéficie lorsque les développeurs peuvent adapter des kernels existants sans en concevoir de nouveaux. Les acheteurs doivent décider quelle quantité de travail d’intégration ils peuvent tolérer.

B300 offre également de meilleures performances agrégées par GPU dans le test de Wafer. Cette densité peut compter là où l’espace en baie, l’alimentation électrique, les ports réseau ou la disponibilité des centres de données contraignent le déploiement.

Un GPU moins coûteux n’est pas automatiquement moins cher au niveau du service. Les opérateurs doivent inclure l’utilisation des serveurs, l’énergie, le réseau, le temps d’ingénierie, la capacité de réserve, la reprise après défaillance et la maintenance logicielle.

Si un nœud B300 peut absorber un trafic qui exige davantage de nœuds AMD, l’infrastructure environnante peut réduire l’avantage initial de performances par dollar. À l’inverse, une application aux exigences de latence modérées peut réaliser davantage d’économies en acceptant le pic inférieur d’AMD.

La bonne comparaison est un objectif de niveau de service, et non un slogan au niveau de la puce. Un objectif de niveau de service définit la latence, la disponibilité et le débit qu’un système doit fournir de manière constante.

Les équipes devraient comparer les deux plateformes avec le même niveau d’interactivité visé. Elles devraient également mesurer des longueurs de prompt, des longueurs de sortie, un comportement de cache, une concurrence, une quantification et des attentes de disponibilité identiques.

Un benchmark optimisé indépendamment sur chaque plateforme peut répondre à la question de savoir quel système fonctionne le mieux après un réglage expert. Un benchmark utilisant un logiciel identique peut répondre à la question de la portabilité de la pile. Ce sont deux questions différentes.

Le test de Wafer s’oriente vers la première. Il a réglé le chemin MI355X et comparé le service obtenu à ses déploiements Nvidia. Cela reflète la façon dont un opérateur pourrait rechercher la meilleure économie disponible, mais complique une attribution architecturale stricte.

B300 reste la plateforme la plus rapide dans les chiffres publiés. MI355X mérite l’attention parce que l’hypothèse de location plus basse compense largement cette différence sous la charge de travail choisie par Wafer.

C’est un résultat concurrentiel significatif. Ce n’est pas un transfert de la couronne de performance de Nvidia.

Ce que le benchmark ne permet pas d’établir

Les résultats publiés restent un instantané produit par une entreprise, avec des détails méthodologiques limités et aucune reproduction indépendante associée à l’affirmation principale.

Wafer développe des produits d’optimisation GPU et d’inférence. L’entreprise propose également un accès aux modèles hébergés. Elle possède une expertise manifeste, mais a un intérêt commercial à montrer que le travail logiciel peut ouvrir des alternatives à Nvidia.

Cela n’invalide pas le benchmark. Cela signifie que les lecteurs doivent considérer les mesures comme des résultats rapportés par l’opérateur, plutôt que comme une certification sectorielle neutre.

L’article de benchmark identifie la longueur du prompt, la sortie demandée, les configurations matérielles, le débit et certains travaux d’optimisation. Il ne fournit pas de dossier complet de reproductibilité dans l’article.

Des détails importants restent flous. L’article ne précise pas entièrement chaque révision logicielle, la procédure de préchauffage, la distribution des requêtes, la durée de mesure, l’étape de vérification des sorties ou la mesure de la consommation électrique.

La configuration B300 utilisait également un traitement du contexte désagrégé, selon le libellé comparatif de Wafer. La désagrégation sépare le traitement du prompt de la génération de tokens afin que chaque étape puisse utiliser des ressources adaptées. Cela peut affecter à la fois les performances et la conception du système.

L’entrée MI355X utilisait un parallélisme tensoriel à huit voies. Le déploiement B200 utilisait 16 GPU répartis sur deux nœuds. L’entrée B300 combinait le parallélisme tensoriel à huit voies avec le traitement désagrégé.

Il s’agit de déploiements pratiques, mais pas de configurations parfaitement symétriques. Chaque plateforme a rencontré des contraintes de mémoire et de topologie différentes. Cette asymétrie est en partie le sujet même de la comparaison, mais elle limite les conclusions sur la seule architecture des puces.

Le résultat de performances par dollar dépend également des hypothèses de location. Les marchés des GPU varient selon les fournisseurs cloud, les durées de contrat, les régions, la disponibilité et les modèles de réservation. Un acheteur disposant de capacité Nvidia à tarif réduit peut parvenir à une conclusion différente.

Les règles de rédaction partagées empêchent d’indiquer ici des prix commerciaux précis. Le fait important est que Wafer a supposé que la capacité MI355X coûtait sensiblement moins par heure de GPU que B300. Son verdict économique découle directement de cette hypothèse.

La disponibilité compte également. Un accélérateur théoriquement attractif ne procure aucune économie si une équipe ne peut pas réserver suffisamment de nœuds dans la région requise. La présence cloud plus large de Nvidia peut réduire les frictions d’approvisionnement.

Le comportement du modèle présente une autre incertitude. Le décodage spéculatif accélère la génération uniquement lorsque le modèle de brouillon prédit des tokens que le modèle principal accepte. Les taux d’acceptation peuvent varier selon le code, la prose, les mathématiques, les langues et les réglages d’échantillonnage.

Le benchmark de Wafer sur des entrées courtes peut donc produire des gains différents de ceux d’un agent traitant un grand dépôt. La recherche à long contexte, l’assistance client et l’extraction par lots peuvent chacun déplacer l’équilibre entre préremplissage et décodage.

Le modèle lui-même est également nouveau. Moonshot a publié les poids de Kimi K3 le 27 juillet 2026, quelques jours seulement avant que Wafer publie ses mesures du 31 juillet. Les frameworks, les quantifications et les kernels optimisés en sont encore à un stade précoce.

Le guide initial d’AMD était délibérément prudent. Il validait le chargement et la correction de base sur huit GPU MI355X, mais ne revendiquait pas un débit maximal, une latence par token ou une efficacité des kernels de pointe.

Wafer a apporté cette couche supplémentaire de travail sur les performances. Des équipes indépendantes devraient désormais reproduire le résultat avec des scripts ouverts et des cibles de service clairement définies.

La comparaison devrait également aller au-delà de B300. Les systèmes plus récents de Nvidia, les futurs accélérateurs AMD et le matériel d’inférence spécialisé modifieront les options disponibles. Les mises à jour logicielles peuvent changer le classement actuel sans remplacer aucune puce.

La qualité est également en jeu. Les formats de faible précision et les méthodes spéculatives devraient préserver le comportement des sorties dans des tolérances définies. Un résultat de vitesse nécessite des vérifications de correction, en particulier lorsque des changements d’échantillonnage peuvent masquer des différences subtiles.

Le modèle de Moonshot utilise des représentations mixtes de faible précision afin de réduire les besoins en mémoire et en calcul. Ces choix font partie de son architecture prévue. Les implémentations doivent néanmoins confirmer que chaque backend produit des résultats acceptables sur des tâches représentatives.

L’interprétation la plus défendable est conditionnelle : pour la charge de travail, la pile logicielle et les hypothèses de location de Wafer, MI355X a fourni le meilleur résultat de performances par dollar.

L’interprétation la moins défendable est qu’AMD a largement vaincu Nvidia dans l’inférence IA. Les éléments publiés ne permettent pas d’étayer cette conclusion.

Trois signaux détermineront si AMD peut reproduire cette victoire

Le résultat d’AMD avec Kimi K3 ne devient stratégiquement important que s’il résiste à des tests indépendants, à des charges de travail plus variées et aux mises à jour courantes des frameworks.

Le premier signal est la reproductibilité. Des opérateurs indépendants devraient exécuter Kimi K3 sur MI355X et B300 avec des configurations publiées, des prompts identiques, des sorties vérifiées et des objectifs de latence équivalents.

Un avantage répété de performances par dollar renforcerait l’affirmation de Wafer. De grands écarts entre les équipes suggéreraient que le résultat dépend fortement d’un réglage spécialisé ou de conditions d’infrastructure favorables.

La reproduction devrait couvrir davantage que le seul débit agrégé maximal. Les tests doivent mesurer le délai avant le premier token, la vitesse de décodage par utilisateur, la concurrence soutenue, les taux d’erreur, l’utilisation de la mémoire, la consommation électrique et la stabilité sur de longues durées.

Ils devraient également présenter le modèle de coûts complet, sans supposer qu’un instantané de location publique représente tous les acheteurs. Les capacités contractualisées et les infrastructures détenues en propre peuvent modifier le calcul.

Le deuxième signal à surveiller est l’intégration des améliorations ROCm dans les frameworks de serving standard. La correction top-k et le chemin de prefill avec padding de Wafer ont résolu des problèmes concrets, mais les correctifs privés créent des obligations de maintenance.

Si SGLang, AITER, vLLM et les projets associés intègrent des correctifs comparables, davantage d’équipes pourront reproduire le résultat sans maintenir de branches personnalisées. Cela transformerait l’expertise d’un opérateur en un gain pour l’ensemble de l’écosystème.

Une prise en charge rapide en amont réduirait aussi le risque qu’une mise à jour du framework casse un chemin optimisé. Les acheteurs d’infrastructure valorisent la reproductibilité, car les systèmes de production vivent bien plus longtemps que les campagnes de benchmarks.

Si les correctifs restent fragmentés, l’avantage logiciel de Nvidia demeure intact, même lorsque le matériel AMD paraît favorable. Le fossé défensif de CUDA comprend la documentation, les outils de débogage, la couverture des bibliothèques, les développeurs expérimentés et le comportement prévisible des frameworks.

Le troisième signal est la performance sur des charges de travail proches de la production. Le contexte d’un million de tokens de Kimi K3 ouvre la voie à des tâches impliquant de grands dépôts, des collections de documents, des historiques de recherche et de longues sessions d’agents.

Ces charges de travail renforcent l’importance du prefill, de la gestion du cache, de l’ordonnancement des requêtes et de la fragmentation mémoire. Wafer a déjà montré que le résultat initial d’AMD en cold-prefill était inférieur à celui du B300 avant l’activation d’un chemin de kernel optimisé.

Une victoire plus large exigerait que le MI355X reste compétitif sur les courts prompts conversationnels, les longs documents, les agents de code, les entrées multimodales et le trafic mixte. Il doit aussi maintenir une latence acceptable tandis que le nœud gère de nombreux utilisateurs.

Si AMD affiche de bonnes performances dans l’ensemble de ces conditions, les acheteurs de matériel disposeront d’un levier important. Ils pourront négocier face à une seconde plateforme crédible et déployer de grands modèles à poids ouverts sans accepter automatiquement une prime Nvidia.

Si l’avantage disparaît en dehors des tests de débit sur entrées courtes, le MI355X restera une option spécifique à certaines charges de travail. Cela peut toujours permettre des déploiements précieux, mais n’affaiblira pas fondamentalement la position de Nvidia.

La leçon plus large tirée de hacker news est que les modèles à poids ouverts transforment l’inférence en compétition de systèmes. Les développeurs de modèles définissent l’architecture, les fabricants de puces fournissent la mémoire et la puissance de calcul, tandis que les équipes de frameworks déterminent quelle part de cette capacité devient exploitable.

Kimi K3 intensifie cette compétition, car son checkpoint oblige les acheteurs à se confronter immédiatement aux limites de mémoire. Il favorise également les plateformes capables de prendre en charge le calcul en faible précision, le routage efficace des experts et un état de contexte étendu.

Les développeurs devraient suivre les dépôts de benchmarks et les notes de version des frameworks. Les équipes d’infrastructure devraient exécuter leurs propres traces de trafic au lieu de s’appuyer sur un seul chiffre de tokens par seconde.

Les acheteurs en entreprise devraient exiger des comparaisons à la latence requise par leurs applications. Ils devraient intégrer le travail d’ingénierie et le risque opérationnel aux hypothèses de location d’accélérateurs.

Les éléments actuels donnent à AMD un résultat crédible et à Nvidia un avertissement clair. Le B300 reste plus rapide, tandis que le MI355X offrirait, selon les informations disponibles, une meilleure économie pour le déploiement de Kimi K3 par Wafer.

La question suivante est de savoir si cet avantage deviendra courant. Suivez les benchmarks indépendants, la prise en charge logicielle en amont et les tests de production à long contexte avant de considérer un résultat de hacker news comme un changement durable.