Les benchmarks CPU AGI d’Arm mettent AMD sous pression, mais l’avance de 1,99x est modélisée

Arm affirme que son nouveau processeur accomplit près de deux fois plus de travail par rack que l’EPYC 9755 d’AMD sur sept charges sélectionnées. Les benchmarks CPU AGI d’Arm font état d’un avantage moyen de 1,99x après extrapolation des résultats mesurés au niveau de la puce à l’aide d’hypothèses sur la puissance des serveurs.

Ce titre peut sembler annoncer une défaite nette d’AMD. Les résultats sous-jacents racontent une histoire plus nuancée. Arm a affiché une avance moyenne de 1,20x par puce, tandis que son avantage bien plus important par rack provient surtout de la possibilité d’installer davantage de serveurs dans un budget énergétique fixe.

Signal65 a examiné les tests dans le cadre d’une analyse commandée par Arm. Toutefois, l’entreprise n’a pas réexécuté indépendamment l’intégralité de la comparaison sur du matériel distinct. Le benchmark évalue également le travail CPU autour des agents IA, et non l’intelligence des modèles ou l’inférence sur accélérateur.

Le résultat importe donc pour une raison précise. Arm invite les acheteurs d’infrastructure à évaluer les CPU pour IA agentique selon le travail accompli par rack, plutôt que de considérer les performances par socket comme la réponse définitive.

Les benchmarks CPU AGI d’Arm déplacent la compétition vers le rack

L’affirmation centrale d’Arm n’est pas que chaque CPU AGI surpasse chaque processeur AMD de près de deux fois au niveau du socket.

L’analyse à l’échelle du rack a comparé le processeur d’Arm à l’EPYC 9755 de cinquième génération d’AMD. Elle couvrait sept charges liées à l’exécution d’outils, à la récupération d’informations, au service web, au génie logiciel et au support du serving de modèles.

Signal65 a rapporté un ratio moyen de performances par rack modélisées de 1,99x en faveur d’Arm. Les résultats individuels par rack allaient de 1,43x à 3,19x selon la charge.

Les sept tests étaient MySQL, NGINX, Milvus, Terminal-Bench 2, une relecture de SWE-bench, fastText et la surcharge CPU de vLLM. Ils représentent différentes composantes du parcours logiciel entourant un modèle d’IA.

MySQL mesure le débit des bases de données transactionnelles. NGINX couvre le traitement des requêtes web et API, tandis que Milvus représente la récupération vectorielle pour la mémoire et la recherche des agents.

Terminal-Bench 2 examine le travail effectué dans des environnements de ligne de commande isolés. Le test utilisait 72 types de tâches et exécutait 128 instances simultanément.

La relecture de SWE-bench couvrait 259 tâches de génie logiciel. Au lieu de demander à un modèle de choisir des actions différentes à chaque exécution, le benchmark rejouait un flux de travail fixe.

Cette approche par relecture est importante, car les agents IA sont non déterministes. Deux exécutions peuvent impliquer des commandes, des délais de services distants ou des plans générés par le modèle différents, même lorsque la tâche demandée est identique.

fastText a mesuré l’entraînement CPU de représentations de mots. Le test vLLM a mesuré la surcharge du processeur autour du serving de modèles, tout en contournant le travail de calcul principal du modèle.

Cette dernière distinction évite une interprétation fréquente mais erronée. Le résultat vLLM ne montre pas à quelle vitesse le CPU AGI exécute l’inférence de grands modèles de langage par rapport à un GPU.

La puce d’Arm a remporté cinq des sept comparaisons par puce. Elle devançait AMD de 9 % dans Terminal-Bench, de 13 % dans la relecture SWE-bench et de 97 % dans fastText.

AMD a conservé l’avantage dans deux charges d’infrastructure établies. L’EPYC 9755 était 12 % plus rapide dans MySQL et 5 % plus rapide dans Milvus au niveau mesuré de la puce.

