Sandisk e SK hynix pubblicano una specifica HBF aperta, ma ora arriva la prova dell'hardware

Sandisk e SK hynix hanno pubblicato la prima specifica aperta per High Bandwidth Flash il 4 agosto, appena sei mesi dopo il lancio del loro gruppo di standardizzazione. L'annuncio è arrivato su Google News con una promessa insolitamente concreta per una tecnologia di memoria emergente: capacità fino a 512GB e larghezza di banda fino a 3TB/s.

Questa combinazione punta a colmare un divario sempre più ampio nei sistemi AI. High Bandwidth Memory, o HBM, offre velocità vicino ai processori ma resta limitata in capacità. Le unità a stato solido offrono molta più capacità, ma sono troppo lontane dal processore per molte attività di inferenza sensibili alla latenza.

High Bandwidth Flash, nota come HBF, è progettata per occupare il livello intermedio tra le due. Sandisk e SK hynix non propongono di sostituire ogni stack HBM con flash NAND. Vogliono che i sistemi usino HBM per i dati più attivi e HBF per set di lavoro più ampi che richiedono comunque un accesso rapido.

La specifica rende questa architettura più facile da valutare per i progettisti di processori. Non dimostra che HBF possa offrire le prestazioni dichiarate nell'hardware di produzione. La vera sfida, quindi, non è Sandisk contro SK hynix. È la specifica aperta contro il lavoro di ingegnerizzazione e adozione ancora necessario.

La specifica HBF trasforma un'idea di memoria in un obiettivo condiviso

La pubblicazione offre ai team che lavorano su processori, packaging e software un obiettivo comune per HBF, ma non fornisce un prodotto finito.

SK hynix ha annunciato la specifica insieme a Sandisk durante FMS 2026 a Santa Clara, in California. L'evento si svolge dal 4 al 6 agosto ed è incentrato sulle tecnologie di memoria e storage.

Le aziende hanno pubblicato il lavoro tramite l'Open Compute Project, o OCP, un'organizzazione di settore focalizzata sull'infrastruttura aperta per data center. Questa scelta conta perché HBF richiede la partecipazione di più di due fornitori di memoria.

Secondo l'annuncio della specifica HBF, il progetto iniziale supporta due configurazioni fisiche. Uno stack a otto die rappresenta un'opzione, mentre uno stack a 16 die supporta la capacità massima annunciata.

La specifica copre capacità fino a 512GB. Definisce inoltre tre classi prestazionali, con una larghezza di banda compresa approssimativamente tra 0.4TB/s e 3TB/s.

Queste classi consentono ai progettisti di sistemi di adattare le implementazioni HBF a diversi requisiti di carico di lavoro e costo. Una classe inferiore potrebbe supportare attività di inferenza meno esigenti senza obbligare ogni progetto a puntare al package più complesso.

La pubblicazione affronta anche caratteristiche elettriche, affidabilità del packaging, connessioni ai processori e linee guida per input e output software. Questi dettagli portano HBF oltre il concetto da presentazione, avvicinandola a qualcosa che i team di ingegneria possono esaminare.

La connessione al processore utilizza Universal Chiplet Interconnect Express, o UCIe. UCIe è un'interfaccia aperta a livello di package che collega die semiconduttori separati all'interno di un unico sistema.

Le specifiche UCIe ufficiali coprono connessioni fisiche, protocolli, comportamento del software e test di conformità. L'uso di questa interfaccia riduce la necessità che HBF dipenda dalla connessione proprietaria di un singolo fornitore di processori.

Crea inoltre un percorso per collegare HBF a CPU, GPU e altri acceleratori. Questa flessibilità è centrale nell'argomentazione a favore dello standard aperto, perché l'infrastruttura AI comprende più di un'architettura di processore.

Tuttavia, uno standard di interfaccia non crea automaticamente interoperabilità. I fornitori devono comunque sviluppare controller, metodi di packaging, firmware, driver, politiche di gestione della memoria e test di conformità che funzionino insieme.

Questa distinzione si perde facilmente in un breve titolo su Google News. Sandisk e SK hynix hanno pubblicato una specifica, non moduli HBF generalmente disponibili o server AI di produzione.

La loro velocità resta comunque degna di nota. Sandisk e SK hynix hanno annunciato la loro partnership originaria per la standardizzazione nell'agosto 2025. Hanno avviato il filone di lavoro OCP nel febbraio 2026 e prodotto questa prima specifica circa sei mesi dopo.

