Compute Express Link: Funktionsweise und Vorteile von CXL

Wenn der Arbeitsspeicher im falschen Server hängt

Wenn wir mittelgroße IT-Abteilungen bei einer Server-Konsolidierung begleiten, taucht in den Bestandsaufnahmen regelmäßig dasselbe Bild auf: Ein nennenswerter Teil des verbauten Arbeitsspeichers bleibt ungenutzt, weil sich die produktiven Lasten auf wenige Knoten konzentrieren. Der Speicher sitzt am falschen Sockel, der Server kann ihn nicht ohne Weiteres an andere Systeme weiterreichen – er ruht, bis irgendwann jemand die Zeile in der Inventarliste streicht.

Genau an dieser Stelle setzt Compute Express Link an, ein offener Interconnect-Standard, der physisch auf PCI Express aufsetzt, aber die starre Kopplung von DRAM an einen bestimmten CPU-Sockel aufbricht. Das bedeutet für die Praxis nicht, dass vorhandene DIMMs plötzlich zu frei verschiebbaren Pool-Ressourcen werden. Gemeint ist vielmehr eine neue Speicherschicht aus dedizierten CXL-Geräten, die sich je nach Architektur gezielter zuweisen und gemeinsam nutzen lässt.

In Rechenzentren spricht man in diesem Zusammenhang von „Stranded Memory“ – also DRAM, der zwar eingebaut und bezahlt ist, aber nicht zur aktiven Last passt. In klassischen Serverarchitekturen bleibt nach Branchenschätzungen ein erheblicher Anteil des installierten Speichers ungenutzt oder kann nicht dort eingesetzt werden, wo er gerade gebraucht wird. Das ist kein theoretisches Konstrukt, sondern ein wiederkehrendes Thema in unseren Support-Tickets, sobald Kunden virtualisierte Umgebungen verdichten, Datenbank-Cluster neu schneiden oder Server für stark schwankende Lasten auslegen.

CXL schafft dafür keinen magischen Recycling-Kanal für beliebige Altkomponenten. Es schafft eine standardisierte Verbindung, über die Speichererweiterungen, Beschleuniger und Hosts enger zusammenarbeiten können. Der Unterschied ist entscheidend: Nicht der alte DDR-Speicher wandert automatisch in einen Pool, sondern die Infrastruktur wird von Anfang an so geplant, dass zusätzliche CXL-Speichergeräte über geeignete Hosts und Switches erreichbar sind.

Was Compute Express Link tatsächlich ist

Compute Express Link, kurz CXL, ist ein offener Industriestandard, der CPUs, Beschleuniger wie GPUs und FPGAs sowie Speichererweiterungen kohärent miteinander verbindet. Das im März 2019 unter anderem von Intel, Google und weiteren Unternehmen gegründete Konsortium wollte eine Lücke schließen, die PCIe allein nicht füllen konnte: die kohärente, latenzarme Anbindung von Geräten und externem Speicher an einen Host-Prozessor über eine Infrastruktur, die in Servern ohnehin vorhanden ist.

Dabei nutzt CXL die physische und elektrische Schicht von PCI Express, ergänzt diese aber um drei eigene Protokolle, die parallel beziehungsweise alternativ zum klassischen PCIe-Transport laufen. Das ist der entscheidende Punkt: Es handelt sich nicht um eine komplett neue Stecker- oder Kabelwelt, sondern um eine zusätzliche „Sprache“, die über die bekannte PCIe-Infrastruktur gesprochen wird.

Die Gemeinsamkeit mit PCIe endet allerdings nicht bei der Mechanik. CXL muss von Prozessor, Mainboard, Firmware, Betriebssystem und gegebenenfalls Hypervisor unterstützt werden. Ein physisch passender Slot macht einen Server deshalb noch nicht automatisch CXL-tauglich. In der Beschaffung ist die Steckkarte nur ein Teil der Gleichung; mindestens ebenso wichtig sind die Fähigkeiten der Plattform, die Firmware-Versionen und die gewünschte Speicher-Topologie.