NGINX a produit un ratio de 1,20x en faveur d’Arm. La charge de surcharge CPU vLLM a donné à Arm un résultat de 1,16x.

Sur l’ensemble des sept ratios normalisés, Arm a obtenu un avantage moyen de 1,20x par puce. Ce résultat est significatif, mais reste bien inférieur au chiffre de 1,99x associé à l’affirmation au niveau du rack.

Le modèle de rack a transformé la comparaison en tenant compte de la puissance nominale des serveurs. Il supposait entre 950 et 1 050 watts pour un serveur Arm à deux sockets, selon la configuration du CPU AGI.

Le système AMD s’est vu attribuer une estimation de puissance nominale de 1 700 watts. Les deux calculs incluaient la mémoire et les autres composants du serveur, et non seulement la puissance thermique de conception du processeur.

Après avoir réservé environ 8 % d’un budget de rack de 24 kilowatts au réseau et à la distribution électrique, le modèle pouvait accueillir 21 ou 23 serveurs Arm. Il pouvait accueillir 13 serveurs AMD dans le même budget.

Cela a produit entre 5 712 et 5 888 cœurs Arm physiques par rack modélisé. Le rack AMD contenait 3 328 cœurs physiques.

Le multiplicateur de densité qui en résultait a placé chaque charge Arm au-dessus d’AMD au niveau du rack. Même MySQL, qui favorisait AMD par puce, devenait un résultat modélisé de 1,43x pour Arm par rack.

Milvus est passé de 0,95x par puce à 1,54x par rack. La relecture SWE-bench est passée de 1,13x à exactement 2,00x dans le modèle de rack.

fastText a généré le ratio le plus élevé. Son résultat mesuré de 1,97x par puce est devenu un résultat modélisé de 3,19x par rack.

Ces chiffres étayent l’argument d’Arm selon lequel les centres de données contraints par la puissance devraient évaluer le travail utile total. Ils ne montrent pas deux racks en fonctionnement accomplissant ces charges sous une puissance à la prise directement mesurée.

Pourquoi l’IA agentique rend le travail CPU plus visible

Les agents IA déplacent une part substantielle du travail hors de l’accélérateur, faisant de la capacité CPU un élément de l’expérience visible par l’utilisateur.

Une requête d’IA générative classique peut sembler centrée sur l’inférence du modèle. Un agent de production exécute une séquence plus longue impliquant planification, récupération, appels d’outils, validation et gestion d’état.

Le GPU ou un autre accélérateur effectue toujours les calculs denses des réseaux neuronaux. Le CPU coordonne une grande partie du parcours d’exécution environnant et exécute de nombreux outils sélectionnés par l’agent.

Un agent de programmation offre un exemple concret. Il peut inspecter un dépôt, lancer un environnement isolé, installer des dépendances, compiler du code, exécuter des tests et analyser les échecs.

Chaque appel au modèle peut déclencher une nouvelle série de travail CPU. L’exécution simultanée de milliers d’agents multiplie la demande exercée sur les conteneurs, les bases de données, les API, le stockage et les systèmes de planification.

Les agents d’entreprise créent un profil différent. Ils peuvent interroger des enregistrements, appeler des services internes, appliquer des politiques d’accès, sérialiser des réponses, mettre à jour l’état des flux de travail et écrire des journaux d’audit.

La récupération ajoute des opérations d’indexation et de recherche vectorielle. Le serving de modèles ajoute la tokenisation, la planification des requêtes, le batching, le streaming et la gestion des métadonnées de cache autour de l’accélérateur.

Le cadre d’évaluation d’Arm sépare ce travail entre les fonctions du framework d’agents et les outils propres aux cas d’usage. Il distingue aussi les benchmarks de composants des mesures de tâches de bout en bout.

Les tests de composants aident à isoler le comportement du processeur. Les tests de bout en bout montrent si un composant plus rapide permet d’accomplir une tâche plus rapidement ou avec davantage de fiabilité.

