Ken Claffey, CEO di VDURA – Intervista: un ritorno alla conversazione

Ken Claffey, CEO e Presidente di VDURA, è un leader di business e prodotti con esperienza approfondita nel settore cloud e infrastrutture aziendali, sviluppo di hardware e software e crescita strategica attraverso funzioni di prodotto, operazioni e mercato. Nel corso della sua carriera, ha costruito e guidato team di alto livello a livello globale, ha eseguito la strategia aziendale, ha guidato la crescita dei ricavi e l’innovazione dei prodotti e ha trasformato aziende sottoprestanti. Prima di assumere la guida di VDURA, Claffey ha ricoperto ruoli di leadership senior in Seagate Technology (STX ), dove ha lavorato come SVP e General Manager sovraintendendo ai sistemi aziendali e al P&L, e in precedenza ha ricoperto posizioni di leadership in Xyratex, Adaptec e Eurologic, portando con sé decenni di esperienza nel settore dello storage aziendale e del calcolo ad alte prestazioni.

VDURA è un’azienda di infrastrutture di dati definite dal software che costruisce soluzioni di storage moderne ottimizzate per carichi di lavoro di intelligenza artificiale e calcolo ad alte prestazioni sotto il motto “velocità incontra durabilità”. La piattaforma di storage VDURA combina le prestazioni del file system parallelo flash-first con la resilienza dello storage degli oggetti in un’architettura unificata che si scala linearmente attraverso migliaia di client e nodi, semplificando le operazioni e riducendo il costo totale di proprietà. Fondata originariamente come Panasas e ribattezzata nel 2024, la piattaforma di VDURA supporta ambienti on-premises, cloud e ibridi con avanzata automazione, accelerazione dei metadati e prestazioni scalabili progettate per mantenere i cluster di GPU alimentati e i dati protetti per utilizzi aziendali, di ricerca e mission-critici di intelligenza artificiale e calcolo ad alte prestazioni.

Come ha influenzato il tuo percorso nel settore HPC e dello storage la tua visione secondo cui lo storage sta diventando il vincolo determinante nell’infrastruttura di intelligenza artificiale?

Aver costruito sistemi di storage per alcuni degli ambienti di calcolo più esigenti del mondo ti fa sviluppare un’intuizione per capire dove si trovano realmente i collo di bottiglia, piuttosto che dove la gente pensa che si trovino. A Xyratex e attraverso il lavoro su ClusterStor in Seagate, stavamo risolvendo problemi di storage per supercomputer dove la fisica era spietata. O si alimentava il calcolo o non lo si faceva.

Ciò che vedo ora nell’infrastruttura di intelligenza artificiale è lo stesso vincolo fondamentale, solo travestito da diverse economie. L’ossessione per le GPU nel mercato Neocloud era comprensibile. NVIDIA (NVDA ) ha creato una risorsa scarsa e trasformativa. Ma l’ipotesi che lo storage si sarebbe scalato facilmente e a buon mercato insieme a essa si è rivelata un’illusione. Si è rotta. Lo storage sta ora tendendo verso il 20-30% dei budget dell’infrastruttura di intelligenza artificiale nelle implementazioni all-flash, crescendo più velocemente di qualsiasi altro componente. Quando hai trascorso una carriera a guardare lo storage diventare il vincolo di binding in ogni ambiente di calcolo su larga scala, smetti di essere sorpreso quando il resto del mercato si rende conto di questa realtà.

Perché la pianificazione dello storage è stata depotenziata durante la corsa all’infrastruttura Neocloud?

Si sono verificate alcune ipotesi strutturali che si sono incontrate esattamente nel momento sbagliato. In primo luogo, i prezzi del flash erano temporaneamente favorevoli. Gli SSD NVMe erano abbastanza economici e abbondanti da far sembrare ragionevole l’adozione di una configurazione all-flash per default. Non era saggezza architettonica, ma il risultato di una finestra economica breve che gli operatori hanno scambiato per una condizione permanente.

In secondo luogo, la dinamica competitiva premia il numero di GPU sopra ogni altra cosa. Il mercato Neocloud stava venendo valutato in base a quanti chip NVIDIA si potevano inserire in un rack. Lo storage rappresentava all’incirca il 10% della voce di spesa, facile da approvare senza un’attenta verifica. In terzo luogo, la decisione di adottare una configurazione all-flash sembrava sicura perché eliminava la complessità. Un solo livello, un solo tipo di supporto, semplice da acquistare e gestire. Il problema è che “semplice” e “sostenibile economicamente” hanno smesso di essere la stessa cosa nel momento in cui la fornitura di NAND si è ridotta e i prezzi sono schizzati. A quel punto, le decisioni di infrastruttura erano già state prese.

