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

Was sich beim Wechsel auf einen ARM-VPS ändert

Ein ARM-VPS verwendet dasselbe Linux und dasselbe 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 Softwarekomponente Ihres Stacks entweder als arm64-Build verfügbar sein oder sich neu kompilieren lassen.

Moderne Stacks erfüllen diese Voraussetzung meist ohne Anpassungen. Probleme treten vor allem an zwei Stellen auf: bei Container-Images, die nur für eine Architektur erstellt wurden, und bei proprietärer 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 bedeutet was?

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 Intel- oder AMD-System x86_64 aus. dpkg --print-architecture gibt auf diesen beiden Systemen jeweils arm64 und amd64 aus. Beide Antworten 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 Image-Plattform linux/arm64.

Auf arm64 gibt es in /proc/cpuinfo keine Zeile model name. Stattdessen gibt es ein Feld Features. Hardware-Kryptografie wird dort durch Flags wie aes pmull sha1 sha2 angezeigt. Dabei handelt es sich um die ARMv8 Cryptographic Extensions. Sie übernehmen auf ARM-Systemen dieselbe Aufgabe wie AES-NI auf Intel- und AMD-Prozessoren: 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 enthält, auf einen arm64-Host übertragen, 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 bedeutet, dass der Kernel die Ausführung der Datei verweigert, weil der ELF-Header (Executable and Linkable Format) einen Maschinentyp angibt, den diese CPU nicht unterstützt. Keine Einstellung kann das beheben. Die benötigten Instruktionen sind in der Hardware nicht vorhanden.

Prüfen Sie das Manifest vor dem Deployment:

docker buildx imagetools inspect nginx:1.27

Die Ausgabe enthält eine Platform:-Zeile pro Image im Manifest-Listen-Eintrag, beispielsweise linux/amd64 und linux/arm64. Wenn linux/arm64 fehlt, wird dieser Tag auf einem ARM-VPS nicht gestartet. 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. Verwenden Sie daher bevorzugt imagetools.

Wenn Sie Images selbst erstellen, erstellen Sie beide Architekturen mit einem Befehl und übertragen Sie anschließend eine Manifest-Liste:

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

Für das Erstellen für eine fremde Architektur auf einem einzelnen Host muss die QEMU-Benutzermodus-Emulation beim Kernel-Handler binfmt_misc registriert sein:

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

Verwenden Sie die Emulation zum Erstellen und Testen. Verwenden Sie sie nicht zum Bereitstellen von Netzwerkdiensten. Die Docker-Dokumentation weist darauf hin, dass die Emulation mit QEMU „deutlich langsamer als native Builds sein kann, insbesondere bei rechenintensiven Aufgaben wie dem Kompilieren sowie der Kompression oder Dekompression“. Ein emulierter x86-Dienst auf einer ARM-Instanz macht daher die Einsparung zunichte, die den Wechsel motiviert hat. Die Einrichtung des Hosts für den nativen Betrieb ist auf beiden Architekturen identisch: Docker auf einem VPS ausführen behandelt dieses Thema. Eine vorhandene Compose-Datei funktioniert unverändert, sobald jedes darin verwendete Image ein arm64-Manifest enthält.

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

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

Fragen Sie apt direkt auf der ARM-Instanz:

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

apt-cache policy mit Candidate: (none) bedeutet, dass kein aktiviertes Repository einen Build dieses Pakets für diese Architektur veröffentlicht. 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 sie zu überspringen. Ein Repository eines Anbieters, 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. Das Paket scheint dann zu fehlen, obwohl die eigentliche Ursache der Pin ist.

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

Interpretierte Sprachen und Bytecode-Runtimes sind grundsätzlich portabel. PHP, Python, Ruby und Node.js bieten in den wichtigsten Distributionen arm64-Pakete. Go und Rust kompilieren durch die Auswahl eines Targets nach arm64. Ein LEMP-Stack, eine Node-API, ein Go-Binary hinter Nginx oder eine Postgres-Datenbank sind unter arm64 alltägliche Anwendungsfälle.

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

