Présentation des bonnes pratiques d'inférence sur GKE

Ce document présente les bonnes pratiques générales pour exécuter des charges de travail d'inférence sur GKE.

Ce document s'adresse aux administrateurs de données, aux opérateurs et aux développeurs qui souhaitent adopter les bonnes pratiques pour leurs charges de travail d'inférence à l'aide d'accélérateurs, tels que les GPU et les TPU, avec Kubernetes et GKE. Pour en savoir plus sur les rôles courants, consultez Rôles utilisateur et tâches courantes de GKE.

Préparer le service d'inférence sur GKE

Cette section décrit les bonnes pratiques de base à suivre lorsque vous vous préparez à déployer une charge de travail d'inférence. Ces pratiques incluent l'analyse de votre cas d'utilisation, le choix des modèles et la sélection des accélérateurs.

Analyser les caractéristiques de votre cas d'utilisation de l'inférence

Avant de déployer une charge de travail d'inférence, analysez ses exigences spécifiques. Cette analyse vous aide à prendre des décisions architecturales qui équilibrent les performances, les coûts et la fiabilité. Comprendre votre cas d'utilisation vous aide à sélectionner les modèles, les accélérateurs et les configurations appropriés pour atteindre vos objectifs de niveau de service (SLO).

Pour guider votre analyse, évaluez les dimensions clés suivantes de votre charge de travail :

  • Définissez les exigences de performances et de latence : déterminez les SLO de latence et de débit de votre application. Les métriques clés à définir incluent les requêtes par seconde (RPS), la latence de réponse, la longueur des jetons d'entrée et de sortie, et le taux de succès de cache (hit) de préfixe. Pour en savoir plus, consultez Métriques de performances d'inférence.
  • Évaluez les exigences et l'échelle du modèle : les caractéristiques du modèle que vous avez choisi ont une incidence directe sur vos besoins en infrastructure. Tenez compte de la longueur maximale du contexte acceptée par le modèle et comparez-la à celle requise par votre charge de travail. Si votre cas d'utilisation ne nécessite pas un contexte maximal, la réduction de la longueur maximale du contexte peut libérer de la mémoire d'accélérateur pour un cache KV plus grand, ce qui peut augmenter le débit.
  • Définissez des contraintes de coût et d'activité : votre budget et vos objectifs commerciaux sont des facteurs clés pour concevoir un service d'inférence durable et économique. Définissez votre coût par million de jetons cible pour les entrées et les sorties, ainsi que votre budget mensuel total pour cette charge de travail. Identifiez votre objectif d'optimisation (par exemple, le rapport prix/performances, la latence la plus faible ou le débit le plus élevé) et déterminez si votre application peut tolérer une latence variable.

Choisir les modèles adaptés à vos cas d'utilisation d'inférence

Le choix du bon modèle a un impact direct sur les performances, le coût et la faisabilité de votre application d'inférence. Pour sélectionner le modèle optimal, évaluez les candidats en fonction des critères suivants :

  • Alignement des tâches et des modalités : évaluez les modèles en fonction des tâches désignées et des modalités acceptées. Un modèle optimisé pour une tâche spécifique surpasse presque toujours un modèle plus polyvalent.
  • Caractéristiques techniques : l'architecture et la précision du type de données d'un modèle (FP16, FP8 et FP4, par exemple) sont des facteurs clés pour déterminer ses besoins en ressources et ses performances. Cette évaluation vous aide à déterminer si vous devez appliquer des techniques de quantification. Vérifiez la précision acceptée pour les pondérations du modèle, assurez-vous que le framework est compatible et vérifiez la longueur de contexte maximale acceptée par le modèle.
  • Performances et rentabilité : pour prendre une décision basée sur les données, comparez les modèles que vous avez présélectionnés à l'aide de benchmarks accessibles au public et de vos propres tests internes. Utilisez des classements comme Chatbot Arena pour comparer les modèles et évaluer le coût par million de jetons pour chaque modèle sur votre matériel cible.

Appliquer la quantification au modèle

La quantification est une technique permettant d'optimiser vos charges de travail d'inférence en réduisant l'empreinte mémoire de votre modèle. Elle convertit les pondérations, les activations et le cache clé-valeur (KV) du modèle à partir de formats à virgule flottante de haute précision (tels que FP16, FP32 et FP64) en formats de précision inférieure (tels que FP8 et FP4). Cette réduction de la mémoire peut entraîner des améliorations significatives en termes de performances et de rentabilité.

La quantification réduit l'empreinte mémoire du modèle, ce qui réduit la surcharge de transfert de données et libère de la mémoire pour un cache KV plus grand.

Pour appliquer efficacement la quantification à vos modèles, suivez ces recommandations :

  • Évaluez le compromis de précision : la quantification peut parfois entraîner une perte de précision du modèle. Lorsque vous évaluez le compromis de précision de la quantification, gardez à l'esprit que la quantification sur 8 bits peut souvent entraîner une perte de précision minime. En revanche, la quantification sur 4 bits peut réduire jusqu'à quatre fois les besoins en mémoire de l'accélérateur, mais elle peut également entraîner une perte de précision plus importante que la quantification sur 8 bits. Évaluez les performances du modèle quantifié pour votre cas d'utilisation spécifique afin de vous assurer que la précision reste dans une plage acceptable. Pour évaluer la perte de précision, vous pouvez utiliser des outils tels que OpenCompass et Language Model Evaluation Harness.
  • Évaluez la compatibilité avec l'accélération matérielle : pour tirer le meilleur parti de la quantification, utilisez des accélérateurs qui fournissent une accélération matérielle pour les formats de données utilisés par le modèle quantifié. Exemple :
    • Les GPU NVIDIA H100 fournissent une accélération matérielle pour les opérations FP8 et FP16.
    • Les GPU NVIDIA B200 offrent une accélération matérielle pour les opérations FP4, FP8 et FP16.
    • Cloud TPU v5p fournit une accélération matérielle pour les opérations FP8.
  • Recherchez des modèles préquantifiés : avant de quantifier un modèle vous-même, consultez les dépôts de modèles publics tels que Hugging Face. Dans l'idéal, trouvez un modèle qui a été entraîné de manière native à une précision inférieure, car cela peut améliorer les performances sans la perte potentielle de précision due à la quantification post-entraînement.
  • Utilisez une bibliothèque de quantification : si aucun modèle préquantifié n'est disponible, utilisez une bibliothèque pour effectuer vous-même la quantification. Les serveurs d'inférence tels que vLLM permettent d'exécuter des modèles quantifiés à l'aide de diverses techniques. Vous pouvez utiliser des outils tels que llm-compressor pour appliquer des techniques de quantification à un modèle non quantifié.
  • Envisagez de quantifier le cache KV : en plus de quantifier les pondérations du modèle, vous pouvez également quantifier le cache KV. Cette technique réduit encore la mémoire requise pour le cache KV lors de l'exécution, ce qui peut améliorer les performances.

