ARM VPS oder x86 VPS: Was ändert sich wirklich?

Was sich beim Wechsel zu einem ARM-VPS ändert

Ein ARM-VPS verwendet dasselbe Linux und denselben Nginx wie ein x86-VPS und kostet pro Kern meist weniger. Das Risiko beim Wechsel liegt in der Kompatibilität. Ein für x86-64 kompiliertes Programm kann unter arm64 überhaupt nicht ausgeführt werden. Daher muss jede Software in Ihrem Stack einen arm64-Build bereitstellen oder sich neu kompilieren lassen.

Die meisten modernen Stacks erfüllen diese Voraussetzung ohne Anpassungen. Probleme treten hauptsächlich an zwei Stellen auf: bei Container-Images, die nur für eine Architektur erstellt wurden, und bei Closed-Source-Software ohne arm64-Download. Mit den folgenden Befehlen prüfen Sie beide Punkte für Ihren eigenen Stack, bevor Sie eine Instanz buchen. Wenn Sie noch klären, welche Art von Server Sie benötigen, beginnen Sie mit was ein VPS ist und wie er sich von Shared Hosting unterscheidet.

arm64, aarch64, amd64: Welche Bezeichnung steht wofür?

Führen Sie diese Befehle auf jeder Instanz aus, bevor Sie etwas anderes tun.

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

uname -m gibt auf einem ARM-System aarch64 und auf einem System mit Intel- oder AMD-Prozessor x86_64 aus. dpkg --print-architecture gibt auf denselben beiden Systemen arm64 beziehungsweise amd64 aus. Beide Ergebnisse sind korrekt. Der Linux-Kernel und das Debian-Paketsystem verwenden unterschiedliche Bezeichnungen für denselben Befehlssatz. Daher bezeichnen aarch64 und arm64 das eine und x86_64 und amd64 das andere. Docker verwendet die Bezeichnungen im Debian-Stil. Deshalb lautet die Plattformangabe eines Images linux/arm64.

Auf arm64 gibt es in /proc/cpuinfo keine Zeile model name. Stattdessen wird ein Feld Features ausgegeben. Hardwarebeschleunigte Kryptografie erscheint dort als Flags wie aes pmull sha1 sha2. Dabei handelt es sich um die ARMv8 Cryptographic Extensions. Sie übernehmen auf Intel- und AMD-Prozessoren dieselbe Aufgabe wie AES-NI: Sie beschleunigen TLS (Transport Layer Security) und die Festplattenverschlüsselung per Hardware. AES-Hardwarebeschleunigung auf einer VPS prüfen beschreibt den Test für beide Architekturen.

Warum Container zuerst ausfallen und wie der Fehler aussieht

Jedes Docker-Image-Manifest enthält die Architektur, für die das Image erstellt wurde. Wenn Sie ein Image, das nur ein amd64-Manifest besitzt, auf einen arm64-Host pullen, ist der Pull erfolgreich. Der Fehler tritt beim Start des ersten Prozesses auf:

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 ist die Fehlermeldung des Kernels, dass die Datei nicht ausgeführt werden kann, weil ihr ELF-Header (Executable and Linkable Format) einen Maschinentyp angibt, den diese CPU nicht unterstützt. Keine Einstellung kann das beheben. Die erforderlichen Instruktionen sind in der Hardware nicht vorhanden.

Prüfen Sie das Manifest, bevor Sie das Image bereitstellen:

docker buildx imagetools inspect nginx:1.27

Die Ausgabe enthält für jedes Image im Manifest-Listenobjekt eine Zeile mit Platform:, beispielsweise linux/amd64 und linux/arm64. Wenn linux/arm64 fehlt, wird dieser Tag auf einer ARM-VPS nicht starten. docker manifest inspect --verbose nginx:1.27 zeigt dieselben Informationen an. Docker dokumentiert docker manifest jedoch als experimentellen Befehl, dessen Verhalten sich zwischen Releases ändern kann. Bevorzugen Sie daher imagetools.

Für Images, die Sie selbst erstellen, erstellen Sie beide Architekturen mit einem Befehl und pushen Sie eine Manifest-Liste:

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

Das Erstellen für eine fremde Architektur auf einem einzelnen Host erfordert die im Kernel registrierte QEMU-User-Mode-Emulation über den Handler binfmt_misc:

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

