Axion, le CPU Arm de Google Cloud : quand et comment il vaut la peine de migrer

Cymbal Shops grandissait, et la croissance apportait un symptôme reconnaissable : la dépendance aux VM à usage général causait des retards de performance et épuisait les ressources destinées à construire des fonctions d'IA. La migration de son e-commerce vers Google Cloud avec une infrastructure optimisée « powered by Google Axion » a donné des résultats immédiats et a libéré du budget pour l'IA générative. Ce qui rend ce cas précieux, c'est qu'il n'est pas venu seulement avec une facture plus légère : il est venu avec un critère pour choisir où faire tourner chaque charge. Le matériel de « Fundamentals of Google's Arm-based Axion Processors », de Google Skills, est celui que je déroule ici.

Le problème de fond : legacy et usage général

L'entrée dans le sujet est un chiffre qui cadre tout : les systèmes legacy captent deux tiers de la dépense technologique mondiale. Par-dessus, l'infrastructure à usage général touche ses limites de prix/performance et d'échelle, tandis que les organisations poursuivent trois mandats qui se contredisent : accélérer l'innovation d'IA, moderniser les applications et atteindre des objectifs ambitieux de durabilité environnementale.

Quand le calcul à usage général est le goulot d'étranglement, la question n'est plus combien de serveurs il faut, mais quel type de processeur convient à chaque profil de charge.

x86 et Arm : où l'histoire se termine et où elle continue

Deux philosophies aux origines différentes. x86 (CISC, instructions complexes) est né avec les PC, a grandi dans les data centers et fait aujourd'hui tourner la plupart des applications dans le cloud ; ses cœurs ont ajouté des fonctionnalités et des extensions riches, comme l'encodage média, le chiffrement, le calcul confidentiel et la compression, en peu d'opérations. Arm (RISC, instructions réduites) est né pour le mobile et l'edge, avec un jeu d'instructions plus petit qui utilise moins d'énergie et moins de transistors pour des opérations simples et bien définies.

La réponse du matériel à « quand j'utilise x86 et quand Arm ? » est, textuellement, qu'aujourd'hui la différence importe peu : les deux offrent une performance de grande qualité pour les charges cloud, et peu de programmeurs écrivent de l'assemblage pour leur processeur. Restent deux nuances. Les systèmes haute fréquence qui utilisent de l'assemblage ajusté continuent de s'optimiser sur x86, avec des décennies d'optimisation derrière. Et côté efficacité, Axion occupe moins de la moitié de l'espace physique de silicium d'autres processeurs, avec l'efficacité énergétique que cela implique.

La lecture implicite est celle de l'efficacité, pas de la relève : Arm apparaît comme l'option d'efficacité pour la plupart des charges, et non comme un remplacement universel de x86.

Axion : le premier CPU Arm personnalisé de Google pour le cloud

Axion est le premier CPU Arm personnalisé de Google pour le cloud, et le mot qui explique son conception est l'intégration verticale. En le concevoir en interne, les équipes support, ingénierie logicielle et hardware sont sous un même toit, de sorte que le retour des clients parvient vite à l'équipe hardware pour concevoir de nouvelles versions. Co-concevoir hardware et logiciel pour des services optimisés à l'échelle de la planète est la stratégie, et le résultat concret est qu'Axion a été construit pour s'intégrer avec le logiciel Google comme Cloud SQL, GKE et Spanner.

Ce n'est pas la première fois que Google fabrique son propre silicium : il y a six générations de TPU, deux d'unités de codage vidéo (avec jusqu'à 33 fois plus d'efficacité en transcodage vidéo) et trois de puces tensorielles pour mobile. Axion rejoint cette ligne. Et il vaut la peine de regarder le cadrage de fond : toute stratégie de cloud cherche à extraire le maximum de l'infrastructure, et le pari du design vertical est que cette performance se décide dans le co-design et ne se rattrape pas après avec des réglages d'application.

C4A et N4A, et pourquoi il vaut les déployer ensemble

Les séries de machines couvrent le spectre du calcul à usage général avec deux objectifs opérationnels distincts. C4A est pour la haute performance et les charges plus exigeantes. N4A est pour la performance équilibrée, quand le pic n'est pas requis en permanence.

Le guide « better together » est la recommandation que donne le matériel et la partie la plus ignorée en pratique : traiter l'environnement comme un écosystème à paliers et déployer les deux séries, en utilisant l'outil adapté à chaque travail.

flowchart LR
    subgraph Tier[Écosystème à paliers]
        C[C4A : haute performance] --> N[N4A : performance équilibrée]
    end

Les charges se répartissent ainsi. Pour C4A : serveurs de jeu, inférence IA/ML, streaming de médias, bases de données relationnelles, bases de données et caches en mémoire, analytique de données et intelligence d'affaires. Pour N4A : microservices, dépôts de code, bureaux virtuels, stockage et archivage, traitement par lots, CRM, applications internes et dev/test.

Les chiffres de la feuille de ressources accompagnent la recommandation. C4A : jusqu'à 10 % de performance en plus que les instances Arm des fournisseurs leaders, jusqu'à 65 % de meilleur prix/performance et jusqu'à 60 % d'efficacité énergétique en mieux que des VM x86 comparables de génération actuelle. N4A : jusqu'à 91 % de performance en plus que les instances Arm leaders pour les charges SIR17 (le matériel ne définit pas l'acronyme), jusqu'à 2x de meilleur prix/performance et jusqu'à 105 % de meilleur prix/performance face à la génération x86 comparable.

