Analisi SemiAnalysis 4-hi HBM: perché stack più corti potrebbero vincere nell'inferenza AI

SemiAnalysis ha contestato la corsa al rialzo dell'industria della memoria per l'AI, sostenendo che HBM 4-hi possa offrire la piena larghezza di banda usando un terzo dei die DRAM.

L'affermazione è rilevante perché i produttori di acceleratori hanno trascorso anni ad aggiungere stack di memoria più alti. Più livelli hanno aumentato la capacità, supportato modelli più grandi e contribuito a rendere la memoria ad alta larghezza di banda una componente essenziale del calcolo AI.

L'analisi SemiAnalysis 4-hi HBM afferma che l'inferenza cambia ora questo calcolo. I sistemi su scala rack offrono una maggiore capacità aggregata, mentre la quantizzazione e l'offload della cache riducono la quantità che ciascuna GPU deve contenere.

Il rapporto non afferma che ogni carico di lavoro richieda meno memoria. L'addestramento, batch di grandi dimensioni e i modelli futuri possono ancora favorire stack più alti. La sua argomentazione più incisiva riguarda l'inferenza interattiva, dove la larghezza di banda spesso limita la generazione di token prima che la capacità diventi scarsa.

Questo crea un confronto diretto tra due priorità progettuali. Una privilegia la massima capacità di memoria per acceleratore. L'altra privilegia la massima larghezza di banda in token ottenibile da ogni wafer DRAM vincolato.

La riduzione di memoria riportata per Rubin Ultra di Nvidia fornisce il segnale immediato. SemiAnalysis afferma che l'acceleratore avrà 192GB di HBM, in calo rispetto ai 288GB di Rubin standard e Blackwell Ultra.

L'azienda non ha descritto pubblicamente una configurazione Rubin Ultra 4-hi. Tuttavia, il passaggio riportato verso stack 8-hi suggerisce che HBM sempre più alta non sia più una scelta automatica.

Se questo ragionamento si estendesse a HBM4E 4-hi, l'infrastruttura AI potrebbe usare meno die DRAM senza sacrificare la larghezza di banda esterna di ciascuno stack. Ciò ridurrebbe i costi della memoria e produrrebbe più package HBM utilizzabili da una disponibilità limitata di wafer.

La roadmap della memoria di Nvidia non si muove più in una sola direzione

Il cambiamento significativo non è che Nvidia abbia improvvisamente bisogno di poca memoria. È che la capacità aggiuntiva non sembra più preziosa a qualunque costo.

Blackwell Ultra ha definito chiaramente la direzione dell'alta capacità. Nvidia indica 288GB di HBM3E per GPU Blackwell Ultra e 20TB nell'intero rack GB300 NVL72.

Le specifiche GB300 dell'azienda indicano inoltre una larghezza di banda aggregata della memoria GPU fino a 576TB al secondo. Queste cifre mostrano perché Nvidia in precedenza enfatizzasse sia la capacità sia la larghezza di banda.

SemiAnalysis ora riporta che Rubin Ultra invertirà parte di questa tendenza. I suoi previsti 192GB per GPU rappresentano una riduzione di un terzo rispetto a Blackwell Ultra e Rubin convenzionale.

Il confronto richiede una certa cautela. L'architettura di Rubin Ultra sarebbe cambiata da quattro die di calcolo a due. La precedente capacità di memoria attesa apparteneva quindi a un diverso progetto di sistema.

Anche normalizzando per questo cambiamento, SemiAnalysis stima che la memoria scenda dai precedenti 256GB per die di calcolo a 96GB. Si tratta di un sostanziale riassetto architetturale, non di un ritocco cosmetico alle specifiche.

Il rapporto identifica l'offerta come una delle ragioni. Nvidia avrebbe assicurato una significativa capacità di logica avanzata e packaging, ma i wafer HBM disponibili non possono sostenere volumi equivalenti di stack 12-hi.

Uno stack 12-hi contiene dodici die DRAM core sopra il suo die base. Uno stack 8-hi ne usa otto, consentendo alla stessa offerta di DRAM lavorata di supportare più stack finiti.