CXL im Verhältnis zu PCIe

PCIe ist in erster Linie ein I/O-Interconnect. Darüber kommunizieren beispielsweise Netzwerkadapter, NVMe-SSDs, GPUs und RAID-Controller mit dem Host. CXL verwendet dieselbe grundlegende physische Verbindung, ergänzt sie aber um Mechanismen für Cache-Kohärenz und den Zugriff auf Gerätespeicher.

Für eine gewöhnliche PCIe-Karte genügt es, dass Host und Gerät Daten austauschen können. Bei CXL geht es zusätzlich darum, dass mehrere Komponenten ein konsistentes Bild von Speicherinhalten behalten. Das ist besonders relevant, wenn ein Beschleuniger mit dem Arbeitsspeicher des Hosts arbeitet oder wenn der Prozessor auf Speicher zugreift, der nicht direkt auf dem Mainboard, sondern in einem CXL-Gerät sitzt.

Wie CXL unter der PCIe-Hülle arbeitet

Wer Compute Express Link verstehen will, muss sich zunächst die drei Subprotokolle anschauen. Sie sind das eigentliche Herzstück des Standards und erklären, warum eine CXL-Karte mehr kann als eine gewöhnliche PCIe-Karte im selben Slot.

CXL.io – der bekannte I/O-Kanal

CXL.io entspricht im Wesentlichen dem klassischen PCIe-Protokoll für I/O und Konfiguration. Es übernimmt das Auflisten der Geräte, das Initialisieren, das Interrupt-Handling und die klassische DMA-Kommunikation. In der Praxis merkt der Administrator davon zunächst wenig – die Anmeldung eines CXL-Geräts im Betriebssystem ähnelt der einer normalen Netzwerk- oder Storage-Karte, nur dass später zusätzliche Funktionen zur Verfügung stehen.

CXL.io bleibt auch dann relevant, wenn ein Gerät zusätzlich CXL.cache oder CXL.mem verwendet. Über diesen Teil der Verbindung werden grundlegende Verwaltungs- und Konfigurationsaufgaben abgewickelt. Ohne eine funktionierende CXL.io-Seite kommt also auch die eigentliche Speicherfunktion nicht zum Einsatz.

CXL.cache – kohärenter Zugriff von außen

CXL.cache erlaubt es einem Gerät, kohärent auf den Host-Speicher zuzugreifen. Das bedeutet: Wenn ein Beschleuniger über CXL.cache Daten aus dem DRAM der CPU anfordert, kann er mit einem konsistenten Speicherabbild arbeiten. Die CPU und das Gerät müssen nicht unabhängig voneinander mit potenziell veralteten Kopien hantieren.

Für beschleunigte Workloads ist das ein erheblicher Vorteil, weil sich die Komplexität der Speichersynchronisation aus den Anwendungsprogrammen und aus einem Teil der Treiberlogik herausverlagert. Das macht CXL.cache interessant für bestimmte GPU-, FPGA- und DPU-Szenarien. Es bedeutet aber nicht, dass jede Anwendung automatisch schneller wird. Die Vorteile hängen weiterhin von Zugriffsmustern, Latenz, Bandbreite und der konkreten Implementierung des Beschleunigers ab.

CXL.mem – der Host sieht den Gerätespeicher

CXL.mem dreht die Richtung um: Der Host-Prozessor kann mit normalen Load-/Store-Operationen auf Speicher zugreifen, der physisch im CXL-Gerät sitzt. Für die Software erscheint dieser Speicher als zusätzliche adressierbare Kapazität, auch wenn er nicht in Form eines klassischen DIMM-Moduls direkt am Speichercontroller des Prozessors hängt.