Secondo SK hynix, Google e lo sviluppatore di processori AI Tenstorrent partecipano ora al consorzio. La loro presenza offre al progetto un contributo prezioso sia dal lato dei carichi di lavoro sia da quello dei processori.

Nessuna delle due aziende ha annunciato un sistema di produzione qualificato che utilizzi la specifica. Nessun benchmark indipendente ha ancora dimostrato la larghezza di banda, la latenza, la durata o le prestazioni energetiche di un dispositivo commerciale conforme.

Il documento aperto cambia quindi ciò di cui il settore può discutere. Invece di dibattere su una categoria di memoria non definita, gli ingegneri possono esaminare dimensioni degli stack, classi di larghezza di banda, interfacce, aspettative di packaging e requisiti software.

Questo è l'evento immediato. La questione più ampia è perché l'inferenza AI abbia bisogno di un ulteriore livello di memoria.

Perché l'inferenza AI sta mettendo sotto pressione HBM e SSD

HBF esiste perché l'inferenza richiede sempre più spesso un accesso simile a HBM a set di dati troppo grandi per essere mantenuti interamente in HBM.

L'addestramento AI riceve gran parte dell'attenzione infrastrutturale, ma l'inferenza crea un problema di memoria diverso. L'addestramento costruisce un modello. L'inferenza esegue ripetutamente quel modello per rispondere alle richieste, generare contenuti multimediali, usare strumenti o gestire un agente.

Un servizio distribuito potrebbe richiedere pesi del modello, dati di attenzione, token in cache, indici di recupero e contesto applicativo. Mantenere ogni set di dati attivo nella memoria più veloce diventa difficile man mano che crescono modelli e carichi di lavoro simultanei.

HBM colloca stack di DRAM vicino a un processore e li collega attraverso un'interfaccia ampia. Questo design offre una larghezza di banda elevata agli acceleratori che devono spostare rapidamente grandi quantità di dati.

I suoi punti di forza non eliminano i vincoli fisici. Spazio nel package, complessità produttiva, energia, capacità e disponibilità influenzano tutti la quantità di HBM che può essere collocata accanto a ciascun processore.

Gli SSD enterprise risolvono un problema diverso. Conservano molte più informazioni a un costo inferiore per bit e il flash NAND mantiene i dati senza alimentazione continua. Il loro percorso di storage convenzionale aggiunge latenza e overhead software.

Questo lascia un divario architetturale. Alcuni dati per l'inferenza non richiedono la minore latenza possibile di HBM, ma necessitano di un accesso più rapido e diretto di quello offerto da un normale percorso SSD.

SK hynix descrive HBF come un livello di supporto, mentre HBM continua a gestire il lavoro che richiede la maggiore larghezza di banda. Questo modello di memoria a livelli assegna i dati a tecnologie diverse in base alla frequenza di accesso e alle esigenze prestazionali.

Un modello di grandi dimensioni offre uno scenario utile. Le parti usate più frequentemente potrebbero restare in HBM, mentre i pesi meno attivi risiederebbero in HBF. Un SSD potrebbe contenere dati di cui il sistema ha bisogno meno spesso.

Il sistema sposterebbe quindi le informazioni tra i livelli al variare delle condizioni del carico di lavoro. Questo approccio ricorda le gerarchie di cache consolidate, ma capacità, requisiti di larghezza di banda e sfide di packaging sono molto maggiori.

Il vantaggio dipende dalle decisioni di collocazione. Se il software recupera ripetutamente i dati sbagliati da un livello più lento, i core del processore possono restare in attesa e le prestazioni complessive possono diminuire.

HBF deve quindi diventare più che flash densa accanto a un acceleratore. Il sistema circostante ha bisogno di controller e software in grado di prevedere quali dati appartengono a ciascun livello di memoria.

L'AI agentica rafforza questa pressione. Un agente può mantenere cronologie più lunghe, consultare conoscenze esterne, chiamare strumenti software e coordinare diverse operazioni del modello per una singola richiesta utente.

Questi flussi di lavoro creano set di lavoro più grandi e meno prevedibili. Possono inoltre mantenere l'infrastruttura di inferenza occupata più a lungo rispetto a un singolo prompt e una singola risposta.

