L’inférence sur TPU de Google vient de défier l’avantage de coût de Nvidia avec Ironwood

L’inférence sur TPU de Google a atteint une nouvelle étape, Ironwood offrant apparemment jusqu’à 50 % de performances supplémentaires par dollar par rapport au Nvidia B200 dans certains tests. Ce résultat provient d’un aperçu officiel d’InferenceX, un projet de benchmarking tiers piloté par SemiAnalysis. Il remet en cause l’idée selon laquelle l’économie compétitive des TPU n’existe qu’au sein de Google.

Cette nuance est importante. SemiAnalysis a testé une pile de service TPU récemment ouverte à l’extérieur face à des accélérateurs Nvidia, dans des conditions précises de modèle, de précision, de débit et de latence. Ironwood n’a pas remporté toutes les comparaisons, et son logiciel ne dispose pas encore de plusieurs optimisations présentes dans les déploiements GPU matures.

L’enjeu de fond n’est donc pas un benchmark face à un autre. Il s’agit de la tentative de Google de rendre son système TPU verticalement intégré utilisable par des clients habitués à l’environnement logiciel CUDA de Nvidia. Si Google y parvient, les acheteurs disposeront d’une alternative crédible pour l’inférence à grande échelle, sans avoir à attendre que l’écart matériel se réduise à lui seul.

L’inférence sur TPU de Google sort des murs de Google

Le changement important est que des acteurs externes peuvent désormais évaluer l’inférence sur TPU de Google au moyen d’un workflow de service de modèles ouverts plus familier.

Google exploite des TPU en production depuis plus d’une décennie. Ses services internes ont donné à l’entreprise un contrôle inhabituel sur la conception des accélérateurs, les compilateurs, les réseaux, les modèles et les logiciels de déploiement. Ce contrôle a rendu les TPU efficaces chez Google, mais n’a pas automatiquement créé une plateforme accessible aux développeurs externes.

Ironwood change une partie de cette équation. Google a présenté le TPU de septième génération en avril 2025 comme son premier TPU conçu spécifiquement pour l’inférence. L’inférence est le processus qui consiste à exécuter un modèle entraîné afin de produire une réponse, une image, une prédiction ou une action.

Google a ensuite rendu Ironwood généralement disponible via Google Cloud. Ses détails de lancement d’Ironwood décrivent des configurations atteignant 9 216 puces et 42,5 exaflops par pod. Google a également revendiqué une efficacité énergétique près de 30 fois supérieure à celle de son premier Cloud TPU de 2018.

Ces spécifications ont établi l’échelle du matériel. Elles ne répondaient pas à la question de savoir si une équipe externe pouvait servir efficacement des modèles à poids ouverts sans s’appuyer sur l’environnement de production privé de Google.

Les nouveaux résultats d’InferenceX abordent cette question plus difficile. SemiAnalysis indique que l’aperçu utilise TorchTPU, une pile logicielle externe conçue pour relier les workflows de modèles orientés PyTorch aux TPU de Google. Il s’appuie également sur des travaux autour de SGLang, un moteur de service open source utilisé pour l’inférence de grands modèles de langage.

Cette combinaison compte, car la plupart des développeurs d’IA ne choisissent pas un accélérateur en lisant ses spécifications de calcul de pointe. Ils évaluent la quantité de travail d’ingénierie qui sépare un checkpoint de modèle d’un service de production stable.

L’aperçu du benchmark tiers indique qu’Ironwood a surpassé les Nvidia B200 et B300 en performances par dollar sur certaines parties de la plage de fonctionnement testée. À un objectif de 100 tokens générés par seconde et par utilisateur, SemiAnalysis a calculé un avantage de coût d’environ 19 % sur le B200. L’avantage signalé atteignait environ 34 % sur le B300.

À un objectif plus lent de 20 tokens par seconde, Ironwood a produit 9 364 tokens totaux par seconde et par puce lors du test rapporté. Le B200 en a produit 8 903, tandis que le B300 en a produit 8 925. Cela représentait environ 5 % de débit brut supplémentaire pour Ironwood dans cette exécution particulière.