Aucune de ces approches ne suffit seule. Un processeur peut dominer un benchmark de base de données sans raccourcir le flux de travail total d’un agent, notamment lorsque la latence du modèle prédomine.

Un résultat de bout en bout peut également masquer la cause d’un écart de performance. Des modèles, réseaux, outils ou décisions d’agent différents peuvent éclipser la différence sous-jacente entre processeurs.

Arm propose les trajectoires d’agents rejouables comme passerelle entre ces deux approches. Une trajectoire enregistre les opérations produites durant une session d’agent et exécute la même séquence sur chaque système.

Cette technique réduit les variations liées aux décisions du modèle. Elle rend également la comparaison plus reproductible, car les deux processeurs reçoivent un flux de travail équivalent.

Toutefois, la relecture retire une partie du système en direct. Elle mesure la vitesse à laquelle l’infrastructure exécute un parcours prédéterminé, et non si une pile complète d’agents trouve un meilleur parcours.

Cette limite explique pourquoi l’étiquette de raisonnement et de planification exige de la prudence. Les tests concernés mesurent le support CPU de ces flux de travail plutôt que la qualité du raisonnement machine.

La même prudence s’applique à la concurrence. Un serveur qui démarre davantage d’environnements d’agents n’est pas automatiquement meilleur si les temps de réponse s’effondrent sous une utilisation soutenue.

La méthodologie d’Arm met l’accent sur le travail accompli et utile tout en maintenant la réactivité. Ce cadrage relie le débit aux limites physiques auxquelles sont confrontés les centres de données.

La fourniture d’énergie est devenue l’une de ces limites. La capacité de refroidissement et l’espace en rack limitent également le nombre de processeurs qu’un opérateur peut déployer, indépendamment de la disponibilité des puces.

Dans ces conditions, dominer par socket ne produit pas toujours le meilleur résultat à l’échelle de l’installation. Un processeur modérément plus rapide peut perdre à l’échelle du rack si son serveur associé consomme beaucoup plus d’énergie.

À l’inverse, un serveur plus efficace peut créer une capacité totale supérieure même s’il perd certains tests au niveau de la puce. Les résultats d’Arm dans MySQL et Milvus illustrent cette possibilité dans son modèle.

Arm a développé la méthodologie avec le soutien de Fujitsu, Meta et OpenAI. Leur soutien signale un intérêt pour des mesures CPU plus représentatives, mais ne fait pas du cadre une norme industrielle.

Meta a déclaré que les agents de production nécessitent une meilleure visibilité sur la manière dont les charges sollicitent l’infrastructure sous-jacente. OpenAI a mis en avant l’orchestration et l’exécution d’outils comme des domaines nécessitant des benchmarks représentatifs.

Fujitsu a relié cet effort au développement de son processeur Arm haute performance. Ces trois perspectives soutiennent de meilleures mesures, même si chaque organisation a aussi un intérêt dans l’infrastructure basée sur Arm.

Le cadre lui-même reconnaît qu’il ne s’agit pas d’une suite de benchmarks finalisée. Il définit des catégories de charges et des limites de mesure tout en laissant la notation et un accord plus large sans résolution.

Cette distinction est essentielle. Arm a proposé une manière de structurer le débat, puis publié des résultats favorables à l’aide de tests alignés sur cette proposition.

Le résultat de 1,99x provient de la densité, et non d’une victoire de puce par 2x

L’histoire des performances du CPU AGI d’Arm dépend davantage de la densité de déploiement modélisée que de performances écrasantes au niveau du socket.

Arm a testé deux configurations de CPU AGI, car le même matériel n’était pas disponible pour chaque charge. Terminal-Bench 2 et SWE-bench utilisaient une puce à 128 cœurs fonctionnant à 2,8 GHz avec de la mémoire DDR5-7200.

Les cinq autres charges utilisaient un CPU AGI à 136 cœurs fonctionnant à 3,2 GHz avec de la DDR5-8000. Le système de comparaison d’AMD utilisait un socket EPYC 9755 à 128 cœurs avec de la DDR5-6400.

