La scommessa di VAST Data su AMD Blocks sfida il controllo di Nvidia sull'infrastruttura AI

VAST Data ha ampliato la propria partnership con AMD su sei livelli dell'infrastruttura, trasformando la storia di amd blocks in una sfida diretta ai sistemi AI incentrati su Nvidia.

L'accordo collega l'AI Operating System di VAST ai processori AMD EPYC di sesta generazione, alle GPU Instinct, ai rack Helios, al networking Pensando, al software ROCm e allo storage condiviso per l'inferenza. VAST utilizzerà inoltre chip EPYC nel suo prossimo hardware CBox ed EBox.

Questa portata conta più di un semplice annuncio di compatibilità. VAST ha già stretti legami con Nvidia e con i provider cloud che distribuiscono acceleratori Nvidia. Ora sta costruendo un percorso AMD che si estende dai dati archiviati ai token generati.

Il cambiamento riflette una trasformazione più ampia nella spesa per l'AI. L'addestramento rimane importante, ma le imprese hanno sempre più bisogno di infrastrutture per inferenza continua, agenti di ragionamento e applicazioni basate sul retrieval. Questi carichi di lavoro spostano ripetutamente modelli, prompt e contesto riutilizzabile tra storage, memoria, CPU e GPU.

AMD fornisce i componenti di calcolo. VAST vuole coordinare i dati che li circondano. Se il loro progetto funzionerà sotto carichi di produzione, gli acquirenti avranno un'alternativa più completa al modello di infrastruttura integrata di Nvidia.

La domanda centrale non è se AMD possa fornire un acceleratore veloce. È se AMD e i suoi partner possano far sì che un intero sistema AI si comporti come un unico prodotto.

La partnership AMD Blocks va oltre il supporto alle GPU

VAST considera AMD una base infrastrutturale, non un'opzione di acceleratore aggiunta alla fine di un ciclo di vendita.

La collaborazione ampliata è stata resa nota in occasione dell'evento Advancing AI 2026 di AMD a San Francisco, il 22 e 23 luglio. Le aziende hanno descritto una piattaforma comune per addestramento, inferenza, reinforcement learning e AI agentica.

Il primo impegno riguarda gli appliance di VAST. I processori EPYC di sesta generazione, precedentemente noti con il nome in codice Venice, alimenteranno la sesta generazione dei sistemi VAST CBox e la terza generazione dei sistemi EBox.

I sistemi CBox eseguono servizi dati e operazioni sui metadati nell'architettura VAST. I sistemi EBox forniscono la capacità di storage sottostante e i percorsi dati. L'integrazione dei processori EPYC in entrambe le linee di prodotto assegna ad AMD un ruolo all'interno della piattaforma VAST, anche quando i clienti utilizzano altri acceleratori.

La nuova generazione EPYC supporta PCI Express 6.0. Questa interconnessione offre il doppio della larghezza di banda teorica di PCI Express 5.0, migliorando potenzialmente il trasferimento tra processori, storage, dispositivi di rete e acceleratori collegati.

VAST afferma che la larghezza di banda aggiuntiva dovrebbe agevolare i suoi servizi di file, oggetti, database, warehouse e streaming di eventi. Tuttavia, le prestazioni applicative dipenderanno ancora dal comportamento del software, dalla profondità delle code, dal design di rete e dalla concorrenza dei carichi di lavoro.

La collaborazione copre anche una Reference Architecture per l'infrastruttura AI sviluppata con DriveNets. Il progetto combina VAST AI OS, sistemi AMD Helios a scala rack e networking DriveNets AI Fabric.

Una reference architecture è un modello di distribuzione documentato con scelte dei componenti, indicazioni di dimensionamento e connessioni validate. Riduce il lavoro di progettazione, ma non dimostra che ogni carico di lavoro cliente raggiungerà lo stesso obiettivo prestazionale.

Le indicazioni previste riguardano addestramento dei modelli, inferenza, reinforcement learning e carichi di lavoro con cache chiave-valore. Una cache chiave-valore, solitamente abbreviata in cache KV, conserva dati di attenzione che un modello linguistico può riutilizzare mentre genera token successivi.

TensorMesh e EmbeddedLLM partecipano a ulteriori attività sull'inferenza. Il loro coinvolgimento estende il progetto oltre la qualificazione dei processori, includendo il deployment software per applicazioni agentiche di produzione.