Des coûts matériels modélisés plus faibles ont accru l’avantage calculé. SemiAnalysis a rapporté 50,4 % de tokens par dollar supplémentaires par rapport au B200 à un point de forte concurrence. Il a fait état d’un avantage bien plus important sur le B300 au même point.

Il s’agit de résultats de benchmark, et non de classements universels. Ils représentent des modèles et configurations sélectionnés exécutés sur une pile encore en développement. Ils font néanmoins évoluer la discussion autour des TPU du potentiel architectural vers une économie observable de l’extérieur.

Cette transition crée la tension centrale. Google ne doit plus seulement montrer que ses propres équipes peuvent tirer de la valeur des TPU. L’entreprise doit démontrer que les clients peuvent reproduire une part suffisante de cette valeur avec un effort, une latence, une fiabilité et une couverture de modèles acceptables.

Le résultat sur le coût met sous pression la position par défaut de Nvidia

Un avantage crédible de coût pour les TPU met Nvidia sous pression, car les acheteurs d’inférence achètent du travail accompli, et non des spécifications de puces de pointe.

Les grands services d’IA doivent traiter un nombre énorme de tokens d’entrée et de sortie. De faibles différences d’utilisation, de latence et de consommation énergétique se cumulent sur des charges de travail persistantes. Les performances par dollar sont donc plus utiles que le débit brut pour comparer des systèmes de production.

Cette métrique exige néanmoins du contexte. Un système peut augmenter son débit total en regroupant davantage de requêtes, mais des lots plus grands font souvent attendre les utilisateurs individuels plus longtemps. Un coût par token inférieur a moins d’intérêt si le service manque son objectif de temps de réponse.

SemiAnalysis a rendu ce compromis visible dans ses mesures à forte concurrence. Avec une concurrence de 256, Ironwood a enregistré un délai moyen jusqu’au premier token de 5,41 secondes. Le B200 a atteint 3,75 secondes, tandis que le B300 a atteint 2,40 secondes.

Le délai jusqu’au premier token mesure le temps d’attente d’un utilisateur avant que le modèle ne commence à générer sa réponse. Il est particulièrement important pour les interfaces de chat, les assistants de programmation, les systèmes vocaux et les agents interactifs.

L’écart de latence complique toute affirmation selon laquelle Ironwood bat simplement Blackwell. Le meilleur résultat de coût d’Ironwood est apparu à un point de fonctionnement où Nvidia fournissait le premier token plus rapidement. Les différents clients n’accorderont pas la même valeur à cet échange.

Un service hors ligne de traitement de documents peut accepter des attentes plus longues s’il gagne un débit substantiel. Un chatbot grand public en concurrence sur la réactivité peut préférer un premier token plus rapide, même lorsque chaque requête achevée coûte davantage.

Les agents de longue durée créent un autre modèle de charge de travail. Ils relisent continuellement le contexte, appellent des outils, mettent à jour leur état et génèrent de courtes réponses. Leurs besoins d’infrastructure diffèrent de ceux d’un prompt unique suivi d’une longue réponse.

Ces distinctions expliquent pourquoi InferenceX présente une courbe de Pareto plutôt qu’un score unique mis en avant. Une courbe de Pareto montre les meilleures combinaisons disponibles de coût et de latence sans prétendre qu’un point de fonctionnement convient à toutes les applications.

Ironwood serait resté compétitif sur une grande partie de cette courbe. Pour un temps de réponse médian de bout en bout de 20 secondes, SemiAnalysis a estimé un avantage de coût de 8 % sur le B200 et de 25 % sur le B300.

Toutefois, le B200 a pris l’avantage sur une portion plus réduite de la courbe qui se chevauche. Nvidia a également conservé des avantages importants lorsque les modèles utilisaient des calculs FP4 de précision inférieure.

FP4 stocke les valeurs numériques sous forme de représentations en virgule flottante sur quatre bits. Il peut accroître le débit et réduire l’utilisation mémoire, même si une quantification agressive peut aussi affecter la qualité du modèle. Ironwood ne dispose pas de calcul FP4 natif, selon l’analyse du benchmark.

