L’affermazione di Sandisk e SK hynix sullo standard HBF necessita ancora di prove

Sandisk e SK hynix sono approdate su Google News con un’affermazione di grande impatto: i partner avrebbero rilasciato la prima specifica dell’Open Compute Project per High Bandwidth Flash.

Il titolo sembra indicare un passo decisivo verso uno standard di settore. Eppure, gli annunci accessibili delle aziende descrivono un gruppo di lavoro OCP e l’avvio della standardizzazione, non una specifica completata.

La distinzione è importante perché High Bandwidth Flash, o HBF, è ancora una classe di memoria proposta piuttosto che un prodotto commerciale ampiamente testato. HBF colloca flash NAND impilata vicino ai processori AI, puntando a offrire una capacità maggiore della memoria ad alta larghezza di banda e più banda rispetto allo storage convenzionale.

La sfida centrale non è semplicemente Sandisk contro un altro produttore di memoria. È la promessa di HBF di fornire abbondante memoria per l’inferenza contro i vantaggi in termini di latenza, durata, software e produzione degli affermati sistemi HBM.

Sandisk apporta una profonda esperienza in NAND e nel wafer bonding. SK hynix contribuisce con competenze nella progettazione HBM, nel packaging e nella produzione ad alto volume. La loro collaborazione conferisce maggiore credibilità a HBF, ma gli annunci di partnership non possono sostituire hardware interoperabile o uno standard pubblico approvato.

La vicenda risultante è più significativa di un normale aggiornamento di specifica. Verifica se l’infrastruttura AI possa aggiungere un livello di memoria pratico tra la costosa HBM e lo storage SSD relativamente distante.

Cosa Google News conferma e cosa non conferma

L’evento confermato è uno sforzo di standardizzazione organizzato, mentre il presunto rilascio di una specifica OCP completata resta difficile da verificare pubblicamente.

Il 25 febbraio 2026, Sandisk e SK hynix hanno tenuto un incontro di avvio per la standardizzazione HBF presso la sede di Sandisk a Milpitas, in California. Entrambe le aziende hanno dichiarato che avrebbero formato un gruppo di lavoro dedicato nell’ambito dell’Open Compute Project.

Il loro obiettivo dichiarato è sviluppare HBF come standard di settore per l’infrastruttura di inferenza AI. Il gruppo di lavoro offre un forum per definire i requisiti tecnici e incoraggiare la partecipazione oltre le due aziende fondatrici.

Si tratta di un progresso significativo. Un gruppo di lavoro OCP può esporre una proposta a costruttori di sistemi, progettisti di chip, operatori cloud e altri fornitori di memoria prima che i prodotti si consolidino.

Tuttavia, avviare quel processo è diverso dal rilasciare una specifica tecnica approvata. L’annuncio di SK hynix sulla standardizzazione HBF afferma che i partner avrebbero avviato il gruppo di lavoro e iniziato l’attività di standardizzazione.

La corrispondente iniziativa OCP di Sandisk presenta anch’essa l’evento come un inizio. Non identifica una versione finale della specifica, una data di approvazione, un numero di documento pubblico o un programma di conformità.

Questi dettagli mancanti creano un divario di verifica attorno al titolo circolato tramite Google News. La presenza in un aggregatore conferma che gli editori hanno riportato l’affermazione, non che OCP abbia completato la propria revisione tecnica.

Una specifica rilasciata normalmente lascia una traccia più chiara. I lettori dovrebbero aspettarsi un titolo del documento, un numero di versione, una cronologia delle revisioni, uno stato di governance e contenuti tecnici scaricabili.

Uno standard maturo definisce inoltre ciò che i fornitori indipendenti devono implementare. Ciò potrebbe includere interfacce elettriche, comportamento dei comandi, dimensioni del packaging, limiti termici, obiettivi di affidabilità e regole di interoperabilità.

Nulla di tutto ciò significa che la specifica riportata sia necessariamente fittizia. Potrebbe esistere un contributo preliminare, una bozza o un documento appena presentato senza essere facilmente indicizzato.