La copertura originale cita inoltre sette provider cloud AI che utilizzano servizi correlati ad AMD: 5C, Core42, Crusoe, EmbeddedLLM, Phanos.AI, TensorWave e Vultr.

Questo elenco di clienti dimostra attività di deployment già in corso, ma non rivela quanta capacità gestisca ciascun provider. Non stabilisce neppure se i clienti utilizzino il progetto completo di VAST, AMD e DriveNets.

Ciononostante, l'ampiezza degli impegni rende questa iniziativa più estesa di un semplice badge di certificazione. AMD entra nella roadmap di prodotto di VAST, nella sua reference architecture, nel suo software di inferenza e nella sua storia di deployment presso i clienti.

La partnership crea quindi un test misurabile. Gli acquirenti potranno valutarla attraverso sistemi rilasciati, progetti documentati, benchmark pubblici e referenze di produzione, anziché tramite dichiarazioni generiche sull'apertura.

L'inferenza trasforma il contesto archiviato in un problema di calcolo

La partnership arriva ora perché l'inferenza rende lo spostamento dei dati parte del percorso critico di ogni risposta.

L'addestramento tradizionale dei modelli concentra un'enorme capacità di calcolo in esecuzioni pianificate. L'inferenza di produzione si comporta diversamente. Serve molte richieste simultanee, mantiene il contesto utente, recupera informazioni esterne e spesso genera lunghe sequenze di ragionamento.

Questo schema può lasciare gli acceleratori costosi in attesa. Una GPU può avere capacità aritmetica sufficiente, ma bloccarsi comunque mentre il sistema carica i pesi del modello, recupera documenti o ricostruisce contesto generato in precedenza.

VAST sostiene che l'inferenza sia fondamentalmente un problema di dati. L'affermazione è credibile nella sua direzione generale, anche se calcolo, networking e pianificazione software restano altrettanto importanti in molti deployment.

Prompt lunghi e conversazioni multi-turno ampliano la cache KV associata a ciascuna richiesta attiva. Conservare ogni voce della cache nella memoria GPU offre una bassa latenza, ma la memoria degli acceleratori è limitata e costosa.

Eliminare la cache consente di risparmiare spazio, ma obbliga il modello a ricalcolare gli stati di attenzione precedenti. Spostare voci selezionate nella memoria host o nello storage condiviso crea un'altra possibilità, a condizione che il sistema possa recuperarle abbastanza rapidamente.

VAST e AMD stanno testando questa terza strada. La loro integrazione combina GPU Instinct, AMD Infinity Context, software ROCm e storage VAST per scaricare voci riutilizzabili della cache KV.

Il percorso dati utilizza la scheda di interfaccia di rete AMD Pensando Pollara 400. Trasferisce informazioni tra memoria GPU e storage NVMe di VAST su NFS usando TCP o l'accesso diretto remoto alla memoria.

L'accesso diretto remoto alla memoria, o RDMA, consente a un sistema di accedere alla memoria di un altro sistema con un coinvolgimento limitato della CPU. Nella rete giusta, può ridurre latenza e overhead del processore durante trasferimenti ripetuti.

VAST prevede inoltre controlli automatizzati del ciclo di vita della cache. Gli amministratori potrebbero applicare policy che fanno scadere ed eliminano il contesto archiviato contenente informazioni personali, riservate o regolamentate.

Questa funzionalità affronta una conseguenza meno visibile dell'offloading della cache. Una volta che lo stato transitorio del modello si sposta nello storage condiviso, diventa un dato soggetto a governance anziché memoria GPU temporanea.

Le imprese devono sapere quale utente o applicazione ha creato la cache, per quanto tempo rimane disponibile e se un altro tenant può accedervi. Hanno inoltre bisogno di controlli di eliminazione che funzionino tra repliche e sistemi di ripristino.

Il contesto condiviso potrebbe migliorare l'utilizzo in varie situazioni. Un agente di assistenza clienti potrebbe riutilizzare un lungo manuale di prodotto in migliaia di conversazioni. Un assistente di programmazione potrebbe conservare il contesto del repository tra attività correlate.

Un sistema di ricerca potrebbe preservare documenti elaborati mentre diversi agenti esaminano le stesse evidenze. Un servizio di ragionamento potrebbe spostare conversazioni inattive fuori dalla memoria degli acceleratori, per poi ripristinarle quando gli utenti tornano.