Questo conta perché HBM consuma più capacità produttiva per bit rispetto alla DRAM convenzionale. Le via attraverso il silicio, note come TSV, trasportano segnali e alimentazione verticalmente attraverso lo stack di memoria.

Queste TSV richiedono lavorazioni aggiuntive. I die HBM includono inoltre area per le connessioni verticali, riducendo la densità di bit rispetto alla memoria ordinaria prodotta con un processo analogo.

SemiAnalysis aveva precedentemente stimato che HBM consumasse circa tre volte più capacità di wafer per bit rispetto alla DRAM commodity. La sua stima si avvicina a quattro volte con il passaggio della produzione verso HBM4.

Questa cifra è una stima di analisti, non uno standard di settore. Tuttavia, l'onere produttivo sottostante è ben consolidato presso i fornitori di memoria.

SK hynix, Samsung e Micron devono lavorare, assottigliare, connettere, testare e confezionare più die noti come funzionanti. Ogni livello aggiuntivo aumenta l'uso di materiali ed espone il package a ulteriori rischi di resa.

Storicamente gli stack più alti hanno giustificato questo onere perché gli acceleratori necessitavano della loro capacità. Pesi dei modelli, attivazioni, gradienti, stati dell'ottimizzatore e cache chiave-valore competono tutti per la memoria in diversi carichi di lavoro.

La nuova decisione suggerisce che la capacità abbia superato una soglia per alcuni sistemi di inferenza. Una volta che un rack contiene il working set necessario, aggiungere memoria a ogni GPU produce meno valore.

Nvidia non ha confermato pubblicamente l'esatta suddivisione della capacità di Rubin Ultra indicata da SemiAnalysis. L'affermazione dovrebbe pertanto rimanere un cambiamento di roadmap riportato, non una specifica di prodotto finalizzata.

Ciononostante, le preparazioni della catena di fornitura possono rivelare una direzione prima di un lancio pubblico. SemiAnalysis afferma che i fornitori si stanno preparando affinché le configurazioni 8-hi diventino standard dopo una spinta del settore verso prodotti 12-hi e 16-hi.

Il cambiamento riportato apre la strada a HBM 4-hi. Se otto livelli sono sufficienti, i progettisti devono chiedersi se quattro livelli possano servire determinate implementazioni di inferenza in modo più economico.

Questa domanda sarebbe sembrata controcorrente durante la recente corsa alla capacità. In presenza di gravi vincoli DRAM, diventa una delle scelte architetturali più pratiche del settore.

SemiAnalysis 4-hi HBM mantiene la larghezza di banda eliminando die

Uno stack HBM più corto riduce la capacità, ma non riduce automaticamente la larghezza di banda esterna del package.

HBM trasferisce i dati attraverso un'interfaccia molto ampia, invece di fare affidamento soltanto su velocità di segnalazione estreme. HBM4 espande tale interfaccia a 2.048 connessioni dati per stack.

Lo standard HBM4 è stato pubblicato da JEDEC nell'aprile 2025. Definisce le fondamenta per una nuova generazione di memoria per AI e calcolo ad alte prestazioni.

Secondo SemiAnalysis, ciascun die DRAM HBM4 può accedere fino a 512 delle connessioni dati dello stack. Quattro die possono quindi popolare tutte le 2.048 connessioni.

L'aggiunta dal quinto al dodicesimo die aumenta la capacità. Non amplia l'interfaccia esterna oltre quelle 2.048 connessioni.

I pin disponibili sono suddivisi tra più livelli di memoria in uno stack più alto. Lo stack presenta comunque la stessa interfaccia complessiva all'acceleratore.

Questo è il meccanismo centrale alla base dell'argomentazione a favore degli stack corti. Un package 4-hi, 8-hi e 12-hi può offrire una larghezza di banda nominale comparabile quando usa la stessa generazione e velocità di segnalazione.

Le loro capacità differiscono nettamente. SemiAnalysis modella die core HBM4E da 32 gigabit, ottenendo 16GB per 4-hi, 32GB per 8-hi e 48GB per 12-hi.

Si tratta di configurazioni future modellate, non di prodotti retail generalmente disponibili. Illustrano come il numero di livelli modifichi la capacità lasciando intatta l'interfaccia del package.