La conclusione prudente è più circoscritta. I materiali di prima parte accessibili pubblicamente confermano il gruppo di lavoro, ma non dimostrano in modo indipendente l’esistenza di una specifica OCP completata.

Questo divario dovrebbe orientare l’interpretazione dell’articolo. Il cambiamento importante è che due grandi aziende di memoria stanno inserendo HBF in un riconosciuto processo di infrastruttura aperta.

La questione irrisolta è fino a che punto quel processo sia avanzato. Finché OCP non pubblicherà documentazione identificabile, “prima specifica” dovrebbe essere trattato come un’affermazione riportata, non come un traguardo consolidato.

Perché l’inferenza AI ha bisogno di un altro livello di memoria

HBF punta allo spazio sempre più ampio tra HBM veloce ma limitata in capacità e SSD capienti ma troppo lontani dagli acceleratori.

L’inferenza AI legge ripetutamente i pesi del modello e dati di attenzione temporanei mentre genera risposte. I modelli di grandi dimensioni possono quindi richiedere sia alta capacità sia un flusso sostenuto di dati verso i processori.

HBM gestisce bene questo compito perché colloca DRAM impilata verticalmente vicino a un acceleratore. Le interfacce ampie spostano i dati più velocemente di quanto possa fare la memoria server convenzionale.

Il compromesso riguarda capacità, complessità produttiva e spazio limitato nel package. L’aggiunta di più stack HBM aumenta i costi di sistema e consuma area preziosa attorno al processore.

Gli SSD aziendali offrono molta più capacità, ma le loro interfacce orientate ai blocchi e i percorsi di storage aggiungono latenza. Non possono semplicemente comportarsi come HBM accanto a una GPU.

HBF propone un livello intermedio. Impila flash NAND usando concetti di packaging associati a HBM, quindi collega tale capacità attraverso un percorso ampio ad alta larghezza di banda.

La scheda tecnica HBF pubblicata da Sandisk descrive un obiettivo di prima generazione di 1,6 terabyte al secondo. Elenca inoltre 256 gigabit per die e 512 gigabyte in uno stack da 16 die.

Queste cifre sono obiettivi aziendali, non risultati di benchmark indipendenti. Spiegano comunque perché i progettisti di infrastrutture siano interessati.

Uno stack HBF da 512 gigabyte conterrebbe molti più dati di un tipico package HBM. Più stack potrebbero mantenere componenti di modello più grandi vicino agli acceleratori, invece di recuperarli ripetutamente dagli SSD.

Il progetto è particolarmente rilevante per l’inferenza perché molte distribuzioni eseguono molte più letture che scritture. La NAND tollera un numero limitato di cicli di programmazione e cancellazione, ma i carichi di lavoro di servizio dei modelli, ricchi di letture, possono ridurre questo svantaggio.

Le applicazioni utili potrebbero includere l’archiviazione dei pesi del modello, degli indici di recupero o di porzioni della cache chiave-valore. Una cache chiave-valore conserva dati di attenzione creati mentre un modello elabora e genera una sequenza.

Nessuno di questi usi rende HBF equivalente a HBM. La NAND ha una latenza di accesso più elevata della DRAM, quindi il software deve collocare i dati in base al comportamento del carico di lavoro.

Le informazioni consultate più frequentemente rimarrebbero in HBM. Dati più grandi o meno sensibili alla latenza potrebbero passare in HBF, mentre gli SSD conserverebbero dataset meno attivi e storage durevole.

Questa configurazione a livelli sposta la complessità anziché eliminarla. Acceleratori, compilatori, sistemi operativi e framework di serving devono sapere dove appartengono i dati e quando spostarli.

Il meccanismo assomiglia più a una gerarchia di memoria che a una sostituzione diretta. I processori usano già registri, cache, memoria di sistema e storage perché nessuna singola tecnologia ottimizza ogni requisito.

HBF estende questa gerarchia più vicino all’acceleratore. Il suo valore dipende dalla capacità di mantenere abbastanza dati utili nelle vicinanze senza esporre la latenza della NAND nei momenti critici dell’esecuzione.