Cosa sorprende maggiormente gli operatori quando vedono come lo storage sta influenzando l’utilizzo delle loro GPU?

La relazione è più diretta di quanto la maggior parte degli operatori si renda conto fino a quando non si trovano di fronte a GPU inattive. Le esecuzioni di training con checkpointing frequente creano richieste di scrittura a burst che possono bloccare il calcolo se lo strato di storage non può assorbirle abbastanza velocemente. Le pipeline di dati per il pre-elaboramento e l’ingestione creano richieste di throughput di lettura sostenute che, se non soddisfatte, possono privare le GPU di lavoro.

Le linee guida di NVIDIA per DGX quantificano questo: l’addestramento LLM basato su testo richiede circa 0,5 GB/s di throughput di lettura per GPU, mentre i carichi di lavoro di intelligenza artificiale e visualizzazione fisica richiedono circa 4 GB/s di letture e 2 GB/s di scritture per GPU. Se la tua architettura di storage non può fornire questo, non stai eseguendo le tue GPU a piena capacità. Stai eseguendo solo la frazione di lavoro che il tuo storage consente.

L’architettura conta enormemente a livello di cluster. Un sistema di storage che interpone un intermediario tra l’unità e il client può mostrare un throughput di intestazione comparabile su un singolo drive, ma a livello di scala potresti finire per aver bisogno di tre volte più dischi per saturare lo stesso parco di GPU. Tre volte gli SSD, tre volte la potenza, tre volte lo spazio nel rack. La matematica dell’utilizzo si complica rapidamente.

Che differenziali di costo possono emergere puramente dalla selezione degli SSD e dal design architettonico anche quando le metriche di throughput di intestazione appaiono simili?

Questo è il punto in cui gli operatori si trovano in seri guai, perché i numeri di intestazione possono essere genuinamente fuorvianti. Prendiamo un esempio rappresentativo. Un SSD NVMe QLC da 122,88 TB costa circa 27.000 dollari. Un’unità da 7,68 TB della stessa generazione offre un throughput sequenziale comparabile per circa 1.800 dollari. Per un cluster di 4.096 GPU su specifica Enhanced di NVIDIA, quella singola decisione di selezione della capacità produce una fattura flash che va da 600.000 a 9,6 milioni di dollari. Il throughput è effettivamente identico. L’unico variabile è quanto dati freddi si stanno scegliendo di parcheggiare su supporti premium che non offrono alcun beneficio di prestazioni aggiuntivo.

In aggiunta a ciò, il design architettonico determina il numero di dischi a livello di cluster. Un’architettura che fornisce circa 5,8 GB/s di throughput di lettura misurato per SSD ha bisogno di circa 353 dischi per saturare un cluster di 4.096 GPU. Un’architettura che fornisce circa 1,9 GB/s per SSD, a causa dell’overhead dell’intermediario, ha bisogno di oltre 1.000 dischi. A 12.000 dollari per unità da 30 TB, quella differenza non è un errore di arrotondamento – è una questione di modello di business.

Come dovrebbero rivedere gli operatori lo storage tutto-flash rispetto allo storage a livelli man mano che i prezzi del flash salgono e la fornitura di NAND rimane limitata?

Il punto di partenza è accettare che il presupposto economico dietro l’infrastruttura di intelligenza artificiale tutto-flash era sempre contingente, non fondamentale. Il CEO di Phison ha descritto la capacità di produzione di NAND come effettivamente allocata fino al 2026. Goldman Sachs (GS ) prevede che i prezzi della DRAM aumenteranno del doppio ogni trimestre fino allo stesso periodo. La scelta tutto-flash aveva senso quando il flash era economico e abbondante. Non lo è più.

La cornice giusta è chiedersi a cosa serve realmente il flash. Il flash è un mezzo di prestazioni. Dovrebbe essere dimensionato per saturare le richieste di throughput delle GPU, nient’altro. Tutto il resto, compresi i dati freddi, i checkpoint che non vengono attivamente letti e gli insiemi di addestramento archiviati, appartengono a dischi a densità elevata, che rimangono di diversi ordini di grandezza più economici per TB.

La trappola in cui cadono gli operatori è trattare il tiering come un’aggiunta: acquistare uno strato primario tutto-flash, aggiungere un archivio di oggetti per i dati freddi e connetterli con spostatori di dati esterni. Ciò introduce un secondo stack software, un secondo piano di dati, complessità di rete e sovraccarico operativo. L’approccio dei hyperscaler, che esegue SSD e HDD all’interno dello stesso stack software con tiering ad alte prestazioni nativo e senza spostatori di dati esterni, mantiene lo storage vicino al 10% del budget dell’infrastruttura mentre ancora soddisfa ogni GPU.

