Compute Express Link: Funktionsweise und Vorteile für Server

Wenn der Arbeitsspeicher knapp wird, bevor die DIMM-Slots voll sind

Passende DDR5-Module müssen dann nicht nur verfügbar sein, sondern auch zur vorgesehenen Geschwindigkeit, Bestückung und Plattformkonfiguration passen. Der Griff zum zweiten Server löst das Kapazitätsproblem zwar, schafft aber zugleich neue Komplexität bei Betrieb, Lizenzen und Datenplatzierung.

Genau dort setzt Compute Express Link an: nicht als weiterer Name im Protokollalphabet, sondern als Möglichkeit, Speicher und Beschleuniger kohärent an den Prozessor anzubinden. Die Compute-Express-Link-Funktionsweise im Server ist allerdings mehr als ein kompatibler Steckplatz. CPU, Mainboard, Firmware, Topologie und Betriebssystem müssen dieselbe Sprache sprechen. Fehlt eines dieser Elemente, bleibt der vermeintliche CXL-Port im Zweifel ein gewöhnlicher PCIe-Steckplatz.

Kohärente Protokolle: Die Architektur von CXL.io, CXL.cache und CXL.mem

CXL nutzt dieselbe physische Schicht wie PCI Express: elektrische Verbindung, Steckverbinder und Teile der bestehenden Infrastruktur bleiben damit vertraut. Der cxl-vs-pcie-Unterschied liegt nicht im Blech des Steckplatzes, sondern in den zusätzlichen Protokollen. Sie erlauben eine Cache-Kohärenz zwischen Host und Gerät, die PCIe allein nicht bereitstellt.

Für ein cxl standard einfach erklärt genügt deshalb ein Bild: PCIe transportiert Daten zu einem Gerät und zurück. CXL kann zusätzlich regeln, welche Seite gerade mit einer gültigen Version dieser Daten arbeitet. Das ist entscheidend, sobald ein Beschleuniger im Arbeitsspeicher des Hosts liest oder die CPU Speicher auf einem externen Gerät wie einen Teil ihres eigenen Adressraums behandelt.

CXL.io: Der I/O-Anker

CXL.io übernimmt weitgehend die vertrauten Aufgaben von PCIe: Geräteerkennung, Initialisierung, Konfiguration und klassische I/O-Zugriffe. Ein CXL-Gerät erscheint für das Betriebssystem daher zunächst wie ein PCIe-Endgerät.

Allein mit CXL.io entsteht noch kein Speicherpool und keine Kohärenz. Die Ebene ist dennoch unverzichtbar, weil sie das Gerät in die Plattform einbindet und die Basis für die weitergehenden CXL-Protokolle bildet. Ein Gerät, das nur diese Schicht nutzt, besitzt praktisch eine PCIe-Verbindung mit CXL-Fähigkeit, aber keinen unmittelbaren Vorteil für die Speicherarchitektur.

CXL.cache: Geräte lesen kohärent aus dem Host

CXL.cache erlaubt einem angeschlossenen Gerät, den Arbeitsspeicher des Hosts kohärent zu lesen und lokal zwischenzuspeichern. Das ist insbesondere für FPGA-, ASIC- und andere Beschleuniger relevant, die große Datenmengen aus dem Hauptspeicher verarbeiten, ohne für jeden Zugriff eine neue Kopierkette aufzubauen.

Vor CXL waren solche Konstruktionen meist auf DMA-Mechanismen, fest reservierte Speicherbereiche und zusätzliche Synchronisationslogik angewiesen. Das funktioniert, aber es verschiebt Komplexität in Treiber und Anwendungen. CXL.cache verlagert einen wesentlichen Teil dieser Aufgabe näher an die Hardware: CPU-Cache und Geräte-Cache bleiben über das Protokoll abgestimmt.

CXL.mem: Der Host greift auf Gerätespeicher zu

CXL.mem dreht die Richtung um. Hier greift die CPU auf Speicher zu, der physisch auf einem CXL-Gerät liegt. Dieser Speicher wird kohärent in den Adressraum des Hosts eingebunden; Anwendungen müssen nicht selbst zwischen „internem“ und „externem“ RAM unterscheiden.