Pour en savoir plus, consultez Optimiser les charges de travail d'inférence des LLM sur les GPU.

Choisir les bons accélérateurs

Le choix de l'accélérateur approprié a un impact direct sur les performances, le coût et l'expérience utilisateur de votre service d'inférence. Le choix optimal dépend d'une analyse des besoins en mémoire de votre modèle, de vos objectifs de performances et de votre budget.

Pour choisir l'accélérateur adapté à votre cas d'utilisation spécifique, procédez comme suit :

  1. Calculez vos besoins en mémoire : commencez par calculer la mémoire d'accélérateur minimale requise pour charger et exécuter votre modèle. La mémoire totale correspond à la somme de la mémoire requise pour les pondérations du modèle, la surcharge du moteur d'inférence, les activations intermédiaires et le cache KV.

    Pour estimer la mémoire requise, utilisez l'équation suivante :

    \[ \begin{aligned} \text{Required accelerator memory} = {} & (\text{Model weights} + \text{Overhead} + \text{Activations}) \\ & + (\text{KV cache per batch} \times \text{Batch size}) \end{aligned} \]

    Les termes de l'équation sont les suivants :

    • Poids du modèle : taille des paramètres du modèle.
    • Frais généraux : mémoire tampon pour le serveur d'inférence et autres frais généraux du système, généralement de 1 à 2 Go.
    • Activation : mémoire requise pour les activations intermédiaires lors de l'exécution d'un modèle.
    • Cache KV par lot : mémoire requise pour le cache KV pour une seule séquence, qui évolue en fonction de la longueur du contexte et de la configuration du modèle.
    • Taille du lot : nombre de séquences (max_num_sequences) qui seront traitées simultanément par le moteur d'inférence.

    Exemple : calculer les besoins en mémoire de l'accélérateur pour Gemma 3

    Pour calculer la mémoire d'accélérateur requise pour déployer un modèle Gemma 3 à 27 milliards de paramètres avec une précision BF16 pour un cas d'utilisation de génération de texte, vous pouvez utiliser les valeurs suivantes.

    Pour obtenir une présentation interactive de ce calcul, consultez De quelle quantité de VRAM mon modèle a-t-il besoin ? Notebook Colab.

    • Entrées :
      • Pondérations du modèle : 54 Go
      • Taille du lot (max_num_sequences) : 1
      • Longueur moyenne des entrées : 1 500 jetons
      • Longueur moyenne de la réponse : 200 jetons
      • Frais généraux du moteur d'inférence : 1 Go (estimation)
      • Taille du type de données du cache KV : 2 (pour BF16)
      • Vecteurs KV : 2 (un pour la clé et un pour la valeur)
    • Configuration du modèle pour un modèle Gemma 3 27B adapté aux instructions :
      • hidden_size : 5376
      • intermediate_size : 21504
      • num_attention_heads : 32
      • num_hidden_layers : 62
      • num_key_value_heads : 16
    • Calcul de la mémoire :
      • sequence_length = avg_input_length + avg_output_length = 1 500 + 200 = 1 700 jetons
      • pytorch_activation_peak_memory = (max_num_sequences * sequence_length * (18 * hidden_size + 4 * intermediate_size)) / (1000^3) = ~0,31 Go (estimation).
      • head_dims = hidden_size / num_attention_heads = 5376 / 32 = 168
      • kv_cache_memory_per_batch = (kv_vectors * max_num_sequences * sequence_length * num_key_value_heads * head_dims * num_hidden_layers * kv_data_type_size) / (1000^3) = (2 * 1 * 1700 * 16 * 168 * 62 * 2) / (1000^3) = ~1,13 Go
      • Mémoire de l'accélérateur requise = Model weights + Overhead + Activations + KV cache per batch = 54 + 1 + 0,31 + 1,13 = ~56,44 Go

    La mémoire totale estimée de l'accélérateur dont vous avez besoin pour déployer le modèle est d'environ 57 Go.

  2. Évaluez les options d'accélérateur : une fois que vous avez estimé vos besoins en mémoire, évaluez les options GPU et TPU disponibles sur GKE.

    En plus de la quantité de mémoire de l'accélérateur, tenez compte des exigences suivantes concernant le modèle pour votre évaluation :

    • Pour les modèles qui nécessitent plusieurs accélérateurs, vérifiez la compatibilité avec la connectivité à haut débit, comme NVLINK et GPUDirect, afin de réduire la latence de communication.
    • Pour les modèles quantifiés, utilisez des accélérateurs avec accélération matérielle native pour les types de données de précision inférieure, tels que FP8 et FP4, afin d'obtenir les meilleurs avantages en termes de performances.

    Votre choix implique un compromis entre ces fonctionnalités, les performances, le coût et la disponibilité.

    Conseil : Pour obtenir les dernières recommandations d'accélérateurs basées sur des benchmarks de performances de diffusion et une analyse des coûts, vous pouvez également utiliser l'outil de démarrage rapide de l'inférence GKE. Pour en savoir plus, consultez la documentation Guide de démarrage rapide de GKE Inference.

    Pour vous aider à choisir les accélérateurs adaptés à votre charge de travail, le tableau suivant récapitule les options les plus appropriées pour les cas d'utilisation d'inférence courants. Ces cas d'utilisation sont définis comme suit :

    • Inférence de petits modèles : pour les modèles comportant quelques milliards de paramètres, où la charge de calcul est limitée à un seul hôte.
    • Inférence de grands modèles sur un seul hôte : pour les modèles comportant des dizaines à des centaines de milliards de paramètres, où la charge de calcul est répartie sur plusieurs accélérateurs sur une seule machine hôte.
    • Inférence de grands modèles multi-hôtes : pour les modèles comportant des centaines de milliards à des milliers de milliards de paramètres, où la charge de calcul est partagée entre plusieurs accélérateurs sur plusieurs machines hôtes.
    Cas d'utilisation Accélérateurs recommandés Série de machines Caractéristiques clés
    Inférence de petits modèles NVIDIA L4 G2 Option économique pour les petits modèles (24 Go de mémoire par GPU).
    NVIDIA RTX Pro 6000 G4 Solution économique pour les modèles de moins de 30 milliards de paramètres et la génération d'images (96 Go de mémoire par GPU). Prend en charge la communication GPU peer-to-peer directe, ce qui la rend adaptée à l'inférence multi-GPU à hôte unique.
    TPU v5e - Optimisé pour la rentabilité.
    TPU v6e - Offre la plus grande valeur pour les modèles de transformateurs et de texte en image.
    Inférence de grands modèles à hôte unique NVIDIA A100 A2 Convient à la plupart des modèles qui tiennent sur un seul nœud (jusqu'à 640 Go de mémoire totale).
    NVIDIA H100 A3 Idéal pour les charges de travail d'inférence qui tiennent sur un seul nœud (jusqu'à 640 Go de mémoire totale).
    NVIDIA B200 A4 Option évolutive pour les modèles exigeants qui tiennent sur un seul nœud (jusqu'à 1 440 Go de mémoire totale).
    TPU v4 - Offre un bon équilibre entre coût et performances.
    TPU v5p - Option hautes performances pour les charges de travail exigeantes.
    Inférence de grands modèles multi-hôtes NVIDIA H200 A3 Ultra Convient aux grands modèles gourmands en mémoire (jusqu'à 1 128 Go de mémoire totale).
    NVIDIA B200 / GB200 A4 / A4X Pour les charges de travail les plus exigeantes, gourmandes en calcul et liées au réseau. Les machines A4X utilisent des processeurs basés sur Arm, ce qui peut nécessiter une refactorisation de la charge de travail (modifications du code au-delà d'une simple recompilation du conteneur) si votre charge de travail utilise des fonctionnalités ou des optimisations spécifiques à x86.
    TPU v5e - Optimisé pour l'efficacité et les performances pour le serving de LLM de taille moyenne à grande.
    TPU v5p - Option hautes performances pour l'inférence multihôte nécessitant une parallélisation à grande échelle.
    TPU v6e - Optimisé pour le serving de transformateurs, de modèles de conversion de texte en image et de CNN.

    Exemple : Choisir un accélérateur pour un modèle de 260 Go

    Imaginons que vous deviez déployer un modèle nécessitant 260 Go de mémoire d'accélérateur totale (200 Go pour le modèle, 50 Go pour le cache KV et 10 Go pour la surcharge).

    En fonction des besoins en mémoire uniquement, vous pouvez exclure les GPU NVIDIA L4, car la plus grande machine G2 offre un maximum de 192 Go de mémoire d'accélérateur. De plus, comme les GPU L4 ne sont pas compatibles avec la connectivité à haut débit et à faible latence entre les accélérateurs, la répartition de la charge de travail sur plusieurs nœuds n'est pas une option viable pour atteindre les performances souhaitées.

    Si vous souhaitez éviter de refactoriser vos charges de travail x86-64 (c'est-à-dire de devoir modifier votre code pour qu'il puisse s'exécuter sur un autre type de processeur), vous devez également exclure les accélérateurs NVIDIA GB200 et GB300, qui utilisent des processeurs basés sur Arm.

    Il vous reste les options suivantes :

    • NVIDIA A100
    • NVIDIA RTX Pro 6000
    • NVIDIA H100
    • NVIDIA H200
    • NVIDIA B200

    Tous ces accélérateurs disposent de suffisamment de mémoire. L'étape suivante consiste à évaluer leur disponibilité dans vos régions cibles. Supposons que vous constatiez que seuls les GPU NVIDIA A100 et NVIDIA H100 sont disponibles dans une région spécifique. Après avoir comparé le rapport prix/performances de ces deux options, vous pouvez choisir le GPU NVIDIA H100 pour votre charge de travail.

    GPU multi-instances

    Pour augmenter l'utilisation des GPU et optimiser leurs coûts, vous pouvez utiliser des configurations de GPU multi-instances. Avec cette configuration, vous partitionnez un GPU compatible pour partager un seul GPU sur plusieurs conteneurs sur GKE. Lorsque vous provisionnez un GPU multi-instance, vous n'associez que des GPU entiers à vos nœuds GKE et vous êtes soumis à la tarification des GPU correspondante. Nous vous recommandons d'utiliser des GPU multi-instances uniquement avec des charges de travail approuvées.

    Par exemple, vous pouvez associer une carte NVIDIA RTX PRO 6000 et effectuer les opérations suivantes :

    • Partitionnez-la en quatre instances (chaque instance fournit 24 Go de mémoire d'accélérateur) et exécutez des charges de travail d'inférence de modèles de diffusion ou de petits modèles, tels que des modèles comportant environ 8 milliards de paramètres et utilisant la précision du format de données FP16 pour les poids du modèle. Cette partition peut présenter un meilleur rapport prix/performances qu'une NVIDIA L4.
    • Partitionnez-le en deux instances (chacune fournissant 48 Go de mémoire d'accélérateur) et exécutez de petites charges de travail d'inférence de modèle, telles que des modèles comportant environ 15 milliards de paramètres et utilisant la précision du format de données FP16 pour les poids du modèle. Cette partition peut être une alternative à l'exécution de charges de travail d'inférence sur un GPU NVIDIA A100 de 40 Go.

    Pour en savoir plus, consultez Exécuter des GPU multi-instances.

    Pour en savoir plus, consultez les sections Types de machines GPU et Famille de machines optimisées pour les accélérateurs dans la documentation Compute Engine.

  3. Sélectionnez une stratégie de distribution d'inférence : si votre modèle est trop volumineux pour un seul accélérateur, sélectionnez une stratégie de distribution en fonction des exigences de votre charge de travail.

    Commencez par choisir une stratégie de distribution en fonction de la topologie de votre matériel :

    • Accélérateur unique : si votre modèle tient sur un seul accélérateur, il s'agit de l'approche la plus simple et recommandée.
    • Nœud unique, accélérateurs multiples : si votre modèle tient sur un seul nœud avec plusieurs accélérateurs, vous pouvez utiliser le parallélisme de tenseur pour distribuer le modèle sur les accélérateurs de ce nœud.
    • Plusieurs nœuds, plusieurs accélérateurs : si votre modèle est trop volumineux pour un seul nœud, vous pouvez utiliser une combinaison de parallélisme de tenseur et de pipeline pour le répartir sur plusieurs nœuds.

    Pour mettre en œuvre ces stratégies, vous pouvez utiliser les techniques de parallélisme suivantes :

    • Parallélisme Tensor : cette technique fragmente les couches d'un modèle sur plusieurs accélérateurs. Elle est très efficace au sein d'un même nœud avec des interconnexions à haut débit comme NVLINK ou PCIe direct peer-to-peer, mais elle nécessite une communication importante entre les accélérateurs.

      Exemple : parallélisme de tenseur

      Par exemple, imaginons que vous deviez déployer un modèle avec 109 milliards de paramètres. À sa précision BF16 (16 bits) par défaut, le chargement des poids du modèle dans la mémoire de l'accélérateur nécessite environ 113 Go. Un seul GPU NVIDIA H100 fournit 80 Go de mémoire. Par conséquent, même sans tenir compte des autres exigences de mémoire telles que le cache KV, vous avez besoin d'au moins deux GPU NVIDIA H100 pour charger le modèle, en utilisant une taille de parallélisme tensoriel de deux.

    • Parallélisme des pipelines : cette technique partitionne les couches d'un modèle de manière séquentielle sur plusieurs nœuds. Il est bien adapté à la distribution d'un modèle sur plusieurs nœuds dans un déploiement multihôte et nécessite moins de communication entre les rangs de modèle que le parallélisme tensoriel.

      Exemple : Parallélisme hybride (tenseur et pipeline)

      Pour un très grand modèle comportant plus de 600 milliards de paramètres, la mémoire requise peut dépasser 1,1 To. Dans un scénario avec deux nœuds a3-megagpu-8g (chacun avec huit GPU NVIDIA H100), le cluster total dispose de 1,28 To de mémoire d'accélérateur. Pour exécuter le modèle, vous devez implémenter une stratégie hybride : parallélisme tensoriel à huit voies dans chaque nœud et parallélisme de pipeline à deux voies sur les deux nœuds. Le modèle serait divisé en deux étapes, la première moitié des couches se trouvant sur le premier nœud et la seconde moitié sur le second nœud. Lorsqu'une requête arrive, le premier nœud la traite et envoie les données intermédiaires sur le réseau au deuxième nœud, qui termine le calcul.

    Pour obtenir d'autres consignes sur le choix d'une stratégie d'inférence distribuée pour une réplique de modèle unique, consultez Parallélisme et mise à l'échelle dans la documentation vLLM.

  4. Sélectionnez un type de machine optimisé pour les accélérateurs : en fonction de votre choix d'accélérateur et du nombre dont vous avez besoin, sélectionnez un type de machine qui fournit ces ressources. Chaque type de machine offre une combinaison spécifique de processeurs virtuels, de mémoire système et de bande passante réseau, ce qui peut également avoir un impact sur les performances de votre charge de travail. Par exemple, si vous avez besoin de 16 GPU NVIDIA H100, vous devez sélectionner le type de machine a3-megagpu-16g.

  5. Exécutez vos propres benchmarks : les performances de votre charge de travail d'inférence dépendent fortement de votre cas d'utilisation spécifique. Exécutez vos propres benchmarks pour valider vos choix et affiner votre configuration.

Optimiser la configuration de votre serveur d'inférence

Pour obtenir des performances optimales lorsque vous déployez votre charge de travail d'inférence, nous vous recommandons un cycle d'analyse comparative et d'ajustement :

  1. Commencez par le guide de démarrage rapide GKE Inference pour obtenir une configuration Kubernetes de base optimisée pour votre cas d'utilisation.
  2. Exécutez des benchmarks pour capturer les métriques de débit et de latence de référence.
  3. Ajustez la configuration de votre serveur d'inférence.
  4. Exécutez à nouveau des benchmarks et comparez les résultats pour valider vos modifications.

Les recommandations suivantes sont basées sur le serveur d'inférence vLLM, mais les principes s'appliquent également aux autres serveurs. Pour obtenir des conseils détaillés sur tous les paramètres disponibles, consultez la documentation Optimisation et réglage de vLLM :

  • Configurer le parallélisme :
    • Parallélisme de tenseur (tensor_parallel_size) : définissez ce paramètre sur le nombre d'accélérateurs sur un seul nœud pour segmenter la charge de travail. Par exemple, définir tensor_parallel_size=4 répartira la charge de travail sur quatre accélérateurs. Sachez que l'augmentation de cette valeur peut entraîner une surcharge de synchronisation excessive.
    • Parallélisme du pipeline (pipeline_parallel_size) : définissez cette valeur sur le nombre de nœuds sur lesquels vous distribuez votre modèle. Par exemple, si vous effectuez un déploiement sur deux nœuds avec huit accélérateurs chacun, vous devez définir tensor_parallel_size=8 et pipeline_parallel_size=2. L'augmentation de cette valeur peut entraîner des pénalités de latence.
  • Ajuster le cache KV (gpu_memory_utilization) : ce paramètre contrôle le pourcentage de mémoire GPU réservé aux pondérations, aux activations et au cache KV du modèle. Une valeur plus élevée augmente la taille du cache KV et peut améliorer le débit. Nous vous recommandons de définir cette valeur sur une valeur comprise entre 0.9 et 0.95. Si vous rencontrez des erreurs de mémoire insuffisante (OOM), diminuez cette valeur.
  • Configurer la longueur de contexte maximale (max_model_len) : pour réduire la taille du cache KV et les besoins en mémoire, vous pouvez définir une longueur de contexte maximale inférieure à celle par défaut du modèle. Cela peut vous permettre d'utiliser des GPU plus petits et plus économiques. Par exemple, si votre cas d'utilisation ne nécessite qu'un contexte de 40 000 jetons, mais que la valeur par défaut de votre modèle est de 256 000, définir max_model_len sur 40 000 libérera de la mémoire pour un cache KV plus grand, ce qui pourrait entraîner un débit plus élevé.
  • Configurez le nombre de requêtes simultanées (max_num_batched_tokens, max_num_seqs) : ajustez le nombre maximal de requêtes que vLLM traite simultanément pour éviter la préemption lorsque le cache KV manque d'espace. Des valeurs inférieures pour max_num_batched_tokens et max_num_seqs réduisent les besoins en mémoire, tandis que des valeurs plus élevées peuvent améliorer le débit au risque d'erreurs OOM. Pour trouver les valeurs optimales, nous vous recommandons d'exécuter des tests de performances et d'observer le nombre de demandes de préemption dans les métriques Prometheus exportées par vLLM.

Pour en savoir plus, consultez les ressources suivantes :

Optimiser la latence et la disponibilité

Pour que votre service d'inférence soit à la fois réactif et fiable, vous devez l'optimiser pour une faible latence de démarrage et une disponibilité élevée des ressources.

Optimiser la latence de démarrage à froid des charges de travail d'inférence

Il est essentiel de réduire au minimum le temps nécessaire au démarrage de vos charges de travail d'inférence, à la fois pour l'efficacité des coûts et pour l'expérience utilisateur. Une faible latence de démarrage à froid permet à votre cluster de s'adapter rapidement à la demande, ce qui garantit un service réactif tout en minimisant le besoin de surprovisionnement coûteux.

Optimiser le temps de démarrage des pods

Le temps nécessaire à la préparation d'un pod dépend en grande partie du temps nécessaire à l'extraction de l'image de conteneur et au téléchargement des pondérations du modèle. Pour optimiser les deux, envisagez les stratégies suivantes :

  • Accélérer le chargement du modèle avec un chargeur de données optimisé : la méthode que vous utilisez pour stocker et charger les pondérations de votre modèle a un impact significatif sur le temps de démarrage. Pour les versions 0.10.2 et ultérieures de vLLM, l'approche recommandée consiste à utiliser Run:ai Model Streamer pour charger les modèles en les diffusant directement depuis un bucket Cloud Storage.

    Si le flux n'est pas disponible pour votre cas d'utilisation, vous pouvez installer un bucket Cloud Storage à l'aide de Cloud Storage FUSE et ajuster ses performances en activant les espaces de noms hiérarchiques et en utilisant des techniques telles que les téléchargements parallèles et la prélecture. Pour en savoir plus sur ces techniques, consultez Optimiser les performances du pilote CSI Cloud Storage FUSE pour GKE. Dans les deux cas, nous vous recommandons d'utiliser Anywhere Cache pour créer des caches de lecture zonaux performants pour vos buckets et d'activer l'accès uniforme au niveau du bucket pour contrôler l'accès à vos buckets de manière uniforme.

    Si vous utilisez déjà Managed Lustre pour le stockage de fichiers hautes performances pour vos charges de travail d'entraînement, vous pouvez également l'utiliser pour charger les pondérations de modèle pour l'inférence. Cette approche offre un accès à faible latence lorsque la localité des données et la compatibilité POSIX sont essentielles.

  • Activer le streaming d'images : pour réduire le temps nécessaire à l'extraction de vos images de conteneur, activez le streaming d'images sur votre cluster GKE. Le streaming d'images permet à vos conteneurs de démarrer avant le téléchargement de l'image entière, ce qui peut réduire considérablement le temps de démarrage des pods.

Activer les nœuds à démarrage rapide

Pour les charges de travail qui nécessitent un scaling rapide, vous pouvez profiter des nœuds à démarrage rapide dans GKE. Les nœuds à démarrage rapide sont des ressources matérielles pré-initialisées dont le temps de démarrage est nettement plus court que celui des nœuds standards. Si votre cluster répond aux exigences, GKE active automatiquement les nœuds à démarrage rapide.

Planifier la capacité et maximiser la disponibilité des accélérateurs

La disponibilité des accélérateurs très demandés, comme les GPU et les TPU, peut être limitée. Il est donc essentiel d'adopter une stratégie de planification proactive de la capacité.

Planifier et réserver la capacité

La disponibilité des accélérateurs à forte demande peut être limitée. Il est donc essentiel d'adopter une stratégie de planification proactive de la capacité. Pour garantir l'accès aux ressources dont vous avez besoin, suivez ces recommandations :

  • Déterminez la capacité de référence et la gestion des pics : planifiez la capacité de référence de l'accélérateur que vous devez réserver. Le montant à réserver dépend de votre cas d'utilisation. Par exemple, vous pouvez réserver 100 % de la capacité requise pour les charges de travail critiques qui ne tolèrent aucun retard, ou vous pouvez réserver un certain centile (comme le 90e ou le 95e) et acquérir le reste à la demande pour gérer les pics.

  • Réserver une capacité de base : pour obtenir des ressources avec un niveau d'assurance élevé, créez des réservations. Vous pouvez choisir un type de réservation en fonction de vos besoins. Par exemple, pour réserver des ressources très demandées comme des accélérateurs pour une période future spécifique, vous pouvez créer des réservations futures en mode Agenda.

  • Orchestrer la capacité pour les pics : pour la demande qui dépasse vos réservations de référence, vous pouvez mettre en œuvre une stratégie de repli en utilisant d'autres types de capacité, comme les VM à la demande, les VM Spot ou le planificateur de charges de travail dynamique (DWS). Vous pouvez automatiser cette stratégie de secours en utilisant des classes de calcul personnalisées pour définir un ordre de priorité pour le provisionnement de différents types de capacité.

  • Accédez à des prix réduits : pour votre capacité de base, achetez des remises sur engagement d'utilisation pour bénéficier de prix fortement réduits en échange d'un engagement d'un ou trois ans.

Utilisez le planificateur de charges de travail dynamique avec le mode de provisionnement à démarrage flexible si vos charges de travail tolèrent les retards dans l'acquisition de capacité.

Pour les charges de travail qui peuvent tolérer un certain délai dans l'acquisition de capacité, le planificateur de charge de travail dynamique (DWS) avec le mode de provisionnement à démarrage flexible est une option permettant d'obtenir des accélérateurs à un prix réduit. Le programmeur de charge de travail dynamique vous permet de mettre en file d'attente des demandes de capacité pour une durée maximale de sept jours.

Lorsque vous utilisez DWS avec le mode de provisionnement de démarrage Flex, nous vous recommandons ce qui suit :

  • Intégrez-le à une classe de calcul personnalisée : utilisez une classe de calcul personnalisée pour définir le DWS dans une stratégie de remplacement prioritaire pour acquérir de la capacité.
  • Définir une durée d'exécution maximale : le paramètre maxRunDurationSeconds définit la durée d'exécution maximale des nœuds demandés via DWS. Si vous définissez une valeur inférieure à la valeur par défaut de sept jours, vous avez plus de chances d'obtenir les nœuds demandés.
  • Activer le recyclage des nœuds : pour éviter les temps d'arrêt de vos charges de travail, activez le recyclage des nœuds. Cette fonctionnalité commence à provisionner un nouveau nœud avant l'expiration de l'ancien, ce qui assure une transition plus fluide.
  • Minimisez les perturbations : pour minimiser les perturbations causées par l'éviction et les mises à niveau des nœuds, configurez des intervalles et des exclusions de maintenance, désactivez la réparation automatique des nœuds et profitez de la stratégie de mises à niveau de courte durée.

Utiliser des classes de calcul personnalisées

Les classes de calcul personnalisées sont une fonctionnalité GKE qui vous permet de définir une liste hiérarchisée de configurations d'infrastructure pour vos charges de travail. Les CCC offrent des fonctionnalités clés conçues pour améliorer l'obtention d'accélérateurs :

  • Priorités de calcul de remplacement : vous pouvez définir une liste de configurations classées par ordre de priorité. Si votre option préférée n'est pas disponible lors d'un événement de scaling à la hausse, l'autoscaler passe automatiquement à la suivante dans la liste, ce qui augmente considérablement la probabilité d'acquérir de la capacité.
  • Migration active vers des nœuds de priorité supérieure : lorsque vous configurez cette fonctionnalité, GKE remplace automatiquement les nœuds exécutés sur des configurations de priorité inférieure par des nœuds de configurations de priorité supérieure à mesure qu'ils deviennent disponibles. Cela permet de s'assurer que vos pods s'exécutent finalement sur vos nœuds préférés (et souvent les plus rentables).

Les classes de calcul personnalisées vous permettent de créer une stratégie de remplacement pour acquérir des nœuds. Cette stratégie utilise une liste hiérarchisée de différents types de capacité, tels que les VM à la demande, les VM Spot ou les réservations. Chacun de ces types de capacité présente un niveau de disponibilité différent :

  • Les réservations offrent le plus haut niveau d'assurance pour l'obtention de la capacité. Tenez compte des restrictions lorsque vous utilisez des réservations avec des CCC. Par exemple, certains types de réservations limitent les types de machines que vous pouvez réserver ou le nombre maximal de machines que vous pouvez demander.
  • À la demande : modèle de provisionnement standard, qui offre de la flexibilité, mais qui peut être soumis à des contraintes de capacité régionale pour les ressources à forte demande.
  • VM Spot : utilisez la capacité disponible à un prix inférieur, mais les VM peuvent être préemptées. Lorsqu'un événement de préemption se produit, GKE accorde aux pods concernés un délai de grâce de 30 secondes maximum pour l'arrêt progressif, dans la mesure du possible. Pour en profiter, rendez vos charges de travail tolérantes aux événements de préemption en implémentant des points de contrôle et des mécanismes de nouvelle tentative.
  • Le programmeur de charge de travail dynamique vous permet de mettre en file d'attente les demandes de ressources rares à des prix réduits. Cette fonctionnalité est idéale pour les charges de travail qui peuvent tolérer des délais dans l'acquisition de capacité.

L'ordre de votre liste de priorités doit changer selon que votre objectif principal est de minimiser la latence ou d'optimiser les coûts. Par exemple, vous pouvez configurer les listes de priorité suivantes pour différentes exigences de charge de travail :

Priorité Charges de travail à faible latence Charges de travail optimisées pour les coûts (tolérantes à la latence)
1 Réservations (spécifiques, puis toutes) Réservations (spécifiques, puis toutes)
2 À la demande VM Spot
3 VM Spot Programmeur de charge de travail dynamique
4 Programmeur de charge de travail dynamique À la demande

Pour les cas d'utilisation à faible latence, la capacité à la demande est prioritaire après les réservations, car elle signale rapidement les pénuries de capacité, ce qui permet au CCC de revenir rapidement à l'option suivante.

Pour les cas d'utilisation optimisés pour les coûts, les VM Spot et DWS avec démarrage flexible sont prioritaires après les réservations afin de profiter de coûts plus bas. La capacité à la demande est utilisée comme dernier recours.

Configurer la règle d'emplacement de vos clusters et pools de nœuds GKE

La règle d'emplacement de l'autoscaler de cluster contrôle la façon dont GKE distribue les nœuds dans les zones lors d'un événement de scaling à la hausse. Ce paramètre est particulièrement important lorsque vous utilisez des classes de calcul personnalisées, car il détermine les zones que l'autoscaler de cluster prendra en compte avant d'appliquer la liste de priorité des CCC.

Pour augmenter vos chances d'obtenir des accélérateurs, configurez la stratégie d'emplacement en fonction des exigences de votre charge de travail :

  • location-policy=ANY : la priorité est d'obtenir de la capacité plutôt que d'équilibrer les nœuds de manière uniforme entre les zones. Ce paramètre est particulièrement pertinent lorsque votre CCC inclut des VM Spot ou des types de machines à disponibilité variable, car ANY permet à l'autoscaler de cluster de choisir la zone la plus susceptible de répondre aux types de nœuds prioritaires du CCC. Utilisez également ce paramètre pour donner la priorité à l'utilisation des réservations inutilisées. Lorsque vous utilisez cette règle, nous vous recommandons de commencer par num-nodes=0 pour donner à Cluster Autoscaler un maximum de flexibilité dans la recherche de capacité.

  • location-policy=BALANCED : tente de répartir les nœuds de manière égale dans toutes les zones disponibles. Utilisez cette règle lorsque vos charges de travail utilisent des ressources facilement disponibles et que vous souhaitez maintenir la redondance zonale pour une haute disponibilité.

Vous pouvez configurer ce paramètre lorsque vous créez ou mettez à jour un pool de nœuds.

Optimiser l'efficacité et les coûts

En surveillant attentivement vos accélérateurs et en adaptant intelligemment vos charges de travail, vous pouvez réduire considérablement le gaspillage et vos coûts opérationnels.

Observer vos accélérateurs et vos serveurs d'inférence

Une stratégie d'observabilité complète est essentielle pour comprendre les performances et l'utilisation de vos charges de travail d'inférence. GKE fournit une suite d'outils pour vous aider à surveiller vos accélérateurs et vos serveurs d'inférence :

  • Surveiller les métriques DCGM pour les GPU NVIDIA : pour surveiller l'état et les performances de vos GPU NVIDIA, configurez GKE pour qu'il envoie les métriques NVIDIA Data Center GPU Manager (DCGM) à Cloud Monitoring.
  • Activez la surveillance automatique des applications : pour simplifier la surveillance de vos serveurs d'inférence, activez la surveillance automatique des applications dans GKE.
  • Instrumentez vos charges de travail avec OpenTelemetry : pour les charges de travail qui ne sont pas compatibles avec la surveillance automatique des applications, utilisez OpenTelemetry pour collecter des métriques et des traces personnalisées.

Faire évoluer automatiquement vos pods

Pour vous assurer que vos charges de travail d'inférence peuvent s'adapter dynamiquement aux variations de la demande, utilisez un autoscaler horizontal de pods (AHP) pour ajuster automatiquement le nombre de pods. Pour les charges de travail d'inférence, il est essentiel de baser vos décisions de scaling sur des métriques qui reflètent directement la charge sur le serveur d'inférence, plutôt que sur les métriques standards de processeur ou de mémoire.

Pour configurer l'autoscaling pour vos charges de travail d'inférence, nous vous recommandons les éléments suivants :

  • Configurer HPA en fonction des métriques d'inférence : pour des performances optimales, configurez AHP pour qu'il évolue en fonction des métriques de votre serveur d'inférence. La meilleure métrique dépend de l'optimisation que vous souhaitez effectuer (faible latence ou débit élevé).

    • Pour les charges de travail sensibles à la latence, vous avez deux options principales :

      • Utilisation du cache KV (par exemple, vllm:gpu_cache_usage_perc) : cette métrique est souvent le meilleur indicateur des pics de latence à venir. Une utilisation élevée du cache KV indique que le moteur d'inférence approche de sa capacité maximale. Le HPA peut utiliser ce signal pour ajouter des répliques de manière préventive et maintenir une expérience utilisateur stable.
      • Nombre de requêtes en cours d'exécution (taille de lot) (par exemple,vllm:num_requests_running) : cette métrique est directement liée à la latence, car les tailles de lot plus petites entraînent généralement une latence plus faible. Toutefois, l'utiliser pour l'autoscaling peut être difficile, car la maximisation du débit dépend de la taille des requêtes entrantes. Vous devrez peut-être choisir une valeur inférieure à la taille de lot maximale possible pour vous assurer que l'AHP évolue correctement à la hausse.

    • Pour les charges de travail sensibles au débit, effectuez un scaling en fonction de la taille de la file d'attente (par exemple, vllm:num_requests_waiting). Cette métrique mesure directement le backlog de travail et constitue un moyen simple d'adapter la capacité de traitement à la demande entrante. Étant donné que cette métrique ne prend en compte que les requêtes en attente et non celles en cours de traitement, elle peut ne pas atteindre la latence la plus faible possible par rapport à la mise à l'échelle en fonction de la taille du lot.

  • Définissez un nombre minimal d'instances répliquées : pour garantir une disponibilité cohérente et une expérience utilisateur de base, définissez toujours un nombre minimal d'instances répliquées pour votre déploiement d'inférence.

  • Activez le profil HPA de performances : sur les versions 1.33 ou ultérieures de GKE, le profil HPA de performances est activé par défaut sur les clusters éligibles pour améliorer le temps de réaction du AHP.

Pour en savoir plus, consultez Configurer HPA pour les charges de travail LLM sur les GPU et Autoscaler les charges de travail d'inférence LLM sur les TPU.

Rapprocher les données de vos charges de travail

Le temps nécessaire à vos charges de travail pour charger des données, telles que les pondérations de modèle, peut être une source importante de latence. En rapprochant vos données de vos ressources de calcul, vous pouvez réduire les temps de transfert de données et améliorer les performances globales.

  • Créez des caches de lecture zonaux avec Anywhere Cache : si vous utilisez Cloud Storage pour stocker des données pour vos charges de travail d'IA/ML, activez Anywhere Cache. Anywhere Cache crée des caches de lecture zonaux hautes performances pour vos buckets Cloud Storage.
  • Mettre en cache les données fréquemment consultées sur des disques SSD locaux : pour les charges de travail qui nécessitent un accès à très faible latence aux données temporaires, utilisez des disques SSD locaux comme cache hautes performances. L'utilisation de disques SSD locaux comme stockage temporaire à faible latence pour stocker les données fréquemment utilisées vous aide à réduire le temps d'inactivité des ressources coûteuses, telles que les accélérateurs, en réduisant considérablement le temps d'attente des accélérateurs pour la fin des opérations d'E/S. Notez que toutes les séries de machines ne sont pas compatibles avec les SSD locaux, ce qui peut avoir une incidence sur votre choix d'accélérateurs.
  • Gérer les caches avec GKE Data Cache : pour les charges de travail qui lisent fréquemment des données à partir de disques persistants, activez GKE Data Cache. GKE Data Cache utilise des disques SSD locaux pour créer un cache géré hautes performances pour vos disques persistants. Pour la plupart des charges de travail de production, nous vous recommandons d'utiliser le mode Writethrough afin d'éviter toute perte de données en écrivant les données de manière synchrone dans le cache et sur le disque persistant sous-jacent.

Optimiser pour les architectures de scaling avancées

Pour répondre aux exigences des applications à grande échelle ou distribuées à l'échelle mondiale, vous pouvez adopter des architectures de scaling avancées afin d'améliorer les performances, la fiabilité et la gestion du trafic.

Équilibrer la charge du trafic avec la passerelle d'inférence GKE

Pour les charges de travail d'inférence dans un seul cluster, nous vous recommandons d'utiliser GKE Inference Gateway. La passerelle d'inférence est un équilibreur de charge basé sur l'IA qui surveille les métriques d'inférence pour acheminer les requêtes vers le point de terminaison le plus optimal. Cette fonctionnalité améliore les performances et l'utilisation des accélérateurs.

Lorsque vous utilisez la passerelle d'inférence GKE, nous vous recommandons de suivre ces bonnes pratiques :

  • Regroupez les pods de diffusion dans un InferencePool : définissez un InferencePool pour chaque groupe de pods diffusant vos charges de travail d'inférence. Pour en savoir plus, consultez Personnaliser la configuration de la passerelle GKE Inference.
  • Multiplexer les charges de travail critiques en termes de latence : définissez InferenceObjectives pour spécifier les propriétés de diffusion de votre modèle, telles que son nom et sa priorité. GKE Inference Gateway donne la priorité aux charges de travail de priorité plus élevée, ce qui vous permet de multiplexer les charges de travail critiques en termes de latence et celles tolérantes à la latence, et d'implémenter des stratégies de délestage en cas de trafic important.
  • Utiliser le routage adapté au modèle : pour acheminer les requêtes en fonction du nom du modèle dans le corps de la requête, utilisez le routage basé sur le corps. Lorsque vous utilisez le routage basé sur le corps, assurez-vous que vos backends sont disponibilité élevée. La passerelle renvoie une erreur si l'extension n'est pas disponible, ce qui empêche le routage incorrect des requêtes.
  • Autorisez la passerelle à distribuer automatiquement le trafic : GKE Inference Gateway achemine intelligemment le trafic en surveillant les métriques clés des serveurs d'inférence dans InferencePool, telles que l'utilisation du cache KV, la longueur de la file d'attente et les index du cache de préfixes. Cet équilibrage de charge en temps réel optimise l'utilisation des accélérateurs, réduit la latence de queue et augmente le débit global par rapport aux méthodes traditionnelles.
  • Intégrer Apigee et Model Armor : pour améliorer la sécurité et la gestion, intégrez Apigee pour la gestion des API et Model Armor pour les contrôles de sécurité.

Déployer des charges de travail d'inférence sur plusieurs nœuds

Pour les très grands modèles qui ne peuvent pas tenir sur un seul nœud, vous devez répartir votre charge de travail d'inférence sur plusieurs nœuds. Cela nécessite une architecture qui minimise la latence de communication entre les nœuds et garantit que tous les composants de la charge de travail distribuée sont gérés comme une seule unité.

Tenez compte des bonnes pratiques suivantes :

  • Maximisez la bande passante et le débit du réseau d'accélérateurs : lorsqu'une charge de travail est distribuée sur plusieurs nœuds, le réseau devient un facteur de performance essentiel. Pour minimiser la latence de communication entre les nœuds, utilisez des technologies de mise en réseau hautes performances telles que NVIDIA GPUDirect. Selon la taille de votre cluster et l'intensité de la communication requise par votre charge de travail, vous pouvez choisir parmi les options suivantes :

    • GPUDirect-TCPX : efficace pour une gamme de charges de travail d'inférence multinœuds exécutées sur A3 High.
    • GPUDirect-TCPXO : offre des performances améliorées avec une décharge plus importante et une bande passante plus élevée, ce qui est avantageux pour les grands clusters par rapport à TCPX standard. Il s'exécute sur les machines A3 Mega.
    • GPUDirect RDMA : offre la bande passante inter-nœuds la plus élevée et la latence la plus faible en permettant l'accès direct à la mémoire entre les GPU de différents nœuds, en contournant le processeur. Il est idéal pour les scénarios d'inférence à grande échelle les plus exigeants sur les machines A3 Ultra et A4.

    Pour en savoir plus, consultez :

    Pour vérifier que la configuration de votre réseau multinœud fonctionne comme prévu, nous vous recommandons d'exécuter des tests avec des outils tels que la bibliothèque NVIDIA Collective Communications Library (NCCL).

  • Utiliser LeaderWorkerSet pour gérer les charges de travail distribuées : lorsque vous déployez une charge de travail distribuée avec état, telle qu'un service d'inférence multinœud, il est essentiel de gérer tous ses composants comme une seule unité. Pour ce faire, utilisez LeaderWorkerSet, une API native de Kubernetes qui vous permet de gérer un groupe de pods associés en tant qu'entité unique. Un LeaderWorkerSet garantit que tous les pods de l'ensemble sont créés et supprimés ensemble, ce qui est essentiel pour maintenir l'intégrité d'une charge de travail distribuée.

  • Placer les nœuds à proximité physique à l'aide d'un emplacement compact : la distance physique entre les nœuds de votre charge de travail distribuée peut avoir un impact important sur la latence réseau entre les nœuds. Pour minimiser cette latence, utilisez une stratégie d'emplacement compact pour vos pools de nœuds GKE. Une règle de concentration demande à GKE de placer les nœuds d'un pool de nœuds le plus près possible les uns des autres dans une zone.

Déployer des charges de travail d'inférence dans plusieurs régions

Pour les applications distribuées à l'échelle mondiale qui nécessitent une haute disponibilité et une faible latence, il est essentiel de déployer vos charges de travail d'inférence dans plusieurs régions. Une architecture multirégion peut vous aider à améliorer la fiabilité et la disponibilité des accélérateurs, à réduire la latence perçue par les utilisateurs et à respecter les exigences réglementaires spécifiques à chaque emplacement.

Pour déployer et gérer efficacement un service d'inférence multirégional, suivez ces recommandations :

  • Provisionnez des clusters GKE dans plusieurs régions où vous avez réservé de la capacité ou prévoyez d'en avoir besoin pour gérer les pics de charge.
  • Choisissez la stratégie de stockage adaptée aux pondérations de votre modèle. Pour optimiser l'efficacité opérationnelle, créez un bucket Cloud Storage multirégional. Pour optimiser les coûts, créez un bucket régional dans chaque région et répliquez les poids de votre modèle.
  • Utilisez Anywhere Cache pour créer des caches de lecture zonaux pour vos buckets Cloud Storage afin de réduire à la fois la latence du réseau et les coûts de sortie des données.

Récapitulatif des bonnes pratiques

Le tableau suivant récapitule les bonnes pratiques recommandées dans ce document :

Sujet Tâche
Déploiement et configuration
  • Analyser les caractéristiques de votre cas d'utilisation pour l'inférence
  • Choisir les modèles adaptés à vos cas d'utilisation d'inférence
  • Appliquer la quantification au modèle
  • Choisir les bons accélérateurs
  • Choisir votre stratégie de distribution d'inférence
  • Optimiser la configuration de votre serveur d'inférence
Latence de démarrage à froid
  • Optimiser le temps de démarrage des pods
  • Activer les nœuds à démarrage rapide
Planification des capacités et disponibilité des accélérateurs
  •  Planifier et réserver la capacité
  •  Utiliser le planificateur de charges de travail dynamique
  •  Utiliser des classes de calcul personnalisées
  • Configurer la règle de localisation de vos clusters et pools de nœuds GKE
Efficacité des ressources et des accélérateurs
  • Observer vos accélérateurs et vos serveurs d'inférence
  • Faire évoluer automatiquement vos pods
  • Rapprochez les données de vos charges de travail
Équilibrage de charge
  • Utiliser la passerelle d'inférence GKE pour les déploiements à cluster unique
Déploiements multinœuds
  • Maximiser la bande passante et le débit du réseau d'accélérateurs
  • Utiliser LeaderWorkerSet pour regrouper les pods
  • Placer les nœuds à proximité physique à l'aide de l'emplacement compact
Déploiements multirégionaux
  •  Provisionner des clusters GKE dans plusieurs régions
  • Équilibrer la charge du trafic entre les régions
  • Stocker les pondérations du modèle dans des buckets Cloud Storage
  • Mettre en cache des données avec Anywhere Cache

Étapes suivantes