Bibliotheken mit handgeschriebenem 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. Deshalb lassen sie sich kompilieren und ausführen. Die Performance kann sich gegenüber dem x86-Build in beide Richtungen unterscheiden. Messen Sie das auf Ihrer Instanz, statt es anhand eines Artikels vorherzusagen.

Proprietäre Software ist das tatsächliche Ausschlusskriterium. Ein Monitoring-Agent eines Anbieters, ein lizenzierter Datenbanktreiber, ein kommerzielles Control Panel oder ein Antivirus-Daemon wird als kompiliertes Binary bereitgestellt. Wenn der Anbieter keinen arm64-Build veröffentlicht, können Sie daran nichts ändern. cPanel und WHM ist 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 (geprüft im August 2026; die Angaben sollten auf der Anforderungsseite des Anbieters erneut geprüft werden). Wenn dies das einzige Hindernis ist, 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 noch unterscheiden

x86-64-Server sind nahezu austauschbar. ARM-Server sind weniger einheitlich, und die Unterschiede liegen unterhalb Ihrer Anwendung.

Die Seitengröße ist der Unterschied, der in der Produktion relevant wird. Die meisten arm64-Kernel verwenden 4 KiB große Seiten, genau wie x86-64. Einige verwenden 64 KiB. Red Hat Enterprise Linux 8 für aarch64 wurde standardmäßig mit einem Kernel ausgeliefert, der 64 KiB große Seiten verwendet. RHEL 9 setzte den Standard wieder auf 4 KiB zurück 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 Mindestbedarf an Speicher für einen Prozess mit vielen kleinen Speicherzuordnungen, weil der kleinste Speicherblock, den der Kernel bereitstellen kann, sechzehnmal größer ist. Führen Sie getconf PAGESIZE auf der Instanz aus und lesen Sie den Wert ab, statt ihn anzunehmen. Die Seitengröße ist nicht die einzige Kernelentscheidung, die sich auf Sie auswirkt. Auch die von Ihrem Provider bereitgestellte Version bestimmt, wie Arbeit auf die Cores verteilt wird. Das in Linux 7.2 hinzugefügte cachebewusste Scheduling wird auf arm64 und x86-64 gleichermaßen verwendet.

Einige kleinere Unterschiede sollten Sie ebenfalls kennen. Unter 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 von Intel GVT-g bereitgestellte virtuelle 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-Architektur-Images.

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

Lesen Sie die Einschränkungen in derselben Ankündigung. Sie zeigen, wie begrenzt die offiziell unterstützte ARM-Serverhardware weiterhin ist. Proxmox validierte NVIDIA-Grace- und NVIDIA-Vera-Systeme bereits am ersten Tag. Vorausgegangen waren gemeinsame Tests mit NVIDIA und Supermicro auf Grace-Hopper-Hardware. Für andere UEFI-basierte ARMv8-A- und ARMv9-A-Systeme gilt Best-Effort-Support. Single-Board-Computer, die ausschließlich Device Tree verwenden, etwa der Raspberry Pi, werden nicht unterstützt. Ein Gast läuft nur auf einem Node derselben Architektur. Live-Migration funktioniert nur zwischen Nodes derselben Architektur. Gemischte Architektur-Cluster werden offiziell nicht unterstützt.

Das ist die sachliche Lage im August 2026. Dass ein Hypervisor-Hersteller arm64 mit demselben Release-Zyklus wie x86-64 veröffentlicht, ist ein echter Fortschritt für die Plattform. Die am ersten Tag unterstützte Hardwareliste umfasst zwei CPU-Familien.

Checkliste vor dem Commit

