Surveillance et observabilité Observabilité et métriques

Observabilité

Surveillance et observabilité

Ciblez une utilisation élevée du GPU

La sous-utilisation GPUs indique que les ressources GPU allouées ne sont pas pleinement exploitées par les charges de travail, ce qui entraîne un gaspillage de capacité de calcul. Pour les AI/ML charges de travail sur Amazon EKS, nous vous recommandons de surveiller l'utilisation du GPU afin de cibler l'utilisation élevée du GPU et d'optimiser l'efficacité des ressources. La sous-utilisation GPUs gaspille la capacité de calcul et augmente les coûts, tandis que la surplanification peut entraîner des conflits et une dégradation des performances.

Nous vous recommandons de configurer Cloudwatch Container Insights sur Amazon EKS pour identifier des pods, des nœuds ou des charges de travail spécifiques présentant de faibles indicateurs d'utilisation du GPU. Il s'intègre facilement à Amazon EKS, ce qui vous permet de surveiller l'utilisation du GPU et d'ajuster la planification des pods ou les types d'instances si l'utilisation tombe en dessous des niveaux cibles. Sinon, si cela ne répond pas à vos besoins spécifiques (par exemple, visualisation avancée), envisagez d'utiliser DCGM-Exporter de NVIDIA aux côtés de Prometheus et Grafana pour la surveillance native de Kubernetes. Les deux approches fournissent des informations sur les métriques du GPU, ce qui vous permet d'ajuster la planification des pods ou les types d'instances si l'utilisation tombe en dessous des niveaux cibles. Vérifiez les métriques NVIDIA telles que nvidia_smi_utilization_gpu (utilisation du calcul du GPU) et nvidia_smi_utilization_memory (utilisation de la mémoire du GPU) via DCGM-Exporter ou. CloudWatch Observez les tendances, telles que le faible taux d'utilisation constant à certaines heures ou pour des tâches spécifiques.

Les limites de ressources statiques dans Kubernetes (par exemple, le nombre de processeurs, de mémoire et de GPU) peuvent entraîner un provisionnement excessif ou une sous-utilisation, en particulier pour les charges de travail dynamiques telles que l'inférence. AI/ML Nous vous recommandons d'analyser les tendances d'utilisation et de regrouper les charges de travail en un nombre réduit GPUs, en veillant à ce que chaque GPU soit pleinement utilisé avant d'en allouer de nouveaux. S' GPUs ils sont sous-utilisés, envisagez les stratégies suivantes pour optimiser la planification et le partage. Pour en savoir plus, consultez les meilleures pratiques d'EKS en matière de calcul et d'autoscaling pour plus de détails.

Observabilité et métriques

Utilisation d'outils de surveillance et d'observabilité pour vos charges de travail AI/ML

Les AI/ML services modernes fonctionnent à l'intersection de l'infrastructure, de la modélisation et de la logique des applications. Les ingénieurs de plateforme gèrent l'infrastructure, la pile d'observabilité et veillent à ce que les métriques soient collectées, stockées et visualisées. AI/ML Les ingénieurs définissent des mesures spécifiques au modèle et se concentrent sur les performances sous des charges et des distributions variables. Les développeurs d'applications utilisent des API, acheminent les demandes et suivent les indicateurs de niveau de service et les interactions des utilisateurs. Le succès dépend de la mise en place de pratiques d'observabilité unifiées dans tous les environnements qui donnent à toutes les parties prenantes une visibilité sur l'état et les performances du système.

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 souvent confrontées à des erreurs out-of-memory (OOM), à une inefficacité des ressources et à des coûts inutiles. Pour les clients d'EKS, une surveillance efficace garantit de meilleures performances, une meilleure résilience et une réduction des coûts. Une approche holistique qui combine la surveillance granulaire du GPU à l'aide de NVIDIA DCGM Exporter (par exemple, mémoire GPU utilisée, mémoire GPU libre), la surveillance et l'optimisation du service d'inférence pour les informations distribuées sur les charges de travail avec leurs métriques natives à l'aide de frameworks tels que Ray, vLLM et des informations au niveau des applications pour des métriques personnalisées.

Outils et cadres

Certains outils et frameworks proposent des out-of-the-box métriques natives pour surveiller les AI/ML charges de travail, ce qui facilite l'intégration sans configuration personnalisée supplémentaire. Ils 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. En voici quelques exemples :

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 pour collecter les métriques du GPU et propose des tableaux de bord prédéfinis pour des informations rapides. Activé par l'installation du module complémentaire CloudWatch Observability sur votre cluster, Container Insights déploie et gère le cycle de vie de l'exportateur NVIDIA DCGM, qui collecte les métriques du GPU à partir des pilotes de Nvidia et les expose à celles-ci. CloudWatch

