ARM betreibt jetzt die Hälfte der Cloud: Graviton 4, Ampere Altra Max und die Zahlen hinter dem Rückzug von x86

Der Wandel ist keine Theorie mehr

Den größten Teil des vergangenen Jahrzehnts war ARM im Serverraum ein Versprechen — stets zwei Jahre von der Produktionsreife entfernt. Diese Zeit ist vorbei. AWS meldet, dass Graviton-basierte Instanzen inzwischen einen erheblichen und wachsenden Anteil seiner Compute-Flotte betreiben. Amperes Altra Max-Chips laufen in Produktionsumgebungen bei Oracle Cloud, Microsoft Azure und Google Cloud. NVIDIAs Grace CPU wird in Grace Hopper Superchips geliefert, die weltweit in KI-Clustern eingesetzt werden. Die Frage lautet nicht mehr, ob ARM Server-Workloads bewältigen kann. Die Frage ist, welche Workloads den x86-Aufpreis noch rechtfertigen.

Die Kernthese ist einfach und durch Zahlen belegt: ARM-Server-Chips liefern mehr Durchsatz pro Watt und mehr Durchsatz pro Dollar als ihre x86-Pendants — bei den Workloads, die die modernen Cloud-Ausgaben dominieren: Web-Serving, containerisierte Microservices, In-Memory-Caching und Machine Learning Inference. x86 behält echte Vorteile bei Single-Threaded-Legacy-Software, Windows Server-Workloads und Anwendungen mit harten Abhängigkeiten von x86-ISA-Extensions. Alles andere ist eine Migrationsdiskussion.

AWS Graviton 4: Der Benchmark, der das Gespräch veränderte

AWS Graviton 4, Ende 2023 vorgestellt und der Antrieb hinter den R8g-, C8g- und M8g-Instanzfamilien, basiert auf einem maßgeschneiderten ARM Neoverse V2-Kern im 3nm-TSMC-Prozess. Der Chip kommt mit 96 Kernen, DDR5-5600-Speicherunterstützung und einem 75 MB großen System-Level-Cache. AWS gibt an, dass Graviton 4 eine bis zu 30 % bessere Compute-Performance gegenüber Graviton 3 liefert sowie eine bis zu 40 % bessere Performance pro Watt im Vergleich zu vergleichbaren x86-Instanzen in der eigenen Flotte.

Beim SPECrate2017_int_base erreichen Graviton 4-Instanzen in Tests von Drittanbietern einen aggregierten Score von 650–700 über alle Kerne, was mit Intel Xeon Sapphire Rapids zu ähnlichen Preispunkten konkurriert — bei geringerem Stromverbrauch an der Instanzgrenze. Für Java-basierte Workloads — ein bedeutender Anteil der Enterprise-Cloud-Ausgaben — erzielt Graviton 4 beim SPECjbb2015 rund 20–25 % höheren Durchsatz als Graviton 3, das seinerseits bereits vergleichbare Intel-Instanzen auf diesem Benchmark übertroffen hatte.

Das Preisargument ist direkt. Eine AWS m8g.4xlarge-Instanz (16 vCPU, Graviton 4) kostet in us-east-1 on-demand rund 0,616 $/Stunde. Eine vergleichbare m7i.4xlarge-Instanz (16 vCPU, Intel Sapphire Rapids) schlägt mit rund 0,806 $/Stunde zu Buche. Das entspricht einer Kostensenkung von 24 % — bevor man berücksichtigt, dass die ARM-Instanz bei zustandslosen Workloads oft einen höheren Anfragedurchsatz pro vCPU erzielt.

Ampere Altra Max: 128 Kerne, Single-Threaded-Vorhersehbarkeit

Ampere Computings Altra Max unterscheidet sich architektonisch bewusst von Graviton 4. Während AWS ein Hochleistungs-Kern-Design auf Basis von Neoverse V2 verwendet, setzt Ampere auf eigene Single-Threaded-Kerne — kein Simultaneous Multithreading (SMT). Der Altra Max bietet bis zu 128 Kerne, die mit bis zu 3,0 GHz takten, einen 128 MB großen L3-Cache und 8-Kanal-DDR4-3200-Speicher. Die TDP liegt beim 128-Kern-Modell bei 250–270 W.

