Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Beobachtbarkeit

Überwachung und Beobachtbarkeit

GPU-Metriken erklärt

Die Metrik zur GPU-Auslastung zeigt, ob die GPU während des Beispielfensters irgendwelche Arbeiten ausgeführt hat. Diese Metrik erfasst den Prozentsatz der Zeit, in der die GPU mindestens eine Anweisung ausgeführt hat. Sie gibt jedoch nicht Aufschluss darüber, wie effizient die GPU ihre Hardware genutzt hat. Eine GPU enthält mehrere Streaming-Multiprozessoren (SMs), d. h. parallel Verarbeitungseinheiten, die Befehle ausführen. Eine 100-prozentige Auslastung kann bedeuten, dass die GPU über all ihre Funktionen hinweg umfangreiche parallel Workloads ausgeführt hat SMs, oder es kann bedeuten, dass ein einziger kleiner Befehl die GPU während des Testzeitraums aktiviert hat. Um die tatsächliche Auslastung zu verstehen, müssen Sie die GPU-Metriken auf mehreren Ebenen der Hardwarearchitektur untersuchen. Jeder Streaming-Multiprozessor besteht aus unterschiedlichen Kerntypen, und jede Schicht weist unterschiedliche Leistungsmerkmale auf. Metriken der obersten Ebene (GPU-Auslastung, Speicherauslastung, GPU-Leistung und GPU-Temperatur, sichtbar über nvidia-smi) zeigen, ob das Gerät aktiv ist. Tiefere Messwerte (SM-Auslastung, SM-Aktivität und Tensorkernnutzung) zeigen, wie effizient die GPU ihre Ressourcen nutzt.

Zielen Sie auf einen hohen GPU-Stromverbrauch ab

Zu wenig genutzte Rechenkapazität wird GPUs verschwendet und die Kosten steigen, da Workloads nicht alle GPU-Komponenten gleichzeitig beanspruchen. Verfolgen Sie für AI/ML Workloads auf Amazon EKS den GPU-Stromverbrauch als Proxy, um die tatsächliche GPU-Aktivität zu ermitteln. Die GPU-Auslastung gibt an, wie viel Zeit die GPU einen beliebigen Kernel ausführt. Es wird jedoch nicht angegeben, ob die Streaming-Multiprozessoren, Speichercontroller und Tensorkerne alle gleichzeitig aktiv sind. Durch den Stromverbrauch wird diese Lücke aufgedeckt, da voll ausgelastete Hardware deutlich mehr Energie verbraucht als Hardware, die schlanke Kernel ausführt oder zwischen Aufgaben ungenutzt bleibt. Vergleichen Sie den Stromverbrauch mit der Thermal Design Power (TDP) der GPU, um eine Unterauslastung zu erkennen, und untersuchen Sie dann, ob Ihre Arbeitslast durch CPU-Vorverarbeitung, Netzwerk-I/O oder ineffiziente Batchgrößen behindert wird.

Richten Sie CloudWatch Container Insights auf Amazon EKS ein, um Pods, Knoten oder Workloads mit geringem GPU-Stromverbrauch zu identifizieren. Dieses Tool lässt sich direkt in Amazon EKS integrieren und ermöglicht es Ihnen, den GPU-Stromverbrauch zu überwachen und Pod-Scheduling oder Instance-Typen anzupassen, wenn der Stromverbrauch unter Ihre Zielwerte fällt. Wenn Sie erweiterte Visualisierungen oder benutzerdefinierte Dashboards benötigen, verwenden Sie den DCGM-Exporter von NVIDIA mit Prometheus und Grafana für die Kubernetes-native Überwachung. Beide Ansätze liefern wichtige NVIDIA-Metriken wie (GPU-Stromverbrauch) und (GPU-Temperatur). nvidia_smi_power_draw nvidia_smi_temperature_gpu Eine Liste der Metriken finden Sie unter https://docs.aws.amazon.com/AmazonCloudWatch/ latest/monitoring/CloudWatch -Agent-NVIDIA-GPU.htm. Achten Sie auf Muster wie z. B. einen konstant niedrigen Stromverbrauch zu bestimmten Zeiten oder für bestimmte Aufgaben. Anhand dieser Trends können Sie ermitteln, wo Workloads konsolidiert oder die Ressourcenzuweisung angepasst werden müssen.

