Implémentation de l'observabilité des inférences sur les clusters HyperPod - Amazon SageMaker AI

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.

Implémentation de l'observabilité des inférences sur les clusters HyperPod

Amazon SageMaker HyperPod fournit des fonctionnalités complètes d'observabilité des inférences qui permettent aux scientifiques des données et aux ingénieurs en apprentissage automatique de surveiller et d'optimiser leurs modèles déployés. Cette solution est activée par SageMaker HyperPod Observability et collecte automatiquement les indicateurs de performance pour les charges de travail d'inférence, fournissant ainsi une surveillance prête à la production grâce aux tableaux de bord intégrés de Prometheus et Grafana.

Lorsque les métriques sont activées par défaut, la plateforme capture les données essentielles sur les performances des modèles, notamment la latence des invocations, les demandes simultanées, les taux d’erreur et les métriques au niveau des jetons, tout en fournissant des points de terminaison Prometheus standard aux clients qui préfèrent mettre en œuvre des solutions d’observabilité personnalisées.

Note

Cette rubrique décrit en détail la mise en œuvre de l'observabilité par inférence sur les HyperPod clusters. Pour une référence plus générale, consultez Observabilité des clusters et des tâches.

Ce guide fournit des step-by-step instructions pour implémenter et utiliser l'observabilité par inférence sur vos HyperPod clusters. Vous apprendrez à configurer les métriques dans vos fichiers YAML de déploiement, à accéder aux tableaux de bord de surveillance en fonction de votre rôle (administrateur, scientifique des données ou ingénieur de machine learning), à intégrer des solutions d’observabilité personnalisées à l’aide des points de terminaison Prometheus et à résoudre les problèmes de surveillance courants.

Métriques d’inférence prises en charge

Métriques d’invocation

Ces métriques capturent les données de demande et de réponse d’inférence de modèle, offrant ainsi une visibilité universelle, quel que soit votre type de modèle ou le cadre de service. Lorsque les métriques d’inférence sont activées, elles sont calculées au moment de l’invocation et exportées vers votre infrastructure de surveillance.

  • model_invocations_total : nombre total de demandes d’invocation adressées au modèle

  • model_errors_total : nombre total d’erreurs lors de l’invocation du modèle

  • model_concurrent_requests : demandes de modèle simultanées actives

  • model_latency_milliseconds : latence d’invocation de modèle en millisecondes

  • model_ttfb_milliseconds : latence du délai jusqu’au premier octet du modèle en millisecondes

Métriques des conteneurs de modèles

Ces métriques fournissent des informations sur les opérations internes de vos conteneurs de modèles, notamment le traitement des jetons, la gestion des files d’attente et les métriques de performance spécifiques au cadre. Les métriques disponibles dépendent de votre cadre de service de modèle :

Dimensions des métriques

Toutes les métriques d’inférence incluent des étiquettes complètes qui permettent un filtrage et une analyse détaillés de vos déploiements :

  • Identité de cluster :

    • cluster_id- L'identifiant unique du HyperPod cluster

    • cluster_name- Le nom du HyperPod cluster

  • Identité de ressource :

    • resource_name- Nom du déploiement (par exemple, jumpstart-model-deployment « »)

    • resource_type : type de déploiement (jumpstart, inference-endpoint)

    • namespace : espace de noms Kubernetes pour la multilocation

  • Caractéristiques du modèle :

    • model_name : identifiant de modèle spécifique (par exemple, « llama-2-7b-chat »)

    • model_version- Version du modèle pour les A/B tests et les annulations

    • model_container_type : cadre de service (TGI, LMI, -)

  • Contexte de l’infrastructure :

    • pod_name : identifiant individuel du pod pour le débogage

    • node_name : nœud Kubernetes pour la corrélation des ressources

    • instance_type- type d' EC2 instance pour l'analyse des coûts

  • Contexte opérationnel :

    • metric_source : point de collecte (reverse-proxy, model-container)

    • task_type : classification de la charge de travail (inférence)

Configuration des métriques dans le code YAML de déploiement

Amazon SageMaker HyperPod active les métriques d'inférence par défaut pour tous les déploiements de modèles, offrant ainsi une observabilité immédiate sans configuration supplémentaire. Vous pouvez personnaliser le comportement des métriques en modifiant la configuration YAML du déploiement pour activer ou désactiver la collecte de métriques en fonction de vos besoins spécifiques.

Déployez un modèle à partir de JumpStart

Utilisez la configuration YAML suivante pour déployer un JuJumpStartmpStart modèle avec les métriques activées :

