Beobachtbarkeit

Überwachung und Beobachtbarkeit

Ziel ist eine hohe GPU-Auslastung

Eine unzureichende Auslastung GPUs weist darauf hin, dass die zugewiesenen GPU-Ressourcen von den Workloads nicht vollständig genutzt werden, was zu einer Verschwendung von Rechenkapazität führt. Für AI/ML Workloads auf Amazon EKS empfehlen wir, die GPU-Auslastung zu überwachen, um eine hohe GPU-Auslastung zu erreichen und die Ressourceneffizienz zu optimieren. Nicht ausgelastete GPUs Ressourcen verschwenden Rechenkapazität und erhöhen die Kosten, während eine zu hohe Terminplanung zu Konflikten und Leistungseinbußen führen kann.

Wir empfehlen, Cloudwatch Container Insights auf Amazon EKS einzurichten, um bestimmte Pods, Knoten oder Workloads mit niedrigen GPU-Nutzungsmetriken zu identifizieren. Es lässt sich leicht in Amazon EKS integrieren, sodass Sie die GPU-Auslastung überwachen und Pod-Scheduling oder Instance-Typen anpassen können, falls die Auslastung unter das Zielniveau fällt. Wenn dies Ihren spezifischen Anforderungen nicht entspricht (z. B. erweiterte Visualisierung), sollten Sie alternativ den DCGM-Exporter von NVIDIA zusammen mit Prometheus und Grafana für die Kubernetes-native Überwachung verwenden. Beide Ansätze bieten Einblicke in die GPU-Metriken, sodass Sie die Pod-Planung oder die Instance-Typen anpassen können, falls die Auslastung unter das Zielniveau fällt. Überprüfen Sie NVIDIA-Metriken wie nvidia_smi_utilization_gpu (GPU-Compute-Nutzung) und nvidia_smi_utilization_memory (GPU-Speichernutzung) über den DCGM-Exporter oder. CloudWatch Halten Sie Ausschau nach Trends, wie z. B. einer konstant niedrigen Auslastung zu bestimmten Zeiten oder bei bestimmten Jobs.

Statische Ressourcenbeschränkungen in Kubernetes (z. B. CPU-, Arbeitsspeicher- und GPU-Anzahl) können zu einer Über- oder Unterauslastung führen, insbesondere bei dynamischen Workloads wie Inferenz. AI/ML Wir empfehlen, Nutzungstrends zu analysieren und Workloads auf weniger zu konsolidieren, um sicherzustellen GPUs, dass jede GPU voll ausgelastet ist, bevor neue zugewiesen werden. Wenn diese nicht ausgelastet GPUs sind, sollten Sie die folgenden Strategien in Betracht ziehen, um die Planung und gemeinsame Nutzung zu optimieren. Weitere Informationen finden Sie in den Best Practices für EKS Compute und Autoscaling.

Beobachtbarkeit und Metriken

Verwenden Sie Überwachungs- und Beobachtungstools für Ihre Workloads AI/ML

Moderne AI/ML Dienste arbeiten an der Schnittstelle von Infrastruktur, Modellierung und Anwendungslogik. Plattformingenieure verwalten die Infrastruktur und den Observability-Stack und stellen sicher, dass Metriken gesammelt, gespeichert und visualisiert werden. AI/ML Ingenieure definieren modellspezifische Metriken und konzentrieren sich auf die Leistung bei variierender Last und Verteilung. Anwendungsentwickler nutzen APIs, leiten Anfragen weiter und verfolgen Service-Level-Metriken und Benutzerinteraktionen. Der Erfolg hängt von der Einführung einheitlicher Überwachbarkeitspraktiken in allen Umgebungen ab, die allen Beteiligten Einblick in den Zustand und die Leistung des Systems geben.

Die Optimierung von Amazon EKS-Clustern für AI/ML Workloads stellt die Überwachung vor besondere Herausforderungen, insbesondere im Zusammenhang mit der GPU-Speicherverwaltung. Ohne angemessene Überwachung sehen sich Unternehmen häufig mit out-of-memory (OOM-) Fehlern, Ressourcenineffizienzen und unnötigen Kosten konfrontiert. Für EKS-Kunden sorgt eine effektive Überwachung für eine bessere Leistung, Ausfallsicherheit und geringere Kosten. Ein ganzheitlicher Ansatz, der eine detaillierte GPU-Überwachung mithilfe des NVIDIA DCGM Exporter (z. B. genutzter GPU-Speicher, freier GPU-Speicher), die Überwachung und Optimierung von Inferenzdiensten für verteilte Workloads mit ihren nativen Metriken unter Verwendung von Frameworks wie Ray, vLLM und Erkenntnissen auf Anwendungsebene für benutzerdefinierte Metriken kombiniert.

