Chiplet-Architektur: Wie moderne Server-CPUs aufgebaut sind

Trotzdem meldet er sich, weil seine Virtualisierungsumgebung ungleichmäßig läuft. Einige VMs reagieren flott, andere wirken zäh, obwohl sie nominell auf derselben CPU laufen. Die Lizenzkosten für die hohe Kernzahl sind bereits bezahlt, der Leistungszuwachs gegenüber dem alten System fällt aber geringer aus als erwartet.

Was hier passiert, ist kein Defekt und kein Konfigurationsfehler im klassischen Sinn. Es ist die unmittelbare Konsequenz einer Designentscheidung, die in den letzten Jahren die gesamte Server-Landschaft verändert hat: der Weg weg vom monolithischen Die hin zur Chiplet-Architektur. Wer versteht, wie moderne Server-CPUs aufgebaut sind und warum Hersteller wie AMD und Intel ihre Prozessoren als modulare Multi-Chip-Module konstruieren, kann derartige Phänomene nicht nur erklären, sondern auch aktiv entschärfen. Das ist das Thema dieses Artikels: Wie funktioniert die Chiplet-Architektur in Server-Prozessoren, und was bedeutet sie konkret für Admins, die mit diesen Systemen arbeiten?

Vom monolithischen Die zum modularen Multi-Chip-Modul

Über viele Jahre hinweg war ein Server-Prozessor ein einzelner, zusammenhängender Siliziumblock – ein sogenannter monolithischer Die. Auf diesem Die befanden sich Rechenkerne, Cache-Hierarchie, Speichercontroller und I/O-Logik in einem Stück. Solange sich Strukturen vergrößern ließen, war dieser Ansatz effizient: kurze Signalwege, einheitliche Fertigung, aus Sicht des Betriebssystems eine einzige CPU.

Mit dem Ende klassischer Skalierungsregeln stößt dieser Ansatz jedoch an harte Grenzen. Je größer ein Die wird, desto geringer fällt die Ausbeute in der Fertigung aus, weil ein einziger Defekt auf dem Wafer den gesamten Chip unbrauchbar machen kann. Hinzu kommen steigende Maskenkosten und die Tatsache, dass unterschiedliche Funktionen auf einem Die unterschiedliche Fertigungsprozesse optimaler umsetzen würden – etwa dichte Logik für Rechenkerne und robuste I/O-Schaltungen für externe Schnittstellen.

Die Chiplet-Architektur ist die Antwort auf genau diese Probleme. Statt eines großen monolithischen Dies werden mehrere kleinere Chiplets in einem gemeinsamen Package zusammengefasst und intern über einen Die-to-Die-Interconnect miteinander verbunden. Für das Betriebssystem wirkt das Package weiterhin wie eine einzelne CPU, intern jedoch finden sich klar abgegrenzte Bausteine: Rechen-Chiplets für die Kerne, I/O-Dies für Speicher- und Schnittstellenanbindung, gegebenenfalls zusätzliche Tiles für spezielle Funktionen.

Chiplets sind kein Selbstzweck. Sie sind eine Antwort auf Physik, Ausbeute und Kosten – und sie verändern die Spielregeln für die Leistung im laufenden Betrieb.

AMD EPYC 9005: Infinity Fabric und die NUMA-Topologie

Die EPYC-9005-Familie, die AMD im Oktober 2024 vorgestellt hat, ist ein gutes Beispiel dafür, wie konsequent ein Hersteller das Chiplet-Konzept für Server-CPUs umsetzen kann. Im Zentrum steht ein zentraler I/O-Die, um den herum mehrere Core-Complex-Dies (CCDs) angeordnet sind. Die Anbindung zwischen diesen Bausteinen übernimmt AMDs Infinity Fabric, ein Hochgeschwindigkeits-Interconnect, der innerhalb des Packages arbeitet und sowohl die Datenpfade als auch die Kohärenz zwischen den Chiplets organisiert.

