VPS ARM ou x86 : quelles différences concrètes ?

Ce qui change lorsque vous passez à un VPS ARM

Un VPS ARM utilise le même Linux et le même Nginx qu’un VPS x86. Son coût par cœur est généralement inférieur. Le principal risque concerne la compatibilité. Un programme compilé pour x86-64 ne peut pas fonctionner sur arm64. Chaque logiciel de votre stack doit donc fournir une build arm64 ou pouvoir être recompilé.

La plupart des stacks modernes passent ce test sans modification. Les problèmes se concentrent à deux endroits : les images de conteneurs qui n’ont été construites que pour une seule architecture et les logiciels propriétaires sans téléchargement arm64. Les commandes ci-dessous répondent à ces deux questions pour votre propre stack, avant que vous ne payiez une instance. Si vous cherchez encore à déterminer le type de serveur dont vous avez besoin, commencez par ce qu’est un VPS et en quoi il diffère d’un hébergement mutualisé.

arm64, aarch64, amd64 : quelle différence entre ces noms ?

Exécutez ces commandes sur n’importe quelle instance avant toute autre opération.

uname -m
dpkg --print-architecture
lscpu | head -n 12
getconf PAGESIZE

uname -m affiche aarch64 sur une machine ARM et x86_64 sur une machine Intel ou AMD. dpkg --print-architecture affiche arm64 et amd64 sur ces deux mêmes machines. Les deux réponses sont correctes. Le noyau Linux et le système de packaging Debian ont choisi des noms différents pour le même jeu d’instructions. aarch64 et arm64 désignent donc une architecture, tandis que x86_64 et amd64 désignent l’autre. Docker utilise les noms du système Debian, raison pour laquelle la plateforme d’une image s’écrit linux/arm64.

Sur arm64, il n’y a pas de ligne model name dans /proc/cpuinfo. Vous obtenez à la place un champ Features, où les fonctions cryptographiques matérielles apparaissent sous forme de flags tels que aes pmull sha1 sha2. Il s’agit des extensions cryptographiques d’ARMv8. Elles remplissent le même rôle qu’AES-NI sur les processeurs Intel et AMD : elles accélèrent matériellement TLS (transport layer security) et le chiffrement des disques. Vérifier l’accélération matérielle AES sur un VPS présente le test pour les deux architectures.

Pourquoi les conteneurs échouent en premier, et à quoi ressemble l’erreur

Chaque manifeste d’image Docker indique l’architecture pour laquelle l’image a été construite. Si vous téléchargez sur un hôte arm64 une image qui ne possède qu’un manifeste amd64, le téléchargement réussit. L’échec survient au démarrage du premier processus :

WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
exec /usr/local/bin/docker-entrypoint.sh: exec format error

exec format error correspond au refus du noyau d’exécuter le fichier, car son en-tête ELF (executable and linkable format) indique un type de machine que ce CPU ne prend pas en charge. Aucun paramètre ne peut résoudre ce problème. Les instructions ne sont pas présentes dans le silicium.

Vérifiez le manifeste avant le déploiement :

docker buildx imagetools inspect nginx:1.27

La sortie affiche une ligne Platform: pour chaque image du manifest list, par exemple linux/amd64 et linux/arm64. Si linux/arm64 est absent, ce tag ne démarrera pas sur un VPS ARM. docker manifest inspect --verbose nginx:1.27 affiche les mêmes informations, mais Docker documente docker manifest comme une commande expérimentale dont le comportement peut changer entre les releases. Préférez donc imagetools.

Pour les images que vous construisez vous-même, construisez les deux architectures avec une seule commande, puis poussez un manifest list :

docker buildx build --platform linux/amd64,linux/arm64 -t registry.example.com/app:1.4 --push .

Construire pour une architecture différente sur un seul hôte nécessite que l’émulation QEMU en mode utilisateur soit enregistrée auprès du gestionnaire binfmt_misc du noyau :

docker run --privileged --rm tonistiigi/binfmt --install all