apiVersion: inference.sagemaker.aws.amazon.com/v1 kind: JumpStartModel metadata: name:mistral-model namespace: ns-team-a spec: model: modelId: "huggingface-llm-mistral-7b-instruct" modelVersion: "3.19.0" metrics: enabled:true # Default: true (can be set to false to disable) replicas: 2 sageMakerEndpoint: name: "mistral-model-sm-endpoint" server: instanceType: "ml.g5.12xlarge" executionRole: "arn:aws:iam::123456789:role/SagemakerRole" tlsConfig: tlsCertificateOutputS3Uri: s3://hyperpod/mistral-model/certs/

Déployez des modèles personnalisés et affinés depuis Amazon S3 ou Amazon FSx

Configurez des points de terminaison d’inférence personnalisés avec des paramètres de métriques détaillés à l’aide du code YAML suivant :

apiVersion: inference.sagemaker.aws.amazon.com/v1 kind: JumpStartModel metadata: name:mistral-model namespace: ns-team-a spec: model: modelId: "huggingface-llm-mistral-7b-instruct" modelVersion: "3.19.0" metrics: enabled:true # Default: true (can be set to false to disable) replicas: 2 sageMakerEndpoint: name: "mistral-model-sm-endpoint" server: instanceType: "ml.g5.12xlarge" executionRole: "arn:aws:iam::123456789:role/SagemakerRole" tlsConfig: tlsCertificateOutputS3Uri: s3://hyperpod/mistral-model/certs/ Deploy a custom inference endpoint Configure custom inference endpoints with detailed metrics settings using the following YAML: apiVersion: inference.sagemaker.aws.amazon.com/v1 kind: InferenceEndpointConfig metadata: name: inferenceendpoint-deepseeks namespace: ns-team-a spec: modelName: deepseeks modelVersion: 1.0.1 metrics: enabled: true # Default: true (can be set to false to disable) metricsScrapeIntervalSeconds: 30 # Optional: if overriding the default 15s modelMetricsConfig: port: 8000 # Optional: if overriding, it defaults to the WorkerConfig.ModelInvocationPort.ContainerPort within the InferenceEndpointConfig spec 8080 path: "/custom-metrics" # Optional: if overriding the default "/metrics" endpointName: deepseek-sm-endpoint instanceType: ml.g5.12xlarge modelSourceConfig: modelSourceType: s3 s3Storage: bucketName: model-weights region: us-west-2 modelLocation: deepseek prefetchEnabled: true invocationEndpoint: invocations worker: resources: limits: nvidia.com/gpu: 1 requests: nvidia.com/gpu: 1 cpu: 25600m memory: 102Gi image: 763104351884.dkr.ecr.us-west-2.amazonaws.com/djl-inference:0.32.0-lmi14.0.0-cu124 modelInvocationPort: containerPort: 8080 name: http modelVolumeMount: name: model-weights mountPath: /opt/ml/model environmentVariables: ... tlsConfig: tlsCertificateOutputS3Uri: s3://hyperpod/inferenceendpoint-deepseeks4/certs/
Note

Pour désactiver les métriques pour des déploiements spécifiques, configurez metrics.enabled: false dans votre configuration YAML.

Surveillance et dépannage des charges de travail d’inférence par rôle

Amazon SageMaker HyperPod fournit des fonctionnalités d'observabilité complètes qui prennent en charge différents flux de travail utilisateur, de la configuration initiale du cluster au dépannage avancé des performances. Suivez les conseils suivants en fonction de votre rôle et de vos exigences en matière de surveillance.

HyperPod administrateur

Votre responsabilité : activez l’infrastructure d’observabilité et garantissez l’intégrité du système dans l’ensemble du cluster.

Ce que vous devez savoir :

  • L’observabilité à l’échelle du cluster fournit des métriques d’infrastructure pour toutes les charges de travail.

  • La configuration en un clic déploie une pile de surveillance avec des tableaux de bord préconfigurés.

  • Les métriques d’infrastructure sont distinctes des métriques d’inférence spécifiques au modèle.

Ce que vous devez faire :

  1. Accédez à la HyperPod console.

  2. Sélectionnez votre cluster.

  3. Accédez à la page de détails du HyperPod cluster que vous venez de créer. Vous verrez une nouvelle option pour installer le module complémentaire HyperPod d'observabilité.

  4. Cliquez sur l’option Installation rapide. Après 1 à 2 minutes, toutes les étapes seront terminées et vous verrez le tableau de bord Grafana et les détails de l’espace de travail Prometheus.

Cette action unique déploie automatiquement le module complémentaire EKS, configure les opérateurs d’observabilité et provisionne des tableaux de bord prédéfinis dans Grafana.

Scientifique des données

Votre responsabilité : déployez les modèles de manière efficace et surveillez leurs performances de base.

Ce que vous devez savoir :

  • Les métriques sont automatiquement activées lorsque vous déployez des modèles.

  • Les tableaux de bord Grafana offrent une visibilité immédiate sur les performances des modèles.

  • Vous pouvez filtrer les tableaux de bord pour vous concentrer sur vos déploiements spécifiques.

