Best practice di archiviazione per i workload AI/ML sulle VM TPU

Per massimizzare le prestazioni e l'efficienza dei costi dei tuoi workload AI/ML sulle VM TPU, seleziona e configura la soluzione di archiviazione giusta per il tuo workload. Se rimuovi i colli di bottiglia I/O, puoi ridurre il tempo di inattività degli acceleratori TPU, il che riduce i tempi e i costi di addestramento.

Questo documento fornisce consigli di archiviazione specifici per il workload e best practice di ottimizzazione per l'addestramento, il checkpoint, la gestione e la memorizzazione nella cache su VM TPU. Prima di applicare queste pratiche, esamina le opzioni di archiviazione per i dati TPU disponibili. Questo documento presuppone che tu abbia familiarità con le VM TPU e che tu abbia esperienza di base con il provisioning delle risorse Cloud Storage.

Indicazioni specifiche per il carico di lavoro

La tabella seguente fornisce suggerimenti per l'archiviazione, elencati in ordine di preferenza, per diversi carichi di lavoro:

Workload Suggerimento Ottimizzazione e strumenti (se applicabile)
Set di dati di addestramento, inclusa la preparazione dei dati
  1. Utilizza i bucket regionali di Cloud Storage con Rapid Cache e la regolazione lato client (ad esempio le letture in anteprima) per ottenere il costo più basso.
  2. Utilizza Cloud Storage Rapid Bucket per ottenere prestazioni e scalabilità ottimali.
  3. Utilizza Managed Lustre se stai standardizzando Lustre (storage del file system) a causa dell'elevata concorrenza dei metadati o di file di piccole dimensioni (meno di 1 MB).
  • Per i bucket Cloud Storage regionali, abilita lo spazio dei nomi gerarchico.
  • Per i bucket Cloud Storage regionali o Rapid Bucket, utilizza Cloud Storage FUSE e gRPC. Per GKE, utilizza il profilo gcsfusecsi-training.
  • Per Managed Lustre, valuta la possibilità di utilizzare il livello Dinamico per ridurre i costi e ottimizzare automaticamente le prestazioni.
Checkpoint e pesi dell'apprendimento per rinforzo
  1. Utilizza Managed Lustre per prestazioni elevate senza una messa a punto approfondita per requisiti di bassa latenza (meno di 1 ms), come checkpoint sincroni e propagazione dei pesi ad alta velocità per l'apprendimento per rinforzo.
  2. Utilizza Cloud Storage Rapid Bucket per la massima velocità effettiva per il checkpointing asincrono e multilivello e per parallelizzare le operazioni di checkpointing nell'archiviazione. Rapid Bucket fornisce l'elevato throughput necessario per questi workload.
Per Rapid Bucket, utilizza il profilo gcsfusecsi-checkpointing.
Archiviazione e download del modello
  1. Utilizza Hyperdisk ML per la memorizzazione nella cache di modelli di piccole dimensioni e fino a 2500 istanze.
  2. Utilizza la stessa soluzione di archiviazione che utilizzi per i set di dati di addestramento (Managed Lustre, Rapid Bucket o bucket regionali) se vuoi standardizzare una singola soluzione di archiviazione.
Per scaricare i modelli, utilizza GKE Run:ai Model Streamer o Cloud Storage FUSE con un punto di montaggio separato utilizzando il profilo gcsfusecsi-serving.
Offload della cache coppia chiave-valore (KV)
  1. Utilizza sempre la memoria della CPU host (RAM) come livello principale per liberare la VRAM senza aggiungere una latenza significativa.
  2. Se la memoria della CPU non è sufficiente, utilizza Managed Lustre come secondo livello parallelo a bassa latenza nella gerarchia della cache per soddisfare le esigenze di latenza ultra bassa (inferiore a 1 ms) dello scaricamento della cache KV con un throughput elevato (fino a 10 TB/s).

Ottimizzazioni di Cloud Storage

Le sezioni seguenti descrivono le best practice per ottimizzare le prestazioni quando utilizzi Cloud Storage con le VM TPU.

Abilitare lo spazio dei nomi gerarchico per l'ottimizzazione dei metadati

Per migliorare le prestazioni dei metadati, abilita lo spazio dei nomi gerarchico quando crei bucket regionali per i workload di AI/ML. Il rendimento dei metadati si riferisce alla velocità con cui Cloud Storage può elaborare le operazioni che comportano la ricerca, l'elenco o la modifica di percorsi e cartelle degli oggetti, anziché la lettura o la scrittura dei contenuti dei file stessi.