Utilisez l’émulation pour construire et tester. Ne l’utilisez pas pour servir du trafic. La documentation Docker indique que l’émulation avec QEMU « peut être beaucoup plus lente que les builds natifs, en particulier pour les tâches exigeantes en calcul comme la compilation et la compression ou la décompression ». Un service x86 émulé sur une instance ARM annule donc l’économie qui a motivé la migration. La configuration de l’hôte est identique dans le cas natif sur les deux architectures : exécuter Docker sur un VPS la présente, et un fichier Compose existant fonctionne sans modification dès que chaque image qu’il référence possède un manifeste arm64.

Les paquets dont j’ai besoin existent-ils pour arm64 ?

Ubuntu et Debian construisent presque toute leur archive pour arm64. apt install nginx postgresql redis-server se comporte donc de la même manière sur les deux architectures. Les dépôts tiers sont la principale source de différences.

Interrogez directement apt sur l’instance ARM :

apt-cache policy some-vendor-agent
apt-get install -s some-vendor-agent

Le résultat apt-cache policy avec Candidate: (none) signifie qu’aucun dépôt activé ne publie de build de ce paquet pour cette architecture. apt-get install -s simule l’installation sans rien écrire. Dans le même cas, la commande se termine par E: Unable to locate package.

Lisez ensuite la sortie de apt update au lieu de la faire défiler sans la consulter. Un dépôt fournisseur limité à amd64 l’indique explicitement :

N: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://repo.example.com/apt stable InRelease' doesn't support architecture 'arm64'

Le dépôt est configuré et accessible, mais il ne contient aucun paquet que cette machine puisse installer. Vérifiez également l’entrée de source elle-même. Une ligne avec [arch=amd64] est ignorée sur un hôte arm64. Le paquet semble alors manquant, alors que la cause réelle est cette restriction.

Quels workloads sont sûrs et lesquels nécessitent une vérification préalable

Les runtimes interprétés et bytecode sont conçus pour être portables. PHP, Python, Ruby et Node.js proposent tous des packages arm64 dans les distributions principales. Go et Rust se compilent pour arm64 en définissant une seule cible. Une stack LEMP, une API Node, un binaire Go derrière Nginx ou une base de données Postgres constituent des usages courants sur arm64.

Un compilateur just in time (JIT) produit du code machine pendant l’exécution du programme. Il a donc besoin d’un générateur de code pour l’architecture cible. Les versions actuelles en proposent un : OpenJDK, .NET, le moteur V8 intégré à Node.js et PyPy prennent tous en charge arm64 sous Linux. Le vrai risque concerne les anciennes versions figées. Un script de déploiement qui installe une version de runtime publiée il y a plusieurs années doit être vérifié dans les notes de cette version pour confirmer la prise en charge de aarch64. Il ne faut pas supposer qu’elle fonctionnera.

Les bibliothèques qui contiennent de l’assembleur x86 écrit manuellement ou des intrinsics SSE et AVX constituent un cas moins visible. La plupart disposent aussi d’un chemin NEON (NEON est le jeu d’instructions vectorielles d’ARM) ou d’une solution de repli en C standard. Elles se compilent et s’exécutent donc normalement. Les performances peuvent être meilleures ou moins bonnes que celles du build x86. Mesurez-les sur votre instance au lieu de les déduire d’un article.

Les logiciels propriétaires constituent le véritable blocage. Un agent de monitoring fourni par un éditeur, un driver de base de données sous licence, un control panel commercial ou un daemon antivirus est livré sous forme de binaire compilé. Si l’éditeur ne publie pas de build arm64, vous ne pouvez rien y faire. cPanel et WHM en sont le cas le plus clair dans l’hébergement : leur configuration système requise mentionne x86_64 et ne liste pas ARM. Un serveur avec control panel reste donc sur x86 (vérifié en août 2026 ; cette information mérite d’être revérifiée sur la page officielle des prérequis de l’éditeur). Si c’est le seul élément qui vous retient, les alternatives à cPanel à utiliser sur un VPS constituent le point de départ. Vérifiez ensuite la prise en charge de l’architecture pour chacune d’elles de la même manière.