La distinzione economica deriva da ciò che i fornitori consumano. Il contenuto DRAM determina gran parte del costo di uno stack HBM, mentre i clienti dell'inferenza spesso attribuiscono valore alla larghezza di banda che alimenta i loro acceleratori.

Un acquirente di 4-hi ottiene meno gigabyte. Può comunque ricevere il percorso dati necessario a mantenere alimentate le unità di calcolo.

Questo cambia la misura di efficienza rilevante. L'approvvigionamento focalizzato sulla capacità chiede quanti gigabyte entrino accanto a ciascun acceleratore. Quello focalizzato sulla larghezza di banda chiede quanti token possano supportare quei collegamenti di memoria.

Per l'inferenza, la seconda domanda può dominare. La decodifica autoregressiva genera l'output in sequenza, e ogni passaggio deve leggere dalla memoria i pesi attivi del modello.

Il processo spesso esegue relativamente poca aritmetica per ogni byte trasferito. Ciò rende la decodifica vincolata dalla larghezza di banda della memoria, il che significa che la consegna dei dati limita il throughput prima del calcolo puro.

Uno stack più alto aiuta soltanto quando il carico di lavoro usa la sua capacità aggiuntiva. Altrimenti, i die extra contengono informazioni che la larghezza di banda disponibile non può leggere con frequenza sufficiente.

SemiAnalysis fornisce una larghezza di banda HBM4E esemplificativa di 3.328GB al secondo per stack. Deriva questo numero da 2.048 pin operanti a 13 gigabit al secondo.

A 100 token generati al secondo, ciò rappresenta 33,28GB di larghezza di banda teorica per ciascun token. Il working set utile non può superare questo budget se ogni token deve leggerlo una volta.

Uno stack da 48GB conterrebbe quindi più dati di quanti la larghezza di banda teorica possa scansionare per token. Parte della capacità resterebbe inutilizzabile per quel particolare carico di lavoro a quella velocità.

I sistemi reali non mantengono mai ogni unità della larghezza di banda nominale. Overhead di protocollo, schemi di accesso, comunicazione e comportamento del software riducono il throughput effettivo.

Questa limitazione può rafforzare il caso degli stack corti. Una minore larghezza di banda utilizzabile significa che il carico di lavoro raggiunge il proprio limite di banda prima di poter sfruttare tutta la capacità installata.

L'HBM 4-hi spiegata da questo meccanismo non è semplicemente memoria meno costosa. È una configurazione che separa la larghezza di banda esterna dalla massima densità verticale.

La distinzione influenza anche l'output produttivo. Un wafer usato per stack a quattro livelli può teoricamente supportare tre volte più package di uno usato per stack a 12 livelli.

I guadagni effettivi dipendono da rese, disponibilità dei die base, test e throughput del packaging. Gli stack più corti dovrebbero inoltre evitare alcune perdite cumulative di assemblaggio associate a livelli aggiuntivi.

SemiAnalysis sostiene che la conseguente larghezza di banda per wafer HBM conti quanto i token per watt. Entrambe le metriche misurano l'output AI utile rispetto a una risorsa che non può espandersi rapidamente.

Perché l'inferenza attribuisce più valore alla larghezza di banda che alla capacità massima

L'inferenza interattiva premia la memoria che può alimentare rapidamente il processore, mentre la capacità inutilizzata contribuisce poco al throughput dei token.

Addestramento e inferenza impongono requisiti diversi a HBM. L'addestramento conserva pesi, attivazioni, gradienti e dati dell'ottimizzatore mentre elabora grandi batch tramite passaggi forward e backward.

Questo carico di lavoro può consumare un'enorme capacità. Esegue inoltre abbastanza calcoli da diventare vincolato dal calcolo durante molte operazioni.

La decodifica dell'inferenza è diversa. Il sistema legge ripetutamente i pesi attivi e la cache chiave-valore dell'utente, o KV cache, mentre produce un token dopo l'altro.

La KV cache conserva informazioni di attenzione relative ai token precedenti. Impedisce al modello di ricalcolare l'intera conversazione ogni volta che genera un altro token.