Verwenden Sie die Emulation zum Erstellen und Testen. Verwenden Sie sie nicht zum Bereitstellen von Netzwerkdiensten. In der Docker-Dokumentation steht, dass die Emulation mit QEMU „deutlich langsamer als native Builds sein kann, insbesondere bei rechenintensiven Aufgaben wie der Kompilierung sowie der Komprimierung oder Dekomprimierung“. Ein emulierter x86-Dienst auf einer ARM-Instanz macht daher den Vorteil zunichte, der den Wechsel motiviert hat. Die Host-Konfiguration für den nativen Betrieb ist auf beiden Architekturen identisch: Docker auf einer VPS ausführen beschreibt sie. Eine vorhandene Compose-Datei funktioniert unverändert, sobald jedes darin verwendete Image über ein arm64-Manifest verfügt.

Sind die benötigten Pakete für arm64 verfügbar?

Ubuntu und Debian bauen fast das gesamte Archiv für arm64. Daher verhält sich apt install nginx postgresql redis-server auf beiden Architekturen gleich. Die Lücken gibt es bei Drittanbieter-Repositorys.

Fragen Sie direkt auf der ARM-Instanz bei apt nach:

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

Wenn apt-cache policy Candidate: (none) meldet, veröffentlicht kein aktiviertes Repository einen Build dieses Pakets für diese Architektur. apt-get install -s simuliert die Installation und schreibt nichts. Im selben Fall endet der Befehl mit E: Unable to locate package.

Lesen Sie anschließend die Ausgabe von apt update, statt darüber hinwegzuscrollen. Ein Anbieter-Repository, das nur amd64 unterstützt, weist darauf hin:

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

Das Repository ist konfiguriert und erreichbar. Es enthält jedoch kein Paket, das diese Maschine installieren kann. Prüfen Sie auch den Source-Eintrag selbst. Eine mit [arch=amd64] markierte Zeile wird auf einem arm64-Host übersprungen. Dadurch wirkt das Paket fehlend, obwohl die eigentliche Ursache die Pin-Konfiguration ist.

Welche Workloads sind unkritisch, und welche müssen zuerst geprüft werden

Interpretierte Laufzeitumgebungen und Bytecode-Laufzeitumgebungen sind grundsätzlich portabel. PHP, Python, Ruby und Node.js bieten in den wichtigsten Distributionen arm64-Pakete. Go und Rust kompilieren per Cross-Compilation für arm64, wenn Sie ein Ziel festlegen. Ein LEMP-Stack, eine Node-API, ein Go-Binary hinter Nginx oder eine Postgres-Datenbank sind unter arm64 normale Anwendungsfälle.

Ein Just-in-Time-Compiler (JIT) erzeugt Maschinencode während der Programmausführung. Deshalb benötigt er einen Codegenerator für die Zielarchitektur. Aktuelle Versionen bieten einen solchen Codegenerator: OpenJDK, .NET, die V8-Engine in Node.js und PyPy unterstützen arm64 unter Linux. Das eigentliche Risiko sind festgelegte alte Versionen. Ein Deploy-Skript, das eine Runtime-Version von vor mehreren Jahren installiert, sollte anhand der Versionshinweise dieser Version auf aarch64-Unterstützung geprüft werden. Sie sollten nicht einfach davon ausgehen, dass sie funktioniert.

Bibliotheken mit manuell geschriebenem x86-Assembler oder SSE- und AVX-Intrinsics sind ein weniger offensichtlicher Fall. Die meisten bieten zusätzlich einen NEON-Pfad (NEON ist der ARM-Vektorinstruktionssatz) oder einen einfachen C-Fallback. Sie lassen sich daher kompilieren und ausführen. Die Performance kann in beide Richtungen von der x86-Version abweichen. Messen Sie das auf Ihrer Instanz, statt es anhand eines Artikels vorherzusagen.

Proprietäre Software ist der tatsächliche Blocker. Ein Monitoring-Agent eines Herstellers, ein lizenzierter Datenbanktreiber, ein kommerzielles Control Panel oder ein Antivirus-Daemon wird als kompiliertes Binary bereitgestellt. Wenn der Hersteller keinen arm64-Build veröffentlicht, können Sie daran nichts ändern. cPanel und WHM sind im Hosting der eindeutigste Fall: Die Systemanforderungen nennen x86_64 und führen ARM nicht auf. Ein Server mit Control Panel bleibt daher auf x86 (Stand August 2026; die Anforderungen sollten auf der Website des Herstellers erneut geprüft werden). Wenn Sie nur das zurückhält, finden Sie unter den cPanel-Alternativen, die sich auf einem VPS betreiben lassen einen geeigneten Ausgangspunkt. Prüfen Sie die Architekturunterstützung jeder Alternative auf dieselbe Weise.

Kernel und Seitengröße: Wo sich ARM-Instanzen weiterhin unterscheiden

x86-64-Server sind fast vollständig austauschbar. ARM-Server sind weniger einheitlich, und die Unterschiede liegen unterhalb Ihrer Anwendung.

