Osservabilità

Monitoraggio e osservabilità

Obiettivo: un utilizzo elevato della GPU

Il sottoutilizzo GPUs indica che le risorse GPU allocate non vengono sfruttate appieno dai carichi di lavoro, con conseguente spreco di capacità di elaborazione. Per i AI/ML carichi di lavoro su Amazon EKS, consigliamo di monitorare l'utilizzo della GPU per mirare a un utilizzo elevato della GPU e ottimizzare l'efficienza delle risorse. Lo GPUs spreco insufficiente di capacità di elaborazione e aumenta i costi, mentre una pianificazione eccessiva può portare a contese e al degrado delle prestazioni.

Consigliamo di configurare Cloudwatch Container Insights su Amazon EKS per identificare pod, nodi o carichi di lavoro specifici con parametri di utilizzo della GPU ridotti. Si integra facilmente con Amazon EKS e consente di monitorare l'utilizzo della GPU e modificare la pianificazione dei pod o i tipi di istanze se l'utilizzo scende al di sotto dei livelli target. In alternativa, se ciò non soddisfa i tuoi requisiti specifici (ad esempio, visualizzazione avanzata), prendi in considerazione l'utilizzo di DCGM-Exporter di NVIDIA insieme a Prometheus e Grafana per il monitoraggio nativo di Kubernetes. Entrambi gli approcci forniscono informazioni sulle metriche della GPU, consentendoti di modificare la pianificazione dei pod o i tipi di istanze se l'utilizzo scende al di sotto dei livelli target. Controlla i parametri NVIDIA come nvidia_smi_utilization_gpu (utilizzo del calcolo della GPU) e nvidia_smi_utilization_memory (utilizzo della memoria della GPU) tramite DCGM-Exporter o. CloudWatch Cerca le tendenze, ad esempio un utilizzo costantemente ridotto in determinate ore o per lavori specifici.

I limiti statici delle risorse in Kubernetes (ad esempio, il numero di CPU, memoria e GPU) possono portare a un approvvigionamento eccessivo o al sottoutilizzo, in particolare per carichi di lavoro dinamici come l'inferenza. AI/ML Consigliamo di analizzare le tendenze di utilizzo e di consolidare i carichi di lavoro su un numero inferiore di GPU, assicurandosi che ogni GPU sia completamente utilizzata prima di allocarne di nuove. GPUs Se GPUs sono sottoutilizzate, prendete in considerazione le seguenti strategie per ottimizzare la pianificazione e la condivisione. Per ulteriori informazioni, consulta le best practice EKS Compute and Autoscaling per i dettagli.

Osservabilità e metriche

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

AI/ML I servizi moderni operano all'intersezione tra infrastruttura, modellazione e logica delle applicazioni. Gli ingegneri della piattaforma gestiscono l'infrastruttura e lo stack di osservabilità e assicurano che le metriche vengano raccolte, archiviate e visualizzate. AI/ML Gli ingegneri definiscono metriche specifiche del modello e si concentrano sulle prestazioni in condizioni di carico e distribuzione variabili. Gli sviluppatori di applicazioni utilizzano le API, inoltrano le richieste e tengono traccia delle metriche a livello di servizio e delle interazioni con gli utenti. Il successo dipende dalla definizione di pratiche di osservabilità unificate in tutti gli ambienti che offrano a tutte le parti interessate visibilità sullo stato e sulle prestazioni del sistema.

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 spesso si trovano ad affrontare errori out-of-memory (OOM), inefficienze delle risorse e costi inutili. Per i clienti EKS, un monitoraggio efficace garantisce migliori prestazioni, resilienza e costi inferiori. Un approccio olistico che combina il monitoraggio granulare della GPU tramite NVIDIA DCGM Exporter (ad esempio, memoria GPU utilizzata, memoria GPU libera), il monitoraggio e l'ottimizzazione dell'inferenza che serve per informazioni dettagliate sui carichi di lavoro distribuiti con le metriche native utilizzando framework come Ray, VLLM e approfondimenti a livello di applicazione per metriche personalizzate.