1. Führen Sie uname -m auf einer Testinstanz aus und bestätigen Sie, dass der Befehl aarch64 ausgibt.
2. Führen Sie docker buildx imagetools inspect für jedes Image in Ihrer Compose-Datei aus und bestätigen Sie für jedes Image eine linux/arm64-Plattformzeile.
3. Führen Sie apt update auf der ARM-Instanz aus und lesen Sie jede ausgegebene Skipping acquire-Warnung.
4. Öffnen Sie für jeden Closed-Source-Agenten, von dem Sie abhängig sind, die Downloadseite und suchen Sie dort nach einem Build für arm64 oder aarch64.
5. Führen Sie getconf PAGESIZE aus und notieren Sie die Antwort, bevor Sie den Arbeitsspeicher dimensionieren.
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 geben Ihnen kein Preis-Leistungs-Verhältnis für ARM im Vergleich zu x86 an. Die Preise pro Kern unterscheiden sich je nach Anbieter und Tarif. Ein Messwert auf der Hardware eines anderen Anbieters sagt nichts zuverlässig ü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 Kostenseite des Vergleichs. Der Speicher ist eine von der CPU-Architektur getrennte Entscheidung. Wie NVMe mit SATA-SSD auf einem VPS verglichen wird behandelt diesen Teil. Führen Sie auf beiden Tarifen denselben Test aus. Verwenden Sie nach Möglichkeit Ihre eigene Arbeitslast. Lassen Sie Ihre Messwerte entscheiden.

FAQ

Laufen meine Docker-Container auf einem ARM-VPS?

Sie laufen, wenn jedes Image im Stack einen linux/arm64-Eintrag in seinem Manifest enthält. Prüfen Sie jedes Image mit docker buildx imagetools inspect <image> und suchen Sie nach einer Zeile mit Platform: linux/arm64. Offizielle Images auf Docker Hub unterstützen in der Regel mehrere Architekturen. Images kleinerer Anbieter und Images, die Sie selbst auf einem x86-Rechner 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 verweigert. 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 angeforderte Image-Plattform linux/amd64 nicht zur erkannten Host-Plattform linux/arm64/v8 passt. Die Lösung ist ein Build für die richtige Architektur. Eine Konfigurationsänderung ermöglicht es nicht, eine x86-64-Binärdatei nativ auf ARM auszuführen.

Ist arm64 dasselbe wie aarch64?

Ja. Beide Bezeichnungen stehen für den 64-Bit-Befehlssatz von ARM. Der Kernel meldet aarch64 über uname -m, während die Paketierung von Debian und Ubuntu sowie die Docker-Plattformzeichenfolgen arm64 verwenden. Auf der anderen Seite gibt es dieselbe Aufteilung: uname -m steht für x86_64, während die Paketierung amd64 verwendet. Wenn eine Downloadseite nur aarch64-Dateien anbietet, sind dies die richtigen Dateien für einen Rechner, den dpkg --print-architecture als arm64 bezeichnet.

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

Diese Frage hat keine allgemeingültige Antwort. Jede einzelne Kennzahl, die Sie lesen, wurde auf Hardware ermittelt, die nicht Ihrer Hardware entspricht. Die Geschwindigkeit hängt vom konkreten CPU-Modell, von der Anzahl der Ihnen zugewiesenen Kerne, vom Umgang des Anbieters mit der Auslastung durch andere Mandanten und davon ab, wie gut Ihre Arbeitslast Vektorbefehle nutzt. Führen Sie Benchmarks mit den beiden Tarifen durch, zwischen denen Sie tatsächlich wählen, möglichst mit Ihrer eigenen Arbeitslast, und vergleichen Sie diese Werte.

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

Führen Sie vier Prüfungen in dieser Reihenfolge durch. Stellen Sie sicher, dass jedes Container-Image ein arm64-Manifest enthält. Stellen Sie sicher, dass jedes apt-Repository eines Drittanbieters binary-arm64 veröffentlicht. Stellen Sie sicher, dass für jeden Closed-Source-Agenten 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 jeweiligen Server auf x86 zu belassen.