Ampere Computing : processeurs Arm et options cloud

Ampere Computing conçoit des processeurs de serveur fondés sur l’architecture Arm pour le cloud, les centres de données et les infrastructures associées. Ses familles Altra et AmpereOne sont des CPU : elles exécutent des systèmes d’exploitation, des services applicatifs et des calculs compatibles. Elles sont distinctes de l’architecture GPU Ampere de NVIDIA.

Pour évaluer un serveur ou une instance cloud Ampere, les questions concrètes concernent la compatibilité logicielle, les performances de l’application, la mémoire disponible et le coût total d’exploitation. Le nombre de cœurs et le jeu d’instructions ne suffisent pas à y répondre. Ce guide présente les familles de processeurs, leurs usages chez les fournisseurs cloud et une méthode pour évaluer une migration.

Que fait Ampere Computing ?

Ampere est une entreprise de conception de semi-conducteurs basée à Santa Clara, en Californie, fondée par Renée James. Elle développe des CPU de serveur qui implémentent le jeu d’instructions Arm 64 bits. Les fabricants construisent des serveurs autour de ces processeurs, tandis que les fournisseurs cloud peuvent en proposer l’accès sous forme de machines virtuelles ou de matériel dédié.

En mars 2025, SoftBank a annoncé un accord pour acquérir Ampere Computing dans le cadre d’une transaction de 6,5 milliards de dollars en numéraire. L’acquisition a été finalisée le 25 novembre 2025, faisant d’Ampere une filiale détenue à 100 % par SoftBank Group. Cette opération finalisée est distincte de toute future sortie de processeur ou de tout engagement de déploiement.

La proximité des noms peut prêter à confusion. NVIDIA Ampere désigne une architecture GPU ; Ampere Computing est l’entreprise qui conçoit les CPU de serveur présentés ici. Pour choisir entre différents types de processeurs, notre comparatif des CPU, GPU et NPU explique leurs rôles respectifs.

Les processeurs Ampere : Altra, Altra Max et AmpereOne

La documentation actuelle d’Ampere couvre plusieurs familles. Le tableau résume les caractéristiques publiées des processeurs, et non les ressources garanties par une instance cloud donnée. Une VM peut n’exposer qu’une partie de la capacité du serveur.

Famille de processeurs	Nombre de cœurs publié	Interface mémoire	Connectivité PCIe
Altra	32, 64 ou 80	DDR4-3200 sur 8 canaux	128 lignes PCIe 4.0
Altra Max	96 ou 128	DDR4-3200 sur 8 canaux	128 lignes PCIe 4.0
AmpereOne	96 à 192	DDR5 sur 8 canaux, jusqu’à 5 200 MT/s	128 lignes PCIe 5.0
AmpereOne M	96 à 192	DDR5-5600 sur 12 canaux	96 lignes PCIe 5.0

Sources : les fiches produit Ampere des familles Altra, AmpereOne et AmpereOne M. Une configuration Altra à plusieurs sockets peut affecter des lignes au CCIX. Vérifiez les connexions réelles des périphériques, les modules mémoire installés et la prise en charge par le micrologiciel.

Ces familles utilisent des cœurs à un seul thread matériel. AmpereOne et AmpereOne M disposent de cœurs compatibles Arm conçus par Ampere, et la famille M modifie l’équilibre entre mémoire et entrées-sorties. Tous les processeurs Ampere ne sont donc pas un même produit décliné avec différents nombres de cœurs.

Davantage de cœurs peut aider lorsque le travail se répartit entre des requêtes ou des processus indépendants. Cela ne garantit ni une latence plus faible pour une requête, ni une exécution plus rapide du code séquentiel, ni une bande passante mémoire suffisante pour tous les cœurs simultanément. Comparez la configuration complète et le comportement de l’application.

Quels fournisseurs cloud proposent des instances Ampere ?

De grands fournisseurs documentent des services précis utilisant Ampere. Comparez les noms des familles d’instances : la seule mention « Arm » n’identifie pas le fabricant du processeur.

Fournisseur	Exemple documenté	Famille de processeurs
Microsoft Azure	Machines virtuelles Dpsv5	Ampere Altra
Google Cloud	Machines virtuelles Tau T2A	Ampere Altra
Oracle Cloud Infrastructure	A1 Compute et A2 Compute	Altra pour A1 ; AmpereOne pour A2

