CXL 4.0 nel 2026: come il memory pooling e i 128 GT/s stanno cambiando i server per l’AI e il cloud computing

La memoria è diventata uno dei principali vincoli delle moderne infrastrutture per l’intelligenza artificiale e il cloud. Processori e acceleratori continuano a diventare più veloci, ma aggiungere una quantità di memoria sufficiente per alimentarli in modo efficiente è sempre più difficile e costoso. Compute Express Link, meglio noto come CXL, affronta questo problema fornendo una connessione coerente tra processori, acceleratori e memoria esterna. CXL 4.0, pubblicato dal CXL Consortium nel novembre 2025, aumenta la velocità massima di trasferimento da 64 GT/s a 128 GT/s, mantenendo al tempo stesso le funzionalità di memory pooling e condivisione sviluppate nelle precedenti generazioni di CXL. Nel 2026, questa combinazione è particolarmente rilevante per l’inferenza AI, i grandi server cloud e il computing su scala rack. CXL 4.0 non rende obsolete la memoria DDR convenzionale o la memoria ad alta larghezza di banda, né trasforma immediatamente ogni rack in un unico enorme sistema di memoria. Offre però una soluzione concreta per considerare la memoria come una risorsa più flessibile, anziché come una quantità fissa assegnata permanentemente a un singolo processore.

Perché CXL 4.0 è importante per i server AI e cloud nel 2026

CXL è stato sviluppato perché il rapporto tradizionale tra processori e memoria stava diventando troppo restrittivo per i carichi di lavoro dei data center. Un server convenzionale dispone di una quantità fissa di memoria locale collegata attraverso i canali di memoria della CPU. Questa configurazione funziona bene quando i carichi di lavoro sono prevedibili, ma i sistemi cloud e AI raramente rimangono stabili nel tempo. Un server può aver bisogno temporaneamente di diversi terabyte di memoria, mentre un’altra macchina nello stesso rack può disporre di grandi quantità di DRAM inutilizzata. Installare in ogni server abbastanza memoria locale da coprire il possibile picco di domanda significa lasciare inutilizzata una capacità costosa per gran parte del tempo. CXL modifica questo rapporto permettendo ai dispositivi di memoria compatibili di trovarsi al di fuori della normale configurazione DIMM del processore, pur continuando a essere accessibili attraverso operazioni di lettura e scrittura tipiche della memoria. Le precedenti versioni di CXL hanno introdotto espansione, switching, pooling e condivisione. CXL 4.0 si concentra soprattutto sull’aumento della quantità di dati che può transitare attraverso queste connessioni.

Il cambiamento principale è il passaggio a 128 GT/s, il doppio rispetto alla velocità massima di 64 GT/s di CXL 3.x. CXL 4.0 raggiunge questo risultato sfruttando la segnalazione fisica definita per PCI Express 7.0, la cui specifica finale 1.0 è stata pubblicata nel giugno 2025. GT/s significa giga-transfer al secondo e non deve essere confuso con gigabyte al secondo. Il valore indica la velocità di segnalazione di ogni corsia, mentre la larghezza di banda effettivamente utilizzabile dipende da fattori come il numero di corsie, l’overhead del protocollo e la configurazione del dispositivo. PCI Express 7.0, per esempio, può offrire fino a 512 GB/s di larghezza di banda bidirezionale con una connessione a sedici corsie. CXL utilizza la stessa base fisica ad alta velocità, ma aggiunge i meccanismi di coerenza e il comportamento di memoria necessari affinché processori, acceleratori e dispositivi di memoria possano lavorare insieme. Il risultato è una capacità di collegamento molto più elevata senza obbligare il software a gestire la memoria collegata come se fosse un normale sistema di archiviazione o una risorsa di rete tradizionale.

Questa maggiore velocità di trasferimento è importante perché l’espansione della memoria è utile solo quando il percorso verso quella memoria è sufficientemente rapido per il carico di lavoro. La DRAM locale rimane la soluzione preferita per i dati sensibili alla latenza, mentre la HBM continua a essere essenziale quando GPU e altri acceleratori richiedono una larghezza di banda estremamente elevata vicino alle unità di calcolo. La memoria CXL occupa una posizione diversa nella gerarchia. Può offrire una capacità molto superiore rispetto a quella che sarebbe economicamente conveniente installare accanto a ogni processore o acceleratore, con caratteristiche di accesso migliori rispetto al trasferimento degli stessi dati su SSD. Per le infrastrutture AI, questo crea un ulteriore livello di memoria tra la preziosa memoria locale ad alta velocità e l’archiviazione molto più lenta. Per gli operatori cloud, offre inoltre un modo per adattare più precisamente la capacità di memoria alle variazioni dei carichi di lavoro, evitando di configurare ogni server per il suo peggior scenario teorico. Il valore di CXL 4.0 deriva quindi tanto dalla flessibilità quanto dalla sua velocità di trasferimento.