SemiAnalysis a comparé les systèmes principalement en FP8 et avec une prédiction d’un seul token pour ses tests les plus directement comparables. L’organisme a noté que le chemin FP4 de Nvidia peut prendre l’avantage lorsque les clients acceptent ses compromis de qualité et de mise en œuvre.

La pression exercée sur Nvidia est donc plus limitée qu’un récit de remplacement direct. Google remet en question la position économique par défaut de Nvidia pour certaines charges d’inférence, en particulier lorsque des formes de modèles stables favorisent du matériel spécialisé.

Nvidia propose toujours une large couverture des charges de travail, des bibliothèques largement déployées, des opérateurs expérimentés et des outils de débogage établis. Ces atouts réduisent le risque d’intégration d’une manière qui n’apparaît pas dans les graphiques de débit de tokens.

La pression immédiate porte sur les prix et la segmentation de produits de Nvidia. Si les clients peuvent déplacer des charges d’inférence prévisibles vers Ironwood, Nvidia devra défendre Blackwell par une meilleure utilisation, une latence plus faible, des choix de précision plus larges ou un déploiement plus simple.

Google subit également une pression. L’entreprise doit transformer un aperçu prometteur en résultats clients reproductibles. Sinon, les acheteurs traiteront le benchmark comme une démonstration optimisée plutôt que comme une alternative d’approvisionnement.

Pourquoi la pile TPU externe de Google compte davantage qu’un seul benchmark

Le véritable mécanisme est l’externalisation du logiciel, car un matériel compétitif ne peut pas réduire la dépendance à CUDA lorsque les clients peinent à déployer leurs modèles.

CUDA est la plateforme de programmation de Nvidia et son ensemble de bibliothèques accélérées pour le calcul GPU. Son importance dépasse le langage utilisé pour écrire des kernels. CUDA relie pilotes, compilateurs, bibliothèques de communication, profileurs, moteurs d’inférence, optimiseurs de modèles et des années de connaissances des développeurs.

Ce système connecté réduit le risque opérationnel. Une équipe confrontée à un problème de performances GPU peut s’appuyer sur une documentation abondante, des outils familiers, le support du fournisseur et une vaste communauté d’ingénieurs. Elle peut souvent réutiliser des schémas de déploiement entre différentes générations de Nvidia.

Google a historiquement optimisé les TPU au moyen d’outils et d’équipes internes. JAX est devenu la voie de programmation publique la plus visible, tandis que de nombreux projets d’IA externes se sont standardisés autour de PyTorch et CUDA.

TorchTPU tente de réduire cette fracture. Il donne aux développeurs orientés PyTorch une voie d’accès à l’exécution sur TPU tout en prenant en charge des couches de modèles et de service familières. Plus cette expérience se rapproche des workflows existants, plus le coût de changement pour Google diminue.

SGLang constitue un autre pont. Il gère les tâches de service de modèles telles que la planification des requêtes, l’utilisation de la mémoire, le batching et l’exécution distribuée. La prise en charge d’un moteur d’inférence reconnu permet à Google de concurrencer Nvidia au-delà du niveau de la puce.

Cela ne signifie pas que le problème logiciel est résolu. SemiAnalysis a identifié des travaux inachevés autour du décodage spéculatif, du service désagrégé, du déchargement du cache clé-valeur et des charges de travail d’agents à plusieurs tours.

Le décodage spéculatif utilise un modèle plus petit ou plus rapide pour proposer des tokens qu’un modèle plus grand vérifie. Lorsqu’il est bien mis en œuvre, il augmente la vitesse de génération sans modifier la distribution de sortie attendue du modèle final.

Le service désagrégé sépare le traitement des prompts de la génération de tokens. Ces phases imposent des exigences différentes au calcul, à la mémoire et au réseau ; des pools de ressources spécialisés peuvent donc améliorer l’utilisation.

Le déchargement du cache clé-valeur déplace, lorsque cela est approprié, les données d’attention stockées hors de la mémoire de l’accélérateur. Il peut augmenter la capacité effective pour de longs contextes ou de nombreuses sessions simultanées, mais les déplacements de données peuvent introduire de la latence.