Tools und Frameworks

Bestimmte Tools und Frameworks bieten native out-of-the-box Metriken für die Überwachung von AI/ML Workloads und ermöglichen so eine einfachere Integration ohne zusätzliche benutzerdefinierte Einrichtung. Diese konzentrieren sich auf Leistungsaspekte wie Latenz, Durchsatz und Token-Generierung, die für die Bereitstellung von Inferenzen und das Benchmarking von entscheidender Bedeutung sind. Beispiele sind unter anderem:

• vLLM: Eine Serving-Engine mit hohem Durchsatz für große Sprachmodelle (LLMs), die native Metriken wie Anforderungslatenz und Speichernutzung bereitstellt.

• Ray: Ein Framework für verteilte Datenverarbeitung, das Metriken für skalierbare KI-Workloads ausgibt, einschließlich der Ausführungszeiten von Aufgaben und der Ressourcennutzung.

• Hugging Face Text Generation Inference (TGI): Ein Toolkit für die Bereitstellung und Bereitstellung LLMs mit integrierten Metriken für die Inferenzleistung.

• NVIDIA genai-perf: Ein Befehlszeilentool zum Benchmarking generativer KI-Modelle, zur Messung von Durchsatz, Latenz und LLM-spezifischen Metriken, wie z. B. Anfragen, die in bestimmten Zeitintervallen abgeschlossen wurden.

Methoden zur Beobachtbarkeit

Wir empfehlen, alle zusätzlichen Beobachtbarkeitsmechanismen auf eine der folgenden Arten zu implementieren.

CloudWatch Container Insights Wenn Ihr Unternehmen AWS-native Tools mit minimalem Einrichtungsaufwand bevorzugt, empfehlen wir CloudWatch Container Insights. Es ist in den NVIDIA DCGM Exporter integriert, um GPU-Metriken zu sammeln, und bietet vorgefertigte Dashboards für schnelle Einblicke. Container Insights wird durch die Installation des CloudWatch Observability-Add-ons auf Ihrem Cluster aktiviert und implementiert und verwaltet den Lebenszyklus des NVIDIA DCGM Exporter, der GPU-Metriken von den Treibern von Nvidia sammelt und sie für sie bereitstellt. CloudWatch

Sobald es in Container Insights integriert ist, erkennt es CloudWatch automatisch NVIDIA GPUs in Ihrer Umgebung, sammelt die kritischen Integritäts- und Leistungskennzahlen Ihrer NVIDIA-Daten GPUs als CloudWatch Metriken und stellt sie auf kuratierten Dashboards zur Verfügung. out-of-the-box Darüber hinaus können Ray und vLLM CloudWatch mithilfe des Unified Agent zum Senden von Metriken integriert werden. CloudWatch Dies vereinfacht die Beobachtbarkeit in EKS-Umgebungen, sodass sich die Teams auf die Leistungsoptimierung und Kostenoptimierung konzentrieren können.

Weitere Informationen und eine vollständige Liste der verfügbaren Metriken finden Sie unter Amazon EKS- und Kubernetes Container Insights-Metriken. Weitere Informationen zu detaillierten Implementierungen finden Sie unter Gewinnen betrieblicher Einblicke für NVIDIA-GPU-Workloads mithilfe von Amazon CloudWatch Container Insights und Optimierung der KI-Reaktionsfähigkeit: Ein praktischer Leitfaden für latenzoptimierte Inferenzen mit Amazon Bedrock.

Managed Prometheus und Grafana Wenn Ihr Unternehmen mit Open-Source-Tools und maßgeschneiderten Dashboards vertraut ist, empfehlen wir die Bereitstellung von Prometheus mit dem NVIDIA DCGM-Exporter und Grafana für Kubernetes-natives Monitoring mit erweiterten Visualisierungen. Prometheus erfasst Metriken und Grafana erstellt erweiterte Visualisierungen.