Noyaux et taille des pages : les différences qui subsistent entre les instances ARM

Les serveurs x86-64 sont presque interchangeables. Les serveurs ARM sont moins uniformes, et les différences se situent sous votre application.

La taille des pages est la différence qui atteint la production. La plupart des noyaux arm64 utilisent des pages de 4 KiB, comme x86-64. Certains utilisent des pages de 64 KiB. Red Hat Enterprise Linux 8 pour aarch64 fournissait par défaut un noyau avec des pages de 64 KiB, tandis que RHEL 9 a rétabli la valeur par défaut à 4 KiB tout en conservant un paquet kernel-64k distinct pour les charges de travail qui nécessitent une taille supérieure. Une taille de page de 64 KiB augmente le minimum de mémoire requis par un processus comportant de nombreux mappings de petite taille, car le plus petit bloc que le noyau peut allouer est seize fois plus grand. Exécutez getconf PAGESIZE sur l’instance et lisez la valeur affichée au lieu de la déduire.

Quelques différences plus limitées méritent également d’être connues. Il n’existe pas de paquet de microcode CPU fourni par le système d’exploitation sur arm64. Les mises à jour du firmware proviennent donc de votre fournisseur, et non de apt. Les serveurs ARM démarrent via l’UEFI (unified extensible firmware interface) et décrivent leur matériel via l’ACPI (advanced configuration and power interface). Certaines fonctions x86 n’ont aucun équivalent ARM, notamment le chiffrement de la mémoire AMD SEV et les GPU médiés Intel GVT-g.

La plateforme serveur ARM est-elle arrivée à maturité ?

Sur le plan logiciel, oui. Debian, Ubuntu, Fedora et RHEL proposent tous des builds arm64 de premier ordre, et les images officielles sur Docker Hub sont généralement multi-architecture.

L’exemple récent le plus clair est Proxmox. Le 5 August 2026, Proxmox a annoncé la première édition arm64 officiellement prise en charge de Proxmox Virtual Environment, la version 9.2. Elle partage les dépôts de paquets et le cycle de publication avec l’édition x86-64. Elle repose sur Debian 13.5, avec Linux 7.0, QEMU 11.0, LXC 7.0 et ZFS 2.4. La configuration et les outils correspondent à ceux de x86-64, à l’exception de quelques éléments spécifiques à l’architecture.

Lisez les réserves présentées dans cette même annonce. Elles montrent à quel point le matériel serveur ARM officiellement pris en charge reste limité. Proxmox a validé les systèmes NVIDIA Grace et NVIDIA Vera dès le lancement, après des tests menés conjointement avec NVIDIA et Supermicro sur du matériel Grace Hopper. Les autres matériels ARMv8-A et ARMv9-A reposant sur UEFI bénéficient d’une prise en charge au mieux des possibilités. Les single-board computers utilisant uniquement un device tree, comme le Raspberry Pi, ne sont pas pris en charge. Un guest ne peut s’exécuter que sur un node de sa propre architecture. La live migration fonctionne uniquement entre des nodes de même architecture. Les clusters d’architectures mixtes ne sont pas officiellement pris en charge.

C’est la situation réelle en August 2026. Le fait qu’un éditeur d’hyperviseur propose arm64 selon le même cycle de publication que x86-64 représente un progrès concret pour la plateforme. La liste du matériel pris en charge dès le lancement se limite à two CPU families.

Liste de vérifications à effectuer avant de vous engager

1. Exécutez uname -m sur une instance de test et vérifiez qu’il affiche aarch64.
2. Exécutez docker buildx imagetools inspect sur chaque image de votre fichier Compose et vérifiez la présence d’une ligne de plateforme linux/arm64 pour chacune.
3. Exécutez apt update sur l’instance ARM et lisez chaque avertissement Skipping acquire affiché.
4. Ouvrez la page de téléchargement de chaque agent closed source dont vous dépendez et recherchez explicitement une build arm64 ou aarch64.
5. Exécutez getconf PAGESIZE et notez la réponse avant de dimensionner la mémoire.
6. Effectuez votre propre benchmark sur le plan ARM et sur le plan x86 entre lesquels vous hésitez.