Cosa cambia concretamente con 128 GT/s

Raddoppiare la velocità di un collegamento da 64 GT/s a 128 GT/s non significa che un’applicazione diventi automaticamente due volte più veloce. Molte applicazioni sono limitate dalle prestazioni del processore, dalla capacità degli acceleratori, dal comportamento del software o dalla latenza della memoria, piuttosto che dal collegamento CXL stesso. La larghezza di banda aggiuntiva diventa importante quando grandi quantità di dati devono spostarsi contemporaneamente tra processori, acceleratori e memoria espansa. Un server impegnato nell’inferenza di modelli di grandi dimensioni, nell’analisi dei dati o nell’esecuzione di un database in-memory può avere numerosi processi che leggono e scrivono dati nello stesso momento. In queste condizioni, un’interconnessione più lenta può diventare un collo di bottiglia condiviso anche quando dietro di essa è disponibile una grande quantità di memoria. CXL 4.0 offre maggiore margine per questo tipo di traffico. Il CXL Consortium ha inoltre mantenuto la struttura di trasferimento a dimensione fissa e i meccanismi di protezione dagli errori sviluppati per la generazione a 64 GT/s, consentendo di aumentare la velocità senza accettare semplicemente un incremento proporzionale della latenza del protocollo.

CXL 4.0 introduce anche le bundled ports. In termini semplici, più connessioni fisiche CXL possono essere considerate come un’unica connessione logica, a condizione che il dispositivo e il sistema host supportino questa configurazione. Si tratta di una funzione utile quando un singolo collegamento non è in grado di fornire abbastanza larghezza di banda a un acceleratore ad alte prestazioni o a un altro componente particolarmente esigente. Invece di costringere il resto del sistema a gestire ogni connessione come un percorso completamente separato, le bundled ports forniscono un metodo definito per aggregarle. La specifica supporta inoltre collegamenti nativi x2, che possono aiutare i progettisti a collegare un numero maggiore di dispositivi quando non è necessaria la massima larghezza di banda su ogni connessione, e consente l’uso di fino a quattro retimer per aumentare la portata del canale. Questi cambiamenti sono rilevanti per server ad alta densità e configurazioni rack in cui i componenti non possono sempre essere posizionati immediatamente accanto al processore. Offrono ai progettisti più possibilità di bilanciare larghezza del collegamento, numero di dispositivi, distanza e banda disponibile.

L’affidabilità è altrettanto importante quando la memoria viene spostata oltre la scheda madre. Il guasto di un modulo DIMM convenzionale interessa generalmente un singolo server, mentre una memoria condivisa o inserita in un pool può supportare più macchine o carichi di lavoro importanti. CXL 4.0 include quindi ulteriori funzionalità RAS, ossia reliability, availability e serviceability, dedicate alla memoria, con l’obiettivo di migliorare la visibilità degli errori e le attività di manutenzione. Questo non elimina la possibilità di guasti, e gli operatori devono comunque prevedere ridondanza, monitoraggio e una corretta distribuzione dei carichi di lavoro. Tuttavia, queste funzioni rendono più semplice gestire memoria CXL ad alta capacità come parte integrante dell’infrastruttura, anziché come una periferica insolita. Anche la piena compatibilità con le versioni precedenti è un aspetto pratico importante. I sistemi CXL 4.0 sono progettati per funzionare, dove supportato, con le generazioni precedenti di CXL, quindi le aziende non devono sostituire l’intera infrastruttura CXL in una sola fase. Questo è particolarmente importante nel 2026, perché il settore sta contemporaneamente implementando dispositivi CXL 2.0 e 3.x e iniziando la progettazione e la validazione dell’hardware CXL 4.0 a 128 GT/s.

Memory pooling: dalla memoria fissa del server alla capacità condivisa

