Le 5 novembre 2026, SemiAnalysis a publié les résultats de quatre soumissions de Google TPUv7, aussi appelé Ironwood, au benchmark AgentX. Ils varient selon le modèle, la précision numérique, la pile logicielle et la mesure retenue : ces essais ne désignent pas un accélérateur gagnant dans tous les cas.

AgentX met à l’épreuve l’inférence par agents

AgentX évalue des échanges en plusieurs tours avec de longs contextes, la réutilisation de préfixes et des pics d’activité de sous-agents, selon SemiAnalysis. La réutilisation de préfixes consiste à exploiter de nouveau une partie commune du contexte d’une requête. Ce scénario porte donc sur le service de modèles dans une charge de travail particulière, pas sur toutes les tâches d’inférence.

Deux mesures reviennent dans les résultats. Les tokens par dollar rapportent le débit de génération au coût du service selon les hypothèses de l’analyse. Le décodage mesure la production des jetons de réponse après le traitement de l’entrée ; le résultat de bout en bout tient compte du service complet. Une puce peut donc se classer différemment selon l’étape mesurée.

Pour comparer ces résultats, gardez ensemble le modèle, la précision, le système de référence et la métrique : changer l’un de ces éléments peut changer le classement.

Quatre modèles, des résultats différents

Pour Muse Spark Open, la soumission de RadixArk utilisait SGLang-TorchTPU et des poids NVFP4. SemiAnalysis décrit le TPUv7 comme compétitif en performances de décodage par dollar, selon le coût TPU communiqué par Meta, mais relève que la latence de bout en bout devait encore être améliorée, notamment en optimisant le préremplissage du contexte. L’analyse indique aussi que les têtes d’attention de largeur 64 conduisaient à remplir 25 % du réseau systolique du TPU pour l’attention à long contexte.

Sur GLM-5.2 en FP8, SemiAnalysis rapporte que le TPUv7 produisait entre 1,2 et 2,7 fois plus de tokens par dollar que les B200, B300 et MI355X, entre 60 et 300 tokens par seconde et par utilisateur. À 150 tokens par seconde et par utilisateur, le rapport indiqué face au H200 était de 4,4 fois.

Le résultat GLM-5.3 en FP4 va dans l’autre sens au point de fonctionnement cité : à 100 tokens par seconde et par utilisateur, SemiAnalysis rapporte que les GB300 et GB200 obtenaient respectivement 3,6 et 3,5 fois plus de tokens par dollar que le TPUv7. L’analyse attribue cet écart en partie à l’absence de prise en charge native du FP4 sur le TPUv7 ; elle signale aussi un compromis de qualité dans les comparaisons en FP4. Pour cette configuration à long contexte, elle décrit plus de 90 % des requêtes comme mises en cache et indique que le mécanisme d’attention parcimonieuse sélectionnait 2 048 entrées du cache par requête.

Pour Qwen3.5 397B, la première soumission en FP8 avec vLLM affichait, selon SemiAnalysis, 1,67 fois plus de performances par dollar que le GB300 NVL72 en FP4. Une soumission NVIDIA ultérieure obtenait de meilleurs résultats en décodage, tandis que le TPUv7 restait devant sur la mesure de bout en bout dans la configuration décrite. Le déploiement llm-d mobilisait 24 à 32 puces TPUv7 par résultat, à raison de quatre puces par hôte. Au point le plus rapide testé pour chaque système, le temps d’attente du premier jeton au 90e centile était de 8,6 secondes sur TPUv7 et de 11,1 secondes sur GB300 FP4.

Les résultats de Kimi K3 ont également évolué avec les soumissions. Au lancement, SemiAnalysis rapportait que le TPUv7 atteignait entre 0,77 et 0,91 fois les tokens par dollar du GB300, sur une plage de 50 à 200 tokens par seconde et par utilisateur. Dans une comparaison à un seul utilisateur, le débit indiqué était de 391 tokens par seconde et par utilisateur sur TPUv7, contre 251 sur GB300. Après quatre actualisations de NVIDIA, l’analyse rapportait un avantage de 1,5 à 2,6 fois pour le GB300 en FP4. Une autre comparaison ultérieure donnait au TPUv7 entre 1,15 et 2,5 fois les tokens par dollar des GB200, B200 et B300.

Pourquoi un même benchmark ne donne pas un classement unique

Les chiffres ne mesurent pas tous la même chose. Le débit à un utilisateur, les tokens par dollar sur une plage d’interactivité donnée, la latence du premier jeton et la performance de bout en bout répondent à des questions différentes. Le cas de Qwen3.5 le montre directement : la soumission NVIDIA devançait le TPUv7 en décodage, mais pas sur la mesure de bout en bout rapportée.

La précision compte aussi. FP8, FP4, NVFP4 et MXFP4 désignent des formats numériques de tailles différentes ; comparer des configurations utilisant des formats différents ne revient pas à comparer uniquement les accélérateurs. Les résultats GLM-5.2 en FP8 et GLM-5.3 en FP4 concernent d’ailleurs des modèles et des conditions distincts.

Les exemples Ironwood publiés par Google Cloud

La bibliothèque de Google Cloud présente des exemples d’inférence sur Ironwood, notamment le service de GPT OSS-120B et de Qwen3-Coder-480B avec vLLM, ainsi que des exemples PyTorch/TorchTPU. Ces parcours indiquent des pistes logicielles et des modèles à examiner ; ils ne constituent pas des mesures de performance AgentX.