Der Verzicht auf SMT ist eine bewusste Designentscheidung mit realen Konsequenzen. Cloud-Anbieter, die Altra Max einsetzen, können vCPUs anbieten, die 1:1 auf physische Kerne abgebildet werden — das eliminiert die Noisy-Neighbor-Varianz, die SMT-fähige x86-Instanzen unter gemischter Last plagt. Oracle Cloud Infrastructure bietet Ampere A1-Instanzen (ältere Altra-Generation) für 0,01 $/OCPU-Stunde an — das günstigste Compute-Angebot aller großen Cloud-Anbieter. Benchmark-Ergebnisse von Phoronix auf Altra Max-Knoten zeigen lineares Skalierungsverhalten bis 128 Threads bei embarrassingly parallel workloads — etwas, das x86-Chips mit SMT jenseits ihrer physischen Kernanzahl nicht mehr sauber liefern.

Amperes Ziel-Workload-Liste liest sich wie ein Katalog moderner Infrastruktur: NGINX, HAProxy, Redis, Memcached, PostgreSQL mit leselastigen Workloads und containerisierte Microservices auf Kubernetes. Teams, die diese Stacks betreiben, senken mit Altra Max-Instanzen messbar ihre Kosten pro Anfrage.

NVIDIA Grace: ARM trifft HBM3 für KI-Workloads

NVIDIAs Grace CPU, eingesetzt in den Grace Hopper- und Grace Blackwell Superchip-Konfigurationen, ist ein 72-Kern-ARM-Neoverse-V2-Design, das über NVLink-C2C mit NVIDIA-GPU-Dies verbunden ist. Die Grace CPU selbst erreicht eine Speicherbandbreite von 500 GB/s mit LPDDR5X — ein Wert, der das weit übersteigt, was konventionelle DDR5-Kanäle auf x86-Server-Plattformen liefern.

Im GH200 Grace Hopper Superchip teilen sich CPU und H100-GPU ein einheitliches Memory-Fabric mit 900 GB/s zwischen beiden. Das ist kein Marketingversprechen — es eliminiert den PCIe-Flaschenhals, der die GPU-Auslastung bei LLM Inference-Workloads begrenzt, bei denen das Modell häufig Daten zwischen CPU- und GPU-Speicher verschieben muss. Für die Inference großer Sprachmodelle und multimodaler Modelle liefert der GH200 messbar mehr Tokens pro Sekunde pro Dollar als vergleichbare H100-SXM5-Konfigurationen mit x86-Host-CPUs — hauptsächlich durch reduzierte Datenübertragungslatenz.

Apple M4 Ultra im Mac Pro: ARM auf Profi-Workstation-Niveau

Apples M4 Ultra, für den Mac Pro 2025 angekündigt, kombiniert zwei M4 Max-Dies über das UltraFusion-Interconnect zu einem Chip mit bis zu 80 CPU-Kernen (60 Performance, 20 Effizienz), bis zu 80 GPU-Kernen und einer Unified Memory Architecture, die bis zu 192 GB bei über 800 GB/s aggregierter Bandbreite unterstützt. Die TDP des M4-Ultra-Systems liegt bei rund 300 W Gesamtsystemleistung — vergleichbar mit einem einzelnen High-End-Intel Xeon W-Die allein.

Der Mac Pro ist kein Cloud-Server, aber seine Benchmarks sind für die Server-Debatte direkt relevant. Im Cinebench R24 nT erzielt der M4 Ultra rund 9.000–9.500 Punkte im Multi-Core — vergleichbar mit einem Threadripper 7970X bei etwa doppeltem Stromverbrauch. Entwickler, die ARM-native containerisierte Anwendungen auf M4 Ultra Mac Pros bauen und testen, betreiben bereits produktionsäquivalente Workloads lokal, bevor sie auf Graviton 4 oder Altra Max in der Produktion deployen. Die Angleichung des Software-Ökosystems schreitet schnell voran.

ARMs architektonische Vorteile für Server-Workloads

Die Gründe, warum ARM bei der Effizienz gewinnt, sind struktureller Natur — kein vorübergehender Trend. Das ARM ISA erzeugt kleinere Instruction Footprints als x86, was den Instruction-Cache-Druck reduziert. Der Verzicht auf Legacy-x87- und komplexe Variable-Length-Decode-Logik bedeutet, dass mehr Fläche pro Die auf Execution Units und Cache entfällt. Moderne ARM-Server-Kerne wie Neoverse V2 und Neoverse N2 implementieren Out-of-Order-Execution mit breiten Pipelines, die Intels Golden Cove und AMDs Zen 4 beim Durchsatz pro Takt bei Integer- und speicherintensiven Workloads ebenbürtig sind oder übertreffen.