Les deux plateformes exécutaient les mêmes scripts de benchmark. Elles n’exécutaient pas des environnements logiciels identiques.

La plupart des tests Arm utilisaient Ubuntu 24.04 avec une version personnalisée de Linux 7.1.3. Le test SWE-bench utilisait Ubuntu 26.04.

La configuration principale enregistrée d’AMD utilisait Ubuntu 24.04 et Linux 6.8. Certains paramètres variaient également selon le test.

Les différences logicielles peuvent affecter le comportement du compilateur, la planification, les pilotes et les performances applicatives. Elles rendent plus difficile l’attribution de chaque écart à la seule architecture du processeur.

Le modèle de puissance du serveur crée une autre distinction importante. Signal65 et Arm ont utilisé des chiffres nominaux plutôt que de mesurer des racks de production complets sous charge.

La puissance nominale reste utile pour la planification de capacité. Les opérateurs ne peuvent pas installer un équipement qui dépasse la conception électrique et thermique d’un rack, même si la consommation typique est plus faible.

Toutefois, la puissance nominale peut diverger de la consommation propre à une charge. Un système peut consommer moins que son maximum nominal lors d’une application et s’en approcher lors d’une autre.

La puissance réelle dépend aussi de la configuration de la mémoire, du stockage, du réseau, du refroidissement, des alimentations, du firmware et des politiques de gestion du système. Ces variables deviennent déterminantes lorsque le nombre de serveurs porte le titre principal.

Les hypothèses de mémoire ont modifié l’avantage rapporté. Le modèle principal d’Arm attribuait 4 Go par thread matériel.

Le multithreading simultané d’AMD expose deux threads matériels par cœur physique. La conception Arm testée utilise un thread par cœur.

Ce choix donnait aux serveurs AMD modélisés environ 2 To de mémoire et aux serveurs Arm environ 1 To. Il attribuait 336 watts à la mémoire AMD et 192 watts à la mémoire Arm.

Signal65 a également calculé un scénario attribuant la mémoire par cœur physique. Dans cette hypothèse, AMD nécessitait moins de puissance mémoire et l’avantage moyen d’Arm par rack passait de 1,99x à environ 1,81x.

Arm conservait néanmoins une avance modélisée substantielle. Cette baisse montre à quel point un choix raisonnable de planification de capacité peut modifier sensiblement le chiffre final.

La capacité mémoire n’est pas un simple détail de benchmark. Certains déploiements d’agents conservent de grands index, caches, magasins d’état ou environnements d’exécution simultanés.

Un serveur disposant de plus de mémoire peut prendre en charge des charges de travail qu’une configuration plus dense, mais de moindre capacité, ne peut pas héberger efficacement. Les acheteurs doivent donc comparer la capacité système réellement exploitable, et pas seulement le débit normalisé.

L’EPYC 9755 d’AMD prend en charge 128 cœurs physiques et 256 threads. Il appartient également à une vaste plateforme serveur utilisée pour les charges de travail généralistes, les bases de données, la virtualisation et l’hébergement d’IA.

Le CPU AGI d’Arm vise une proposition plus spécifique. Il associe des cœurs Arm denses à une bande passante mémoire et des E/S importantes pour les infrastructures d’IA.

Cette spécialisation ne rend aucune des deux architectures universellement supérieure. Elle modifie les contraintes qui déterminent le meilleur choix.

Un opérateur cloud confronté à un plafond de puissance fixe pourrait privilégier le nombre de tâches achevées par rack. Un acheteur de solutions de bases de données pourrait mettre l’accent sur les performances par socket, la maturité logicielle, la capacité mémoire ou le comportement des licences.

Un opérateur de cluster d’IA peut chercher à maintenir coûteux accélérateurs constamment occupés. Une préparation et une orchestration plus rapides côté CPU peuvent réduire le temps d’inactivité des accélérateurs, mais ces tests n’ont pas mesuré un flux de travail complet soutenu par des accélérateurs.