Nei bucket senza spazio dei nomi gerarchico abilitato, le cartelle non esistono come risorse effettive, ma sono invece cartelle simulate rappresentate da prefissi del nome oggetto delimitati da barre (/). In questo modo, operazioni come l'elenco dei contenuti della directory o la ridenominazione delle directory risultano lente perché il sistema deve scansionare tutti gli oggetti con quel prefisso. Lo spazio dei nomi gerarchico fornisce una vera struttura del file system, il che è importante per i workload di AI/ML per diversi motivi:

  • Rinomina atomica delle directory: i framework ML utilizzano i cambi di nome delle directory per finalizzare i checkpoint. Lo spazio dei nomi gerarchico supporta le ridenominazioni atomiche, garantendo che i checkpoint vengano finalizzati rapidamente.
  • QPS iniziale più elevato: lo spazio dei nomi gerarchico supporta un numero di query al secondo (QPS) iniziale fino a otto volte superiore per le letture e le scritture rispetto ai bucket senza spazio dei nomi gerarchico abilitato. In questo modo si evitano colli di bottiglia quando molte TPU accedono contemporaneamente allo spazio di archiviazione.
  • Operazioni efficienti a livello di cartella: trovare ed elencare i file all'interno di directory specifiche è molto più veloce, riducendo i tempi di risposta durante l'addestramento e il caricamento dei dati.

I bucket di zona, offerti tramite Rapid Bucket, utilizzano lo spazio dei nomi gerarchico per impostazione predefinita. Per saperne di più, consulta la panoramica dello spazio dei nomi gerarchico.

Utilizza Cloud Storage FUSE con i profili appropriati

Cloud Storage FUSE è un adattatore FUSE che consente di montare i bucket come file system locale. Quando utilizzi Google Kubernetes Engine, ti consigliamo di utilizzare il driver CSI di Cloud Storage FUSE e i profili Cloud Storage FUSE per automatizzare l'ottimizzazione delle prestazioni.

Per ulteriori informazioni sulle best practice per l'utilizzo di Cloud Storage FUSE, consulta Best practice per l'ottimizzazione delle prestazioni.

Personalizza il disco di avvio della VM TPU

Puoi personalizzare l'ambiente del sistema operativo guest su una VM TPU utilizzando script di avvio o creando immagini personalizzate. La personalizzazione del disco di avvio è utile per gli scenari seguenti:

  • Precaricamento di software e librerie: installa framework ML specifici, dipendenze o software personalizzato per ridurre il tempo di avvio della VM e garantire ambienti coerenti.
  • Utilizzo di distribuzioni del sistema operativo non standard: utilizza una distribuzione o una versione del sistema operativo non inclusa nell'elenco gestito da Google.
  • Applicazione di configurazioni di sicurezza e monitoraggio: applica impostazioni di sicurezza personalizzate, installa agent di monitoraggio o imposta variabili di ambiente.

Tuttavia, il recupero del disco di avvio per le VM TPU è limitato. Non puoi scollegare o creare snapshot del disco di avvio per la riparazione offline, quindi fai attenzione quando apporti modifiche che influiscono sul processo di avvio. Se segui queste best practice, puoi ridurre il rischio di errori di avvio quando personalizzi gli ambienti VM TPU.

Quando personalizzi il disco di avvio, tieni presente i seguenti principi chiave:

  • Riduci al minimo le modifiche al disco di avvio: se possibile, installa le applicazioni e archivia i dati sui volumi Persistent Disk o Hyperdisk anziché modificare pesantemente il disco di avvio.

  • Utilizza gli UUID per il montaggio: quando aggiungi voci al file /etc/fstab, utilizza sempre gli UUID per identificare dischi e partizioni (UUID=...) anziché i nomi dei dispositivi come /dev/sdb1. Non è garantito che i nomi dei dispositivi generati automaticamente rimangano stabili dopo i riavvii.