Consultez les caractéristiques actuelles d’Azure Dpsv5, la documentation Arm de Google Cloud et le guide OCI des ressources de calcul Arm. Les instances C4A de Google, fondées sur Axion, utilisent par exemple un processeur différent de celui des Tau T2A.

Vérifiez la région, les quotas, les images de système d’exploitation disponibles, le stockage, les limites réseau et la définition d’un vCPU ou d’un OCPU chez le fournisseur. Des nombres identiques ne désignent pas nécessairement les mêmes ressources matérielles. Confirmez les tarifs actuels de l’instance complète et des services nécessaires au lieu de reprendre un ancien prix horaire.

Quelles applications méritent un essai ?

Les services web, les services applicatifs, les caches et les applications conteneurisées constituent des points de départ utiles lorsque leurs dépendances prennent en charge Arm64. Ils permettent souvent de répartir les requêtes entre plusieurs processus de traitement. Le débit et le comportement sous accès concurrents deviennent alors des mesures pertinentes.

Les bases de données exigent une évaluation plus précise. Testez la version du moteur, les extensions, les accès au stockage, les données utilisées en mémoire et la procédure de restauration. Un changement de CPU peut avoir peu d’effet si l’application passe l’essentiel de son temps à attendre le stockage ou un service distant.

Les processeurs Ampere peuvent également exécuter des tâches d’inférence compatibles sur CPU. Leur pertinence dépend du modèle, du moteur d’exécution, du format numérique, de la taille des lots, de la latence visée et du volume de requêtes. L’entraînement à grande échelle et l’inférence exigeante peuvent nécessiter des accélérateurs. Un nombre élevé de cœurs CPU ne démontre pas une équivalence avec un GPU.

Le calcul scientifique demande la même prudence. Vérifiez le solveur, les bibliothèques numériques, les exigences de précision et le comportement lors de l’ajout de ressources. Notre guide des serveurs HPC couvre les besoins du système complet, notamment la mémoire, le stockage et les interconnexions.

La compatibilité logicielle est le premier point à vérifier

Arm64 et x86-64 sont des jeux d’instructions différents. Un exécutable x86-64 ne devient pas une application Arm native lorsqu’on le copie sur un serveur Ampere. Il faut une version Arm64 prise en charge, une recompilation adaptée du code source ou une approche d’émulation explicitement évaluée.

Examinez toute la pile logicielle : système d’exploitation, moteur d’exécution, paquets, extensions natives, pilotes de base de données, agents de supervision, outils de sécurité et logiciels sous licence. Un langage peut prendre en charge Arm64 alors qu’une dépendance indispensable ne le fait pas. Vérifiez les versions exactes et les conditions de support de l’éditeur avant de mobiliser l’équipe pour la migration.

Les conteneurs dépendent toujours de l’architecture

Un conteneur regroupe des logiciels ; il ne supprime pas les exigences de compatibilité du CPU. La documentation Docker sur les builds multiplateformes explique comment une image peut contenir des variantes distinctes, telles que linux/amd64 et linux/arm64. Confirmez que l’image déployée contient la variante nécessaire.

L’émulation peut aider pendant le développement ou une transition, mais ses performances doivent être mesurées séparément de celles d’une version native. Testez sur l’architecture serveur prévue avant de tirer des conclusions pour la production. Incluez la construction des images, le téléchargement des dépendances, le démarrage et la reprise après incident, au-delà du simple lancement de l’application.

Vérifier le système d’exploitation pris en charge

Choisissez une image Arm64 prise en charge par le fournisseur et l’application. La disponibilité de Windows sur des appareils Arm ne démontre pas la compatibilité de Windows Server avec l’instance cloud choisie. Consignez l’image exacte et la version du noyau pour pouvoir reconstruire l’environnement.

Comparer performances, efficacité énergétique et coûts

Commencez par un besoin de service : requêtes traitées avec une latence acceptable, tâches validées par heure ou réponses d’inférence au niveau de qualité requis. Comparez ensuite des configurations qui répondent à ce besoin. Un prix horaire inférieur n’est utile que si le service atteint toujours son objectif.