Ein einzelnes CCD enthält einen Core Complex, kurz CCX. Innerhalb eines CCX arbeiten entweder bis zu acht Zen-5-Kerne oder bis zu 16 Zen-5c-Kerne zusammen, die sich 32 MB L3-Cache teilen. Auf dem I/O-Die selbst sitzen unter anderem die Speichercontroller und die I/O-Subsysteme. Insgesamt nennt AMD für die Familie bis zu 192 Kerne und 384 Threads, bis zu 12 DDR5-Kanäle pro CPU sowie DDR5-Geschwindigkeiten bis 6400 MT/s. Diese Werte sind Maximalwerte innerhalb der Produktfamilie und nicht automatisch in jedem einzelnen Modell erreichbar – beim Vergleich konkreter SKUs lohnt sich also ein Blick in die Detaildaten.

Eine wichtige Konsequenz: Für das Betriebssystem ist eine EPYC-9005-CPU eine NUMA-Architektur. Das bedeutet, dass Zugriffe auf Speicher und I/O je nach räumlicher Nähe von Kern, Speichercontroller und I/O-Controller unterschiedliche Latenzen aufweisen können. Besonders deutlich wird das in der Konfiguration NPS=4, bei der ein einzelner Sockel in vier NUMA-Domänen mit jeweils bis zu vier CCDs und drei Speichercontrollern aufgeteilt wird.

Der I/O-Die verfügt über acht SerDes-Blöcke mit jeweils 16 Lanes, also rechnerisch bis zu 128 I/O-Lanes. Dieselbe physische I/O-Schicht kann je nach Konfiguration für PCIe Gen 5, Infinity Fabric, SATA und CXL genutzt werden – das ist möglich, weil es sich um unterschiedliche Protokolle auf einer gemeinsamen Infrastruktur handelt. Gerade diese Flexibilität ist einer der großen Vorteile des Chiplet-Ansatzes, weil sich derselbe Siliziumblock für verschiedene Aufgaben konfigurieren lässt.

Das bedeutet für die Praxis: Wer auf einem EPYC-9005-System eine VM startet, sollte im Hypervisor darauf achten, dass die vCPUs aus derselben NUMA-Domäne kommen wie der zugewiesene Speicher. Andernfalls wandern Speicherzugriffe über die Infinity-Fabric-Links zwischen den Chiplets, was Latenz kostet. Werkzeuge wie numactl auf Linux oder die NUMA-Affinitätseinstellungen in VMware und Hyper-V sind hier die ersten Ansprechpartner.

Mehr Kerne allein bringen wenig, wenn Speicher und I/O nicht lokal angebunden sind. NUMA-Awareness ist bei Chiplet-Designs kein Bonus, sondern Grundvoraussetzung.

Intel Xeon 6: Tile-basierte Architektur für skalierbare Workloads

Auch Intel geht ab der Xeon-6-Generation über die gesamte Produktfamilie hinweg zu einem modularen, tile-basierten Mehrchip-Aufbau über. Statt von Chiplets spricht Intel von Tiles – die Idee ist jedoch vergleichbar: Mehrere Compute- und I/O-Tiles werden in einem gemeinsamen Prozessor-Package integriert und intern über eine Die-to-Die-Verbindung angesprochen. Für das Betriebssystem bleibt die Xeon-6-CPU eine einzelne CPU, intern jedoch sind die Ressourcen über mehrere Tiles verteilt, was Spielraum für sehr unterschiedliche Modellvarianten schafft.

Ein besonders interessantes Beispiel für diese Modularität ist der Intel Xeon 6 SoC für Netzwerk- und Edge-Einsatz. Hier kombiniert Intel ein Compute-Chiplet der Xeon-6-Familie mit einem I/O-Chiplet, das auf Edge-Anwendungen zugeschnitten ist. Genannt werden bis zu 32 PCIe-5.0-Lanes, bis zu 16 CXL-2.0-Lanes und 2×100-Gbit/s-Ethernet. Die Zahl der Speicherkanäle hängt vom jeweiligen BGA-Package ab und liegt je nach Ausführung bei vier oder acht Kanälen. Damit ist dieses Modell eher für kompakte, bandbreitenintensive Appliances gedacht als für klassische, speicherlastige Datenbankserver.