Ces capacités sont devenues importantes dans les principaux déploiements GPU. L’infrastructure privée de Google utiliserait certaines techniques comparables, mais sa pile TPU externe n’expose pas encore tous les chemins optimisés.

Cette lacune explique une comparaison révélatrice dans le rapport de benchmark. SemiAnalysis a constaté qu’un système Nvidia GB300 NVL72 utilisant le service désagrégé conservait environ 30 % d’avantage en performances par dollar sur une partie de la plage de latence. La comparaison avec le TPU utilisait le service agrégé, car son chemin externe désagrégé n’était pas entièrement optimisé.

Il ne s’agissait pas d’une comparaison architecturale parfaitement équitable. Elle a toutefois montré à quel point les logiciels de production peuvent influer sur le résultat. Le leadership matériel évolue lorsqu’un système bénéficie d’une stratégie de planification et de service plus mature.

Nvidia étend également sa couche d’inférence. L’entreprise a publié Dynamo 1.0 en mars 2026 sous forme de logiciel open source pour l’inférence générative et agentique distribuée. Dynamo coordonne des opérations telles que le routage des requêtes, la gestion de la mémoire et le serving désagrégé.

Nvidia a également contribué au projet open source FlashInfer avec des kernels CUDA TensorRT-LLM. Cette stratégie place des composants optimisés par Nvidia au sein des frameworks que les développeurs utilisent déjà.

Google ne peut donc pas réduire le fossé créé par CUDA en se contentant d’atteindre un objectif statique. L’entreprise doit progresser tandis que Nvidia continue d’ouvrir certaines parties de sa pile technologique et d’optimiser ses systèmes à l’échelle du rack.

L’élément prometteur pour Google réside dans sa capacité à coordonner le développement matériel et logiciel. Les ingénieurs TPU peuvent concevoir compilateurs, kernels, interconnexions et systèmes de serving autour des mêmes hypothèses architecturales.

La contrainte tient à la diversité des modèles. Une matrice spécialisée fonctionne au mieux lorsque les dimensions et les opérations du modèle correspondent à sa géométrie. Les modèles conçus et optimisés autour des GPU peuvent produire des structures peu efficaces pour l’exécution sur TPU.

SemiAnalysis a mis ce problème en évidence avec les dimensions d’attention et le routage des mixture-of-experts. Un modèle populaire peut encore exiger un travail important sur les kernels avant d’exploiter efficacement Ironwood.

L’ouverture aux clients externes dépend donc d’une matrice de compatibilité en expansion, et non d’un unique portage réussi. Les acheteurs doivent avoir l’assurance que les nouvelles familles de modèles recevront des optimisations rapides sans exiger un accès direct aux ingénieurs performance de Google.

Ironwood remporte certains tests, mais le déficit de vérification demeure

L’avantage rapporté est significatif, mais son périmètre reste trop étroit pour établir une avance générale de Google TPU en matière d’inférence.

InferenceX présente ses résultats comme les premières mesures d’inférence tierces pour Ironwood. Cela confère à ce travail une plus grande indépendance qu’un benchmark publié uniquement par Google. Toutefois, SemiAnalysis attribue également à des ingénieurs Google et à d’autres équipes participantes une contribution à la construction et à l’optimisation de la pile testée.

La collaboration est normale lors des premiers benchmarks matériels. Elle peut révéler plus précisément les performances atteignables d’un système qu’une installation sans assistance. Elle rapproche aussi le résultat d’une implémentation de référence optimisée plutôt que d’un déploiement client moyen.

L’aperçu s’est initialement concentré sur une charge de travail 8k1k. Cette notation décrit généralement le traitement d’une entrée de 8 000 tokens et la génération de 1 000 tokens de sortie. Elle représente un prompt conséquent suivi d’une réponse significative, mais ne couvre pas tous les schémas d’inférence modernes.

Les agents de code peuvent réutiliser et étendre des dépôts au fil de nombreux tours. Les agents de recherche peuvent alterner de longues entrées de récupération avec de courts appels d’outils. Les applications vocales privilégient une faible latence continue, tandis que la synthèse par lots privilégie le débit global.