Per gli sviluppatori, la domanda non è se ogni applicazione abbia bisogno di HBF. La domanda è se i futuri sistemi di inferenza richiederanno un livello intermedio che riduca la costosa capacità HBM senza ricorrere allo storage ordinario.

Per gli acquirenti aziendali, l'architettura della memoria può influire sull'utilizzo dei server, sui tempi di risposta, sul consumo energetico e sul numero di modelli che entrano in un singolo sistema. Questi fattori incidono sui costi operativi anche quando gli utenti non vedono mai i componenti sottostanti.

Anche i knowledge worker hanno un interesse indiretto. Contesto locale più ampio e agenti più persistenti richiedono un'infrastruttura in grado di conservare e recuperare in modo efficiente i dati di lavoro.

Una base di conoscenza ricercabile affronta un problema di collocazione simile a livello applicativo. Il materiale pertinente deve raggiungere rapidamente il modello senza caricare ogni documento nel livello di contesto più veloce.

HBF affronta il lato hardware di questa sfida più ampia. Cerca di mantenere una maggiore quantità di dati relativi al modello sufficientemente vicina al calcolo per un'inferenza pratica, senza trattare ogni bit come dati HBM premium.

Questo crea pressione su fornitori di processori, operatori cloud e produttori di memoria. Ogni gruppo deve decidere se un ulteriore livello migliori il sistema abbastanza da giustificare maggiore complessità di packaging e software.

L'attenzione di Google News nasconde la vera sfida: specifica contro silicio

La specifica è abbastanza credibile da attirare partner, ma solo il silicio funzionante potrà dimostrare che HBF merita un posto accanto ai processori AI.

Sandisk ha presentato per la prima volta HBF come un'architettura di memoria basata su NAND destinata all'inferenza. Il suo piano originale prevedeva i primi campioni HBF nella seconda metà del 2026.

L'azienda prevedeva inoltre campioni dei primi dispositivi per l'inferenza che incorporano HBF all'inizio del 2027. Questi obiettivi erano inclusi nel suo comunicato sulla partnership del 2025.

La specifica dell'agosto 2026 non conferma che tali traguardi relativi ai campioni siano stati raggiunti. Stabilisce il quadro tecnico che i potenziali prodotti dovrebbero seguire.

Il concetto di prima generazione di Sandisk punta a 1.6TB/s di larghezza di banda in lettura e 512GB in uno stack a 16 die. Le generazioni successive dovrebbero superare 2TB/s e raggiungere infine 3.2TB/s.

Questi numeri provengono dal brief tecnico HBF di Sandisk. Restano obiettivi aziendali, non misurazioni indipendenti su sistemi commerciali.

Il brief afferma inoltre che una configurazione HBF simulata ha ottenuto prestazioni entro il 2.2 percento rispetto a un modello HBM a capacità illimitata in un test specifico. Il carico di lavoro utilizzava pesi a otto bit del modello Llama 3.1 405B.

Il risultato richiede un'interpretazione attenta. Sandisk lo ha basato su test interni e simulazioni, e il confronto presupponeva una capacità HBM illimitata. I prodotti reali dovranno affrontare capacità finite, limiti termici, comportamento del software e traffico di dati concorrente.

Anche il NAND si comporta diversamente dalla DRAM. Offre densità e non volatilità, ma generalmente comporta una latenza di accesso maggiore e considerazioni più stringenti sulla durata.

La maggiore dimensione delle pagine di HBF può complicare i carichi di lavoro che richiedono piccole porzioni di dati sparse. Spostare byte non necessari consuma larghezza di banda ed energia anche quando la velocità di trasferimento dichiarata appare elevata.

L'inferenza di modelli a prevalenza di lettura è un punto di partenza plausibile, perché i pesi addestrati cambiano meno spesso rispetto a molte altre strutture dati. Utilizzi più intensivi in scrittura eserciterebbero una pressione maggiore sulla gestione della durata.

Il packaging rappresenta un'altra prova. Uno stack a 16 die richiede produzione coerente, controllo termico, integrità del segnale e una resa produttiva accettabile.

Un progetto può funzionare in simulazione ma diventare costoso quando viene assemblato su larga scala. Difetti in un componente possono influire sull’economia di un intero package avanzato.

Il dato di 512GB è quindi importante, ma la capacità utilizzabile è solo una parte del prodotto. Gli acquirenti esamineranno la distribuzione della latenza, la larghezza di banda sostenuta, la gestione degli errori, la temperatura, la durata e il comportamento sotto carichi di lavoro misti.

