Ce guide des bonnes pratiques présente les métriques disponibles et explique comment sélectionner des métriques appropriées pour configurer votre autoscaler horizontal de pods (Horizontal Pod Autoscaler, HPA) pour vos charges de travail d'inférence sur GKE. L'autoscaler horizontal de pods est un moyen efficace de vous assurer que vos serveurs de modèles évoluent de manière appropriée en fonction de la charge. L'ajustement des paramètres HPA est le principal moyen d'aligner le coût de votre matériel provisionné sur la demande de trafic afin d'atteindre les objectifs de performances de votre serveur d'inférence.
Pour obtenir des exemples de mise en œuvre de ces bonnes pratiques, consultez la page Configurer l'autoscaling pour les charges de travail LLM sur les GPU avec GKE.
Objectifs
Ce guide est destiné aux clients d'IA générative, aux utilisateurs GKE nouveaux ou existants, aux ingénieurs en ML et aux ingénieurs LLMOps (DevOps) qui souhaitent optimiser leurs charges de travail LLM à l'aide de GPU avec Kubernetes.
Après avoir lu ce guide, vous devriez être capable de :
- Comprendre les métriques d'autoscaling pour l'inférence LLM.
- Comprendre les principaux compromis au niveau des métriques à utiliser pour l'autoscaling.
Présentation des métriques d'autoscaling pour l'inférence LLM
Les métriques suivantes sont disponibles dans GKE:
Métriques de serveur
Les serveurs d'inférence LLM courants tels que TGI, vLLM et NVIDIA Triton émettent des métriques de performances spécifiques aux charges de travail. GKE simplifie le scraping et l'autoscaling des charges de travail en fonction de ces métriques au niveau du serveur. Vous pouvez utiliser ces métriques pour plus de visibilité sur les indicateurs de performance, tels que la taille des lots, la taille de la file d'attente et les latences de décodage.
En fonction de ces métriques, vous pouvez diriger l'autoscaling sur les indicateurs de performances les plus pertinents. Les principales métriques au niveau du serveur pour l'autoscaling sont les suivantes:
- Taille de la file d'attente:nombre de requêtes en attente de traitement dans la file d'attente du serveur. Utilisez la taille de la file d'attente pour optimiser le débit et réduire les coûts tout en respectant un certain seuil de latence cible. Pour en savoir plus, consultez la section Bonnes pratiques associées.
- Taille de lot:nombre de requêtes en cours d'inférence. Utilisez la taille de lot pour atteindre des seuils de latence cible inférieurs à la taille de la file d'attente. Pour en savoir plus, consultez la section Bonnes pratiques associées.
Ces métriques sont souvent résilientes aux performances et aux fluctuations de trafic, ce qui en fait un point de départ fiable pour l'autoscaling sur diverses configurations matérielles de GPU.
Métriques concernant les GPU
Les GPU émettent diverses métriques d'utilisation et de performances, offrant ainsi un autoscaling indépendant des charges de travail pour toutes les tâches basées sur les GPU, y compris l'inférence de charges de travail dépourvues de métriques personnalisées. Pour savoir comment configurer la collecte DCGM, consultez la section Configurer la collecte DCGM.
Les métriques GPU courantes pour GKE incluent:
| Métrique GPU | Utilisation | Limites |
|---|---|---|
Utilisation du GPU (DCGM_FI_DEV_GPU_UTIL) |
Mesure le cycle de travail, qui correspond à la durée d'activité du GPU. | Ne mesure pas le volume de travail effectué lorsque le GPU est actif. Il est donc difficile de mapper les métriques de performances basées sur l'inférence, telles que la latence et le débit, à un seuil d'utilisation du GPU. |
Utilisation de la mémoire du GPU (DCGM_FI_DEV_FB_USED) |
Mesure la quantité de mémoire GPU utilisée à un moment donné. Cela est utile pour les charges de travail qui mettent en œuvre l'allocation dynamique de la mémoire du GPU. | Pour les charges de travail qui préallouent de la mémoire GPU ou ne désallouent jamais de mémoire (telles que les charges de travail s'exécutant sur TGI et vLLM), cette métrique ne fonctionne que pour le scaling à la hausse et n'effectue pas de scaling à la baisse lorsque le trafic diminue. |
Métriques concernant les processeurs
Dans GKE, l'HPA fonctionne directement avec l'autoscaling basé sur le processeur et la mémoire. Pour les charges de travail exécutées sur des processeurs, les métriques d'utilisation du processeur et de la mémoire sont généralement la principale métrique d'autoscaling.
Pour les charges de travail d'inférence exécutées sur des GPU, nous ne recommandons pas l'utilisation du processeur et de la mémoire comme seuls indicateurs de la quantité de ressources consommées par une tâche, car l'inférence de charges de travail repose principalement sur des ressources GPU. Par conséquent, utiliser uniquement des métriques de processeur pour l'autoscaling peut entraîner des performances et des coûts non optimaux.
Éléments à prendre en compte pour choisir des métriques d'autoscaling
Tenez compte des considérations et des bonnes pratiques suivantes afin de sélectionner la meilleure métrique pour l'autoscaling sur GKE afin d'atteindre les objectifs de performances de votre charge de travail d'inférence.
Bonne pratique: Utilisez la taille de la file d'attente pour optimiser le débit et réduire les coûts en respectant un certain seuil de latence cible
Nous vous recommandons d'effectuer l'autoscaling de la taille de la file d'attente lors de l'optimisation du débit et des coûts, et lorsque vos objectifs de latence sont réalisables avec le débit maximal de la taille de lot maximale de votre serveur de modèles.
La taille de la file d'attente est directement liée à la latence des requêtes. Les requêtes entrantes sont placées en file d'attente sur le serveur de modèles avant d'être traitées, ce qui s'ajoute à la latence globale. La taille de la file d'attente est un indicateur sensible des pics de charge, car une charge accrue remplit rapidement la file d'attente.
L'autoscaling basé sur la taille de la file d'attente réduit la durée en procédant à un scaling à la hausse en cas de charge ou à un scaling à la baisse lorsque la file d'attente est vide. Cette approche est relativement facile à mettre en œuvre et ne dépend pas de la charge de travail, car la taille de la file d'attente est indépendante de la taille de la requête, du modèle et du matériel.
Envisagez de vous concentrer sur la taille de la file d'attente si vous souhaitez optimiser le débit tout en respectant la configuration de votre serveur de modèles. La taille de la file d'attente permet de suivre les requêtes en attente, et non de les traiter. vLLM et TGI utilisent un traitement par lot continu, qui maximise les requêtes simultanées et maintient la file d'attente faible lorsque l'espace par lot est disponible. La file d'attente augmente considérablement lorsque l'espace par lot est limité. Utilisez donc le point de croissance comme signal pour lancer le scaling à la hausse. En combinant l'autoscaling de la taille de la file d'attente avec un débit par lot optimisé, vous pouvez optimiser le débit des requêtes.
Déterminer la valeur de seuil optimale de la taille de file d'attente optimale pour l'HPA
Tenez compte de la tolérance HPA, qui est définie par défaut sur une plage d'absence d'action de 0,1 autour de la valeur cible afin d'atténuer l'oscillation.
Pour choisir le seuil de taille de file d'attente approprié, commencez par une valeur comprise entre 3 et 5 et augmentez progressivement jusqu'à ce que les requêtes atteignent la latence souhaitée. Utilisez l'outil locust-load-inference pour les tests. Pour les seuils inférieurs à 10, ajustez les paramètres de scaling à la hausse de l'autoscaler horizontal de pods afin de gérer les pics de trafic.
Vous pouvez également créer un tableau de bord personnalisé Cloud Monitoring pour visualiser le comportement des métriques.
Limites
La taille de la file d'attente ne contrôle pas directement les requêtes simultanées. Par conséquent, son seuil ne peut pas garantir une latence inférieure à celle autorisée par la taille de lot maximale. Pour contourner ce problème, vous pouvez réduire manuellement la taille maximale de lot ou effectuer un autoscaling sur la taille de lot.
Bonne pratique: Utiliser la taille de lot pour atteindre des seuils de latence cible inférieurs à la taille de la file d'attente
Nous vous recommandons de choisir l'autoscaling basé sur la taille des lots si vous avez des charges de travail sensibles à la latence où le scaling basé sur la file d'attente n'est pas assez rapide pour répondre à vos besoins.
La taille de lot est directement liée au débit et à la latence d'une requête entrante. La taille de lot est un bon indicateur des pics de charge, car une augmentation de la charge entraîne l'ajout de requêtes au lot existant, ce qui entraîne une taille de lot plus importante. En général, plus la taille de lot est élevée, plus la latence est élevée. L'autoscaling sur la taille de lot garantit que votre charge de travail évolue pour maximiser le nombre de requêtes traitées en parallèle en même temps, et évolue à la baisse lorsque moins de requêtes sont traitées en parallèle.
Si la taille de la file d'attente atteint déjà vos objectifs de latence, donnez-lui la priorité pour l'autoscaling. Cela permet d'optimiser le débit et la rentabilité. Cependant, la taille de lot est utile pour les charges de travail sensibles à la latence. Des tailles de lot plus importantes augmentent le débit, mais augmentent également la latence en raison de la phase de préremplissage de certaines requêtes interrompant la phase de décodage d'autres sur les serveurs de modèles avec traitement par lot continu. Vous pouvez surveiller les modèles de taille de lot et utiliser l'autoscaling pour minimiser les requêtes simultanées lors des pics de charge.
Si votre serveur de modèles le permet, nous vous recommandons de personnaliser la taille maximale de lot afin de bénéficier d'un mécanisme de réglage supplémentaire. Vous pouvez également associer ce mode à l'autoscaling basé sur la file d'attente.
Déterminer la valeur de seuil optimale de taille de lot pour l'HPA
Tenez compte de la tolérance HPA, qui est une plage sans action par défaut de 0,1 autour de la valeur cible afin d'atténuer l'oscillation.
Pour choisir le seuil approprié pour la taille de lot, augmentez de manière expérimentale la charge sur votre serveur et observez où la taille de lot augmente. Nous vous recommandons également d'utiliser l'outil locust-load-inference pour les tests. Une fois que vous avez identifié la taille maximale de lot, définissez la valeur cible initiale légèrement en dessous de cette valeur maximale et diminuez-la jusqu'à atteindre la latence souhaitée.
Vous pouvez également créer un tableau de bord personnalisé Cloud Monitoring pour visualiser le comportement des métriques.
Limites
L'autoscaling sur la taille de lot, tout en étant utile pour le contrôle de la latence, présente des limites. L'évolution de la taille des requêtes et des contraintes matérielles rend difficile la recherche du bon seuil pour la taille de lot.
Bonne pratique: optimiser votre configuration HPA
Nous vous recommandons de définir les options de configuration HPA suivantes:
- Intervalle de stabilisation: utilisez cette option de configuration HPA pour éviter les modifications rapides du nombre d'instances dupliquées en raison des fluctuations des métriques. Les valeurs par défaut sont de 5 minutes pour le scaling à la baisse (éviter un scaling à la baisse prématuré) et de 0 pour le scaling à la hausse (garantir la réactivité). Ajustez la valeur en fonction de la volatilité de votre charge de travail et de votre réactivité préférée.
- Règles de scaling: utilisez cette option de configuration de l'autoscaler horizontal de pods pour affiner le comportement du scaling à la hausse et à la baisse. Vous pouvez définir la limite de la règle "Pods" pour spécifier le nombre absolu d'instances dupliquées modifiées par unité de temps, et la limite de la règle "Pourcentage" pour spécifier le pourcentage de variation.
Pour en savoir plus sur ces options, consultez la page Autoscaling horizontal des pods dans la documentation Open Source Kubernetes.
Étape suivante
- Découvrez comment configurer l'autoscaling pour les charges de travail LLM sur les GPU.