Das ist die Grundlage für transparente Speichererweiterungen. Ein CXL-Gerät vom Typ 3 kann beispielsweise zusätzlichen DRAM bereitstellen, der vom Host in die Speicherverwaltung und in die NUMA-Topologie eingebunden wird. Je nach Plattform lässt sich dieser Speicher unterschiedlich priorisieren oder bestimmten Anwendungen zuordnen. In der Regel bleibt der lokal angebundene Arbeitsspeicher die bevorzugte Ebene für besonders latenzkritische Zugriffe; CXL-Speicher ergänzt die Kapazität dort, wo mehr Raum wichtiger ist als die kürzestmögliche Zugriffszeit.

CXL.mem ist außerdem ein Baustein für Memory Pooling. Für einen echten gemeinsam nutzbaren Pool reicht ein einzelnes CXL-Gerät im Server jedoch nicht aus. Dafür braucht es eine geeignete Fabric-Architektur mit CXL-Switches, passenden Speichergeräten und Software, die die Ressourcen verwaltet.

Compute Express Link ersetzt keinen lokalen DDR5-Steckplatz – aber es verschiebt die Grenze, ab der zusätzliche Kapazität nicht mehr zwingend über einen neuen CPU-Sockel bereitgestellt werden muss.

Die drei Gerätetypen und ihre Rollen

CXL klassifiziert kompatible Hardware in drei Gerätetypen, die sich am unterstützten Protokollbündel und am Vorhandensein eigenen Speichers unterscheiden. Die folgende Übersicht zeigt, welcher Typ für welches Szenario gedacht ist:

Das bedeutet für die Praxis: Wer im Support eine CXL-Karte in einen Server schraubt, sollte zuerst prüfen, welcher Gerätetyp dahintersteckt. Eine Typ-3-Karte mit DRAM lässt sich vom Betriebssystem als zusätzlicher NUMA-Knoten einbinden. Ein Typ-2-Gerät verfügt dagegen über eigene Rechen- oder Beschleunigungslogik und nutzt CXL.cache und CXL.mem gemeinsam. Eine Typ-1-SmartNIC bleibt ein I/O- und Beschleunigungsgerät ohne eigenen CXL-Speicher; ihre Rolle liegt in der kohärenten Verbindung zum Host und in der Entlastung bestimmter Aufgaben.

Die Typen sind keine Leistungsstufen. Ein Typ-3-Gerät ist nicht automatisch „besser“ als ein Typ-2-Gerät, sondern für eine andere Aufgabe gedacht. Wer zusätzliche Speicherkapazität für Datenbanken oder Virtualisierung sucht, sollte nicht von der Rechenleistung einer Karte ausgehen, sondern von der gewünschten Speicherfunktion und der Einbindung in die Plattform.

Stranded Memory und Memory Pooling in der Praxis

Die wirtschaftlich spannendste Eigenschaft von Compute Express Link ist die Möglichkeit, dedizierten zusätzlichen Arbeitsspeicher mehreren Servern zugänglich zu machen – das sogenannte Memory Pooling. Eingeführt wurde diese Fähigkeit mit CXL 2.0, das neben den Endgeräten auch CXL-Switches spezifiziert. Erst durch diese Switches wird der Speicher in einer geeigneten Architektur wirklich mehreren Hosts zugänglich. Die Speichergeräte hängen dann nicht mehr ausschließlich an einem einzelnen Server, sondern können über die CXL-Fabric verwaltet und je nach Bedarf zugewiesen werden.

Dabei ist die Abgrenzung zur klassischen Serveraufrüstung wichtig: Herkömmliche DIMMs aus ausgemusterten oder älteren Servern werden nicht ohne Weiteres zu CXL-Pool-Speicher. Sie besitzen weder die erforderliche CXL-Schnittstelle noch die Logik eines CXL-Speichergeräts. Für einen Pool braucht es dafür entwickelte CXL-Memory-Expander beziehungsweise Typ-3-Geräte, die ihren Speicher über CXL.mem bereitstellen. Ein CXL-Switch stellt anschließend die Verbindung zu mehreren Hosts her. Erst das Zusammenspiel aus Speichergerät, Switch, CXL-fähigem Host und Verwaltungssoftware ergibt eine nutzbare Pooling-Architektur.