I tre livelli di larghezza di banda sollevano inoltre questioni di implementazione. La specifica identifica gli obiettivi, ma i fornitori devono dimostrare quali processori e package possano sostenere ciascun livello.

UCIe fornisce una base di interfaccia aperta, non la garanzia che qualsiasi stack HBF possa connettersi a qualsiasi acceleratore. I programmi di conformità e i progetti di riferimento determineranno quanta interoperabilità otterrà effettivamente il mercato.

È qui che Google e Tenstorrent contano. Google porta esperienza nella gestione di grandi servizi AI e nella progettazione di acceleratori personalizzati. Tenstorrent può verificare se l’interfaccia funziona oltre il modello GPU dominante.

La loro adesione al consorzio è un segnale positivo di adozione. Non equivale a un impegno d’acquisto, a un annuncio di prodotto o a una distribuzione.

L’assenza di un processore di produzione identificato rimane la principale lacuna da verificare. HBF necessita di almeno una piattaforma di accelerazione con controller, design del package, stack software e un beneficio documentato sul carico di lavoro.

Senza tale integrazione, lo standard rischia di diventare tecnicamente interessante ma commercialmente marginale. L’industria dei semiconduttori contiene molte specifiche che non hanno mai raggiunto un ampio impiego in produzione.

Sandisk e SK hynix migliorano le probabilità perché le loro capacità sono complementari. Sandisk contribuisce con la progettazione NAND e l’architettura flash, mentre SK hynix copre NAND, DRAM, HBM, packaging e produzione di massa.

La loro partnership riduce inoltre l’impressione che HBF sia soltanto un tentativo proprietario di proteggere un singolo fornitore. La pubblicazione tramite OCP invita a una revisione più ampia e a una potenziale partecipazione.

Tuttavia, l’apertura può rallentare le decisioni quando le aziende non concordano sui dettagli di implementazione. Un ecosistema amplia la propria portata accettando più partecipanti, ma il consenso e il lavoro di conformità richiedono tempo.

La specifica ha superato il primo ostacolo istituzionale. Ora arrivano la validazione del silicio, seguita dalla validazione del sistema, dal supporto software, dalla qualificazione dei clienti e dall’economia di produzione.

Un titolo può trattare la pubblicazione come un completamento. I mercati hardware la considerano l’inizio di un test più lungo.

HBF integra HBM e questo compromesso ne definisce il mercato

HBF vince solo se la capacità aggiuntiva compensa i suoi costi di latenza e integrazione senza indebolire i carichi di lavoro che dovrebbe supportare.

Definire HBF un sostituto di HBM crea il confronto sbagliato. SK hynix lo posiziona esplicitamente tra HBM e SSD, mentre HBM mantiene la responsabilità per la fascia di larghezza di banda più esigente.

Questa distinzione protegge l’architettura da uno standard irrealistico. HBF basata su NAND non deve superare la DRAM in ogni operazione. Deve rendere utile un pool di memoria più ampio con prestazioni accettabili.

Sandisk aveva in precedenza affermato che HBF potrebbe offrire da otto a 16 volte la capacità di HBM a un costo simile. L’attuale specifica aperta è più prudente: definisce configurazioni e livelli di prestazione invece di dimostrare tale affermazione economica.

Anche il confronto di capacità cambierà nel tempo. I fornitori di HBM continuano ad aumentare capacità e larghezza di banda degli stack, quindi HBF compete con un riferimento in evoluzione.

HBM beneficia di un supporto consolidato da parte degli acceleratori e della domanda produttiva. Roadmap dei processori, investimenti nel packaging, controller di memoria e strumenti software ruotano già attorno a essa.

HBF parte senza questa base installata. Il suo vantaggio proposto è la densità, non la maturità.

Gli SSD esercitano pressione dall’altro lato. Non possono eguagliare un livello di memoria nel package, ma i miglioramenti a software e interconnessioni possono rendere lo storage più utile per i carichi di lavoro AI.

I progettisti di sistemi potrebbero decidere che una cache SSD migliorata offra prestazioni sufficienti con un rischio di integrazione inferiore. Altri potrebbero riservare pool HBM più ampi ai carichi di lavoro premium invece di aggiungere un terzo livello.

HBF deve superare queste alternative a livello di sistema completo. Un favorevole costo per bit non aiuta se controller aggiuntivi, area del package, raffreddamento o software annullano i risparmi.