Ce que vous devez faire :

  1. Déployez votre modèle en utilisant votre méthode préférée :

    1. Interface utilisateur Amazon SageMaker Studio

    2. HyperPod Commandes CLI

    3. Kit SDK Python dans les blocs-notes

    4. kubectl avec configurations YAML

  2. Accédez aux métriques de votre modèle :

    1. Ouvrez Amazon SageMaker Studio

    2. Accédez à HyperPod Cluster et ouvrez le tableau de bord Grafana

    3. Sélectionnez le tableau de bord d’inférence.

    4. Appliquez des filtres pour visualiser le déploiement de votre modèle spécifique.

  3. Surveillez les indicateurs de performance clés :

    1. Suivez la latence et le débit du modèle.

    2. Surveillez les taux d’erreur et la disponibilité.

    3. Passez en revue les tendances d’utilisation des ressources.

Une fois cette opération terminée, vous aurez une visibilité immédiate sur les performances de votre modèle sans configuration supplémentaire, ce qui vous permettra d’identifier rapidement les problèmes de déploiement ou les variations des performances.

Ingénieur de machine learning (MLE)

Votre responsabilité : maintenir les performances du modèle de production et résoudre les problèmes de performance complexes.

Ce que vous devez savoir :

  • Les métriques avancées incluent les détails des conteneurs de modèles, tels que les profondeurs des files d’attente et les métriques relatives aux jetons.

  • L’analyse de corrélation entre plusieurs types de métriques révèle les causes racines.

  • Les configurations d’autoscaling ont un impact direct sur les performances lors des pics de trafic.

Scénario hypothétique : le modèle de discussion instantanée d’un client connaît des réponses lentes intermittentes. Les utilisateurs se plaignent de retards de 5 à 10 secondes. Le MLE peut tirer parti de l’observabilité d’inférence pour une étude systématique des performances.

Ce que vous devez faire :

  1. Examinez le tableau de bord Grafana pour comprendre l’ampleur et la gravité du problème de performance :

    1. Alerte de latence élevée active depuis 09h30

    2. Latence P99 : 8,2 s (normale : 2,1 s)

    3. Période affectée : 09h30-10h15 (45 minutes)

  2. Corrélez plusieurs métriques pour comprendre le comportement du système lors de l’incident :

    1. Demandes simultanées : pics de 45 (normal : 15 à 20)

    2. Mise à l’échelle des pods : KEDA a mis à l’échelle 2→5 pods lors de l’incident

    3. Utilisation du GPU : restée normale (85 à 90 %)

    4. Utilisation de la mémoire : normale (24 Go/32 Go)

  3. Examinez le comportement du système distribué, car les métriques d’infrastructure semblent normales :

    1. Vue au niveau des nœuds : tous les pods sont concentrés sur le même nœud (mauvaise distribution).

    2. Métriques des conteneurs de modèles : la profondeur de file d’attente TGI indique 127 demandes (normal : 5 à 10).

    Available in Grafana dashboard under "Model Container Metrics" panel Metric: tgi_queue_size{resource_name="customer-chat-llama"} Current value: 127 requests queued (indicates backlog)
  4. Identifiez les problèmes de configuration interconnectée :

    1. Politique de mise à l’échelle KEDA : trop lente (intervalle d’interrogation de 30 s)

    2. Chronologie de mise à l’échelle : réponse à la mise à l’échelle retardée de plus de 45 secondes par rapport au pic de trafic

  5. Mettez en œuvre des correctifs ciblés sur la base de l’analyse :

    1. Intervalle d’interrogation KEDA mis à jour : 30 s → 15 s

    2. Valeur de maxReplicas augmentée dans la configuration de la mise à l’échelle

    3. Seuils de mise à l’échelle ajustés pour effectuer une mise à l’échelle plus tôt (15 demandes simultanées à la place de 20)

Vous pouvez diagnostiquer systématiquement les problèmes de performance complexes à l’aide de métriques complètes, mettre en œuvre des correctifs ciblés et établir des mesures préventives pour maintenir les performances constantes du modèle de production.

Mise en œuvre votre propre intégration d’observabilité

Amazon SageMaker HyperPod expose les mesures d'inférence via les points de terminaison Prometheus conformes aux normes du secteur, permettant ainsi l'intégration à votre infrastructure d'observabilité existante. Utilisez cette approche lorsque vous préférez implémenter des solutions de surveillance personnalisées ou intégrer des plateformes d’observabilité tierces au lieu d’utiliser la pile Grafana et Prometheus intégrée.

Accès aux points de terminaison des métriques d’inférence

Ce que vous devez savoir :

  • Les métriques d’inférence sont automatiquement exposées sur les points de terminaison Prometheus standardisés.

  • Les métriques sont disponibles quel que soit votre type de modèle ou votre cadre de service.

  • Les pratiques standard de Prometheus en matière de récupération s’appliquent à la collection de données.