In der Support-Praxis sehen wir drei typische Szenarien, in denen Memory Pooling sinnvoll sein kann:

1. Datenbank-Konsolidierung: Mehrere kleinere Datenbankserver werden auf zwei oder drei größere Knoten verdichtet. Der zusätzliche Speicher kommt dabei nicht aus den ausgebauten DIMMs der Altgeräte, sondern aus dedizierten CXL-Typ-3-Geräten. Über CXL-Switches kann die Speicherkapazität abhängig von der Last einem oder mehreren Hosts zur Verfügung gestellt werden. Das erleichtert die Dimensionierung, ersetzt aber nicht die Analyse von Datenbank-Cache, NUMA-Verhalten und Failover-Anforderungen.

2. Burst-Analytics in wechselnden Zeitfenstern: Tagsüber läuft ein ERP-Cluster mit stabilem Speicherbedarf, nachts startet ein Batch-Job, der kurzfristig deutlich mehr RAM benötigt. Ein Pool aus CXL-Speichergeräten kann diese zusätzliche Kapazität bereitstellen, ohne dass jeder ERP-Knoten dauerhaft auf den Spitzenbedarf ausgelegt werden muss. Entscheidend ist, dass die Zuweisung und Rückgabe der Ressourcen durch die Plattform sauber unterstützt wird.

3. KI-Inferenz-Farmen: GPUs in einer Inferenzfarm benötigen je nach Modell und Auslastung unterschiedlich viel Host-Speicher. Statt jeden Server auf das Maximum auszulegen, kann ein Verbund aus Typ-3-Speichergeräten und CXL-Switches zusätzliche Kapazität gezielt den Hosts zur Verfügung stellen, die sie tatsächlich benötigen. Eine Typ-2-CXL-Karte kann in diesem Szenario weiterhin als Beschleuniger eingesetzt werden; sie ist aber nicht der Mechanismus, der das serverübergreifende Memory Pooling bereitstellt.

Der Nutzen liegt vor allem in der Entkopplung von Kapazität und Serverknoten. Das verbessert die Auslastung, bringt aber auch neue Abhängigkeiten. Fällt ein Switch aus, kann das mehrere Hosts und Speichergeräte betreffen. Deshalb gehören Redundanz, Fehlerdomänen und die Frage nach dem Verhalten bei einem Link- oder Geräteausfall bereits in die Architekturplanung – nicht erst in die Abnahme.

CXL löst ein Speicherproblem, das nicht auf dem Datenblatt steht: die unfreiwillige Verschwendung von DRAM, der im falschen Sockel montiert wurde. Für den Pool braucht es allerdings eigens dafür ausgelegte CXL-Speichergeräte.

Lokale Erweiterung oder Pool?

Nicht jedes CXL-Projekt muss gleich als große Fabric geplant werden. In vielen Fällen ist eine lokale Typ-3-Speichererweiterung der sinnvollere Einstieg. Dabei steckt das Gerät direkt im Host und stellt zusätzliche Kapazität für genau diesen Server bereit. Das ist technisch und organisatorisch weniger komplex als ein Pool mit Switches, kann aber bereits bei speicherintensiven Datenbanken, In-Memory-Anwendungen oder Virtualisierung helfen.

Ein gepooltes Szenario lohnt sich eher dann, wenn mehrere Hosts stark unterschiedliche oder zeitlich wechselnde Speicherprofile haben. Die erwartete Auslastung muss hoch genug sein, damit Switches, Geräte, Management und Redundanz nicht nur zusätzliche Kosten erzeugen. Außerdem sollte die Anwendung mit einer nicht lokal angebundenen Speicherebene umgehen können. Die Frage lautet also nicht nur, ob CXL mehr Speicher bereitstellt, sondern ob die jeweilige Last von der zusätzlichen Kapazität trotz höherer Latenz profitiert.

Bandbreite und Formfaktoren im Vergleich