Le affermazioni sul consumo energetico richiedono analoga cautela. La NAND conserva le informazioni senza alimentazione di refresh, offrendo un vantaggio strutturale per i dati memorizzati.

Tuttavia, il consumo energetico include anche movimento dei dati, correzione degli errori, controller e gestione termica. La metrica rilevante è l’energia per inferenza completata, non la caratteristica di potenza isolata di un componente.

Il livello di gestione della memoria diventa decisivo. Il software deve identificare i dati usati frequentemente, collocarli in modo appropriato e spostarli prima che il processore si fermi.

Questo requisito crea opportunità per i fornitori di acceleratori e gli operatori cloud. Essi controllano pianificazione, comportamento del compilatore, serving dei modelli e telemetria che possono guidare il posizionamento.

Crea anche un rischio di lock-in. Un’interfaccia fisica aperta non garantisce che il software di livello superiore resti portabile tra processori e fornitori di memoria.

Gli sviluppatori avranno bisogno di strumenti che espongano il comportamento di HBF senza costringere ogni team di modelli a gestire manualmente le pagine. Altrimenti, solo i maggiori operatori di infrastrutture potrebbero ottenere vantaggi costanti.

I primi carichi di lavoro interessanti condivideranno probabilmente diverse caratteristiche. Saranno ad alta lettura, limitati dalla capacità, tolleranti a una certa latenza aggiuntiva e abbastanza importanti da giustificare hardware specializzato.

Il serving di modelli di grandi dimensioni corrisponde a questo profilo. Anche i sistemi di retrieval, i modelli di raccomandazione e alcune applicazioni multimodali potrebbero trarne vantaggio quando i dati attivi superano la capacità HBM pratica.

Non tutti i compiti AI lo fanno. I modelli piccoli che rientrano comodamente nella memoria esistente guadagnano poco da un altro livello. Le applicazioni sensibili alla latenza con schemi di accesso irregolari potrebbero preferire HBM nonostante i suoi limiti di capacità.

L’addestramento presenta un caso più difficile perché legge e scrive ripetutamente grandi strutture di dati. La narrativa iniziale su HBF si concentra sull’inferenza per una buona ragione.

Questo compromesso mantiene l’annuncio con i piedi per terra. HBF non elimina la gerarchia di memoria. Aggiunge un altro livello e chiede ai progettisti di sistemi di gestire tale gerarchia in modo più intelligente.

La strategia più ampia di SK hynix rafforza questa visione. L’azienda promuove un portafoglio che comprende HBM, DRAM convenzionale, NAND, SSD enterprise e livelli di memoria emergenti.

Questo portafoglio può ridurre la concorrenza interna tra HBM e HBF. SK hynix può supportare qualunque combinazione scelgano i clienti, sebbene l’economia dei singoli prodotti influenzerà comunque le sue priorità.

Sandisk ha un incentivo diverso. La sua concentrazione nel flash rende l’inferenza AI un’opportunità per avvicinare la NAND al calcolo ad alto valore.

La partnership allinea tali incentivi attorno a uno standard comune. Non elimina la concorrenza di Samsung, Micron, Kioxia, dei fornitori di processori o di architetture di memoria alternative.

La partecipazione dei concorrenti rafforzerebbe HBF come categoria industriale. Potrebbe anche indebolire la capacità di Sandisk e SK hynix di differenziare i propri prodotti.

Questa è una tensione salutare per uno standard aperto. Un’adozione ampia richiede solitamente che i fornitori cedano parte del controllo in cambio di un mercato più grande.

Tre segnali mostreranno se HBF andrà oltre il titolo

Le prossime prove dovranno arrivare da campioni, impegni sui processori e carichi di lavoro misurati, non da un’altra presentazione della specifica.

Il primo segnale è silicio HBF funzionante legato alla nuova specifica. La roadmap precedente di Sandisk collocava i campioni iniziali nella seconda metà del 2026, lasciando una finestra limitata per l’esecuzione.

Un utile annuncio sui campioni dovrebbe identificare capacità, livello di larghezza di banda, configurazione del package e stato dei test. Dovrebbe inoltre distinguere i campioni interni di ingegneria dall’hardware disponibile per i clienti.

Test indipendenti o da parte dei clienti rafforzerebbero ulteriormente il caso. Latenza misurata, larghezza di banda sostenuta, potenza, resistenza e temperatura contano più di un valore di trasferimento di picco.

