Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Osservabilità

Monitoraggio e osservabilità

Spiegazione delle metriche della GPU

La metrica sull'utilizzo della GPU mostra se la GPU ha funzionato correttamente durante la finestra di esempio. Questa metrica rileva la percentuale di tempo in cui la GPU ha eseguito almeno un'istruzione, ma non rivela l'efficienza con cui la GPU ha utilizzato il proprio hardware. Una GPU contiene più Streaming Multiprocessor (SMs), che sono le unità di elaborazione parallele che eseguono le istruzioni. Una lettura dell'utilizzo al 100% può significare che la GPU ha eseguito pesanti carichi di lavoro paralleli su tutte le sue unità SMs, oppure può significare che una singola piccola istruzione ha attivato la GPU durante il periodo di campionamento. Per comprendere l'utilizzo effettivo, è necessario esaminare le metriche della GPU a più livelli dell'architettura hardware. Ogni Streaming Multiprocessor è costruito con diversi tipi di core e ogni livello presenta caratteristiche prestazionali diverse. Le metriche di primo livello (utilizzo della GPU, utilizzo della memoria, potenza della GPU e temperatura della GPU, visibili tramite nvidia-smi) mostrano se il dispositivo è attivo. Metriche più approfondite (utilizzo di SM, SM Activity e utilizzo del tensor core) rivelano l'efficienza con cui la GPU utilizza le sue risorse.

Obiettivi a un elevato consumo energetico della GPU

Il sottoutilizzo GPUs spreca la capacità di elaborazione e aumenta i costi perché i carichi di lavoro non riescono a coinvolgere tutti i componenti della GPU contemporaneamente. Per i AI/ML carichi di lavoro su Amazon EKS, monitora il consumo energetico della GPU come proxy per identificare l'attività effettiva della GPU. GPU Utilization riporta la percentuale di tempo in cui la GPU esegue qualsiasi kernel, ma non rivela se i multiprocessori di streaming, i controller di memoria e i tensor core siano tutti attivi contemporaneamente. Il consumo energetico colma questa lacuna, perché l'hardware completamente impegnato consuma molta più energia rispetto all'hardware che esegue kernel leggeri o rimane inattivo tra un'attività e l'altra. Confrontate l'energia assorbita con la potenza di progettazione termica (TDP) della GPU per individuare il sottoutilizzo, quindi verificate se il carico di lavoro è ostacolato dalla preelaborazione della CPU, dall'I/O di rete o dalle dimensioni inefficienti dei batch.

CloudWatch Configura Container Insights su Amazon EKS per identificare pod, nodi o carichi di lavoro con un basso consumo energetico della GPU. Questo strumento si integra direttamente con Amazon EKS e consente di monitorare il consumo energetico della GPU e di regolare la pianificazione dei pod o i tipi di istanze quando il consumo energetico scende al di sotto dei livelli target. Se hai bisogno di una visualizzazione avanzata o di dashboard personalizzate, usa DCGM-Exporter di NVIDIA con Prometheus e Grafana per il monitoraggio nativo di Kubernetes. Entrambi gli approcci evidenziano metriche chiave di NVIDIA come (consumo energetico della GPU) e (temperatura della GPU). nvidia_smi_power_draw nvidia_smi_temperature_gpu Per un elenco di metriche, consulta -Agent-NVIDIA-GPU.htm. https://docs.aws.amazon.com/AmazonCloudWatch/ latest/monitoring/CloudWatch Cerca modelli come un consumo energetico costantemente basso in orari specifici o per lavori particolari. Queste tendenze ti aiutano a identificare dove consolidare i carichi di lavoro o modificare l'allocazione delle risorse.

I limiti statici delle risorse in Kubernetes (come il numero di CPU, memoria e GPU) spesso portano a un approvvigionamento eccessivo o al sottoutilizzo, specialmente per carichi di lavoro dinamici come l'inferenza in cui la domanda oscilla. AI/ML Analizza le tendenze di utilizzo e consolida i carichi di lavoro riducendoli al minimo. GPUs Assicurati che ogni GPU raggiunga il pieno utilizzo prima di allocarne altre. Questo approccio riduce gli sprechi e abbassa i costi. Per una guida dettagliata sull'ottimizzazione della pianificazione e delle strategie di condivisione, consulta le best practice EKS Compute and Autoscaling

Osservabilità e metriche