Das ist der Kern der Speichererweiterung im Server. Ein einzelnes CXL-Speichergerät kann Kapazität ergänzen, ohne dass dafür zwingend weitere lokale DIMMs erforderlich sind. Hinter Switches lässt sich die Idee in größere Topologien übertragen. Für viele IT-Verantwortliche ist CXL.mem deshalb der praktische Einstieg in CXL: Nicht, weil lokaler DRAM dadurch ersetzt würde, sondern weil sich die Speicherhierarchie kontrolliert erweitern lässt.

Compute Express Link ist im Kern PCIe plus Kohärenz – und genau diese Kohärenz ist der Punkt, an dem herkömmliche Erweiterungskarten an ihre Grenze stoßen.

Klassifizierung der Hardware: Von Beschleunigern bis zur Speichererweiterung

Die CXL-Spezifikation unterscheidet drei verbreitete Gerätetypen. Das ist keine Formalie für Datenblätter. Die Geräteklasse bestimmt, welche Protokolle nutzbar sind und ob eine Karte vor allem beschleunigt, eigenen Speicher bereitstellt oder beides verbindet.

Typ-1-Geräte sind für Beschleuniger interessant, die eng mit Host-Daten arbeiten, aber keinen eigenen Speicher in den gemeinsamen Adressraum einbringen müssen. Typ 2 kombiniert beide Richtungen: Das Gerät kann Host-Speicher kohärent lesen und zugleich eigenen Speicher bereitstellen. Das macht diesen Typ für heterogene Rechenlasten attraktiv, erhöht aber auch die Anforderungen an Treiber, Plattform und Softwaremodell.

Für den klassischen Ausbau der Speicherkapazität ist Typ 3 die naheliegende Klasse. Hier steht CXL.mem im Mittelpunkt. Ein solcher Ausbau beantwortet jedoch nicht jede Leistungsfrage automatisch. Lokaler DRAM bleibt die bevorzugte Ressource für besonders latenzempfindliche Datenstrukturen. CXL-Speicher ist eine zusätzliche Ebene, keine magische Gleichstellung aller Bytes im System.

Die sinnvolle Reihenfolge lautet daher: Erst den Engpass beschreiben, dann die Geräteklasse wählen, anschließend Plattform und konkrete Produkte prüfen. In der Praxis passiert häufig das Gegenteil. Dann wird eine verfügbare Karte zum Ausgangspunkt der Architektur – und die eigentliche Frage, ob Kapazität, Bandbreite, Latenz oder Beschleunigung fehlt, kommt zu spät.

Memory Pooling und Fabrics: Skalierbare Ressourcen im CXL-4.0-Ökosystem

Innerhalb eines Servers ist CXL bereits nützlich. Spannend wird der Standard im Rechenzentrum, wenn Speicher nicht mehr nur an einen einzelnen Mainboard-Sockel gebunden gedacht wird. Memory Pooling beschreibt das Zusammenfassen von CXL-Speicherressourcen in einer Topologie mit Switches und mehreren angeschlossenen Komponenten.

Ein CXL-Switch leitet CXL- und PCIe-Verbindungen zwischen Upstream-, Downstream- und Peer-Geräten weiter. Damit entstehen Architekturen, in denen Speicher nicht zwangsläufig dauerhaft in genau einem Servergehäuse verbleiben muss. Das ist für Umgebungen interessant, in denen Workloads unterschiedlich viel Kapazität benötigen und klassische DIMM-Bestückung regelmäßig zu Überprovisionierung führt.

Was CXL 4.0 tatsächlich erweitert

Die aktuelle öffentliche Spezifikation ist CXL 4.0. Sie wurde am 18. November 2025 angekündigt und verdoppelt die Signalisierungsrate von 64 GT/s auf 128 GT/s. CXL 4.0 basiert auf PCIe 7.0 und bleibt zu CXL 3.x, 2.0, 1.1 und 1.0 rückwärtskompatibel.

