Custom-ARM-Server-Chips nagen an der x86-Dominanz in Cloud-Rechenzentren

Zwei Jahrzehnte lang bedeutete „Server" x86 — einen Intel- oder AMD-Chip, der denselben Instruction Set ausführte, egal ob er im Rechenzentrum einer Bank oder im Rack eines Startups in einer Colocation-Einrichtung stand. Diese Annahme bricht bei den drei größten Cloud-Anbietern gerade zusammen. AWS, Google Cloud und Microsoft Azure haben jeweils in den vergangenen Jahren ihre eigenen Arm-basierten Server-CPUs entwickelt, und Mitte 2026 entfällt auf diese Chips ein so großer Anteil der neu aufgebauten Hyperscaler-Rechenkapazität, dass x86 nicht mehr der selbstverständliche Standard ist, der es einmal war.

Die Zahlen hinter dem Wandel

Der Arm-Anteil an Server-CPU-Lieferungen ist laut Halbleiteranalysten, die diese Kategorie beobachten, von rund 5 % im Jahr 2020 auf etwa 15 bis 23 % im Jahr 2025 gestiegen. Die aufschlussreichere Zahl kam aus Präsentationen auf der Computex 2026: Dort vorgestellte Studien bezifferten Arm-basierte Chips auf nahezu die Hälfte der Hyperscaler-Rechenkapazität — nicht nach Stückzahlen, sondern gemessen an der tatsächlich eingesetzten Kapazität bei AWS, Google und Microsoft zusammen. Der Arm-basierte Servermarkt selbst ist von rund 5,8 Milliarden US-Dollar im Jahr 2023 auf geschätzte 8,2 Milliarden US-Dollar im Jahr 2026 gewachsen.

Dieses Wachstum ging interessanterweise nicht zulasten von AMD. Die Wachstumsprognosen für AMD-Server-CPU-Lieferungen wurden für 2026 von 14 % auf 23 % nach oben korrigiert, und Intels eigene Prognose verschob sich von einem Rückgang um 3 % auf ein Wachstum von 3 %. Der Kuchen wächst schnell genug, dass die Gewinne von Arm und AMD gleichzeitig stattfinden — es ist der Legacy-Intel-x86-Anteil, nicht die x86-Architektur als solche, der am stärksten unter Druck gerät.

Drei Chips, drei unterschiedliche Wetten

AWS ist am weitesten vorangeprescht. Graviton5, seit dem 10. Juni 2026 allgemein verfügbar, vereint 192 Arm Neoverse V3-Kerne auf vier Chiplets, die im 3nm-Prozess von TSMC gefertigt werden, mit 192 MB L3-Cache, DDR5-Speicher und PCIe Gen 6 — das entspricht einer fünffachen Cache-Erhöhung gegenüber Graviton4 und einem behaupteten Performance-Uplift von 25 %. AWS hat ihn explizit für Workloads der „agentic AI era" entwickelt: Inference Serving, Retrieval-Pipelines und die Art von bursty, speicherhungrigen Request-Mustern, die AI Agents erzeugen — anstelle klassischer Batch-Computing-Lasten.

Google Axion verfolgt einen anderen Ansatz und ist als CPU-Hälfte eines aufeinander abgestimmten Paares mit Googles TPU v8-Racks positioniert. Google gibt an, dass Axion eine um 30 % bessere Performance als konkurrierende Arm-Cloud-Instanzen und eine um 60 % bessere Energieeffizienz als vergleichbare x86-Instanzen liefert — wobei Effizienz das entscheidende Stichwort ist, da Axions Aufgabe im Wesentlichen darin besteht, Daten in TPUs einzuspeisen und aus ihnen auszulesen, ohne dabei zum Leistungs- oder Wärme-Bottleneck dieser Pipeline zu werden.

Microsofts Cobalt ist der leiseste der drei, aber an diesem Punkt wohl der produktionsbewährteste: Er läuft heute in Azure-Regionen mit echten Workloads, wobei Kunden wie Databricks produktive Datenplattformen darauf betreiben — und nicht nur Pilotdeployments. Anders als Graviton und Axion, die auf KI-nahe Framing-Narrative setzen, hat Microsoft Cobalt nüchterner als allgemeines Kosten- und Effizienzangebot für gewöhnliche Azure-Rechenlasten vermarktet.

