ARM Fait Tourner la Moitié du Cloud : Graviton 4, Ampere Altra Max et les Chiffres Derrière le Recul de l'x86

Le Virage N'est Plus Théorique

Pendant la majeure partie de la dernière décennie, ARM en salle serveur relevait de la promesse — toujours à deux ans d'être prêt pour la production. Cette époque est révolue. AWS indique que ses instances basées sur Graviton alimentent désormais une part substantielle et croissante de sa flotte de calcul. Les puces Altra Max d'Ampere font tourner des workloads de production chez Oracle Cloud, Microsoft Azure et Google Cloud. Le Grace CPU de NVIDIA est expédié dans des Grace Hopper Superchips déployés dans des clusters IA à travers le monde. La question n'est plus de savoir si ARM peut gérer des workloads serveur. La question est de savoir quels workloads justifient encore de payer la prime x86.

La thèse centrale est simple et étayée par des chiffres : les puces serveur ARM délivrent plus de débit par watt et plus de débit par dollar que leurs homologues x86 sur les workloads qui dominent les dépenses cloud modernes — serving web, microservices conteneurisés, cache en mémoire et inférence Machine Learning. L'x86 conserve de vrais avantages sur les logiciels legacy mono-thread, les workloads Windows Server et les applications avec des dépendances fortes aux extensions ISA x86. Tout le reste est une conversation sur la migration.

AWS Graviton 4 : Le Benchmark Qui a Changé la Donne

AWS Graviton 4, lancé fin 2023 et alimentant les familles d'instances R8g, C8g et M8g, est construit sur un cœur ARM Neoverse V2 personnalisé en procédé 3nm TSMC. La puce est livrée avec 96 cœurs, un support mémoire DDR5-5600 et un cache système de 75 Mo. AWS affirme que Graviton 4 offre jusqu'à 30 % de meilleures performances de calcul par rapport à Graviton 3, et jusqu'à 40 % de meilleures performances par watt par rapport aux instances x86 comparables de sa propre flotte.

Sur SPECrate2017_int_base, les tests tiers des instances Graviton 4 affichent des scores dans la plage de 650 à 700 en agrégé sur l'ensemble des cœurs, ce qui est compétitif face à l'Intel Xeon Sapphire Rapids à des niveaux de prix similaires, tout en consommant moins d'énergie à la frontière de l'instance. Pour les workloads Java — une part majeure des dépenses cloud entreprise — Graviton 4 obtient un débit environ 20 à 25 % plus élevé sur SPECjbb2015 que Graviton 3, qui surpassait déjà les instances Intel comparables sur ce benchmark.

L'argument tarifaire est direct. Une AWS m8g.4xlarge (16 vCPU, Graviton 4) coûte environ 0,616 $/heure à la demande en us-east-1. Une m7i.4xlarge comparable (16 vCPU, Intel Sapphire Rapids) tourne à environ 0,806 $/heure. C'est une réduction de coût de 24 % avant même de prendre en compte le fait que l'instance ARM gère souvent un débit de requêtes plus élevé par vCPU sur les workloads stateless.

Ampere Altra Max : 128 Cœurs, Prévisibilité Mono-Thread

L'Altra Max d'Ampere Computing est architecturalement différent du Graviton 4 de manière délibérée. Là où AWS utilise un design de cœur haute performance dérivé de Neoverse V2, Ampere utilise ses propres cœurs mono-thread — pas de simultaneous multithreading (SMT). L'Altra Max est livré avec jusqu'à 128 cœurs, fonctionnant chacun jusqu'à 3,0 GHz, avec un cache L3 de 128 Mo et une mémoire DDR4-3200 à 8 canaux. Le TDP se situe à 250–270 W pour la variante 128 cœurs.

