Choisir une stratégie d'équilibrage de charge pour l'inférence de modèles d'IA/ML sur GKE

Cette page vous aide à choisir la stratégie d'équilibrage de charge appropriée pour les charges de travail d'inférence de modèles d'IA/ML sur Google Kubernetes Engine (GKE).

Cette page est destinée aux personnes suivantes :

  • Ingénieurs en machine learning (ML), administrateurs et opérateurs de plate-forme, et spécialistes des données et de l'IA qui souhaitent utiliser les fonctionnalités d'orchestration de conteneurs Kubernetes pour mettre en service des charges de travail d'IA/ML.
  • Architectes cloud et spécialistes de la mise en réseau qui interagissent avec la mise en réseau Kubernetes.

Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans Google Cloud le contenu, consultez Rôles utilisateur et tâches courantes de GKE.

Avant de lire cette page, assurez-vous de bien comprendre les points suivants :

Lorsque vous déployez des charges de travail d'inférence de modèles d'IA/ML sur GKE, choisissez la bonne stratégie d'équilibrage de charge pour optimiser les performances, l'évolutivité et le rapport coût/efficacité :

  • Choisissez GKE Inference Gateway pour optimiser le routage et l'équilibrage de charge lors de la mise en service de charges de travail d'IA/ML.
  • Choisissez GKE Gateway avec des métriques personnalisées, qui utilise des équilibreurs de charge d'application. Cette option offre un contrôle à usage général et vous permet de configurer la distribution du trafic en fonction de métriques spécifiques aux exigences de votre application ou de votre infrastructure.

Présentation de GKE Inference Gateway

GKE Inference Gateway optimise et gère les charges de travail d'inférence exigeantes d'IA générative et de grands modèles de langage (LLM) complexes. Elle étend l'API GKE Gateway et offre plusieurs avantages clés :

  • Routage intelligent basé sur l'IA : GKE Inference Gateway surveille les métriques critiques spécifiques à l'IA, y compris les suivantes :

    • Utilisation du cache KV du serveur de modèles
    • Longueur de la file d'attente des requêtes en attente
    • Utilisation globale des GPU/TPU
    • Disponibilité des adaptateurs LoRa
    • Coût de calcul des requêtes individuelles En fonction de ces métriques, la passerelle distribue intelligemment le trafic vers le réplica de serveur de modèles le plus adapté et le moins chargé.

  • Priorisation des requêtes : la passerelle fournit des mécanismes pour prioriser les requêtes.

  • Autoscaling optimisé : la passerelle offre des mécanismes d'autoscaling optimisés pour les serveurs de modèles.

Présentation de GKE Gateway avec des métriques personnalisées

Google Cloud offre des ressources d'équilibreur de charge d'application compatibles avec des étendues telles que les étendues externes globales et externes régionales. Ces équilibreurs de charge à usage général distribuent le trafic en fonction des métriques personnalisées signalées par vos services de backend. Cette approche offre un contrôle précis sur la distribution de la charge, ce qui vous permet de la baser sur des indicateurs de performances spécifiques à l'application.

Comparer GKE Inference Gateway et GKE Gateway avec des métriques personnalisées

Utilisez le tableau suivant pour comparer les fonctionnalités de GKE Inference Gateway et de GKE Gateway avec des métriques personnalisées, et choisissez la solution d'équilibrage de charge adaptée à vos charges de travail d'inférence d'IA/ML sur GKE.

