VPS ARM ou x86 : quelles différences pour votre stack ?

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, et son coût par cœur est généralement inférieur. Le risque du changement concerne la compatibilité. Un programme compilé pour x86-64 ne peut pas s’exécuter sur arm64. Chaque composant de votre stack doit donc disposer d’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 conteneur qui n’ont été conçues que pour une architecture et les logiciels propriétaires qui ne proposent aucun téléchargement arm64. Les commandes ci-dessous permettent de vérifier ces deux points pour votre propre stack avant de payer 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 : que signifie chaque nom ?

Exécutez ces commandes sur toute 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 mêmes machines. Les deux réponses sont correctes. Le kernel 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, ce qui explique qu’une plateforme d’image soit indiquée comme linux/arm64.

Sur arm64, il n’y a pas de ligne model name dans /proc/cpuinfo. Vous y trouverez plutôt un champ Features, dans lequel les fonctions de chiffrement matériel apparaissent sous forme de flags comme aes pmull sha1 sha2. Il s’agit des extensions cryptographiques ARMv8. Elles remplissent le même rôle que l’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 manifest d’image Docker indique l’architecture pour laquelle l’image a été compilée. Si vous téléchargez une image qui ne possède qu’un manifest amd64 sur un hôte arm64, 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 kernel 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 réglage ne peut résoudre ce problème. Les instructions ne sont pas présentes dans le silicium.

Vérifiez le manifest avant le déploiement :

docker buildx imagetools inspect nginx:1.27

La sortie affiche une ligne Platform: par image dans la manifest list, comme 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 compilez vous-même, compilez les deux architectures en une seule commande et envoyez une manifest list :

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

La compilation pour une architecture étrangère sur un seul hôte nécessite l’émulation QEMU en mode utilisateur, enregistrée auprès du handler binfmt_misc du kernel :

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

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

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

Ubuntu et Debian construisent presque toute l’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 à l’origine des principales lacunes.

Interrogez directement apt sur l’instance ARM :

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

Le message apt-cache policy avec Candidate: (none) signifie qu’aucun dépôt activé ne publie de version de ce paquet pour cette architecture. apt-get install -s simule l’installation sans rien écrire. Dans ce 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. Un dépôt fournisseur limité à amd64 l’indique clairement :

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 installable par cette machine. Vérifiez également l’entrée de source elle-même. Une ligne marquée avec [arch=amd64] est ignorée sur un hôte arm64. Le paquet semble alors manquant, alors que la cause réelle est le pinning.

Charges de travail compatibles et vérifications nécessaires

Les environnements d’exécution interprétés et bytecode sont conçus pour être portables. PHP, Python, Ruby et Node.js disposent tous de paquets 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 sont des usages courants sur arm64.

Un compilateur just in time (JIT) produit le 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 d’un environnement d’exécution 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 à la main 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’un fallback en C standard. Elles peuvent donc être compilées et exécutées. Les performances peuvent différer de celles de la build x86 dans un sens comme dans l’autre. Mesurez-les sur votre instance au lieu de les déduire d’un article.

Les logiciels propriétaires sont le véritable obstacle. 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 fourni sous la forme d’un binaire compilé. Si l’éditeur ne publie pas de build arm64, vous ne pouvez rien y faire. cPanel and WHM est le cas le plus clair dans l’hébergement : sa configuration requise mentionne x86_64 et ne liste pas ARM. Un serveur avec control panel doit donc rester sur x86 (vérification effectuée en août 2026, mais cette information mérite d’être relue sur la page officielle de configuration requise de l’éditeur). Si c’est le seul élément qui vous retient, commencez par les alternatives à cPanel à utiliser sur un VPS, puis vérifiez la prise en charge de l’architecture pour chacune de la même manière.

Noyau 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 ces différences se situent sous votre application.

La taille des pages est la différence qui se manifeste en 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 utilisant 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 la mémoire minimale nécessaire à un processus comportant de nombreux mappages 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 au lieu de la supposer. La taille des pages n’est pas la seule décision du noyau qui vous concerne, car la version fournie par votre fournisseur détermine également la manière dont les tâches sont planifiées sur les cœurs, et la planification tenant compte du cache ajoutée dans Linux 7.2 fonctionne aussi bien sur arm64 que sur x86-64.