Utilizzo di strumenti di monitoraggio e osservabilità per i carichi di lavoro AI/ML

AI/ML I servizi moderni richiedono il coordinamento tra infrastruttura, modellazione e logica applicativa. Gli ingegneri della piattaforma gestiscono l'infrastruttura e lo stack di osservabilità. Raccolgono, archiviano e visualizzano le metriche. AI/ML gli ingegneri definiscono metriche specifiche del modello e monitorano le prestazioni in condizioni di carico e distribuzione dei dati variabili. Gli sviluppatori di applicazioni utilizzano APIs, indirizzano le richieste e tengono traccia delle metriche a livello di servizio e delle interazioni con gli utenti. Senza pratiche di osservabilità unificate, questi team lavorano in silos e perdono segnali critici sullo stato e le prestazioni del sistema. La creazione di una visibilità condivisa tra gli ambienti garantisce che tutte le parti interessate possano rilevare tempestivamente i problemi e mantenere un servizio affidabile.

L'ottimizzazione dei cluster Amazon EKS per i AI/ML carichi di lavoro presenta sfide di monitoraggio uniche, in particolare per quanto riguarda la gestione della memoria GPU. Senza un monitoraggio adeguato, le organizzazioni devono affrontare errori out-of-memory (OOM), inefficienze delle risorse e costi inutili. Un monitoraggio efficace garantisce migliori prestazioni, resilienza e costi inferiori per i clienti EKS. Utilizza un approccio olistico che combini tre livelli di monitoraggio. Innanzitutto, monitora le metriche granulari della GPU utilizzando NVIDIA DCGM Exporter per tenere traccia del consumo energetico della GPU, della temperatura della GPU, dell'attività SM, dell'occupazione SM e degli errori XID. In secondo luogo, monitora framework che servono l'inferenza come Ray e vLLm per ottenere informazioni sui carichi di lavoro distribuiti attraverso le loro metriche native. In terzo luogo, raccogli informazioni a livello di applicazione per tracciare metriche personalizzate specifiche per il tuo carico di lavoro. Questo approccio a più livelli offre visibilità dall'utilizzo dell'hardware alle prestazioni delle applicazioni.

Strumenti e framework

Diversi strumenti e framework forniscono out-of-the-box metriche native per il monitoraggio dei carichi di lavoro. AI/ML Queste metriche integrate eliminano la necessità di strumentazione personalizzata e riducono i tempi di configurazione. Le metriche si concentrano su aspetti prestazionali come latenza, velocità effettiva e generazione di token, che sono fondamentali per il servizio di inferenza e il benchmarking. L'utilizzo di metriche native consente di iniziare il monitoraggio immediatamente senza creare pipeline di raccolta personalizzate.

Metodi di osservabilità

Si consiglia di implementare eventuali meccanismi di osservabilità aggiuntivi in uno dei seguenti modi.

CloudWatch Container Insights Se la tua organizzazione preferisce strumenti nativi di AWS con una configurazione minima, ti consigliamo CloudWatch Container Insights. Si integra con NVIDIA DCGM Exporter per raccogliere i parametri della GPU e offre dashboard predefinite per informazioni rapide. Abilitato dall'installazione del componente aggiuntivo CloudWatch Observability sul cluster, Container Insights implementa e gestisce il ciclo di vita di NVIDIA DCGM Exporter, che raccoglie le metriche della GPU dai driver di Nvidia e le espone a. CloudWatch

Dopo aver installato Container Insights, rileva automaticamente NVIDIA nel tuo ambiente e raccoglie metriche critiche su salute e CloudWatch prestazioni. GPUs Queste metriche vengono visualizzate su dashboard curate. out-of-the-box Puoi anche integrare Ray e VLLm CloudWatch utilizzando l'Unified CloudWatch Agent per inviare le relative metriche native. Questo approccio unificato semplifica l'osservabilità negli ambienti EKS e consente ai team di concentrarsi sull'ottimizzazione delle prestazioni e dei costi anziché sulla creazione di un'infrastruttura di monitoraggio.

Per un elenco completo delle metriche disponibili, consulta le metriche di Amazon EKS e Kubernetes Container Insights. Per step-by-step indicazioni sull'implementazione del monitoraggio della GPU, consulta Ottieni informazioni operative per i carichi di lavoro delle GPU NVIDIA utilizzando Amazon CloudWatch Container Insights. Per esempi pratici di ottimizzazione della latenza di inferenza, consulta Ottimizzazione della reattività dell'IA: una guida pratica all'inferenza ottimizzata per la latenza di Amazon Bedrock.