Ce que cet article ne prétend pas établir

Nous n’allons pas vous fournir de ratio prix/performances entre ARM et x86. Le prix par cœur varie selon le fournisseur et l’offre, et une valeur mesurée sur le matériel de quelqu’un d’autre ne permet pas de prédire les performances du vôtre. Mesurez-les plutôt vous-même. Notre guide des benchmarks d’un VPS couvre sysbench et fio avec une méthode reproductible, et ce que coûte réellement un VPS traite l’aspect tarifaire de la comparaison. Le stockage constitue une décision distincte de l’architecture CPU, et comparaison entre NVMe et SSD SATA sur un VPS couvre cet aspect. Exécutez le même test sur les deux offres, avec votre propre charge de travail lorsque c’est possible, puis laissez vos mesures trancher.

FAQ

Mes conteneurs Docker fonctionneront-ils sur un VPS ARM ?

Ils fonctionneront si chaque image de la stack possède une entrée linux/arm64 dans son manifeste. Vérifiez chaque image avec docker buildx imagetools inspect <image> et recherchez une ligne Platform: linux/arm64. Les images officielles de Docker Hub sont généralement multi-architecture. Les images de petits éditeurs, ainsi que celles que vous avez construites vous-même sur une machine x86, ne le sont souvent pas. Pour vos propres images, reconstruisez-les avec docker buildx build --platform linux/amd64,linux/arm64 ... --push afin qu’un même tag serve aux deux architectures.

Que signifie exec format error sur un serveur ARM ?

Le kernel a tenté d’exécuter un binaire dont l’en-tête ELF indique un autre type de machine, puis l’a refusé. Sur un hôte arm64, il s’agit presque toujours d’un binaire ou d’une image de conteneur x86-64. Docker affiche d’abord un avertissement indiquant que la plateforme d’image demandée, linux/amd64, ne correspond pas à la plateforme détectée sur l’hôte, linux/arm64/v8. La solution consiste à utiliser un build pour la bonne architecture. Aucun changement de configuration ne permet d’exécuter nativement un binaire x86-64 sur ARM.

arm64 est-il identique à aarch64 ?

Oui. Ce sont deux noms pour désigner le jeu d’instructions ARM 64 bits. Le kernel indique aarch64 via uname -m, tandis que les systèmes de packaging Debian et Ubuntu ainsi que les chaînes de plateforme Docker utilisent arm64. La même distinction existe de l’autre côté : uname -m indique x86_64, tandis que le packaging utilise amd64. Si une page de téléchargement propose uniquement des fichiers aarch64, ce sont les bons fichiers pour une machine que dpkg --print-architecture désigne par arm64.

Un VPS ARM est-il plus rapide qu’un VPS x86 ?

Cette question n’a pas de réponse générale. Tout ratio présenté a été mesuré sur un matériel différent du vôtre. Les performances dépendent du modèle précis de CPU, du nombre de cœurs qui vous sont attribués, de la manière dont le fournisseur gère la contention entre tenants et de la capacité de votre workload à utiliser les instructions vectorielles. Faites un benchmark des deux offres entre lesquelles vous hésitez, avec votre propre workload si possible, puis comparez les résultats.

Que dois-je vérifier avant de migrer un serveur de production vers arm64 ?

Effectuez quatre vérifications, dans cet ordre. Vérifiez que chaque image de conteneur possède un manifeste arm64. Vérifiez que chaque dépôt apt tiers publie binary-arm64. Vérifiez que chaque agent closed source propose un téléchargement aarch64. Exécutez ensuite getconf PAGESIZE sur l’instance cible, car un kernel utilisant des pages de 64 KiB modifie l’empreinte mémoire des processus comportant de nombreux mappings de petite taille. Tout élément qui échoue à l’une de ces quatre vérifications justifie de conserver ce serveur particulier sur x86.