Strumenti e framework

Alcuni strumenti e framework offrono out-of-the-box metriche native per il monitoraggio dei AI/ML carichi di lavoro, che consentono un'integrazione più semplice senza ulteriori configurazioni personalizzate. Questi si concentrano su aspetti prestazionali come la latenza, la velocità effettiva e la generazione di token, che sono fondamentali per il servizio di inferenza e il benchmarking. Esempi includono:

• VLLm: un motore di servizio ad alta velocità per modelli linguistici di grandi dimensioni (LLMs) che fornisce metriche native come la latenza delle richieste e l'utilizzo della memoria.

• Ray: un framework di elaborazione distribuito che emette metriche per carichi di lavoro AI scalabili, inclusi i tempi di esecuzione delle attività e l'utilizzo delle risorse.

• Hugging Face Text Generation Inference (TGI): un toolkit per l'implementazione e la distribuzione, con metriche integrate per le prestazioni di inferenza. LLMs

• NVIDIA genai-perf: uno strumento a riga di comando per il benchmarking di modelli di intelligenza artificiale generativa, la misurazione del throughput, della latenza e delle metriche specifiche del LLM, come le richieste completate in intervalli di tempo specifici.

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

Una volta effettuato l'onboarding su Container Insights, rileva CloudWatch automaticamente NVIDIA GPUs nel tuo ambiente, raccoglie i parametri critici di salute e prestazioni di NVIDIA sotto forma di parametri e li rende disponibili su dashboard curate. GPUs CloudWatch out-of-the-box Inoltre, è possibile integrare Ray e VLLm con l'utilizzo di Unified Agent per inviare metriche. CloudWatch CloudWatch Ciò semplifica l'osservabilità negli ambienti EKS, consentendo ai team di concentrarsi sulla regolazione delle prestazioni e sull'ottimizzazione dei costi.

Per ulteriori informazioni, per visualizzare un elenco completo delle metriche disponibili, consulta i parametri di Amazon EKS e Kubernetes Container Insights. Fai riferimento a Ottieni informazioni operative per i carichi di lavoro delle GPU NVIDIA utilizzando Amazon CloudWatch Container Insights e Ottimizzazione della reattività dell'IA: una guida pratica all'inferenza ottimizzata per la latenza di Amazon Bedrock per implementazioni dettagliate.

Prometheus e Grafana gestiti Se la tua organizzazione ha dimestichezza con strumenti open source e dashboard personalizzati, ti consigliamo di implementare Prometheus con NVIDIA DCGM-Exporter e Grafana per il monitoraggio nativo di Kubernetes con visualizzazioni avanzate. Prometheus analizza le metriche e Grafana crea visualizzazioni avanzate.

Inoltre, puoi utilizzare framework open source come Ray e VLLm per esportare i parametri in Prometheus (che può essere visualizzato utilizzando Grafana), oppure puoi connetterti a una fonte di dati AWS X-Ray, quindi creare dashboard per esaminare analisi, approfondimenti o tracce.

Per ulteriori informazioni, consulta Monitoraggio dei carichi di lavoro GPU su Amazon EKS utilizzando i servizi open source gestiti da AWS per un'implementazione dettagliata.

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

Per i parametri di formazione di base per i AI/ML carichi di lavoro su EKS, prendi in considerazione una combinazione di parametri che indicano lo stato e le prestazioni del tuo cluster Amazon EKS e i carichi di lavoro di machine learning in esecuzione su di esso. Per un'implementazione dettagliata, consulta Introduzione all'osservazione dei carichi di lavoro di machine learning su Amazon EKS. Di seguito, analizziamo le metriche che consigliamo di monitorare.

Metriche sull'utilizzo delle risorse:

• Utilizzo di CPU, memoria, GPU e memoria GPU: il monitoraggio di queste metriche per i carichi di lavoro ML consente di garantire che le risorse allocate siano sufficienti e di identificare opportunità di ottimizzazione. Ad esempio, è possibile tracciare metriche come gpu_memory_usage_bytes identificare i modelli di consumo della memoria, rilevare i picchi di utilizzo e calcolare percentili come il 95° percentile (P95) per comprendere le maggiori richieste di memoria durante l'allenamento. Questo aiuta a ottimizzare i modelli e l'infrastruttura per evitare errori di OOM e ridurre i costi.