Une seule charge de travail ne peut représenter ces différences. Les acheteurs ont besoin de résultats couvrant les longueurs de prompts, les longueurs de sortie, les niveaux de concurrence, les architectures de modèles, les formats de quantification et les objectifs de niveau de service.

La qualité des modèles doit également faire partie de la comparaison. FP4 peut améliorer le débit de Nvidia, mais une configuration à précision réduite doit être évaluée au regard de la précision des tâches et de la cohérence des sorties. Un résultat de vitesse est incomplet si des changements de précision entraînent un comportement différent du modèle.

La méthodologie de coût présente une autre incertitude. SemiAnalysis a utilisé un coût total de possession modélisé pour les systèmes achetés en externe, plutôt que de s’appuyer uniquement sur les tarifs de location du cloud public. Ces modèles dépendent d’hypothèses concernant l’acquisition, l’utilisation, l’énergie, le réseau, le financement et la durée de vie utile.

L’économie interne de Google diffère de celle de ses clients. Le rapport a estimé un avantage TPU plus important en appliquant les hypothèses de coûts internes de Google. Les acheteurs externes ne peuvent pas supposer qu’ils bénéficieront de la même structure de coûts.

La disponibilité peut encore modifier le calcul. Un accélérateur techniquement efficace offre une valeur limitée si les clients ne peuvent obtenir une capacité suffisante dans les régions qu’ils utilisent. Nvidia fait également face à des contraintes d’approvisionnement, mais ses systèmes restent disponibles auprès de nombreux fournisseurs cloud et partenaires serveurs.

Le catalogue TPU actuel de Google répertorie Ironwood comme étant généralement disponible. Il présente aussi TPU 8i comme une génération à venir axée sur l’inférence. La capacité réelle, les options d’achat, les modalités de support et l’accès géographique peuvent néanmoins varier selon le client.

La portabilité constitue un autre coût que les benchmarks capturent rarement. Une entreprise qui standardise ses optimisations spécifiques aux TPU peut améliorer son économie tout en devenant plus dépendante de Google Cloud ou de fournisseurs de systèmes sélectionnés.

CUDA crée un verrouillage, mais s’éloigner de CUDA ne supprime pas automatiquement ce verrouillage. Cela peut remplacer une pile intégrée par une autre. Les frameworks ouverts ne réduisent ce risque que lorsque le comportement et les performances se transfèrent de manière prévisible entre les backends.

Les preuves opérationnelles compteront autant qu’une nouvelle courbe de benchmark. Les clients ont besoin de reprise après défaillance, d’observabilité, d’autoscaling, de contrôles de sécurité, de gestion des versions et de mises à niveau prévisibles.

Ils ont également besoin d’ingénieurs capables de diagnostiquer les régressions de performance. Une plateforme offrant un coût par token inférieur peut devenir coûteuse si des spécialistes doivent réécrire régulièrement des kernels ou examiner le comportement du compilateur.

Pour cette raison, le résultat d’InferenceX doit être interprété comme une preuve de compétitivité dans des conditions sélectionnées. Il ne prouve pas qu’Ironwood est devenu le meilleur accélérateur pour chaque modèle ou chaque organisation.

Cette distinction ne diminue pas l’importance de cette annonce. Les débats antérieurs sur les TPU s’arrêtaient souvent à la question de savoir si les avantages privés de Google pouvaient quitter son propre environnement. Cet aperçu montre qu’au moins une partie de la pile peut désormais prendre en charge une inférence économiquement compétitive et testable de l’extérieur.

La charge de la preuve s’est déplacée. Google doit élargir la surface testée, tandis que Nvidia doit démontrer que ses avantages logiciels et de latence justifient sa position sur les charges de travail où Ironwood réduit les coûts.

TPU 8i étend le défi au-delà d’Ironwood

Ironwood établit une voie externe crédible, tandis que TPU 8i est conçu pour répondre à plusieurs limites révélées par la comparaison actuelle.

Google a annoncé sa huitième génération de TPU en avril 2026, avec des conceptions distinctes pour l’entraînement et l’inférence. TPU 8t cible l’entraînement à grande échelle, tandis que TPU 8i se concentre sur le post-entraînement, l’apprentissage par renforcement et l’inférence.

