Compute Express Link: Was ist CXL und wie funktioniert es?

Compute Express Link: Was ist CXL und wie funktioniert es?

Wenn ein Kunde anruft, dessen Datenbankserver in der nächtlichen Auswertung an die 95-Prozent-Marke des Arbeitsspeichers stößt, und gleichzeitig fragt, ob sich der vorhandene DDR5-Steckplatz nicht doch noch erweitern lässt, dann landen wir seit ein paar Jahren bei einer Antwort, die vorher so nicht möglich war: Ja, mit Compute Express Link. Der Standard verschiebt die Grenzen dessen, was ein Server-Mainboard leisten kann, ohne dass das gesamte System ausgetauscht werden muss. Genau das macht CXL für mich als Technikerin am Schreibtisch des Kunden so relevant, denn die Technologie löst ein sehr konkretes Alltagsproblem, von dem viele Administratorinnen und Administratoren erst erfahren, wenn die Speicherlimits erreicht sind.

Compute Express Link, kurz CXL, ist ein offener Industriestandard für eine schnelle, latenzarme und cache-kohärente Verbindung zwischen Host-Prozessoren einerseits und Beschleunigern oder Speichererweiterungen andererseits. Wer den Begriff zum ersten Mal hört, denkt häufig an eine weitere Variante von PCI Express. Das ist nicht falsch, greift aber zu kurz. CXL nutzt zwar die physische und elektrische Schicht von PCIe, führt jedoch ein eigenes Protokoll-Set ein, das auf dieser Leitung eine ganz eigene Sprache spricht. Genau diese Sprache ermöglicht es, dass Prozessor und angeschlossenes Gerät dieselbe Sicht auf den Speicher teilen — ein Punkt, an dem klassische PCIe-Verbindungen bisher scheitern.

Aufbau und Protokolle: drei Wege über einen Link

Die Architektur von CXL setzt auf der PCIe-Physical-Layer auf und ergänzt sie um drei spezifische Protokolle. Das bedeutet für die Praxis: Die Steckkarte sitzt weiterhin im bekannten PCIe-Slot, kommuniziert aber nicht mehr nur über das Standard-PCIe-Protokoll, sondern kann je nach Bedarf eines der drei CXL-Protokolle aktivieren.

CXL ersetzt PCIe nicht — es erweitert die Sprache, die PCIe ohnehin schon spricht.

CXL.io ist dabei der vertraute Anteil: Es entspricht weitgehend dem klassischen PCIe-Protokoll und übernimmt Aufgaben wie Geräteerkennung, Konfiguration, Interrupt-Handling und den Standard-I/O-Datenverkehr. Geräte, die nur diese Sprache sprechen, verhalten sich aus Sicht des Host-Systems wie gewohnt. CXL.cache dreht die Datenrichtung um und erlaubt es dem angeschlossenen Gerät, direkt auf den Arbeitsspeicher der CPU zuzugreifen, und zwar cache-kohärent, also ohne veraltete Kopien. Eine GPU kann auf diese Weise ohne Umwege über Treiberzwischenspeicher auf aktuelle Daten im Host-RAM zugreifen. CXL.mem wiederum öffnet die andere Tür: Hier kann die CPU den Speicher des angeschlossenen Geräts nutzen, als wäre es eigener Arbeitsspeicher. Genau dieses Protokoll ist es, das in unserem Eingangsbeispiel mit dem ausgelasteten Datenbankserver den entscheidenden Unterschied macht, weil es eine Erweiterung über die DIMM-Slots hinaus erlaubt.

Die Kombination ist dabei nicht starr. CXL kann flexibel pro Link entscheiden, welche der drei Protokolle aktiv sind. Eine häufige Konfiguration in aktuellen Server-CPUs ist CXL.io plus CXL.mem, weil viele Speichererweiterungen klassische I/O-Funktionen mitbringen, aber keine Beschleuniger-Aufgaben übernehmen. Eine GPU oder ein FPGA nutzt dagegen alle drei Protokolle parallel.

Drei Geräteklassen: Typ 1, Typ 2 und Typ 3

Die CXL-Spezifikation definiert drei Geräteklassen, die sich in der Frage unterscheiden, ob und wie viel eigener Speicher das Gerät mitbringt. Für die tägliche Arbeit im Support ist diese Klassifizierung extrem hilfreich, weil sie direkt verrät, welches Gerät sich für welchen Einsatzzweck eignet.