Prometheus e Grafana gestiti Se la tua organizzazione ha bisogno di dashboard personalizzati e funzionalità di visualizzazione avanzate, implementa Prometheus con NVIDIA DCGM-Exporter e Grafana per il monitoraggio nativo di Kubernetes. Prometheus acquisisce e archivia le metriche della GPU da DCGM-Exporter, mentre Grafana offre funzionalità flessibili di visualizzazione e avviso. Questo approccio offre un maggiore controllo sulla progettazione delle dashboard e sulla conservazione delle metriche rispetto a Container Insights. CloudWatch

Puoi estendere questo stack di monitoraggio integrando framework open source come Ray e VLLm Ray e vLLm per esportare le loro metriche native su Prometheus. Puoi anche connettere Grafana a una fonte di dati AWS X-Ray per visualizzare tracce distribuite e identificare i colli di bottiglia prestazionali nella pipeline di inferenza. Questa combinazione offre end-to-end visibilità dalle metriche a livello di GPU attraverso i flussi di richiesta a livello di applicazione.

Per step-by-step indicazioni sulla distribuzione di questo stack di monitoraggio, consulta Monitoraggio dei carichi di lavoro GPU su Amazon EKS utilizzando i servizi open source gestiti da AWS.

Prendi in considerazione il monitoraggio della formazione di base e le metriche di ottimizzazione

Monitora i parametri di formazione di base per monitorare lo stato e le prestazioni del tuo cluster Amazon EKS e dei carichi di lavoro di machine learning in esecuzione su di esso. I carichi di lavoro di formazione hanno requisiti di monitoraggio diversi rispetto ai carichi di lavoro di inferenza perché vengono eseguiti per periodi prolungati, consumano risorse in modo diverso e richiedono visibilità sulla convergenza dei modelli e sull'efficienza della pipeline di dati. Le metriche riportate di seguito consentono di identificare i punti critici, ottimizzare l'allocazione delle risorse e garantire il corretto completamento dei lavori di formazione. Per step-by-step indicazioni sull'implementazione di questo approccio di monitoraggio, consulta Introduzione all'osservazione dei carichi di lavoro di machine learning su Amazon EKS.

Metriche sull'utilizzo delle risorse

Monitora le metriche sull'utilizzo delle risorse per verificare che le risorse vengano consumate correttamente. Queste metriche consentono di identificare i punti deboli e le cause principali dei problemi di prestazioni.

Metriche delle prestazioni del modello

Monitora le metriche delle prestazioni dei modelli per verificare che il processo di formazione produca modelli che soddisfano i requisiti di precisione e aziendali. Queste metriche consentono di determinare quando interrompere l'allenamento, confrontare le versioni dei modelli e identificare il degrado delle prestazioni.

Metriche sulla qualità dei dati e sulla deriva

Monitora la qualità dei dati e le metriche sulla deriva per garantire che i dati di allenamento rimangano coerenti e rappresentativi. La deriva dei dati può causare un peggioramento delle prestazioni del modello nel tempo, mentre i problemi di qualità dei dati possono impedire la convergenza dei modelli o produrre risultati inaffidabili.

Metriche di latenza e velocità effettiva

Monitora le metriche di latenza e velocità effettiva per identificare i punti deboli nella pipeline di formazione e ottimizzare l'utilizzo delle risorse. Queste metriche aiutano a capire dove viene impiegato il tempo durante la formazione e dove concentrare gli sforzi di ottimizzazione.

Tassi di errore e fallimenti

Monitora i tassi di errore e gli errori in tutta la pipeline di formazione per mantenere l'affidabilità e prevenire lo spreco di risorse di elaborazione. Gli errori non rilevati possono causare l'interruzione automatica dei processi di formazione, la produzione di modelli non validi o la perdita di ore di tempo della GPU prima che si notino problemi.

Metriche specifiche per Kubernetes ed EKS

Monitora le metriche di Kubernetes ed EKS per garantire che l'infrastruttura del cluster rimanga integra e possa supportare i carichi di lavoro di formazione. Queste metriche ti aiutano a rilevare i problemi dell'infrastruttura prima che causino errori di formazione o un peggioramento delle prestazioni.