• Utilizzo delle risorse di nodi e pod: il monitoraggio dell'utilizzo delle risorse a livello di nodo e pod consente di identificare la contesa di risorse e i potenziali colli di bottiglia. Ad esempio, controllate se alcuni nodi sono sovrautilizzati, il che potrebbe influire sulla pianificazione dei pod.

• Confronto tra utilizzo delle risorse e richieste e limiti: consente di capire se il cluster è in grado di gestire i carichi di lavoro attuali e quelli futuri. Ad esempio, confronta l'utilizzo effettivo della memoria con i limiti per evitare out-of-memory errori.

• Metriche interne dei framework ML: acquisisci i parametri di formazione e convergenza interni dai framework ML (TensorFlow, PyTorch), come le curve di perdita, il tasso di apprendimento, il tempo di elaborazione in batch e la durata delle fasi di formazione, spesso visualizzati con o in modo simile. TensorBoard

Metriche delle prestazioni del modello:

• Precisione, precisione, richiamo e punteggio F1: sono fondamentali per comprendere le prestazioni dei modelli ML. Ad esempio, dopo l'allenamento, calcola il punteggio F1 su un set di convalida per valutare le prestazioni.

• Metriche aziendali specifiche e KPIs: definisci e monitora le metriche direttamente collegate al valore aziendale delle tue iniziative. AI/ML Ad esempio, in un sistema di raccomandazioni, monitora l'aumento del coinvolgimento degli utenti.

• Monitoraggio di queste metriche nel tempo: questo aiuta a identificare qualsiasi peggioramento delle prestazioni del modello. Ad esempio, confronta le metriche delle prestazioni tra le diverse versioni del modello per individuare le tendenze.

Metriche sulla qualità dei dati e sulla deriva:

• Proprietà statistiche dei dati di input: monitorali nel tempo per rilevare deviazioni o anomalie dei dati che potrebbero influire sulle prestazioni del modello. Ad esempio, monitora la media delle funzioni di input per rilevare i cambiamenti.

• Rilevamento e avvisi della deriva dei dati: implementa meccanismi per rilevare e avvisare automaticamente sui problemi di qualità dei dati. Ad esempio, utilizzate i test per confrontare i dati correnti con i dati di addestramento e avvisare in caso di deviazioni significative.

Metriche di latenza e velocità effettiva:

• End-to-End Latenza delle pipeline di formazione ML: monitora il tempo impiegato dai dati per fluire attraverso l'intera pipeline di formazione. Ad esempio, misura il tempo totale dall'inserimento dei dati all'aggiornamento del modello.

• Produttività e velocità di elaborazione della formazione: monitora il volume di dati elaborati durante l'allenamento per garantire l'efficienza. Ad esempio, monitora i campioni positivi e negativi elaborati al secondo.

• Checkpoint Restore Latency: monitora il tempo impiegato per caricare in memoria un checkpoint del modello salvato da una posizione di archiviazione (S3, EFS FSx , ecc.) durante la ripresa di un processo, il ripristino da un errore o l'inizializzazione. GPU/CPU Questa metrica influisce direttamente sul tempo di ripristino del processo, sulle prestazioni di avvio a freddo e sull'efficienza complessiva delle pipeline di interferenza. Nei servizi di inferenza con scalabilità automatica, il caricamento lento dei checkpoint può causare ritardi nell'avvio a freddo e una degradazione dell'esperienza utente. Queste metriche correlate vengono comunemente utilizzate anche per migliorare il checkpoint del modello: latenza del downtime dei checkpoint, tempo di deserializzazione del modello, dimensione del checkpoint e numero di errori di ripristino dei checkpoint.

• Durata della richiesta di inferenza: monitora il tempo necessario per completare una richiesta di inferenza. Questo è il tempo che intercorre tra la richiesta iniziale ricevuta e la risposta completata dal modello.