Diese Aufteilung ist im Datenblatt eines jeden CXL-Geräts angegeben und entscheidet darüber, welche Protokolle tatsächlich aktiv werden. Eine reine Speichererweiterung vom Typ 3 nutzt typischerweise CXL.io für die Konfiguration und CXL.mem für den eigentlichen Datenzugriff; CXL.cache bleibt außen vor, weil das Gerät keinen eigenen Speicher hat, den es aktiv in den Host-Cache zurückspielen könnte. Bei einer High-End-GPU vom Typ 2 sind dagegen alle drei Protokolle im Spiel, weil sowohl der Host die GPU-Daten lesen können soll als auch die GPU auf den Host-Speicher zugreift.

Versionsentwicklung: ein Jahrzehnt in rasanten Sprüngen

Die CXL-Spezifikation ist kein statisches Dokument, sondern wird seit der ersten Veröffentlichung im Juni 2019 in schnellen Zügen weiterentwickelt. Wer heute eine Investitionsentscheidung trifft, sollte die Versionsunterschiede kennen, weil sich Bandbreite, Funktionen und damit auch die Anwendungsfelder mit jeder Generation verschoben haben.

Wer die Tabelle aufmerksam liest, sieht drei große Sprünge: den Sprung zu PCIe 6.0 mit CXL 3.0, der die Bandbreite pro Link verdoppelt und gleichzeitig die Fabric-Funktionen einführt; den Sprung zu CXL 3.1, der die Sicherheit auf das Niveau von Confidential Computing hebt; und den Sprung zu PCIe 7.0 mit CXL 4.0, der noch einmal eine Verdopplung der Datenrate pro Lane mitbringt. Zwischen diesen Sprüngen liegen oft Detailversionen wie 3.2, die bestehende Funktionen verfeinern, ohne das Rad neu zu erfinden.

Für die tägliche Praxis im Serverraum bedeutet das: Wer aktuell ein CXL-fähiges System mit PCIe-5.0-Basis anschafft, bekommt eine solide Plattform für Memory Pooling und kann viele gängige Erweiterungskarten nutzen. Wer neu plant und einige Jahre vorausdenkt, sollte die Augen nach Mainboards mit PCIe-6.0-CXL-Unterstützung offen halten, schon wegen der Fabric-Funktionen, die für skalierbare Rechenzentren immer wichtiger werden. Die Spezifikation für CXL 4.0 ist seit November 2025 veröffentlicht; Produkte werden allerdings erst gegen Ende 2026 beziehungsweise 2027 in nennenswertem Umfang erwartet, sodass sich eine Investition in diese Generation aktuell nur dann rechnet, wenn konkrete Bandbreitenanforderungen über die Grenzen von PCIe 6.0 hinausgehen.

Memory Pooling und Fabric: geteilte Ressourcen, weniger Verschwendung

Die vielleicht wichtigste praktische Eigenschaft, die CXL ab der Version 2.0 mitbringt, ist das sogenannte Memory Pooling. Dahinter steckt eine Idee, die im klassischen Server-Design nicht funktioniert: Arbeitsspeicher, der in einem Server aktuell nicht ausgelastet ist, soll dynamisch einem anderen Server zur Verfügung gestellt werden können, der gerade unter Last steht. In der Praxis begegnet uns das in Form von Kunden, deren Datenbank-VMs nachts den Speicher voll auslasten, während andere VMs auf demselben Cluster tagsüber brachliegen. Früher bedeutete das: mehr RAM kaufen, auch wenn die Auslastung im Schnitt bei knapp über der Hälfte liegt. Mit Memory Pooling lässt sich diese Verschwendung kontrolliert abbauen.

Das funktioniert über CXL-Switches, die als vermittelnde Komponente zwischen mehrere Hosts und mehrere Speicherpools geschaltet werden. Jeder Host sieht weiterhin seine eigene Speicherhierarchie, kann aber bei Bedarf transparent auf entfernte DIMM-Äquivalente zugreifen. Das bedeutet für die Praxis eine deutlich bessere Auslastung der vorhandenen RAM-Kapazität und damit niedrigere Gesamtbetriebskosten, ein Argument, das in Gesprächen mit Geschäftsführungen meist schneller verfängt als reine Technikfolien.

Memory Pooling ist das CXL-Feature, das die Auslastung von Server-Arbeitsspeicher vom Hoffen auf den richtigen Moment zum steuerbaren Prozess macht.