Registri di applicazioni e istanze

Raccogli e analizza i log delle applicazioni e delle istanze per diagnosticare problemi che le sole metriche non sono in grado di spiegare. I log forniscono un contesto dettagliato su errori, cambiamenti di stato ed eventi di sistema che aiutano a capire perché i processi di formazione falliscono o funzionano male. La correlazione dei log con le metriche consente di individuare più rapidamente le cause alla radice.

Le seguenti sezioni mostrano come raccogliere le metriche sopra descritte utilizzando due approcci consigliati da AWS: CloudWatch Container Insights e Amazon Managed Prometheus Amazon Managed Prometheus con Amazon Managed Grafana. Scegli CloudWatch Container Insights se preferisci gli strumenti nativi di AWS con configurazione minima e dashboard predefiniti. Scegli Amazon Managed Prometheus con Amazon Managed Grafana se hai bisogno di dashboard personalizzati, funzionalità di visualizzazione avanzate o desideri integrarti con l'infrastruttura di monitoraggio esistente basata su Prometheus. Per un elenco completo delle metriche di Container Insights disponibili, consulta le metriche di Amazon EKS e Kubernetes Container Insights.

Prendi in considerazione il monitoraggio delle metriche di inferenza online in tempo reale

Nei sistemi in tempo reale, la bassa latenza è fondamentale per fornire risposte tempestive agli utenti o ad altri sistemi dipendenti. L'elevata latenza può compromettere l'esperienza utente o violare i requisiti prestazionali. I componenti che influenzano la latenza di inferenza includono il tempo di caricamento del modello, il tempo di preelaborazione, il tempo di previsione effettivo, il tempo di post-elaborazione, il tempo di trasmissione di rete. Consigliamo di monitorare la latenza di inferenza per garantire risposte a bassa latenza che soddisfino gli accordi sui livelli di servizio () e di sviluppare metriche personalizzate per quanto segue. SLAs Esegui il test in base al carico previsto, includi la latenza di rete, tieni conto delle richieste simultanee ed esegui il test con batch di dimensioni variabili.

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/Vo una sessione (uso della cache):

Negli argomenti successivi, dimostreremo la raccolta di dati per alcune delle metriche sopra menzionate. Forniremo esempi dei due approcci consigliati da AWS: AWS-Native CloudWatch Container Insights e Amazon Managed Prometheus open source con Amazon Managed Grafana. Sceglieresti una di queste soluzioni in base alle tue esigenze complessive di osservabilità. Consulta i parametri di Amazon EKS e Kubernetes Container Insights per l'elenco completo dei parametri di Container Insights.

Monitoraggio dell'utilizzo della memoria della GPU

Come discusso nell'Prendi in considerazione il monitoraggio della formazione di base e le metriche di ottimizzazioneargomento, l'utilizzo della memoria GPU è essenziale per prevenire errori out-of-memory (OOM) e garantire un utilizzo efficiente delle risorse. Gli esempi seguenti mostrano come utilizzare l'applicazione di formazione per esporre un istogramma metrico personalizzato e calcolare l'utilizzo della memoria P95 per identificare i picchi di consumo. gpu_memory_usage_bytes Assicuratevi di eseguire il test con un esempio di lavoro di formazione (ad esempio, la messa a punto di un modello di trasformatore) in un ambiente di staging.

Esempio di AWS-Native CloudWatch Container Insights

Questo esempio dimostra come strumentare l'applicazione di formazione per esporla gpu_memory_usage_bytes come istogramma utilizzando l'approccio nativo di AWS. Tieni presente che il AI/ML contenitore deve essere configurato per emettere log strutturati in formato CloudWatch Embedded Metrics Format (EMF). CloudWatch logs analizza EMF e pubblica le metriche. Usa aws_embedded_metrics nella tua applicazione di formazione per inviare log strutturati in formato EMF a Logs, che estrae le metriche della 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()

Esempio di Prometheus e Grafana

Questo esempio dimostra come strumentare l'applicazione di formazione per esporla gpu_memory_usage_bytes` come istogramma utilizzando la libreria client Prometheus in 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()

Tieni traccia della durata della richiesta di inferenza per l'inferenza online in tempo reale