Darüber hinaus können Sie Open-Source-Frameworks wie Ray und vLLM verwenden, um Metriken nach Prometheus zu exportieren (die mit Grafana visualisiert werden können), oder Sie können eine Connect zu einer AWS X-Ray X-Ray-Datenquelle herstellen und dann Dashboards erstellen, um Analysen, Erkenntnisse oder Traces zu betrachten.

Weitere Informationen finden Sie unter Überwachen von GPU-Workloads auf Amazon EKS mithilfe von AWS-verwalteten Open-Source-Services für eine detaillierte Implementierung.

Erwägen Sie die Überwachung von Kernschulungen und die Feinabstimmung von Kennzahlen

Ziehen Sie für zentrale Trainingsmetriken für AI/ML Workloads auf EKS eine Kombination von Metriken in Betracht, die den Zustand und die Leistung Ihres Amazon EKS-Clusters und der darauf ausgeführten Machine-Learning-Workloads angeben. Eine detaillierte Implementierung finden Sie unter Einführung in die Beobachtung von Workloads für maschinelles Lernen auf Amazon EKS. Im Folgenden finden Sie eine Aufschlüsselung der Metriken, die wir zur Überwachung empfehlen.

Kennzahlen zur Ressourcennutzung:

• CPU-, Arbeitsspeicher-, GPU- und GPU-Speichernutzung — Durch die Überwachung dieser Metriken für ML-Workloads können Sie sicherstellen, dass die zugewiesenen Ressourcen ausreichend sind, und Optimierungsmöglichkeiten identifizieren. Sie können beispielsweise Messwerte wie Speicherverbrauchsmuster identifizierengpu_memory_usage_bytes, Spitzennutzung erkennen und Perzentile wie das 95. Perzentil (P95) berechnen, um den höchsten Speicherbedarf während des Trainings zu ermitteln. Dies hilft bei der Optimierung Ihrer Modelle und Infrastruktur, um OOM-Fehler zu vermeiden und Kosten zu senken.

• Nutzung von Knoten- und Pod-Ressourcen — Durch die Verfolgung der Ressourcennutzung auf Knoten- und Pod-Ebene können Sie Ressourcenkonflikte und potenzielle Engpässe erkennen. Prüfen Sie beispielsweise, ob Knoten überlastet sind, was sich auf die Pod-Planung auswirken könnte.

• Vergleich der Ressourcennutzung mit Anfragen und Limits — Dies gibt Aufschluss darüber, ob Ihr Cluster aktuelle und future Workloads bewältigen kann. Vergleichen Sie beispielsweise die tatsächliche Speicherauslastung mit den Grenzwerten, um out-of-memory Fehler zu vermeiden.

• Interne Kennzahlen aus ML-Frameworks — Erfassen Sie interne Trainings- und Konvergenzmetriken aus ML-Frameworks (TensorFlow, PyTorch), wie Verlustkurven, Lernrate, Batch-Verarbeitungszeit und Dauer von Trainingsschritten, die häufig mit oder ähnlichem visualisiert werden. TensorBoard

Modellieren Sie Leistungskennzahlen:

• Genauigkeit, Präzision, Erinnerungsvermögen und F1-Score — Diese sind entscheidend, um die Leistung Ihrer ML-Modelle zu verstehen. Berechnen Sie beispielsweise nach dem Training den F1-Score eines Validierungssatzes, um die Leistung zu beurteilen.

• Geschäftsspezifische Kennzahlen und KPIs — Definieren und verfolgen Sie Kennzahlen, die in direktem Zusammenhang mit dem Geschäftswert Ihrer Initiativen stehen. AI/ML Verfolgen Sie beispielsweise in einem Empfehlungssystem die erhöhte Nutzerinteraktion.

• Verfolgen Sie diese Metriken im Laufe der Zeit — Auf diese Weise können Sie jegliche Verschlechterung der Modellleistung erkennen. Vergleichen Sie beispielsweise Leistungskennzahlen verschiedener Modellversionen, um Trends zu erkennen.

Datenqualität und Drift-Metriken:

• Statistische Eigenschaften von Eingabedaten — Überwachen Sie diese Daten im Laufe der Zeit, um Datenabweichungen oder Anomalien zu erkennen, die sich auf die Modellleistung auswirken könnten. Verfolgen Sie beispielsweise den Mittelwert von Eingabe-Features, um Verschiebungen zu erkennen.