Più utenti e contesti più lunghi ingrandiscono questa cache. Tuttavia, una capacità maggiore è preziosa solo se il sistema può servire quegli utenti entro un obiettivo di latenza accettabile.

Il batching complica il quadro. Elaborando insieme più richieste, un server può ripartire una singola lettura dei pesi del modello tra più utenti.

Batch più grandi migliorano il throughput totale, ma richiedono anche più capacità per la KV cache. È qui che gli stack 8-hi o 12-hi possono recuperare un vantaggio.

Il compromesso è l'interattività. Un fornitore può attendere più a lungo per formare batch più grandi, oppure può restituire token rapidamente con batch più piccoli.

SemiAnalysis modella questa relazione usando Kimi K3 su una futura configurazione Rubin Ultra NVL576. Rileva che gli stack più alti offrono guadagni di throughput decrescenti all'aumentare della velocità richiesta per utente.

A un valore modellato di 213 token al secondo per ciascun utente, il rapporto non rileva alcun vantaggio di throughput oltre 4-hi. Il limite di larghezza di banda arriva prima che la capacità di memoria aggiuntiva diventi utile.

In altri punti della curva, 8-hi aumenta il throughput massimo dell'8 percento. Una configurazione 12-hi lo aumenta del 10 percento rispetto a 4-hi.

Quei miglioramenti sono reali all’interno del modello. La questione è se compensino il costo aggiuntivo in termini di memoria e sistema.

SemiAnalysis stima che il suo sistema Rubin Ultra 8-hi modellato costi il 12,1 percento in più rispetto alla base 4-hi. La sua configurazione 12-hi aggiunge il 26,3 percento.

Si tratta di stime degli analisti basate su componenti futuri e prezzi della memoria presunti. Non sono preventivi dei fornitori né costi di proprietà misurati di sistemi Rubin Ultra installati.

All’interno di queste ipotesi, il throughput cresce più lentamente del costo del sistema. Il costo risultante per token è più elevato per entrambe le configurazioni più alte.

Questa è l’affermazione più forte nel caso HBM 4-hi di SemiAnalysis. Stack più corti non si limitano a ridurre il conto dell’hardware; migliorano l’output modellato per unità di spesa.

Il calcolo su scala rack rende l’argomento più plausibile. I server precedenti collegavano otto GPU, quindi la memoria su ciascun dispositivo limitava fortemente l’intero sistema di serving.

Un sistema H100 HGX forniva 640GB di HBM aggregata. I pesi dei modelli di grandi dimensioni potevano occupare la maggior parte di quella capacità prima che il sistema memorizzasse una cache KV sostanziale.

L’H200 ha alleviato tale pressione aggiungendo memoria a ogni GPU. In quella fase, una maggiore capacità per dispositivo aveva un valore operativo immediato.

GB300 NVL72 cambia la scala. Nvidia collega 72 GPU Blackwell Ultra tramite NVLink, creando un dominio di comunicazione condiviso molto più grande.

Il rack dispone di circa 20TB di memoria GPU. La sua capacità aggregata è di gran lunga superiore a quella di un server Hopper a otto GPU.

SemiAnalysis confronta questa crescita con Kimi K3, un modello mixture-of-experts da 2,8 trilioni di parametri. Questi modelli attivano solo un sottoinsieme dei propri esperti per ciascun token.

Il rapporto stima che una replica quantizzata di Kimi K3 occupi 1.561GB. Consumerebbe meno dell’8 percento di una configurazione GB300 NVL72 di circa 21TB.

La quantizzazione rappresenta i numeri con meno bit, riducendo l’archiviazione dei pesi e il traffico di memoria. Scambia una parte della precisione numerica con requisiti hardware sostanzialmente inferiori.

I grandi domini NVLink distribuiscono inoltre gli esperti su più GPU. Questa disposizione aumenta le esigenze di comunicazione ma riduce il numero di pesi del modello che ciascun dispositivo deve contenere.

Secondo quanto riportato, Rubin Ultra espande il dominio da NVL72 a NVL576. Tale aumento di otto volte delle GPU connesse può compensare una riduzione di un terzo della HBM per acceleratore.