Das Schöne an diesem Ansatz aus Sicht eines Plattformentwicklers: Die Tiles lassen sich gezielt kombinieren, sodass für unterschiedliche Workloads unterschiedliche Profile entstehen, ohne dass die CPU von Grund auf neu entwickelt werden muss. Wer heute eine Storage-Appliance mit hoher Bandbreite baut, kann auf einen Xeon-6-SoC mit vielen PCIe-Lanes zurückgreifen. Wer eher klassische Virtualisierung fährt, wählt ein anderes Tile-Set mit mehr Speicherkanälen. Im Hintergrund steht auch Intels Engagement für 3D-Packaging-Technologien wie Foveros – sie sind die Voraussetzung dafür, dass sich Tiles in Zukunft nicht nur nebeneinander, sondern auch stapelweise kombinieren lassen.

Das bedeutet für die Praxis: Beim Vergleich von Xeon-6-Modellen ist es sinnvoll, nicht nur die Kernzahl und die Taktfrequenz zu betrachten, sondern auch die Anzahl und Anbindung der Tiles. Ein scheinbar kleiner Unterschied bei den Speicherkanälen kann sich je nach Datenbank- oder In-Memory-Workload deutlich im Durchsatz niederschlagen.

Die Rolle von UCIe bei der Standardisierung von Die-to-Die-Interconnects

Eine Architektur lebt von ihren Verbindungen. Wenn Chiplets in einem Package zusammenarbeiten, müssen sie sich über eine standardisierte Schnittstelle verständigen. Genau hier setzt UCIe an, das Universal Chiplet Interconnect Express Consortium. UCIe definiert einen offenen Standard für Die-to-Die-Interconnects und deckt mehrere Ebenen ab: die physische Schicht, den Protokoll-Stack, das Softwaremodell und ein Konformitätsregelwerk, mit dem Hersteller die Kompatibilität ihrer Chiplets nachweisen können.

Für die Industrie ist das ein entscheidender Schritt. Solange jeder Hersteller seinen eigenen Die-to-Die-Interconnect pflegt, lassen sich Chiplets verschiedener Anbieter kaum miteinander kombinieren. Ein gemeinsamer Standard schafft die Grundlage dafür, dass Chiplets aus unterschiedlichen Quellen in einem Package koexistieren können – vorausgesetzt, die elektrischen, Packaging- und Produktanforderungen passen zusammen. Der Standard allein ersetzt diese Prüfungen nicht, aber er senkt die Hürde für ein Ökosystem erheblich.

Die UCIe-2.0-Spezifikation erweitert das Spektrum unter anderem um Funktionen für Test, Management und Debug über mehrere Chiplets hinweg und unterstützt 3D-Packaging. Die Variante UCIe 3D ist laut Konsortium auf Hybrid Bonding mit Bump-Pitches von 10 bis 25 µm bis hin zu 1 µm oder weniger ausgelegt. Solche Werte zeigen, wohin die Reise geht: weg von klassischer Wire-Bond-Technik hin zu extrem feinen vertikalen Verbindungen, die Latenzen weiter senken und die Bandbreite pro Fläche deutlich erhöhen.

Ohne standardisierte Die-to-Die-Schnittstellen bleibt jede Chiplet-Architektur eine Insellösung. UCIe ist der Versuch, daraus ein gemeinsames Vokabular zu machen – vergleichbar mit PCIe für Steckkarten.

Performance-Faktoren: Warum Kernanzahl nicht gleich Rechenleistung ist

Zurück zum Eingang dieses Artikels: Der Kunde mit 192 Kernen, der mehr erwartet hat. Die Chiplet-Architektur erklärt einen Teil des Phänomens, aber bei weitem nicht alles. Die tatsächliche Performance hängt von mehreren Faktoren ab, die in der Praxis oft unterschätzt werden.

Cache-Hierarchie und -Aufteilung: Innerhalb eines CCX teilen sich die Kerne 32 MB L3-Cache. Arbeitet eine Anwendung stark innerhalb eines CCX, ist die Cache-Lokalität hoch. Springt sie zwischen CCXs, müssen Daten über Infinity Fabric ausgetauscht werden, was zusätzliche Latenz bedeutet. Bei stark threadparallelen Datenbank-Workloads kann genau das den Unterschied zwischen linearer und stagnierender Skalierung ausmachen.