La tempistica riflette anche un cambiamento nelle priorità dell’infrastruttura AI. L’addestramento ha dominato la prima ondata di spesa per acceleratori, mentre l’inferenza sta diventando un onere operativo più rilevante.

L’addestramento spesso premia la massima larghezza di banda per un lavoro pianificato. L’inferenza deve bilanciare latenza, capacità, utilizzo e potenza su richieste ripetute.

Finestre di contesto più ampie aumentano questa pressione. Lo stesso vale per i modelli mixture-of-experts, che attivano componenti selezionati del modello ma richiedono comunque ai sistemi di archiviare e recuperare pesi estesi.

Sandisk ha iniziato a presentare pubblicamente HBF nel 2025. Il suo accordo di collaborazione dell’agosto 2025 affermava che i primi campioni di memoria erano previsti per la seconda metà del 2026.

Lo stesso annuncio indicava come obiettivo campioni dei primi dispositivi di inferenza dotati di HBF per l’inizio del 2027. Tali date restano obiettivi finché i clienti non riceveranno e convalideranno hardware funzionante.

Questo calendario rende urgente la standardizzazione. I fornitori hanno bisogno di presupposti stabili prima di impegnare interfacce per acceleratori, package, controller, sistemi di raffreddamento e software in un livello di memoria non familiare.

Il vero avversario di HBF è il sistema HBM esistente

Sandisk e SK hynix devono dimostrare che la capacità NAND aggiuntiva compensi il costo derivante dall’aggiunta di latenza, complessità software e un’altra tecnologia di packaging.

HBF viene spesso descritta come un’alternativa a HBM, ma questa impostazione semplifica eccessivamente la posizione competitiva. È più probabile che i sistemi HBF iniziali integrino HBM anziché eliminarla.

HBM fornisce memoria di lavoro a bassa latenza e alto throughput per gli acceleratori. HBF mira a mantenere dataset più grandi e ricchi di letture vicino alle stesse risorse di calcolo.

Questo crea un benchmark impegnativo. HBF non deve semplicemente superare un SSD. Deve migliorare i sistemi di inferenza completi abbastanza da giustificarne la riprogettazione.

La metrica rilevante non è soltanto la larghezza di banda di picco. Gli operatori valutano token al secondo, tempo al primo token, utenti simultanei, consumo energetico, utilizzo degli acceleratori e costo totale del sistema.

Un’elevata larghezza di banda dichiarata può coesistere con prestazioni applicative scarse. Accessi casuali, overhead del controller, movimento dei dati e cache miss possono determinare i risultati effettivi.

Sandisk afferma che la propria tecnologia CMOS directly Bonded to Array collega direttamente la circuiteria di controllo a un array NAND. L’approccio mira a percorsi dati più brevi e a un maggiore parallelismo rispetto a quanto offra un controller SSD convenzionale.

SK hynix contribuisce con esperienza nelle through-silicon vias, nell’assemblaggio degli stack, nella gestione termica e nella produzione HBM. Questa conoscenza del packaging affronta una parte diversa del problema.

La partnership è quindi complementare. Sandisk conosce la flash ad alta densità, mentre SK hynix opera al centro dell’attuale mercato HBM.

Crea inoltre un’insolita tensione strategica. SK hynix beneficia della forte domanda di HBM, eppure sta contribuendo a sviluppare una tecnologia posizionata al di sotto di HBM nella gerarchia di memoria.

L’apparente contraddizione ha senso se HBF espande il mercato complessivo. SK hynix può proteggere il proprio ruolo nell’HBM partecipando al contempo a un secondo livello che altrimenti potrebbe svilupparsi senza di essa.

Non è necessariamente una sfida a somma zero. Un acceleratore per l’inferenza potrebbe usare HBM per il calcolo attivo e HBF per la capacità del modello, aumentando la domanda per entrambe.

La competizione più difficile riguarda l’architettura di sistema. Gli attuali server AI collegano già gli acceleratori a HBM, DRAM host, storage NVMe e storage in rete.

HBF deve conquistarsi un posto all’interno di questa gerarchia. Ogni nuovo livello aggiunge controller, decisioni di pianificazione, modalità di guasto, requisiti di convalida e dipendenze di approvvigionamento.

