Ce qu’AWS a annoncé le 10 juin
AWS a mis Graviton5 en disponibilité générale le 10 juin 2026, en l’associant à deux familles d’instances : M9g pour les charges de travail généralistes et M9gd pour les déploiements à forte intensité de stockage. L’annonce avait été anticipée depuis AWS re:Invent en décembre 2025, mais la disponibilité générale transforme une diapositive de feuille de route en décision d’achat.
Le chiffre phare : 192 cœurs Arm par puce — le plus grand nombre de cœurs jamais atteint dans la lignée Graviton. Mais le seul comptage des cœurs ne raconte pas l’histoire complète. Selon la couverture de SiliconAngle lors du lancement, Graviton5 embarque la prise en charge de la mémoire DDR5 et l’intégration PCIe, deux premières pour la famille Graviton. Le cache L3 est cinq fois plus grand que celui de Graviton4, et chaque cœur accède à 2,6 fois plus de cache L3 — une amélioration structurelle qui réduit la latence d’accès mémoire pour les charges de travail parallèles qui définissent les architectures cloud modernes.
Les revendications de performances d’AWS situent l’amélioration globale du calcul à 25% par rapport à Graviton4. En décomposant par type de charge de travail, les chiffres s’élargissent : 35% plus rapide sur les applications web et l’inférence de modèles de machine learning, 30% plus rapide sur les bases de données. La variante M9gd ajoute du NVMe local — jusqu’à 11,4 To de SSD par instance — avec des opérations d’entrée/sortie 30% plus rapides par seconde par rapport à la génération précédente. La bande passante réseau progresse de 15% globalement ; les instances M9g de grande taille atteignent le double de la bande passante Amazon EBS de leurs homologues Graviton4.
Plus de 120 000 clients AWS utilisent déjà des générations Graviton antérieures, selon la page produit AWS Graviton. Cette base installée ne migre pas automatiquement vers Graviton5, mais elle signale à quel point les instances basées sur Arm ont pénétré les charges de travail d’entreprise qui auraient historiquement opté pour x86.
La guerre du silicium personnalisé et pourquoi elle s’intensifie en 2026
Graviton5 n’est pas apparu isolément. Il s’inscrit dans une campagne pluriannuelle des hyperscalers pour supplanter le silicium marchand dans leurs centres de données. La logique stratégique est simple : posséder la feuille de route du processeur permet à un fournisseur cloud d’optimiser pour ses propres charges de travail, de se découpler des cycles de publication d’Intel et AMD, et de capturer la marge qui revenait auparavant aux vendeurs de puces.
AWS a lancé ce scénario en 2018 avec Graviton1. Chaque génération a élargi l’avantage de performances et la couverture des cas d’usage. Graviton4 a conquis le tier des bases de données. Graviton5 est explicitement positionné pour l’IA agentique — les charges de travail nécessitant un calcul CPU continu et à haut débit à grande échelle, incluant le raisonnement en temps réel, la génération de code et l’orchestration de tâches multi-étapes. Le nombre de 192 cœurs n’est pas fortuit ; il est calibré pour les modèles de concurrence que les agents IA génèrent lorsque plusieurs fils de raisonnement s’exécutent simultanément.
Google suit une trajectoire parallèle avec Axion, son processeur de centre de données basé sur Arm. Microsoft développe Cobalt 100. Le modèle est désormais structurel : chaque grand hyperscaler construit ou acquiert du silicium personnalisé. L’implication pour les entreprises est que d’ici 2027, l’instance x86 ne sera plus le choix par défaut sur aucun cloud majeur — ce sera une sélection délibérée pour les charges de travail ayant des dépendances ISA spécifiques ou des restrictions de licence logicielle.
L’angle de l’efficacité amplifie la pression économique. AWS déclare que les instances Graviton consomment jusqu’à 60% moins d’énergie que les instances EC2 comparables pour les mêmes performances. À l’échelle d’une grande facture cloud d’entreprise, ce gain d’efficacité se traduit directement en réduction de coûts et en reporting de durabilité. Pour les organisations ayant des engagements net-zéro, exécuter Graviton5 n’est pas un choix technique — c’est un choix de gouvernance.
Publicité
Ce que trois premiers adoptants révèlent sur les modèles de déploiement
Meta, Snowflake et Uber se sont publiquement engagés à déployer des instances Graviton5, comme l’a rapporté Guru3D dans sa couverture du lancement de Graviton5. L’analyse de leurs profils d’usage révèle les trois modèles de déploiement qui définiront l’adoption précoce.
L’intérêt de Meta s’aligne sur l’inférence à grande échelle. L’inférence de grands modèles de langage est une charge de travail CPU-plus-accélérateur où le CPU gère la tokenisation, l’ordonnancement et les étapes de pré/post-traitement entourant le calcul GPU. Une puce à 192 cœurs avec 2,6 fois plus de cache L3 par cœur signifie que chaque CPU peut gérer nettement plus de sessions d’inférence concurrentes avant de saturer — réduisant directement le nombre d’instances GPU nécessaires.
Le déploiement de Snowflake signale des charges de travail de bases de données et d’analytique. L’amélioration des performances de bases de données de 30% et le doublement de la bande passante EBS sur les grandes instances répondent à la contrainte architecturale centrale de Snowflake : déplacer de grands ensembles de données entre le stockage et le calcul lors des requêtes. Une E/S plus rapide signifie une latence de requête plus faible au même coût, ou la même latence à un coût plus bas.
L’adoption par Uber pointe vers les microservices distribués et la prise de décision en temps réel — correspondance de courses, tarification dynamique, détection de fraude. Ce sont précisément les charges de travail que l’amélioration de 15% de la bande passante réseau et la réduction de la latence inter-cœurs ciblent. Pour une entreprise exploitant des milliers de microservices sur des millions de requêtes concurrentes, une amélioration de calcul de 25% se multiplie sur l’ensemble de la flotte.
Ce que les responsables techniques doivent faire face à Graviton5
1. Auditer votre inventaire d’instances x86 pour identifier les candidats à la migration Graviton
La première étape n’est pas un pilote — c’est un exercice de classification. Segmentez votre inventaire EC2 en trois groupes : (a) les charges de travail sans dépendances ISA avec des runtimes conteneurisés — celles-ci migrent avec une recompilation et un changement de paramètre ; (b) les charges de travail avec des licences logicielles commerciales qui restreignent le déploiement Arm — celles-ci nécessitent une négociation avec le fournisseur avant la migration ; (c) les charges de travail liées à x86 par du code natif hérité ou de l’assembleur embarqué — celles-ci nécessitent un chemin de remédiation plus long.
AWS rapporte que plus de 120 000 clients ont déjà effectué des migrations Graviton, beaucoup d’entre eux terminant en quelques heures. Les outils ont considérablement mûri depuis Graviton1. Pour les charges de travail du groupe (a) fonctionnant sur des conteneurs ou des runtimes modernes interprétés (Python, Node.js, JVM, Go), le chemin de migration est documenté et le risque est faible. Priorisez ceux-ci en premier — c’est le chemin le plus rapide pour capturer la réduction de coûts de 20% et l’amélioration de l’efficacité énergétique de 60%.
2. Effectuer des benchmarks sur votre profil de charge de travail réel, pas sur les revendications agrégées d’AWS
L’amélioration de calcul de 25% est un agrégat sur les classes de charges de travail. Vos résultats varieront considérablement. Les applications web et les charges d’inférence de machine learning voient 35% d’amélioration ; les bases de données en voient 30%. Le calcul par lots, le transcodage vidéo et la simulation scientifique auront leurs propres profils. Avant de vous engager sur des familles d’instances à grande échelle, exécutez votre charge de travail de production réelle — ou une relecture représentative — sur des instances M9g en parallèle avec votre type d’instance actuel.
AWS fournit un niveau d’essai gratuit (t4g.small, 750 heures/mois jusqu’en décembre 2026) pour une évaluation initiale. Pour les benchmarks à l’échelle de la production, exécutez un test parallèle de deux semaines : routez un pourcentage du trafic vers des instances M9g et comparez les percentiles de latence, le débit et les taux d’erreur par rapport à votre baseline. Capturez le coût par transaction comme métrique principale — et non le débit brut, qui optimise la mauvaise variable.
3. Intégrer le NVMe local M9gd dans la revue de votre architecture de stockage
La variante M9gd avec jusqu’à 11,4 To de SSD NVMe local n’est pas seulement une mise à niveau de stockage — elle change le calcul architectural pour l’accès aux données sensibles à la latence. Les applications qui extraient actuellement des données chaudes depuis EBS ou ElastiCache parce que la latence d’EBS est trop élevée pourraient être en mesure de se consolider sur des instances M9gd avec du NVMe local, éliminant un niveau de complexité d’infrastructure.
La contrepartie est la volatilité du stockage d’instance : le NVMe local ne persiste pas lors des arrêts d’instance. Le modèle qui fonctionne consiste à utiliser le stockage d’instance pour les données chaudes éphémères (caches, tampons d’écriture, ensembles de travail) avec synchronisation vers EBS durable ou S3 lors des points de contrôle. Si votre application gère déjà les défaillances de nœuds correctement — partitions Kafka, répliques Redis, réplication Cassandra — le NVMe local de M9gd s’intègre naturellement. Si votre application suppose la persistance du stockage après les redémarrages, M9gd ajoute un travail architectural qui peut ne pas valoir le gain de latence pour votre cas d’usage.
4. Réévaluer les hypothèses budgétaires de votre infrastructure d’IA agentique
Graviton5 a été explicitement conçu pour les modèles de concurrence de l’IA agentique. Si votre plan d’infrastructure IA 2026 inclut des frameworks d’orchestration multi-agents — qu’il s’agisse de LangChain, LlamaIndex, l’API tool-use d’Anthropic ou une orchestration propriétaire — vos hypothèses de dimensionnement CPU ont probablement été faites avant que Graviton5 ne soit disponible. Une instance à 192 cœurs avec 35% de meilleures performances d’inférence de machine learning change le ratio d’instances CPU/GPU dont vous avez besoin dans votre stack de service d’agents.
Plus précisément : les étapes de pré- et post-traitement autour de l’inférence GPU (formatage des prompts, comptage de tokens, gestion du contexte, analyse des sorties) sont liées au CPU. Sur une instance de l’ère Graviton4, ces étapes pouvaient créer un goulot d’étranglement pour un GPU rapide. Sur Graviton5, les mêmes étapes se terminent plus rapidement et avec plus de concurrence, ce qui signifie que votre utilisation du GPU s’améliore — vous obtenez plus de débit d’inférence du même investissement en accélérateurs.
La vue d’ensemble : ce que le silicium personnalisé signifie pour l’économie cloud jusqu’en 2028
Le lancement de Graviton5 n’est pas une simple annonce produit. C’est un point de données dans un changement structurel qui se jouera jusqu’à la fin de la décennie.
La trajectoire du silicium personnalisé des hyperscalers est désormais établie : AWS (Graviton, Trainium, Inferentia), Google (Axion, TPU), Microsoft (Cobalt, Maia). À chaque cycle, ces puces gagnent du terrain sur le silicium marchand pour un ensemble plus large de charges de travail. Le point auquel une charge de travail exécutée sur du silicium personnalisé est toujours moins chère que la même charge sur Intel ou AMD — en l’absence de verrouillage ISA — approche. Pour le calcul généraliste, AWS soutient que ce point a déjà été franchi avec la revendication d’avantage de coût de 20%.
Pour les organisations d’ingénierie, cela crée une question de gouvernance qui va au-delà de la sélection des puces. La chaîne d’approvisionnement logicielle doit de plus en plus être compatible Arm. Les images de base des conteneurs, les dépendances de runtime, les binaires compilés et les agents tiers doivent tous cibler Arm/aarch64 comme plateforme de première classe. Les organisations qui traitent cela comme une tâche de migration ponctuelle devront refaire le travail chaque fois qu’une nouvelle charge de travail sera ajoutée. La posture durable est d’établir Arm comme cible de build par défaut et x86 comme exception, nécessitant une justification explicite.
Questions Fréquemment Posées
Quelle est la différence entre les instances AWS Graviton5 M9g et M9gd ?
Les instances M9g sont des instances de calcul généralistes optimisées pour les applications web, les bases de données, l’inférence de machine learning et les charges de travail distribuées. Les instances M9gd ajoutent du stockage SSD NVMe local — jusqu’à 11,4 To par instance — les rendant adaptées aux applications nécessitant un accès à faible latence à de grands ensembles de données éphémères tels que les caches, les tampons d’écriture et les ensembles de travail d’analytique. Les deux utilisent la même puce Graviton5 à 192 cœurs et offrent la même amélioration de performances de 25% par rapport à Graviton4.
Comment Graviton5 se compare-t-il aux générations Graviton précédentes d’AWS ?
Graviton5 offre 25% de performances de calcul supérieures à Graviton4, avec des améliorations spécifiques de 35% pour les applications web et l’inférence de machine learning et de 30% pour les charges de travail de bases de données. Le cache L3 est cinq fois plus grand que celui de Graviton4, et chaque cœur accède à 2,6 fois plus de cache — réduisant la latence mémoire pour les charges de travail concurrentes. Graviton5 introduit également la mémoire DDR5 et l’intégration PCIe, deux premières pour la famille Graviton, ainsi qu’une bande passante réseau 15% plus élevée et jusqu’à 100% de bande passante EBS en plus sur les grandes instances.
Les entreprises devraient-elles migrer leurs charges de travail x86 vers Graviton5 immédiatement ?
Pas toutes en même temps. La bonne approche consiste à classer les charges de travail en trois groupes : les charges de travail conteneurisées ou avec des runtimes modernes sans dépendances ISA (migration rapide — jours à semaines), les logiciels commerciaux avec des restrictions de licence Arm (nécessite d’abord une négociation avec le fournisseur) et le code natif x86 hérité (chemin de remédiation plus long). AWS rapporte que de nombreux clients complètent les migrations Graviton en quelques heures grâce aux outils actuels. Pour la plupart des organisations, commencer par le premier groupe capture la majorité des économies de coûts avec un risque minimal, tandis que le troisième groupe est déprioritisé jusqu’à ce que les éditeurs de logiciels publient des versions natives Arm.
Sources et lectures complémentaires
- complémentaires
- AWS Graviton5 fait ses débuts avec de nouvelles instances M9g et M9gd — SiliconAngle
- AWS Graviton — Page produit officielle — Amazon Web Services
- AWS Graviton5 : 192 cœurs Arm et PCIe 6.0 — Guru3D
- AWS reconstruit son CPU serveur autour de l’IA agentique : lancement de Graviton5 à 192 cœurs — TechTimes
- AWS lance le CPU Graviton5 avec 192 cœurs pour l’IA agentique — ConvergeDigest