La comparaison entre le CPU AGI d’Arm et AMD est donc plus restreinte que le titre ne le laisse entendre. Il s’agit d’une comparaison de tâches sélectionnées, visibles par le CPU, et d’un scénario de déploiement modélisé.

Il ne s’agit pas d’une étude du coût total. Les résultats publiés ne fournissent pas de comparaison complète des coûts d’acquisition, de la migration logicielle, du support opérationnel, du réseau ou des changements d’infrastructure.

Ils ne comparent pas non plus Arm à tous les processeurs x86 pertinents. AMD propose d’autres configurations EPYC, tandis qu’Intel est en concurrence avec les plateformes Xeon dans les déploiements d’entreprise et cloud.

Le processeur Vera de Nvidia offre une deuxième voie basée sur Arm. Une étude distincte des charges de travail Vera a fait état de solides résultats par cœur face à l’EPYC 9755 pour des tâches proches de celles des agents.

Cette étude n’a pas mesuré la consommation électrique ni le débit du serveur dans son ensemble. Son résultat plus limité renforce la nécessité de distinguer les affirmations par cœur, par socket, par rack et de bout en bout.

AMD promeut également les CPU comme des composants critiques des systèmes d’IA agentique. Son propre argumentaire sur les CPU pour agents met l’accent sur l’orchestration, le traitement des données, la sécurité et la prise en charge des accélérateurs.

Le véritable désaccord ne porte donc pas sur l’importance des CPU. Il concerne la manière dont les acheteurs doivent définir la charge de travail, normaliser les systèmes et transformer des mesures de composants en décisions de déploiement.

Ce que l’affirmation de performance du CPU AGI d’Arm n’établit pas

Signal65 a validé les relevés et les calculs d’Arm, mais ce processus n’équivalait pas à une répétition indépendante en laboratoire.

Signal65 a observé à distance les exécutions de test d’Arm. L’entreprise a examiné les journaux d’origine, les fichiers de résultats, les scripts et les enregistrements de configuration.

Une équipe d’examen distincte a reconstruit les calculs à l’aide de son propre code. Selon l’analyse, elle a reproduit les sept résultats avec un écart inférieur à 0,5 %.

Ce travail apporte davantage d’examen qu’un graphique fournisseur non vérifié. Il vérifie si les ratios rapportés découlent des résultats capturés et du modèle de rack.

Arm a toutefois commandité l’analyse et fourni les systèmes testés. Signal65 n’a pas acquis de matériel équivalent ni répété indépendamment l’expérience complète dans son propre laboratoire.

L’examen s’est également heurté à des lacunes de configuration. Signal65 n’a pu confirmer indépendamment les paramètres BIOS et mémoire que pour un système EPYC 9965 utilisé dans une comparaison sandbox distincte.

L’entreprise n’a pas pu vérifier indépendamment tous les paramètres BIOS et mémoire des systèmes équipés du CPU AGI et de l’EPYC 9755. Cela limite la certitude quant à l’origine des plus petits écarts de performance.

Cette distinction compte surtout pour les résultats serrés. Une avance de 97 % sur fastText a peu de chances de disparaître à cause d’un réglage mineur, mais un écart de 5 % ou 9 % mérite un examen plus attentif.

La moyenne arithmétique crée une autre limite. La moyenne des ratios normalisés accorde à chaque charge de travail la même influence, quelle que soit la fréquence à laquelle un déploiement réel réalise cette opération.

Une entreprise peut exécuter en permanence des transactions de base de données et entraîner rarement des modèles fastText. Une autre peut exploiter des milliers de sandboxes de programmation et très peu d’infrastructure transactionnelle.

La moyenne publiée de 1,99x ne prédit donc pas le gain de capacité de chaque acheteur. Chaque opérateur a besoin d’un résultat pondéré par les charges de travail, fondé sur son propre profil d’exécution.

La suite de tests mélange également des applications établies et des proxys d’agents émergents. MySQL et NGINX ont une longue histoire, tandis que les benchmarks d’agents fondés sur la relecture restent comparativement récents.