Zu den cxl-3-1-features und den späteren Erweiterungen gehört die Entwicklung hin zu größeren, flexibleren Fabric-Topologien. CXL 4.0 ergänzt gebündelte Ports, native x2-Linkbreiten und die Möglichkeit von bis zu vier Retimern pro Verbindung. Das verbessert die Optionen für Fan-out und größere Reichweiten in künftigen Plattformen.

Die Einschränkung ist wichtig: Eine Spezifikation ist kein Liefertermin für marktreife Hardware. Wer eine Serverlandschaft plant, sollte sauber trennen zwischen einer Architektur, die der Standard beschreibt, und Komponenten, die tatsächlich mit der gewünschten Generation, Linkbreite und Firmware verfügbar sind. Gerade bei CXL entscheidet diese Unterscheidung über realistische Erwartungen.

Pooling ist nicht automatisch Sharing

Memory Pooling wird oft mit gemeinsam genutztem Speicher gleichgesetzt. Das greift zu kurz. Ein Pool kann Speicher zunächst so bereitstellen, dass definierte Bereiche einem Host zugewiesen werden. Das ist etwas anderes als ein Modell, bei dem mehrere Hosts gleichzeitig denselben Speicherbereich nutzen und Lasten dynamisch verteilen.

Die exklusive Zuweisung ist betrieblich klarer: Ein Host erhält einen Bereich, das Betriebssystem verwaltet ihn als Ressource dieses Systems, und die Zuständigkeiten bleiben nachvollziehbar. Echtes Sharing verlangt zusätzliche Fabric-, Sicherheits- und Softwaremechanismen. Es ist eine deutlich anspruchsvollere Disziplin als das bloße Anschließen mehrerer Speichergeräte an einen Switch.

Für memory pooling im Rechenzentrum ist das keine Spitzfindigkeit. Die Frage lautet nicht nur: „Wie viel Speicher kann ich bündeln?“ Sie lautet vor allem: „Wer darf welchen Speicher wann nutzen, und wie verhält sich die Anwendung, wenn sich Latenz und Entfernung innerhalb der Speicherhierarchie unterscheiden?“ Wer das vor der Beschaffung sauber beantwortet, plant eine Plattform. Wer es erst nach der Installation klärt, verwaltet im ungünstigen Fall eine Sammlung teurer Sonderfälle.

Implementierung in der Praxis: Intel Xeon 6 und NUMA-Management unter Linux

CXL-Hardware wird nicht dadurch produktiv, dass sie im Server erkannt wird. Der relevante Teil beginnt danach: Wie stellt das Betriebssystem den Speicher dar, welche NUMA-Distanzen sieht die Anwendung, und welche Daten gehören wirklich in welche Ebene?

Unter Linux erscheinen lokaler DRAM und CXL-Speicher im Standardmodus als getrennte NUMA-Knoten. Das ist konsequent, denn beide Speicherarten unterscheiden sich in ihrer Anbindung. Linux und Anwendungen können Daten und Prozesse damit gezielt platzieren. Diese Freiheit ist wertvoll, verlangt aber ein Verständnis für den Workload.

Eine Datenbank mit klaren Hotsets, eine In-Memory-Analyse und eine virtualisierte Umgebung reagieren nicht identisch auf zusätzlichen, weiter entfernten Speicher. Wer einfach nur Kapazität hinzufügt und die Platzierung dem Zufall überlässt, kann zwar Speicherdruck entschärfen, zugleich aber die Latenz an einer kritischen Stelle erhöhen.

Was die Intel-Plattform mitbringt

Eine am 8. Juli 2026 überprüfte Intel-Kompatibilitätsübersicht zeigt, dass Intel Xeon Scalable der vierten und fünften Generation sowie Intel Xeon 6 und Xeon 6+ CXL und PCIe 5.0 unterstützen. Die ersten drei Xeon-Scalable-Generationen unterstützen weder CXL noch PCIe 5.0. Bei Upgrade-Projekten wird dieser Bruch zwischen Plattformgenerationen regelmäßig unterschätzt.