Le cas Cymbal Shops a appliqué cette approche par paliers : il a cessé de payer trop cher la performance sur des tâches secondaires et a réinvesti cette économie dans le développement d'IA générative haute priorité.

Les sept vitesses de migration

Le cadre de migration ordonne les chemins du plus rapide au plus lent, pour que chaque application du portefeuille ait le chemin le plus court vers Arm.

flowchart TD
    S1[1. Services gérés : appuyer deploy] --> S2[2. Conteneurs : node pools Axion et multi-arch]
    S2 --> S3[3. Interprétés : image ARM64]
    S3 --> S4[4. Nginx, MySQL, Linux : paquets Arm]
    S4 --> S5[5. Compilés : cross-compiler]
    S5 --> S6[6. .NET et Windows : Cloud Run ou porter]
    S6 --> S7[7. Bibliothèques spécifiques : refactorer]

Services gérés. Cloud SQL, Spanner et GKE sont déjà optimisés pour Arm : la migration, c'est essentiellement appuyer deploy.

Charges conteneurs. Choisir les bons node pools Axion et préparer les conteneurs pour le multi-arch avec le guide des charges Arm.

Langages interprétés sur Linux. Java, Python, Node.js, PHP et Ruby : passer l'image en ARM64 et laisser pip, Maven, npm ou Gems installer les dépendances compilées pour Arm.

Nginx, MySQL et applications Linux. Choisir des VM Axion et installer les paquets Arm existants ; beaucoup tournent plus vite sur Arm, avec des guides de réglage disponibles.

Langages compilés sur Linux. C, C++, Go et Rust suffisent généralement avec une recompilation en visant Arm via un cross-compiler compatible ; dans certains cas il faut ajuster les tailles d'entiers et l'endianness, des tâches de routine pour beaucoup d'équipes d'ingénierie.

.NET et applications Windows. Les applications .NET peuvent s'héberger directement sur Cloud Run ; pour les autres il faut décider si porter sur Linux/Arm est viable ou explorer d'autres stratégies.

Bibliothèques spécifiques au processeur. Une forte dépendance à des bibliothèques ou optimisations spécifiques signifie un refactoring important ou des solutions alternatives, avec une roadmap définie avec Google.

Le cadre identifie le chemin le plus rapide pour chaque application du portefeuille, et l'ordre n'est pas décoratif : on commence toujours là où il n'y a pas de code à toucher. Et un raccourci pour ceux qui tournent déjà en Arm : si la charge vit sur Azure ou AWS, la migration « move-to-move » avec Migrate to Virtual Machines amène l'instance vers Google Cloud avec une ré-architecture minimale.

L'instance de test

La démonstration du matériel fait le parcours complet dans la console. Create Instance, nom descriptif, région et zone par défaut, type de machine N4A avec 2 vCPU et 8 Go de mémoire, Debian comme système d'exploitation (les machines Axion utilisent Hyperdisk), et Create. En chemin, le choix du système d'exploitation confirme un détail pratique : les autres systèmes d'exploitation compatibles Arm se cherchent comme dans n'importe quelle autre famille de CPU, et les options réseau restent par défaut.

La vérification a deux marches. Dans la vue détaillée, le disque de démarrage montre l'architecture ARM 64 et la plateforme CPU apparaît comme Google Axion avec architecture ARM 64. Et en SSH depuis la console intégrée, uname révèle la version du kernel Arm et l'architecture aarch64.

Ce qui ferme la démonstration est le geste le plus simple de tous : installer Nginx avec le gestionnaire de paquets standard, sans configuration extra pour être une instance Axion, et voir avec curl qu'il sert sa page par défaut.

Outils, accompagnement et la route en trois étapes

Quatre outils accompagnent la migration. Migration Center évalue l'environnement et construit un plan basé sur les données, en estimant la dépense, en découvrant les actifs et en recommandant des ressources. Migrate to Virtual Machines couvre la migration move-to-move depuis d'autres clouds Arm. RaMP est un programme holistique de bout en bout pour évaluer, exécuter et réduire le risque de la transformation. Et Google Cloud Consulting propose l'engagement « Migration Accelerator » de quatre semaines, avec des roadmaps expertes et une analyse financière.

La route que le matériel répète en trois étapes sert de checklist de départ : identifier les charges aptes aux bénéfices d'Arm, implémenter une preuve de concept avec des spécialistes Google, PSO ou partenaires, et migrer et déployer avec des services professionaux ou un partenaire. La feuille de ressources sert de référence rapide téléchargeable, avec les chiffres de chaque famille et les charges recommandées sur une seule page.

Ce que le cadrage laisse et ce qui est resté non exécuté

Ce qui survit aux changements d'interface, ce sont deux idées. Choisir la famille par profil de charge (pic soutenu sur C4A, profil équilibré sur N4A) et les combiner comme écosystème, pas comme choix unique. Et migrer par le chemin le plus court des sept vitesses, plutôt que par celui que le portefeuille paraît mériter.

Ce qui est resté non exécuté dans cette documentation : le quiz n'a ni été ouvert ni soumis, la credential n'a pas été réclamée, le terme SIR17 n'est pas défini dans le matériel téléchargé, et partie du matériel bundle contient du texte de gabarit d'un autre cadre de migration avec des marqueurs non remplis qui ne correspond pas au contenu d'Axion.

---

*Source : « Fundamentals of Google's Arm-based Axion Processors », de Google Skills (cours google.axion-processors).*