Se campioni conformi appariranno nei tempi previsti, la specifica acquisirà credibilità come base di prodotto. Un ritardo suggerirebbe che packaging, comportamento della NAND, controller o produzione rimangono irrisolti.

Il secondo segnale è un processore o una piattaforma cloud identificati. Google e Tenstorrent partecipano al consorzio, ma né la partecipazione né le apparizioni in panel confermano l’adozione commerciale.

Un impegno serio collegherebbe HBF a una roadmap di processore, un package di riferimento, una scheda di sviluppo o una distribuzione cloud. Identificherebbe inoltre come il software assegna i dati tra HBM e HBF.

Osservate il supporto del controller e gli strumenti per sviluppatori insieme all’hardware. Un dispositivo di memoria privo di software per pianificazione, profiling e posizionamento non può offrire il suo pieno beneficio di sistema.

Una piattaforma impegnata non garantirebbe uno standard industriale. Stabilirebbe che un progettista di processori vede un valore sufficiente da assorbire il costo di integrazione.

Diversi partecipanti tra processori o cloud sosterrebbero la tesi dell’ecosistema aperto. Una singola implementazione proprietaria restringerebbe il ruolo di HBF e aumenterebbe la dipendenza da un solo cliente.

Il terzo segnale è la prova dei carichi di lavoro sotto vincoli realistici. La simulazione di Sandisk offre un’ipotesi di partenza, ma i sistemi di produzione devono gestire HBM finita, richieste miste, limiti termici e schemi di accesso variabili.

I benchmark dovrebbero confrontare configurazioni complete, non componenti isolati. Un sistema HBF deve dimostrare throughput, latenza, energia e costo rispetto a pool HBM più grandi o alternative supportate da SSD.

I test più informativi copriranno l’inferenza di grandi modelli con più utenti simultanei. Dovrebbero inoltre spiegare precisione del modello, dimensione del batch, lunghezza del contesto, politica di caching e utilizzo del processore.

Un risultato favorevole mostrerebbe che HBF mantiene occupate costose unità di calcolo supportando al contempo modelli attivi più grandi. Rafforzerebbe il caso della memoria a livelli mentre l’inferenza cresce.

Risultati deboli esporrebbero il costo della latenza NAND o del movimento dei dati. Potrebbero confinare HBF a utilizzi più ristretti, nei quali la capacità conta più del tempo di risposta.

Il rilascio della specifica tramite OCP offre a ricercatori e potenziali adottanti una base condivisa per tali valutazioni. Il lancio dell’open workstream mostra inoltre che le aziende intendono reclutare un ecosistema anziché mantenere HBF chiuso.

I lettori che seguono la storia tramite Google News dovrebbero distinguere ogni futura tappa. Un membro del consorzio, un campione, un dispositivo integrato e una distribuzione in produzione rappresentano livelli di prova molto diversi.

Sandisk e SK hynix hanno completato il primo di questi stadi. Hanno definito un’architettura aperta con obiettivi chiari di capacità, larghezza di banda, interfaccia, packaging e software.

Ora l’onere passa dal documento degli standard ai team di ingegneria. Devono dimostrare che HBF può essere prodotto in modo affidabile, connesso tra processori e gestito senza creare un nuovo e costoso collo di bottiglia.

Il risultato conta oltre le due aziende di memoria. Hardware HBF di successo offrirebbe ai progettisti di sistemi AI un altro modo per bilanciare capacità, larghezza di banda, energia e costo.

Anche un fallimento offrirebbe una lezione utile. Mostrerebbe che il divario tra HBM e SSD non può essere colmato semplicemente avvicinando NAND densa al calcolo tramite packaging.

Il prossimo titolo di Google News che vale la pena aprire dovrebbe quindi contenere più di un’altra partnership. Cercate silicio misurabile, un processore identificato e un risultato di carico di lavoro che un’altra organizzazione possa esaminare.

Finché quei segnali non arriveranno, HBF è una proposta insolitamente dettagliata con sponsor credibili. Non è ancora un livello dimostrato nell’infrastruttura AI di produzione.

Seguite i campioni, le integrazioni e i benchmark piuttosto che il numero degli annunci. Quale fornitore di processori sarà il primo a dimostrare che HBF aperto può migliorare un sistema di inferenza reale?