Cette combinaison est utile, car les agents appellent une infrastructure familière. Elle est également discutable, car le mélange retenu détermine ce qui reçoit le même poids.

Le reportage original a souligné que le résultat n’établit pas une domination globale de l’IA agentique. Les processeurs, les charges de travail, les configurations et la méthodologie développée par Arm en définissent la portée.

Aucune inférence GPU complète n’était incluse dans le résultat vLLM. La catégorie raisonnement et planification n’a pas testé si un modèle raisonnait avec davantage de précision.

Le calcul par rack n’incluait pas un déploiement de 24 kilowatts directement mesuré. Il a modélisé le nombre de serveurs à partir de la puissance système nominale, après avoir réservé de la capacité pour l’infrastructure du rack.

Le prix ne faisait pas partie de la comparaison publique. Les licences applicatives, les travaux de migration, la formation du personnel et la compatibilité avec les outils de déploiement existants n’y figuraient pas non plus.

Ces omissions n’invalident pas le benchmark. Elles définissent ce que le résultat permet d’étayer.

Arm peut raisonnablement affirmer que ses systèmes testés ont produit un débit modélisé par rack supérieur selon les hypothèses documentées. L’entreprise ne peut pas transformer cette affirmation en une domination universelle de l’IA agentique.

AMD peut raisonnablement souligner ses deux victoires par puce et l’effet des hypothèses sur la mémoire. Ces éléments n’effacent pas l’avantage de densité d’Arm dans le modèle publié.

L’interprétation la plus productive se situe entre ces positions. Arm a présenté une hypothèse crédible qui justifie des tests plus larges et indépendants sur du matériel de production.

Cette hypothèse est que la puissance par rack et le débit soutenu des outils d’agents devraient peser davantage que les comparaisons traditionnelles par socket. Le résultat de 1,99x constitue une première étude de cas en faveur de cet argument.

Pour les acheteurs, la méthode pourrait s’avérer aussi influente que le vainqueur actuel. Une suite commune et transparente permettrait aux opérateurs de comparer Arm, AMD, Intel et Nvidia selon des périmètres identiques.

Une telle suite devrait inclure une puissance système mesurée, des logiciels équivalents, un firmware documenté, une pondération au niveau des charges de travail et une validation de bout en bout reproductible.

Elle devrait aussi présenter plusieurs vues plutôt que de tout compresser dans un seul ratio. Les résultats par cœur, par socket, par watt, par rack et par dollar répondent à des questions opérationnelles différentes.

La réussite des tâches et la latence doivent rester distinctes du débit d’infrastructure. Un système qui réalise davantage d’actions rejouées ne produira pas nécessairement de meilleurs résultats d’agent si les délais du modèle ou du réseau dominent.

Trois signaux détermineront si l’affirmation d’Arm par rack se confirme

Le matériel de production, des tests plus larges des concurrents et les déploiements clients détermineront si l’avantage modélisé d’Arm devient un avantage opérationnel.

Le premier signal sera constitué de tests indépendants sur les systèmes finaux de production équipés du CPU AGI. Signal65 a indiqué que les résultats actuels reflètent des systèmes précoces et que des travaux de suivi plus larges sont prévus.

Un suivi convaincant devrait mesurer la consommation complète du serveur pendant chaque charge de travail. Il devrait utiliser des systèmes d’exploitation, paramètres de compilateur, capacités mémoire, firmware et conditions de refroidissement comparables.

Le test le plus probant équiperait plusieurs serveurs et validerait expérimentalement le calcul du rack. Il montrerait si la densité, le réseau, la thermique et l’utilisation soutenue se comportent comme le prévoit le modèle.

Si les tests de production restent proches de la moyenne de 1,99x, la position d’Arm deviendra beaucoup plus solide. Une baisse importante montrerait que la modélisation fondée sur la puissance nominale a surestimé la capacité déployable.