Quelques différences moins importantes sont également à connaître. Il n’existe pas de paquet de microcode CPU du système d’exploitation sur arm64 : les mises à jour du firmware viennent 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 au moyen de l’ACPI (advanced configuration and power interface). Certaines fonctionnalités x86 n’ont aucun équivalent ARM, notamment le chiffrement de la mémoire AMD SEV et les GPU virtualisés par médiation Intel GVT-g.

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

Du côté 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.

La preuve récente la plus claire est Proxmox. Le 5 août 2026, Proxmox a annoncé la première édition arm64 officiellement prise en charge de Proxmox Virtual Environment, 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 d’un petit nombre d’éléments propres à l’architecture.

Lisez les réserves de 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 basés sur UEFI bénéficient d’une prise en charge au meilleur effort. Les ordinateurs monocarte reposant uniquement sur un device tree, comme le Raspberry Pi, ne sont pas pris en charge. Un invité ne peut s’exécuter que sur un nœud de la même architecture. La migration à chaud ne fonctionne qu’entre des nœuds de même architecture. Les clusters d’architectures mixtes ne sont pas officiellement pris en charge.

C’est la situation réelle en août 2026. Le fait qu’un éditeur d’hyperviseur propose arm64 selon le même cycle de publication que x86-64 constitue un progrès réel pour la plateforme. La liste du matériel pris en charge dès le lancement se limite à deux familles de processeurs.

Checklist à effectuer avant de vous engager

1. Exécutez uname -m sur une instance de test et vérifiez qu’elle 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 propriétaire dont vous dépendez et recherchez une build arm64 ou aarch64.
5. Exécutez getconf PAGESIZE et notez le résultat avant de dimensionner la mémoire.
6. Effectuez votre propre benchmark sur l’offre ARM et l’offre x86 entre lesquelles vous hésitez.

Ce que cet article ne prétend pas

Nous n’allons pas vous donner un rapport prix/performances entre ARM et x86. Le prix par cœur varie selon le fournisseur et l’offre, et une mesure obtenue sur le matériel de quelqu’un d’autre ne permet pas de prédire les résultats sur le vôtre. Mesurez-les vous-même. Notre guide des benchmarks d’un VPS couvre sysbench et fio avec une méthode reproductible, tandis que le coût réel d’un VPS traite l’aspect tarifaire de la comparaison. Le stockage est une décision distincte de l’architecture CPU, et la comparaison entre NVMe et SSD SATA sur un VPS couvre cette partie. Exécutez le même test sur les deux offres, avec votre propre charge de travail lorsque c’est possible, puis basez votre choix sur vos mesures.

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 et celles que vous avez compilées vous-même sur une machine x86 ne le sont souvent pas. Pour vos propres images, effectuez une nouvelle compilation avec docker buildx build --platform linux/amd64,linux/arm64 ... --push afin qu’un même tag serve les deux architectures.

Que signifie exec format error sur un serveur ARM ?

Le kernel a essayé d’exécuter un binaire dont l’en-tête ELF indique un autre type de machine et l’a refusé. Sur un hôte arm64, cela signifie presque toujours qu’il s’agit d’un binaire x86-64 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 de l’hôte détectée, linux/arm64/v8. La solution consiste à compiler pour la bonne architecture. Aucune modification 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 le jeu d’instructions ARM 64 bits. Le kernel indique aarch64 via uname -m, tandis que les systèmes de packaging Debian et Ubuntu et les chaînes de plateforme Docker utilisent arm64. La même différence existe de l’autre côté : uname -m indique x86_64, tandis que le système de 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 comme 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 unique que vous avez lu 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 les tenants et de la capacité de votre workload à utiliser les instructions vectorielles. Mesurez les deux offres entre lesquelles vous hésitez réellement, 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 propriétaire 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 qui possèdent de nombreux petits mappings. Tout élément qui échoue à l’une de ces quatre vérifications justifie de conserver ce serveur particulier sur x86.