Il supporto software diventa decisivo. Un framework di serving deve sapere quali tensori o segmenti di cache possono tollerare la latenza di HBF.

Un posizionamento inefficace potrebbe bloccare un costoso acceleratore mentre attende la flash. Un buon posizionamento potrebbe consentire allo stesso acceleratore di servire un modello più grande o più richieste simultanee.

Gli sviluppatori avranno bisogno di strumenti di profiling che rendano visibili questi effetti. Il posizionamento automatico potrebbe alla fine nascondere parte della complessità, ma i primi sistemi richiederanno probabilmente ottimizzazioni specifiche per il carico di lavoro.

Gli standard aiutano offrendo ai team software un obiettivo stabile. Riducono inoltre il rischio che ciascun fornitore di acceleratori implementi un'interfaccia incompatibile.

OCP è rilevante perché tra i suoi membri figurano soggetti attivi nel cloud e nei data center in grado di valutare i compromessi a livello di sistema. Il loro coinvolgimento darebbe a HBF una validazione più solida rispetto all'azione isolata di due fornitori.

Tuttavia, un gruppo di lavoro aperto non garantisce un'adozione diffusa. Samsung, Micron, Kioxia, i progettisti di acceleratori e gli operatori hyperscale devono decidere se l'interfaccia proposta sia nel loro interesse.

Alcuni fornitori potrebbero preferire memoria collegata tramite CXL, configurazioni HBM più capienti, formati di modello compressi o architetture SSD più veloci. CXL è un'interconnessione che supporta l'espansione e la condivisione della memoria tra processori e dispositivi.

Queste soluzioni possono sovrapporsi a HBF. Possono anche ridurre la necessità di collocare NAND in un package simile a HBM.

HBF deve quindi confrontarsi con un avversario costituito dai sistemi già installati, non con una singola azienda. Le architetture esistenti incentrate su HBM dispongono già di strumenti di produzione, relazioni con i clienti e supporto software.

Sandisk e SK hynix possono mettere in discussione questa posizione solo con prove provenienti da sistemi completi. Una specifica è utile, ma saranno risultati ripetibili sui carichi di lavoro a decidere se il nuovo livello sopravviverà.

Ciò a cui la specifica HBF non può ancora rispondere

La maggiore incertezza non riguarda la capacità della NAND impilata di spostare dati rapidamente, ma la possibilità che i sistemi commerciali la utilizzino in modo prevedibile ed economico.

La prima questione irrisolta è la latenza. Sandisk ha promosso un ambizioso obiettivo di larghezza di banda sequenziale, ma la larghezza di banda non descrive ogni schema di accesso.

I carichi di lavoro di inferenza possono recuperare piccole porzioni di dati sparse. HBF deve dimostrare come controller e software gestiscano tali richieste senza creare lunghi stalli del processore.

La seconda questione riguarda la durata in scrittura. Le celle NAND sopportano meno scritture della DRAM e i sistemi di inferenza aggiornano continuamente alcune forme di stato temporaneo.

I pesi dei modelli, prevalentemente in lettura, si adattano ai punti di forza di HBF. Un comportamento della cache ad alta intensità di scrittura potrebbe rivelarne i limiti, a meno che i sistemi non reindirizzino le scritture o gestiscano efficacemente l'usura.

La terza questione riguarda il comportamento termico. L'impilamento di numerosi die NAND con logica aumenta la densità vicino ad acceleratori che generano già una notevole quantità di calore.

Un minore consumo per bit memorizzato sarebbe utile, ma il raffreddamento a livello di package rimane un problema di sistema. I fornitori devono pubblicare limiti operativi in presenza di carichi di lavoro sostenuti.

La resa produttiva crea un altro rischio. Un package contenente numerosi die collegati può perdere valore economico se i difetti riducono il numero di stack utilizzabili.

Il processo di bonding di Sandisk e l'esperienza di packaging di SK hynix affrontano questa sfida. Nessuna delle due aziende ha ancora fornito dati pubblici, testati in modo indipendente, su resa o affidabilità per HBF commerciale.

