Le puces cloud bon marché avec le chemin de retour coûteux

Jusqu’à deux tiers de meilleure performance prix, moins d’énergie par opération de calcul, matériel propre sans surcoût Nvidia : avec ces promesses, AWS, Microsoft et Google poussent leurs puces cloud développées en interne. L’avantage est réel et mesurable. Ce que le calcul ne révèle pas, c’est le prix du retour.

Les points clés en bref

• L’avantage de prix est réel : Les puces ARM propres des hyperscalers offrent une meilleure performance prix que les instances x86 classiques, selon la charge de travail, jusqu’à deux tiers dans les meilleurs cas. L’écart est le plus grand pour les services de scale-out.
• Il ne s’applique pas à tout : Les logiciels x86 legacy, les charges de travail HPC avec des bibliothèques spécialisées et les produits ISV sans licence ARM paient l’avantage. La réduction est soumise à des conditions.
• Le verrouillage se déplace : Chaque puce est propriétaire. Une charge de travail optimisée pour Graviton ne fonctionne pas à l’identique sur Axion ou Cobalt. Qui veut changer, construit et teste à nouveau.

Related :Rapatriement du cloud : quand le rapatriement est rentable  /  Courant continu 800 volts dans les centres de données

Pourquoi les hyperscalers construisent soudainement leurs propres puces

Qui aujourd’hui réserve une instance de calcul ne décide plus seulement entre les fournisseurs. Il décide entre les architectures de processeurs que aucun concurrent ne partage : Graviton chez AWS, Cobalt chez Azure, Axion chez Google Cloud. Trois conceptions ARM propres, trois écosystèmes propres. Pour les architectes cloud, cela déplace une vieille question à une nouvelle place, une étape plus profonde dans la pile.

La motivation derrière les développements internes est purement économique. Le silicium personnalisé réduit la dépendance à Intel, AMD et surtout Nvidia, dont la marge autrement est dans la facture cloud. Cela économise de l’énergie par opération de calcul, et dans les centres de données pleins, l’énergie est désormais l’entrave la plus dure que le capital. Et cela lie les clients à des types d’instances que seul un fournisseur possède. Chez AWS, l’activité avec des puces propres a atteint selon des estimations industrielles un chiffre d’affaires de plusieurs milliards par an.

Les générations se succèdent au rythme annuel. AWS a déployé en juin Graviton5, un processeur ARM avec 192 cœurs sur le processus 3 nanomètres de TSMC et selon le fournisseur environ 25 % plus rapide que le prédécesseur. Pour l’entraînement de l’IA, AWS positionne à côté Trainium2 comme alternative aux GPU Nvidia et exploite pour cela ses propres grands ensembles dans la zone de puces à six chiffres.

Microsoft mise sur Maia 200 un accélérateur d’IA propre avec 216 Go de mémoire HBM3e et avec Cobalt 200 une CPU ARM pour la charge de serveur classique. Google a avec Axion son premier processeur ARM propre dans les familles d’instances C4A et N4A en production. Trois fournisseurs, même logique : du silicium au service, tout contrôler soi-même.

Où la réduction est réelle et où elle bascule

L’effet d’économie n’est pas une réduction globale. Il se produit là où le logiciel est proprement compilé pour ARM et évolue horizontalement. Pour les serveurs Web, les microservices, les charges de travail Java et MySQL, les sidecars de conteneur et les services sans état, ARM gagne dans presque toutes les mesures. Google cite jusqu’à 50 % de performances supplémentaires et 60 % d’efficacité énergétique meilleure par rapport à des machines x86 comparables. SAP a signalé des gains de performances notables sur Graviton pour sa charge de travail de base de données HANA.

L’autre côté est rarement mentionné dans les supports publicitaires. Les bibliothèques HPC spécialisées, les anciens binaires x86 sans build ARM et les logiciels ISV commerciaux dont la licence ne couvre pas l’architecture, annulent l’avantage. Si vous exécutez un moteur de base de données avec une licence x86 uniquement, vous économisez sur l’instance, mais vous payez plus pour le support.

