Bonnes pratiques de stockage pour les charges de travail d'IA/de ML sur les VM TPU
Pour maximiser les performances et la rentabilité de vos charges de travail d'IA/ML sur les VM TPU, sélectionnez et configurez la solution de stockage adaptée à votre charge de travail. En supprimant les goulots d'étranglement d'E/S, vous pouvez réduire le temps d'inactivité de vos accélérateurs TPU, ce qui réduit le temps et les coûts d'entraînement.
Ce document fournit des recommandations de stockage spécifiques aux charges de travail et des bonnes pratiques d'optimisation pour l'entraînement, la création de points de contrôle, le service et la mise en cache sur les VM TPU. Avant d'appliquer ces pratiques, consultez les options de stockage disponibles pour les données TPU. Dans ce document, nous partons du principe que vous connaissez les VM TPU et que vous avez une expérience de base en provisionnement de ressources Cloud Storage.
Conseils spécifiques à la charge de travail
Le tableau suivant fournit des recommandations de stockage, listées par ordre de préférence, pour différentes charges de travail :
| Charge de travail | Recommandation | Optimisation et outils (le cas échéant) |
|---|---|---|
| Ensembles de données d'entraînement, y compris la préparation des données |
|
|
| Points de contrôle et pondérations de l'apprentissage par renforcement |
|
Pour Rapid Bucket, utilisez le profil gcsfusecsi-checkpointing.
|
| Stockage et téléchargement de modèles |
|
Pour télécharger des modèles, utilisez GKE Run:ai Model Streamer ou Cloud Storage FUSE avec un point d'installation distinct à l'aide du profil gcsfusecsi-serving.
|
| Déchargement du cache de paires clé/valeur |
|
Optimisations Cloud Storage
Les sections suivantes décrivent les bonnes pratiques pour optimiser les performances lorsque vous utilisez Cloud Storage avec des VM TPU.
Activer l'espace de noms hiérarchique pour optimiser les métadonnées
Pour améliorer les performances des métadonnées, activez l'espace de noms hiérarchique lorsque vous créez des buckets régionaux pour les charges de travail d'IA/de ML. Les performances des métadonnées font référence à la vitesse à laquelle Cloud Storage peut traiter les opérations qui impliquent la recherche, la liste ou la modification des chemins d'accès et des dossiers des objets, plutôt que la lecture ou l'écriture du contenu des fichiers eux-mêmes.
Dans les buckets sans espace de noms hiérarchique activé, les dossiers n'existent pas en tant que ressources réelles, mais sont plutôt des dossiers simulés représentés par des préfixes de noms d'objets délimités par des barres obliques (/). Cela ralentit les opérations telles que la liste du contenu d'un répertoire ou le renommage de répertoires, car le système doit analyser tous les objets portant ce préfixe. L'espace de noms hiérarchique fournit une véritable structure de système de fichiers, ce qui est important pour les charges de travail d'IA/de ML pour plusieurs raisons :
- Renommage atomique de répertoires : les frameworks de ML utilisent le renommage de répertoires pour finaliser les points de contrôle. L'espace de noms hiérarchique prend en charge les renommages atomiques, ce qui permet de finaliser rapidement les points de contrôle.
- RPS initial plus élevé : l'espace de noms hiérarchique permet d'obtenir un nombre de requêtes par seconde (RPS) initial jusqu'à huit fois plus élevé pour les opérations de lecture et d'écriture par rapport aux buckets sans espace de noms hiérarchique activé. Cela évite les goulots d'étranglement lorsque de nombreux TPU accèdent au stockage simultanément.
- Opérations efficaces au niveau des dossiers : la recherche et la liste des fichiers dans des répertoires spécifiques sont beaucoup plus rapides, ce qui réduit les temps de réponse lors de l'entraînement et du chargement des données.
Les buckets zonaux, proposés par le biais de Rapid Bucket, utilisent l'espace de noms hiérarchique par défaut. Pour en savoir plus, consultez la présentation des espaces de noms hiérarchiques.
Utiliser Cloud Storage FUSE avec les profils appropriés
Cloud Storage FUSE est un adaptateur FUSE qui vous permet d'installer des buckets en tant que système de fichiers local. Lorsque vous utilisez Google Kubernetes Engine, nous vous recommandons d'utiliser le pilote CSI Cloud Storage FUSE et les profils Cloud Storage FUSE pour automatiser l'optimisation des performances.
Pour en savoir plus sur les bonnes pratiques d'utilisation de Cloud Storage FUSE, consultez Bonnes pratiques pour optimiser les performances.
Personnaliser le disque de démarrage de la VM TPU
Vous pouvez personnaliser l'environnement de l'OS invité sur une VM TPU en utilisant des scripts de démarrage ou en créant des images personnalisées. La personnalisation du disque de démarrage est utile dans les cas suivants :
- Préchargement de logiciels et de bibliothèques : installez des frameworks de ML, des dépendances ou des logiciels personnalisés spécifiques pour réduire le temps de démarrage des VM et garantir des environnements cohérents.
- Utilisation de distributions d'OS non standards : utilisez une distribution ou une version d'OS qui ne figure pas dans la liste gérée par Google.
- Appliquer des configurations de sécurité et de surveillance : appliquez des paramètres de sécurité personnalisés, installez des agents de surveillance ou définissez des variables d'environnement.
Toutefois, la récupération du disque de démarrage pour les VM TPU est limitée. Vous ne pouvez pas dissocier ni créer d'instantané du disque de démarrage pour effectuer des réparations hors connexion. Soyez donc prudent lorsque vous apportez des modifications qui affectent le processus de démarrage. En suivant ces bonnes pratiques, vous pouvez réduire le risque d'échec du démarrage lorsque vous personnalisez vos environnements de VM TPU.
Lorsque vous personnalisez votre disque de démarrage, gardez à l'esprit les principes clés suivants :
Limitez les modifications apportées au disque de démarrage : dans la mesure du possible, installez les applications et stockez les données sur des volumes Persistent Disk ou Hyperdisk plutôt que de modifier considérablement le disque de démarrage.
Utiliser les UUID pour le montage : lorsque vous ajoutez des entrées au fichier
/etc/fstab, utilisez toujours les UUID pour identifier les disques et les partitions (UUID=...) plutôt que les noms d'appareils tels que/dev/sdb1. La stabilité des noms d'appareils générés automatiquement n'est pas garantie lors des redémarrages.
Suivez ces recommandations pour réduire le risque d'échec du démarrage lorsque vous apportez des modifications au système :
Gestion des erreurs : implémentez des modes de vérification des erreurs et d'échec progressif robustes dans vos scripts. Consignez des messages détaillés dans la console série et Cloud Logging pour faciliter le débogage.
Dépendances critiques : soyez extrêmement prudent lorsque vous modifiez des fichiers essentiels au démarrage, tels que le fichier
/etc/fstab, les configurations réseau ou les paramètres du bootloader. Une erreur de syntaxe ou une saisie incorrecte peuvent rendre la VM non amorçable.Disques secondaires : si votre script repose sur des disques secondaires, assurez-vous qu'il gère les cas où le disque peut être absent ou met plus de temps que prévu à s'associer. Évitez de rendre le processus de démarrage trop dépendant des montages de disques secondaires, sauf en cas d'absolue nécessité.
Vous trouverez ci-dessous des exemples d'entrées
/etc/fstabrecommandées et non recommandées pour le montage d'un disque secondaire :- Approche conseillée :
UUID=a1b2c3d4-e5f6-7890-1234-567890abcdef /mnt/mydata ext4 defaults,nofail 0 2 - Approche déconseillée :
/dev/sdb1 /mnt/mydata ext4 defaults 0 2
L'utilisation de l'option
nofailpeut empêcher le système de s'arrêter si le disque n'est pas trouvé, mais assurez-vous que votre application peut gérer l'indisponibilité du point d'installation.- Approche conseillée :
Gestion des packages : soyez prudent lorsque vous ajoutez des dépôts tiers. Assurez-vous qu'ils sont fiables et compatibles avec l'image de l'OS de base. Comprenez les dépendances des packages que vous installez et leur impact potentiel sur les bibliothèques système.
Espace disque : surveillez l'utilisation du disque de démarrage. Une journalisation intensive ou des installations logicielles volumineuses peuvent remplir le disque de démarrage et empêcher la VM de démarrer.
Journalisation : configurez vos applications et vos scripts pour qu'ils enregistrent des journaux détaillés dans la console série, car il s'agit du principal outil de diagnostic des problèmes de démarrage sur les VM TPU.
Planifier votre capacité de stockage
Il est important de planifier la capacité de stockage dont votre charge de travail aura besoin pour utiliser pleinement vos accélérateurs. Cela inclut la capacité de stockage et la bande passante des points de contrôle.
Estimer l'espace de stockage
Vous pouvez utiliser les estimations suivantes comme point de départ pour vos besoins de stockage :
| Type de charge de travail | Stockage des ensembles de données | Stockage des points de contrôle |
|---|---|---|
| Pré-entraînement de LLM | 2 To par TPU | 200 Go par TPU |
| Entraînement multimodal | 12 To par TPU | 1 To par TPU |
| Inférence | 1 To par TPU | 1 Go par TPU |
Estimer la bande passante du point de contrôle
Vous pouvez estimer la bande passante de point de contrôle minimale requise pour les charges de travail d'entraînement à l'aide de la formule suivante. Pour les lectures de données, les entraînements multiples ou l'entraînement et l'inférence, augmentez vos besoins en bande passante estimés de manière proportionnelle.
- Taille du point de contrôle : nombre de paramètres × octets par paramètre (environ 12 à 16 octets par paramètre pour FP16 + état de l'optimiseur). Ajoutez un tampon (environ 3x) pour les états de l'optimiseur et les différentes précisions.
- Intervalle de point de contrôle : fréquence à laquelle vous enregistrez un point de contrôle (par exemple, toutes les 15 minutes).
- Bande passante requise : Taille du point de contrôle ÷ intervalle de point de contrôle.
L'exemple suivant montre comment estimer la bande passante de point de contrôle minimale pour Qwen3-72B :
- Taille du point de contrôle : 72 milliards de paramètres × 12 octets ≈ 864 Go par point de contrôle. Avec un tampon, 3 × 864 Go ≈ 2,5 To.
- Intervalle de point de contrôle : 2 minutes = 120 secondes.
- Bande passante requise : 2,5 To ÷ 120 secondes ≈ 20 Gbit/s.
Recettes de référence
Pour obtenir des exemples de configurations de stockage pour des charges de travail et du matériel spécifiques, consultez les recettes suivantes :
- Inférence TPU7x :
- Entraînement TPU7x :
Quotas et limites de bande passante
La bande passante des offres Cloud Storage et Compute Engine est limitée par des quotas par défaut. Si vous dépassez un quota, vos requêtes d'entrée et de sortie peuvent être limitées.
Pour en savoir plus sur les quotas Cloud Storage et sur la façon de demander une augmentation, consultez Quotas et limites dans la documentation Cloud Storage. Pour en savoir plus sur les quotas Compute Engine pour Hyperdisk et Persistent Disk, consultez Quotas de disque.
Étapes suivantes
- Options de stockage pour les données TPU
- Connecter des VM TPU à des buckets Cloud Storage
- Associer un stockage de blocs durable à une VM TPU
- Bonnes pratiques pour optimiser les performances de Cloud Storage FUSE