Compute Express Link ist eng an die jeweilige Generation von PCI Express gekoppelt, weil es deren physische Schicht wiederverwendet. Welche Bandbreite ein CXL-Gerät tatsächlich liefert, hängt also direkt davon ab, welche PCIe-Version und welcher Link im Server-Mainboard zur Verfügung stehen:

Die Zuordnung sollte zeitlich und technisch nicht als starre Aussage über jede verfügbare Hardware verstanden werden. PCIe 6.0 und 6.1 gehören bei CXL 3.0 und 3.1 bereits zur entsprechenden Generation der physischen Schnittstelle. PCIe 7.0 ist der PHY-Bezug für CXL 4.0. Welche Kombination in einem konkreten Server, Switch oder Speichergerät tatsächlich implementiert ist, hängt vom Produkt und vom Ausbaustand der Plattform ab.

Für die tägliche Arbeit heißt das: Wer eine CXL-Speichererweiterung vom Typ 3 kauft, erhält je nach Generation und Linkbreite eine deutlich höhere Bandbreite als bei älteren I/O-Verbindungen. Das macht CXL attraktiv für Kapazitätserweiterungen. Trotzdem ist ein CXL-Link nicht automatisch gleichwertig mit der direkten Anbindung lokaler DDR-Speicherkanäle. Neben der nominellen Bandbreite spielen Protokolloverhead, Controller, Switches, Entfernung, Zugriffsrichtung und die NUMA-Topologie eine Rolle.

Genau aus diesem Grund sehen wir CXL derzeit vor allem als Kapazitätsschicht und nicht als Ersatz für schnellen lokalen Speicher. Die lokalen DIMMs bleiben die erste Wahl für Daten, auf die besonders häufig und latenzkritisch zugegriffen wird. CXL kann dort ansetzen, wo zusätzlicher Speicherplatz wichtiger ist als die kürzestmögliche Latenz. Die genauen Latenzzuschläge gegenüber direkt angebundenen DDR5-DIMMs variieren je nach Host-Architektur und Controller und sind nicht pauschal bezifferbar.

Auch bei den Formfaktoren hat sich einiges getan. Neben klassischen PCIe-Add-in-Karten, kurz AIC, sind vor allem die EDSFF-Formate E1.S und E3.S relevant. Sie sind kompakt, lassen sich dichter im Rack verbauen und können je nach Plattform hot-swap-fähig ausgelegt werden – Eigenschaften, die für Speichergeräte in dicht bestückten Servern sehr willkommen sind.

Bei EDSFF darf man die Mechanik trotzdem nicht isoliert betrachten. Die Einbausituation beeinflusst Luftstrom, Servicezugang, Stromversorgung und die mögliche Bestückungsdichte. Ein Speichergerät, das auf dem Papier in das Chassis passt, ist nicht automatisch für jede thermische Konfiguration geeignet. Gerade bei mehreren Geräten hinter einem CXL-Switch muss die Kühlung mit der geplanten Last dauerhaft funktionieren.

Was beim ersten CXL-Ausbau in der Praxis zählt

Bevor eine CXL-Erweiterung in Produktion geht, lohnt sich ein kurzer Realitätscheck. Einige Punkte entscheiden immer wieder darüber, ob aus einer technisch interessanten Karte tatsächlich eine brauchbare Infrastruktur wird:

• Host-Prozessor und Plattform müssen CXL unterstützen. Eine CXL-Karte in einem älteren Server ohne CXL-fähige CPU verhält sich nicht automatisch wie ein vollwertiges CXL-Gerät. Je nach Plattform bleibt es bei einer PCIe-Funktion, während der kohärente Modus nicht zur Verfügung steht. Vor jeder Bestellung sollten daher Mainboard-Datenblatt, CPU-Liste, BIOS- beziehungsweise UEFI-Unterstützung und die Angaben des Serverherstellers zusammen betrachtet werden.
• Die CXL-Version muss zusammenpassen. CXL-Gerät, Host, Switch und Firmware müssen nicht nur elektrisch miteinander funktionieren, sondern auch die benötigten Funktionen derselben beziehungsweise kompatibler Generationen unterstützen. Besonders bei Pooling, Switching und der Geräteverwaltung reicht ein allgemeiner Hinweis auf „CXL-Unterstützung“ nicht aus.
• Firmware aktuell halten. Die CXL-Initialisierung wird über die Firmware ausgehandelt. Vorkonfigurierte Server mit veralteter Firmware listen CXL-Geräte mitunter gar nicht oder nur eingeschränkt auf. Das betrifft nicht nur das BIOS oder UEFI, sondern je nach Plattform auch Management-Controller, Switch-Firmware und Treiber.
• NUMA-Topologie bewusst planen. Eine lokale CXL-Speichererweiterung wird vom Betriebssystem als eigene Speicherebene oder als eigener NUMA-Knoten angesprochen. Bei datenbankintensiven Workloads sollten die Platzierung der Datenbankpuffer, die Thread-Affinität und die Speicher-Policies entsprechend justiert werden. Ein System, das den zusätzlichen Speicher zwar erkennt, ihn aber für jede Anwendung gleich behandelt, nutzt die Hardware nicht unbedingt optimal.
• Pooling braucht Ressourcenverwaltung. In einer Switch-Architektur muss festgelegt sein, welcher Host auf welches Typ-3-Gerät zugreifen darf und wie die Kapazität verteilt wird. Dazu gehören Zuweisungsregeln, Isolation, Monitoring und das Verhalten bei Überbelegung. Ohne diese Ebene wird aus dem Pool kein flexibler Speicher, sondern eine zusätzliche Fehlerquelle.
• Redundanz und Fehlerdomänen einplanen. Bei mehreren Hosts darf ein einzelner Switch oder ein einzelner Speicherpfad nicht unbemerkt zum zentralen Ausfallpunkt werden. Die gewünschte Verfügbarkeit entscheidet darüber, wie viele Links, Switches und Speichergeräte benötigt werden. Das kann die Komplexität deutlich erhöhen, ist für produktive Umgebungen aber nicht optional.
• Thermik und Stromversorgung nicht unterschätzen. EDSFF-Geräte im dichten Verbund entwickeln mehr Wärme als eine einzelne PCIe-Karte im traditionellen Slot. Im Rack ist eine funktionierende Luftzirkulation Pflicht. Auch die Leistungsbudgets des Servers und des Chassis müssen zur geplanten Bestückung passen.
• Hypervisor-Kompatibilität prüfen. Nicht alle Virtualisierungsumgebungen unterstützen CXL-Typ-3-Geräte als Host-Speichererweiterung in allen Versionen. Vor dem Rollout lohnt ein Blick in die Release-Notes der eingesetzten Plattform. Zusätzlich sollte geprüft werden, ob Migration, Neustart, Live-Betrieb und Fehlerbehandlung mit der gewünschten Speicherklasse funktionieren.
• Anwendungen nach Zugriffsmuster auswählen. CXL bringt nicht jeder Anwendung denselben Vorteil. Große, kapazitätsintensive Workloads mit tolerierbaren Latenzen können profitieren. Kleine, stark latenzsensitive Datenstrukturen bleiben oft besser im lokalen Speicher. Ein Kapazitätsgewinn allein ist noch kein ausreichender Grund, die Speicherhierarchie einer Anwendung zu verändern.
• Monitoring von Anfang an einrichten. Neben der belegten Kapazität sollten Bandbreite, Latenz, Link-Zustand, Fehlerzähler, Temperatur und die Verteilung über NUMA-Knoten sichtbar sein. Nur dann lässt sich nach dem Rollout unterscheiden, ob eine Anwendung tatsächlich von CXL profitiert oder den zusätzlichen Speicher lediglich wegen ungünstiger Affinitätsregeln verwendet.