Une fois intégré à Container Insights, il détecte CloudWatch automatiquement NVIDIA GPUs dans votre environnement, collecte les indicateurs critiques de santé et de performance de votre NVIDIA GPUs sous forme de CloudWatch métriques et les met à disposition sur des tableaux de bord sélectionnés out-of-the-box. De plus, Ray et vLLM peuvent être intégrés à CloudWatch l'aide de l' CloudWatch agent unifié pour envoyer des métriques. Cela simplifie l'observabilité dans les environnements EKS, permettant aux équipes de se concentrer sur le réglage des performances et l'optimisation des coûts.

Pour plus d'informations, pour consulter la liste complète des métriques disponibles, consultez les métriques Amazon EKS et Kubernetes Container Insights. Reportez-vous à Obtenir des informations opérationnelles pour les charges de travail des GPU NVIDIA à l'aide d'Amazon CloudWatch Container Insights et d'optimisation de la réactivité de l'IA : un guide pratique sur l'inférence optimisée par Amazon Bedrock en fonction de la latence pour des implémentations détaillées.

Prometheus et Grafana gérés Si votre entreprise est à l'aise avec les outils open source et les tableaux de bord personnalisés, nous vous recommandons de déployer Prometheus avec le NVIDIA DCGM-Exporter et Grafana pour la surveillance native de Kubernetes avec des visualisations avancées. Prometheus récupère les métriques et Grafana crée des visualisations avancées.