Mit CXL 3.0 und 3.1 wurden diese Fabric-Funktionen erheblich erweitert. Das Port-Based Routing erlaubt es, bis zu 4.096 Knoten in einer einzigen CXL-Fabric zu adressieren, eine Größenordnung, die weit über das hinausgeht, was klassische PCIe-Topologien leisten können. Hinzu kommen Multi-Level-Switching, also mehrere hintereinandergeschaltete Switch-Hops, sowie eine direkte Peer-to-Peer-Kommunikation zwischen Geräten, ohne dass der Host als Zwischenstation dienen muss. Eine GPU kann auf diese Weise direkt mit einer SmartNIC Daten austauschen, was bei datenintensiven KI-Workloads einen erheblichen Latenzvorteil bringt und einen Teil der Engpässe auflöst, die heute noch über das Host-Speichersubsystem laufen.

Sicherheit: Confidential Computing auf CXL-Basis

Was passiert, wenn sensible Daten nicht mehr im eigenen Gehäuse bleiben, sondern über einen CXL-Switch hinweg in Speicherpools wandern? Genau diese Frage hat die Branche lange beschäftigt, und die Antwort steht in Form des Trusted Execution Environment Security Protocols (TSP) seit CXL 3.1 zur Verfügung.

TSP nutzt virtualisierungsbasierte TEEs, also isolierte, hardwaregestützte Vertrauensbereiche, um die Integrität und Vertraulichkeit von Daten abzusichern, die über CXL.cache und CXL.mem übertragen werden. Das bedeutet konkret: Auch wenn ein Speichermodul physisch in einem anderen Server steckt und über einen gemeinsamen Switch angesprochen wird, bleiben die Daten darin durch kryptografische Verfahren gegen unbefugten Zugriff geschützt. Für regulierte Branchen, etwa Finanzdienstleister, Gesundheitswesen oder öffentliche Verwaltung, ist genau diese Eigenschaft der Punkt, der den Schritt vom Pilotprojekt zum Produktiveinsatz ermöglicht.

Diese Schutzmechanismen laufen auf der CXL-Verbindung selbst und nicht erst in der Anwendungsschicht. Das ist ein wichtiger Unterschied, weil damit der Schutz auch dann greift, wenn das Betriebssystem oder der Hypervisor kompromittiert wäre. Der Trend, der sich hier abzeichnet, ist klar: Mit jeder neuen CXL-Generation werden die Sicherheitsfunktionen erweitert, nicht abgespeckt, ein Zeichen dafür, dass die Spezifikationsverantwortlichen die Bedrohungslage sehr ernst nehmen.

Was das für die Praxis bedeutet

Für IT-Verantwortliche und Techniker stellt sich am Ende nicht die Frage, ob CXL relevant wird, sondern wann und in welcher Form. Die Technologie hat sich vom Konzept zur auslieferungsfähigen Spezifikation entwickelt, und die ersten Server-Plattformen mit nativer CXL-Unterstützung sind im produktiven Einsatz. Wer heute einen neuen Server anschafft, sollte darauf achten, dass Mainboard und CPU-Chipsatz CXL-fähig sind, auch wenn der konkrete Anwendungsfall aktuell noch keinen Beschleuniger oder externes Memory Pooling benötigt. Eine Nachrüstung über einen separaten CXL-Steckplatz ist später oft günstiger als ein Komplettumbau.

Wer mit KI-Workloads plant, profitiert besonders von der CXL.cache-Kohärenz, weil GPUs und FPGAs ohne Datenduplikate auf den Host-Speicher zugreifen können. Wer Speicherengpässe in klassischen Datenbank- oder Virtualisierungsumgebungen hat, findet in Typ-3-Modulen eine Antwort, die über das hinausgeht, was DIMM-Slots hergeben. Und wer ein Rechenzentrum mit schwankender Auslastung betreibt, sollte die Fabric-Funktionen ab CXL 3.0 als Werkzeug begreifen, das Speicher dort einsetzt, wo er gerade gebraucht wird, statt ihn in stillen Servern verfallen zu lassen.

Am Ende bleibt es das, was jede gute Technologie ausmacht: Sie löst ein konkretes Problem, das Administratoren jeden Tag haben, und sie schafft Raum für Konfigurationen, die vorher schlicht nicht möglich waren. Compute Express Link gehört deshalb in jeden Werkzeugkasten, der mit moderner Server-Architektur, GPU-Beschleunigung oder skaliertem Memory-Management zu tun hat — nicht als Bonus, sondern als strategischer Faktor, der bei der nächsten Hardware-Generation ohnehin mitgedacht werden muss.