Cette séparation reflète l’évolution de la demande en infrastructure d’IA. L’entraînement nécessite un calcul dense au sein de clusters gigantesques. L’inférence doit équilibrer la capacité mémoire, la latence, le débit, l’énergie et des schémas de requêtes qui évoluent rapidement.

Google affirme que TPU 8i offrira une amélioration de 80 % des performances par dollar par rapport à Ironwood pour l’inférence à faible latence sur de grands modèles mixture-of-experts. Les modèles mixture-of-experts n’activent que certains groupes de paramètres pour chaque token, ce qui réduit le calcul tout en créant des exigences de routage et de communication.

L’entreprise indique également que TPU 8i prend en charge le calcul FP4 natif. Cela répond directement à un domaine où Nvidia conservait un avantage dans les comparaisons avec Ironwood.

La feuille de route de huitième génération de Google indique que TPU 8i et TPU 8t offrent jusqu’à deux fois les performances par watt d’Ironwood. Tous deux ont été annoncés pour une arrivée plus tard en 2026.

Il s’agit encore d’affirmations de l’entreprise tant que des tests indépendants ne les confirment pas. Le point important est l’orientation de l’architecture. Google ne traite plus l’inférence comme un usage secondaire de matériel conçu principalement autour de l’entraînement.

TPU 8i accroît également l’importance du travail logiciel externe en cours. Un nouvel accélérateur sans pile de serving exploitable relancerait le problème d’adoption. Un environnement TorchTPU en maturation peut apporter la prise en charge des modèles et les connaissances opérationnelles à la génération suivante.

SemiAnalysis s’attend à ce que TPU 8i concurrence plus directement la plateforme Rubin NVL72 de Nvidia. Cette comparaison dépendra de bien plus que de la prise en charge native de FP4.

Les systèmes Rubin de Nvidia combinent GPU, CPU, réseau, mémoire et logiciels d’inférence à l’échelle du rack. Nvidia a également optimisé sa feuille de route autour des modèles de raisonnement et des charges de travail agentiques, où les inférences répétées augmentent la demande totale de tokens.

Google avance un argument similaire à l’échelle du système. L’entreprise conçoit conjointement le calcul TPU, la communication entre puces, les réseaux optiques, les compilateurs et l’orchestration cloud.

La concurrence oppose de plus en plus des systèmes à des systèmes. Aucun fournisseur ne peut gagner durablement des charges de travail de production grâce à la seule fiche technique d’un accélérateur autonome.

Amazon, AMD et d’autres programmes de silicium personnalisé ajoutent une pression supplémentaire. Leur existence donne aux grands acheteurs davantage de pouvoir de négociation, même lorsque ces acheteurs continuent d’utiliser Nvidia pour de nombreuses charges de travail.

Google occupe toutefois une position distincte. L’entreprise dispose de plusieurs années d’expérience de production avec les TPU, de charges de travail internes majeures, d’un cloud public, du développement de modèles de pointe et d’une feuille de route claire pour les accélérateurs.

Cette combinaison permet à Google de tester des optimisations sur des services internes substantiels avant de les exposer à ses clients. Elle lui permet également d’adapter les modèles Gemini aux caractéristiques des TPU.

L’adoption externe exige le mouvement inverse. Google doit optimiser des modèles populaires qu’il n’a pas conçus, y compris des architectures dont les dimensions reflètent des années de recherche orientée GPU.

C’est là que le fossé créé par CUDA devient moins absolu tout en restant considérable. Les frameworks de haut niveau peuvent masquer les différences matérielles lors de l’exécution de base. Ils ne peuvent pas éliminer automatiquement chaque différence liée aux kernels, au réseau, à l’ordonnancement et à la gestion de la mémoire.

La génération de code assistée par IA peut accélérer une partie du travail de portage. Elle ne peut remplacer la validation de la précision, de la stabilité et des modes de défaillance en production.

TPU 8i renforcera le défi lancé par Google s’il arrive avec une large prise en charge des modèles et un serving désagrégé mature. Il affaiblira le récit si ses meilleures performances économiques dépendent d’une assistance d’ingénierie privilégiée ou de configurations de benchmark étroites.