Anche l'interoperabilità resta incerta. Un vero standard dovrebbe consentire a componenti di fornitori diversi di funzionare con controller e software condivisi.

Un documento sviluppato soprattutto attorno alla tecnologia di un solo fornitore potrebbe essere aperto nel nome, ma difficile da implementare per i concorrenti. La revisione OCP può ridurre questo rischio se la partecipazione diventa ampia.

Anche i termini relativi alla proprietà intellettuale contano. I costruttori di sistemi devono capire quali elementi dell'interfaccia siano aperti e quali dipendano da processi produttivi soggetti a licenza.

Una specifica elettrica non standardizzerebbe automaticamente la fabbricazione fisica. Le aziende possono condividere interfacce proteggendo al contempo i propri progetti di bonding, controller e NAND.

La tempistica merita attenzione. Sandisk aveva precedentemente indicato come obiettivo i primi campioni HBF per la seconda metà del 2026 e campioni di dispositivi dotati di HBF per l'inizio del 2027.

Questi obiettivi implicano che la validazione del silicio, il lavoro sulla specifica e l'integrazione presso i clienti stiano procedendo in parallelo. Lo sviluppo parallelo fa risparmiare tempo, ma aumenta il costo delle modifiche progettuali tardive.

Un documento OCP realmente approvato ridurrebbe parte dell'incertezza. Resterebbero comunque senza risposta la preparazione produttiva, la maturità del software e le prestazioni sui carichi di lavoro.

Anche la stampa di settore ha presentato orizzonti di commercializzazione contrastanti. Alcune fonti indicano campioni intorno al 2026 e al 2027, mentre roadmap più ampie collocano l'adozione matura di HBF più avanti.

Questa differenza può riflettere tappe distinte anziché una contraddizione diretta. I campioni ingegneristici possono arrivare anni prima di prodotti ad alto volume e ampiamente interoperabili.

La distinzione dovrebbe rimanere visibile ogni volta che Google News o un altro aggregatore amplifica un titolo sintetico. “Specifica rilasciata” non significa “prodotto in spedizione”.

Anche “campionamento del prodotto” può riferirsi a unità di valutazione limitate. I clienti possono testare tali dispositivi senza impegnarsi nel loro impiego.

Un caso credibile per l'adozione richiede più di dimostrazioni interne. I costruttori di sistemi indipendenti dovrebbero pubblicare carichi di lavoro che confrontino configurazioni HBF, HBM, memoria host e SSD.

Tali confronti dovrebbero controllare il tipo di acceleratore, le dimensioni del modello, la dimensione del batch, la lunghezza del contesto, la potenza e gli obiettivi di latenza. Altrimenti, i vantaggi di capacità possono nascondere penalizzazioni prestazionali.

Le aziende dovrebbero anche chiarire il comportamento in caso di guasto. Gli operatori devono sapere come i sistemi isolino i die difettosi, preservino la disponibilità del servizio e si riprendano quando un dispositivo HBF fallisce.

Poiché HBF utilizza supporti non volatili, potrebbe sollevare questioni di sicurezza relative ai dati residui dei modelli. Le specifiche dovrebbero definire sanificazione, controlli di accesso e gestione del ciclo di vita.

Nessuno di questi problemi invalida il concetto. Spiegano perché sia importante la differenza tra un gruppo di lavoro e uno standard concluso.

Il gruppo di lavoro apre il dibattito. Una specifica pubblica dovrebbe trasformare quel dibattito in requisiti che fornitori, clienti e ingegneri indipendenti possano testare.

Tre segnali mostreranno se HBF sta diventando reale

La prossima fase dovrebbe essere giudicata sulla base di un documento OCP pubblico, campioni validati e sostegno da parte di aziende oltre Sandisk e SK hynix.

Il primo segnale è una specifica OCP identificabile. Dovrebbe includere una versione, l'ambito tecnico, lo stato di governance e la cronologia delle revisioni.

La pubblicazione rafforzerebbe l'attuale affermazione di standardizzazione. Un'assenza prolungata suggerirebbe che i titoli siano andati avanti rispetto al processo formale.