Mesurez le débit, les percentiles de temps de réponse, le taux d’erreur, l’utilisation de la mémoire et le comportement des ressources partagées. Répétez les essais avec une concurrence réaliste, y compris pendant une période chargée. Une latence moyenne peut masquer un petit groupe de requêtes lentes ayant des conséquences sur l’exploitation.

Pour comparer la consommation de matériel détenu en propre, mesurez le système complet sur une charge représentative. Les caractéristiques électriques du CPU ne correspondent pas à l’énergie totale consommée par le serveur. Incluez les périodes d’inactivité et les équipements environnants lorsqu’ils entrent dans le périmètre étudié. L’architecture seule ne démontre pas une réduction de l’empreinte carbone.

Dans le cloud, comptez le calcul, le stockage, les transferts, les licences, la supervision, le support et le travail de migration. Pour un achat, ajoutez l’installation, l’électricité, le refroidissement, la maintenance et la capacité de réserve. Notre guide d’achat et de location de serveurs explique ces catégories de coûts.

Le coût total par unité de travail terminée et conforme à vos critères constitue une mesure utile. Conservez les données de test et les configurations pour les personnes qui examineront la décision. Un résultat publié par un fournisseur ou un client peut orienter les essais, mais ne prédit pas le résultat d’une autre application.

Une méthode pratique pour évaluer Ampere

1. Choisir un service représentatif. Documentez les types de requêtes, le volume de données, la latence requise, les besoins de disponibilité et le coût d’exploitation actuel.
2. Vérifier la compatibilité Arm64. Répertoriez les dépendances et identifiez les binaires incompatibles, les extensions natives ou les restrictions des éditeurs.
3. Construire un environnement reproductible. Fixez les versions, créez les images adaptées et vérifiez le déploiement et la supervision.
4. Effectuer des tests comparables. Utilisez les mêmes données et critères, consignez les ressources allouées et testez la demande habituelle comme les pics.
5. Valider l’exploitation. Testez les sauvegardes, la restauration, les mises à jour et le retour arrière avant de transférer le trafic de production.
6. Décider à partir des mesures. Intégrez le travail de migration et de maintenance. Étendez le déploiement uniquement si l’avantage se confirme dans une comparaison réaliste.

Gardez le déploiement existant disponible pendant une première mise en service. Définissez les conditions qui déclenchent un retour arrière et les personnes habilitées à le décider. Une migration est terminée lorsque l’équipe sait exploiter et restaurer le service, pas simplement lorsqu’il démarre sur le nouveau CPU.

Que prévoit la feuille de route AmpereOne ?

Ampere a annoncé AmpereOne Aurora en juillet 2024 comme un futur produit pouvant compter jusqu’à 512 cœurs. Une annonce de feuille de route ne constitue ni une fiche d’achat ni une preuve de disponibilité. Avant de planifier un projet autour d’un processeur annoncé, demandez les caractéristiques actuelles du système, une confirmation de disponibilité, la liste des logiciels pris en charge et les conditions de livraison.

Questions fréquentes

Ampere Computing et Arm sont-ils la même entreprise ?

Non. Arm fournit des technologies d’architecture et de processeur. Ampere Computing conçoit des processeurs de serveur qui implémentent le jeu d’instructions Arm. Les noms désignent deux entreprises différentes.

Ampere fabrique-t-il des GPU ?

Les produits Altra et AmpereOne présentés ici sont des CPU. L’architecture distincte Ampere de NVIDIA concerne des GPU. Vérifiez le fabricant et la référence exacte lorsque vous consultez des caractéristiques.

Une instance Ampere coûte-t-elle moins cher qu’une instance x86 ?

C’est possible pour une application adaptée, mais cela dépend de l’instance, des performances, des services associés et des coûts de migration. Comparez le coût par résultat utile au niveau de service requis.

Une application existante peut-elle migrer vers Ampere sans modification ?

Certaines applications exigent peu de modifications du code lorsque toute leur pile prend déjà en charge Arm64. Les fichiers de déploiement, les dépendances, les tests et le support opérationnel restent à examiner. Il n’existe pas de garantie générale de compatibilité.