Trois signaux détermineront si l’ouverture des TPU aux clients externes fonctionne

Les prochaines preuves devront démontrer la reproductibilité, l’étendue des charges de travail et l’adoption par les clients, plutôt qu’un nouveau résultat de pointe isolé.

Le premier signal est un benchmark comparable de serving désagrégé. SemiAnalysis affirme que le parcours TPU externe actuel requiert encore des optimisations dans ce domaine, même si Google utilise des techniques associées en interne.

Une suite utile comparerait Ironwood et les systèmes Nvidia avec la désagrégation activée des deux côtés. Elle devrait utiliser le même modèle, la même précision, le même objectif de qualité, la même contrainte de latence et la même méthodologie de coût.

Si Ironwood réduit l’écart rapporté face à GB300 NVL72, l’argument de Google à l’échelle du système deviendra plus solide. Si l’écart persiste, le logiciel de serving mature de Nvidia restera un avantage décisif.

Le deuxième signal est la performance sur des charges de travail d’agents à plusieurs tours. Ces systèmes traitent de manière répétée un contexte croissant, appellent des outils et produisent de courtes sorties. Ils sollicitent la gestion du cache et la latence différemment d’un benchmark 8k1k.

SemiAnalysis indique prévoir de publier des résultats sur les charges de travail agentiques plus tard en 2026. Ces tests devraient rendre compte du temps jusqu’au premier token, de la latence inter-token, du débit, de l’utilisation mémoire et du coût par tâche achevée.

De bons résultats montreraient que l’inférence Google TPU peut gérer le schéma de demande qui oriente la planification actuelle des infrastructures. De faibles résultats suggéreraient que l’avantage d’Ironwood se concentre sur des tâches de serving plus prévisibles.

Le troisième signal est l’existence de preuves provenant de clients externes. La disponibilité générale est importante, mais les déploiements répétés révèlent si les développeurs peuvent reproduire l’économie des benchmarks sans un support inhabituellement intensif.

Les preuves les plus solides incluraient des charges de travail de production nommées, des modèles ouverts pris en charge, une expansion de capacité et une fiabilité mesurée. Les acheteurs devraient également observer la rapidité avec laquelle les nouveaux modèles reçoivent des kernels TPU optimisés.

Google cite déjà des exemples de clients autour d’Ironwood, notamment des charges de travail plus rapides chez Citadel Securities. Une adoption plus large pour l’inférence montrerait que l’ouverture des TPU dépasse les équipes spécialisées et les grands partenaires stratégiques.

La réponse de Nvidia doit être observée sur la même période. Les améliorations apportées à Dynamo, TensorRT-LLM, Blackwell et Rubin peuvent modifier la comparaison avant que les logiciels TPU n’atteignent leur maturité.

Un avantage de coût n’est pas permanent lorsque les deux plateformes mettent rapidement à jour leur matériel et leurs logiciels de serving. Les acheteurs devraient évaluer des configurations opérationnelles reproductibles plutôt que de conserver un benchmark comme classement figé.

La leçon pratique consiste à dissocier l’adéquation à la charge de travail de l’identité du fournisseur. Une inférence stable et à fort volume peut justifier dès maintenant une évaluation des TPU. Les services sensibles à la latence, les modèles évoluant rapidement ou les équipes fortement investies dans CUDA peuvent encore privilégier Nvidia.

Les équipes d’infrastructure devraient conserver leurs hypothèses de benchmark et leurs constats de déploiement comme des documents évolutifs. Une base de connaissances technique consultable peut aider les équipes à comparer les résultats au fil de l’évolution des modèles, des compilateurs et des générations d’accélérateurs.

Google a franchi un seuil important en rendant l’économie de ses TPU vérifiable par des acteurs externes. L’entreprise n’a pas effacé l’avantage logiciel de Nvidia ni établi une position de leader universel.

La prochaine question est concrète : des clients ordinaires peuvent-ils reproduire les gains d’inférence des TPU Google dans des applications réelles avant que le prochain système de Nvidia ne les réduise ? La réponse déterminera si InferenceX marque un changement durable du marché ou une impressionnante étape précoce.