Questi scenari spiegano perché i fornitori di storage si stiano avvicinando al software di inferenza. Il loro ruolo non termina più quando un checkpoint del modello raggiunge un cluster di GPU.

L'architettura di VAST, chiamata Disaggregated Shared Everything, separa le risorse di calcolo e storage presentando al contempo uno spazio dati comune. L'azienda afferma che questo modello supporta protocolli multipli, tenant isolati e uno spazio dei nomi globale.

Il progetto è adatto ai cloud AI che devono servire molti clienti da un'infrastruttura comune. Crea però anche più dipendenze tra i livelli di storage, rete, runtime e acceleratori.

VAST ha riportato test iniziali con una GPU Instinct MI355X. L'azienda afferma che l'offloading remoto della cache ha prodotto un miglioramento di nove volte nel tempo al primo token e un throughput di token 9,7 volte superiore.

Il tempo al primo token misura il ritardo prima che un modello inizi a rispondere. Il throughput di token misura quanta produzione generata il sistema realizza nel tempo, soprattutto in presenza di domanda simultanea.

Questi dati provengono da un confronto specifico tra l'offloading della cache nella memoria host locale e una partizione VAST remota su NFS con RDMA. Non erano risultati ottenuti contro hardware Nvidia o in un ambiente di produzione completo.

La distinzione è importante. I numeri supportano un meccanismo di storage nelle condizioni testate. Non dimostrano che ogni deployment VAST e AMD produrrà un miglioramento di nove volte.

Anche così, l'esperimento individua il meccanismo alla base della partnership. Le aziende non sostengono che lo storage renda una GPU intrinsecamente più veloce. Stanno cercando di ridurre il lavoro ripetuto e mantenere gli acceleratori occupati.

AMD ha bisogno di partner per contrastare lo stack integrato di Nvidia

La competizione principale contrappone un sistema AMD aperto e costruito con i partner allo stack infrastrutturale strettamente coordinato di Nvidia.

Il vantaggio di Nvidia va oltre le prestazioni degli acceleratori. CUDA, networking, sistemi, librerie, strumenti di deployment e conoscenze operative consolidate riducono tutti l'attrito per gli acquirenti.

Questa base installata influenza le decisioni di acquisto. Un'impresa che sceglie Nvidia può spesso trovare ingegneri esperti, framework testati, capacità cloud gestita e modelli di deployment già esistenti.

AMD sta affrontando lo stesso problema costruendo una quota maggiore della piattaforma circostante. La sua strategia combina CPU EPYC, GPU Instinct, networking Pensando, rack Helios e software ROCm.

VAST colma una lacuna significativa in questa raccolta. Fornisce servizi dati in grado di alimentare gli acceleratori, conservare gli asset dei modelli, gestire il contesto di inferenza e supportare le applicazioni attorno ai modelli.

La logica competitiva è chiara. AMD non deve possedere ogni livello se i partner possono integrare tali livelli in un sistema coerente.

Questo approccio può preservare la scelta degli acquirenti. Un cloud AI potrebbe oggi combinare i servizi dati VAST con acceleratori AMD, mantenendo poi una certa capacità Nvidia per carichi di lavoro legati a CUDA.

VAST beneficia inoltre dell'evitare la dipendenza da un solo fornitore di GPU. I suoi clienti vogliono sempre più accedere a diversi tipi di acceleratori, poiché disponibilità, adeguatezza al carico di lavoro e requisiti software variano.

L'azienda non sta abbandonando Nvidia. Il suo lavoro più approfondito con AMD posiziona invece VAST come infrastruttura dati comune per flotte AI eterogenee.

Questo rende la strategia amd blocks una forma di concorrenza modulare. Ogni blocco ha un ruolo definito, ma il sistema completo dipende da standard e ingegneria tra fornitori.

AMD ha ripetuto questo schema anche altrove. La sua partnership con Nutanix combina EPYC, Instinct, ROCm, orchestrazione cloud e gestione del ciclo di vita aziendale.

AMD ha impegnato un investimento azionario e finanziamenti per l'ingegneria in quell'accordo. La struttura commerciale differisce dall'annuncio VAST, ma entrambi puntano alle imprese che cercano un'alternativa alle piattaforme AI verticalmente integrate.