• Erkennung von Datenabweichungen und Warnmeldungen — Implementieren Sie Mechanismen zur automatischen Erkennung von Datenqualitätsproblemen und zur Warnung bei solchen Problemen. Verwenden Sie beispielsweise Tests, um aktuelle Daten mit Trainingsdaten zu vergleichen und bei signifikanten Abweichungen zu warnen.

Metriken für Latenz und Durchsatz:

• End-to-End Latenz von ML-Trainingspipelines — Überwachen Sie, wie lange es dauert, bis Daten die gesamte Trainingspipeline durchlaufen. Messen Sie beispielsweise die Gesamtzeit von der Datenaufnahme bis zur Modellaktualisierung.

• Trainingsdurchsatz und Verarbeitungsrate — Verfolgen Sie die Menge der während des Trainings verarbeiteten Daten, um die Effizienz sicherzustellen. Überwachen Sie beispielsweise positive und negative Proben, die pro Sekunde verarbeitet werden.

• Latenz bei der Checkpoint-Wiederherstellung — Überwachen Sie die Zeit, die benötigt wird, um einen gespeicherten Modell-Checkpoint von einem Speicherort (S3, EFS FSx usw.) zurück in den GPU/CPU Speicher zu laden, wenn ein Job wieder aufgenommen, nach einem Fehler wiederhergestellt oder initialisiert wird. Diese Kennzahl wirkt sich direkt auf die Wiederherstellungszeit von Jobs, die Kaltstartleistung und die Gesamteffizienz von Interferenz-Pipelines aus. Bei auto-scaling Inferenzdiensten kann das langsame Laden von Checkpoints zu Verzögerungen beim Kaltstart und einer Verschlechterung der Benutzererfahrung führen. Diese verwandten Metriken werden auch häufig zur Verbesserung von Modell-Checkpoints verwendet: Latenz bei Checkpoint-Ausfallzeiten, Deserialisierungszeit des Modells, Checkpoint-Größe und Anzahl der Checkpoint-Wiederherstellungsfehler.

• Dauer einer Inferenzanforderung — Überwachen Sie, wie lange es dauert, bis eine Inferenzanforderung abgeschlossen ist. Dies ist die Zeit vom Empfang der ersten Anfrage bis zur vollständigen Antwort des Modells.

• Token-Durchsatz — Überwachen Sie die Token-Verarbeitungszeit, um die Modellleistung zu messen und Skalierungsentscheidungen zu optimieren. Eine langsame Verarbeitung kann auf Ineffizienzen oder unzureichend genutzte Ressourcen hinweisen, was sich negativ auf die Kostenwirksamkeit auswirkt. Das Verfolgen von Kennzahlen wie eingehenden Tokens pro Sekunde und ausgehenden Tokens pro Sekunde sowie der Verarbeitungszeit kann dabei helfen, Leistungsengpässe, Verlangsamungen und Kostentreiber zu identifizieren.

• Identifizierung von Leistungsengpässen — Verwenden Sie diese Kennzahlen, um Bereiche zu ermitteln, in denen der Trainingsprozess optimiert werden muss. Analysieren Sie beispielsweise die für das Laden von Daten aufgewendete Zeit im Vergleich zur Modellberechnung.

Fehlerraten und Ausfälle:

• Überwachung von Fehlern in der gesamten ML-Pipeline — Dazu gehören Datenvorverarbeitung, Modelltraining und Inferenz. Protokollieren Sie beispielsweise Fehler bei der Vorverarbeitung, um Probleme schnell zu identifizieren.

• Identifizierung und Untersuchung wiederkehrender Fehler — Dies trägt dazu bei, ein qualitativ hochwertiges Modell aufrechtzuerhalten und eine gleichbleibende Leistung sicherzustellen. Analysieren Sie beispielsweise Protokolle, um Muster wie bestimmte Daten zu finden, die Fehler verursachen.

Spezifische Kennzahlen für Kubernetes und EKS:

• Kubernetes-Cluster-State-Metriken — Überwachen Sie den Zustand und den Status verschiedener Kubernetes-Objekte, einschließlich Pods, Knoten und der Kontrollebene. Verwenden Sie beispielsweise Tools, um den Pod-Status kubectl zu überprüfen.