Die Seitengröße ist der Unterschied, der sich in der Produktion bemerkbar macht. Die meisten arm64-Kernel verwenden 4 KiB große Seiten, wie x86-64. Einige verwenden 64 KiB. Red Hat Enterprise Linux 8 für aarch64 wurde standardmäßig mit einem Kernel mit 64-KiB-Seiten ausgeliefert. RHEL 9 stellte den Standard wieder auf 4 KiB um und behielt ein separates kernel-64k-Paket für Workloads bei, die die größere Seitengröße benötigen. Eine Seitengröße von 64 KiB erhöht den Speicherbedarf eines Prozesses mit vielen kleinen Speicherzuordnungen, weil die kleinste Speichereinheit, die der Kernel zuweisen kann, sechzehnmal größer ist. Führen Sie getconf PAGESIZE auf der Instanz aus und lesen Sie den Wert ab, statt ihn vorauszusetzen.

Einige kleinere Unterschiede sollten Sie kennen. Für arm64 gibt es kein Betriebssystempaket für CPU-Microcode. Firmware-Updates kommen daher von Ihrem Provider und nicht aus apt. ARM-Server booten über UEFI (unified extensible firmware interface) und beschreiben ihre Hardware über ACPI (advanced configuration and power interface). Einige x86-Funktionen haben überhaupt kein ARM-Gegenstück. Dazu gehören die AMD-SEV-Speicherverschlüsselung und die durch Intel GVT-g bereitgestellten vermittelten GPUs.

Ist die ARM-Serverplattform ausgereift?

Auf der Softwareseite ja. Debian, Ubuntu, Fedora und RHEL veröffentlichen alle erstklassige arm64-Builds. Die offiziellen Images auf Docker Hub sind standardmäßig Multi-Arch-Images.

Der deutlichste aktuelle Beleg ist Proxmox. Am 5. August 2026 kündigte Proxmox die erste offiziell unterstützte arm64-Ausgabe von Proxmox Virtual Environment an, Version 9.2. Sie verwendet dieselben Paket-Repositorys und denselben Release-Lebenszyklus wie die x86-64-Ausgabe. Sie basiert auf Debian 13.5 mit Linux 7.0, QEMU 11.0, LXC 7.0 und ZFS 2.4. Konfiguration und Werkzeuge entsprechen x86-64, abgesehen von wenigen architekturspezifischen Punkten.

Lesen Sie die Einschränkungen in derselben Ankündigung. Sie zeigen, wie begrenzt die offiziell unterstützte ARM-Serverhardware weiterhin ist. Proxmox hat NVIDIA-Grace- und NVIDIA-Vera-Systeme bereits am ersten Tag validiert. Dem gingen gemeinsame Tests mit NVIDIA und Supermicro auf Grace-Hopper-Hardware voraus. Andere UEFI-basierte ARMv8-A- und ARMv9-A-Hardware wird nach bestem Wissen und Gewissen unterstützt. Single-Board-Computer, die ausschließlich den Device Tree verwenden, beispielsweise der Raspberry Pi, werden nicht unterstützt. Eine Gast-VM läuft nur auf einem Node mit derselben Architektur. Live-Migration funktioniert nur zwischen Nodes mit derselben Architektur. Cluster mit gemischten Architekturen werden offiziell nicht unterstützt.

Das ist der sachliche Stand im August 2026. Dass ein Hypervisor-Anbieter arm64 mit demselben Lebenszyklus wie x86-64 veröffentlicht, ist ein echter Fortschritt für die Plattform. Die Liste der am ersten Tag unterstützten Hardware umfasst zwei CPU-Familien.

Checkliste vor der verbindlichen Entscheidung

1. Führen Sie uname -m auf einer Testinstanz aus und prüfen Sie, ob aarch64 ausgegeben wird.
2. Führen Sie docker buildx imagetools inspect für jedes Image in Ihrer Compose-Datei aus und prüfen Sie, ob für jedes Image eine linux/arm64-Plattformzeile ausgegeben wird.
3. Führen Sie apt update auf der ARM-Instanz aus und lesen Sie jede ausgegebene Skipping acquire-Warnung.
4. Öffnen Sie die Download-Seite jedes Closed-Source-Agents, von dem Sie abhängig sind, und suchen Sie anhand des Namens nach einem arm64- oder aarch64-Build.
5. Führen Sie getconf PAGESIZE aus und notieren Sie die Antwort, bevor Sie die Speicherkapazität festlegen.
6. Führen Sie Ihren eigenen Benchmark sowohl auf dem ARM-Tarif als auch auf dem x86-Tarif aus, zwischen denen Sie wählen.