Wer diese Punkte vorab adressiert, erlebt beim Einsetzen der ersten CXL-Geräte keine bösen Überraschungen. Der physische Vorgang selbst unterscheidet sich kaum von einer klassischen PCIe-Installation. Der Großteil der Arbeit liegt in der Plattformprüfung, der Firmware- und NUMA-Planung sowie – bei gepoolten Architekturen – in der Auslegung der Switch- und Management-Ebene.

Ein sinnvoller Einführungsweg

In der Praxis ist ein gestufter Ausbau meist belastbarer als der direkte Sprung in eine große Speicherfabric. Ein erster Schritt kann darin bestehen, einen einzelnen CXL-fähigen Host mit einem Typ-3-Gerät zu betreiben. Dabei lassen sich Enumeration, Firmware, Betriebssystemintegration, NUMA-Verhalten und das Monitoring prüfen, ohne sofort mehrere Server voneinander abhängig zu machen.

Im zweiten Schritt kann die Kapazität auf mehrere Hosts verteilt werden. Erst wenn klar ist, dass die Anwendungen, der Hypervisor und die Betriebsprozesse mit der zusätzlichen Speicherebene umgehen können, lohnt sich der Ausbau über CXL-Switches. Dann kommen Themen wie Redundanz, Ressourcenreservierung und automatisierte Zuweisung hinzu.

Diese Reihenfolge klingt weniger spektakulär als ein vollständiger Pool ab dem ersten Tag. Sie entspricht aber dem Umgang mit jeder neuen Infrastrukturkomponente: Erst muss die lokale Funktion stabil sein, dann wird die Architektur skaliert. CXL ist dabei keine Ausnahme.

Fazit

Compute Express Link ist aus unserer Sicht kein Modethema, sondern eine konsequente Antwort auf eine seit Jahren bekannte Speicherlücke: DRAM wird in vielen Servern nicht deshalb knapp, weil im gesamten Rechenzentrum zu wenig davon vorhanden ist, sondern weil die Kapazität an die falschen Knoten gebunden ist. CXL schafft eine standardisierte Möglichkeit, zusätzliche Speicherkapazität näher an die Workloads zu bringen und sie in geeigneten Architekturen flexibler zu verteilen.

Die Kombination aus PCIe-5.0-, PCIe-6.0-/6.1- und – je nach CXL-Generation – PCIe-7.0-PHY, klar definierten Gerätetypen sowie den mit CXL 2.0 eingeführten Switch- und Pooling-Funktionen macht CXL zu einer Technologie, die wir in Architekturdiskussionen großer Speicherumgebungen mit auf den Tisch legen. Entscheidend ist dabei die saubere Zuordnung: Typ 2 steht für Beschleuniger mit eigenem Speicher und kohärenter Verbindung, Typ 3 für Speichererweiterungen. Das eigentliche serverübergreifende Pooling entsteht durch Typ-3-Speichergeräte, CXL-Switches und die passende Verwaltungssoftware – nicht durch eine beliebige CXL-Karte.

Was CXL ausdrücklich nicht ist: ein Ersatz für lokale DDR5-DIMMs auf dem Mainboard. Wer das verspricht, redet die Technologie schöner, als sie heute ist. Lokaler Speicher bleibt für besonders latenzkritische Zugriffe wichtig. Als Kapazitätsschicht, als Brücke zu Memory Pooling und als kohärente Verbindung zu Beschleunigern liefert CXL jedoch einen konkreten Mehrwert.

Voraussetzung ist, dass die Umgebung zur Technologie passt. Ein CXL-Projekt beginnt deshalb nicht mit dem Kauf einer Karte, sondern mit der Frage, welche Speicherprobleme tatsächlich gelöst werden sollen: Fehlt einem einzelnen Host Kapazität? Schwanken die Anforderungen mehrerer Server stark? Oder soll eine Fabric aus standardisierten Speichergeräten langfristig eine flexiblere Infrastruktur ermöglichen? Wer diese Fragen beantwortet und NUMA, Firmware, Thermik, Redundanz sowie Software-Unterstützung einbezieht, bekommt mit CXL keine Marketingfolie, sondern eine belastbare zusätzliche Speicherebene.