Il contenuto del documento conta quanto la sua esistenza. Una proposta meccanica limitata avrebbe meno peso di una specifica che copra interfacce, comandi, affidabilità e interoperabilità.

Il secondo segnale è la tappa di campionamento di Sandisk. L'azienda ha indicato come obiettivo i primi campioni di memoria HBF per la seconda metà del 2026.

I campioni funzionanti dovrebbero produrre evidenze dettagliate, tra cui latenza di accesso casuale, larghezza di banda sostenuta, durata, consumo energetico, comportamento termico e gestione degli errori.

Test indipendenti rafforzerebbero il caso più delle dimostrazioni dei fornitori. Un ritardo non eliminerebbe HBF, ma indebolirebbe il percorso dichiarato verso i campioni di dispositivi previsti per l'inizio del 2027.

Il terzo segnale è la partecipazione oltre i partner fondatori. Occorre osservare se fornitori di acceleratori, hyperscaler, produttori di server, progetti software e ulteriori fornitori di memoria si uniranno al lavoro.

Un'ampia partecipazione dimostrerebbe che HBF sta diventando un'architettura condivisa. Una partecipazione limitata la lascerebbe più vicina a una strategia di prodotto bilaterale.

Samsung, Micron e Kioxia sono punti di confronto particolarmente importanti perché dispongono di competenze rilevanti nella memoria o nel flash. Il loro sostegno, proposte concorrenti o silenzio chiariranno la direzione del mercato.

Il supporto degli acceleratori conta ancora di più. HBF non può diventare un'infrastruttura utile se i processori non dispongono di controller adeguati, connessioni di package e software per la gestione della memoria.

Gli operatori cloud possono fornire il segnale di domanda più forte. Gestiscono flotte di inferenza abbastanza grandi da giustificare cambiamenti architetturali se i miglioramenti di capacità e consumo energetico lo consentono.

Anche gli impegni software meritano attenzione. Il supporto al posizionamento della memoria nei motori di inferenza, nei compilatori e nei sistemi di orchestrazione indicherebbe che i piani hardware sono andati oltre le presentazioni.

I lettori che seguono la storia tramite Google News dovrebbero distinguere questi segnali dagli annunci ripetuti. I titoli distribuiti in syndication fanno spesso apparire una partnership come più conferme indipendenti.

Il quadro di fondo è semplice. Sandisk e SK hynix hanno concordato di collaborare nell'agosto 2025, hanno avviato un gruppo di lavoro OCP nel febbraio 2026 e hanno delineato futuri obiettivi di campionamento.

Una specifica appena rilasciata sarebbe la prossima tappa distinta, ma richiede un documento verificabile. Devono seguire la validazione del prodotto e la partecipazione dell'ecosistema.

Per gli sviluppatori, HBF potrebbe cambiare il modo in cui modelli, cache e dati di recupero vengono collocati attorno agli acceleratori. Potrebbe anche introdurre un ulteriore confine prestazionale che richiede un profiling accurato.

Gli acquirenti aziendali dovrebbero chiedersi se i guadagni di capacità proposti migliorino i loro effettivi carichi di lavoro di serving. Dovrebbero richiedere misurazioni dell'intero sistema anziché fare affidamento sulla larghezza di banda dei componenti.

I knowledge worker e gli utenti dell'AI non acquisteranno HBF direttamente. Potrebbero comunque sentirne gli effetti attraverso contesti più lunghi, modelli più grandi o costi di inferenza inferiori.

Questi benefici rimangono risultati potenziali, non confermati. La risposta più utile è seguire le evidenze anziché accettare una promozione entusiastica o un rigetto prematuro.

Lo sforzo di standardizzazione merita attenzione perché affronta un reale collo di bottiglia della memoria. Il suo successo dipende ora dalla capacità dei partner di trasformare un gruppo di lavoro aperto in un'infrastruttura testabile.

Osservate prima il documento OCP, poi il silicio testato dai clienti e infine la partecipazione esterna. Insieme, questi segnali riveleranno se HBF sta diventando uno standard o rimane una proposta promettente.