Come discusso nell'Prendi in considerazione il monitoraggio della formazione di base e le metriche di ottimizzazioneargomento, la bassa latenza è fondamentale per fornire risposte tempestive agli utenti o ad altri sistemi dipendenti. Gli esempi seguenti mostrano come tenere traccia di una metrica istogramma personalizzatainference_request_duration_seconds, esposta dall'applicazione di inferenza. Calcola la latenza del 95° percentile (P95) per concentrarti sugli scenari peggiori, esegui test con richieste di inferenza sintetica (ad esempio, tramite Locust) in un ambiente di staging e imposta soglie di avviso (ad esempio, >500 ms) per rilevare le violazioni degli SLA.

Esempio di AWS-Native CloudWatch Container Insights

Questo esempio dimostra come creare una metrica di istogramma personalizzata nella tua applicazione di inferenza per inference_request_duration_seconds utilizzando AWS Embedded Metric Format. 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()

Esempio di Prometheus e Grafana

Questo esempio dimostra come creare una metrica istogramma personalizzata nell'applicazione di inferenza per inference_request_duration_seconds utilizzando la libreria client Prometheus in 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)

In Grafana, usa la query histogram_quantile(0.95, sum(rate(inference_request_duration_seconds_bucket[5m])) by (le, pod)) per visualizzare le tendenze di latenza P95. Per ulteriori informazioni, vedere Prometheus Histogram Documentation e Prometheus Client Documentation.

Tieni traccia del throughput dei token per un'inferenza online in tempo reale

Come discusso nell'Prendi in considerazione il monitoraggio della formazione di base e le metriche di ottimizzazioneargomento, consigliamo di monitorare il tempo di elaborazione dei token per valutare le prestazioni del modello e ottimizzare le decisioni di scalabilità. Gli esempi seguenti mostrano come tenere traccia di una metrica istogramma personalizzatatoken_processing_duration_seconds, esposta dall'applicazione di inferenza. Calcola la durata del 95° percentile (P95) per analizzare l'efficienza di elaborazione, eseguire test con carichi di richieste simulati (ad esempio, da 100 a 1000 richieste/secondo) in un cluster non di produzione e regolare i trigger KEDA per ottimizzare la scalabilità.

Esempio di AWS-Native CloudWatch Container Insights

Questo esempio dimostra come creare una metrica di istogramma personalizzata nella tua applicazione di inferenza per token_processing_duration_seconds utilizzando AWS Embedded Metric Format. CloudWatch Utilizza le dimensioni (funzione ) with a custom `get_duration_bucket `set_dimension) per classificare le durate in intervalli (ad esempio, «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

Esempio di Prometheus e Grafana

Questo esempio dimostra come creare una metrica istogramma personalizzata nell'applicazione di inferenza per token_processing_duration_seconds utilizzando la libreria client Prometheus in 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)

In Grafana, usa la query histogram_quantile(0.95, sum(rate(token_processing_duration_seconds_bucket[5m])) by (le, pod))` per visualizzare le tendenze dei tempi di elaborazione P95. Per ulteriori informazioni, vedere Prometheus Histogram Documentation e Prometheus Client Documentation.

Misura la latenza di Checkpoint Restore

Come discusso nell'Prendi in considerazione il monitoraggio della formazione di base e le metriche di ottimizzazioneargomento, la latenza dei checkpoint è una metrica fondamentale durante più fasi del ciclo di vita del modello. Gli esempi seguenti mostrano come tenere traccia di una metrica istogramma personalizzata, esposta dall'applicazione. checkpoint_restore_duration_seconds` Calcola la durata del 95° percentile (P95) per monitorare le prestazioni di ripristino, eseguire test con interruzioni Spot in un cluster non di produzione e impostare soglie di avviso (ad esempio, <30 secondi) per rilevare i ritardi.

Esempio di AWS-Native CloudWatch Container Insights

Questo esempio dimostra come utilizzare l'applicazione batch per esporre checkpoint_restore_duration_seconds come istogramma utilizzando 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")

Esempio di Prometheus e Grafana

Questo esempio dimostra come strumentare l'applicazione batch per esporla checkpoint_restore_duration_seconds come istogramma utilizzando la libreria client Prometheus in 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"))

In Grafana, usa la query histogram_quantile(0.95, sum(rate(checkpoint_restore_duration_seconds_bucket[5m]) by (le)) per visualizzare le tendenze della latenza di ripristino P95. Per ulteriori informazioni, vedere Prometheus Histogram Documentation e Prometheus Client Documentation.