Le deuxième signal sera une comparaison avec un ensemble plus vaste de processeurs. L’AMD EPYC 9755 est important, mais un seul processeur x86 ne peut représenter l’ensemble du marché.

Les options plus récentes et à plus grand nombre de cœurs d’AMD pourraient modifier le calcul de densité. Intel pourrait se comporter différemment dans les domaines du service web, des bases de données, de la récupération d’informations et de l’exécution d’outils.

Nvidia Vera mérite également une comparaison directe, car il utilise des cœurs compatibles Arm, mais vise l’infrastructure d’IA avec une conception système différente. Sa connectivité aux accélérateurs crée une autre voie de déploiement.

Des tests plus larges devraient employer les mêmes charges de travail et une notation transparente. Des sélections de benchmarks propres aux fournisseurs laisseraient les acheteurs face à des affirmations incompatibles.

Si Arm conserve une avance par rack face à plusieurs concurrents, sa méthodologie gagnera en crédibilité au-delà d’un seul appariement favorable. Si la position de tête varie fortement, le choix des charges de travail deviendra l’histoire la plus importante.

Le troisième signal sera l’adoption réelle par des clients, accompagnée de données opérationnelles divulguées. Arm a positionné le CPU AGI pour les hyperscalers et d’autres grands opérateurs d’infrastructure d’IA.

Un déploiement public devrait présenter le travail accompli, la latence, la puissance et l’utilisation avant et après la migration. Il devrait également expliquer les changements logiciels nécessaires pour l’architecture Arm.

Les preuves opérationnelles peuvent révéler des problèmes que les benchmarks ne détectent pas. Elles comprennent la compatibilité des dépendances, l’observabilité, la disponibilité des images de conteneurs, le placement des charges de travail, la récupération après défaillance et l’effort d’administration.

Les résultats clients compteront surtout s’ils couvrent un trafic de production soutenu. De courtes démonstrations ne peuvent reproduire le profil de demande de milliers d’agents persistants.

L’annonce de benchmark d’Arm d’octobre 2026 défend clairement l’évaluation de l’infrastructure à l’échelle du rack. Elle indique également que la méthodologie doit évoluer à mesure que les architectures d’agents changent.

Cet aveu est approprié. Les logiciels agentiques restent mouvants, et la séquence d’outils représentative d’aujourd’hui peut devenir le proxy obsolète de demain.

Les équipes d’infrastructure devraient utiliser les benchmarks du CPU AGI d’Arm comme une raison d’examiner leurs propres goulets d’étranglement, et non comme un verdict universel d’approvisionnement.

Commencez par retracer où un agent passe son temps. Distinguez l’inférence de modèle de la récupération d’informations, du démarrage de sandbox, de l’exécution d’outils, de l’accès aux bases de données, de l’orchestration et de la validation.

Associez ensuite ces étapes à la contrainte réelle. Un cluster peut être confronté à un plafond de puissance, une limite de capacité mémoire, une sous-utilisation des accélérateurs ou une latence de tâche inacceptable.

Ce processus peut transformer une affirmation générale d’un fournisseur en une question locale vérifiable. Il empêche également qu’une moyenne de benchmark ne remplace une planification de capacité propre à la charge de travail.

Les équipes d’ingénierie évaluant une infrastructure d’agents peuvent conserver leurs notes de benchmark, enregistrements de configuration et conclusions de déploiement dans une base de connaissances interrogeable. Cet historique devient précieux lorsque des changements logiciels ou matériels invalident une comparaison antérieure.

Arm a établi la position de départ : son processeur a atteint en moyenne 1,20x par puce et 1,99x par rack modélisé dans sept charges de travail sélectionnées. AMD a néanmoins remporté deux tests au niveau de la puce, et plusieurs hypothèses ont façonné le ratio plus élevé.

La prochaine décision appartient aux testeurs indépendants et aux acheteurs d’infrastructure. Les racks de production mesurés reproduiront-ils l’avantage de densité d’Arm, ou les charges de travail réelles réduiront-elles l’écart ?