L'absence de SMT est un choix de conception aux conséquences bien réelles. Les fournisseurs cloud utilisant l'Altra Max peuvent annoncer des vCPU mappés en 1:1 sur des cœurs physiques, éliminant la variance du noisy-neighbor qui affecte les instances x86 avec SMT sous charge mixte. Oracle Cloud Infrastructure utilise les instances Ampere A1 (Altra de génération précédente) à 0,01 $/OCPU-heure, ce qui en fait l'option de calcul la moins chère parmi les grands fournisseurs cloud. Les résultats de benchmarks de Phoronix sur des nœuds Altra Max montrent un scaling linéaire jusqu'à 128 threads sur des workloads embarrassingly parallel — quelque chose que les puces x86 avec SMT cessent de délivrer proprement au-delà de leur nombre de cœurs physiques.

La liste des workloads cibles d'Ampere ressemble à un catalogue d'infrastructure moderne : NGINX, HAProxy, Redis, Memcached, PostgreSQL avec des workloads à lecture intensive, et des microservices conteneurisés sur Kubernetes. Pour les équipes qui font tourner ces stacks, les instances Altra Max réduisent de manière mesurable le coût par requête.

NVIDIA Grace : ARM Rencontre HBM3 pour les Workloads IA

Le Grace CPU de NVIDIA, utilisé dans les configurations Grace Hopper et Grace Blackwell Superchip, est un design ARM Neoverse V2 à 72 cœurs connecté via NVLink-C2C aux dies GPU NVIDIA. Le Grace CPU lui-même affiche une bande passante mémoire de 500 Go/s en utilisant LPDDR5X, ce qui écrase ce que les canaux DDR5 conventionnels délivrent sur les plateformes serveur x86.

Dans le GH200 Grace Hopper Superchip, le CPU et le GPU H100 partagent un fabric mémoire unifié à 900 Go/s entre eux. Ce n'est pas une affirmation marketing — cela élimine le goulot d'étranglement PCIe qui limite l'utilisation du GPU dans les workloads d'inférence LLM où le modèle doit fréquemment déplacer des données entre la mémoire CPU et GPU. Pour l'inférence de grands modèles de langage et de modèles multimodaux, le GH200 délivre un nombre de tokens-par-seconde par dollar mesurément plus élevé que les configurations H100 SXM5 équivalentes utilisant des CPU hôtes x86, principalement en réduisant la latence de transfert de données.

Apple M4 Ultra dans le Mac Pro : ARM au Niveau du Workstation Professionnel

L'Apple M4 Ultra, annoncé pour le Mac Pro 2025, combine deux dies M4 Max via l'interconnexion UltraFusion, produisant une puce avec jusqu'à 80 cœurs CPU (60 performance, 20 efficacité), jusqu'à 80 cœurs GPU, et une architecture mémoire unifiée supportant jusqu'à 192 Go à plus de 800 Go/s de bande passante agrégée. Le TDP du système M4 Ultra tourne autour de 300 W de puissance système totale, comparable à celui d'un seul die Intel Xeon W haut de gamme.

Le Mac Pro n'est pas un serveur cloud, mais ses benchmarks éclairent directement le débat serveur. Dans Cinebench R24 nT, le M4 Ultra obtient environ 9 000 à 9 500 points en multi-cœur — comparable à un Threadripper 7970X qui consomme environ deux fois plus d'énergie. Les développeurs qui construisent et testent des applications conteneurisées ARM-native sur des Mac Pro M4 Ultra font déjà tourner des workloads équivalents à la production en local avant de déployer sur Graviton 4 ou Altra Max en production. L'alignement de l'écosystème logiciel se referme rapidement.

Les Avantages Architecturaux d'ARM pour le Travail Serveur

Les raisons pour lesquelles ARM l'emporte sur l'efficacité sont structurelles, pas temporaires. L'ISA ARM génère des empreintes d'instructions plus petites que l'x86, réduisant la pression sur le cache d'instructions. L'absence de logique x87 legacy et de décodage complexe à longueur variable signifie qu'une plus grande partie de chaque die est consacrée aux unités d'exécution et au cache. Les cœurs serveur ARM modernes comme Neoverse V2 et Neoverse N2 implémentent une exécution out-of-order avec des pipelines larges qui égalent ou dépassent le Golden Cove d'Intel et le Zen 4 d'AMD en débit par cycle pour les workloads entiers et intensifs en mémoire.