NUMA-Lokalität: Bei NPS=4 kann ein einzelner Speicherkanal weit vom ausführenden Kern entfernt sein. NUMA-Awareness in Hypervisor, Betriebssystem und Anwendung ist der wichtigste Stellhebel. Viele aktuelle Datenbanken und Middleware-Plattformen bringen NUMA-Erkennung inzwischen mit, sie muss aber auch tatsächlich aktiviert sein.

Speicherbandbreite: 12 DDR5-Kanäle mit bis zu 6400 MT/s sind eine Größenordnung, die viele ältere Anwendungen gar nicht ausreizen können. Bottlenecks entstehen dann nicht in der CPU, sondern im Speicher-Subsystem oder im Storage-Backend. Ein aktuelles NVMe-Array bringt hier oft mehr als ein weiteres CPU-Upgrade.

I/O-Topologie: Mit bis zu 128 I/O-Lanes und der gemeinsamen Nutzung für PCIe, Infinity Fabric, SATA und CXL ist die Frage, wie diese Lanes im konkreten System auf die Slots und Geräte verteilt werden, entscheidend. Eine falsche Slot-Bestückung kann dazu führen, dass schnelle NVMe-SSDs an einen Controller angebunden sind, der über eine ausgelastete Bridge läuft.

Firmware und BIOS: NUMA-Konfiguration, CCD-Verteilung und Speicher-Interleaving werden über BIOS-Einstellungen gesteuert. Standardprofile sind nicht immer optimal. Es lohnt sich, das BIOS-Setup mit der Workload abzugleichen und gegebenenfalls vom Plattformhersteller freigegebene Profile für Datenbank-, Virtualisierungs- oder HPC-Workloads zu nutzen.

Eine kleine Auswahl bewährter Maßnahmen aus dem Support-Alltag:

• Vor dem Roll-out die NUMA-Topologie mit Tools wie lscpu, numastat oder den Hersteller-Utilities sichtbar machen und dokumentieren.
• Virtuelle Maschinen und Container nach Möglichkeit an eine NUMA-Domäne pinnen, statt sie quer über das Package zu verteilen.
• Workloads profilieren, bevor neue Hardware angeschafft wird. Eine aktuelle Server-CPU entfaltet ihre Vorteile nur, wenn die Anwendung Speicherbandbreite und Parallelität tatsächlich nutzt.
• Bei Fragen zur BIOS-Konfiguration das Handbuch oder den Plattform-Guide des Herstellers konsultieren – dort sind die NUMA-Profile dokumentiert.
• Storage-Anbindung prüfen: Steckt eine NVMe-SSD in einem Slot, der über einen Switch oder eine Bridge angebunden ist, kostet das Bandbreite. Ein Blick in die Topologie des Mainboards schafft schnell Klarheit.

Modularer Prozessoraufbau als neue Normalität

Die Chiplet-Architektur ist keine Spielerei und kein Marketingbegriff. Sie ist eine Reaktion auf die Grenzen monolithischer Dies und eine der Antworten, mit denen AMD und Intel in den vergangenen Jahren Server-CPUs mit Dutzenden bis Hunderten Kernen auf den Markt gebracht haben. Multi-Chip-Module wie der EPYC 9005 mit Infinity Fabric oder der Xeon 6 mit seinem Tile-Aufbau zeigen, dass sich Modularität und Skalierbarkeit nicht widersprechen – sie ergänzen sich zu einem flexiblen, auf Workloads zugeschnittenen Design.

Gleichzeitig verschiebt diese Architektur einen Teil der Verantwortung dorthin, wo sie hingehört: in die Konfiguration, das Monitoring und das Verständnis der eigenen Workload. Wer weiß, wie sein Prozessor aufgebaut ist und wo die NUMA-Grenzen verlaufen, kann aus jeder Generation mehr herausholen. Wer das ignoriert, kauft teure Kerne, die im ungünstigsten Fall Däumchen drehen.

Standardisierungsinitiativen wie UCIe werden diese Entwicklung in den nächsten Jahren weiter beschleunigen und die Auswahl an Chiplets und Kombinationsmöglichkeiten vergrößern. Wer jetzt die Grundlagen versteht, ist auf diese kommende Vielfalt gut vorbereitet.