Il memory pooling esisteva già prima di CXL 4.0. La funzione è stata introdotta con CXL 2.0, insieme allo switching e a un modello standardizzato di Fabric Manager. CXL 3.0 ha poi ampliato il concetto con fabric più estesi, switching multilivello e condivisione coerente della memoria. La distinzione è importante. Il memory pooling consente di assegnare una determinata quantità di memoria collegata tramite CXL a host differenti in base alle variazioni della domanda. Una porzione assegnata a un server può successivamente essere liberata e destinata a un’altra macchina. La memory sharing va oltre, permettendo a determinate regioni di memoria compatibili di essere disponibili contemporaneamente a più host, mentre i meccanismi di coerenza mantengono allineata la loro visione dei dati. CXL 4.0 conserva queste funzionalità e fornisce al fabric una larghezza di banda notevolmente superiore. Il risultato pratico non è quindi una nuova forma di pooling inventata nel 2026, ma un’interconnessione più veloce che rende i modelli esistenti di pooling e condivisione più interessanti per sistemi di maggiori dimensioni e carichi di lavoro più pesanti.

Un esempio semplice aiuta a capire perché questo approccio sia utile. Immaginiamo diversi server cloud, ciascuno dotato di abbastanza DRAM locale per il normale funzionamento, collegati a un banco aggiuntivo di memoria CXL. Uno dei server potrebbe improvvisamente aver bisogno di centinaia di gigabyte di memoria aggiuntiva per analisi, un servizio di inferenza AI o un grande database. Invece di richiedere che tale capacità sia stata installata permanentemente all’interno di quella specifica macchina, una parte del pool CXL può essere assegnata al server. Quando la domanda diminuisce, la capacità può essere restituita e resa disponibile altrove. Un Fabric Manager coordina le risorse coinvolte, mentre il sistema operativo e il software di orchestrazione stabiliscono come utilizzare la memoria aggiuntiva. L’implementazione esatta varia tra i diversi fornitori e rimane comunque un costo in termini di latenza rispetto alla DRAM locale, ma il principio economico è semplice: la memoria che altrimenti rimarrebbe inutilizzata dietro una CPU può diventare capacità disponibile per altri carichi di lavoro.

Questo approccio affronta il problema noto come stranded memory, cioè memoria installata ma non utilizzata in modo efficiente. I server cloud vengono spesso configurati in funzione dei requisiti di picco anziché delle esigenze medie, perché l’esaurimento della memoria può compromettere seriamente un carico di lavoro o impedirne completamente l’esecuzione. Di conseguenza, un server può avere molta DRAM libera mentre una macchina vicina non dispone di capacità sufficiente. Il pooling riduce la necessità di assegnare a ogni macchina lo stesso ampio margine di sicurezza. Può inoltre rendere gli aggiornamenti meno complessi, perché la memoria aggiuntiva può essere installata in un sottosistema CXL condiviso anziché soltanto popolando i canali di memoria locali del processore. La convenienza economica dipende comunque dal comportamento dei carichi di lavoro, dal costo degli switch, dal consumo energetico, dal supporto software e dalla differenza di prestazioni tra memoria locale e memoria collegata tramite CXL. CXL deve quindi essere considerato come un ulteriore livello della gerarchia di memoria, non come la prova che la DRAM locale non sia più necessaria. Le configurazioni più efficienti utilizzano generalmente diversi tipi di memoria per esigenze differenti.

Perché l’inferenza AI beneficia della memoria pooled e tiered

L’inferenza AI è uno dei motivi più evidenti del crescente interesse verso la memoria CXL nel 2026. L’esecuzione di grandi modelli linguistici richiede molto più della semplice memorizzazione dei pesi del modello. Ogni richiesta attiva può richiedere anche uno stato temporaneo, incluso il key-value cache utilizzato dai modelli transformer per evitare di ricalcolare le informazioni di attenzione già elaborate. Con l’aumento della lunghezza delle finestre di contesto e del numero di utenti simultanei o agenti AI gestiti dai server, questa cache può occupare una quantità considerevole di memoria. Conservare ogni dato nella costosa HBM dell’acceleratore può limitare il numero di sessioni che un server riesce a gestire anche quando la GPU dispone ancora di capacità di calcolo inutilizzata. Spostare tutti i dati in eccesso sugli SSD, al contrario, può introdurre ritardi di accesso molto più elevati. La memoria CXL offre un livello intermedio nel quale determinate informazioni possono rimanere direttamente indirizzabili come memoria senza occupare la capacità locale più preziosa dell’acceleratore.