En outre, vous pouvez utiliser des frameworks open source tels que Ray et vLLM pour exporter des métriques vers Prometheus (qui peuvent être visualisés à l'aide de Grafana), ou vous pouvez vous connecter à une source de données AWS X-Ray, puis créer des tableaux de bord pour examiner les analyses, les informations ou les traces.

Pour plus d'informations, consultez la section Surveillance des charges de travail du GPU sur Amazon EKS à l'aide des services open source gérés par AWS pour une implémentation détaillée.

Envisagez de surveiller la formation de base et de peaufiner les indicateurs

Pour les indicateurs de formation de base relatifs aux AI/ML charges de travail sur EKS, envisagez une combinaison de mesures indiquant l'état et les performances de votre cluster Amazon EKS et les charges de travail d'apprentissage automatique exécutées sur celui-ci. Reportez-vous à la section Introduction à l'observation des charges de travail d'apprentissage automatique sur Amazon EKS pour une mise en œuvre détaillée. Ci-dessous, nous détaillons les indicateurs que nous recommandons de surveiller.

Mesures d'utilisation des ressources :

Utilisation du processeur, de la mémoire, du processeur graphique et de la mémoire du processeur graphique : la surveillance de ces indicateurs pour les charges de travail ML vous permet de vous assurer que les ressources allouées sont suffisantes et d'identifier les opportunités d'optimisation. Par exemple, le suivi de mesures telles que gpu_memory_usage_bytes vous pouvez identifier les modèles de consommation de mémoire, détecter les pics d'utilisation et calculer des percentiles tels que le 95e percentile (P95) pour comprendre les demandes de mémoire les plus élevées pendant l'entraînement. Cela permet d'optimiser vos modèles et votre infrastructure afin d'éviter les erreurs OOM et de réduire les coûts.
Utilisation des ressources des nœuds et des pods : le suivi de l'utilisation des ressources au niveau du nœud et du pod vous permet d'identifier les problèmes de contention des ressources et les goulots d'étranglement potentiels. Par exemple, vérifiez si des nœuds sont surutilisés, ce qui pourrait affecter la planification des pods.
Comparaison de l'utilisation des ressources avec les demandes et les limites : cela permet de savoir si votre cluster est capable de gérer les charges de travail actuelles et de s'adapter aux charges de travail futures. Par exemple, comparez l'utilisation réelle de la mémoire aux limites afin d'éviter les out-of-memory erreurs.
Mesures internes issues des frameworks ML : capturez les indicateurs de formation et de convergence internes à partir des frameworks ML (TensorFlow, PyTorch), tels que les courbes de perte, le taux d'apprentissage, le temps de traitement par lots et la durée des étapes de formation, souvent visualisés avec ou similaire. TensorBoard

Mesures de performance du modèle :

Exactitude, précision, rappel et score F1 : ils sont essentiels pour comprendre les performances de vos modèles de machine learning. Par exemple, après l'entraînement, calculez le score F1 sur un ensemble de validation pour évaluer les performances.
Mesures spécifiques à l'entreprise et KPIs — Définissez et suivez les indicateurs directement liés à la valeur commerciale de vos AI/ML initiatives. Par exemple, dans un système de recommandation, suivez l'engagement accru des utilisateurs.
Suivi de ces mesures au fil du temps : cela permet d'identifier toute dégradation des performances du modèle. Par exemple, comparez les indicateurs de performance des différentes versions du modèle pour identifier les tendances.

Mesures de qualité et de dérive des données :

Propriétés statistiques des données d'entrée : surveillez-les au fil du temps pour détecter les dérives des données ou les anomalies susceptibles d'avoir un impact sur les performances du modèle. Par exemple, suivez la moyenne des entités en entrée pour détecter les décalages.
Détection de la dérive des données et alertes — Mettez en œuvre des mécanismes pour détecter et signaler automatiquement les problèmes de qualité des données. Par exemple, utilisez des tests pour comparer les données actuelles avec les données d'entraînement et signaler toute dérive significative.

Mesures de latence et de débit :

End-to-End Latence des pipelines de formation ML : surveillez le temps nécessaire pour que les données circulent dans l'ensemble du pipeline de formation. Par exemple, mesurez le temps total entre l'ingestion des données et la mise à jour du modèle.
Débit de formation et taux de traitement : suivez le volume de données traitées pendant la formation pour garantir l'efficacité. Par exemple, surveillez les échantillons positifs et négatifs traités par seconde.
Latence de restauration du point de contrôle : surveillez le temps nécessaire pour charger un point de contrôle du modèle enregistré depuis un emplacement de stockage (S3, EFS, FSx etc.) vers la GPU/CPU mémoire lors de la reprise d'une tâche, d'une reprise après un échec ou de l'initialisation. Cette métrique a un impact direct sur le temps de reprise des tâches, les performances de démarrage à froid et l'efficacité globale des pipelines d'interférence. Dans les services d'inférence à auto-scaling, la lenteur du chargement aux points de contrôle peut entraîner des retards de démarrage à froid et une dégradation de l'expérience utilisateur. Ces indicateurs connexes sont également couramment utilisés pour améliorer le point de contrôle du modèle : latence des temps d'arrêt aux points de contrôle, temps de désérialisation du modèle, taille du point de contrôle et nombre d'échecs de restauration des points de contrôle.
Durée de la demande d'inférence — Surveillez le temps nécessaire pour traiter une demande d'inférence. Il s'agit du délai entre la réception de la demande initiale et la réponse complète du modèle.
Débit des jetons : surveillez le temps de traitement des jetons pour évaluer les performances du modèle et optimiser les décisions de dimensionnement. La lenteur du traitement peut indiquer un manque d'efficacité ou une sous-utilisation des ressources, ce qui a un impact sur le rapport coût-efficacité. Le suivi des indicateurs tels que les jetons entrants et sortants par seconde, ainsi que le temps de traitement, peuvent aider à identifier les goulots d'étranglement, les ralentissements et les facteurs de coûts liés aux performances.
Identification des goulots d'étranglement liés aux performances : utilisez ces indicateurs pour identifier les domaines à optimiser dans le processus de formation. Par exemple, analysez le temps consacré au chargement des données par rapport au calcul du modèle.

Taux d'erreurs et défaillances :

Surveillance des erreurs tout au long du pipeline d'apprentissage automatique : cela inclut le prétraitement des données, l'apprentissage des modèles et l'inférence. Par exemple, enregistrez les erreurs lors du prétraitement pour identifier rapidement les problèmes.
Identification et investigation des erreurs récurrentes : cela permet de maintenir un modèle de haute qualité et de garantir des performances constantes. Par exemple, analysez les journaux pour trouver des modèles tels que des données spécifiques à l'origine des défaillances.

Métriques spécifiques à Kubernetes et EKS :

Mesures de l'état du cluster Kubernetes : surveillez l'état et l'état de divers objets Kubernetes, notamment les pods, les nœuds et le plan de contrôle. Par exemple, utilisez des outils tels que kubectl la vérification de l'état des modules.
Succès/échecs d'exécution du pipeline : suivez les cycles du successful/failed pipeline, la durée des tâches, le temps d'achèvement des étapes et les erreurs d'orchestration (par exemple, à l'aide d'Kubeflow/Mlflow/Argoévénements).
Mesures des services AWS : suivez les métriques des autres services AWS qui prennent en charge votre infrastructure EKS et les applications qui y sont exécutées. Par exemple, si vous utilisez Amazon S3, surveillez la taille du compartiment pour suivre l'utilisation du stockage.
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 ou défaillances de performance. Par exemple, suivez le temps de latence des demandes du serveur d'API pour des raisons de réactivité.

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.

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 la réception d'une demande et le moment où la réponse est renvoyée. Par exemple, mesurez le temps écoulé 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.

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 dans votre application d'entraînement pour envoyer des journaux structurés au format EMF à Logs, qui extrait les métriques du GPU CloudWatch .


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 et la documentation sur le client 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 pour évaluer les performances du modèle et 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 et la documentation sur le client 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 et la documentation sur le client de Prometheus.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Stockage

Performances