Bonnes pratiques : pools de nœuds de calcul Cloud Run avec GPU

Preview — GPU support for Cloud Run worker pools

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les fonctionnalités de pré-DG sont disponibles "en l'état" et peuvent avoir une prise en charge limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Cette page présente les bonnes pratiques à suivre pour optimiser les performances lorsque vous utilisez un pool de nœuds de calcul Cloud Run avec des charges de travail d'IA telles que l'entraînement de grands modèles de langage (LLM) à l'aide de vos frameworks préférés, l'affinage et l'inférence par lots ou hors connexion sur les LLM. Pour créer un pool de nœuds de calcul Cloud Run capable d'effectuer des tâches gourmandes en calcul ou un traitement par lot en temps réel, vous devez :

• Utilisez des modèles qui se chargent rapidement et qui nécessitent une transformation minimale en des structures compatibles avec les GPU, et optimisez leur chargement.
• Utilisez des configurations qui permettent une exécution simultanée, efficace et maximale afin de réduire le nombre de GPU nécessaires pour diffuser un nombre cible de requêtes par seconde tout en réduisant les coûts.

Méthodes recommandées pour charger de grands modèles de ML sur Cloud Run

Google recommande de stocker les modèles de ML dans les images de conteneur ou d'optimiser leur chargement à partir de Cloud Storage.

Compromis pour le stockage et le chargement des modèles de ML

Voici une comparaison des options :

Emplacement du modèle	Heure du déploiement	Expérience en développement	Délai de démarrage du conteneur	Coût du stockage
Image du conteneur	Lent. L'importation d'une image contenant un modèle volumineux dans Cloud Run prend davantage de temps.	Les modifications apportées à l'image de conteneur nécessitent un redéploiement, qui peut être lent pour les images de grande taille.	Dépend de la taille du modèle. Pour les modèles très volumineux, utilisez Cloud Storage pour des performances plus prévisibles mais plus lentes.	Potentiellement plusieurs copies dans Artifact Registry.
Cloud Storage, chargé à l'aide de l'installation de volume Cloud Storage FUSE	Rapide. Modèle téléchargé au démarrage du conteneur.	Facile à configurer, ne nécessite pas de modifications de l'image Docker.	Rapide grâce aux optimisations réseau. Le téléchargement n'est pas parallélisé.	Une copie dans Cloud Storage.
Cloud Storage, téléchargé simultanément à l'aide de la commande Google Cloud CLI gcloud storage cp ou de l'API Cloud Storage, comme indiqué dans l'exemple de code de téléchargement simultané de transfer manager.	Rapide. Modèle téléchargé au démarrage du conteneur.	Un peu plus difficile à configurer, car vous devrez installer Google Cloud CLI sur l'image ou mettre à jour le code pour utiliser l'API Cloud Storage.	Rapide grâce aux optimisations réseau. Google Cloud CLI télécharge le fichier de modèle en parallèle, ce qui est plus rapide que l'installation de FUSE.	Une copie dans Cloud Storage.
Internet	Rapide. Modèle téléchargé au démarrage du conteneur.	Généralement plus simple (de nombreux frameworks téléchargent des modèles à partir de dépôts centraux).	Souvent de mauvaise qualité et imprévisible : Les frameworks peuvent appliquer des transformations de modèle lors de l'initialisation. (Vous devez le faire au moment de la compilation). L'hôte du modèle et les bibliothèques permettant de le télécharger peuvent ne pas être efficaces. Le téléchargement depuis Internet présente un risque de fiabilité. Vos pools de nœuds de calcul peuvent ne pas démarrer si la cible de téléchargement est indisponible et le modèle sous-jacent téléchargé peut changer, ce qui diminue la qualité. Nous vous recommandons d'héberger votre propre bucket Cloud Storage.	Dépend du fournisseur d'hébergement du modèle.

Stocker des modèles dans des images de conteneurs

En stockant le modèle de ML dans l'image de conteneur, le chargement du modèle bénéficiera de l'infrastructure de streaming de conteneurs optimisée de Cloud Run. Toutefois, la création d'images de conteneur incluant des modèles de ML est un processus gourmand en ressources, en particulier lorsque vous travaillez avec des modèles volumineux. En particulier, le processus de compilation peut être limité par le débit du réseau. Lorsque vous utilisez Cloud Build, nous vous recommandons d'utiliser une machine de compilation plus puissante avec des performances de calcul et de réseau améliorées. Pour ce faire, créez une image à l'aide d'un fichier de configuration de compilation incluant les étapes suivantes :

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'IMAGE', '.']
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'IMAGE']
images:
- IMAGE
options:
 machineType: 'E2_HIGHCPU_32'
 diskSizeGb: '500'
 

Vous pouvez créer une copie de modèle par image si la couche contenant le modèle est distincte entre les images (hachage différent). Des coûts Artifact Registry supplémentaires peuvent être facturés, car il peut y avoir une copie du modèle par image si votre couche de modèle est unique pour chaque image.

Stocker des modèles dans Cloud Storage