Questo non significa che un operatore AI dovrebbe semplicemente spostare un intero modello dalla HBM alla memoria CXL. I dati utilizzati più frequentemente continuano a beneficiare di una posizione il più possibile vicina all’acceleratore, e la larghezza di banda disponibile nella HBM rimane nettamente superiore a quella di un livello di memoria CXL esterno. Un progetto più realistico mantiene i dati del modello sensibili alla latenza nella HBM, conserva i dati di lavoro appropriati nella DRAM locale del sistema e utilizza la capacità CXL per le informazioni che devono restare rapidamente disponibili ma non richiedono la massima larghezza di banda locale in ogni momento. Il tiering e l’offload della KV cache sono esempi importanti discussi dal settore CXL nel 2026. Quando il software riesce a identificare quali dati devono essere collocati in ciascun livello, il server può supportare contesti più lunghi o un maggior numero di richieste di inferenza simultanee senza dover aggiungere una quantità equivalente di costosa memoria dell’acceleratore. Il vantaggio riguarda quindi l’efficienza della capacità, non l’idea che CXL sia intrinsecamente più veloce della HBM.

Lo stesso principio si applica anche ad altri tipi di carichi di lavoro. I sistemi di raccomandazione possono utilizzare tabelle di embedding molto grandi, i processi di elaborazione dei dati possono lavorare con dataset più grandi della DRAM locale e l’inferenza eseguita su CPU può richiedere una quantità di memoria superiore a quella che una configurazione server convenzionale può offrire in modo economicamente conveniente. CXL può estendere la memoria utilizzabile per questi carichi di lavoro mantenendo la normale semantica di accesso alla memoria. Il pooling aggiunge un ulteriore livello di flessibilità perché la capacità può seguire la domanda anziché essere dedicata in modo permanente a una singola macchina. Questo è particolarmente interessante nelle infrastrutture AI condivise, dove servizi diversi raggiungono i propri picchi in momenti differenti. Un processo batch può richiedere molta memoria durante la notte, mentre un servizio di inferenza può aver bisogno della stessa capacità durante le ore lavorative. L’allocazione dinamica non elimina ogni vincolo operativo e lo spostamento della capacità tra host richiede comunque la gestione da parte del sistema operativo e del software infrastrutturale, ma offre agli operatori molte più possibilità rispetto a un server con memoria fissa.

Come CXL 4.0 cambia la progettazione dei server e l’economia del cloud

Il cambiamento a lungo termine introdotto da CXL è soprattutto architetturale, non semplicemente numerico. I server tradizionali sono progettati intorno a risorse appartenenti a una singola macchina: processori, moduli DIMM e acceleratori vengono installati per quel server e vi rimangono anche quando sono poco utilizzati. CXL permette di gestire alcune di queste risorse, in particolare la memoria, in modo più indipendente. Un rack può contenere server convenzionali insieme a switch CXL, dispositivi di espansione della memoria e sistemi di memoria pooled, con la capacità assegnata in funzione delle esigenze dei carichi di lavoro. CXL 3.x fornisce già gran parte del comportamento fabric necessario per questo modello. CXL 4.0 aggiunge una larghezza di banda molto maggiore e nuove possibilità di connessione, particolarmente importanti con l’aumento del numero di dispositivi e del volume di traffico. Questo non trasforma un rack in un singolo computer, ma riduce la dipendenza dal principio secondo cui ogni byte di memoria utile deve essere installato fisicamente accanto alla CPU che lo utilizzerà.

Per i fornitori di servizi cloud, il vantaggio economico più evidente è il possibile miglioramento dell’utilizzo della memoria. La DRAM rappresenta una parte significativa del costo e del consumo energetico dei server con elevate esigenze di memoria. Se ogni server viene configurato per gestire rari picchi di domanda, gran parte di questo investimento può produrre poco lavoro utile durante il normale funzionamento. Un pool di memoria condiviso può consentire agli operatori di acquistare capacità in funzione della domanda aggregata, anziché dotare ogni macchina di memoria sufficiente per il proprio massimo teorico individuale. Il risparmio non è automatico. Switch CXL, controller, enclosure di memoria e software di gestione hanno a loro volta un costo e consumano energia, mentre i carichi di lavoro che richiedono costantemente una latenza molto bassa possono continuare a giustificare grandi quantità di DRAM locale. Il caso economico più convincente si presenta quindi quando la domanda di memoria varia significativamente tra gli host, quando la capacità è più importante della latenza minima o quando una maggiore quantità di memoria consente a processori e acceleratori costosi di rimanere produttivi anziché attendere che i dati vengano recuperati dall’archiviazione.

