CXL 4.0 im Jahr 2026: Wie Memory Pooling und 128 GT/s KI- und Cloud-Server verändern
Arbeitsspeicher ist zu einem der wichtigsten Engpässe moderner KI- und Cloud-Infrastrukturen geworden. Prozessoren und Beschleuniger werden immer leistungsfähiger, doch es wird zunehmend schwieriger und kostspieliger, ausreichend Speicher bereitzustellen, um sie effizient auszulasten. Compute Express Link, besser bekannt als CXL, löst dieses Problem mit einer kohärenten Verbindung zwischen Prozessoren, Beschleunigern und externem Speicher. CXL 4.0, das vom CXL Consortium im November 2025 veröffentlicht wurde, erhöht die maximale Datenrate von 64 GT/s auf 128 GT/s und behält gleichzeitig die Funktionen für Memory Pooling und Memory Sharing bei, die bereits in früheren CXL-Generationen entwickelt wurden. Im Jahr 2026 ist diese Kombination vor allem für KI-Inferenz, große Cloud-Server und Rack-Scale-Computing relevant. Sie macht weder herkömmlichen DDR-Speicher noch High-Bandwidth Memory überflüssig und verwandelt auch nicht jedes Server-Rack sofort in ein einziges riesiges Speichersystem. CXL eröffnet jedoch einen praktischen Weg, Speicher als flexiblere Ressource zu behandeln und nicht mehr ausschließlich als fest zugeordnete Kapazität, die dauerhaft an einen bestimmten Prozessor gebunden ist.
Warum CXL 4.0 im Jahr 2026 für KI- und Cloud-Server wichtig ist
CXL wurde entwickelt, weil die traditionelle Beziehung zwischen Prozessoren und Arbeitsspeicher für moderne Rechenzentrums-Workloads zunehmend zu unflexibel wurde. Ein klassischer Server verfügt über eine festgelegte Menge an lokalem Speicher, der über die Speicherkanäle der CPU angebunden ist. Dieses Modell funktioniert gut, wenn die Anforderungen vorhersehbar sind. Cloud- und KI-Systeme weisen jedoch häufig stark schwankende Lasten auf. Ein Server kann vorübergehend mehrere Terabyte zusätzlichen Speicher benötigen, während ein anderes System im selben Rack große Mengen ungenutzten DRAM besitzt. Wird jeder Server mit genügend lokalem Speicher für den denkbaren Spitzenbedarf ausgestattet, bleibt ein erheblicher Teil dieser kostspieligen Kapazität über längere Zeit ungenutzt. CXL verändert dieses Verhältnis, indem kompatible Speichergeräte außerhalb der üblichen DIMM-Struktur des Prozessors eingesetzt werden können und dennoch über speicherähnliche Load- und Store-Operationen erreichbar bleiben. Frühere CXL-Versionen führten Speichererweiterung, Switching, Pooling und Sharing ein. Bei CXL 4.0 liegt ein wesentlicher Schwerpunkt darauf, deutlich mehr Daten über diese Verbindungen übertragen zu können.
Die auffälligste Neuerung ist der Wechsel auf 128 GT/s und damit die Verdopplung der maximalen Datenrate gegenüber den 64 GT/s von CXL 3.x. CXL 4.0 basiert dabei auf der physischen Signalisierung von PCI Express 7.0, dessen finale Version 1.0 im Juni 2025 veröffentlicht wurde. GT/s steht für Giga-Transfers pro Sekunde und darf nicht mit Gigabyte pro Sekunde verwechselt werden. Der Wert beschreibt die Signalisierungsrate einer einzelnen Lane, während die tatsächlich nutzbare Bandbreite unter anderem von der Anzahl der Lanes, dem Protokoll-Overhead und der Gerätekonfiguration abhängt. PCI Express 7.0 kann beispielsweise über eine x16-Verbindung eine bidirektionale Bandbreite von bis zu 512 GB/s bereitstellen. CXL verwendet dieselbe schnelle physische Grundlage, ergänzt sie jedoch um Kohärenz- und Speicherfunktionen, die für die Zusammenarbeit von Prozessoren, Beschleunigern und Speichergeräten erforderlich sind. Dadurch steht wesentlich mehr Verbindungskapazität zur Verfügung, ohne dass Software angebundenen Speicher wie klassischen Massenspeicher oder eine gewöhnliche Netzwerkressource behandeln muss.
Diese höhere Datenrate ist wichtig, weil Speichererweiterung nur dann einen wirklichen Nutzen bringt, wenn die Verbindung zum Speicher schnell genug für den jeweiligen Workload ist. Lokaler DRAM bleibt die bevorzugte Wahl für besonders latenzempfindliche Daten, während HBM weiterhin unverzichtbar ist, wenn GPUs und andere Beschleuniger direkt neben ihren Recheneinheiten eine extrem hohe Bandbreite benötigen. CXL-Speicher nimmt eine andere Position in dieser Speicherhierarchie ein. Er kann wesentlich mehr Kapazität bereitstellen, als sich wirtschaftlich sinnvoll direkt neben jedem Prozessor oder Beschleuniger installieren lässt, und bietet gleichzeitig bessere Zugriffseigenschaften als das Verschieben derselben Daten auf SSD-Speicher. Für KI-Infrastrukturen entsteht dadurch eine zusätzliche nutzbare Speicherebene zwischen knappem, sehr schnellem lokalen Speicher und deutlich langsamerem Massenspeicher. Cloud-Betreiber erhalten außerdem die Möglichkeit, Speicherkapazität genauer an wechselnde Workloads anzupassen, statt jeden Server auf seinen theoretisch höchsten Bedarf auszulegen. Der Wert von CXL 4.0 liegt deshalb nicht nur in der reinen Übertragungsrate, sondern ebenso in der zusätzlichen Flexibilität.
Was 128 GT/s in der Praxis verändert
Die Verdopplung einer Verbindung von 64 GT/s auf 128 GT/s bedeutet nicht automatisch, dass eine Anwendung doppelt so schnell läuft. Viele Anwendungen werden eher durch die Prozessorleistung, den Durchsatz des Beschleunigers, das Verhalten der Software oder die Speicherlatenz als durch die CXL-Verbindung begrenzt. Die zusätzliche Bandbreite wird vor allem dann wichtig, wenn große Datenmengen gleichzeitig zwischen Prozessoren, Beschleunigern und erweitertem Speicher übertragen werden müssen. Ein Server, der große Modelle für Inferenz, Analysen oder In-Memory-Datenbanken ausführt, kann zahlreiche Prozesse besitzen, die gleichzeitig Daten lesen und schreiben. In solchen Situationen kann eine langsamere Verbindung zu einem gemeinsamen Engpass werden, selbst wenn hinter ihr ausreichend Speicherkapazität vorhanden ist. CXL 4.0 schafft für solchen Datenverkehr deutlich mehr Reserven. Das CXL Consortium behält außerdem die für die Generation mit 64 GT/s entwickelte Struktur mit fest definierten Übertragungseinheiten und Fehlerabsicherung bei. Dadurch lässt sich die höhere Datenrate einführen, ohne einfach einen proportionalen Anstieg der Protokolllatenz hinzunehmen.
CXL 4.0 führt zudem sogenannte Bundled Ports ein. Vereinfacht ausgedrückt können mehrere physische CXL-Verbindungen dort, wo Gerät und Host dies unterstützen, als eine logische Verbindung genutzt werden. Das ist hilfreich, wenn eine einzelne Verbindung nicht genügend Bandbreite für einen leistungsstarken Beschleuniger oder eine andere besonders anspruchsvolle Komponente bereitstellen kann. Statt jede Verbindung für den Rest des Systems als vollständig separaten Gerätepfad behandeln zu müssen, bieten Bundled Ports eine definierte Möglichkeit, mehrere Verbindungen zusammenzufassen. Die Spezifikation unterstützt außerdem native x2-Verbindungen. Dadurch können Entwickler eine größere Zahl an Geräten anbinden, wenn nicht jede Verbindung die maximale Bandbreite benötigt. Zusätzlich werden bis zu vier Retimer unterstützt, um größere Übertragungsdistanzen innerhalb eines Systems zu ermöglichen. Diese Änderungen sind besonders für dicht bestückte Server und Rack-Designs relevant, bei denen sich Komponenten nicht immer direkt neben dem Prozessor befinden können. Entwickler erhalten dadurch mehr Möglichkeiten, Verbindungsbreite, Geräteanzahl, Entfernung und Bandbreite aufeinander abzustimmen.
Zuverlässigkeit ist ebenso wichtig, sobald Speicher nicht mehr ausschließlich auf dem Mainboard sitzt. Ein defektes klassisches DIMM betrifft in der Regel nur einen einzelnen Server, während gepoolter oder gemeinsam genutzter Speicher mehrere Systeme oder wichtige Workloads unterstützen kann. CXL 4.0 erweitert deshalb die Funktionen für Reliability, Availability und Serviceability im Speicherbereich, damit Fehler besser erkannt und Wartungsprozesse zuverlässiger durchgeführt werden können. Ausfälle lassen sich dadurch nicht vollständig verhindern, und Betreiber benötigen weiterhin Redundanz, Überwachung und eine durchdachte Verteilung ihrer Workloads. Dennoch wird es einfacher, CXL-Speicher mit hoher Kapazität als regulären Bestandteil der Infrastruktur zu verwalten und nicht als außergewöhnliches Peripheriegerät. Auch die vollständige Abwärtskompatibilität ist in der Praxis von Bedeutung. CXL-4.0-Systeme sind so ausgelegt, dass sie dort, wo die entsprechende Unterstützung vorhanden ist, mit älteren CXL-Generationen zusammenarbeiten können. Unternehmen müssen daher nicht ihre gesamte CXL-Infrastruktur auf einmal ersetzen. Das ist im Jahr 2026 besonders relevant, weil parallel CXL-2.0- und CXL-3.x-Hardware eingesetzt wird, während gleichzeitig die Entwicklung und Validierung von CXL-4.0-Komponenten mit 128 GT/s beginnt.
Memory Pooling: Vom fest zugeordneten Serverspeicher zur gemeinsam nutzbaren Kapazität
Memory Pooling existierte bereits vor CXL 4.0. Die Funktion wurde mit CXL 2.0 eingeführt, zusammen mit Switching und einem standardisierten Fabric-Manager-Modell. CXL 3.0 erweiterte dieses Konzept anschließend durch größere Fabrics, mehrstufiges Switching und kohärentes Memory Sharing. Diese Unterscheidung ist wichtig. Memory Pooling bedeutet, dass eine bestimmte Menge an CXL-angebundenem Speicher je nach aktuellem Bedarf verschiedenen Hosts zugewiesen werden kann. Ein Speicherbereich, der zunächst einem Server zugeordnet wurde, lässt sich später wieder freigeben und einem anderen System bereitstellen. Memory Sharing geht noch einen Schritt weiter und ermöglicht es, unterstützte Speicherbereiche mehreren Hosts gleichzeitig zur Verfügung zu stellen, während Kohärenzmechanismen dafür sorgen, dass die Systeme eine konsistente Sicht auf die Daten behalten. CXL 4.0 übernimmt diese Funktionen und stellt dem Fabric gleichzeitig wesentlich mehr Bandbreite zur Verfügung. Das Ergebnis ist also kein im Jahr 2026 neu erfundenes Pooling-Konzept, sondern eine schnellere Verbindung, die bereits bestehende Pooling- und Sharing-Modelle für größere Systeme und anspruchsvollere Workloads attraktiver macht.
Ein einfaches Beispiel zeigt, weshalb dieses Konzept interessant ist. Mehrere Cloud-Server können jeweils über ausreichend lokalen DRAM für ihren normalen Betrieb verfügen und zusätzlich mit einem gemeinsamen Bereich aus CXL-Speicher verbunden sein. Einer dieser Server benötigt möglicherweise kurzfristig mehrere Hundert Gigabyte zusätzlichen Speicher für Analysen, eine KI-Inferenzanwendung oder eine große Datenbank. Anstatt diese Kapazität dauerhaft in genau diesem System installieren zu müssen, kann ihm ein Teil des CXL-Pools zugewiesen werden. Sinkt der Bedarf wieder, wird die Kapazität freigegeben und steht anschließend für andere Systeme zur Verfügung. Ein Fabric Manager koordiniert die entsprechenden Ressourcen, während Betriebssystem und Orchestrierungssoftware bestimmen, wie der zusätzliche Speicher verwendet wird. Die konkrete Umsetzung unterscheidet sich je nach Hersteller, und gegenüber lokalem DRAM entsteht weiterhin zusätzliche Latenz. Das wirtschaftliche Grundprinzip bleibt jedoch einfach: Speicher, der ansonsten ungenutzt hinter einer einzelnen CPU verbleiben würde, kann anderen Workloads zur Verfügung gestellt werden.
Dieser Ansatz richtet sich gegen das Problem des sogenannten Stranded Memory. Cloud-Server werden häufig für Spitzenanforderungen und nicht für den durchschnittlichen Bedarf konfiguriert, weil ein Speichermangel einen Workload stark verlangsamen oder seine Ausführung vollständig verhindern kann. Dadurch kann ein Server über freien DRAM verfügen, während einem benachbarten System Kapazität fehlt. Pooling kann den Bedarf verringern, jeden Server mit derselben großen Sicherheitsreserve auszustatten. Gleichzeitig lassen sich Upgrades potenziell einfacher durchführen, weil zusätzlicher Speicher in einem gemeinsamen CXL-System installiert werden kann und nicht ausschließlich über die lokalen Speicherkanäle des Prozessors ergänzt werden muss. Ob dieses Modell wirtschaftlich sinnvoll ist, hängt weiterhin vom Verhalten der Workloads, den Kosten der Switches, dem Stromverbrauch, der Softwareunterstützung und dem Leistungsunterschied zwischen lokalem und CXL-angebundenem Speicher ab. CXL sollte deshalb als zusätzliche Speicherebene betrachtet werden und nicht als Hinweis darauf, dass lokaler DRAM nicht mehr benötigt wird. Besonders effiziente Systeme kombinieren in der Regel mehrere Speicherarten für unterschiedliche Aufgaben.
Warum KI-Inferenz von gepooltem und gestuftem Speicher profitieren kann
KI-Inferenz gehört im Jahr 2026 zu den deutlichsten Gründen für das wachsende Interesse an CXL-Speicher. Beim Betrieb großer Sprachmodelle müssen nicht nur die Modellgewichte gespeichert werden. Jede aktive Anfrage kann zusätzlich temporären Zustand benötigen, darunter den Key-Value-Cache, den Transformer-Modelle verwenden, um bereits verarbeitete Attention-Informationen nicht erneut berechnen zu müssen. Mit längeren Kontextfenstern und einer größeren Zahl gleichzeitiger Nutzer oder KI-Agenten kann dieser Cache erhebliche Speicherkapazität beanspruchen. Werden sämtliche Daten im teuren HBM des Beschleunigers gehalten, kann die Zahl der gleichzeitig verarbeitbaren Sitzungen begrenzt werden, obwohl die GPU noch über freie Rechenleistung verfügt. Werden überschüssige Daten dagegen vollständig auf SSDs ausgelagert, können deutlich höhere Zugriffsverzögerungen entstehen. CXL-Speicher bietet eine Zwischenstufe, in der ausgewählte Informationen weiterhin direkt als Speicher adressierbar bleiben, ohne die wertvollste lokale Kapazität des Beschleunigers vollständig zu belegen.
Das bedeutet nicht, dass ein KI-Betreiber einfach ein komplettes Modell aus HBM in CXL-Speicher verschieben sollte. Besonders häufig benötigte Daten profitieren weiterhin davon, möglichst nah am Beschleuniger zu liegen, und die Bandbreite von HBM ist deutlich höher als die einer externen CXL-Speicherebene. Ein realistischeres Design hält latenzkritische Modelldaten im HBM, bewahrt geeignete Arbeitsdaten im lokalen Systemspeicher auf und nutzt CXL-Kapazität für Informationen, die schnell verfügbar bleiben müssen, aber nicht zu jedem Zeitpunkt die maximale lokale Bandbreite benötigen. KV-Cache-Tiering und Offloading gehören zu den wichtigsten Beispielen, die 2026 innerhalb der CXL-Branche diskutiert werden. Kann die Software zuverlässig bestimmen, welche Daten in welcher Speicherebene liegen sollten, kann ein Server längere Kontexte oder mehr gleichzeitige Inferenzanfragen unterstützen, ohne im gleichen Umfang teuren Beschleunigerspeicher hinzufügen zu müssen. Der Vorteil liegt daher vor allem in einer effizienteren Nutzung der vorhandenen Kapazität und nicht darin, dass CXL grundsätzlich schneller als HBM wäre.
Dasselbe Prinzip gilt auch außerhalb großer Sprachmodelle. Empfehlungssysteme können sehr große Embedding-Tabellen verwalten, Datenverarbeitungsaufgaben können mit Datensätzen arbeiten, die den lokalen DRAM übersteigen, und CPU-basierte Inferenz kann mehr Speicher benötigen, als sich in einer herkömmlichen Serverkonfiguration wirtschaftlich sinnvoll bereitstellen lässt. CXL kann den nutzbaren Speicherbereich für solche Workloads erweitern und gleichzeitig gewöhnliche Speicherzugriffsmechanismen beibehalten. Durch Pooling entsteht eine zusätzliche Flexibilitätsebene, weil Speicherkapazität dem Bedarf folgen kann, statt dauerhaft einer einzelnen Maschine zugeordnet zu sein. Das ist besonders für gemeinsam genutzte KI-Infrastrukturen interessant, in denen verschiedene Dienste zu unterschiedlichen Zeiten ihre Lastspitzen erreichen. Ein Batch-Job kann beispielsweise nachts viel Speicher beanspruchen, während ein Inferenzdienst dieselbe Kapazität während der Geschäftszeiten benötigt. Dynamische Zuweisung beseitigt nicht sämtliche betrieblichen Einschränkungen, und die Verteilung von Kapazität zwischen Hosts muss weiterhin durch Betriebssystem und Infrastruktur-Software verwaltet werden. Betreiber erhalten dadurch jedoch deutlich mehr Möglichkeiten als bei einem Server mit unveränderlicher Speicherausstattung.
Wie CXL 4.0 Serverdesign und Cloud-Wirtschaftlichkeit verändert
Die langfristige Veränderung durch CXL ist eher architektonischer als rein numerischer Natur. Klassische Server werden um Ressourcen herum entwickelt, die einer einzelnen Maschine gehören: Prozessoren, DIMMs und Beschleuniger werden für diesen Server installiert und verbleiben dort auch dann, wenn sie nur wenig genutzt werden. CXL ermöglicht es, bestimmte Ressourcen und insbesondere Speicher unabhängiger zu behandeln. Ein Rack kann herkömmliche Server gemeinsam mit CXL-Switches, Speichererweiterungsgeräten und gepoolten Speichersystemen enthalten, wobei Kapazität abhängig von den Anforderungen der jeweiligen Workloads verteilt wird. CXL 3.x bietet bereits einen großen Teil der Fabric-Funktionen, die für dieses Modell erforderlich sind. CXL 4.0 ergänzt erheblich mehr Verbindungsbandbreite und zusätzliche Anschlussmöglichkeiten, die mit steigender Gerätezahl und wachsendem Datenverkehr immer wichtiger werden. Dadurch wird ein Rack nicht zu einem einzigen Computer. Die bisherige Annahme, dass jeder nutzbare Speicher physisch direkt neben der CPU installiert sein muss, die später auf ihn zugreift, verliert jedoch zunehmend an Bedeutung.
Für Cloud-Anbieter liegt der offensichtlichste finanzielle Vorteil in einer potenziell besseren Speicherauslastung. DRAM macht einen beträchtlichen Anteil der Kosten und des Energiebedarfs speicherintensiver Server aus. Wird jedes System für selten auftretende Lastspitzen ausgestattet, kann ein großer Teil dieser Investition während des normalen Betriebs kaum produktiv genutzt werden. Ein gemeinsamer Speicherpool kann Betreibern ermöglichen, Kapazität stärker am gesamten Bedarf einer Gruppe von Systemen auszurichten, statt jede einzelne Maschine für ihr theoretisches Maximum auszustatten. Einsparungen entstehen jedoch nicht automatisch. CXL-Switches, Controller, Speichergehäuse und Managementsoftware verursachen ebenfalls Kosten und verbrauchen Energie. Workloads, die dauerhaft besonders niedrige Speicherlatenzen benötigen, können weiterhin große Mengen lokalen DRAM rechtfertigen. Der überzeugendste wirtschaftliche Nutzen entsteht daher dort, wo der Speicherbedarf zwischen Hosts stark schwankt, Kapazität wichtiger als minimale Latenz ist oder zusätzlicher Speicher dazu beiträgt, teure Prozessoren und Beschleuniger produktiv zu halten, statt auf Daten warten zu lassen, die erst aus Massenspeicher geladen werden müssen.
Betriebliche Flexibilität könnte sich als ebenso wichtig erweisen wie die reinen Hardwarekosten. Ein Cloud-Dienst kann sich während der Lebensdauer eines Servers erheblich verändern. KI-Modelle werden größer, Datenbanken wachsen und Kunden wechseln zwischen verschiedenen Instanztypen. Bei einer Maschine mit fest installiertem Speicher kann ein höherer Kapazitätsbedarf dazu führen, dass der Workload verschoben oder die Hardware ersetzt werden muss. CXL-Erweiterung und Memory Pooling schaffen die Möglichkeit, die verfügbare Speichermenge zu verändern, ohne den Compute-Knoten vollständig neu aufzubauen. Außerdem lassen sich stärker spezialisierte Serverkonfigurationen realisieren: Einige Systeme verfügen über viel lokalen Speicher, während andere für Workloads, die zusätzliche Latenz tolerieren können, stärker auf gemeinsam nutzbare Kapazität zurückgreifen. Zuverlässigkeit und Sicherheit bleiben in diesem Modell entscheidend. Speicher muss sicher neu zugewiesen werden können, Fehler müssen isoliert werden und Daten eines Workloads dürfen für andere Workloads nicht sichtbar werden. Wenn CXL zunehmend für Multi-Host- und Rack-Scale-Systeme verwendet wird, werden solche Managementanforderungen zu einem grundlegenden Bestandteil der Architektur.
Was nach 2026 von CXL-Implementierungen zu erwarten ist
Eine der wichtigsten Tatsachen im Jahr 2026 ist, dass eine veröffentlichte CXL-4.0-Spezifikation nicht bedeutet, dass CXL-Hardware mit 128 GT/s bereits flächendeckend in produktiven Rechenzentren eingesetzt wird. Aktuelle kommerzielle Systeme und Demonstrationen verteilen sich auf mehrere Generationen. Samsungs CXL-Speichermodul MD220 verwendet beispielsweise CXL 2.0 über PCIe 5.0 und ist mit Kapazitäten von 128 GB und 256 GB erhältlich, während Samsungs rackorientiertes Memory-Pooling-System CMM-B ebenfalls auf CXL-1.1- und CXL-2.0-Technologie basiert. SK hynix zeigte auch 2026 noch CXL-2.0-basierte CMM-DDR5-Lösungen, während auf Veranstaltungen des CXL Consortium im selben Jahr bereits funktionierende CXL-3.2-Verbindungen und entsprechende Controller präsentiert wurden. Gleichzeitig stellen Halbleiter-IP-Anbieter bereits Controller-, Sicherheits- und Verifikationstechnologien für CXL 4.0 bereit, die für Chips mit 128 GT/s vorgesehen sind. Der Übergang hat also begonnen, doch ausgereifte heutige Produkte und künftige CXL-4.0-Entwicklungen existieren parallel.
Eine schrittweise Einführung ist bei einer Serververbindung dieser Art normal. Nach der Veröffentlichung einer Spezifikation müssen Controller, Switches, Retimer, Prozessoren, Speichergeräte, Firmware und Betriebssystemunterstützung entwickelt werden. Anschließend folgen Konformitätstests und herstellerübergreifende Interoperabilitätsprüfungen, bevor große Betreiber eine neue Generation mit ausreichender Sicherheit einsetzen können. CXL 4.0 profitiert davon, dass es die Architektur früherer CXL-Versionen fortsetzt und abwärtskompatibel bleibt. Hersteller können dadurch auf bestehender Software und bereits gesammelter Entwicklungserfahrung aufbauen. Der erste Grund für einen Wechsel zu CXL 4.0 wird nicht zwangsläufig allein der Wert von 128 GT/s sein. Für Betreiber ist entscheidender, ob die zusätzliche Bandbreite mehr Speichergeräte, mehr parallelen Datenverkehr oder eine höhere Aktivität von Beschleunigern erlaubt, ohne dass die Verbindung selbst zum Engpass wird. Wenn sich CXL-Fabrics von einfacher Speichererweiterung in Richtung gepoolter und gemeinsam genutzter Ressourcen auf Rack-Ebene entwickeln, gewinnt die zusätzliche Bandbreite weiter an Bedeutung, weil immer mehr Workloads um dieselbe Verbindungskapazität konkurrieren.
Für KI- und Cloud-Infrastrukturen sollte CXL 4.0 deshalb als Teil einer grundlegenderen Veränderung der Speicherarchitektur betrachtet werden und nicht nur als Geschwindigkeitssteigerung einer einzelnen Generation. Lokaler DDR-Speicher wird weiterhin vergleichsweise schnellen CPU-Speicher bereitstellen, HBM bleibt für Beschleuniger mit extrem hohen Bandbreitenanforderungen unverzichtbar und SSDs werden weiterhin wirtschaftliche, persistente Speicherkapazität liefern. CXL ergänzt diese Ressourcen um eine flexible Ebene, über die Server auf größere Pools kohärenten Speichers zugreifen können und Kapazität mit weniger physischen Einschränkungen zugewiesen werden kann. Die Generation mit 128 GT/s schafft mehr Spielraum, damit diese Ebene weiter wachsen kann. Kurzfristig werden viele produktive Systeme weiterhin CXL 2.0 oder 3.x verwenden, während neue Chips schrittweise in Richtung CXL 4.0 entwickelt werden. Über die folgenden Servergenerationen dürfte die wichtigere Veränderung jedoch darin bestehen, nicht mehr ausschließlich zu fragen, wie viel Speicher in einem einzelnen Server installiert ist, sondern wie viel geeigneter Speicher einem Workload genau dann bereitgestellt werden kann, wenn er ihn tatsächlich benötigt.