Configuration des points de terminaison des métriques d’inférence :

  • Port : 9113

  • Chemin : /metrics

  • Point de terminaison complet : http://pod-ip:9113/metrics

Métriques d’inférence disponibles :

  • model_invocations_total : nombre total de demandes d’invocation adressées au modèle

  • model_errors_total : nombre total d’erreurs lors de l’invocation du modèle

  • model_concurrent_requests : demandes simultanées actives par modèle

  • model_latency_milliseconds : latence d’invocation de modèle en millisecondes

  • model_ttfb_milliseconds : latence du délai jusqu’au premier octet du modèle en millisecondes

Accès aux métriques des conteneurs de modèles

Ce que vous devez savoir :

  • Les conteneurs modèles présentent des métriques supplémentaires spécifiques à leur cadre de service.

  • Ces métriques fournissent des informations internes sur les conteneurs, telles que le traitement des jetons et la profondeur des files d’attente.

  • La configuration des points de terminaison varie selon le type de conteneur de modèle.

Pour les déploiements de JumpStart modèles utilisant des conteneurs d'inférence de génération de texte (TGI) :

Pour les déploiements de JumpStart modèles utilisant des conteneurs LMI (Large Model Inference) :

Pour les points de terminaison d’inférence personnalisés (BYOD) :

  • Port : configuré par le client (par défaut : 8080). Par défaut, c'est le. WorkerConfig ModelInvocationPort. ContainerPort dans les limites InferenceEndpointConfig des spécifications.)

  • Chemin : configuré par le client (par défaut /metrics)

Mise en œuvre d’une intégration d’observabilité personnalisée

Avec une intégration d’observabilité personnalisée, vous êtes responsable des éléments suivants :

  1. Récupération des métriques : mettez en œuvre la récupération compatible avec Prometheus à partir des points de terminaison ci-dessus.

  2. Exportation de données : configurez l’exportation vers la plateforme d’observabilité de votre choix.

  3. Alertes : configurez des règles d’alerte en fonction de vos exigences opérationnelles.

  4. Tableaux de bord : créez des tableaux de bord de visualisation adaptés à vos besoins de surveillance.

Résolution des problèmes d’observabilité d’inférence

Le tableau de bord n’affiche aucune donnée

Si le tableau de bord Grafana est vide et que tous les panneaux indiquent « Aucune donnée », effectuez les étapes suivantes pour enquêter :

  1. Vérifiez que l’administrateur a installé l’observabilité d’inférence :

    1. Accédez à HyperPod la console > Sélectionnez le cluster > Vérifiez si le statut « Observabilité » indique « Activé »

    2. Vérifiez que le lien vers l’espace de travail Grafana est accessible depuis l’aperçu du cluster.

    3. Vérifiez que l’espace de travail Amazon Managed Prometheus est configuré et qu’il reçoit des données.

  2. Vérifiez que HyperPod l'observabilité est activée :

    hyp observability view
  3. Vérifiez que les métriques des modèles sont activées :

    kubectl get jumpstartmodel -n <namespace> customer-chat-llama -o jsonpath='{.status.metricsStatus}' # Expected: enabled: true, state:Enabled
    kubectl get jumpstartmodel -n <namespace> customer-chat-llama -o jsonpath='{.status.metricsStatus}' # Expected: enabled: true, state:Enabled
  4. Vérifiez le point de terminaison des métriques :

    kubectl port-forward pod/customer-chat-llama-xxx 9113:9113 curl localhost:9113/metrics | grep model_invocations_total# Expected: model_invocations_total{...} metrics
  5. Vérifiez les journaux :

    # Model Container kubectl logs customer-chat-llama-xxx -c customer-chat-llama# Look for: OOM errors, CUDA errors, model loading failures # Proxy/SideCar kubectl logs customer-chat-llama-xxx -c sidecar-reverse-proxy# Look for: DNS resolution issues, upstream connection failures # Metrics Exporter Sidecar kubectl logs customer-chat-llama-xxx -c otel-collector# Look for: Metrics collection issues, export failures

Autres problèmes courants

Problème Solution Action

L’observabilité d’inférence n’est pas installée

Installer l’observabilité d’inférence via la console

« Activer l'observabilité » dans la console HyperPod

Métriques désactivées dans le modèle

Mettre à jour la configuration du modèle

Ajouter metrics: {enabled: true} aux spécifications du modèle

Espace de travail AMP non configuré

Corriger la connexion aux sources de données

Vérifier l’identifiant de l’espace de travail AMP dans les sources de données Grafana

La connectivité réseau

Vérifiez les groupes de sécurité/ NACLs

S’assurer que les pods peuvent atteindre les points de terminaison AMP