La flessibilità operativa potrebbe rivelarsi importante quanto il costo dell’hardware. Un servizio cloud può cambiare notevolmente durante la vita utile di un server. I modelli AI diventano più grandi, i database crescono e i clienti passano da un tipo di istanza a un altro. Con una macchina dotata di memoria fissa, un aumento della capacità può richiedere lo spostamento del carico di lavoro o la sostituzione dell’hardware. L’espansione e il pooling tramite CXL rendono possibile modificare la memoria disponibile senza dover ricostruire il nodo di calcolo. Possono inoltre favorire configurazioni server più specializzate: alcune macchine possono disporre di molta memoria locale, mentre altre possono dipendere maggiormente dalla capacità condivisa per carichi di lavoro in grado di tollerare una latenza aggiuntiva. Affidabilità e sicurezza restano fondamentali in questo modello. La memoria deve essere riassegnata in modo sicuro, i guasti devono essere isolati e i dati appartenenti a un carico di lavoro non devono diventare visibili a un altro. Con l’evoluzione di CXL verso l’utilizzo multi-host e su scala rack, questi requisiti di gestione diventano parte integrante della progettazione.

Cosa aspettarsi dalle implementazioni CXL dopo il 2026

La realtà più importante da considerare nel 2026 è che la pubblicazione della specifica CXL 4.0 non significa che l’hardware CXL a 128 GT/s sia già diffuso in tutti i data center di produzione. I sistemi commerciali e le dimostrazioni attuali comprendono ancora diverse generazioni. Il modulo di memoria CXL MD220 di Samsung, per esempio, utilizza CXL 2.0 su PCIe 5.0 ed è disponibile con capacità di 128 GB e 256 GB, mentre il sistema di memory pooling CMM-B di Samsung orientato ai rack utilizza anch’esso tecnologie CXL 1.1 e 2.0. Nel corso del 2026 SK hynix continuava a mostrare soluzioni CMM-DDR5 di classe CXL 2.0, mentre gli eventi del CXL Consortium includevano collegamenti e controller CXL 3.2 funzionanti dal vivo. Allo stesso tempo, i fornitori di tecnologie per la progettazione di semiconduttori stanno già mettendo a disposizione controller CXL 4.0, funzioni di sicurezza e strumenti di verifica per chip destinati a operare a 128 GT/s. In altre parole, la transizione è in corso, ma i prodotti maturi di oggi convivono con i progetti CXL 4.0 destinati alle generazioni successive.

Questa adozione graduale è normale per un’interconnessione destinata ai server. Alla pubblicazione di una specifica devono seguire controller, switch, retimer, processori, dispositivi di memoria, firmware, supporto dei sistemi operativi, test di conformità e verifiche di interoperabilità tra più fornitori prima che i grandi operatori possano procedere con implementazioni su vasta scala. CXL 4.0 parte da una posizione favorevole perché prosegue l’architettura delle precedenti versioni CXL e mantiene la compatibilità con esse, permettendo ai produttori di sfruttare l’esperienza già acquisita sul piano software e progettuale. Il primo motivo per adottarlo non sarà necessariamente il valore di 128 GT/s in sé. Gli operatori saranno più interessati a capire se la larghezza di banda aggiuntiva consenta di utilizzare più dispositivi di memoria, gestire più traffico simultaneo o aumentare l’attività degli acceleratori senza creare un collo di bottiglia. Con l’evoluzione dei fabric CXL dalla semplice espansione della memoria verso risorse pooled e condivise a livello di rack, la banda aggiuntiva diventa sempre più utile perché un numero crescente di carichi di lavoro compete per la stessa capacità di interconnessione.

Per le infrastrutture AI e cloud, CXL 4.0 dovrebbe quindi essere considerato come parte di un cambiamento più ampio nella progettazione della memoria, non semplicemente come un aumento di velocità legato a una nuova generazione. La memoria DDR locale continuerà a fornire memoria relativamente veloce per le CPU, la HBM continuerà a essere utilizzata dagli acceleratori che richiedono una larghezza di banda estrema e gli SSD continueranno a offrire capacità persistente a costi contenuti. CXL aggiunge un livello flessibile tra queste risorse, consentendo ai server di accedere a pool più ampi di memoria coerente e permettendo di assegnare la capacità con meno vincoli fisici. La generazione a 128 GT/s offre a questo livello più spazio per crescere. Nel breve periodo, molti sistemi di produzione continueranno ancora a utilizzare CXL 2.0 o 3.x mentre il nuovo silicio si muove verso CXL 4.0. Nelle generazioni successive di server, il cambiamento più importante sarà probabilmente il passaggio dalla domanda “quanta memoria è installata in questo server?” alla domanda “quanta memoria adatta può essere resa disponibile a questo carico di lavoro nel momento in cui ne ha effettivamente bisogno?”.