Entre la décision et l’économie, il existe une phase de transition qui n’apparaît pas dans aucun calcul de prix. Lorsque vous migrez, vous faites fonctionner les deux architectures en parallèle pendant un certain temps : double matrice de tests, doubles images de base, doubles profils de surveillance. Cette double maintenance est temporaire, mais elle repousse le point de retour sur investissement. Les équipes qui tiennent compte de cela ne déclarent l’effet d’économie qu’à partir du trimestre où l’ancienne charge de travail x86 est désactivée.

Avant chaque migration, il est donc nécessaire de faire un inventaire des charges de travail, et non un tableau de prix. Quel service est sans état et prêt pour ARM, lequel dépend d’une dépendance x86 qui n’est plus documentée ? La classification détermine le cas commercial, et non le prix catalogue par vCPU.

Le verrouillage qui n’est pas dans le contrat

C’est là que se trouve la véritable pointe. Le verrouillage ne se trouve plus seulement dans le contrat, il se trouve dans la construction. L’ancienne liaison cloud était une question de transfert de données et de services gérés. Le silicium personnalisé introduit un deuxième niveau de liaison, une étape plus profonde dans la pile. Une image optimisée pour Graviton fonctionne sur Axion ou Cobalt, mais rarement avec la même efficacité. Les trois conceptions ARM diffèrent dans les extensions vectorielles, la hiérarchie de cache et la connexion mémoire. Les indicateurs de compilation, les bibliothèques optimisées et les profils de charge sont calibrés pour chaque famille de puces.

Lorsqu’on change de fournisseur, on reconstruit, on mesure à nouveau et on ajuste le réglage. En pratique, cela bloque une petite équipe pendant des semaines, et finalement, la même application fonctionne qu’avant, mais sur un silicium différent. Ce sont précisément ces coûts de changement qui donnent au fournisseur la position de négociation qu’il semble abandonner avec la réduction à l’entrée.

La puce économique ne coûte rien à l’entrée. Elle coûte à la sortie.

ARM dans le cloud reste le choix approprié pour la majeure partie du portefeuille. Le seul danger est de supposer que moins cher signifie automatiquement plus libre. Si vous acceptez la réduction sans calculer les coûts de sortie, vous échangez une dépendance à Nvidia contre une dépendance à l’architecture. La façon dont ce changement se traduit sur le plan de la capacité est illustrée par la course parallèle sur les GPU, qui met sous pression toute l’équipe de plateforme.

Comment les équipes sécurisent l’effet d’économie sans se limiter

La solution s’appelle la discipline dans la chaîne de production. Cinq étapes séparent le cas commercial solide de l’échec coûteux.

1. Intégrer la compatibilité ARM dès le début dans les tests d’intégration continue (CI). Les builds multi-architecture doivent faire partie de la chaîne de production avant que la première charge de travail productive ne soit migrée. Quiconque l’ajoute après coup paie deux fois.
2. Classer les charges de travail au lieu de les déplacer de manière globale. Les workloads sans état et compatibles ARM en premier, les workloads legacy et liés aux éditeurs de logiciels en dernier ou pas du tout.
3. Prendre en compte les coûts de sortie dans le cas commercial. Pas seulement l’économie mensuelle, mais également l’effort nécessaire pour déplacer la charge de travail vers un autre processeur ou revenir à x86 plus tard.
4. Étiquetage FinOps par architecture. Sans attribution de coûts propre à chaque type d’instance, l’effet réel reste invisible dans les postes comptables agrégés.
5. Garder les images standard portables. Écrire les conteneurs et l’infrastructure en tant que code de manière à ce que le changement d’architecture reste une décision de configuration et non une reconstruction à partir de zéro.

Pour la plupart des équipes, il est clair que les instances ARM sont rentables dès le départ pour la partie « scale-out » du portefeuille, et que l’effet d’économie justifie la portabilité. Mais quiconque planifie la migration comme une voie à sens unique perd précisément le pouvoir de négociation que la concurrence entre les hyperscalers lui offre.

Foire aux questions

Plus de contenu du réseau MBF Media

Source de l’image : générée par IA (Juni 2026)