La discussion sur l’infrastructure de l’intelligence artificielle s’éloigne de plus en plus du simple « rendement brut » pour se concentrer sur un aspect bien plus tangible : combien coûte le service de chaque token lorsque l’utilisateur exige des réponses rapides, à grande échelle, tout en conservant une bonne « sensation » d’interaction. Dans ce contexte, les modèles MoE (Mixture of Experts / Mélange d’Experts) poussent l’industrie vers un défi complexe : la communication entre nœuds et la latence interne deviennent presque aussi cruciaux que la puissance de calcul.
Dans cette optique, la société Signal65 a publié une analyse centrée sur ce qu’elle appelle « la nouvelle économie de l’inférence » pour les MoE, comparant les plateformes de NVIDIA et AMD avec une idée de base : le coût relatif par token dépend du coût de la plateforme et du nombre de tokens par seconde qu’elle délivre réellement pour un objectif d’interactivité précis. La conclusion — avec des nuances importantes — est frappante : dans une configuration orientée MoE, un rack NVIDIA GB200 NVL72 peut offrir jusqu’à 28× plus de débit par GPU que AMD MI355X à un niveau élevé d’interactivité (75 tokens/seconde/utilisateur), ce qui se traduit par jusqu’à 15× plus de « performance par dollar » à ce niveau.
Pourquoi les MoE changent la donne : le goulot d’étranglement n’est plus seulement la « computation »
Les MoE fonctionnent en activant dynamiquement des « experts » (sous-réseaux spécialisés), permettant une efficacité accrue par rapport aux modèles denses… mais à un prix : un échange massif de données. En pratique, lorsqu’on scale un MoE, apparaissent des schémas du type « all-to-all » qui pénalisent la latence et exercent une pression sur la bande passante interne. En termes simples : vous pouvez avoir des GPU ultra-rapides, mais si la coordination entre experts se grippe, l’expérience interactive s’en trouve grandement affectée.
C’est ici qu’NVIDIA mise sur le concept de rack-scale : une large capacité de calcul et de mémoire haute vitesse, conçue pour minimiser ces « tolls » lors du déplacement de données dans le système. Signal65 attribue une grande partie de l’avantage observé à cette architecture de « co-conception » (hardware + interconnexion + software) et à une configuration à grande échelle avec une mémoire partagée rapide.
Qu’est-ce qu’un GB200 NVL72 (en gros) et pourquoi cela compte-t-il ?
Le terme « NVL72 » est devenu une référence courante pour décrire des racks NVIDIA avec 72 accélérateurs reliés par une interconnexion interne très haute vitesse, conçus pour fonctionner comme un « super-nœud » pour l’IA. Dans le cas du GB200, cette famille est associée à la plateforme Grace-Blackwell ; dans la littérature spécialisée, il est décrit comme un système de rack combinant CPU Grace et GPU Blackwell dans une architecture à forte couplage.
L’idée derrière tout cela n’est pas nouvelle, mais l’exécution est extrême : dans les MoE, la valeur ne réside pas seulement dans le nombre de TFLOPS disponibles, mais dans le nombre de tokens utiles produits avec une latence acceptable, sans que le système ne passe son temps à « s’auto-parler ».
Ce que AMD propose avec le MI355X
De son côté, AMD mise sur la gamme Instinct avec un discours très pertinent dans le domaine de l’IA : mémoire et bande passante. Sur sa fiche officielle, AMD présente le MI355X comme un accélérateur basé sur sa 4e génération AMD CDNA, doté de 288 Go de HBM3E et pouvant atteindre 8 To/s de bande passante mémoire, entre autres caractéristiques orientées IA.
En clair : en termes de densité mémoire et de puissance pour des scénarios très exigeants, AMD propose un produit clairement agressif. La grande question est de savoir si, dans les MoE hautement interactifs et à grande échelle, l’avantage se déplace vers celui qui maîtrise le mieux le « réseau » du système.
Les chiffres de l’étude : coût par token et « performance par dollar »
Signal65 explique qu’ils s’appuient sur des mesures de performance tierces et qu’ils détaillent l’aspect économique pour que le lecteur comprenne leurs hypothèses. Leur tableau comparatif (en utilisant les prix publics d’Oracle Cloud pour ces plateformes) adopte une méthode de « coût relatif » où le coût par token est calculé selon :
- le coût par GPU-heure,
- divisé par le nombre de tokens par seconde par GPU à l’objectif d’interactivité,
- puis extrapolé à des millions de tokens.
Dans ce cadre, et pour les MoE :
- À 25 tokens/seconde/utilisateur :
- Rapport de prix (GB200 vs MI355X) : 1,86×
- Delta de performance (par GPU) : 5,85×
- Performance par dollar : 3,1×
- Coût relatif par token : environ 1/3 de celui du MI355X
- À 75 tokens/seconde/utilisateur :
- Rapport de prix : 1,86×
- Delta de performance : 28×
- Performance par dollar : 15×
- Coût relatif par token : environ 1/15 de celui du MI355X
Pour résumer rapidement dans un tableau :
| Objectif d’interactivité | Plateforme (référence Signal65) | Ratio prix (vs MI355X) | Delta de performance (vs MI355X) | Performance/$ | Coût relatif par token |
|---|---|---|---|---|---|
| 25 tokens/sec/utilisateur | GB200 NVL72 | 1,86× | 5,85× | 3,1× | environ 1/3 |
| 25 tokens/sec/utilisateur | MI355X | 1,0× | 1,0× | 1,0× | 1,0× |
| 75 tokens/sec/utilisateur | GB200 NVL72 | 1,86× | 28× | 15× | environ 1/15 |
| 75 tokens/sec/utilisateur | MI355X | 1,0× | 1,0× | 1,0× | 1,0× |
De plus, Signal65 souligne que, dans leur analyse, la référence de prix publics pour le MI355X en cloud provient d’Oracle, qui a aussi annoncé la disponibilité du MI355X en OCI à partir de 8,60 $/heure (selon leur communiqué).
Ce que l’on ne dit pas en titre : pourquoi il faut lire les petites lignes
Ces résultats ne représentent pas une « vérité universelle » sur la performance NVIDIA vs AMD. C’est plutôt une photographie d’un scénario très précis :
- MoE, où la communication interne et la latence dictent tout.
- Un objectif d’interactivité explicite (25 vs 75 tokens/sec/utilisateur), qui modifie radicalement le point de fonctionnement.
- Des piles logicielles concrètes (Signal65 mentionne des combinaisons comme TensorRT-LLM, vLLM et une configuration associée à « Dynamo » dans ses graphiques), ce qui peut fortement influencer la comparaison en pratique.
- Des prix « listés » dans le cloud, qui reflètent rarement ce qu’un hyper-échelle réel paie, à cause des engagements, remises, réservations ou accords de capacité.
Il y a aussi une dimension presque philosophique : si l’industrie se dirige vers des expériences « chat » de plus en plus interactives, la métrique tokens/sec avec des objectifs latence stricts pourrait devenir l’indicateur clé de performance. Si, à l’inverse, l’accent est mis sur le débit brut en batch, d’autres modèles denses ou des charges privilégiant la mémoire, la cartographie pourrait évoluer.
Malgré tout, l’idée centrale semble claire : à grande échelle, l’architecture du système dans sa globalité (interconnexion + mémoire + logiciel) peut faire une différence énorme en termes d’économie d’inférence, même si le concurrent propose des accélérateurs très performants sur le papier.
Questions fréquentes
Pourquoi « tokens par seconde par utilisateur » est-il une métrique clé en IA générative ?
Parce qu’il reflète l’expérience réelle : pas seulement combien de tokens la GPU peut produire, mais si elle peut maintenir une réponse fluide pour de nombreux utilisateurs simultanément.
Quelle différence pratique y a-t-il entre un modèle dense et un MoE en termes de coûts d’inférence ?
Le MoE peut être plus efficace en calcul, mais nécessite souvent plus de coordination et de trafic interne : si l’interconnexion devient le goulot d’étranglement, le coût par token « utile » augmente dans des scénarios interactifs.
Pourquoi le « coût par token » peut-il fortement varier entre fournisseurs cloud et centres de données en propre ?
En cloud, ce sont les prix, la disponibilité, les quotas et remises ; en interne, l’amortissement, la consommation d’énergie, la refroidissement et l’utilisation moyenne jouent un rôle. La même plateforme peut être « chère » ou « économique » selon le niveau d’utilisation et le profil de demande.
Peut-on extrapoler un benchmark MoE à son propre contexte (service client, RAG, copilotes internes) ?
Avec précaution : la combinaison de modèles, la quantification, la longueur du contexte, la concurrence et les objectifs latence modifient le résultat. La clé est la méthodologie : mesurer le TPS pour votre objectif d’interactivité et le convertir en coût par million de tokens avec vos prix réels.