AMD ha inoltre collaborato con Red Hat, Oracle, Microsoft, importanti sviluppatori di modelli e progetti di software per l'inferenza. Il suo ecosistema software include framework e fornitori di modelli in grado di ridurre le lacune di compatibilità a livello applicativo.

VAST contribuisce a un livello diverso. Si concentra sul percorso che porta dalle informazioni archiviate al contesto attivo del modello, dove spostamenti inefficienti possono annullare i vantaggi offerti da processori più veloci.

Il design Helios di AMD alza ulteriormente la posta in gioco. Helios integra CPU, GPU, networking e software in un sistema a livello di rack, invece di chiedere ai clienti di assemblare autonomamente server con acceleratori.

L'analista indipendente Steve McDowell ha descritto la configurazione Helios del 2026 come composta da 72 GPU MI455X e 18 CPU Venice in un singolo rack raffreddato a liquido. La sua analisi di Helios inquadra la sfida di AMD nel trasformare i progressi hardware in capacità effettivamente implementata, paragonabile alla scala di Nvidia.

L'architettura di riferimento VAST e DriveNets circonda quel rack con dati e networking scale-out. Insieme, questi componenti avvicinano AMD a un sistema acquistabile, anziché a un catalogo di chip.

Tuttavia, la modularità introduce costi di coordinamento. I clienti necessitano di firmware, driver, impostazioni di rete, policy di storage, versioni runtime, osservabilità ed escalation del supporto allineati.

Nvidia può risolvere una quota maggiore di questi problemi all'interno di un'unica struttura aziendale. Un design basato su AMD distribuisce la responsabilità tra diverse aziende.

Questa differenza è il compromesso centrale. Uno stack costruito dai partner offre flessibilità e leva negoziale, ma la sua esperienza operativa deve avvicinarsi alla coerenza di una piattaforma strettamente integrata.

VAST può ridurre questo onere tramite design di riferimento documentati e configurazioni testate. Non può eliminare la necessità di supporto congiunto tra fornitori indipendenti.

La pressione di mercato ricade anzitutto sui provider cloud AI incentrati su Nvidia e sulle imprese che pianificano il prossimo ciclo di capacità. Ora dispongono di un'altra architettura da valutare prima di estendere un'infrastruttura basata su un unico fornitore.

Mette pressione anche su AMD. Le partnership pubbliche accrescono le aspettative riguardo a sistemi disponibili, benchmark ripetibili e clienti disposti a eseguire carichi di lavoro di valore al di fuori dell'ambiente Nvidia.

Il risultato di 9,7x necessita di una verifica nella realtà produttiva

Il benchmark della cache di VAST è incoraggiante, ma il suo riferimento ristretto non può definire da solo il caso aziendale per l'architettura combinata.

Il guadagno di throughput dichiarato di 9,7 volte confronta due metodi di posizionamento della cache all'interno di un test basato su AMD. Non confronta sistemi AMD e Nvidia completi, né divulga un benchmark standard di settore.

Molti dettagli possono modificare il risultato. Dimensione della cache, lunghezza del prompt, concorrenza delle richieste, architettura del modello, memoria host disponibile, distanza dello storage, congestione di rete e tasso di cache hit incidono tutti sulle prestazioni.

La scelta del riferimento conta particolarmente. La memoria host locale sembra più veloce dello storage remoto, ma la pressione sulla capacità e i modelli di accesso possono ribaltare questa aspettativa in presenza di elevata concorrenza.

Una partizione VAST remota può aggregare capacità tra server e preservare più contesto riutilizzabile. Se il riferimento basato sulla memoria locale espelle frequentemente voci utili, lo storage remoto può evitare una notevole rielaborazione.

Si tratta di un vantaggio di sistema valido. Richiede comunque che gli acquirenti comprendano con precisione quando si manifesta.

VAST riconosce che gli incrementi relativi di velocità dipendono dall'hardware sottostante. Un sistema con capacità di calcolo o latenza di storage differenti può produrre un rapporto diverso.

I carichi di lavoro in produzione combinano inoltre diversi tipi di richieste. Alcune conversazioni sono brevi e traggono pochi vantaggi da una cache persistente. Altre contengono contesti ampi, ma ritornano troppo di rado per giustificare la conservazione del loro stato.

Il riutilizzo della cache crea un'altra incertezza. L'offloading genera valore solo quando una richiesta successiva può riutilizzare le informazioni archiviate a un costo inferiore rispetto al ricalcolo.

