TL;DR: HBM e memoria CXL non sono alternative equivalenti. HBM serve quando il limite è la banda vicino alla GPU; CXL aggiunge capacità più economica per dati meno urgenti. Per una PMI la scelta sensata non è comprare più memoria “veloce” in blocco, ma misurare il working set e separare dati caldi e freddi. Se devo scegliere un’architettura, scelgo HBM per il percorso critico e CXL solo come secondo livello controllato.

La memoria è tornata al centro dell’infrastruttura AI. Il candidato di oggi parte da una proposta concreta: riutilizzare moduli DDR4 dietro controller CXL, invece di scartarli quando i server passano a piattaforme DDR5. L’idea è utile, ma può produrre una lettura sbagliata: più capacità non equivale a più prestazioni.

Il confronto corretto è tra due strategie. La prima concentra budget e dati nella memoria HBM vicina all’acceleratore. La seconda costruisce una gerarchia: HBM per ciò che deve essere letto subito, memoria collegata via CXL per il working set meno caldo, storage per il resto.

Il criterio: tempo di accesso, capacità e complessità

Valuto i due approcci su quattro domande: quanta banda offre la memoria al calcolo, quanta capacità si può aggiungere, quanto costa gestire il placement dei dati e quanto è maturo lo stack software. Non confronto quindi due DIMM o due listini. Confronto il ruolo che ogni livello svolge nel sistema.

I numeri pubblicati dai vendor rendono visibile la differenza, pur senza costituire un benchmark omogeneo. La pagina NVIDIA per GB300 NVL72 indica 20 TB di memoria GPU e fino a 576 TB/s di banda complessiva su 72 GPU. La linea Marvell Structera X dichiara fino a 200 GB/s per il controller e oltre 4 TB di capacità DDR4. HBM vince sulla velocità locale; CXL cambia la scala della capacità.

Approccio A: più HBM vicino alla GPU

HBM è la scelta naturale quando il collo di bottiglia è alimentare GPU o acceleratori senza lasciarli in attesa. Training, inferenza ad alto throughput e porzioni attive del KV cache beneficiano della banda elevata e della vicinanza fisica al processore.

Il vantaggio operativo è la prevedibilità. Il dato resta nel dominio per cui l’hardware e i framework sono ottimizzati. Ci sono meno movimenti tra livelli, meno policy da tarare e meno casi in cui una pagina “fredda” diventa improvvisamente calda nel posto sbagliato. Per un servizio con SLA stretti, questa semplicità vale denaro.

Il contro è altrettanto netto. La capacità HBM è limitata dal package dell’acceleratore e cresce insieme a hardware costoso. Se il carico conserva grandi quantità di contesto, embedding, cache o feature che non vengono lette con la stessa frequenza, pagare HBM per tutto significa usare il tier più caro anche per dati che potrebbero stare altrove.

Approccio B: HBM più memoria CXL a livelli

CXL aggiunge memoria coerente attraverso l’interconnessione PCIe e permette espansione, pooling e condivisione. Il CXL Consortium ha introdotto il pooling con CXL 2.0; la specifica 3.2 ha poi aggiunto una Hot-Page Monitoring Unit pensata per il tiering. La documentazione AMD sulla memory expansion descrive la migrazione delle pagine calde verso la DRAM locale e di quelle fredde verso la memoria CXL.

Qui il vantaggio è usare una risorsa proporzionata al bisogno. Un pool CXL può contenere dati che devono restare indirizzabili ma non saturano continuamente il percorso di memoria. Marvell propone anche il riuso di DDR4: il controller Structera X 2404 supporta dodici DIMM per dispositivo. È capacità recuperata, non HBM economica.

Il prezzo nascosto è il software. Qualcuno deve distinguere le pagine calde da quelle fredde, osservare i fault, misurare le migrazioni e impedire che il traffico CXL diventi il nuovo collo di bottiglia. Anche la compatibilità va qualificata: CPU, firmware, sistema operativo, controller e carico devono comportarsi come previsto. Senza telemetria, il tiering è solo una speranza architetturale.

Cosa cambia per PMI, WordPress e automazioni

Quasi nessuna PMI comprerà direttamente uno switch CXL. La decisione arriva attraverso il cloud, un server gestito o un fornitore di inferenza. Per questo il capitolato deve chiedere metriche di workload, non sigle hardware: latenza p95 e p99, token al secondo, tasso di cache hit, costo per richiesta e comportamento quando il contesto cresce.

Su WordPress il principio resta valido. Un plugin che genera bozze, analizza cataloghi WooCommerce o costruisce embedding non deve tenere tutto nel tier più costoso. Contenuti correnti e cache attiva possono stare vicino al calcolo; archivio, vettori poco consultati e batch notturni possono usare memoria o storage più economici. La stessa logica vale in n8n e Make: separare i passaggi interattivi dai job asincroni prima di scegliere il modello o la macchina.

Questo approfondisce un punto già emerso nell’analisi su energia, fibra e RAM nell’infrastruttura AI: la capacità disponibile conta, ma conta di più dove viene messa rispetto al percorso critico. Se il provider vende una sola metrica aggregata, manca il dato che serve per decidere.

Una prova pratica prima di cambiare architettura

Partirei da un test A/B sullo stesso carico. Nel profilo A il working set resta nella memoria locale più veloce. Nel profilo B una quota crescente viene spostata sul tier CXL o, nel cloud, su un’istanza con memoria espansa. Poi misurerei latenza di coda, throughput, costo orario e volume di dati migrati.

Se il profilo B aumenta la capacità senza degradare gli SLA, il tiering sta facendo il suo lavoro. Se la latenza p99 sale appena il contesto supera una soglia, il carico non è abbastanza “freddo” per quel livello. Non serve discutere se CXL sia veloce in assoluto: serve sapere se è abbastanza veloce per quella parte del workflow.

La mia take: HBM prima, CXL dopo la misura

Per un nuovo sistema AI sceglierei HBM sul percorso critico e introdurrei CXL solo dopo avere osservato il working set reale. È una scelta meno elegante di una grande memoria uniforme, ma è verificabile e limita il rischio di spostare la latenza in un punto difficile da vedere.

CXL è convincente quando risolve un problema di capacità già misurato, soprattutto per inferenza, cache e consolidamento. Non lo userei per compensare un’architettura che copia dati inutilmente o conserva tutto senza una policy. La decisione netta è questa: prima riduci e classifica i dati; poi compra banda per quelli caldi e capacità per quelli freddi.

Fonti

Approfondimenti