Intel Xeon 6 bietet laut Produktübersicht bis zu 64 CXL-2.0-Lanes mit bis zu 32 GT/s je Lane und unterstützt Geräte der Typen 1, 2 und 3. Das ist eine solide Grundlage, ersetzt aber keine Prüfung des konkreten Servers. Entscheidend sind weiterhin:

• Führt das Mainboard die vorgesehenen CXL-Signale tatsächlich an die gewünschten Steckplätze?
• Unterstützt das eingesetzte BIOS beziehungsweise UEFI die benötigte CXL-Funktion und die gewünschte Topologie?
• Passt die Firmware des CXL-Geräts zur Plattform und zum vorgesehenen Betriebsmodus?
• Teilt sich ein Steckplatz Lanes mit anderen Komponenten, etwa Netzwerk, Storage oder GPU?
• Ist die gewählte Linkbreite auch nach Bestückung aller Erweiterungskarten noch verfügbar?

Ein CPU-Datenblatt kann eine Fähigkeit ausweisen. Es garantiert nicht, dass jede Serverkonfiguration diese Fähigkeit auch nutzbar macht. Gerade bei dicht bestückten Systemen entscheiden Lane-Aufteilung, Riser-Design und Firmware-Freigaben über den tatsächlichen Funktionsumfang.

NUMA oder Flat Memory Mode

Auf unterstützten Xeon-6-Systemen stehen für CXL-Speicher unterschiedliche Platzierungsmodelle zur Verfügung. Im klassischen NUMA-Modus bleiben lokaler DRAM und CXL-Speicher als getrennte Knoten sichtbar. Das erlaubt eine bewusste Steuerung: Latenzkritische Daten bleiben möglichst lokal, weniger häufig genutzte Datenstrukturen können in den CXL-Bereich wandern.

Der Aufwand ist nicht trivial. Anwendungen müssen NUMA-Eigenschaften entweder selbst berücksichtigen oder durch Betriebssystem- und Orchestrierungsmechanismen passend gesteuert werden. Besonders in virtualisierten Umgebungen sollte klar sein, welche vNUMA-Topologie der Gast sieht und wo die tatsächlichen Speicherseiten auf dem Host liegen.

Der Intel Flat Memory Mode verfolgt den anderen Ansatz. Er kann beide Speicherarten als flachen Adressraum darstellen und die Platzierung in Hardware verwalten. Für Standardworkloads reduziert das die Komplexität erheblich. Der Preis dafür ist weniger direkte Kontrolle durch den Administrator. Bei sehr gezielt optimierten Anwendungen kann die explizite NUMA-Sicht deshalb weiterhin die bessere Wahl sein.

CXL erweitert die Speicherhierarchie. Ob daraus ein Kapazitätsgewinn oder ein Latenzproblem wird, entscheidet die Platzierung der Daten.

Die Wahl sollte vor der Inbetriebnahme getroffen werden. Ein späterer Wechsel betrifft nicht nur eine BIOS-Option, sondern oft die Annahmen, auf denen Betriebssystemkonfiguration, Virtualisierung und Anwendungsbetrieb beruhen.

Strategien für die Speicherplatzierung: Flat Memory Mode und Alignment-Vorgaben

Neben Plattform und NUMA-Modell bestimmt der Kernel, wie CXL-Speicher konkret als Ressource verfügbar wird. Das betrifft Regionen, Blockgrößen und die Frage, ob Speicher im laufenden Betrieb hinzugefügt oder entfernt werden soll.

Mit Linux-Kernel 6.14 gilt: Die CXL-Spezifikation erlaubt Speicherregionen ab 256 MB. Nutzbare Blockgröße und Ausrichtung hängen jedoch von der Architektur ab. Auf x86 beginnt die Standardblockgröße bei 256 MB und kann bei größeren Systemen bis zu 2 GB reichen.

Für robuste, plattformübergreifende Hotplug-Konfigurationen empfiehlt die Kernel-Dokumentation deshalb, CXL-Regionen auf 2 GB auszurichten – sowohl bei der Basisadresse als auch bei der Regionsgröße.