Che lezioni può trarre il livello Neocloud dal design delle scelte di storage dei hyperscaler?

La lezione più importante è che Google (GOOGL ), Meta e Microsoft (MSFT ) non eseguono tutto-flash, e hanno più esperienza di carichi di lavoro di intelligenza artificiale di chiunque altro. Implementano architetture a livelli misti con tiering intelligente: abbastanza flash NVMe per saturare il throughput delle GPU, poi scaricare su dischi a densità elevata il più velocemente possibile. Questo non è un preferenza filosofica. È un imperativo economico guidato da una chiara comprensione della fisica dei carichi di lavoro di intelligenza artificiale.

La seconda lezione è l’integrazione architettonica. I hyperscaler non risolvono il tiering assemblando sistemi separati. Eseguono SSD e HDD sullo stesso stack software, lo stesso piano di dati, con il tiering come un’operazione di primo livello all’interno del sistema di storage, non come un lavoro batch gestito da uno strumento separato. Quell’integrazione è ciò che consente loro di mantenere lo storage economico a scala enorme mentre mantiene le garanzie di prestazioni che i loro parchi di GPU richiedono.

La terza lezione è la garanzia di durabilità. AWS S3 offre 11 “nines” di durabilità. Azure Blob offre 12 o più. Le architetture HPC legacy costruite su RAID locali possono scendere al di sotto di 5 “nines” a livello di scala a seconda dei tassi di guasto dei dischi e delle finestre di ricostruzione, potenzialmente migliaia di file persi all’anno su un corpus di un miliardo di file. Il codice di cancellazione della rete moderno con protezione multilivello può superare gli 11 “nines”. Il divario tra quelle due realtà è la differenza tra un sistema di storage che puoi effettivamente garantire con un contratto di servizio e uno che non puoi.

Come dovrebbero quantificare i team di infrastruttura l’impatto economico della disponibilità dello storage sui parchi di GPU?

La matematica è sobria quando la si esegue onestamente. Il guasto dello storage condiviso non produce un deficit di SLA proporzionale. Produce una violazione simultanea su ogni rack di GPU connesso a quello storage. Un cluster di 5.000 GPU con una disponibilità dello storage del 98% non consegna un errore di prestazioni del 2%. Produce 876.000 ore di calcolo perse all’anno. A costi rappresentativi per ora di GPU, ciò si traduce in milioni di dollari di calcolo inattivo ogni anno, più crediti di SLA dovuti su ogni rack interessato contemporaneamente.

Il raggio di azione del guasto dello storage in un cluster grande è l’intero cluster. I team di infrastruttura devono modellare questo esplicitamente: qual è il costo annualizzato del calcolo inattivo al tuo livello di disponibilità dello storage attuale, quali sono gli obblighi dei crediti di SLA che si attaccano a ogni livello di disponibilità e qual è il rischio di abbandono dei clienti a causa di violazioni di SLA? CoreWeave (CRWV ) e Oracle (ORCL ) stanno già offrendo un uptime del rack al 99%. I fornitori che non possono eguagliare questo stanno perdendo accordi oggi, e gli accordi che stanno perdendo sono sempre più i contratti aziendali ad alto valore che il mercato Neocloud ha bisogno di dimostrare la sua economia a lungo termine.

Come si confrontano diverse architetture di storage in termini di prestazioni per watt in ambienti vincolati dalla potenza?

Questo emerge quasi in ogni conversazione di infrastruttura seria e la differenza non è marginale. È moltiplicativa. Sulla base di specifiche pubblicate e configurazioni comparabili, fornendo circa 1.340 GB/s di throughput di lettura, un’architettura brucia 55 kW mentre un’altra raggiunge una produzione simile a circa 16 kW. Ciò rappresenta un differenziale di 3,4 volte nelle prestazioni per watt. In un data center dove i carichi di lavoro di intelligenza artificiale stanno consumando da 40 a 250 kilowatt per rack contro una connessione di rete fissa, i watt di storage sprecati sono GPU che non puoi distribuire. La stessa documentazione di BlueField-4 di NVIDIA afferma esplicitamente che la disponibilità di potenza è il vincolo principale per la scalabilità delle fabbriche di intelligenza artificiale.