Warum Hyperscaler heute ihre eigene Silicon-Strategie verfolgen

Die Eigenentwicklung einer Server-CPU ist keine Entscheidung, die Cloud-Anbieter leichtfertig getroffen haben — sie erfordert jahrelanges Chip-Engineering-Investment, das die meisten Softwareunternehmen nie angehen. Die Gegenleistung ist die Kontrolle über eine Variable, die früher vollständig in den Händen von Intels und AMDs Produktroadmaps lag: Performance-per-Watt im Rechenzentrumsmaßstab. Strom ist inzwischen die bindende Beschränkung dafür, wie viel Rechenkapazität ein Hyperscaler physisch aufbauen kann — angesichts von Grid-Interconnection-Limits und dem enormen Strombedarf von AI-Training- und Inference-Clustern. Eine intern entwickelte CPU kann gezielt auf den Workload-Mix optimiert werden, den der jeweilige Anbieter tatsächlich betreibt, statt auf das allgemeine Profil, das ein Merchant-Chiphersteller anpeilen muss, um alle Kunden zu bedienen.

Das erklärt auch, warum Nvidias Grace CPU — ein Arm-basierter Chip, der unmittelbar neben Nvidias GPUs auf demselben Board sitzt — hier ebenfalls relevant ist, obwohl Nvidia kein Cloud-Anbieter ist. Er ist der deutlichste Beleg dafür, dass Arms Vorteil in diesem Zyklus nicht wirklich auf den Kosten für Instruction-Set-Lizenzen beruht; vielmehr geht es darum, welche Architektur einem Chip-Designer ermöglicht, genau die CPU-Memory-Interconnect-Kombination zu bauen, die sein spezifischer Accelerator oder Workload benötigt — anstatt das zu kaufen, was Intel oder AMD in dem jeweiligen Jahr geliefert haben.

Was das für AMD, Intel und unabhängige Arm-Anbieter bedeutet

AMDs beschleunigte Server-Wachstumsdynamik legt nahe, dass das Unternehmen Anteile von Intel übernommen hat, anstatt Terrain an Arm zu verlieren — EPYC bleibt die Standard-Merchant-x86-Wahl für Workloads, die nicht von einem Hyperscaler mit eigenem Silicon-Programm betrieben werden. Intels Rückkehr zu positivem Wachstum ist ein kleinerer Erfolg, aber ein echter — nach Jahren der Erosion beim Server-Marktanteil. Das Unternehmen, das vom Trend zur Hyperscaler-eigenen Silicon-Strategie ausgesperrt bleibt, ist Ampere Computing: Der unabhängige Arm-Server-Chip-Designer, dessen AmpereOne-Prozessoren direkt mit Graviton und Axion für Kunden konkurrieren, die keinen eigenen Chip entwickeln wollen — Cloud-Anbieter unterhalb der Top drei sowie Unternehmen, die Arm-Workloads in Colocation statt in Hyperscaler-Clouds betreiben.

Was das bedeutet, wenn Sie entscheiden, wo Sie Workloads ausführen

Für Engineering-Teams, die Cloud-Instanztypen evaluieren, hat sich die praktische Frage von „Ist Arm reif genug?" zu „Welche Workloads sollten als Erstes migriert werden?" verschoben. Stateless, horizontal skalierte Services — Web-Tiers, API Gateways, Inference Serving — verzeichnen in der Regel die deutlichsten Preis-Leistungs-Gewinne auf Graviton- oder Axion-Instanzen, oft 20 bis 40 % niedrigere Kosten bei gleichwertigem Durchsatz — vorausgesetzt, Ihre Build-Pipeline produziert bereits Arm64-Binaries oder Ihr Language Runtime abstrahiert den Unterschied (Go, Java und die meisten interpretierten Sprachen migrieren mit minimalem Aufwand; C/C++-Codebasen mit architekturspezifischen Intrinsics erfordern echte Porting-Arbeit). Die Chips, die früher eine Nischen-Kostenoptimierung für einen Teil der Workloads waren, sind heute die Standardlösung, auf der AWS, Google und Microsoft neue Kapazitäten betreiben wollen — was bedeutet, dass das Benchmarking des eigenen Workloads auf Arm-Instanzen keine optionale Due-Diligence-Maßnahme mehr ist, sondern das Aufholen gegenüber dem Stand der Infrastruktur, der bereits Realität ist.