Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Observabilité
Astuce
Découvrez les
Surveillance et observabilité
Explication des métriques du GPU
La métrique d'utilisation du GPU indique si le GPU a exécuté du travail pendant la fenêtre d'exemple. Cette métrique capture le pourcentage de temps pendant lequel le GPU a exécuté au moins une instruction, mais elle ne révèle pas l'efficacité avec laquelle le GPU a utilisé son matériel. Un GPU contient plusieurs multiprocesseurs de streaming (SMs), qui sont des unités de traitement parallèle qui exécutent les instructions. Un taux d'utilisation de 100 % peut signifier que le GPU a exécuté de lourdes charges de travail parallèles sur tous ses SMs composants, ou cela peut signifier qu'une seule petite instruction a activé le GPU au cours de la période d'échantillonnage. Pour comprendre l'utilisation réelle, vous devez examiner les métriques du GPU à plusieurs niveaux de l'architecture matérielle. Chaque multiprocesseur de streaming est construit à partir de différents types de cœurs, et chaque couche présente des caractéristiques de performance différentes. Des indicateurs de haut niveau (utilisation du processeur graphique, utilisation de la mémoire, puissance du processeur graphique et température du processeur, visibles via nvidia-smi) indiquent si l'appareil est actif. Des indicateurs plus approfondis (utilisation du SM, activité du SM et utilisation du noyau tensoriel) révèlent l'efficacité avec laquelle le GPU utilise ses ressources.
Ciblez une consommation d'énergie élevée du GPU
La sous-utilisation GPUs gaspille la capacité de calcul et augmente les coûts car les charges de travail n'impliquent pas tous les composants du GPU simultanément. Pour les AI/ML charges de travail sur Amazon EKS, suivez la consommation d'énergie du GPU en tant que proxy afin d'identifier l'activité réelle du GPU. L'utilisation du GPU indique le pourcentage de temps pendant lequel le GPU exécute un noyau, mais ne révèle pas si les multiprocesseurs de streaming, les contrôleurs de mémoire et les cœurs tensoriels sont tous actifs en même temps. La consommation d'énergie met en évidence cet écart, car le matériel entièrement engagé consomme beaucoup plus d'énergie que le matériel utilisant des noyaux légers ou restant inactif entre les tâches. Comparez la consommation d'énergie à la puissance thermique nominale (TDP) du GPU pour détecter la sous-utilisation, puis déterminez si votre charge de travail est entravée par le prétraitement du processeur, les E/S réseau ou des tailles de lots inefficaces.
CloudWatch Configurez Container Insights sur Amazon EKS pour identifier les pods, les nœuds ou les charges de travail consommant peu d'énergie du processeur graphique. Cet outil s'intègre directement à Amazon EKS et vous permet de surveiller la consommation d'énergie du GPU et d'ajuster la planification des pods ou les types d'instances lorsque la consommation d'énergie tombe en dessous de vos niveaux cibles. Si vous avez besoin d'une visualisation avancée ou de tableaux de bord personnalisés, utilisez DCGM-Exporter de NVIDIA avec Prometheus et Grafana pour une surveillance native de Kubernetes. Les deux approches mettent en évidence des indicateurs clés de NVIDIA tels que nvidia_smi_power_draw (consommation d'énergie du GPU) et nvidia_smi_temperature_gpu (température du GPU). Pour obtenir la liste des métriques, explorez https://docs.aws.amazon.com/AmazonCloudWatch/ latest/monitoring/CloudWatch -Agent-NVIDIA-GPU.htm. Recherchez des modèles tels qu'une faible consommation d'énergie constante pendant des heures spécifiques ou pour des tâches particulières. Ces tendances vous aident à identifier les domaines dans lesquels consolider les charges de travail ou ajuster l'allocation des ressources.
Les limites de ressources statiques dans Kubernetes (telles que le nombre de processeurs, de mémoire et de GPU) entraînent souvent un provisionnement excessif ou une sous-utilisation, en particulier pour les charges de AI/ML travail dynamiques telles que l'inférence lorsque la demande fluctue. Analysez vos tendances d'utilisation et consolidez vos charges de travail en réduisant le nombre de vos charges de GPUs travail. Assurez-vous que chaque GPU est pleinement utilisé avant d'en allouer d'autres. Cette approche permet de réduire le gaspillage et les coûts. Pour obtenir des conseils détaillés sur l'optimisation des stratégies de planification et de partage, consultez les meilleures pratiques d'EKS en matière de calcul et d'autoscaling
Observabilité et métriques
Utilisation d'outils de surveillance et d'observabilité pour vos charges de travail AI/ML
Les AI/ML services modernes nécessitent une coordination entre l'infrastructure, la modélisation et la logique des applications. Les ingénieurs de plateforme gèrent l'infrastructure et le stack d'observabilité. Ils collectent, stockent et visualisent les métriques. AI/ML les ingénieurs définissent des métriques spécifiques au modèle et surveillent les performances sous différentes charges et distributions de données. Les développeurs d'applications consomment APIs, acheminent les demandes et suivent les indicateurs de niveau de service et les interactions des utilisateurs. Sans pratiques d'observabilité unifiées, ces équipes travaillent en silos et passent à côté de signaux critiques concernant l'état et les performances du système. L'établissement d'une visibilité partagée entre les environnements permet à toutes les parties prenantes de détecter les problèmes à un stade précoce et de maintenir un service fiable.
L'optimisation des clusters Amazon EKS pour les AI/ML charges de travail présente des défis de surveillance uniques, notamment en ce qui concerne la gestion de la mémoire du GPU. Sans surveillance adéquate, les entreprises sont confrontées à des erreurs out-of-memory (OOM), à une inefficacité des ressources et à des coûts inutiles. Une surveillance efficace garantit de meilleures performances, une meilleure résilience et une réduction des coûts pour les clients d'EKS. Utilisez une approche holistique qui combine trois niveaux de surveillance. Tout d'abord, surveillez les métriques granulaires du GPU à l'aide de NVIDIA DCGM Exporter
Outils et cadres
Plusieurs outils et frameworks fournissent des out-of-the-box métriques natives pour surveiller les AI/ML charges de travail. Ces métriques intégrées éliminent le besoin d'une instrumentation personnalisée et réduisent le temps de configuration. Les métriques se concentrent sur les aspects de performance tels que la latence, le débit et la génération de jetons, qui sont essentiels pour le service d'inférence et l'analyse comparative. L'utilisation de métriques natives vous permet de commencer à surveiller immédiatement sans créer de pipelines de collecte personnalisés.
-
vLLM : moteur de service à haut débit pour les grands modèles linguistiques (LLMs) qui fournit des mesures natives telles que la latence des demandes et l'utilisation de la mémoire.
-
Ray : infrastructure informatique distribuée qui émet des mesures pour les charges de travail évolutives de l'IA, notamment les temps d'exécution des tâches et l'utilisation des ressources.
-
Hugging Face Text Generation Inference (TGI) : une boîte à outils pour le déploiement et le LLMs service, avec des métriques intégrées pour les performances d'inférence.
-
NVIDIA genai-perf : outil en ligne de commande permettant d'évaluer les modèles d'IA génératifs, de mesurer le débit, la latence et les indicateurs spécifiques au LLM, tels que les demandes traitées à des intervalles de temps spécifiques.
Méthodes d'observabilité
Nous recommandons de mettre en œuvre tout mécanisme d'observabilité supplémentaire de l'une des manières suivantes.
CloudWatch Container Insights Si votre entreprise préfère les outils natifs d'AWS avec une configuration minimale, nous recommandons CloudWatch Container Insights. Il s'intègre à l'exportateur NVIDIA DCGM
Après avoir installé Container Insights, il détecte CloudWatch automatiquement NVIDIA GPUs dans votre environnement et collecte des indicateurs de santé et de performance critiques. Ces statistiques apparaissent sur des out-of-the-box tableaux de bord sélectionnés. Vous pouvez également intégrer Ray
Pour obtenir la liste complète des métriques disponibles, consultez les métriques Amazon EKS et Kubernetes Container Insights. Pour step-by-step obtenir des conseils sur la mise en œuvre de la surveillance du GPU, reportez-vous à la section Obtenir des informations opérationnelles pour les charges de travail des GPU NVIDIA à l'aide d'Amazon CloudWatch Container Insights
Prometheus et Grafana gérés Si votre entreprise a besoin de tableaux de bord personnalisés et de fonctionnalités de visualisation avancées, déployez Prometheus avec le NVIDIA DCGM-Exporter et Grafana pour la surveillance native de Kubernetes.
Vous pouvez étendre cette pile de surveillance en intégrant des frameworks open source tels que Ray et VLLM Ray et VLLM
Pour step-by-step obtenir des conseils sur le déploiement de cette pile de surveillance, reportez-vous à la section Surveillance des charges de travail du GPU sur Amazon EKS à l'aide des services open source gérés par AWS
Envisagez de surveiller la formation de base et de peaufiner les indicateurs
Surveillez les indicateurs d'entraînement de base pour suivre l'état et les performances de votre cluster Amazon EKS ainsi que les charges de travail d'apprentissage automatique qui y sont exécutées. Les charges de travail de formation ont des exigences de surveillance différentes de celles des charges de travail d'inférence, car elles s'exécutent sur de longues périodes, consomment les ressources différemment et nécessitent une visibilité sur la convergence des modèles et l'efficacité du pipeline de données. Les indicateurs ci-dessous vous aident à identifier les goulets d'étranglement, à optimiser l'allocation des ressources et à garantir le succès des tâches de formation. Pour step-by-step obtenir des conseils sur la mise en œuvre de cette approche de surveillance, reportez-vous à la section Introduction à l'observation des charges de travail d'apprentissage automatique sur Amazon EKS
Mesures d'utilisation des ressources
Surveillez les indicateurs d'utilisation des ressources pour vérifier que vos ressources sont correctement consommées. Ces indicateurs vous aident à identifier les goulets d'étranglement et les causes profondes des problèmes de performance.
-
Processeur, mémoire, réseau, puissance du processeur graphique et température du processeur graphique : surveillez ces indicateurs pour vous assurer que les ressources allouées répondent aux demandes de charge de travail et identifier les opportunités d'optimisation. Suivez des indicateurs tels que gpu_memory_usage_bytes pour identifier les modèles de consommation de mémoire et détecter les pics d'utilisation. Calculez des percentiles tels que le 95e percentile (P95) pour comprendre les exigences de mémoire les plus élevées pendant l'entraînement. Cette analyse vous aide à optimiser les modèles et l'infrastructure afin d'éviter les erreurs OOM et de réduire les coûts.
-
Occupation du SM, FPxx activité du SM, activité : surveillez ces métriques pour comprendre comment la ressource sous-jacente du GPU est utilisée. Objectif 0,8 pour l'activité SM en règle générale
. -
Utilisation des ressources des nœuds et des pods : suivez l'utilisation des ressources au niveau du nœud et du pod afin d'identifier les problèmes de contention des ressources et les goulots d'étranglement potentiels. Vérifiez si les nœuds approchent des limites de capacité, ce qui peut retarder la planification des modules et ralentir les tâches de formation.
-
Utilisation des ressources par rapport aux demandes et aux limites : comparez l'utilisation réelle des ressources aux demandes et limites configurées afin de déterminer si votre cluster peut gérer les charges de travail actuelles et les charges de travail futures. Cette comparaison indique si vous devez ajuster les allocations de ressources pour éviter les erreurs OOM ou le gaspillage de ressources.
-
Métriques internes à partir de frameworks ML - Capturez les métriques de formation et de convergence internes à partir de frameworks de ML tels que TensorFlow et PyTorch. Ces indicateurs incluent les courbes de perte, le taux d'apprentissage, le temps de traitement par lots et la durée des étapes de formation. Visualisez ces indicateurs à l'aide d'outils TensorBoard ou similaires pour suivre la convergence des modèles et identifier les inefficiences en matière de formation.
Mesures de performance du modèle
Surveillez les indicateurs de performance des modèles pour vérifier que votre processus de formation produit des modèles qui répondent aux exigences de précision et de gestion. Ces indicateurs vous aident à déterminer quand arrêter l'entraînement, à comparer les versions des modèles et à identifier la dégradation des performances.
-
Exactitude, précision, rappel et score F1 : suivez ces indicateurs pour comprendre les performances de votre modèle sur les données de validation. Calculez le score F1 sur un ensemble de validation après chaque période d'entraînement pour évaluer si le modèle s'améliore et quand il atteint des niveaux de performance acceptables.
-
Mesures spécifiques à l'entreprise et KPIs — Définissez et suivez les mesures qui mesurent directement la valeur commerciale de vos AI/ML initiatives. Pour un système de recommandation, suivez des indicateurs tels que le taux de clics ou le taux de conversion pour vous assurer que le modèle génère les résultats commerciaux escomptés.
-
Performances au fil du temps : comparez les indicateurs de performance entre les versions des modèles et les cycles d'entraînement pour identifier les tendances et détecter les dégradations. Vérifiez si les nouvelles versions des modèles maintiennent ou améliorent les performances par rapport aux modèles de base. Cette comparaison historique vous permet de décider s'il convient de déployer de nouveaux modèles ou d'étudier les problèmes de formation.
Qualité des données et mesures de dérive
Surveillez la qualité des données et les mesures de dérive pour vous assurer que vos données d'entraînement restent cohérentes et représentatives. La dérive des données peut entraîner une dégradation des performances des modèles au fil du temps, tandis que les problèmes de qualité des données peuvent empêcher les modèles de converger ou produire des résultats peu fiables.
-
Propriétés statistiques des données d'entrée : suivez les propriétés statistiques telles que la moyenne, l'écart type et la distribution des entités en entrée dans le temps afin de détecter les dérives ou les anomalies des données. Vérifiez si la distribution des fonctionnalités change de manière significative par rapport à vos données d'entraînement de base. Par exemple, si la moyenne d'une caractéristique critique change de plus de deux écarts types, déterminez si votre pipeline de données a changé ou si la source de données sous-jacente a changé.
-
Détection de la dérive des données et alertes — Mettez en œuvre des mécanismes automatisés pour détecter les problèmes de qualité des données et les signaler avant qu'ils n'aient une incidence sur la formation. Utilisez des tests statistiques tels que le test de Kolmogorov-Smirnov ou le test du Khi carré pour comparer les distributions de données actuelles avec vos données d'entraînement d'origine. Configurez des alertes lorsque les tests détectent une dérive significative afin de réentraîner les modèles avec des données mises à jour ou d'étudier les problèmes liés au pipeline de données.
Mesures de latence et de débit
Surveillez les indicateurs de latence et de débit pour identifier les goulots d'étranglement dans votre pipeline de formation et optimiser l'utilisation des ressources. Ces indicateurs vous aident à comprendre où le temps est consacré pendant la formation et sur quoi concentrer les efforts d'optimisation.
-
End-to-End Latence des pipelines de formation ML : mesurez le temps total pendant lequel les données circulent dans l'ensemble de votre pipeline de formation, de l'ingestion des données à la mise à jour du modèle. Suivez cette métrique d'un cycle d'entraînement à l'autre pour déterminer si les modifications apportées au pipeline améliorent ou dégradent les performances. Une latence élevée indique souvent des goulots d'étranglement dans le chargement des données, le prétraitement ou la communication réseau entre les nœuds.
-
Débit de formation et taux de traitement : suivez le volume de données que votre pipeline de formation traite par unité de temps afin de garantir une utilisation efficace des ressources. Surveillez les indicateurs tels que les échantillons traités par seconde ou les lots terminés par minute. Un faible débit par rapport à la capacité de votre matériel indique que le chargement des données, le prétraitement ou le calcul des modèles sont inefficaces et gâchent les cycles du GPU.
-
Latence de sauvegarde et de restauration des points de contrôle : surveillez le temps nécessaire pour enregistrer les points de contrôle du modèle dans le stockage (S3, EFS FSx) et restaurez-les dans la mémoire du GPU ou du processeur lors de la reprise des tâches ou de la reprise après une panne. Les opérations lentes aux points de contrôle prolongent le temps de reprise des tâches et augmentent les coûts. Suivez la taille du point de contrôle, la durée des sauvegardes, la durée de restauration et le nombre d'échecs afin d'identifier les opportunités d'optimisation telles que la compression ou l'accélération des niveaux de stockage.
-
Temps de chargement et de prétraitement des données : mesurez le temps passé à charger les données depuis le stockage et à appliquer des transformations de prétraitement. Comparez ce temps au temps de calcul du modèle pour déterminer si votre entraînement est lié aux données ou au calcul. Si le chargement des données occupe plus de 20 % du temps total de formation, envisagez d'optimiser votre pipeline de données avec la mise en cache, le préchargement ou un stockage plus rapide.
Taux d'erreur et défaillances
Surveillez les taux d'erreur et les défaillances tout au long de votre pipeline de formation afin de maintenir la fiabilité et d'éviter le gaspillage de ressources informatiques. Les erreurs non détectées peuvent entraîner l'échec silencieux des tâches d'entraînement, produire des modèles non valides ou faire perdre des heures de temps au GPU avant que vous ne remarquiez de problèmes.
-
Surveillance des erreurs de pipeline — Suivez les erreurs à toutes les étapes de votre pipeline de ML, y compris le prétraitement des données, la formation des modèles et les opérations aux points de contrôle. Enregistrez les types d'erreurs, les fréquences et les composants concernés pour identifier rapidement les problèmes. Les erreurs courantes incluent les incohérences entre les formats de données, out-of-memory les échecs lors du prétraitement et les échecs de sauvegarde des points de contrôle dus aux limites de stockage. Configurez des alertes lorsque les taux d'erreur dépassent les seuils de référence afin de pouvoir enquêter avant que les erreurs ne se répercutent en cascade.
-
Analyse des erreurs récurrentes — Identifiez et étudiez les modèles d'erreurs récurrentes afin de prévenir les défaillances futures et d'améliorer la fiabilité du pipeline. Analysez les journaux pour déterminer si des échantillons de données, des tailles de lots ou des configurations de formation spécifiques sont systématiquement à l'origine de défaillances. Par exemple, si certains types de données d'entrée déclenchent des erreurs de prétraitement, ajoutez des contrôles de validation plus tôt dans le pipeline ou mettez à jour votre logique de nettoyage des données. Suivez le temps moyen entre les défaillances (MTBF) pour déterminer si la fiabilité de votre pipeline s'améliore au fil du temps. »
Métriques spécifiques à Kubernetes et EKS
Surveillez les indicateurs Kubernetes et EKS pour vous assurer que votre infrastructure de cluster reste saine et qu'elle peut prendre en charge vos charges de travail de formation. Ces indicateurs vous aident à détecter les problèmes d'infrastructure avant qu'ils n'entraînent des échecs de formation ou une dégradation des performances.
-
Mesures de l'état du cluster Kubernetes : surveillez l'état et l'état des objets Kubernetes, notamment les pods, les nœuds, les déploiements et les services. Suivez l'état des pods pour identifier les pods bloqués dans des états de boucle en attente, en panne ou en panne. Surveillez l'état des nœuds pour détecter les problèmes tels que la pression du disque, la pression de la mémoire ou l'indisponibilité du réseau. Utilisez kubectl ou des outils de surveillance pour vérifier ces indicateurs en permanence et configurer des alertes lorsque les pods ne démarrent pas ou que les nœuds deviennent impossibles à planifier.
-
Mesures d'exécution du pipeline de formation — Suivez les cycles réussis et échoués du pipeline, la durée des tâches, le temps d'achèvement des étapes et les erreurs d'orchestration. Vérifiez si les tâches de formation sont achevées dans les délais prévus et si les taux d'échec augmentent au fil du temps. Suivez des indicateurs tels que le taux de réussite, la durée moyenne des tâches et le délai avant l'échec. Ces indicateurs vous aident à déterminer si des problèmes d'infrastructure, de configuration ou de qualité des données sont à l'origine d'échecs de formation.
-
Mesures des services AWS : suivez les métriques des services AWS qui prennent en charge votre infrastructure EKS et vos charges de travail de formation. Surveillez les métriques S3 telles que la latence des demandes, les taux d'erreur et le débit pour garantir la cohérence des performances de chargement des données. Suivez les indicateurs de volume EBS, notamment les IOPS, le débit et la longueur des files d'attente, afin de détecter les goulots d'étranglement liés au stockage. Surveillez les journaux de flux VPC et les métriques du réseau pour identifier les problèmes de connectivité entre les nœuds ou avec les services externes.
-
Mesures du plan de contrôle Kubernetes : surveillez le serveur d'API, le planificateur, le gestionnaire de contrôleurs et la base de données etcd pour détecter les problèmes de performances ou les défaillances qui affectent les opérations du cluster. Suivez la latence des demandes du serveur API, le taux de demandes et le taux d'erreur pour garantir que le plan de contrôle répond rapidement aux demandes de planification. Surveillez la taille de la base de données etcd, la durée des validations et les changements de leader pour détecter les problèmes de stabilité. La latence élevée du serveur API ou les changements fréquents de leader ETCD peuvent retarder la planification des modules et prolonger les délais de démarrage des tâches de formation.
Journaux des applications et des instances
Collectez et analysez les journaux des applications et des instances pour diagnostiquer les problèmes que les indicateurs ne peuvent expliquer à eux seuls. Les journaux fournissent un contexte détaillé sur les erreurs, les changements d'état et les événements du système qui vous aident à comprendre pourquoi les tâches de formation échouent ou fonctionnent mal. La corrélation entre les journaux et les métriques vous permet d'identifier les causes profondes plus rapidement.
-
Journaux des applications : collectez les journaux des applications provenant de vos tâches de formation, de vos pipelines de données et de vos frameworks de machine learning afin d'identifier les goulots d'étranglement et de diagnostiquer les défaillances. Ces journaux capturent des informations détaillées sur l'exécution des tâches, notamment les erreurs de chargement des données, les échecs d'initialisation du modèle, les erreurs de sauvegarde des points de contrôle et les avertissements spécifiques au framework. Corrélez les horodatages des journaux avec les pics métriques pour comprendre les causes de la dégradation des performances ou des défaillances. Par exemple, si l'utilisation du GPU baisse soudainement, consultez les journaux des applications pour détecter les erreurs indiquant des blocages du pipeline de données ou des échecs de prétraitement. Utilisez des outils de journalisation centralisés tels que CloudWatch Logs ou Fluent Bit pour agréger les journaux de tous les pods et les rendre consultables.
-
Journaux d'instance : collectez des journaux au niveau de l'instance, tels que les journaux du système et les résultats dmesg, pour détecter les problèmes matériels et les problèmes au niveau du noyau. Ces journaux révèlent des problèmes tels que des erreurs de pilote GPU, des défaillances d'allocation de mémoire, I/O des erreurs de disque et des problèmes d'interface réseau qui peuvent ne pas apparaître dans les journaux des applications. Corrélez les journaux d'instance avec les journaux et les métriques des applications pour déterminer si les échecs de formation sont dus à des problèmes matériels ou à des problèmes d'application. Par exemple, si une tâche de formation échoue avec une out-of-memory erreur, consultez les journaux dmesg pour détecter les messages du noyau OOM Killer indiquant si le système n'a plus de mémoire ou si l'application a dépassé ses limites de conteneur. Configurez des alertes pour les erreurs matérielles critiques, telles que les erreurs XID du GPU ou les pannes de disque, afin de pouvoir remplacer les instances défaillantes avant qu'elles n'entraînent des interruptions d'entraînement généralisées.
Les sections suivantes expliquent comment collecter les métriques décrites ci-dessus à l'aide de deux approches recommandées par AWS : CloudWatch Container Insights et Amazon Managed Prometheus Amazon Managed Prometheus with Amazon Managed Grafana. Choisissez CloudWatch Container Insights si vous préférez les outils natifs d'AWS dotés d'une configuration minimale et de tableaux de bord prédéfinis. Choisissez Amazon Managed Prometheus avec Amazon Managed Grafana si vous avez besoin de tableaux de bord personnalisés, de fonctionnalités de visualisation avancées ou si vous souhaitez intégrer une infrastructure de surveillance existante basée sur Prometheus. Pour obtenir la liste complète des métriques Container Insights disponibles, consultez les métriques Amazon EKS et Kubernetes Container Insights.
Envisagez de surveiller les mesures d'inférence en ligne en temps réel
Dans les systèmes en temps réel, une faible latence est essentielle pour fournir des réponses rapides aux utilisateurs ou aux autres systèmes dépendants. Une latence élevée peut dégrader l'expérience utilisateur ou enfreindre les exigences de performance. Les composants qui influencent la latence d'inférence incluent le temps de chargement du modèle, le temps de prétraitement, le temps de prédiction réel, le temps de post-traitement et le temps de transmission du réseau. Nous recommandons de surveiller la latence d'inférence pour garantir des réponses à faible latence conformes aux accords de niveau de service (SLAs) et de développer des métriques personnalisées pour les éléments suivants. Effectuez des tests en fonction de la charge attendue, incluez la latence du réseau, prenez en compte les demandes simultanées et testez avec des lots de différentes tailles.
-
Délai jusqu'au premier jeton (TTFT) : délai entre le moment où un utilisateur soumet une demande et celui où il reçoit le début de la réponse (le premier mot, jeton ou fragment). Par exemple, dans les chatbots, vous pouvez vérifier combien de temps il faut pour générer le premier résultat (jeton) une fois que l'utilisateur a posé une question.
-
End-to-End Latence — Il s'agit du temps total entre le moment où une demande est reçue et le moment où la réponse est renvoyée. Par exemple, mesurez le délai entre la demande et la réponse.
-
Jetons de sortie par seconde (TPS) : indique la rapidité avec laquelle votre modèle génère de nouveaux jetons une fois qu'il commence à répondre. Par exemple, dans les chatbots, vous pouvez suivre la vitesse de génération des modèles linguistiques pour un texte de référence.
-
Taux d'erreur : suit les demandes ayant échoué, ce qui peut indiquer des problèmes de performances. Par exemple, surveillez les demandes infructueuses concernant des documents volumineux ou certains caractères.
-
Débit : mesurez le nombre de demandes ou d'opérations que le système peut traiter par unité de temps. Par exemple, suivez les demandes par seconde pour gérer les pics de charge.
K/V (Key/Value) cache can be a powerful optimization technique for inference latency, particularly relevant for transformer-based models. K/V cache stores the key and value tensors from previous transformer layer computations, reducing redundant computations during autoregressive inference, particularly in large language models (LLMs). Cache Efficiency Metrics (specifically for K/Vou un cache de session (utilisation) :
-
hit/miss Taux de cache — Pour les configurations d'inférence utilisant la mise en cache (K/V ou intégration de caches), mesurez la fréquence à laquelle le cache est utile. Les faibles taux de réussite peuvent indiquer des modifications de la configuration du cache ou de la charge de travail sous-optimales, deux facteurs susceptibles d'augmenter la latence.
Dans les rubriques suivantes, nous démontrons la collecte de données pour certains des indicateurs mentionnés ci-dessus. Nous fournirons des exemples des deux approches recommandées par AWS : AWS Native CloudWatch Container Insights et Amazon Managed Prometheus open source avec Amazon Managed Grafana. Vous choisiriez l'une de ces solutions en fonction de vos besoins globaux en matière d'observabilité. Consultez les métriques Amazon EKS et Kubernetes Container Insights pour obtenir la liste complète des métriques Container Insights.
Suivi de l'utilisation de la mémoire GPU
Comme indiqué dans la Envisagez de surveiller la formation de base et de peaufiner les indicateurs rubrique, l'utilisation de la mémoire du GPU est essentielle pour éviter les erreurs out-of-memory (OOM) et garantir une utilisation efficace des ressources. Les exemples suivants montrent comment instrumenter votre application d'entraînement pour exposer une métrique d'histogramme personnalisée et calculer l'utilisation de la mémoire P95 pour identifier les pics de consommation. gpu_memory_usage_bytes Veillez à effectuer le test avec un exemple de tâche de formation (par exemple, peaufiner un modèle de transformateur) dans un environnement de test.
Exemple d'AWS CloudWatch Container Insights
Cet exemple montre comment instrumenter votre application de formation pour l'exposer gpu_memory_usage_bytes sous forme d'histogramme en utilisant l'approche native d'AWS. Notez que votre AI/ML conteneur doit être configuré pour émettre des journaux structurés au format EMF ( CloudWatch Embedded Metrics Format). CloudWatch logs analyse les données EMF et publie les métriques. Utilisez aws_embedded_metrics
from aws_embedded_metrics import metric_scope import torch import numpy as np memory_usage = [] @metric_scope def log_gpu_memory(metrics): # Record current GPU memory usage mem = torch.cuda.memory_allocated() memory_usage.append(mem) # Log as histogram metric metrics.set_namespace("MLTraining/GPUMemory") metrics.put_metric("gpu_memory_usage_bytes", mem, "Bytes", "Histogram") # Calculate and log P95 if we have enough data points if len(memory_usage) >= 10: p95 = np.percentile(memory_usage, 95) metrics.put_metric("gpu_memory_p95_bytes", p95, "Bytes") print(f"Current memory: {mem} bytes, P95: {p95} bytes") # Example usage in training loop for epoch in range(20): # Your model training code would go here log_gpu_memory()
Exemple de Prometheus et Grafana
Cet exemple montre comment instrumenter votre application d'entraînement pour l'exposer gpu_memory_usage_bytes` sous forme d'histogramme à l'aide de la bibliothèque cliente Prometheus en Python.
from prometheus_client import Histogram from prometheus_client import start_http_server import pynvml start_http_server(8080) memory_usage = Histogram( 'gpu_memory_usage_bytes', 'GPU memory usage during training', ['gpu_index'], buckets=[1e9, 2e9, 4e9, 8e9, 16e9, 32e9] ) # Function to get GPU memory usage def get_gpu_memory_usage(): if torch.cuda.is_available(): # Get the current GPU device device = torch.cuda.current_device() # Get memory usage in bytes memory_allocated = torch.cuda.memory_allocated(device) memory_reserved = torch.cuda.memory_reserved(device) # Total memory usage (allocated + reserved) total_memory = memory_allocated + memory_reserved return device, total_memory else: return None, 0 # Get GPU memory usage gpu_index, memory_used = get_gpu_memory_usage()
Suivez la durée de la demande d'inférence pour une inférence en ligne en temps réel
Comme indiqué dans la Envisagez de surveiller la formation de base et de peaufiner les indicateurs rubrique, une faible latence est essentielle pour fournir des réponses rapides aux utilisateurs ou aux autres systèmes dépendants. Les exemples suivants montrent comment suivre une métrique d'histogramme personnaliséeinference_request_duration_seconds, exposée par votre application d'inférence. Calculez la latence du 95e percentile (P95) pour vous concentrer sur les pires scénarios, testez avec des demandes d'inférence synthétique (par exemple, via Locust) dans un environnement intermédiaire et définissez des seuils d'alerte (par exemple, > 500 ms) pour détecter les violations des SLA.
Exemple d'AWS CloudWatch Container Insights
Cet exemple montre comment créer une métrique d'histogramme personnalisée dans votre application d'inférence pour inference_request_duration_seconds à l'aide du format de métrique intégré AWS. CloudWatch
import boto3 import time from aws_embedded_metrics import metric_scope, MetricsLogger cloudwatch = boto3.client('cloudwatch') @metric_scope def log_inference_duration(metrics: MetricsLogger, duration: float): metrics.set_namespace("ML/Inference") metrics.put_metric("inference_request_duration_seconds", duration, "Seconds", "Histogram") metrics.set_property("Buckets", [0.1, 0.5, 1, 2, 5]) @metric_scope def process_inference_request(metrics: MetricsLogger): start_time = time.time() # Your inference processing code here # For example: # result = model.predict(input_data) duration = time.time() - start_time log_inference_duration(metrics, duration) print(f"Inference request processed in {duration} seconds") # Example usage process_inference_request()
Exemple de Prometheus et Grafana
Cet exemple montre comment créer une métrique d'histogramme personnalisée dans votre application d'inférence pour inference_request_duration_seconds à l'aide de la bibliothèque cliente Prometheus en Python :
from prometheus_client import Histogram from prometheus_client import start_http_server import time start_http_server(8080) request_duration = Histogram( 'inference_request_duration_seconds', 'Inference request latency', buckets=[0.1, 0.5, 1, 2, 5] ) start_time = time.time() # Process inference request request_duration.observe(time.time() - start_time)
Dans Grafana, utilisez la requête histogram_quantile(0.95, sum(rate(inference_request_duration_seconds_bucket[5m])) by (le, pod)) pour visualiser les tendances de latence du P95. Pour en savoir plus, consultez la documentation sur l'histogramme de Prometheus
Suivez le débit des jetons pour une inférence en ligne en temps réel
Comme indiqué dans la Envisagez de surveiller la formation de base et de peaufiner les indicateurs rubrique, nous recommandons de surveiller le temps de traitement des jetons afin d'évaluer les performances du modèle et d'optimiser les décisions de dimensionnement. Les exemples suivants montrent comment suivre une métrique d'histogramme personnaliséetoken_processing_duration_seconds, exposée par votre application d'inférence. Calculez la durée du 95e percentile (P95) pour analyser l'efficacité du traitement, effectuez des tests avec des charges de demandes simulées (par exemple, 100 à 1 000 demandes/seconde) dans un cluster hors production et ajustez les déclencheurs KEDA pour optimiser la mise à l'échelle.
Exemple d'AWS CloudWatch Container Insights
Cet exemple montre comment créer une métrique d'histogramme personnalisée dans votre application d'inférence pour token_processing_duration_seconds à l'aide du format de métrique intégré AWS. CloudWatch Elle utilise des dimensions () with a custom `get_duration_bucketfonction `set_dimension) pour classer les durées en compartiments (par exemple, « 0.01", « >1").
import boto3 import time from aws_embedded_metrics import metric_scope, MetricsLogger cloudwatch = boto3.client('cloudwatch') @metric_scope def log_token_processing(metrics: MetricsLogger, duration: float, token_count: int): metrics.set_namespace("ML/TokenProcessing") metrics.put_metric("token_processing_duration_seconds", duration, "Seconds") metrics.set_dimension("ProcessingBucket", get_duration_bucket(duration)) metrics.set_property("TokenCount", token_count) def get_duration_bucket(duration): buckets = [0.01, 0.05, 0.1, 0.5, 1] for bucket in buckets: if duration <= bucket: return f"<={bucket}" return f">{buckets[-1]}" @metric_scope def process_tokens(input_text: str, model, tokenizer, metrics: MetricsLogger): tokens = tokenizer.encode(input_text) token_count = len(tokens) start_time = time.time() # Process tokens (replace with your actual processing logic) output = model(tokens) duration = time.time() - start_time log_token_processing(metrics, duration, token_count) print(f"Processed {token_count} tokens in {duration} seconds") return output
Exemple de Prometheus et Grafana
Cet exemple montre comment créer une métrique d'histogramme personnalisée dans votre application d'inférence pour token_processing_duration_seconds à l'aide de la bibliothèque cliente Prometheus en Python.
from prometheus_client import Histogram from prometheus_client import start_http_server import time start_http_server(8080) token_duration = Histogram( 'token_processing_duration_seconds', 'Token processing time per request', buckets=[0.01, 0.05, 0.1, 0.5, 1] ) start_time = time.time() # Process tokens token_duration.observe(time.time() - start_time)
Dans Grafana, utilisez la requête histogram_quantile(0.95, sum(rate(token_processing_duration_seconds_bucket[5m])) by (le, pod))` pour visualiser les tendances du temps de traitement du P95. Pour en savoir plus, consultez la documentation sur l'histogramme de Prometheus
Mesurer la latence de restauration des points de contrôle
Comme indiqué dans la Envisagez de surveiller la formation de base et de peaufiner les indicateurs rubrique, la latence des points de contrôle est une mesure critique au cours des différentes phases du cycle de vie du modèle. Les exemples suivants montrent comment suivre une métrique d'histogramme personnaliséecheckpoint_restore_duration_seconds`, exposée par votre application. Calculez la durée du 95e percentile (P95) pour surveiller les performances de restauration, effectuez des tests avec Spot interruptions dans un cluster hors production et définissez des seuils d'alerte (par exemple, <30 secondes) pour détecter les retards.
Exemple d'AWS CloudWatch Container Insights
Cet exemple montre comment instrumenter votre application par lots pour exposer checkpoint_restore_duration_seconds sous forme d'histogramme à l'aide d'Insights : CloudWatch
import boto3 import time import torch from aws_embedded_metrics import metric_scope, MetricsLogger @metric_scope def log_checkpoint_restore(metrics: MetricsLogger, duration: float): metrics.set_namespace("ML/ModelOperations") metrics.put_metric("checkpoint_restore_duration_seconds", duration, "Seconds", "Histogram") metrics.set_property("Buckets", [1, 5, 10, 30, 60]) metrics.set_property("CheckpointSource", "s3://my-bucket/checkpoint.pt") @metric_scope def load_checkpoint(model, checkpoint_path: str, metrics: MetricsLogger): start_time = time.time() # Load model checkpoint model.load_state_dict(torch.load(checkpoint_path)) duration = time.time() - start_time log_checkpoint_restore(metrics, duration) print(f"Checkpoint restored in {duration} seconds")
Exemple de Prometheus et Grafana
Cet exemple montre comment instrumenter votre application batch pour l'exposer checkpoint_restore_duration_seconds sous forme d'histogramme à l'aide de la bibliothèque cliente Prometheus en Python :
from prometheus_client import Histogram from prometheus_client import start_http_server import torch start_http_server(8080) restore_duration = Histogram( 'checkpoint_restore_duration_seconds', 'Time to restore checkpoint', buckets=[1, 5, 10, 30, 60] ) with restore_duration.time(): model.load_state_dict(torch.load("s3://my-bucket/checkpoint.pt"))
Dans Grafana, utilisez la requête histogram_quantile(0.95, sum(rate(checkpoint_restore_duration_seconds_bucket[5m]) by (le)) pour visualiser les tendances de latence de restauration du P95. Pour en savoir plus, consultez la documentation sur l'histogramme de Prometheus