Segui questi consigli per ridurre il rischio di errori di avvio quando apporti modifiche al sistema:

  • Gestione degli errori: implementa controlli degli errori efficaci e modalità di errore controllato negli script. Registra messaggi dettagliati nella console seriale e in Cloud Logging per facilitare il debug.

  • Dipendenze critiche: presta estrema attenzione quando modifichi i file essenziali per l'avvio, come il file /etc/fstab, le configurazioni di rete o le impostazioni del bootloader. Un errore di sintassi o una voce errata può rendere la VM non avviabile.

  • Dischi secondari: se lo script si basa su dischi secondari, assicurati che gestisca i casi in cui il disco potrebbe non essere presente o impiega più tempo del previsto per essere collegato. Evita di rendere il processo di avvio eccessivamente dipendente dai montaggi del disco secondario, a meno che non sia assolutamente necessario.

    Di seguito sono riportati alcuni esempi di voci /etc/fstab consigliate e non consigliate per il montaggio di un disco secondario:

    • Consigliato: UUID=a1b2c3d4-e5f6-7890-1234-567890abcdef /mnt/mydata ext4 defaults,nofail 0 2
    • Non consigliato: /dev/sdb1 /mnt/mydata ext4 defaults 0 2

    L'utilizzo dell'opzione nofail può impedire l'arresto del sistema se il disco non viene trovato, ma assicurati che l'applicazione possa gestire l'indisponibilità del punto di montaggio.

  • Gestione dei pacchetti: fai attenzione quando aggiungi repository di terze parti. Assicurati che siano attendibili e compatibili con l'immagine del sistema operativo di base. Comprendi le dipendenze di tutti i pacchetti che installi e il loro potenziale impatto sulle librerie di sistema.

  • Spazio su disco: monitora l'utilizzo del disco di avvio. Il logging esteso o le installazioni di software di grandi dimensioni possono riempire il disco di avvio, impedendo l'avvio della VM.

  • Logging: configura le applicazioni e gli script per registrare in modo dettagliato nella console seriale, poiché questo è lo strumento principale per diagnosticare i problemi di avvio sulle VM TPU.

Pianificare la capacità di archiviazione

È importante pianificare la quantità di capacità di archiviazione necessaria al tuo workload per utilizzare completamente gli acceleratori. Ciò include la capacità di archiviazione e la larghezza di banda dei checkpoint.

Stima dello spazio di archiviazione

Puoi utilizzare le seguenti stime come punto di partenza per i tuoi requisiti di spazio di archiviazione:

Tipo di workload Spazio di archiviazione dei set di dati Spazio di archiviazione checkpoint
Preaddestramento di LLM 2 TB per TPU 200 GB per TPU
Addestramento multimodale 12 TB per TPU 1 TB per TPU
Inferenza 1 TB per TPU 1 GB per TPU

Stima della larghezza di banda del checkpoint

Puoi stimare la larghezza di banda minima del checkpointing richiesta per i carichi di lavoro di training utilizzando la seguente formula. Per le letture dei dati, più esecuzioni di addestramento, o addestramento e inferenza, aumenta proporzionalmente i requisiti di larghezza di banda stimati.

  1. Dimensioni del checkpoint: numero di parametri × byte per parametro (circa 12-16 byte per parametro per FP16 + stato dell'ottimizzatore). Aggiungi un buffer (circa 3×) per gli stati dell'ottimizzatore e le diverse precisioni.
  2. Intervallo di checkpoint: la frequenza con cui salvi un checkpoint (ad esempio, ogni 15 minuti).
  3. Larghezza di banda richiesta: dimensione del checkpoint ÷ intervallo tra i checkpoint.

Il seguente esempio mostra come stimare la larghezza di banda minima di checkpoint per Qwen3-72B:

  1. Dimensioni del checkpoint: 72 miliardi di parametri × 12 byte ≈ 864 GB per checkpoint. Con il buffer, 3 × 864 GB ≈ 2,5 TB.
  2. Intervallo di checkpoint: 2 minuti = 120 secondi.
  3. Larghezza di banda richiesta: 2,5 TB ÷ 120 secondi ≈ 20 GBps.

Ricette di riferimento

Per esempi di configurazioni di archiviazione per hardware e carichi di lavoro specifici, consulta le seguenti ricette:

Quote e limiti di larghezza di banda

La larghezza di banda per le offerte Cloud Storage e Compute Engine è limitata dalle quote predefinite. Se superi una quota, le richieste di input e output potrebbero essere limitate.

Per informazioni sulle quote di Cloud Storage e su come richiedere aumenti, consulta la sezione Quote e limiti nella documentazione di Cloud Storage. Per informazioni sulle quote di Compute Engine per Hyperdisk e Persistent Disk, consulta Quote disco.

Passaggi successivi