Fonctionnalité GKE Inference Gateway GKE Gateway avec des métriques personnalisées (via des équilibreurs de charge d'application)
Cas d'utilisation principal Optimise les charges de travail d'inférence d'IA générative et de machine learning sur Kubernetes, y compris la mise en service de grands modèles de langage (LLM). Elle permet de garantir un accès équitable aux ressources de modèles et d'optimiser les charges de travail de LLM basées sur des GPU ou des TPU sensibles à la latence. Fournit un équilibrage de charge HTTP(S) à usage général, distribuant le trafic en fonction de métriques personnalisées signalées par l'application. Cet équilibrage de charge est idéal pour les services sensibles à la latence, tels que les serveurs de jeux en temps réel ou les plates-formes de trading à haute fréquence, qui signalent des données d'utilisation personnalisées.
Routage de base Prend en charge le routage HTTP(S) standard basé sur l'hôte et le chemin d'accès, en étendant l'API GKE Gateway. Prend en charge le routage HTTP(S) standard basé sur l'hôte et le chemin d'accès. Vous configurez cela à l'aide des ressources standards de l'API GKE Gateway.
Logique de routage avancée Fournit des fonctionnalités avancées telles que le routage basé sur les modèles, la répartition du trafic la mise en miroir et l'application de niveaux de priorité et de criticité aux requêtes. Équilibre le trafic en fonction des métriques personnalisées signalées par l'application via la norme ORCA (Open Request Cost Aggregation). Cela permet d'appliquer des règles telles que WEIGHTED_ROUND_ROBIN pour la pondération des points de terminaison dans une localité.
Métriques acceptées Utilise une suite de métriques natives spécifiques à l'IA, telles que l'utilisation des GPU ou des TPU utilisation, les accès au cache KV et la longueur de la file d'attente des requêtes. Elle peut également être configurée pour utiliser des métriques signalées par l'application à l'aide d'un mécanisme d'en-tête HTTP standardisé. S'appuie sur les métriques signalées par l'application à l'aide d'un mécanisme d'en-tête HTTP standardisé, en particulier sur les rapports de charge ORCA (Open Request Cost Aggregation). Ce mécanisme est compatible avec les métriques standards telles que le processeur et la mémoire, ainsi qu'avec les métriques nommées personnalisées pour les ressources contraintes spécifiques à l'application.
Gestion des requêtes Conçue pour gérer les charges de travail dont les coûts de requête ne sont pas uniformes, ce qui est courant dans les LLM en raison de la complexité variable des requêtes. Elle prend en charge les niveaux de criticité des requêtes criticality levels, ce qui permet de prioriser différents types de requêtes d'inférence. Convient mieux aux charges de travail où les requêtes individuelles ont des coûts de traitement relativement uniformes. Cette solution n'inclut pas de fonctionnalités natives de priorisation des requêtes.
Compatibilité avec les adaptateurs LoRa Offre un routage natif basé sur l'affinité vers les backends équipés d'adaptateurs LoRa spécifiques, ce qui permet de s'assurer que les requêtes sont dirigées vers les ressources appropriées. Ne fournit pas de compatibilité native avec les adaptateurs LoRa ni de routage basé sur l'affinité en fonction des configurations LoRa.
Intégration de l'autoscaling Optimise l'autoscaling pour les serveurs de modèles en exploitant des métriques spécifiques à l'IA, telles que l'utilisation du cache KV, afin de prendre des décisions de scaling plus éclairées. S'intègre à l'autoscaler horizontal de pods (AHP) à l'aide de métriques personnalisées. Ces métriques sont signalées à l'équilibreur de charge d'application et sont utilisées de manière générique pour le scaling, en fonction des signaux de charge signalés.
Installation et configuration Configurez-la avec l'API GKE Gateway. Étend l'API standard avec des définitions de ressources personnalisées (CRD) InferencePool et InferenceModel spécialisées pour activer ses fonctionnalités basées sur l'IA. Vous configurez cette solution à l'aide des ressources standards de l' API GKE Gateway. L'application doit implémenter un mécanisme basé sur un en-tête HTTP, tel que ORCA (Open Request Cost Aggregation), pour signaler des métriques personnalisées pour l'équilibrage de charge.
Sécurité Cette solution inclut le filtrage de contenu basé sur l'IA à l'aide de Model Armor au niveau de la passerelle. Elle exploite également les fonctionnalités de sécurité GKE de base, telles que TLS, Identity and Access Management (IAM), le contrôle des accès basé sur les rôles (RBAC) et les espaces de noms. Cette solution utilise la pile de sécurité standard de l'équilibreur de charge d'application, qui inclut Google Cloud Armor, la terminaison TLS et IAM. Pour activer le filtrage de contenu basé sur l'IA, vous pouvez intégrer Google Cloud Armor en tant qu'extension de service.
Observabilité Offre une observabilité intégrée des métriques spécifiques à l'IA, y compris l'utilisation des GPU ou des TPU, les accès au cache KV, la longueur de la file d'attente des requêtes et la latence des modèles. L'observabilité repose sur toutes les métriques personnalisées que l'application est configurée pour signaler. Vous pouvez les afficher dans Cloud Monitoring. Il peut s'agir de métriques standards ou nommées personnalisées.
Extensibilité Basée sur une base extensible Open Source, ce qui permet d'utiliser un algorithme de sélection de point de terminaison géré par l'utilisateur. Elle étend l'API GKE Gateway avec des [définitions de ressources personnalisées (CRD)](/kubernetes-engine/docs/how-to/deploy-gke-inference-gateway) spécialisées, telles que InferencePool et InferenceModel, pour simplifier les cas d'utilisation courants de l'IA. Conçue pour être flexible, ce qui vous permet d'étendre l'équilibrage de charge à l'aide de n'importe quelle [métrique personnalisée (signal de charge)](/load-balancing/docs/https/applb-custom-metrics) que l'application signale à l'aide de la norme ORCA.
Étape de lancement GA GA

Quand utiliser GKE Inference Gateway ?

Choisissez GKE Inference Gateway pour optimiser les charges de travail d'inférence sophistiquées d'IA et de machine learning sur GKE, en particulier pour les grands modèles de langage (LLM). Nous vous recommandons cette solution dans les situations suivantes :

  • Mise en service de LLM : vous avez besoin de décisions de routage basées sur des états spécifiques aux LLM, tels que l'utilisation du cache KV ou la longueur de la file d'attente des requêtes, lorsque vous utilisez des serveurs de modèles tels que vLLM.
  • Déploiement de modèles avec des adaptateurs LoRa : vous avez besoin d'un routage intelligent basé sur l'affinité vers les backends équipés des adaptateurs LoRa appropriés et disponibles.
  • Gestion des requêtes d'inférence avec des coûts de traitement très variables : par exemple, les tailles ou la complexité dynamiques des requêtes nécessitent un équilibreur de charge tenant compte des coûts.
  • Implémentation de la priorisation des requêtes : vous devez prioriser différentes classes de trafic d'inférence, telles que les requêtes critiques, standards ou supprimables.
  • Optimisation de l'autoscaling : vous souhaitez un mécanisme d'autoscaling étroitement lié à des métriques de performances spécifiques des serveurs de modèles d'IA générative, telles que l'utilisation du cache KV, pour prendre des décisions de scaling plus éclairées.
  • Utilisation de l'intégration de Model Armor : vous devez utiliser Model Armor pour les vérifications de sécurité de l'IA au niveau de la passerelle.
  • Obtention d'une observabilité prête à l'emploi : vous avez besoin d'une observabilité intégrée pour les métriques critiques spécifiques à l'IA, y compris l'utilisation des GPU ou des TPU, les accès au cache KV et la longueur de la file d'attente des requêtes.
  • Simplification des déploiements d'IA générative : vous préférez une solution spécialement conçue qui simplifie les modèles de déploiement courants d'IA générative sur GKE, tout en conservant des options de personnalisation ultérieure grâce à sa base extensible d'API GKE Gateway.

Quand utiliser GKE Gateway avec des métriques personnalisées ?

Pour obtenir un équilibrage de charge flexible à usage général basé sur les indicateurs de performances uniques de votre application, utilisez GKE Gateway avec des métriques personnalisées. Cette approche permet de distribuer la charge en fonction d'indicateurs de performances uniques définis par l'application, y compris des scénarios d'inférence spécifiques. Nous vous recommandons cette approche dans les scénarios suivants :

  • Votre charge de travail présente un volume de trafic élevé avec des coûts de traitement relativement uniformes par requête.
  • La distribution de la charge peut être gérée efficacement par une ou deux métriques personnalisées spécifiques signalées par l'application, généralement via des en-têtes de réponse HTTP à l'aide de la norme de rapport de charge ORCA (Open Request Cost Aggregation).
  • Vos exigences en matière d'équilibrage de charge ne dépendent pas des fonctionnalités spécifiques à l'IA générative ou aux LLM.
  • Votre modèle opérationnel ne nécessite pas l'intelligence spécialisée spécifique à l'IA fournie par GKE Inference Gateway, ce qui évite une complexité architecturale inutile.
  • Le maintien de la cohérence avec les déploiements existants d'équilibreur de charge d'application est une priorité, et ces déploiements répondent aux exigences d'équilibrage de charge du service d'inférence.

Étape suivante