La capacità passa quindi da un problema della singola GPU a un problema di allocazione a livello di rack. Un’implementazione può contenere un modello di grandi dimensioni usando stack di memoria locale più sottili.

Questo non elimina i vincoli di memoria. Cambia il punto in cui gli architetti li risolvono e quale risorsa diventa scarsa per prima.

L’offloading della cache aiuta, ma HBM 4-hi non è una soluzione gratuita

La strategia degli stack corti funziona solo quando software, memoria secondaria e comportamento del carico di lavoro impediscono che la ridotta capacità HBM diventi il collo di bottiglia.

SemiAnalysis ha testato parte di questa ipotesi con un carico di lavoro InferenceX che usa Kimi K3 e 16 GPU GB300. Otto GPU gestivano il prefill, mentre otto gestivano il decode.

Il prefill elabora il prompt prima che inizi la generazione dei token. Separarlo dal decode consente agli operatori di ottimizzare ciascuna fase per comportamenti diversi di calcolo e memoria.

L’esperimento ha ridotto l’utilizzo HBM consentito dal 92 percento all’85 percento. Si tratta di un taglio molto più piccolo rispetto alla differenza di capacità tra stack 8-hi e 4-hi.

Tuttavia, il limite ha ridotto sostanzialmente lo spazio disponibile per la cache KV. Secondo il rapporto, la capacità KV di serving aggregato è scesa da 53GB a 34GB per GPU.

Per le coppie disaggregate, il budget disponibile è sceso da 44GB a 24GB. Questi cambiamenti rappresentavano riduzioni del 36 percento e del 44 percento.

Il throughput è rimasto simile nella maggior parte dei livelli di concorrenza testati. La configurazione limitata ha spostato nella normale DRAM del server i dati inattivi della cache KV.

Questo processo è chiamato KV-cache offloading. Mantiene in HBM le informazioni a cui si accede frequentemente, spostando al contempo lo stato delle conversazioni meno attivo in una memoria più lenta ma più capiente.

I carichi di lavoro agentici possono essere adatti a questo approccio. Spesso si interrompono mentre vengono eseguiti strumenti, le CPU eseguono codice o servizi esterni restituiscono informazioni.

Durante queste pause, la GPU non necessita immediatamente della cache di ogni conversazione. Spostare i dati meno attivi può liberare HBM costosa per le richieste attive.

Il test limitato ha incontrato un chiaro limite. Quando la concorrenza ha superato 70, il throughput è sceso di quasi il 30 percento rispetto alla configurazione con più memoria.

L’occupazione KV della GPU aveva raggiunto il 100 percento. Preemption, trasferimenti ripetuti e accodamento hanno quindi ridotto il lavoro utile.

L’esecuzione vincolata ha inoltre registrato oltre dieci volte più letture dalla cache KV basata su DRAM. L’offloading ha alleviato la pressione sulla capacità, ma ha aumentato il traffico attraverso un livello più lento.

Questo risultato è al tempo stesso favorevole e prudenziale. Mostra che il software può preservare le prestazioni dopo una significativa riduzione della memoria, ma solo al di sotto di una soglia dipendente dal carico di lavoro.

Un servizio di produzione con molti utenti simultanei e contesto esteso può superare quella soglia. In quel caso, stack HBM più alti possono supportare batch più grandi e un throughput totale superiore.

Anche la capacità di rete conta. Distribuire esperti e cache dei modelli su centinaia di acceleratori crea una comunicazione all-to-all intensa.

Un sistema può smettere di essere vincolato dalla capacità della memoria e diventare invece vincolato dalla rete. Tale esito lascia comunque inutilizzata HBM aggiuntiva, ma non garantisce prestazioni complessive efficienti.

La DRAM secondaria presenta un altro vincolo. La memoria dei server sta subendo una propria pressione sull’offerta, mentre i sistemi AI aumentano la capacità lato CPU.

L’offloading consuma inoltre energia e aggiunge complessità operativa. Il software deve decidere cosa rimane caldo, cosa viene spostato e quando i dati devono tornare.