Was dieser Beitrag nicht behauptet

Wir nennen Ihnen kein Preis-Leistungs-Verhältnis für ARM im Vergleich zu x86. Die Preise pro Kern unterscheiden sich je nach Anbieter und Tarif. Ein Messwert von der Hardware eines anderen Anbieters sagt nichts über Ihre Hardware aus. Messen Sie stattdessen selbst. Unser Leitfaden zum Benchmarking eines VPS behandelt sysbench und fio mit einer reproduzierbaren Methode. Was ein VPS tatsächlich kostet behandelt die Preisseite dieses Vergleichs. Der Speicher ist eine separate Entscheidung von der CPU-Architektur. Wie sich NVMe und SATA-SSD bei einem VPS unterscheiden behandelt diesen Teil. Führen Sie auf beiden Tarifen denselben Test aus, möglichst mit Ihrer eigenen Arbeitslast, und richten Sie sich nach Ihren Messwerten.

FAQ

Werden meine Docker-Container auf einem ARM-VPS ausgeführt?

Sie werden ausgeführt, wenn jedes Image im Stack einen linux/arm64-Eintrag in seinem Manifest hat. Prüfen Sie jedes Image mit docker buildx imagetools inspect <image> und suchen Sie nach einer Platform: linux/arm64-Zeile. Offizielle Images auf Docker Hub unterstützen normalerweise mehrere Architekturen. Images kleinerer Anbieter und Images, die Sie selbst auf einem x86-Computer erstellt haben, unterstützen dies häufig nicht. Erstellen Sie eigene Images mit docker buildx build --platform linux/amd64,linux/arm64 ... --push neu, damit ein Tag beide Architekturen abdeckt.

Was bedeutet exec format error auf einem ARM-Server?

Der Kernel hat versucht, eine Binärdatei auszuführen, deren ELF-Header einen anderen Maschinentyp angibt, und hat dies abgelehnt. Auf einem arm64-Host handelt es sich fast immer um eine x86-64-Binärdatei oder ein x86-64-Container-Image. Docker gibt zunächst eine Warnung aus. Darin steht, dass die Plattform des angeforderten Images linux/amd64 nicht mit der erkannten Hostplattform linux/arm64/v8 übereinstimmt. Die Lösung ist ein Build für die richtige Architektur. Durch eine Konfigurationsänderung lässt sich eine x86-64-Binärdatei nicht nativ auf ARM ausführen.

Ist arm64 dasselbe wie aarch64?

Ja. Das sind zwei Bezeichnungen für den 64-Bit-Befehlssatz von ARM. Der Kernel meldet aarch64 über uname -m, während die Paketverwaltung von Debian und Ubuntu sowie die Docker-Plattformstrings arm64 verwenden. Dieselbe Aufteilung gibt es auf der anderen Seite: uname -m steht für x86_64, während die Paketverwaltung amd64 verwendet. Wenn eine Download-Seite nur aarch64-Dateien anbietet, sind dies die richtigen Dateien für eine Maschine, die dpkg --print-architecture als arm64 bezeichnet.

Ist ein ARM-VPS schneller als ein x86-VPS?

Diese Frage lässt sich nicht allgemein beantworten. Jede einzelne Kennzahl, die Sie lesen, wurde auf Hardware ermittelt, die nicht Ihrer Hardware entspricht. Die Geschwindigkeit hängt vom konkreten CPU-Modell, der Anzahl der Ihnen zugewiesenen Kerne, dem Umgang des Anbieters mit der Auslastung durch andere Mandanten und der Nutzung von Vektorinstruktionen durch Ihre Workload ab. Führen Sie Benchmarks für die beiden Tarife durch, zwischen denen Sie tatsächlich wählen, möglichst mit Ihrer eigenen Workload, und vergleichen Sie die Ergebnisse.

Was sollte ich prüfen, bevor ich einen Produktionsserver auf arm64 umstelle?

Führen Sie vier Prüfungen in dieser Reihenfolge durch. Stellen Sie sicher, dass jedes Container-Image ein arm64-Manifest besitzt. Stellen Sie sicher, dass jedes apt-Repository eines Drittanbieters binary-arm64 veröffentlicht. Stellen Sie sicher, dass für jeden Closed-Source-Agent ein aarch64-Download verfügbar ist. Führen Sie anschließend getconf PAGESIZE auf der Zielinstanz aus, da ein Kernel mit 64-KiB-Speicherseiten den Speicherbedarf von Prozessen mit vielen kleinen Mappings verändert. Alles, was eine dieser vier Prüfungen nicht besteht, ist ein Grund, den betreffenden Server weiterhin auf x86 zu betreiben.