Les chiffres d'efficacité énergétique sont cohérents dans tous les tests indépendants. Les résultats SPECpower_ssj2008 — qui mesurent la performance par watt à différents niveaux de charge — montrent que les plateformes serveur ARM d'AWS, Ampere et NVIDIA sont 15 à 40 % plus efficaces que leurs équivalents x86 selon le workload et le niveau de charge. À l'échelle d'un datacenter, cette différence se mesure en mégawatts et en millions de dollars annuellement.

Là Où l'x86 Gagne Encore

L'honnêteté exige de reconnaître où l'x86 conserve l'avantage :

• Workloads Windows Server — AWS ne propose pas d'instances Graviton Windows ; les instances Azure Cobalt 100 ARM ne font tourner que Linux à partir de 2024. SQL Server et .NET Framework (pas .NET Core) restent dépendants de l'x86 en pratique.
• Applications legacy mono-thread — AMD EPYC Genoa et Intel Sapphire Rapids atteignent tous deux des fréquences boost par cœur plus élevées (jusqu'à 4,5 GHz) que les puces serveur ARM actuelles, ce qui importe pour les workloads sérialisés.
• Workloads dépendants d'AVX-512 — Les codes HPC et certains pipelines de transcodage vidéo sont optimisés manuellement pour les extensions SIMD Intel AVX-512. SVE2 d'ARM est compétitif mais nécessite une recompilation et un re-tuning.
• Logiciels ISV avec licence x86 uniquement — Oracle Database, SAP HANA et plusieurs outils EDA commerciaux ne supportent soit pas ARM, soit ont des conditions de licence séparées qui effacent l'avantage en coût.

Points d'Action pour les Ingénieurs qui Choisissent des Instances Cloud

• Commencez votre migration ARM avec les workloads HTTP stateless en premier. NGINX, Node.js, Go et les APIs Python conteneurisées se compilent proprement en ARM64 et affichent le retour sur investissement le plus rapide. Utilisez des instances AWS C8g ou OCI Ampere A1 et effectuez un test de charge A/B par rapport à votre baseline x86 actuelle avant de vous engager.
• Pour les services Java, activez Graviton 4 de manière agressive. La JVM supporte ARM64 depuis des années. Les propres benchmarks d'AWS montrent des gains de débit de 20 à 30 % sur les workloads Spring Boot et Quarkus sur Graviton 4 par rapport aux instances Intel comparables à moindre coût.
• Pour l'inférence IA à grande échelle, évaluez le GH200 avant de vous rabattre par défaut sur H100 + x86. L'architecture mémoire unifiée élimine un vrai goulot d'étranglement pour les modèles au-dessus de 70 milliards de paramètres. Demandez l'accès via AWS, CoreWeave ou NVIDIA DGX Cloud pour benchmarker votre modèle spécifique.
• Ne migrez pas encore les workloads Windows Server ou HPC AVX-512 à moins d'avoir confirmé des builds ARM-native et de les avoir testés. Les économies de coûts ne se matérialisent pas si le workload sous-performe ou nécessite des bibliothèques spécifiques à l'ISA qui n'ont pas encore été portées.
• Utilisez les instances Ampere Altra Max pour Redis, Memcached et NGINX. Le mapping vCPU-to-core en 1:1 et le scaling linéaire des threads rendent la prévisibilité de la latence mesurément meilleure que les instances x86 avec SMT sous charge variable.

Le moment serveur d'ARM n'est pas en train d'arriver — il est arrivé. Le travail restant est la migration systématique des workloads qui tournent encore sur x86 par inertie plutôt que par nécessité.