Decisioni errate possono trasformare il risparmio di capacità in picchi di latenza. L’architettura richiede una pianificazione accurata, gestione della cache e isolamento dei carichi di lavoro.

La crescita futura dei modelli rappresenta l’incertezza maggiore. SemiAnalysis riconosce che la sua analisi applica un carico di lavoro attuale a hardware previsto in futuro.

I server AI restano spesso installati per oltre cinque anni. Modelli, contesti, concorrenza degli utenti e carichi di lavoro di ragionamento possono cambiare drasticamente in quel periodo.

Il rapporto sottopone a stress test un modello tre volte più grande di Kimi K3 e con un requisito di cache per utente triplo. Gli stack più alti diventano più utili con questa ipotesi.

La sua configurazione 8-hi offre il 36 percento di token totali in più rispetto alla 4-hi. La versione 12-hi offre il 47 percento in più, sebbene entrambe operino a una velocità inferiore per utente.

Dopo aver incluso i costi stimati, la 8-hi diventa favorevole al di sotto di 180 token al secondo per utente. Il sistema 12-hi non riesce ancora a compensare il suo aumento di costo modellato.

Questi risultati dimostrano perché HBM 4-hi non può diventare una prescrizione universale. L’altezza di stack preferibile dipende dalle dimensioni del modello, dagli obiettivi di latenza, dal batching e dalla durata del sistema.

I sistemi di addestramento restano un obiettivo particolarmente inadatto a una riduzione aggressiva della capacità. Le loro attivazioni, i gradienti e gli stati dell’ottimizzatore possono usare tutta la memoria disponibile.

Anche i sistemi di inferenza che servono molti modelli indipendenti necessitano di capacità. Gli operatori possono attribuire più valore alla flessibilità che al costo più basso per un singolo carico di lavoro ottimizzato.

Gli acquirenti di hardware affrontano un problema di optionalità. Un acceleratore 4-hi può essere efficiente per il servizio odierno ma restrittivo dopo il cambiamento dei carichi di lavoro.

I ricercatori potrebbero adattare i modelli all’hardware installato. Calcolo iterativo, quantizzazione, esperti sparsi e cache più piccole possono ridurre la dipendenza dai parametri memorizzati.

Questo adattamento non è garantito. I miglioramenti della qualità dei modelli potrebbero tornare a derivare da un maggior numero di parametri o da architetture a uso intensivo di memoria.

La lettura migliore è quindi più circoscritta. HBM a quattro strati offre una configurazione solida per inferenza attentamente caratterizzata, non una sostituzione automatica della memoria più alta.

Meno strati aumentano la pressione sui fornitori di memoria e sugli integratori di sistemi

Se gli acquirenti ottimizzano la larghezza di banda anziché i gigabyte, la pressione economica si sposta dalla produzione DRAM verso die base, packaging, networking e integrazione completa del sistema.

SK hynix, Samsung e Micron hanno trascorso anni a sviluppare HBM più dense e più alte. Le loro roadmap enfatizzano capacità, velocità di segnalazione, resa del packaging e controllo termico.

SK hynix ha iniziato a fornire campioni di HBM4 a 12 strati nel 2025. Il suo annuncio HBM4 descriveva package da 36GB con oltre 2TB al secondo di larghezza di banda.

Questa direzione di prodotto rimane utile per l’addestramento e l’inferenza ad alta intensità di capacità. Un passaggio significativo verso 4-hi introdurrebbe una priorità di acquisto molto diversa.

I clienti potrebbero richiedere la piena larghezza di banda dell’interfaccia con meno die core. I fornitori spedirebbero più package ma meno bit DRAM al loro interno.

A prima vista, questo appare negativo per i ricavi HBM. I fornitori hanno beneficiato della vendita di una maggiore quantità di DRAM specializzata in ogni generazione di acceleratori.

SemiAnalysis sostiene che l’esito potrebbe essere più equilibrato. Stack più corti potrebbero migliorare le rese di assemblaggio e aumentare il numero di package vendibili prodotti da ciascun wafer.

Un fornitore potrebbe anche far pagare il valore della larghezza di banda invece di trattare HBM principalmente come un prodotto in gigabyte. Resta incerto se i clienti accetteranno tale modello.