C’è anche un effetto secondario che gli operatori raramente considerano. Alcune architetture di storage richiedono 5 GB di DRAM e da uno a quattro core CPU dedicati permanentemente bloccati per nodo GPU solo per raggiungere le prestazioni di storage di picco. Su un cluster di 500 nodi, ciò significa 2,5 TB di DRAM e fino a 2.000 core CPU permanentemente non disponibili per i carichi di lavoro di intelligenza artificiale. Quando paghi 30.000 dollari o più per GPU, ogni core rubato e ogni gigabyte bloccato è un’imposta diretta sull’investimento di calcolo che presumibilmente è l’intero punto dell’infrastruttura.

Come l’architettura di storage influenza direttamente la competitività degli SLA man mano che le garanzie di uptime si avvicinano al 99%?

Lo storage è il singolo più grande raggio di azione in qualsiasi cluster di GPU, il che lo rende la singola variabile più importante in qualsiasi impegno di SLA onesto. Il sistema di valutazione ClusterMAX 2.0 di SemiAnalysis, che sta diventando un benchmark influente nell’acquisto di Neocloud, rende gli SLA un fattore esplicito nelle trattative di prezzo. I fornitori senza SLA competitivi stanno perdendo accordi ora.

La dimensione della durabilità è altrettanto importante e meno discussa. I clienti aziendali sono stati condizionati da AWS S3 e Azure Blob ad aspettarsi 11 o 12 “nines” di durabilità. Le architetture HPC legacy costruite su RAID locali possono scendere al di sotto di 5 “nines” a livello di scala a seconda dei tassi di guasto dei dischi e delle finestre di ricostruzione, potenzialmente migliaia di file persi all’anno su un corpus di un miliardo di file. Il codice di cancellazione della rete moderno con protezione multilivello può superare gli 11 “nines”. Il divario tra quelle due realtà è la differenza tra un sistema di storage che puoi effettivamente garantire con un contratto di servizio e uno che non puoi.

Quali capacità di storage sono più probabili a determinare la sopravvivenza a lungo termine di Neocloud attraverso la consolidazione?

Gli operatori che sopravvivranno saranno quelli che avranno risolto l’equazione del costo totale di proprietà in tutta la pila di infrastruttura, non solo l’equazione di acquisto di GPU. Ciò significa diverse capacità specifiche.

In primo luogo, un’architettura software-definita unificata che esegue flash e disco su un solo piano di dati con tiering ad alte prestazioni nativo, senza spostatori di dati esterni, senza un secondo stack software, senza complessità operativa introdotta assemblando sistemi separati. In secondo luogo, uno storage che possa cavalcare curve di costo indipendenti per flash e disco mentre quei mercati si muovono indipendentemente l’uno dall’altro, come faranno. In terzo luogo, sistemi auto-risananti che mantengono un’elevata disponibilità senza amministratori specializzati che eseguono il recupero manuale alle 3 del mattino. La complessità operativa dello storage è un costo invisibile che si compone a livello di scala. In quarto luogo, la durabilità che può essere credibilmente garantita in un contratto di servizio rispetto ai benchmark dei hyperscaler.

Il punto più ampio è che l’onda di consolidamento sta separando l’infrastruttura costruita per i benchmark del primo giorno da quella costruita per l’economia del terzo anno. I tassi di noleggio di H100 sono scesi di oltre il 60% dal picco. Il mercato non sta più premiano l’accumulo di GPU. Sta esigendo la prova del ritorno sull’investimento di capitale. L’architettura di storage è dove vive quella prova, perché è dove le percentuali di utilizzo delle GPU, gli impegni di SLA, l’efficienza energetica e la struttura dei costi a lungo termine si incontrano tutti.

Qual è il tuo messaggio agli operatori Neocloud che stanno valutando la loro strategia di storage oggi?

Non lasciare che la decisione di storage sia quella che hai fatto per default. Ogni altra parte della pila di infrastruttura riceve un’attenta ingegneria e un’attenta valutazione finanziaria. Lo storage dovrebbe essere diverso. Gli operatori che saranno qui tra tre anni sono quelli che hanno preso una dura occhiata al loro vero costo per ora di calcolo utile, hanno capito la loro reale postura di disponibilità e si sono assicurati di essere dimensionati per il carico di lavoro piuttosto che per un accorgimento di acquisto.

La finestra per farlo bene si sta restringendo. La consolidazione è già in corso e l’economia è spietata. Ma per gli operatori disposti a ripensare lo strato di storage con la stessa rigida attenzione che hanno applicato alla selezione delle GPU, l’opportunità è significativa. Lo storage fatto bene non riduce solo i costi. Sblocca il valore completo di ogni GPU nel rack.

Grazie per la grande intervista, lettori che desiderano saperne di più su questa pila tecnologica possono visitare VDURA. Possono anche leggere la nostra precedente intervista con Ken Claffey.