• Erfolgreiche/Fehlgeschlagene Pipeline-Läufe — Verfolgen Sie successful/failed Pipeline-Läufe, Auftragsdauern, Abschlusszeiten von Schritten und Orchestrierungsfehler (z. B. bei der Verwendung von Kubeflow/Mlflow/Argo Ereignissen).

• AWS-Servicemetriken — Verfolgen Sie Metriken für andere AWS-Services, die Ihre EKS-Infrastruktur und die darauf ausgeführten Anwendungen unterstützen. Wenn Sie beispielsweise Amazon S3 verwenden, überwachen Sie die Bucket-Größe, um die Speichernutzung zu verfolgen.

• Kubernetes Control Plane Metrics — Überwachen Sie den API-Server, den Scheduler, den Controller-Manager und die etcd-Datenbank auf Leistungsprobleme oder Ausfälle. Verfolgen Sie beispielsweise die Latenz von API-Serveranfragen im Hinblick auf die Reaktionsfähigkeit.

In den nachfolgenden Themen wird das Sammeln von Daten für einige der oben genannten Kennzahlen demonstriert. Wir werden Beispiele mit den beiden von AWS empfohlenen Ansätzen bereitstellen: AWS-native CloudWatch Container Insights und Amazon Managed Prometheus als Open-Source-Lösung mit Amazon Managed Grafana. Sie würden sich je nach Ihren allgemeinen Anforderungen an die Beobachtbarkeit für eine dieser Lösungen entscheiden. Eine vollständige Liste der Container Insights-Metriken finden Sie unter Amazon EKS- und Kubernetes Container Insights-Metriken.

Erwägen Sie die Überwachung von Online-Inferenzmetriken in Echtzeit

In Echtzeitsystemen ist eine geringe Latenz entscheidend, um Benutzern oder anderen abhängigen Systemen zeitnahe Antworten zu geben. Eine hohe Latenz kann die Benutzererfahrung beeinträchtigen oder Leistungsanforderungen verletzen. Zu den Komponenten, die die Inferenzlatenz beeinflussen, gehören die Ladezeit des Modells, die Vorverarbeitungszeit, die tatsächliche Prognosezeit, die Nachverarbeitungszeit und die Netzwerkübertragungszeit. Wir empfehlen, die Inferenzlatenz zu überwachen, um sicherzustellen, dass Antworten mit niedriger Latenz und Service Level Agreements (SLAs) eingehalten werden, und benutzerdefinierte Metriken für Folgendes zu entwickeln. Testen Sie unter erwarteter Last, berücksichtigen Sie die Netzwerklatenz, berücksichtigen Sie gleichzeitige Anfragen und testen Sie mit unterschiedlichen Batchgrößen.

• Time to First Token (TTFT) — Zeitspanne zwischen dem Senden einer Anfrage durch einen Benutzer und dem Erhalt der ersten Antwort (erstes Wort, Token oder Abschnitt). In Chatbots würden Sie beispielsweise überprüfen, wie lange es dauert, bis die erste Ausgabe (Token) generiert ist, nachdem der Benutzer eine Frage gestellt hat.

• End-to-End Latenz — Dies ist die Gesamtzeit vom Eingang einer Anfrage bis zum Zurücksenden der Antwort. Messen Sie beispielsweise die Zeit von der Anfrage bis zur Antwort.

• Output Tokens Per Second (TPS) — Gibt an, wie schnell Ihr Modell neue Token generiert, nachdem es reagiert hat. In Chatbots würden Sie beispielsweise die Generierungsgeschwindigkeit für Sprachmodelle für einen Basistext verfolgen.

• Fehlerrate — Verfolgt fehlgeschlagene Anfragen, die auf Leistungsprobleme hinweisen können. Überwachen Sie beispielsweise fehlgeschlagene Anfragen für große Dokumente oder bestimmte Zeichen.

• Durchsatz — Messen Sie die Anzahl der Anfragen oder Operationen, die das System pro Zeiteinheit verarbeiten kann. Verfolgen Sie beispielsweise Anfragen pro Sekunde, um Spitzenlasten zu bewältigen.

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/Voder eine Sitzung (Cache verwenden):