Gli amministratori necessitano quindi di policy di ammissione ed espulsione. Il sistema deve decidere quali voci meritano di essere archiviate, quali devono rimanere nella memoria dell'acceleratore e quali devono essere eliminate.

I controlli di sicurezza richiedono un esame altrettanto rigoroso. Una cache KV archiviata può codificare informazioni sensibili provenienti da prompt, documenti recuperati e output precedenti del modello.

Le policy di eliminazione automatizzata aiutano, ma gli acquirenti avranno bisogno di prove riguardo isolamento dei tenant, crittografia, log di accesso, replica, comportamento dei backup e cancellazione verificabile.

Anche la qualità dell'inferenza entra in gioco. Una cache obsoleta o associata in modo errato potrebbe produrre output non validi, contaminazione tra utenti o errori difficili da diagnosticare.

L'annuncio della collaborazione descrive la gestione del ciclo di vita, ma non pubblica un modello di minaccia completo. Non spiega neppure come l'applicazione delle policy funzioni in tutti i runtime di inferenza supportati.

La titolarità operativa rimane irrisolta. Un problema di latenza potrebbe avere origine in ROCm, nel server del modello, nel networking Pollara, nel fabric DriveNets, nelle impostazioni NFS, nel software VAST o nell'applicazione stessa.

Le architetture di riferimento possono definire versioni supportate e procedure diagnostiche. Le referenze dei clienti riveleranno se tali procedure funzionano durante incidenti reali.

La stessa cautela vale per le più ampie dichiarazioni prestazionali di AMD. I test interni possono guidare la valutazione, ma gli acquirenti dovrebbero riprodurre i risultati con i propri modelli, prompt, livelli di concorrenza e obiettivi di livello di servizio.

Un'impresa dovrebbe confrontare il comportamento complessivo del sistema, anziché limitarsi alle specifiche degli acceleratori. Le misure importanti includono richieste completate per rack, latenza del primo token, latenza dei token in output, consumo energetico, tassi di cache hit, ripristino dagli errori e tempo di ingegneria.

La collaborazione ampliata descrive una maggiore efficienza e prestazioni migliori. Non divulga prezzi per i clienti, durata dell'implementazione o risparmi di produzione sottoposti ad audit.

Questa assenza è normale per un annuncio di architettura iniziale. Significa anche che la conclusione commerciale resta aperta.

L'approccio amd blocks sarà credibile quando più clienti riporteranno risultati prevedibili di implementazione e gestione. Una grande dimostrazione a un evento del fornitore è utile, ma è la ripetibilità a creare fiducia.

VAST e AMD affrontano inoltre un bersaglio in movimento. Nvidia continua a migliorare networking, software per l'inferenza, integrazione dello storage e sistemi a livello di rack.

Altre aziende di storage stanno perseguendo la stessa opportunità di alimentare le GPU. Weka, DDN, Dell, HPE, Pure Storage e piattaforme dati cloud-native vogliono tutte assumere un ruolo più ampio nell'infrastruttura AI.

I clienti hanno dunque più di due possibilità. Possono usare uno stack Nvidia integrato, assemblare sistemi basati su AMD o gestire cluster misti con infrastruttura dati separata.

La strada vincente varierà in base al carico di lavoro. Un'azienda legata a software specifico per CUDA potrebbe accettare una minore scelta hardware per ridurre il lavoro di migrazione.

Un cloud AI che serve modelli aperti con elevata concorrenza potrebbe invece attribuire maggior valore alla diversità degli acceleratori e alla capacità di cache condivisa. Le grandi imprese potrebbero privilegiare la responsabilità del supporto e i controlli di conformità rispetto ai rapporti di benchmark di picco.

Queste distinzioni impediscono che l'annuncio diventi un semplice confronto AMD contro Nvidia. Si tratta di un'opzione architetturale che deve guadagnarsi il proprio posto attraverso prove specifiche per ciascun carico di lavoro.

Tre segnali mostreranno se la strategia funziona

La prossima fase dipende dalla spedizione di sistemi di riferimento, dalla pubblicazione di risultati riproducibili e dalla dimostrazione di adozione oltre le partnership nominate.

Il primo segnale è la disponibilità delle prossime generazioni CBox ed EBox di VAST, basate su processori EPYC di sesta generazione. I sistemi spediti trasformeranno un impegno di roadmap in apparecchiature che i clienti potranno qualificare.