Statische Ressourcenbeschränkungen in Kubernetes (wie CPU-, Arbeitsspeicher- und GPU-Anzahl) führen häufig zu einer Über- oder Unterauslastung, insbesondere bei dynamischen AI/ML Workloads wie Inferenz, bei denen der Bedarf schwankt. Analysieren Sie Ihre Nutzungstrends und konsolidieren Sie Workloads auf weniger. GPUs Stellen Sie sicher, dass jede GPU voll ausgelastet ist, bevor Sie weitere GPUs zuweisen. Dieser Ansatz reduziert Verschwendung und senkt die Kosten. Detaillierte Anleitungen zur Optimierung von Planungs- und Sharing-Strategien finden Sie in den Best Practices von EKS Compute and Autoscaling

Beobachtbarkeit und Metriken

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

Moderne AI/ML Dienste erfordern eine Koordination zwischen Infrastruktur, Modellierung und Anwendungslogik. Plattformingenieure verwalten die Infrastruktur und den Observability-Stack. Sie sammeln, speichern und visualisieren Metriken. AI/ML Ingenieure definieren modellspezifische Metriken und überwachen die Leistung bei variierender Last und Datenverteilung. Anwendungsentwickler nutzen APIs, leiten Anfragen weiter und verfolgen Service-Level-Metriken und Benutzerinteraktionen. Ohne einheitliche Beobachtungspraktiken arbeiten diese Teams isoliert und übersehen wichtige Signale über den Zustand und die Leistung des Systems. Die Schaffung einer gemeinsamen Transparenz in allen Umgebungen stellt sicher, dass alle Beteiligten Probleme frühzeitig erkennen und einen zuverlässigen Service aufrechterhalten können.

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 mit out-of-memory (OOM-) Fehlern, Ressourcenineffizienzen und unnötigen Kosten konfrontiert. Eine effektive Überwachung sorgt für eine bessere Leistung, Ausfallsicherheit und geringere Kosten für EKS-Kunden. Verwenden Sie einen ganzheitlichen Ansatz, der drei Überwachungsebenen kombiniert. Überwachen Sie zunächst detaillierte GPU-Metriken mit dem NVIDIA DCGM Exporter, um den GPU-Stromverbrauch, die GPU-Temperatur, die SM-Aktivität, die SM-Belegung und XID-Fehler zu verfolgen. Zweitens sollten Sie Frameworks für Inferenzdienste wie Ray und vLLM überwachen, um anhand ihrer nativen Metriken Einblicke in verteilte Workloads zu gewinnen. Drittens: Sammeln Sie Erkenntnisse auf Anwendungsebene, um benutzerdefinierte Metriken zu verfolgen, die für Ihren Workload spezifisch sind. Dieser mehrschichtige Ansatz bietet Ihnen einen Überblick über die Hardwarenutzung bis hin zur Anwendungsleistung.

Tools und Frameworks

Verschiedene Tools und Frameworks bieten native out-of-the-box Metriken für die Überwachung von AI/ML Workloads. Diese integrierten Metriken machen eine benutzerdefinierte Instrumentierung überflüssig und reduzieren die Einrichtungszeit. Die Metriken konzentrieren sich auf Leistungsaspekte wie Latenz, Durchsatz und Token-Generierung, die für die Bereitstellung von Inferenzen und das Benchmarking von entscheidender Bedeutung sind. Durch die Verwendung nativer Metriken können Sie sofort mit der Überwachung beginnen, ohne benutzerdefinierte Erfassungspipelines erstellen zu müssen.

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