• Token Throughput: monitora il tempo di elaborazione dei token per misurare le prestazioni del modello e ottimizzare le decisioni di scalabilità. L'elaborazione lenta può indicare inefficienze o risorse sottoutilizzate, con un impatto sulla redditività. Il monitoraggio di metriche come i token in entrata al secondo e i token in uscita al secondo, insieme ai tempi di elaborazione, può aiutare a identificare rallentamenti, rallentamenti e fattori di costo nelle prestazioni.

• Identificazione dei punti deboli in termini di prestazioni: utilizza queste metriche per individuare le aree di ottimizzazione del processo di formazione. Ad esempio, analizza il tempo impiegato nel caricamento dei dati rispetto al calcolo del modello.

Tassi di errore e errori:

• Monitoraggio degli errori in tutta la pipeline ML: include la preelaborazione dei dati, l'addestramento dei modelli e l'inferenza. Ad esempio, registrate gli errori di preelaborazione per identificare rapidamente i problemi.

• Identificazione e analisi degli errori ricorrenti: ciò aiuta a mantenere un modello di alta qualità e a garantire prestazioni costanti. Ad esempio, analizza i log per trovare modelli come dati specifici che causano errori.

Metriche specifiche per Kubernetes ed EKS:

• Metriche dello stato del cluster Kubernetes: monitora l'integrità e lo stato di vari oggetti Kubernetes, inclusi pod, nodi e il piano di controllo. Ad esempio, usa strumenti come controllare lo stato dei pod. kubectl

• Success/Failed Pipeline Runs: monitora le esecuzioni della successful/failed pipeline, la durata dei lavori, i tempi di completamento delle fasi e gli errori di orchestrazione (ad esempio, utilizzando gli eventi). Kubeflow/Mlflow/Argo

• AWS Service Metrics: monitora i parametri per altri servizi AWS che supportano la tua infrastruttura EKS e le applicazioni in esecuzione su di essa. Ad esempio, se utilizzi Amazon S3, monitora la dimensione del bucket per tenere traccia dell'utilizzo dello storage.

• Kubernetes Control Plane Metrics: monitora il server API, lo scheduler, il controller manager e il database etcd per rilevare eventuali problemi o guasti di prestazioni. Ad esempio, monitora la latenza delle richieste del server API per verificarne la reattività.

Negli argomenti successivi, illustreremo 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.

Prendi in considerazione il monitoraggio dei parametri 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.

• Time to First Token (TTFT): periodo di tempo che intercorre tra il momento in cui un utente invia una richiesta e la ricezione dell'inizio di una risposta (la prima parola, token o blocco). Ad esempio, nei chatbot, dovresti controllare quanto tempo impiega a generare il primo output (token) dopo che l'utente ha posto una domanda.

• End-to-End Latenza: è il tempo totale che intercorre tra la ricezione di una richiesta e l'invio della risposta. Ad esempio, misura il tempo che intercorre tra la richiesta e la risposta.

• Token di output per secondo (TPS): indica la velocità con cui il modello genera nuovi token dopo aver iniziato a rispondere. Ad esempio, nei chatbot, monitoreresti la velocità di generazione dei modelli linguistici per un testo di base.

• Frequenza di errore: tiene traccia delle richieste non riuscite, il che può indicare problemi di prestazioni. Ad esempio, monitora le richieste non riuscite per documenti di grandi dimensioni o determinati caratteri.

• Throughput: misura il numero di richieste o operazioni che il sistema è in grado di gestire per unità di tempo. Ad esempio, tieni traccia delle richieste al secondo per gestire i carichi di picco.

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

• hit/miss Rapporto di cache: per le configurazioni di inferenza che sfruttano la memorizzazione nella cache (K/V o cache incorporate), misura la frequenza con cui la cache è utile. Le basse percentuali di successo possono indicare che la configurazione della cache o le modifiche del carico di lavoro non sono ottimali, entrambi fattori che possono aumentare la latenza.

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.