Quando si parla del costo dell’intelligenza artificiale, quasi inevitabilmente si finisce a discutere di GPU, token e potenza di calcolo. È comprensibile: sono le componenti più visibili e, soprattutto durante il training, quelle che possono produrre le fatture più impressionanti. Ma c’è una caratteristica dell’infrastruttura AI che rischia di diventare importante quanto il prezzo del compute: le GPU sono una risorsa temporanea, i dati no.
La capacità di calcolo può essere acquistata nel cloud per alcune ore, spostata da un hyperscaler a un GPU cloud specializzato o distribuita fra provider differenti. Dataset di training, checkpoint, embedding, versioni dei modelli e risultati delle elaborazioni, invece, devono continuare a esistere prima e dopo che le GPU sono state spente.
È su questa asimmetria che Wasabi Technologies costruisce il concetto di “AI Storagemaxxing”, termine preso in prestito dalla cultura Internet per indicare l’ottimizzazione dello storage lungo l’intero ciclo di vita dell’intelligenza artificiale. Al di là dell’etichetta, la tesi è interessante: progettare lo storage dopo avere progettato l’AI può trasformarsi in un errore economico e architetturale.
Il dataset vive molto più a lungo del training
Un progetto AI non comincia quando parte il training. I dati devono prima essere raccolti da sorgenti differenti, trasferiti, ripuliti, classificati e consolidati. Solo una parte viene successivamente selezionata e portata sull'infrastruttura ad alte prestazioni utilizzata per addestramento e valutazione.
Ma neppure la conclusione del training segna la fine del loro ciclo di vita. Bisogna conservare checkpoint, versioni dei modelli, dataset, output ed eventualmente embedding, sia per riutilizzarli sia per effettuare retraining, verifiche e audit successivi. Il rischio è utilizzare per tutte queste fasi lo stesso storage ad alte prestazioni necessario nel momento più intensivo del processo. Una scelta tecnicamente semplice, ma non necessariamente economicamente sensata.
La proposta di Wasabi è invece separare il ciclo di vita del dato da quello del compute: portare sullo storage premium soltanto ciò che serve quando serve, spostando successivamente gli artefatti verso infrastrutture meno costose senza renderli indisponibili. È una logica già familiare nell'IT tradizionale attraverso il data tiering, ma l'AI ne amplifica l'importanza per la quantità di informazioni prodotte e per la frequenza con cui gli stessi dati possono essere riutilizzati.
Il vero lock-in potrebbe essere il dato
C'è però un secondo aspetto che va oltre il semplice contenimento dei costi. Il mercato del calcolo per l’AI si sta frammentando. Accanto agli hyperscaler sono comparsi GPU cloud e neocloud specializzati, mentre le aziende possono mantenere parte della capacità on-premise e acquistare risorse esterne per gestire picchi o progetti specifici. In teoria questo dovrebbe aumentare la libertà di scelta, ma la potenza di calcolo è intercambiabile soltanto se è possibile portare i dati dove servono.
Un'organizzazione può trovare GPU più convenienti presso un altro provider, ma il vantaggio economico si riduce rapidamente se per utilizzarle deve trasferire enormi dataset pagando costi di egress o affrontando settimane di migrazione. Lo storage rischia quindi di diventare il punto nel quale si materializza il lock-in dell'infrastruttura AI.
Wasabi propone per questo un modello nel quale lo storage funzioni come “data plane persistente”, separato dai diversi ambienti di calcolo. Dataset e artefatti rimangono su un livello relativamente neutrale, mentre hyperscaler, GPU cloud e infrastrutture locali possono essere utilizzati in funzione delle necessità. È un'impostazione che assume particolare rilevanza se le imprese vogliono costruire strategie AI realmente multicloud anziché limitarsi a dichiararle tali.
Non tutti i byte dell’AI valgono allo stesso modo
Separare dati e potenza di calcolo porta a un'altra considerazione: non tutti i dati AI hanno contemporaneamente bisogno delle stesse prestazioni. Durante il training, alimentare decine o centinaia di GPU può rendere indispensabile un'infrastruttura storage estremamente performante. In quella fase risparmiare sul throughput può essere addirittura controproducente: una GPU costosa che aspetta i dati è probabilmente una delle risorse peggiori da lasciare inattiva, ma la situazione cambia quando il training è finito.
Un checkpoint che deve essere conservato per una futura verifica o un dataset utilizzato per un retraining fra sei mesi non deve sostare sullo stesso storage utilizzato dai carichi attivi. L'ottimizzazione proposta da Wasabi consiste nel far seguire ai dati la curva delle loro esigenze, anziché scegliere una sola classe di infrastruttura e mantenerla per tutta la loro esistenza. Non significa eliminare lo storage specializzato ad alte prestazioni. Significa evitare che diventi il parcheggio permanente di tutto ciò che un progetto AI produce.
La fattura dell’AI non finisce con i token
Questa impostazione ha conseguenze anche sul calcolo del ritorno dell'investimento. Valutare il costo di un servizio AI sulla base dei soli token consumati o delle ore GPU significa osservare soltanto una parte della sua economia. Il costo reale comprende anche raccolta, trasferimento, protezione e conservazione dei dati. E alcuni di questi costi possono essere difficili da prevedere. Modelli tariffari complessi, differenti classi di storage, richieste API, retrieval ed egress possono avere un peso relativamente modesto durante una sperimentazione e diventare molto più significativo quando il servizio passa in produzione e i volumi crescono. “Le organizzazioni che avranno successo con l’AI non saranno necessariamente quelle che spenderanno di più, ma quelle che riusciranno a trasformare le sperimentazioni in servizi commercialmente sostenibili nel modo più efficiente”, osserva David Boland, VP of Cloud Strategy di Wasabi. Il passaggio dal proof of concept alla produzione è infatti il momento nel quale molte ottimizzazioni apparentemente secondarie iniziano a diventare strutturali.
Anche gli agenti possono mettere a rischio i dataset
C'è infine una dimensione di sicurezza che l'arrivo dell'AI agentica rende meno trascurabile. Dataset e artefatti dei modelli non devono soltanto essere disponibili: devono poter essere ricondotti a uno stato conosciuto e affidabile. Il ransomware rappresenta il caso più evidente, ma non è l'unico. Un account compromesso, un errore operativo o un agente AI dotato di privilegi eccessivi potrebbero modificare o cancellare informazioni utilizzate successivamente per training e inferenza.
Il problema è anche piuttosto subdolo perché una compromissione del dataset potrebbe non produrre immediatamente un'interruzione del servizio. Potrebbe invece alterare ciò che il modello imparerà in futuro. Wasabi suggerisce quindi di combinare controlli di accesso, policy di retention, tracciabilità e copie isolate che consentano di recuperare una versione affidabile dei dati. È un principio che avvicina ulteriormente la gestione dell'AI alle discipline tradizionali di data protection e cyber resilience: non basta proteggere il modello se non è possibile fidarsi dei dati che lo alimentano.
Dal GPU-first al data-first
“AI Storagemaxxing” è certamente un'espressione costruita per attirare l'attenzione, ma dietro il termine c'è una questione architetturale concreta. Negli ultimi anni buona parte della progettazione dell'infrastruttura AI è partita dalla domanda “dove troviamo le GPU?”. Con l'aumento dei workload in produzione potrebbe diventare altrettanto importante chiedersi “dove rimarranno i dati?”. La differenza è che la prima decisione può essere relativamente temporanea. La seconda tende a lasciare conseguenze molto più durature. Separare storage e compute, utilizzare infrastrutture differenti nelle varie fasi della pipeline e mantenere i dati portabili può quindi diventare non soltanto un modo per ridurre la fattura cloud, ma una condizione per conservare libertà di scelta sull'intero stack AI. Perché una GPU inutilizzata smette di costare quando viene spenta. Un petabyte di dati, invece, deve continuare a stare da qualche parte.