• hit/miss Cache-Verhältnis — Messen Sie bei Inferenz-Setups, die Caching nutzen (K/V oder eingebettete Caches), wie oft der Cache hilfreich ist. Niedrige Trefferquoten können auf suboptimale Änderungen der Cache-Konfiguration oder der Arbeitslast hindeuten, die beide die Latenz erhöhen können.

In den nachfolgenden Themen wird das Sammeln von Daten für einige der oben genannten Metriken demonstriert. Wir werden Beispiele mit den beiden von AWS empfohlenen Ansätzen bereitstellen: AWS-native CloudWatch Container Insights und Amazon Managed Prometheus als Open-Source-Lösung mit Amazon Managed Grafana. Sie würden sich je nach Ihren allgemeinen Anforderungen an die Beobachtbarkeit für eine dieser Lösungen entscheiden. Eine vollständige Liste der Container Insights-Metriken finden Sie unter Amazon EKS- und Kubernetes Container Insights-Metriken.

Nachverfolgung der GPU-Speichernutzung

Wie im Erwägen Sie die Überwachung von Kernschulungen und die Feinabstimmung von Kennzahlen Thema erörtert, ist die GPU-Speichernutzung unerlässlich, um out-of-memory (OOM-) Fehler zu vermeiden und eine effiziente Ressourcennutzung sicherzustellen. Die folgenden Beispiele zeigen, wie Sie Ihre Trainingsanwendung so instrumentieren, dass eine benutzerdefinierte Histogrammmetrik angezeigt wirdgpu_memory_usage_bytes, und wie die P95-Speichernutzung berechnet wird, um den Spitzenverbrauch zu ermitteln. Stellen Sie sicher, dass Sie den Test anhand eines Beispiel-Trainingsjobs (z. B. der Feinabstimmung eines Transformatormodells) in einer Staging-Umgebung durchführen.

Beispiel für AWS-native CloudWatch Container Insights

Dieses Beispiel zeigt, wie Sie Ihre Trainingsanwendung mithilfe des AWS-nativen Ansatzes gpu_memory_usage_bytes so instrumentieren, dass sie als Histogramm angezeigt wird. Beachten Sie, dass Ihr AI/ML Container so konfiguriert sein muss, dass er strukturierte Logs im EMF-Format ( CloudWatch Embedded Metrics Format) ausgibt. CloudWatch logs analysiert EMF und veröffentlicht die Metriken. Verwenden Sie aws_embedded_metrics in Ihrer Trainingsanwendung, um strukturierte Logs im EMF-Format an Logs zu senden, das GPU-Metriken extrahiert. 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()

Beispiel Prometheus und Grafana