Pour optimiser le chargement des modèles de ML lorsque vous les chargez depuis Cloud Storage, à l'aide d'installations de volumes Cloud Storage ou directement via l'API Cloud Storage ou la ligne de commande, vous devez utiliser un VPC direct avec la valeur de paramètre de sortie définie sur all-traffic, ainsi que l'accès privé à Google.

Charger des modèles depuis Internet

Pour optimiser le chargement des modèles de ML depuis Internet, acheminez tout le trafic via le réseau VPC avec la valeur du paramètre de sortie définie sur all-traffic et configurez Cloud NAT pour accéder à l'Internet public avec une bande passante élevée.

Considérations relatives à la compilation, au déploiement, à l'exécution et à la conception du système

Les sections suivantes décrivent les considérations relatives à la compilation, au déploiement, à l'exécution et à la conception du système.

Au moment de la compilation

La liste suivante présente les éléments à prendre en compte lorsque vous planifiez votre build :

• Choisissez une image de base de bonne qualité. Commencez par une image provenant des conteneurs de deep learning ou du registre de conteneurs NVIDIA pour le framework de ML que vous utilisez. Ces images contiennent les derniers packages liés aux performances. Nous vous déconseillons de créer une image personnalisée.
• Choisissez des modèles quantifiés sur 4 bits afin d'optimiser la simultanéité, sauf si vous pouvez prouver qu'ils affectent la qualité des résultats. La quantification produit des modèles plus petits et plus rapides, ce qui réduit la quantité de mémoire GPU nécessaire pour exécuter le modèle et peut augmenter le chargement en parallèle au moment de l'exécution. Idéalement, les modèles devraient être entraînés à la profondeur de bits cible plutôt que d'être quantifiés en conséquence.
• Choisissez un format de modèle offrant des temps de chargement rapides afin de minimiser le temps de démarrage du conteneur, tel que le format GGUF. Ces formats reflètent plus précisément le type de quantification cible et nécessitent moins de transformations lors de leur chargement sur le GPU. Pour des raisons de sécurité, n'utilisez pas de points de contrôle au format pickle.
• Créez et préchauffez les caches LLM au moment de la compilation. Démarrez le LLM sur la machine de compilation lors de la création de l'image Docker. Activez la mise en cache des requêtes et alimentez des requêtes courantes ou des exemples de requêtes afin de faciliter le préchauffage du cache pour une utilisation réelle. Enregistrez les résultats qu'il génère pour qu'ils soient chargés au moment de l'exécution.
• Enregistrez votre propre modèle d'inférence que vous générez lors de la compilation. Cela permet de gagner un temps considérable par rapport au chargement de modèles stockés de façon moins efficace et l'application de transformations telles que la quantification au démarrage du conteneur.

Lors du déploiement

La liste suivante présente les éléments à prendre en compte lorsque vous planifiez votre déploiement :

• Les pools de nœuds de calcul GPU ne peuvent pas faire l'objet d'un autoscaling. Vous êtes facturé pour le GPU même s'il n'exécute aucun processus.
• Le processeur et la mémoire des pools de nœuds de calcul sont facturés différemment des services et des jobs. Toutefois, le code SKU GPU est facturé au même prix que les services et les jobs.

Lors de l'exécution

• Gérez activement la longueur de contexte compatible. Plus la fenêtre contextuelle est petite, plus le nombre de requêtes pouvant être exécutées en parallèle est élevé. Les détails de la procédure à suivre dépendent du framework.
• Utilisez les caches LLM que vous avez générés au moment de la compilation. Fournissez les mêmes options que celles utilisées au moment de la compilation lorsque vous avez généré la requête et le cache de préfixe.
• Chargez le modèle à partir du modèle enregistré que vous venez d'écrire. Pour comparer les méthodes de chargement du modèle, consultez la section Compromis pour le stockage et le chargement des modèles.
• Envisagez d'utiliser un cache clé-valeur quantifié si votre framework le permet. Cela peut réduire les exigences de mémoire par requête et permet de configurer davantage de parallélisme. Toutefois, cela peut aussi avoir un impact sur la qualité.
• Ajustez la quantité de mémoire GPU à réserver pour les pondérations, les activations et les caches clé/valeur du modèle. Définissez une valeur aussi haute que possible sans obtenir d'erreur de mémoire insuffisante.
• Vérifiez si votre framework dispose d'options permettant d'améliorer les performances de démarrage des conteneurs (par exemple, en utilisant le chargement en parallèle de modèle).

Au moment de la conception du système :

• Ajoutez des caches sémantiques, le cas échéant. Dans certains cas, la mise en cache des requêtes et des réponses entières peut être un excellent moyen de limiter le coût des requêtes courantes.
• Contrôlez la variance dans vos préambules. Les caches de requêtes ne sont utiles que lorsqu'ils contiennent les requêtes de manière séquentielle. Les caches sont effectivement mis en cache avec un préfixe. Les insertions ou les modifications dans la séquence signifient qu'elles ne sont pas mises en cache ou qu'elles ne sont que partiellement présentes.