Gli acquirenti dovrebbero osservare configurazioni supportate, date di disponibilità generale, percorsi di aggiornamento e linee guida per l'implementazione. Un'ampia disponibilità rafforzerebbe l'affermazione che AMD sta diventando una piattaforma VAST standard.

Ritardi o configurazioni limitate indebolirebbero questa conclusione. Suggerirebbero che la partnership sia più avanzata nel marketing che nelle operazioni di prodotto.

Il secondo segnale è l'ampliamento dei test della cache KV. Una divulgazione utile includerebbe modelli, lunghezze del contesto, livelli di concorrenza, tassi di cache hit, topologia di rete e distribuzioni della latenza.

Le prove più solide deriverebbero da test condotti dai clienti o da istruzioni per benchmark riproducibili. Risultati su diversi modelli e motori di inferenza mostrerebbero se il meccanismo si trasferisce oltre un singolo carico di lavoro controllato.

Un miglioramento ripetuto rafforzerebbe l'argomento a favore dello storage condiviso come infrastruttura attiva per l'inferenza. Guadagni minori o incoerenti restringerebbero i casi d'uso indirizzabili dalla tecnologia.

Il terzo segnale è l'adozione in produzione dell'architettura di riferimento congiunta. I clienti nominati mostrano già interesse per la capacità AMD, ma contano di più le implementazioni del design completo.

Osservate i clienti che collegano rack Helios, networking DriveNets, VAST AI OS e inferenza basata su ROCm in un unico ambiente supportato. I loro report operativi dovrebbero includere utilizzo, affidabilità e tempi di rollout.

L'espansione presso i clienti convaliderebbe la risposta guidata dai partner di AMD al vantaggio di integrazione di Nvidia. Progetti pilota isolati mostrerebbero che la sola scelta tecnica non supera la familiarità con il software e la complessità del supporto.

La roadmap di AMD aggiunge urgenza. L'azienda aveva precedentemente indicato la disponibilità di Helios nel corso del 2026 e segnalato una crescente adozione di ROCm nella sua strategia per il data center.

VAST offre a questa strategia un livello dati più solido. Crea anche un banco di prova impegnativo, poiché lo storage e la gestione del contesto si trovano direttamente sul percorso di latenza visibile all'utente.

Gli sviluppatori dovrebbero interessarsene perché le scelte infrastrutturali determinano quali modelli, runtime e strumenti di ottimizzazione restano pratici. Un migliore supporto AMD può ridurre la dipendenza da software progettato attorno a un'unica piattaforma di acceleratori.

Gli operatori di cloud AI dovrebbero interessarsene perché il tempo GPU inutilizzato riduce direttamente la capacità di servizio disponibile. Il contesto condiviso può essere utile solo se i relativi costi di storage e rete restano inferiori al ricalcolo che sostituisce.

Gli acquirenti enterprise dovrebbero interessarsene perché i dati di inferenza hanno requisiti di governance. Spostare il contesto memorizzato nella cache verso storage gestito può migliorare il controllo, ma amplia anche il perimetro di sicurezza.

I knowledge worker sperimenteranno il risultato indirettamente. Se i sistemi preservano in modo efficiente il contesto utile, gli assistenti possono gestire progetti più lunghi senza ricostruire ripetutamente lo stesso background.

Questo risultato dipende anche da come le applicazioni organizzano il materiale sorgente. Una base di conoscenza AI ben mantenuta può migliorare il recupero delle informazioni prima ancora che inizi qualsiasi ottimizzazione dell'infrastruttura.

La strategia amd blocks non è quindi una dichiarazione secondo cui AMD ha sostituito Nvidia. È un piano per rendere il calcolo AMD più facile da implementare come parte di un sistema di inferenza completo.

VAST ha impegnato hardware, software, networking, gestione della cache e design di riferimento in questo piano. Il lavoro rimanente consiste nella convalida pubblica a fronte di una domanda dei clienti mista e sostenuta.

Nei prossimi mesi, ignorate le affermazioni generiche su apertura o fabbriche AI. Cercate appliance VAST effettivamente spedite, risultati della cache riproducibili e clienti che gestiscono l'architettura completa.

Questi tre segnali mostreranno se la partnership crea una seconda strada credibile per l'infrastruttura AI, oppure semplicemente un'altra raccolta di componenti compatibili.