Nach der Installation von Container Insights erkennt Container Insights CloudWatch automatisch NVIDIA GPUs in Ihrer Umgebung und sammelt wichtige Integritäts- und Leistungskennzahlen. Diese Metriken werden auf kuratierten out-of-the-box Dashboards angezeigt. Sie können Ray und vLLM auch integrieren, indem Sie den Unified CloudWatch Agent CloudWatch verwenden, um ihre systemeigenen Metriken zu senden. Dieser einheitliche Ansatz vereinfacht die Beobachtbarkeit in EKS-Umgebungen und ermöglicht es Teams, sich auf die Leistungsoptimierung und Kostenoptimierung zu konzentrieren, anstatt eine Überwachungsinfrastruktur aufzubauen.

Eine vollständige Liste der verfügbaren Metriken finden Sie unter Amazon EKS- und Kubernetes Container Insights-Metriken. step-by-stepAnleitungen zur Implementierung der GPU-Überwachung finden Sie unter Gain operational insights for NVIDIA GPU-Workloads using Amazon CloudWatch Container Insights. Praktische Beispiele für die Optimierung der Inferenzlatenz finden Sie unter Optimizing AI Responsiveness: A practical guide to Amazon Bedrock latency-optimized inference.

Managed Prometheus und Grafana Wenn Ihr Unternehmen maßgeschneiderte Dashboards und erweiterte Visualisierungsfunktionen benötigt, setzen Sie Prometheus mit dem NVIDIA DCGM-Exporter und Grafana für Kubernetes-natives Monitoring ein. Prometheus scannt und speichert GPU-Metriken aus dem DCGM-Exporter, während Grafana flexible Visualisierungs- und Warnfunktionen bietet. Dieser Ansatz bietet Ihnen im Vergleich zu Container Insights mehr Kontrolle über das Dashboard-Design und die Aufbewahrung von Kennzahlen. CloudWatch

Sie können diesen Monitoring-Stack erweitern, indem Sie Open-Source-Frameworks wie Ray und vLLM Ray und vLLM integrieren, um ihre nativen Metriken nach Prometheus zu exportieren. Sie können Grafana auch mit einer AWS X-Ray X-Ray-Datenquelle verbinden, um verteilte Traces zu visualisieren und Leistungsengpässe in Ihrer Inferenzpipeline zu identifizieren. Diese Kombination bietet end-to-end Transparenz von Metriken auf GPU-Ebene bis hin zu Anforderungsabläufen auf Anwendungsebene.

step-by-stepAnleitungen zur Bereitstellung dieses Monitoring-Stacks finden Sie unter Überwachen von GPU-Workloads auf Amazon EKS mithilfe von AWS-verwalteten Open-Source-Services.

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

Überwachen Sie die wichtigsten Trainingsmetriken, um den Zustand und die Leistung Ihres Amazon EKS-Clusters und der darauf ausgeführten Machine-Learning-Workloads zu verfolgen. Trainingsworkloads haben andere Überwachungsanforderungen als Inferenz-Workloads, da sie über längere Zeiträume laufen, Ressourcen unterschiedlich beanspruchen und Einblicke in die Modellkonvergenz und die Effizienz der Datenpipeline erfordern. Die folgenden Kennzahlen helfen Ihnen dabei, Engpässe zu identifizieren, die Ressourcenzuweisung zu optimieren und sicherzustellen, dass Schulungsaufgaben erfolgreich abgeschlossen werden. step-by-stepAnleitungen zur Implementierung dieses Überwachungsansatzes finden Sie unter Einführung in die Beobachtung von Workloads für maschinelles Lernen auf Amazon EKS.

Metriken zur Ressourcennutzung