Die Energieeffizienz-Zahlen sind über unabhängige Tests hinweg konsistent. SPECpower_ssj2008-Ergebnisse — die Performance pro Watt über verschiedene Lastniveaus messen — zeigen, dass ARM-Server-Plattformen von AWS, Ampere und NVIDIA je nach Workload und Lastniveau 15–40 % effizienter sind als x86-Äquivalente. Im Rechenzentrumsmaßstab entspricht dieser Unterschied Megawatt und Millionen von Dollar pro Jahr.

Wo x86 noch gewinnt

Ehrlichkeit erfordert, anzuerkennen, wo x86 weiterhin die Nase vorn hat:

• Windows Server-Workloads — AWS bietet keine Graviton-Windows-Instanzen an; Azure Cobalt 100 ARM-Instanzen laufen seit 2024 ausschließlich unter Linux. SQL Server und .NET Framework (nicht .NET Core) bleiben in der Praxis x86-abhängig.
• Single-Threaded-Legacy-Anwendungen — AMD EPYC Genoa und Intel Sapphire Rapids erreichen höhere Single-Core-Boost-Taktraten (bis zu 4,5 GHz) als aktuelle ARM-Server-Chips, was bei serialisierten Workloads relevant ist.
• AVX-512-abhängige Workloads — HPC-Code und einige Video-Transcoding-Pipelines sind auf Intels AVX-512-SIMD-Extensions optimiert. ARMs SVE2 ist konkurrenzfähig, erfordert aber Neukompilierung und Re-Tuning.
• ISV-Software mit x86-exklusiver Lizenzierung — Oracle Database, SAP HANA und mehrere kommerzielle EDA-Tools unterstützen ARM entweder nicht oder haben separate Lizenzbedingungen, die den Kostenvorteil zunichte machen.

Handlungsempfehlungen für Engineers bei der Wahl von Cloud-Instanzen

• Starten Sie Ihre ARM-Migration mit zustandslosen HTTP-Workloads. NGINX, Node.js, Go und containerisierte Python-APIs kompilieren sauber nach ARM64 und zeigen den schnellsten Return on Investment. Nutzen Sie AWS C8g- oder OCI Ampere A1-Instanzen und führen Sie einen A/B-Lasttest gegen Ihre aktuelle x86-Baseline durch, bevor Sie sich festlegen.
• Aktivieren Sie Graviton 4 für Java-Services konsequent. Die JVM unterstützt ARM64 seit Jahren. AWSs eigene Benchmarks zeigen 20–30 % Durchsatzgewinne bei Spring Boot- und Quarkus-Workloads auf Graviton 4 gegenüber vergleichbaren Intel-Instanzen zu niedrigeren Kosten.
• Evaluieren Sie für KI-Inference im großen Maßstab den GH200, bevor Sie auf H100 + x86 setzen. Die Unified Memory Architecture eliminiert einen realen Flaschenhals bei Modellen oberhalb von 70 Milliarden Parametern. Beantragen Sie Zugang über AWS, CoreWeave oder NVIDIA DGX Cloud, um Ihr spezifisches Modell zu benchmarken.
• Migrieren Sie Windows Server- oder AVX-512-HPC-Workloads noch nicht, sofern Sie keine bestätigten ARM-nativen Builds haben und diese getestet wurden. Die Kosteneinsparungen entstehen nicht, wenn der Workload schlechter abschneidet oder ISA-spezifische Bibliotheken benötigt, die noch nicht portiert wurden.
• Nutzen Sie Ampere Altra Max-Instanzen für Redis, Memcached und NGINX. Das 1:1-vCPU-zu-Kern-Mapping und das lineare Thread-Scaling machen die Latenz-Vorhersagbarkeit unter variabler Last messbar besser als bei SMT-fähigen x86-Instanzen.

ARMs Server-Moment steht nicht bevor — er ist bereits eingetreten. Die verbleibende Aufgabe ist die systematische Migration von Workloads, die noch aus Beharrungsvermögen auf x86 laufen und nicht aus technischer Notwendigkeit.