AI data storage separa gli archivi durevoli dall’accesso rapido
AI data storage deve conciliare due esigenze diverse: conservare a costi sostenibili dataset in continua crescita e distribuire la porzione attiva più piccola con una velocità sufficiente a mantenere operative le unità di elaborazione grafica (GPU). Backblaze ha documentato un’architettura a due tier in cui B2 Cloud Storage conserva la copia durevole di dataset, file derivati e checkpoint, mentre NVIDIA AIStore mantiene i dati usati di frequente su storage locale vicino alle risorse di calcolo. Un checkpoint è uno stato di training salvato che consente di riprendere il lavoro o riutilizzarlo in seguito.
L’architettura riflette il modo in cui i progetti di AI utilizzano i dati. I team possono conservare dataset di origine, revisioni curate e checkpoint successivi, ma un singolo job legge soltanto un sottoinsieme variabile. Il processo di curation può riesaminare il materiale grezzo ogni volta che cambiano i suoi parametri, più tecnici possono riutilizzare la stessa revisione e il training può leggere una revisione per molte epoch, ossia eseguendo passaggi completi sui dati di training. Mantenere l’intero archivio accanto alle GPU può essere costoso, mentre leggerlo ripetutamente da un object storage remoto può influire sulle prestazioni.
AIStore è un object store scale-out open source, vale a dire che può distribuire dati e richieste tra più macchine man mano che aumenta la domanda. Può collegare un bucket B2 remoto tramite una S3-compatible API, un’interfaccia progettata per funzionare come Amazon S3. La prima richiesta di un object lo recupera dal system of record remoto. Le richieste successive possono utilizzare la copia locale nella cache finché rimane disponibile e valida. Le applicazioni S3 supportate possono essere indirizzate all’endpoint AIStore tramite la configurazione, senza sostituire il loro codice di accesso allo storage.
Il software offre anche operazioni pensate per i workload di training. Un job di prefetch carica una revisione nota del dataset prima dell’inizio dell’elaborazione. write-through conserva una copia locale e carica il risultato nel record remoto nell’ambito della stessa richiesta. GetBatch combina molti object di piccole dimensioni in un unico stream ordinato, anziché inviare una richiesta separata per ciascun object. Nell’architettura a tier, i dati passano da B2 attraverso AIStore fino all’applicazione e alla memoria della GPU per la decodifica, la preparazione dei batch e l’esecuzione del modello. I risultati e i checkpoint tornano indietro attraverso AIStore e vengono archiviati in B2.
Backblaze ha realizzato due workflow di esempio per illustrare questo modello. L’esempio di video curation utilizza NVIDIA NeMo Curator, una libreria open source con accelerazione GPU per preparare dataset di grandi dimensioni destinati all’AI generativa. Le esecuzioni complete effettuano il prefetch dei video di origine, mentre quelle limitate o con il prefetch disabilitato recuperano gli input non presenti nella cache quando necessario. Curator produce clip ed embedding Cosmos-Embed1, rappresentazioni numeriche dei contenuti utilizzate dai sistemi di AI, quindi li pubblica tramite AIStore su B2. Le successive esecuzioni di curation possono riutilizzare i video validi ancora presenti nella cache.
L’esempio di training per la robotica riguarda trainer che richiedono una normale directory locale. NVIDIA Isaac GR00T è un modello vision-language-action open per le capacità dei robot umanoidi. I suoi dataset dimostrativi contengono molti file di piccole dimensioni, tra cui tabelle per episodio, video delle telecamere e metadata. L’esempio esegue lo staging di una revisione da AIStore sul nodo GPU, la verifica rispetto a un manifest, ossia un inventario dei file previsti, e quindi avvia il training senza modificare il data loader esistente. I checkpoint vengono pubblicati tramite AIStore su B2. Ripetendo lo staging della stessa revisione è possibile leggere la copia nella cache anziché recuperarla da B2.
Backblaze definisce cinque regole operative per mantenere indipendenti questi tier. In primo luogo, il tier veloce deve essere dimensionato in base ai working set simultanei e al probabile riutilizzo, non in base all’intero archivio. Deve inoltre disporre di spazio libero sufficiente perché i dati caricati tramite prefetch rimangano residenti fino al completamento dello staging. Per i bucket remoti, AIStore abilita per impostazione predefinita LRU eviction. Inizia a rimuovere i dati meno recenti dalla cache quando l’utilizzo del disco supera un high watermark a livello di cluster, impostato per default al 90%. Gli operatori devono quindi configurare tale soglia in funzione del workload, anziché considerarla un valore predefinito di scarsa importanza.
In secondo luogo, è opportuno effettuare il prefetch dei dati quando è importante avere tempi di avvio prevedibili. In terzo luogo, i prefix dei dataset devono essere trattati come posizioni write-once: ogni revisione deve ricevere un nuovo path, come raw/revision-001/, invece di modificare una revisione esistente. AIStore può convalidare gli object nella cache rispetto a B2 a ogni lettura tramite versioning.validate_warm_get, rilevando eventuali modifiche out-of-band. Prefix univoci e immutabili evitano questa verifica a ogni lettura per le revisioni completate. Per i dati conservati a fini di audit o riproducibilità, B2 Object Lock può impedire l’eliminazione di una versione bloccata di un object durante il relativo periodo di conservazione.
In quarto luogo, con ogni risultato deve essere pubblicato un manifest verificabile. Entrambi gli esempi contrassegnano inizialmente un record _SUCCESS.json come pending. Dopo l’arrivo di tutti gli object, lo contrassegnano come completo e registrano le dimensioni e il valore SHA-256 di ciascun file; SHA-256 è un valore crittografico utilizzato per rilevare se un file è stato modificato. Quando esiste un manifest di input, la provenance dell’output include anche il relativo hash, in modo da poter identificare la revisione del dataset di origine.
In quinto luogo, il caricamento iniziale, le letture dalla cache warm, l’elaborazione e la pubblicazione devono essere misurati separatamente, perché ogni fase risponde a cambiamenti diversi. La pubblicazione può rappresentare il trasferimento più consistente: i checkpoint contengono model weights e optimizer state e, secondo Backblaze, persino la sua dimostrazione GR00T di 20 step può pubblicare decine di gigabyte. I repository degli esempi confrontano il recupero diretto da B2 con letture cold e warm tramite AIStore. I relativi integration test confermano che le letture warm non generano alcuna richiesta GET a B2.
Anche i confini delle credential sono importanti. I processi child di Curator e GR00T non ricevono la B2 key. I target AIStore e le utility che si collegano direttamente a B2 ne hanno invece bisogno. Ciò limita i punti in cui deve essere distribuita la credential dello storage remoto senza modificare il workflow S3 dell’applicazione.
La convenienza economica dipende dal riutilizzo. I job che condividono un unico cluster AIStore possono usare gli stessi object nella cache senza scaricarli ripetutamente. Secondo Backblaze, questo può ridurre le letture conteggiate rispetto alla quota di egress gratuito di B2, pari a tre volte lo storage medio mensile. L’azienda afferma inoltre che l’egress verso partner di calcolo come CoreWeave è gratuito e senza limiti. Per un singolo passaggio sequenziale, tuttavia, è più semplice inviare in streaming i dati sharded direttamente da B2 al data loader.
AIStore rimane un’infrastruttura che deve essere gestita da un team. Kubernetes con ais-k8s è una delle opzioni di deployment in produzione. write-through aggiunge una scrittura locale prima di ogni upload, anche se i benchmark di NVIDIA mostrano che questo overhead diminuisce all’aumentare delle dimensioni degli object. Il compromesso è che i risultati pubblicati rimangono nella cache e possono essere riutilizzati da un altro job. Gli operatori devono confrontare questo vantaggio con il lavoro di upload aggiuntivo richiesto per ciascun workload.
Per le organizzazioni che valutano questa separazione tra capacità e prestazioni, AEU Data offre cloud e infrastrutture dati europei come opzione per il data layer sottostante.