Il beneficio per l’offerta è più chiaro. Passare da 12-hi a 4-hi triplica teoricamente il numero di gruppi di die dimensionati per stack disponibili a partire da una quantità fissa di DRAM.

L’aumento effettivo può superare il semplice rapporto se stack più corti aumentano la resa del packaging. Scenderà al di sotto di quel rapporto quando altri componenti diventeranno vincolanti.

Ogni package HBM richiede ancora un die base, test, stacking e collegamento accanto a un acceleratore. Moltiplicare l’output dei package aumenta la domanda per tutti questi passaggi.

HBM4 rende il die base più importante perché include più logica e può utilizzare un processo foundry avanzato. Il risparmio di DRAM non crea una capacità foundry equivalente.

Più package di memoria richiedono inoltre più package di acceleratori. Questi package richiedono interposer, substrati organici, alimentazione, raffreddamento e assemblaggio ad alta densità.

Il collo di bottiglia può quindi migrare anziché scomparire. Wafer logici, die base, substrati, circuiti stampati e integrazione di sistema affronterebbero tutti una domanda maggiore.

I grandi domini scale-up intensificano un altro vincolo. Più acceleratori richiedono switching e networking estesi prima che la loro memoria aggregata si comporti come una risorsa condivisa pratica.

Il GB300 NVL72 di Nvidia utilizza nove tray NVSwitch per collegare 72 GPU. Il suo fabric NVLink di quinta generazione fornisce 130TB al secondo di larghezza di banda aggregata.

I futuri sistemi NVL576 dovranno estendere sostanzialmente questa scala. La loro economia dipende dal fatto che la rete rimanga abbastanza veloce da supportare esperti distribuiti e lo spostamento della cache.

L’energia rimane il confine finale. Raddoppiare il numero di package HBM ricchi di larghezza di banda aiuta solo quando gli operatori possono installare gli acceleratori a essi collegati.

Una strategia 4-hi può estendere la disponibilità di DRAM senza produrre nuova capacità elettrica. Costruzione dei data center, raffreddamento e accesso alla rete elettrica determinano ancora il calcolo utilizzabile.

Questa pressione spiega perché i token per wafer HBM sono una metrica utile, ma non completa. Gli operatori devono ottimizzare insieme token per watt, rack, porta di rete e budget di capitale.

Il cambiamento influenzerebbe anche i mercati della memoria convenzionale. La produzione HBM compete con DRAM per server, PC e dispositivi mobili per le risorse di fabbricazione.

L’uso di meno die core HBM può restituire parte della capacità dei wafer a tali prodotti. Questo sollievo è importante mentre la memoria lato CPU cresce insieme alle implementazioni di AI agentica.

Tuttavia, il beneficio dipende dall’adozione effettiva. Un design 4-hi che consenta un numero molto maggiore di spedizioni di acceleratori potrebbe consumare parte dei risparmi tramite un maggiore volume totale di unità.

I fornitori di memoria potrebbero anche opporsi a un cambiamento rapido se indebolisse la domanda di bit. La loro risposta emergerà attraverso disponibilità dei prodotti, calendari di qualificazione e allocazione della capacità.

La vera sfida, quindi, non è Nvidia contro un singolo fornitore di memoria. È la progettazione dell’inferenza orientata alla larghezza di banda contro l’economia dell’HBM orientata alla capacità.

Questa mappa dei contendenti chiarisce le conseguenze per il settore. Gli stack più bassi vincono quando la larghezza di banda genera ricavi e i gigabyte installati no.

Gli stack più alti vincono quando i clienti possono convertire la capacità aggiuntiva in batch più grandi, più modelli o una maggiore flessibilità dell’hardware nel tempo.

Tre segnali mostreranno se l’HBM 4-hi vincerà davvero

La tesi degli stack corti diventa credibile solo quando roadmap di prodotto, disponibilità produttiva e risultati misurati dell’inferenza convergono.

Il primo segnale è la configurazione finale di Rubin Ultra di Nvidia. La documentazione pubblica deve confermare capacità di memoria, altezza dello stack, larghezza di banda e architettura del sistema NVL576.