Dieses Beispiel zeigt, wie Sie Ihre Trainingsanwendung mithilfe der Prometheus-Clientbibliothek in Python gpu_memory_usage_bytes` so instrumentieren, dass sie als Histogramm angezeigt wird.

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()

Verfolgen Sie die Dauer von Inferenzanfragen für Online-Inferenzen in Echtzeit

Wie bereits im Erwägen Sie die Überwachung von Kernschulungen und die Feinabstimmung von Kennzahlen Thema erörtert, ist eine geringe Latenz entscheidend, um Benutzern oder anderen abhängigen Systemen zeitnahe Antworten zu bieten. Die folgenden Beispiele zeigen, wie Sie eine benutzerdefinierte Histogramm-Metrik verfolgen könneninference_request_duration_seconds, die von Ihrer Inferenzanwendung bereitgestellt wird. Berechnen Sie die Latenz im 95. Perzentil (P95), um sich auf Worst-Case-Szenarien zu konzentrieren, testen Sie mit synthetischen Inferenzanforderungen (z. B. über Locust) in einer Staging-Umgebung und legen Sie Warnschwellenwerte (z. B. > 500 ms) fest, um SLA-Verstöße zu erkennen.

Beispiel für AWS-native CloudWatch Container Insights

Dieses Beispiel zeigt, wie Sie eine benutzerdefinierte Histogramm-Metrik in Ihrer Inferenzanwendung für inference_request_duration_seconds mithilfe des AWS Embedded Metric Format erstellen. 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()

Beispiel Prometheus und Grafana

Dieses Beispiel zeigt, wie Sie eine benutzerdefinierte Histogrammmetrik in Ihrer Inferenzanwendung für inference_request_duration_seconds mithilfe der Prometheus-Clientbibliothek in Python erstellen:

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)

Verwenden Sie in Grafana die Abfrage, um P95-Latenztrends histogram_quantile(0.95, sum(rate(inference_request_duration_seconds_bucket[5m])) by (le, pod)) zu visualisieren. Weitere Informationen finden Sie unter Prometheus-Histogramm-Dokumentation und Prometheus-Client-Dokumentation.

Verfolgen Sie den Token-Durchsatz für Online-Inferenz in Echtzeit

Wie im Erwägen Sie die Überwachung von Kernschulungen und die Feinabstimmung von Kennzahlen Thema besprochen, empfehlen wir, die Token-Verarbeitungszeit zu überwachen, um die Modellleistung zu messen und Skalierungsentscheidungen zu optimieren. Die folgenden Beispiele zeigen, wie Sie eine benutzerdefinierte Histogramm-Metrik verfolgen könnentoken_processing_duration_seconds, die von Ihrer Inferenzanwendung bereitgestellt wird. Berechnen Sie die Dauer des 95. Perzentils (P95), um die Verarbeitungseffizienz zu analysieren, Tests mit simulierten Anforderungslasten (z. B. 100 bis 1000 Anforderungen/Sekunde) in einem Cluster außerhalb der Produktion durchzuführen und KEDA-Trigger anzupassen, um die Skalierung zu optimieren.

Beispiel für AWS-native CloudWatch Container Insights

Dieses Beispiel zeigt, wie Sie eine benutzerdefinierte Histogramm-Metrik in Ihrer Inferenzanwendung für token_processing_duration_seconds mithilfe des AWS Embedded Metric Format erstellen. CloudWatch Es verwendet die ) with a custom `get_duration_bucket Funktion dimensions (`set_dimension), um die Dauer in Bereiche einzuteilen (z. B. „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

Beispiel Prometheus und Grafana

Dieses Beispiel zeigt, wie Sie eine benutzerdefinierte Histogrammmetrik in Ihrer Inferenzanwendung für token_processing_duration_seconds mithilfe der Prometheus-Clientbibliothek in Python erstellen.

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)

Verwenden Sie in Grafana die Abfrage, histogram_quantile(0.95, sum(rate(token_processing_duration_seconds_bucket[5m])) by (le, pod))` um Trends der P95-Verarbeitungszeit zu visualisieren. Weitere Informationen finden Sie unter Prometheus-Histogramm-Dokumentation und Prometheus-Client-Dokumentation.

Messen Sie die Latenz bei der Checkpoint-Wiederherstellung

Wie im Erwägen Sie die Überwachung von Kernschulungen und die Feinabstimmung von Kennzahlen Thema erörtert, ist die Checkpoint-Latenz eine wichtige Kennzahl in mehreren Phasen des Modelllebenszyklus. Die folgenden Beispiele zeigen, wie Sie eine benutzerdefinierte Histogramm-Metrik verfolgen könnencheckpoint_restore_duration_seconds`, die von Ihrer Anwendung bereitgestellt wird. Berechnen Sie die Dauer des 95. Perzentils (P95), um die Wiederherstellungsleistung zu überwachen, Tests mit Spot-Unterbrechungen in einem Cluster außerhalb der Produktion durchzuführen und Schwellenwerte für Warnmeldungen festzulegen (z. B. <30 Sekunden), um Verzögerungen zu erkennen.

Beispiel für AWS-native CloudWatch Container Insights

Dieses Beispiel zeigt, wie Sie Ihre Batch-Anwendung instrumentieren, um checkpoint_restore_duration_seconds mithilfe von Insights als Histogramm darzustellen: 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")

Beispiel Prometheus und Grafana

Dieses Beispiel zeigt, wie Sie Ihre Batch-Anwendung mithilfe der Prometheus-Clientbibliothek in Python checkpoint_restore_duration_seconds so instrumentieren, dass sie als Histogramm angezeigt wird:

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"))

Verwenden Sie in Grafana die Abfrage, histogram_quantile(0.95, sum(rate(checkpoint_restore_duration_seconds_bucket[5m]) by (le)) um Latenztrends bei der P95-Wiederherstellung zu visualisieren. Weitere Informationen finden Sie unter Prometheus-Histogramm-Dokumentation und Prometheus-Client-Dokumentation.