Eine 2-GB-Ausrichtung ist keine Pflicht für jede CXL-Installation, aber die dokumentierte Empfehlung für robuste, plattformübergreifende Hotplug-Konfigurationen.

Diese Empfehlung sollte nicht zur universellen Regel umgedeutet werden. Eine Plattform kann mit kleineren Blockgrößen korrekt arbeiten, wenn ihre Architektur und Konfiguration das zulassen. Wer jedoch Hardware verschiedener Generationen, wechselnde Bestückungen oder Hotplug-Szenarien plant, fährt mit der 2-GB-Ausrichtung in einer dokumentierten, konservativen Konfiguration.

Das bedeutet auch: Die Regionsplanung gehört in die Entwurfsphase. Sie sollte nicht erst beginnen, wenn das Betriebssystem das Gerät bereits erkannt hat. Vor allem bei mehreren CXL-Speichergeräten muss klar sein, welche Kapazität als Region bereitgestellt wird, wie diese Region dem Host zugeordnet wird und welches Verhalten bei Wartung oder Erweiterung erwartet wird.

Was bei der Einführung wirklich zählt

CXL-Projekte scheitern selten an einer einzelnen, großen Fehlentscheidung. Häufiger sind es mehrere kleine Annahmen: Die CPU unterstützt CXL, also werde es der Server schon tun. Der Speicher ist sichtbar, also werde die Anwendung davon profitieren. Ein Switch kann poolen, also könne man Speicher automatisch zwischen Hosts teilen.

Eine belastbare Einführung folgt besser einer nüchternen Reihenfolge:

1. Plattform vor Gerät prüfen. CPU-Generation, Mainboard-Revision, Riser, BIOS-Stand und die unterstützte CXL-Version müssen als Gesamtpaket betrachtet werden. Ein CXL-fähiger Prozessor allein reicht nicht.

2. Topologie dokumentieren. Welche Lanes führen zu welchem Steckplatz? Welche Geräte teilen sich Ressourcen? Wo sitzen Retimer oder Switches? Diese Fragen wirken detailverliebt, bis die erwartete Linkbreite in der realen Bestückung nicht mehr erreicht wird.

3. Speicherziel definieren. Geht es um zusätzliche Kapazität, um eine bessere Auslastung von Speichern über mehrere Systeme hinweg oder um einen Beschleuniger mit kohärentem Zugriff? Aus dieser Antwort ergibt sich die Geräteklasse.

4. NUMA-Strategie vorab wählen. Der klassische NUMA-Modus und Flat Memory Mode lösen unterschiedliche Probleme. Die Entscheidung sollte sich am Workload orientieren, nicht an der vermeintlich bequemeren Grundeinstellung.

5. Regionen bewusst planen. Für Hotplug-Konfigurationen über unterschiedliche Plattformen hinweg ist die dokumentierte 2-GB-Ausrichtung die robuste Wahl. Sie sollte als Teil des Speicherlayouts festgelegt werden, nicht als nachträglicher Reparaturversuch.

6. Firmware und Betriebssystem gemeinsam betrachten. BIOS, BMC, CXL-Geräte-Firmware und Kernel müssen zueinander passen. Updates sollten nachvollziehbar geplant und in einer Testkonfiguration geprüft werden, bevor sie in einen produktiven Bestand wandern.

7. Mit dem echten Workload testen. Datenblätter beschreiben Fähigkeiten, keine Anwendungslatenzen. Entscheidend ist, ob Datenbank, Hypervisor, Analyseplattform oder Beschleuniger tatsächlich von der zusätzlichen CXL-Ebene profitiert.

Compute Express Link verändert nicht die Grundregel, dass lokaler Speicher für kritische Zugriffe wertvoll bleibt. Der Standard schafft aber eine neue, kohärente Erweiterungsebene zwischen klassischem DRAM und entkoppelten Infrastrukturkonzepten. Wer CXL als Architekturentscheidung behandelt statt als schnelle Steckkarten-Aufrüstung, kann Speicherkapazität im Server deutlich flexibler planen – und schafft zugleich eine Grundlage für die Fabric-Topologien, die im Rechenzentrum der nächsten Generation relevant werden.