Una configurazione confermata da 192GB che utilizzi HBM 8-hi sosterrebbe l’argomentazione generale. Un ritorno al 12-hi indebolirebbe le affermazioni secondo cui i requisiti di capacità si sarebbero ampiamente allentati.

Un prodotto Rubin commerciale da 4-hi offrirebbe prove molto più solide. Fino ad allora, la proposta di SemiAnalysis per HBM 4-hi resta una previsione informata sui futuri ASIC e acceleratori.

Il secondo segnale è la qualificazione, da parte dei fornitori, di HBM4 o HBM4E 4-hi ad alta velocità. I vendor devono offrire questi package alle velocità di segnalazione richieste dai progettisti di acceleratori.

La sola larghezza nominale dell’interfaccia non è sufficiente. I prodotti devono garantire rese, comportamento termico, affidabilità e prestazioni sostenute accettabili all’interno di sistemi completi.

Osservate se SK hynix, Samsung o Micron aggiungono configurazioni 4-hi alle roadmap pubbliche. La distribuzione di campioni ai clienti dimostrerebbe che gli stack corti sono andati oltre gli studi architetturali interni.

Osservate anche il modello di prezzo. Se i costi del 4-hi scalano principalmente con la sua capacità inferiore, la sua economia della larghezza di banda diventa convincente.

Se i fornitori concentrano la maggior parte del valore nel die di base e nell’interfaccia, i risparmi attesi potrebbero ridursi. La scarsità dei package potrebbe inoltre mantenere premi elevati nonostante il minore contenuto di DRAM.

Il terzo segnale sono test indipendenti dell’inferenza su carichi di lavoro diversificati. I benchmark devono includere assistenti interattivi, servizi agentici, richieste a contesto lungo e deployment con batch di grandi dimensioni.

La velocità media in token non basterà. I test devono misurare velocità per utente, comportamento delle code, tassi di hit della cache, traffico di offload e latenza di coda.

I risultati dovrebbero inoltre confrontare modelli diversi per dimensioni e architettura. Una configurazione ottimizzata per Kimi K3 non può dimostrare quale sia la scelta migliore per ogni futuro modello di frontiera.

La prova decisiva sarà un vantaggio stabile nel costo per token, rispettando obiettivi realistici di livello di servizio. Tale vantaggio deve resistere a un’elevata concorrenza e a mix di carichi di lavoro variabili.

Gli sviluppatori dovrebbero interessarsene perché i vincoli hardware modellano la progettazione dei modelli. La memoria disponibile influenza quantizzazione, posizionamento degli esperti, gestione del contesto e politica della cache.

Gli acquirenti enterprise dovrebbero interessarsene perché la capacità dichiarata può essere fuorviante. Più HBM non garantisce più inferenza utile quando larghezza di banda, rete o latenza impongono il limite.

I team infrastrutturali dovrebbero valutare i working set a livello di rack. Dovrebbero separare i carichi di lavoro di training, prefill, decode e agentici prima di scegliere un unico profilo di memoria.

Dovrebbero inoltre mantenere margine operativo. Un sistema 4-hi ottimizzato in modo troppo ristretto può perdere il proprio vantaggio quando la domanda si sposta verso batch più grandi o più modelli simultanei.

La lezione più ampia non è che meno memoria vinca sempre. È che la memoria dovrebbe essere acquistata in funzione della risorsa effettivamente consumata dal carico di lavoro.

Per l’inferenza interattiva, tale risorsa è spesso la larghezza di banda. L’HBM a quattro livelli può mantenere l’intero percorso dati esterno usando al contempo meno die DRAM, una risorsa scarsa.

Questo rende l’analisi di SemiAnalysis sull’HBM 4-hi una seria sfida alle ipotesi del settore in favore degli stack più alti. Le prossime divulgazioni sui prodotti mostreranno se i team hardware concordano.

Prima di impegnarsi per una futura flotta di acceleratori, ponetevi tre domande. Il working set rientra nella scala del rack, i dati della cache fredda possono essere spostati in sicurezza e la capacità aggiuntiva aumenta il throughput utile?

Se le risposte indicano la larghezza di banda, il re degli stack corti merita un posto nella roadmap.