Überwachen Sie die Kennzahlen zur Ressourcennutzung, um zu überprüfen, ob Ihre Ressourcen ordnungsgemäß genutzt werden. Diese Kennzahlen helfen Ihnen dabei, Engpässe und die Hauptursachen für Leistungsprobleme zu identifizieren.

Modellieren Sie Leistungskennzahlen

Überwachen Sie die Modellleistungskennzahlen, um zu überprüfen, ob Ihr Trainingsprozess Modelle hervorbringt, die den Genauigkeits- und Geschäftsanforderungen entsprechen. Anhand dieser Metriken können Sie feststellen, wann das Training beendet werden muss, Modellversionen vergleichen und Leistungseinbußen feststellen.

Datenqualität und Drift-Metriken

Überwachen Sie die Datenqualität und die Drift-Metriken, um sicherzustellen, dass Ihre Trainingsdaten konsistent und repräsentativ bleiben. Datendrift kann dazu führen, dass sich die Modellleistung im Laufe der Zeit verschlechtert, während Datenqualitätsprobleme verhindern können, dass Modelle konvergieren oder zu unzuverlässigen Ergebnissen führen.

Metriken für Latenz und Durchsatz

Überwachen Sie die Latenz- und Durchsatzkennzahlen, um Engpässe in Ihrer Trainingspipeline zu identifizieren und die Ressourcennutzung zu optimieren. Diese Kennzahlen helfen Ihnen zu verstehen, wo während der Schulung Zeit aufgewendet wird und worauf Sie sich bei der Optimierung konzentrieren sollten.

Fehlerraten und Ausfälle

Überwachen Sie die Fehlerraten und Ausfälle in Ihrer gesamten Schulungspipeline, um die Zuverlässigkeit aufrechtzuerhalten und eine Verschwendung von Rechenressourcen zu verhindern. Unentdeckte Fehler können dazu führen, dass Trainingsaufgaben unbemerkt fehlschlagen, ungültige Modelle produzieren oder Stunden an GPU-Zeit verschwenden, bevor Sie Probleme bemerken.

Spezifische Kennzahlen für Kubernetes und EKS

Überwachen Sie Kubernetes- und EKS-Metriken, um sicherzustellen, dass Ihre Cluster-Infrastruktur funktionsfähig bleibt und Ihre Trainingsworkloads unterstützen kann. Diese Metriken helfen Ihnen dabei, Infrastrukturprobleme zu erkennen, bevor sie zu Fehlschlägen oder Leistungseinbußen bei der Schulung führen.

Anwendungs- und Instanzprotokolle

Sammeln und analysieren Sie Anwendungs- und Instanzprotokolle, um Probleme zu diagnostizieren, die mit Metriken allein nicht erklärt werden können. Protokolle bieten detaillierten Kontext zu Fehlern, Statusänderungen und Systemereignissen, sodass Sie nachvollziehen können, warum Schulungsaufgaben fehlschlagen oder schlecht abschneiden. Durch die Korrelation von Protokollen mit Metriken können Sie die Hauptursachen schneller ermitteln.

In den folgenden Abschnitten wird gezeigt, wie die oben beschriebenen Metriken mithilfe von zwei von AWS empfohlenen Ansätzen erfasst werden: CloudWatch Container Insights und Amazon Managed Prometheus Amazon Managed Prometheus with Amazon Managed Grafana. Wählen Sie CloudWatch Container Insights, wenn Sie AWS-native Tools mit minimalem Einrichtungsaufwand und vorgefertigten Dashboards bevorzugen. Entscheiden Sie sich für Amazon Managed Prometheus mit Amazon Managed Grafana, wenn Sie maßgeschneiderte Dashboards und erweiterte Visualisierungsfunktionen benötigen oder eine Integration in eine bestehende Prometheus basierte Überwachungsinfrastruktur wünschen. Eine vollständige Liste der verfügbaren 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.

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

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-Speicherauslastung 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 verfügbar zu machen: 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.