Avevamo incontrato per la prima volta le CPU EPYC Venice lo scorso luglio, in occasione di AMD Advancing AI 2026: in quell’occasione l’azienda americana aveva anticipato numero di core, tipologie di memoria e tempistiche di arrivo sul mercato delle CPU EPYC di sesta generazione, inserendole all’interno della propria visione di rack Helios per le elaborazioni di intelligenza artificiale. Mancava però tutto quello che sta sotto la superficie, cioè i dettagli tecnici della nuova architettura Zen 6: com’è fatto il core, come sono organizzati i chiplet, quali scelte sono state fatte per alimentare un numero così elevato di core e quali piattaforme verranno abbinate alle diverse declinazioni del processore.
È proprio questo il tema dell’evento AMD In Depth 2026, che si è tenuto a Las Vegas il 4 e 5 novembre. Due giornate ben distinte: la prima interamente tecnica, con gli architetti che hanno progettato core, SoC e piattaforma; la seconda dedicata ad analizzare come queste tecnologie si traducono in prodotti, sistemi e soluzioni per i clienti, con il contributo di Microsoft e dei principali OEM.
La storia dei processori AMD EPYC inizia nel 2017 e si è sviluppata, ad oggi, attraverso 6 distinte generazioni. Siamo partiti con i primi processori noti con il nome in codice di Naples, la prima proposta basata su architettura Zen, a Rome con il raddoppio della densità di thread, passando per Milan, per Genoa e Bergamo con i primi design point differenziati, sino a Turin con le ottimizzazioni per il ruolo di host processor nei sistemi AI e i modelli a 5 GHz. La sesta generazione prende il nome in codice di Venice e, nelle parole di AMD, è quella pensata per l’era agentica: accanto al nodo host delle GPU servono sempre più CPU per eseguire le sandbox degli agenti, gli strumenti che questi richiamano e tutti quei carichi general purpose che l’IA moltiplica invece di ridurre.
I numeri che AMD mette sul piatto sono importanti: dalla prima generazione EPYC a Venice le prestazioni per singolo socket sono aumentate di circa 20 volte, mentre il confronto generazionale con Turin indica incrementi compresi tra 1,3x e 2,7x a seconda del tipo di carico. Questa evoluzione tecnologica ha permesso ad AMD di guadagnare una importante quota di fatturato nel mercato delle CPU server, superando nel 2026 la quota del 40%.
Zen 6: gli obiettivi del progetto
Mike Clark, Corporate Fellow e Chief Architect delle CPU AMD, nonché architetto del primo core Zen, ha illustrato le caratteristiche architetturali di Zen 6 entrando nel dettaglio delle varie novità implementate. Anche in questo caso è stata seguita una regola che ogni progettista conosce bene: le quattro grandezze presenti in una microarchitettura, cioè frequenza, IPC, consumo e area, si combattono tutte tra di loro. Spingere la frequenza significa ridurre il numero di porte logiche per ciclo di clock e quindi l’IPC; inseguire clock elevati richiede di suddividere il design in blocchi più piccoli, aumentando l’area; un design più grande consuma inevitabilmente di più.
Con Zen 4 AMD aveva iniziato a differenziare i core tramite il design fisico, dando vita alle versioni “c” ottimizzate per densità. Con Zen 6 l’azienda ha voluto spingere ulteriormente su questa strada, con due obiettivi complementari: sfruttare il design più efficiente per massimizzare il throughput complessivo del socket e al tempo stesso offrire un punto operativo a latenza più bassa possibile, per quegli scenari nei quali servono meno core ma con frequenze più elevate.
Gli obiettivi dichiarati per Zen 6 sono quindi cinque: un nuovo importante incremento delle prestazioni del core, lo sfruttamento del design efficiente per il massimo throughput, il potenziamento delle capacità di IA per i carichi agentici, il miglioramento del punto operativo a più bassa latenza e l’ulteriore estensione delle funzionalità di Confidential Computing.
Il front-end: alimentare un back-end sempre più affamato
L’architettura Zen 5 di precedente generazione aveva rappresentato una nuova base di partenza per AMD: fetch e pipeline su due basic block, dispatch e rename a 8 vie, 6 ALU, 4 operazioni di memoria per ciclo (tutte possono essere load, fino a 2 store), datapath floating point a 512 bit, FADD a 2 cicli, data cache L1 da 48 KB. Zen 6 parte da questa base, affinandone ogni aspetto.
Sul front-end le tabelle di predizione dei salti sono state ottimizzate per ottenere predizioni migliori nella stessa area; il Return Address Stack passa da 52 a 64 elementi e le code di predizione sono state ampliate. Il motore di predizione può gestire due salti per ciclo e sino a tre finestre di predizione per ciclo, alimentando due flussi di istruzioni verso il back-end; il fetch resta a 64 byte per ciclo da linee di cache differenti.
La Op Cache cresce da 6K istruzioni a 6,75K micro-op, con due letture per ciclo che possono estrarre sino a 18 micro-op per ciclo contro le 12 istruzioni di Zen 5c. Il motivo di questa attenzione al front-end, ha sottolineato Clark, è semplice: uno dei maggiori colli di bottiglia di un core moderno è un back-end che resta inattivo perché non riceve istruzioni da eseguire. AMD ha inoltre lavorato per ridurre la latenza in caso di errata predizione dei salti, così da riavviare il prima possibile il flusso di istruzioni.
Scheduler, esecuzione e finestra out-of-order
Rename, dispatch e retire restano a 8 vie, ma cambia l’organizzazione degli scheduler interi. Zen 6 adotta uno schema più distribuito, tornando alla condivisione tra scheduler per ALU e AGU: ci sono 96 elementi condivisi ALU/AGU a cui si aggiungono 48 elementi dedicati alle sole ALU, distribuiti su sei scheduler. Le unità di esecuzione sono 6 ALU con 2 moltiplicatori e 3 unità di branch, affiancate da 4 AGU per alimentare l’unità load/store.
La finestra di esecuzione cresce in modo sensibile: il register file fisico per gli interi passa da 240 a 352 elementi e il Reorder Buffer da 448 a 640 istruzioni in volo. AMD ha inoltre ampliato i casi di op-fusion, cioè la possibilità di unire due istruzioni in una singola micro-op: questo significa una sola selezione da parte dello scheduler, una sola esecuzione e un solo forward del risultato, con un vantaggio diretto in termini di consumo e una capacità effettiva del ROB ancora superiore al valore nominale.
Load/store, TLB e prefetch: pensati per 256 core
La data cache L1 resta da 48 KB a 12 vie con latenza di 4 cicli, con 4 pipeline load/store per un mix di 4 load o 2 store per ciclo e trasferimenti da 64 byte per ciclo tra L2 e L1. La novità più interessante riguarda la gestione dei carichi a 256 bit: Zen 5 poteva eseguire due load per ciclo di qualsiasi ampiezza, mentre Zen 6 consente due load da 512 bit oppure quattro load da 256 bit per ciclo. AMD ha in pratica riutilizzato i collegamenti fisici già presenti per AVX-512 per raddoppiare il throughput di caricamento del codice AVX/AVX2, ancora molto diffuso.
Il TLB L1 dati ha 96 elementi completamente associativi per tutte le dimensioni di pagina (4K, 2M, 1G), mentre il TLB L2 gestisce tutte le dimensioni tranne la pagina da 1 GB, servita da un TLB separato. Crescono anche le code: load queue da 64 a 80 elementi, store queue da 96 a 128, con una load ordering queue scalabile.
Un’attenzione particolare è stata dedicata al prefetching dei dati. Con 256 core per socket, nel caso delle soluzioni dotate di core Zen 6c, il comportamento ideale cambia radicalmente tra un sistema poco carico, dove conviene essere aggressivi, e uno saturo, dove prefetch inefficaci finirebbero per sprecare banda di memoria preziosa. Gli algoritmi di Zen 6 si adattano dinamicamente al numero di thread attivi e al carico del sottosistema di memoria.
Floating point e IA: FP16 nativo e Bit Matrix Multiply
L’unità floating point mantiene il datapath AVX-512 a 512 bit, due pipeline FMUL/FMAC e due FADD, con latenze invariate (4 cicli FMAC, 3 FMUL, 2 FADD) nonostante l’incremento di frequenza. Le novità sono sui tipi di dato: Zen 5 supportava il formato FP16 solo per conversione, costringendo a passare dal formato FP32 per i calcoli, mentre Zen 6 integra il supporto completo AVX-512 FP16. Le pipeline VNNI INT8 raddoppiano da 2 a 4, mentre restano 2 quelle per VNNI INT16 e BFLOAT16.
Debutta poi un’estensione proprietaria di AMD, BMM (Bit Matrix Multiply), pensata per algoritmi di manipolazione dei bit utilizzati in crittografia e in alcuni carichi IA, nata da richieste specifiche di alcuni clienti. Il nuovo ISA comprende anche AVX-VNNI-INT8, AVX-NE-CONVERT per le conversioni tra BF16/FP16 e FP32 e la promozione di AVX-IFMA in codifica VEX.
È in questo ambito che si trova una delle poche differenze microarchitetturali tra le due versioni del core: gli scheduler floating point hanno 46 elementi (per ciascuno dei tre) nel core Zen 6 ad alta frequenza e 60 elementi nel core Zen 6c. Il core di tipo c, avendo un target di frequenza più basso, può permettersi strutture più grandi e quindi un IPC più elevato.
Gerarchia di cache: Zen 6c diventa un core per le prestazioni
È forse questo il cambiamento più significativo della nuova generazione rispetto alle precedenti. Ogni core dispone di una cache L2 privata da 1 MB a 16 vie e di 4 MB di cache L3 condivisa. Per il core Zen 6c questo significa che il complesso da 32 core integra 128 MB di L3 a 16 vie, condivisa tra tutti i core: con Zen 5c la cache L3 era stata ridotta a 2 MB per core per far rientrare il design negli obiettivi di densità, e il CCX da 16 core disponeva di 32 MB. Si passa quindi a due volte il numero di core e quattro volte la cache L3 per complesso.
La L3 resta una victim cache, riempita dalle linee espulse dalle L2 e quindi in larga parte esclusiva. I tag delle L2 sono duplicati nella L3 per il probe filtering: se il core 0 manca un dato che si trova nella L2 del core 31, la L3 sa dove instradare la richiesta, senza coinvolgere il sottosistema di memoria. Ogni L2 supporta 127 miss in sospeso verso la L3, mentre il complesso da 32 core può gestirne 1.280 verso la memoria (480 nel CCD a 12 core). Il trasferimento tra L3 e L2 resta a 32 byte per ciclo per ragioni di efficienza, contro i 64 byte per ciclo tra L2 e L1.
Il risultato è che Zen 6c non è più il “fratello minore” ottimizzato per densità, ma secondo AMD diventa il core con il più elevato IPC della gamma e il prodotto di punta per cloud e carichi agentici. Un CCX più grande ha anche un vantaggio pratico: un numero maggiore di carichi e di macchine virtuali rientra in un singolo complesso, riducendo i casi in cui i dati devono essere condivisi tra CCX differenti: questo permette di limitare l’impatto di quello che da sempre è uno dei punti deboli delle architetture a chiplet.
Il core Zen 6 ad alta frequenza cresce invece da 8 a 12 core per CCX, con 48 MB di L3 e sempre 4 MB per core. Il clock massimo passa da 5,0 a 5,3 GHz; per Zen 6c si sale da 3,7 a 4,1 GHz.
IPC: +27% di media con Zen 6c
Misurare l’IPC tra generazioni è diventato più complicato, ha ammesso Clark, perché i CCX hanno ora dimensioni differenti. AMD ha quindi confrontato Zen 6c con Zen 5, il core a IPC più elevato della generazione precedente, a frequenza fissa e con un carico a 16 core. Su Turin, Zen 5, questo occupa due CCD, mentre su Venice rientra interamente in un singolo CCX: tale approccio favorisce in parte Zen 6c grazie alla cache L3 unificata ed è importante tenerne conto.
Il risultato indicato da AMD è un incremento di IPC di circa il 20% nella media geometrica di carichi enterprise e cloud, che sale a circa il 31% con carichi di intelligenza artificiale, per un valore medio complessivo attorno al 27%. Si tratta di valori riferiti a scenari a carico ridotto: come ogni dato di questo tipo, l’effettivo incremento dipenderà dal tipo di applicazione e dovrà essere verificato sul campo.
Zen 6 e Zen 6c non presentano differenze nell’ISA, supportano entrambi SMT e appaiono identici al software: le differenze sono nel design fisico, nella frequenza e in alcune dimensioni interne come gli scheduler FP.
Kernel, virtualizzazione e sicurezza nel core
Il lavoro su Zen 6 non riguarda solo le prestazioni. Debutta FRED (Flexible Return and Event Delivery), una nuova interfaccia tra spazio utente e kernel per interrupt, eccezioni e chiamate di sistema, sviluppata in accordo con Intel su richiesta dei partner software. Il meccanismo legacy di x86 era rimasto sostanzialmente invariato dai tempi di AMD64 e i workaround software per i problemi di sicurezza lo avevano reso decisamente macchinoso.
Per la virtualizzazione arriva PML (Page Modification Logging), che traccia le pagine scritte dalle macchine virtuali e semplifica la migrazione a caldo, e PLZA, che cambia automaticamente in hardware la classe di servizio QoS (monitoraggio di cache L3 e banda di memoria) al passaggio tra modalità utente e kernel.
Sul fronte del Confidential Computing, RMPOPT riduce la penalizzazione delle VM non sicure che girano sullo stesso sistema di VM protette con SEV-SNP, rendendo praticabile la coesistenza di VM standard e confidenziali sulla stessa macchina. Si aggiungono l’ottimizzazione del dirty bit per la migrazione a caldo delle VM confidenziali e una protezione SMT migliorata, che consente di sfruttare entrambi i thread del core quando appartengono allo stesso dominio di sicurezza, invece di dover rinunciare a SMT. Per l’analisi delle prestazioni, infine, AMD introduce un Memory Profiler dedicato, separato da IBS, e un meccanismo di buffering dei campioni IBS in memoria con timestamp, che riduce l’overhead e permette frequenze di campionamento più elevate.
Il SoC Venice: chiplet, packaging avanzato e due die di I/O
Dall’architettura del singolo core Zen 6 si passa al SoC, per il quale AMD ha lavorato a bilanciare quattro obiettivi specifici: massimo throughput, migliore rapporto tra prestazioni e TCO, massima efficienza energetica, il tutto con le funzionalità enterprise di sicurezza, gestibilità, isolamento e RAS.
Ogni SoC può ospitare fino a 8 CCD. Con i CCD Zen 6c da 32 core si ottengono 256 core e 512 thread; con i CCD Zen 6 da 12 core si arriva a 96 core e 192 thread. Questi ultimi possono inoltre ospitare uno strato di 3D V-Cache da 96 MB, per un totale di 144 MB di L3 per CCD e 1.152 MB di cache L3 per socket nelle versioni Venice-X che vedremo al debutto dalla seconda metà del 2027. Per la prima volta entrambi i CCD sono prodotti con lo stesso processo, TSMC N2: con Zen 5 e Zen 5c AMD aveva utilizzato processi differenti, un altro segnale di come AMD consideri ora entrambi i core come core per le prestazioni.
Il CCD a 32 core integra in realtà 33 core, uno dei quali ridondante per migliorare le rese produttive. Il core in eccesso, con la relativa porzione di L3, viene sempre disattivato: nessun prodotto lo vedrà mai abilitato, e ogni CCD espone 32 core attivi con 128 MB di L3.
La vera rivoluzione rispetto a Turin è nel collegamento tra CCD e die di I/O. Nelle precedenti generazioni i CCD erano collegati tramite collegamenti Infinity Fabric GMI, SerDes ad alta frequenza su substrato organico che permettevano di posizionare i CCD anche a una certa distanza dal die di I/O. Il prezzo da pagare era però il consumo. Con Venice AMD adotta gli Elevated Fanout Bridge (EFB), interconnessioni die-to-die a bassa latenza, basso consumo ed elevata banda che collocano i CCD a poche centinaia di micron dall’IOD. Il processo è complesso: su un carrier in vetro vengono costruiti i pilastri in rame, quindi posizionato il die bridge, poi lo stampo con gli strati di ridistribuzione (RDL) che portano i segnali ai microbump su cui vengono posati i die attivi.
Perché questa scelta, visto che AMD in passato aveva rinunciato al packaging avanzato nei server per ragioni di costo? Semplice: un miglior bilanciamento dell’energia a disposizione del processore. Un collegamento SerDes su packaging standard richiede alcuni picojoule per bit, pertanto spostare un terabyte al secondo di dati costa circa 8-10 watt. Con le bande in gioco in Venice si sarebbe lasciato sul tavolo circa il 10% del budget energetico complessivo del processore che è invece ritornato disponibile permettendo, in questo modo, di far funzionare 256 core in un SoC da 400 watt.
Datapath e Infinity Fabric di quinta generazione
Le porte SDP (Scalable Data Port) che collegano CCD e IOD mantengono la stessa ampiezza architetturale, 32 byte per ciclo in lettura e 16 byte per ciclo in scrittura, ma AMD sfrutta in modo opportunistico le linee inutilizzate del canale di comando per trasportare traffico di probe response e scritture intensive, raggiungendo sino a 32 e 25 byte per ciclo rispettivamente. Il numero di porte cresce con i core, mantenendo il rapporto di una porta ogni 8 core: 4 porte per il CCD a 32 core, 3 per quello a 12 core.
Il die di I/O è suddiviso in due IOD identici, ruotati di 180 gradi l’uno rispetto all’altro e collegati anch’essi con packaging avanzato. Ogni IOD integra 8 canali DDR5 (ogni canale a 80 bit è suddiviso in due sotto-canali da 40 bit con propri micro-controller UMC), 48 linee PCIe Gen 6 a 64 Gbps con tre controller, oltre a logica di controllo, power management, hub di I/O e microcontrollori di sicurezza. La dimensione dei due IOD è dettata in larga misura dal perimetro necessario per collegare i bridge EFB, i 16 canali di memoria e le linee PCIe 6.0.
L’Infinity Fabric di quinta generazione gestisce arbitraggio, distribuzione e qualità del servizio di un numero molto più elevato di agenti. AMD ha dovuto rivedere anche il probe filter per gestire cache più ampie e la memoria CXL. Un altro elemento importante è il cambio rapido dello stato di potenza del fabric: le transizioni tra modalità a bassa latenza e modalità orientata alla banda avvengono ora senza tempi di blackout, consentendo di usare questa funzione in modo esteso e di destinare più energia ai core.
Con dimensioni del SoC così elevate, la configurazione NUMA assume un ruolo centrale. AMD continua a supportare NPS1, con la memoria interlacciata su tutti i 16 canali e prestazioni più prevedibili, e NPS4, che suddivide il socket in quadranti per carichi altamente paralleli, ma il focus di Venice è la modalità NPS2. Ogni dominio comprende un IOD con i suoi 8 canali, 128 core e oltre 800 GB/s di banda con MRDIMM a 12,8 GT/s: più di quanto offrisse un intero socket Turin.
Le piattaforme: Venice SP7
AMD ha sviluppato differenti versioni di processori EPYC, in base alla specifica destinazione d’utilizzo. La piattaforma di riferimento è basata sul nuovo socket SP7, compatto (76 x 80 mm), di tipo LGA con poco più di 7.500 contatti, necessari per gestire memorie e I/O a velocità più elevate. Il supporto è per 16 canali DDR5 a 1 DIMM per canale, con RDIMM DDR5-8000 o MRDIMM a 12.800 MT/s (MRDIMM Gen2, standard JEDEC): la banda teorica arriva così a PCI Express 6.0 a 64 Gbps per linea: 96 linee in configurazione a singolo socket con 8 linee PCIe 4.0 aggiuntive, sino a 128 linee più 16 PCIe 4.0 in configurazione a due socket. Tutte le linee supportano anche CXL 3.1. Il collegamento tra i due socket utilizza sino a 3 link Infinity Fabric di quinta generazione a 64 Gbps, raddoppiando la banda per linea rispetto alla generazione precedente. I gruppi IRM della piattaforma arrivano a 600 W, con opzioni a consumo inferiore per chi punta all’efficienza.
Venice SP8, per il mercato enterprise
Per il mercato enterprise AMD ha sviluppato una seconda piattaforma, SP8, con un IOD differente e un socket più piccolo (62,5 x 80 mm). È una proposta nata dal confronto con le grandi aziende Fortune 100, che chiedono più equilibrio e migliori prestazioni per ogni dollaro investito nel sistema. I due IOD dell’SP8 integrano ciascuno 4 canali DDR5 e 64 linee PCIe 6.0: il risultato sono 8 canali di memoria con 2 DIMM per canale, 128 linee PCIe 6.0 in configurazione a singolo socket e sino a 192 in configurazione a due socket. Il TDP massimo è di 400 W, con configurazioni da 8 a 128 core Zen 6c (fino a 4 CCD) o sino a 96 core Zen 6.
Verano: memoria LPDDR5X e “memory winglet”
L’ultimo membro della famiglia è Verano, la proposta che a luglio era stata presentata come EPYC 9006 LP. Lo schema costruttivo è lo stesso, con due IOD centrali, ma i CCD possono arrivare sino a 6, per un massimo di 192 core Zen 6c oppure 72 core Zen 6, con le stesse frequenze massime delle versioni SP7 (4,1 e 5,3 GHz). La novità è nella memoria: per la prima volta AMD utilizza dei memory winglet, quattro die di memoria (MCD) collegati con EFB, ciascuno con 6 canali LPDDR5X a 8.533 MT/s. Il totale è di 24 canali LPDDR5X (48 canali a 16 bit, 768 bit complessivi) su moduli SOCAMM2 sostituibili. La piattaforma è la SB1, a singolo socket, con sino a 500 W e fino a 96 linee PCIe 6.0.
Perché i winglet? La piedinatura LPDDR richiede un’uscita lungo un lato più lungo del package: invece di ingrandire gli IOD, AMD ha preferito spostare i controller su die dedicati, sfruttando il collegamento EFB. Secondo la slide AMD i die di calcolo sono prodotti con tecnologia TSMC N2P, mentre Subramony ha precisato che gli IOD restano in TSMC N6.
Verano è stata progettata come head node per le GPU Instinct di prossima generazione, sfruttando il collegamento con la GPU più veloce rispetto a quanto offerto dalle altre versioni di GPU pur con un valore di banda della memoria inferiore. AMD ha optato per questa direzione calcolando il bilanciamento in funzione del rapporto tra la HBM delle GPU e la memoria di sistema, pensando alle caratteristiche tecniche delle proprie GPU per datacenter. Chi utilizza acceleratori di terze parti continuerà invece a preferire Venice SP7 con i suoi 1,6 TB/s. C’è comunque da segnalare come la memoria LP sia ancora nuova in ambito server e presenta compromessi in termini di RAS: alcuni clienti con stack software verticali sono pronti ad adottarla, altri preferiranno restare su DDR5, e la famiglia Venice permette entrambe le strade.
Le tecnologie di piattaforma: PCIe 6.0, CXL 3.1 e SDXI
Con i processori Zen 6 vedremo al debutto importanto novità anche per quanto riguarda la piattaforma nel suo complesso. Sono quattro le aree coinvolte: memoria e I/O, gestione di prestazioni e consumi, RAS e sicurezza.
Il passaggio a PCI Express 6.0 porta con sé la modalità FLIT a 256 byte e la nuova codifica con FEC, oltre al supporto per relaxed ordering e ordinamento basato su ID. Debutta il Precise Time Measurement (PTM), che sincronizza con precisione la base dei tempi tra CPU e dispositivi PCIe, utile ad esempio per applicazioni di rete che richiedono timestamp precisi. Arriva inoltre il supporto a L0p avviato dal dispositivo, che permette di spegnere parte delle linee di un collegamento senza interrompere il traffico. La Direct Cache Injection, già presente in Turin, può ora essere abilitata di default su qualsiasi porta, anche con dispositivi che non supportano TPH.
Con le GPU Instinct MI450X, Venice SP7 in configurazione a singolo socket può offrire 4 collegamenti x16 xGMI a 64 Gbps: le stesse linee possono funzionare come PCIe, CXL o xGMI coerente. Per i sistemi 2P con acceleratori PCIe, i due socket possono essere collegati con un solo link xGMI, lasciando più linee ai dispositivi.
Infine troviamo SDXI, lo standard SNIA per il data mover hardware, che AMD ha arricchito con funzioni di crittografia: oltre ai trasferimenti a circa 100 GB/s per socket (200 GB/s con due engine SDXI), l’acceleratore offre AES-128/256 anche in modalità XTS, SHA e CRC a circa 50 GB/s. Secondo AMD il solo offload di SHA-256 equivale a circa 30 core. L’acceleratore è virtualizzabile via SR-IOV e utilizzabile in modalità utente con memoria virtuale condivisa.
Gestione dei consumi: UPP, UBPS e FAST
AMD ha individuato tre problemi che affliggono gli operatori di data center: la potenza “bloccata” perché si dimensiona l’alimentazione sul caso peggiore (tra il 15% e il 25% della capacità dei rack resta inutilizzata), il consumo elevato anche a basso utilizzo (dal 60% al 70% del picco anche con sistemi poco carichi) e la proliferazione degli SKU, con 2-3 modelli differenti per servire VM premium e VM batch.
Le risposte sono tre e possono essere combinate tra di loro. Unified Power Provisioning (UPP) considera SoC e DIMM come un unico budget energetico, permettendo di recuperare dal 10 al 15% della potenza provisionata e di aggiungere uno o due server per ogni rack da 35 kW. Utilization Based Power Scaling (UBPS) fa scalare la potenza con il numero di core attivi, al posto del classico power capping statico. FAST (Frequency Adaptive Spectrum Technology) permette di assegnare frequenze minime a gruppi di core, ottenendo più livelli di servizio con un unico SKU fisico. Secondo Ravi Kuppuswamy, UPP porta il vantaggio di Venice in termini di agenti per watt da 2,8x a 3,3x rispetto alla concorrenza.
RAS e sicurezza
Per il RAS, oltre al supporto alle novità di PCIe 6.0 e al recupero dei dispositivi CXL, la novità più significativa è MP RAS: un microcontrollore dedicato a cui viene affidata la gestione degli errori fino a ora eseguita tramite SMI e codice SMM. È il primo passo verso l’eliminazione delle SMI, con benefici in termini di latenza prevedibile e di sicurezza; in futuro AMD prevede API, in collaborazione con OCP, per consentire ai clienti di inserire codice proprio.
La sicurezza è uno dei temi che caratterizza le nuove soluzioni Venice di AMD. La piattaforma integra un root of trust con supporto RSA 4K e crittografia post-quantistica (PQC), il root of trust open source Caliptra 1.2, l’intero spettro SEV, SEV-SNP e SEV-TIO per includere i dispositivi PCIe nell’ambiente di esecuzione fidato, la crittografia dei collegamenti PCIe IDE anche in modalità standalone, il ciphertext hiding e, novità assoluta, la device provenance. Si tratta di una catena di attestazione crittografica che traccia il processore lungo tutto il ciclo produttivo, consentendo di verificare di utilizzare un componente AMD autentico. Gli audit OCP S.A.F.E. dell’intero stack vengono pubblicati su GitHub.
La memoria: il costo più pesante per i server moderni
Se c’è un tema ricorrente nelle discussioni incentrate sui datacenter è quello della memoria: se ne parla per il costo, esploso nel corso degli ultimi anni, oltre che per la disponibilità. Con 256 core per socket e 16 canali DDR5, il costo della DRAM rischia di diventare la voce dominante in un server: parliamo di un’incidenza che parte dal 60-70% sino all’80-90% del costo complessivo nei sistemi con grandi quantitativi di memoria.
AMD affronta il problema su più livelli, proponendo una tecnologia per ogni esigenza:
- DDR5 MRDIMM Gen2 per i carichi limitati dalla banda in cloud, IA e HPC: bandwidth della memoria di 12.800 MT/s, 16 canali memoria su SP7, banda massima teorica a disposizione sino a 1,6 TB/s.
- DDR5 RDIMM per il mainstream: DDR5-8000, circa 1 TB/s di banda su SP7, sino a 8 TB per socket.
- LPDDR5X SOCAMM2 su Verano, per densità ed efficienza: sino a circa 0,8 TB/s, sino a 1,5 TB per socket e un consumo inferiore del 30-40% rispetto a DDR5 a parità di banda; i moduli sono già pronti per il raffreddamento a liquido diretto.
- CXL 3.1 per capacità e costo su larga scala: ogni collegamento x16 offre sino a circa 128 GB/s con la latenza di un salto NUMA.
- MEXT per un’infrastruttura efficiente in termini di TCO.
CXL 3.1: riutilizzare la DRAM esistente
Venice è la terza generazione di CPU EPYC con supporto CXL, ora alla versione 3.1. Tutte le 96 linee (128 su SP8) possono funzionare come PCIe o come CXL senza configurazione preventiva: il dispositivo viene rilevato automaticamente al momento del collegamento. L’utilizzo che AMD suggerisce in questa fase di prezzi elevati è il recupero delle DRAM delle generazioni precedenti, ad esempio moduli DDR4, collocati dietro un controller CXL per espandere la capacità: secondo AMD si può ottenere un costo per GB inferiore dell’87% rispetto a DDR5, senza modifiche alle applicazioni.
La memoria CXL può essere usata con tiering software, sfruttando gli sviluppi del kernel Linux per il posizionamento delle pagine, con interleaving software per aumentare la banda, oppure semplicemente per aumentare la capacità. AMD aggiunge due funzioni proprietarie: il tiering accelerato via SDXI e soprattutto un meccanismo di QoS sulla banda, che evita che il traffico verso la memoria CXL penalizzi i carichi serviti dalla DDR5.
AMD MEXT: la flash che si comporta come DRAM
La novità principale portata da AMD per quanto riguarda le memorie nei datacenter è MEXT, startup acquisita da AMD nel mese di giugno. Questa tecnologia vuole dare una risposta concreta alla problematica legata al costo della memoria e al suo utilizzo ideale.
Se il tema dei prezzi delle memorie è chiaro, meno lo è quello del corretto utilizzo. Studi pubblicati da Microsoft Azure e Meta indicano che metà delle macchine virtuali non accede mai a metà della memoria assegnata, che circa il 25% della DRAM resta inutilizzata perché “bloccata” e che tra il 50% e l’80% delle pagine di memoria nelle applicazioni più ottimizzate non viene toccata per 5, 10 minuti o anche più.
L’idea di MEXT è portare la memoria flash nel dominio della memoria di sistema: la NAND costa 50 volte meno per bit e consuma 30 volte meno della DRAM, ma è anche 500 volte più lenta. Il trucco è usare l’intelligenza artificiale per nascondere la latenza: le pagine fredde vengono spostate sulla flash senza alcun impatto, perché non vengono utilizzate, mentre un motore predittivo riporta in DRAM le pagine che saranno necessarie prima che l’applicazione le richieda. Per sistema operativo e applicazioni la memoria è semplicemente tutta lì: MEXT “fa apparire la flash come DRAM”.
La soluzione è interamente software e si compone di tre elementi: un driver Linux leggero, un motore AI che opera in spazio utente e RAM View, uno strumento di osservabilità opzionale e gratuito per gli utenti EPYC. Il motore è un insieme di modelli, tra i quali uno derivato dai transformer: invece di predire la parola successiva predice la prossima pagina di memoria necessaria, con il vantaggio di non dover rispettare l’ordine esatto, purché le pagine arrivino in tempo. L’addestramento è continuo e in tempo reale, richiede meno di un secondo su un singolo core EPYC, senza GPU, e si adatta ai cambi di fase dell’applicazione. Con latenze della flash di 50-60 microsecondi on-premise (anche il doppio nel cloud), il motore punta a predire con un anticipo di circa 150 microsecondi per tenere conto anche delle latenze P99 e P99.9.
AMD raccomanda un over-provisioning 2x della flash (2 TB di NVMe per ogni TB di memoria aggiunta), le scritture sono sempre sequenziali con un write amplification pari a 1, a tutto vantaggio della durata delle unità, e la metrica più importante dell’SSD è la latenza di lettura casuale. In ambiente virtualizzato MEXT richiede un core per ogni guest. La componente MEXT è a pagamento, distribuita tramite il canale, ed è proprietaria delle piattaforme EPYC.
I risultati: metà DRAM, prestazioni quasi invariate
Sono due i modi di usare MEXT: ce ne si può servire per ridurre la DRAM installata a parità di capacità, ad esempio 1 TB di DRAM più 1 TB di MEXT al posto di 2 TB di DRAM, con il vantaggio aggiuntivo di poter usare moduli da 128 GB, che costano molto meno della metà di quelli da 256 GB. L’uso alternativo è quello di espandere la memoria di un sistema esistente sino a 3 volte, a un costo molto inferiore rispetto all’aggiunta di moduli DRAM.
I dati mostrati da AMD su piattaforme Venice sono molto incoraggianti e testimoniano un ridotto impatto prestazionale a fronte di una forte riduzione di costo:
- Agentic AI: con 50% di DRAM e 50% di MEXT, il geomean di cinque agenti concorrenti mantiene il 99% delle prestazioni (1,9x di prestazioni per dollaro di DRAM); l’agente più affamato di memoria si ferma al 90%. Con solo il 25% di DRAM si scende all’85-88%, ma le prestazioni per dollaro di DRAM salgono a 3,4-3,5x.
- EDA (Synopsys PrimeTime): con la DRAM dimezzata si mantiene il 95% delle prestazioni, con il 62,5% di DRAM in meno il 90%, con il 75% in meno l’80%.
- Spark TPC-DS su Azure (EPYC di quinta generazione): stesso cluster a 3 nodi con metà DRAM, 99% delle prestazioni.
- EDA su Azure HX: raddoppiando la memoria effettiva da 1,4 a 2,6 TB, quattro job PrimeTime girano in parallelo in 6,6 ore invece di 9,3, con 1,4x di throughput sullo stesso hardware.
C’è poi il caso dell’IT interno di AMD, che aveva necessità di espandere la memoria dei server per i carichi EDA. L’alternativa era acquistare moduli da 256 GB a 15.500 dollari ciascuno, oltre 50 dollari per GB. Con MEXT, sulle prime 145 macchine, AMD stima di aver evitato 4,9 milioni di dollari di costi di DRAM, con un risparmio dell’83% rispetto all’alternativa tutta DRAM; il deployment è previsto in crescita sino a 2.000 server nel 2027. Sul fronte dei partner, la prima collaborazione è con HPE: oggi con server “MEXT ready” (EPYC con abbondanza di core e slot NVMe disponibili), successivamente con licenze MEXT e RAM View preinstallati.
Helion, l’infrastruttura rack per i sistemi Venice
A livello di sistema AMD propone Helion, framework di rack aperto per carichi agentici presentato a ottobre all’OCP Summit, basato su rack ORv3 da 21 pollici e declinato in tre versioni:
- Helion Liquid, raffreddato a liquido, con sino a 36.864 core Zen 6 in un rack da 48 OU (32.768 nella versione da 44 OU) e oltre 73.000 agenti in circa 120 kW.
- Helion Air, raffreddato ad aria, con sino a 16.384 core usando CPU da 400 W (8.192 con CPU da 600 W) e oltre 32.000 agenti in circa 60 kW.
- Helion Air Inference, che combina 24 vassoi CPU (12.288 core) e sino a 16 GPU Instinct MI350P nello stesso rack, per 74 PetaFLOPS in FP4.
AMD ha anche confrontato la densità di Helion Liquid con quella delle alternative: 73.728 thread per rack contro i 36.864 di un rack con Xeon “Clearwater Forest” a 288 core, i 20.672 di ARM AGI a 136 core e i 45.056 di un rack MGX con NVIDIA Vera a 88 core.
Disponibilità e roadmap dei processori EPYC
Le CPU Venice SP7 sono in produzione dal trimestre scorso e le prime piattaforme sono già in consegna. Venice SP8 arriverà nella prima metà del 2027, mentre Venice-X e Verano sono attese nella seconda metà del 2027. Rispetto a quanto comunicato a luglio, segnaliamo due aggiornamenti: la frequenza massima dei core Zen 6 sale a 5,3 GHz (contro i 5 GHz indicati a luglio), anche per Venice-X, e Verano viene ora proposta anche in versione a 192 core Zen 6c oltre a quella da 72 core Zen 6.
Per il futuro AMD conferma la cadenza: la settima generazione si chiamerà Florence, con un nuovo processo produttivo, le ACE (AI Compute Extensions) e la nuova generazione di memorie MRDIMM e LPDDR; l’ottava sarà Ravenna. Anche Helion verrà declinato su ogni nuova generazione di CPU: Helion Gen 2 con Florence e Helion Gen 3 con Ravenna, entro il 2030.
Le CPU sono ancora importanti
Venice rappresenta un cambio di passo significativo per le CPU EPYC, e non solo per i numeri: 256 core, 1,6 TB/s di banda di memoria e PCIe 6.0 sono risultati importanti, ma il dato architetturale più interessante è forse la trasformazione di Zen 6c da core “denso” a core per le prestazioni, con 4 MB di cache L3 per core e un CCX da 32 core e 128 MB di L3. A questo si aggiunge l’adozione del packaging avanzato EFB tra CCD e IOD, una scelta che AMD aveva evitato nei server per ragioni di costo e che ora considera indispensabile per contenere il consumo del resto del chip.
Altrettanto interessante è l’approccio alla memoria. Con la DRAM che non scala più e prezzi saliti a livelli mai visti, AMD non si limita a offrire più canali e moduli più veloci, ma propone un ventaglio di soluzioni che va da LPDDR5X a CXL 3.1 sino al software MEXT. I risultati mostrati sono promettenti, con prestazioni attorno al 95-99% dimezzando la DRAM in molti scenari, ma andranno verificati su un ventaglio più ampio di applicazioni, specialmente quelle con accessi alla memoria meno prevedibili.
Resta il fatto che oggi il costo di un server non si misura più solo in base al prezzo della CPU, e che il rapporto tra prestazioni e TCO, come ha ricordato più volte AMD, dipende tanto dal numeratore quanto dal denominatore. Venice prova a lavorare su entrambi: vedremo nei prossimi mesi, con le prime piattaforme sul mercato, quanto di questa promessa si tradurrà in risultati concreti.
Il lancio delle soluzioni Venice conferma però quello che sembra essere un trend ben consolidato: nei datacenter, pur con l’attenzione spasmodica verso le componenti GPU degli ultimi anni, le CPU rimangono fondamentali e la loro importanza è addirittura aumentata visto lo spostamento verso utilizzi di Intelligenza Artificiale agentica da parte di un numero sempre più ampio di utenti.