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/de ML sur Google Kubernetes Engine (GKE).

Cette page est destinée aux personas suivants :

  • 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 diffuser 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 le contenuGoogle Cloud , consultez Rôles utilisateur et tâches courantes de GKE.

Avant de lire cette page, assurez-vous de connaître les éléments suivants :

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

  • Choisissez Passerelle d'inférence GKE pour un routage et un équilibrage de charge optimisés pour le traitement des 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 des métriques spécifiques à vos exigences en termes d'application ou d'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 :

    • Utilisation du cache KV du serveur de modèle
    • Longueur de la file d'attente des demandes
    • Utilisation globale des GPU/TPU
    • Disponibilité des adaptateurs LoRA
    • Le coût de calcul des requêtes individuelles : en fonction de ces métriques, la passerelle distribue intelligemment le trafic vers la réplique de serveur de modèle la plus appropriée et la moins chargée.

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

  • Autoscaling optimisé : la passerelle propose 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 propose des ressources d'équilibreur de charge d'application compatibles avec des niveaux tels que "externe global" et "externe régional". Ces équilibreurs de charge à usage général distribuent le trafic en fonction de métriques personnalisées fournies par vos services de backend. Cette approche permet de contrôler précisément la répartition de la charge, ce qui vous permet de la baser sur des indicateurs de performances spécifiques aux applications.

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 métriques personnalisées (via les é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 diffusion de grands modèles de langage (LLM). Il garantit un accès équitable aux ressources du modèle et optimise les charges de travail LLM sensibles à la latence et basées sur des GPU ou des TPU. Fournit un équilibrage de charge HTTP(S) à usage général, qui distribue 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. Compatible avec le routage HTTP(S) standard basé sur l'hôte et le chemin d'accès. Pour ce faire, utilisez les ressources standards de l'API GKE Gateway.
Logique de routage avancée Fournit des fonctionnalités avancées telles que le routage tenant compte du modèle, la répartition et la mise en miroir du trafic, ainsi que 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'activer 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, les accès au cache KV et la longueur de la file d'attente des requêtes. Il peut également être configuré pour utiliser les 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 le signalement de charge Open Request Cost Aggregation (ORCA). 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 limitées spécifiques aux applications.
Gestion des requêtes Conçue pour gérer les charges de travail avec des coûts de requête non uniformes, qui sont courants dans les LLM en raison de la complexité variable des requêtes. Il est compatible avec les niveaux de criticité des requêtes, ce qui permet de hiérarchiser différents types de requêtes d'inférence. Convient mieux aux charges de travail où les coûts de traitement des requêtes individuelles sont relativement uniformes. Cette solution n'inclut pas de fonctionnalités de hiérarchisation des requêtes natives.
Compatibilité avec les adaptateurs LoRA Il offre un routage natif basé sur l'affinité vers les backends équipés d'adaptateurs LoRa spécifiques, ce qui garantit que les requêtes sont dirigées vers les ressources appropriées. Ne fournit pas de compatibilité native pour les adaptateurs LoRa ni pour le 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, pour prendre des décisions de scaling plus éclairées. Il 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-le 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 compatibles avec 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 les en-têtes HTTP, tel que l'agrégation du coût des requêtes ouvertes (ORCA), pour signaler les métriques personnalisées pour l'équilibrage de charge.
Sécurité Cette solution inclut le filtrage du contenu par IA à l'aide de Model Armor au niveau de la passerelle. Il s'appuie également sur les fonctionnalités de sécurité de base de GKE, 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 du contenu par 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 consulter dans Cloud Monitoring. Il peut s'agir de métriques standards ou personnalisées.
Extensibilité Basé sur une base Open Source extensible, ce qui permet un algorithme de sélection de points 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çu pour la flexibilité, il 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 DG DG

Quand utiliser la passerelle d'inférence GKE ?

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

  • Diffusion 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 comme vLLM.
  • Déployer des 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 corrects et disponibles.
  • Gérer les 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émenter la priorisation des requêtes : vous devez prioriser différentes classes de trafic d'inférence, telles que les requêtes critiques, standards ou délestables.
  • 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 (GenAI), telles que l'utilisation du cache KV, pour prendre des décisions de scaling plus éclairées.
  • Utiliser l'intégration Model Armor : vous devez utiliser Model Armor pour les vérifications de sécurité de l'IA au niveau de la passerelle.
  • Obtenir 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 hits du cache KV et la longueur de la file d'attente des requêtes.
  • Simplifier les 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 d'IA générative courants sur GKE, tout en conservant des options de personnalisation future grâce à sa base d'API GKE Gateway extensible.

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

Pour obtenir un équilibrage de charge flexible et à 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 de le faire dans les cas 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 reporting 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.
  • La cohérence avec les déploiements d'équilibreur de charge d'application existants est une priorité, et ces déploiements répondent aux exigences d'équilibrage de charge du service d'inférence.

Étapes suivantes