Monitoramento e observabilidade Observabilidade e métricas

Observabilidade

Monitoramento e observabilidade

Almeje a alta utilização da GPU

A subutilização GPUs indica que os recursos de GPU alocados não estão sendo totalmente aproveitados pelas cargas de trabalho, levando ao desperdício de capacidade computacional. Para AI/ML cargas de trabalho no Amazon EKS, recomendamos monitorar a utilização da GPU para atingir o alto uso da GPU e otimizar a eficiência dos recursos. A subutilização GPUs desperdiça a capacidade computacional e aumenta os custos, enquanto o excesso de agendamento pode levar à contenção e à degradação do desempenho.

Recomendamos configurar o Cloudwatch Container Insights no Amazon EKS para identificar pods, nós ou cargas de trabalho específicos com baixas métricas de utilização da GPU. Ele é facilmente integrado ao Amazon EKS, permitindo que você monitore a utilização da GPU e ajuste o agendamento de pods ou os tipos de instância se a utilização estiver abaixo dos níveis desejados. Como alternativa, se isso não atender aos seus requisitos específicos (por exemplo, visualização avançada), considere usar o DCGM-Exporter da NVIDIA junto com o Prometheus e o Grafana para monitoramento nativo do Kubernetes. Ambas as abordagens fornecem informações sobre as métricas da GPU, permitindo que você ajuste o agendamento de pods ou os tipos de instância se a utilização estiver abaixo dos níveis desejados. Verifique as métricas da NVIDIA como nvidia_smi_utilization_gpu (uso de computação de GPU) e nvidia_smi_utilization_memory (uso de memória de GPU) via DCGM-Exporter ou. CloudWatch Procure tendências, como baixa utilização consistente durante determinadas horas ou para trabalhos específicos.

Limites estáticos de recursos no Kubernetes (por exemplo, contagem de CPU, memória e GPU) podem levar ao provisionamento excessivo ou à subutilização, especialmente para cargas de trabalho dinâmicas, como inferência. AI/ML Recomendamos analisar as tendências de utilização e consolidar cargas de trabalho em menos GPUs, garantindo que cada GPU seja totalmente utilizada antes de alocar novas. Se GPUs estiverem subutilizados, considere as estratégias a seguir para otimizar o agendamento e o compartilhamento. Para saber mais, consulte as melhores práticas de computação e escalonamento automático do EKS para obter detalhes.

Observabilidade e métricas

Usando ferramentas de monitoramento e observabilidade para suas cargas de trabalho AI/ML

Os AI/ML serviços modernos operam na interseção da infraestrutura, da modelagem e da lógica do aplicativo. Os engenheiros da plataforma gerenciam a infraestrutura, a pilha de observabilidade e garantem que as métricas sejam coletadas, armazenadas e visualizadas. AI/ML Os engenheiros definem métricas específicas do modelo e se concentram no desempenho sob cargas e distribuições variáveis. Os desenvolvedores de aplicativos consomem API, roteiam solicitações e rastreiam métricas de nível de serviço e interações do usuário. O sucesso depende do estabelecimento de práticas unificadas de observabilidade em todos os ambientes que dêem a todas as partes interessadas visibilidade sobre a integridade e o desempenho do sistema.

A otimização de clusters do Amazon EKS para AI/ML cargas de trabalho apresenta desafios de monitoramento exclusivos, especialmente em relação ao gerenciamento de memória de GPU. Sem o monitoramento adequado, as organizações geralmente enfrentam erros out-of-memory (OOM), ineficiências de recursos e custos desnecessários. Para os clientes da EKS, o monitoramento eficaz garante melhor desempenho, resiliência e custos mais baixos. Uma abordagem holística que combina monitoramento granular de GPU usando o NVIDIA DCGM Exporter (por exemplo, memória de GPU usada, memória de GPU livre), monitoramento e otimização de serviços de inferência para insights de carga de trabalho distribuídos com suas métricas nativas usando estruturas como Ray, vLLM e insights em nível de aplicativo para métricas personalizadas.

Ferramentas e estruturas

Certas ferramentas e estruturas oferecem out-of-the-box métricas nativas para monitorar AI/ML cargas de trabalho, facilitando a integração sem configuração personalizada adicional. Eles se concentram em aspectos de desempenho, como latência, taxa de transferência e geração de tokens, que são essenciais para serviços de inferência e benchmarking. Os exemplos incluem:

vLLM: um mecanismo de atendimento de alto rendimento para modelos de linguagem grandes (LLMs) que fornece métricas nativas, como latência de solicitações e uso de memória.
Ray: uma estrutura de computação distribuída que emite métricas para cargas de trabalho de IA escaláveis, incluindo tempos de execução de tarefas e utilização de recursos.
Hugging Face Text Generation Inference (TGI): um kit de ferramentas para implantação e exibição LLMs, com métricas integradas para desempenho de inferência.
NVIDIA genai-perf: uma ferramenta de linha de comando para comparar modelos generativos de IA, medir a taxa de transferência, a latência e as métricas específicas do LLM, como solicitações concluídas em intervalos de tempo específicos.

Métodos de observabilidade

Recomendamos implementar quaisquer mecanismos adicionais de observabilidade de uma das seguintes formas.

CloudWatch Container Insights Se sua organização prefere ferramentas nativas da AWS com configuração mínima, recomendamos CloudWatch o Container Insights. Ele se integra ao NVIDIA DCGM Exporter para coletar métricas de GPU e oferece painéis pré-construídos para insights rápidos. Habilitado pela instalação do complemento CloudWatch Observability em seu cluster, o Container Insights implanta e gerencia o ciclo de vida do NVIDIA DCGM Exporter, que coleta métricas de GPU dos drivers da Nvidia e as expõe a. CloudWatch

Uma vez integrado ao Container Insights, detecta CloudWatch automaticamente a NVIDIA GPUs em seu ambiente, coleta as métricas críticas de saúde e desempenho de sua NVIDIA GPUs como CloudWatch métricas e as disponibiliza em painéis selecionados. out-of-the-box Além disso, o Ray e o vLLM podem ser integrados ao CloudWatch uso do Unified CloudWatch Agent para enviar métricas. Isso simplifica a observabilidade em ambientes EKS, permitindo que as equipes se concentrem no ajuste do desempenho e na otimização de custos.

Para obter mais informações, para ver uma lista completa das métricas disponíveis, consulte as métricas do Amazon EKS e do Kubernetes Container Insights. Consulte Obtenha insights operacionais para cargas de trabalho de GPU NVIDIA usando o Amazon CloudWatch Container Insights e Otimizando a capacidade de resposta da IA: um guia prático para inferência otimizada para latência do Amazon Bedrock para implementações detalhadas.

Prometheus e Grafana gerenciados Se sua organização se sente confortável com ferramentas de código aberto e painéis personalizados, recomendamos implantar o Prometheus com o NVIDIA DCGM-Exporter e o Grafana para monitoramento nativo do Kubernetes com visualizações avançadas. O Prometheus coleta métricas e o Grafana cria visualizações avançadas.

Além disso, você pode usar estruturas de código aberto como Ray e vLLM para exportar métricas para o Prometheus (que podem ser visualizadas usando o Grafana), ou você pode se conectar a uma fonte de dados do AWS X-Ray e criar painéis para analisar análises, insights ou rastreamentos.

Para obter mais informações, consulte Monitoramento de cargas de trabalho de GPU no Amazon EKS usando serviços de código aberto gerenciados pela AWS para obter uma implementação detalhada.

Considere monitorar o treinamento básico e as métricas de ajuste fino

Para as principais métricas de treinamento para AI/ML cargas de trabalho no EKS, considere uma combinação de métricas que indiquem a integridade e o desempenho do seu cluster Amazon EKS e das cargas de trabalho de aprendizado de máquina em execução nele. Consulte Introdução à observação de cargas de trabalho de aprendizado de máquina no Amazon EKS para obter uma implementação detalhada. Abaixo, detalhamos as métricas que recomendamos monitorar.

Métricas de uso de recursos:

Uso de CPU, memória, GPU e GPU — O monitoramento dessas métricas para cargas de trabalho de ML permite garantir que os recursos alocados sejam suficientes e identifique oportunidades de otimização. Por exemplo, rastreie métricas como gpu_memory_usage_bytes identificar padrões de consumo de memória, detectar picos de uso e calcular percentis, como o 95º percentil (P95), para entender as maiores demandas de memória durante o treinamento. Isso ajuda a otimizar seus modelos e infraestrutura para evitar erros de OOM e reduzir custos.
Utilização de recursos de nós e pods — O rastreamento do uso de recursos no nível do nó e do pod ajuda a identificar a contenção de recursos e possíveis gargalos. Por exemplo, verifique se algum nó está sendo usado em excesso, o que pode afetar o agendamento do pod.
Comparação da utilização de recursos com solicitações e limites — Isso fornece uma visão sobre se seu cluster pode lidar com cargas de trabalho atuais e acomodar cargas de trabalho futuras. Por exemplo, compare o uso real da memória com os limites para evitar out-of-memory erros.
Métricas internas de estruturas de ML — Capture métricas internas de treinamento e convergência de estruturas de ML (TensorFlow, PyTorch), como curvas de perda, taxa de aprendizado, tempo de processamento em lote e duração da etapa de treinamento, geralmente visualizadas com ou similares. TensorBoard

Métricas de desempenho do modelo:

Exatidão, precisão, recall e pontuação F1 — são vitais para entender o desempenho de seus modelos de ML. Por exemplo, após o treinamento, calcule a pontuação F1 em um conjunto de validação para avaliar o desempenho.
Métricas específicas do negócio e KPIs — Defina e acompanhe métricas diretamente vinculadas ao valor comercial de suas AI/ML iniciativas. Por exemplo, em um sistema de recomendação, acompanhe o aumento do engajamento do usuário.
Acompanhar essas métricas ao longo do tempo — Isso ajuda a identificar qualquer degradação no desempenho do modelo. Por exemplo, compare as métricas de desempenho entre as versões do modelo para identificar tendências.

Métricas de qualidade e variação de dados:

Propriedades estatísticas dos dados de entrada — monitore-os ao longo do tempo para detectar desvios de dados ou anomalias que possam afetar o desempenho do modelo. Por exemplo, acompanhe a média dos recursos de entrada para detectar mudanças.
Detecção e alertas de desvios de dados — implemente mecanismos para detectar e alertar automaticamente sobre problemas de qualidade de dados. Por exemplo, use testes para comparar dados atuais com dados de treinamento e alertar sobre desvios significativos.

Métricas de latência e taxa de transferência:

End-to-End Latência dos canais de treinamento de ML — monitore o tempo necessário para que os dados fluam por todo o pipeline de treinamento. Por exemplo, meça o tempo total desde a ingestão de dados até a atualização do modelo.
Rendimento e taxa de processamento do treinamento — Acompanhe o volume de dados processados durante o treinamento para garantir a eficiência. Por exemplo, monitore amostras positivas e negativas processadas por segundo.
Latência de restauração do ponto de verificação — Monitore o tempo necessário para carregar um ponto de verificação do modelo salvo de um local de armazenamento (S3 FSx , EFS etc.) de volta GPU/CPU à memória ao retomar um trabalho, recuperar-se de uma falha ou inicializar. Essa métrica afeta diretamente o tempo de recuperação do trabalho, o desempenho da inicialização a frio e a eficiência geral dos pipelines de interferência. Em serviços de inferência com escalonamento automático, o carregamento lento do ponto de verificação pode causar atrasos na inicialização a frio e degradar a experiência do usuário. Essas métricas relacionadas também são comumente usadas para melhorar o ponto de verificação do modelo: latência do tempo de inatividade do ponto de verificação, tempo de desserialização do modelo, tamanho do ponto de verificação e contagem de falhas na restauração do ponto de verificação.
Duração da solicitação de inferência — monitore o tempo necessário para concluir uma solicitação de inferência. Esse é o tempo entre a solicitação inicial recebida e a resposta completa do modelo.
Taxa de transferência de tokens - monitore o tempo de processamento de tokens para avaliar o desempenho do modelo e otimizar as decisões de escalabilidade. O processamento lento pode indicar ineficiências ou recursos subutilizados, afetando a relação custo-benefício. O rastreamento de métricas como tokens de entrada por segundo e saída de tokens por segundo, juntamente com o tempo de processamento, pode ajudar a identificar gargalos de desempenho, lentidão e fatores de custo.
Identificação de gargalos de desempenho — Use essas métricas para identificar áreas de otimização no processo de treinamento. Por exemplo, analise o tempo gasto no carregamento de dados versus computação do modelo.

Taxas de erro e falhas:

Monitoramento de erros em todo o pipeline de ML — Isso inclui pré-processamento de dados, treinamento de modelos e inferência. Por exemplo, registre erros no pré-processamento para identificar problemas rapidamente.
Identificação e investigação de erros recorrentes — Isso ajuda a manter um modelo de alta qualidade e a garantir um desempenho consistente. Por exemplo, analise os registros para encontrar padrões, como dados específicos que causam falhas.

Métricas específicas do Kubernetes e do EKS:

Métricas de estado do cluster do Kubernetes — monitore a integridade e o status de vários objetos do Kubernetes, incluindo pods, nós e o plano de controle. Por exemplo, use ferramentas como kubectl verificar o status do pod.
Execuções bem-sucedidas ou malsucedidas do pipeline — Acompanhe as execuções do successful/failed pipeline, as durações dos trabalhos, os tempos de conclusão das etapas e os erros de orquestração (por exemplo, usando Kubeflow/Mlflow/Argo eventos).
Métricas de serviço da AWS — Acompanhe métricas de outros serviços da AWS que suportam sua infraestrutura EKS e os aplicativos executados nela. Por exemplo, se estiver usando o Amazon S3, monitore o tamanho do bucket para rastrear o uso do armazenamento.
Métricas do plano de controle do Kubernetes — monitore o servidor da API, o agendador, o gerenciador do controlador e o banco de dados etcd em busca de problemas ou falhas de desempenho. Por exemplo, monitore a latência da solicitação do servidor de API para aumentar a capacidade de resposta.

Nos tópicos subsequentes, demonstraremos a coleta de dados para algumas das métricas mencionadas acima. Forneceremos exemplos com as duas abordagens recomendadas pela AWS: CloudWatch Container Insights nativo da AWS e Amazon Managed Prometheus de código aberto com Amazon Managed Grafana. Você escolheria uma dessas soluções com base em suas necessidades gerais de observabilidade. Consulte as métricas do Amazon EKS e do Kubernetes Container Insights para obter a lista completa das métricas do Container Insights.

Considere monitorar métricas de inferência on-line em tempo real

Em sistemas em tempo real, a baixa latência é fundamental para fornecer respostas oportunas aos usuários ou outros sistemas dependentes. A alta latência pode degradar a experiência do usuário ou violar os requisitos de desempenho. Os componentes que influenciam a latência da inferência incluem tempo de carregamento do modelo, tempo de pré-processamento, tempo real de previsão, tempo de pós-processamento e tempo de transmissão da rede. Recomendamos monitorar a latência de inferência para garantir respostas de baixa latência que atendam aos contratos de nível de serviço (SLAs) e desenvolver métricas personalizadas para o seguinte. Teste sob a carga esperada, inclua a latência da rede, contabilize solicitações simultâneas e teste com tamanhos de lote variados.

Time to First Token (TTFT) — Tempo desde o momento em que um usuário envia uma solicitação até receber o início de uma resposta (a primeira palavra, token ou fragmento). Por exemplo, em chatbots, você verificaria quanto tempo leva para gerar a primeira parte da saída (token) depois que o usuário faz uma pergunta.
End-to-End Latência — Esse é o tempo total desde o recebimento de uma solicitação até o envio da resposta. Por exemplo, meça o tempo entre a solicitação e a resposta.
Tokens de saída por segundo (TPS) — Indica a rapidez com que seu modelo gera novos tokens depois de começar a responder. Por exemplo, em chatbots, você acompanharia a velocidade de geração de modelos de linguagem para um texto básico.
Taxa de erro — rastreia solicitações com falha, o que pode indicar problemas de desempenho. Por exemplo, monitore solicitações malsucedidas de documentos grandes ou determinados caracteres.
Rendimento — meça o número de solicitações ou operações que o sistema pode processar por unidade de tempo. Por exemplo, rastreie solicitações por segundo para lidar com picos de carga.

K/V (Key/Value) cache can be a powerful optimization technique for inference latency, particularly relevant for transformer-based models. K/V cache stores the key and value tensors from previous transformer layer computations, reducing redundant computations during autoregressive inference, particularly in large language models (LLMs). Cache Efficiency Metrics (specifically for K/Vou um cache de sessão (uso):

hit/miss Proporção de cache — Para configurações de inferência que utilizam o armazenamento em cache (K/V ou caches incorporados), meça a frequência com que o cache está ajudando. As baixas taxas de acerto podem indicar alterações na configuração do cache ou na carga de trabalho abaixo do ideal, o que pode aumentar a latência.

Rastreando o uso da memória da GPU

Conforme discutido no Considere monitorar o treinamento básico e as métricas de ajuste fino tópico, o uso da memória da GPU é essencial para evitar erros out-of-memory (OOM) e garantir a utilização eficiente dos recursos. Os exemplos a seguir mostram como instrumentar seu aplicativo de treinamento para expor uma métrica de histograma personalizada e calcular o uso da memória P95 para identificar o pico de consumo. gpu_memory_usage_bytes Certifique-se de testar com um exemplo de trabalho de treinamento (por exemplo, ajuste fino de um modelo de transformador) em um ambiente de teste.

Exemplo de insights de CloudWatch contêiner nativos da AWS

Este exemplo demonstra como instrumentar seu aplicativo de treinamento para expor gpu_memory_usage_bytes como um histograma usando a abordagem nativa da AWS. Observe que seu AI/ML contêiner deve ser configurado para emitir registros estruturados no formato CloudWatch Embedded Metrics Format (EMF). CloudWatch logs, analisa o EMF e publica as métricas. Use aws_embedded_metrics em seu aplicativo de treinamento para enviar registros estruturados no formato EMF para o Logs, que extrai as métricas da 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()

Exemplo de Prometheus e Grafana

Este exemplo demonstra como instrumentar seu aplicativo de treinamento para expor gpu_memory_usage_bytes` como um histograma usando a biblioteca cliente Prometheus em 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()

Rastreie a duração da solicitação de inferência para inferência on-line em tempo real

Conforme discutido no Considere monitorar o treinamento básico e as métricas de ajuste fino tópico, a baixa latência é fundamental para fornecer respostas oportunas aos usuários ou a outros sistemas dependentes. Os exemplos a seguir mostram como rastrear uma métrica de histograma personalizada,inference_request_duration_seconds, exposta por seu aplicativo de inferência. Calcule a latência do 95º percentil (P95) para se concentrar nos piores cenários, teste com solicitações de inferência sintética (por exemplo, via Locust) em um ambiente de teste e defina limites de alerta (por exemplo, >500 ms) para detectar violações de SLA.

Exemplo de insights de CloudWatch contêiner nativos da AWS

Este exemplo demonstra como criar uma métrica de histograma personalizada em seu aplicativo de inferência para inference_request_duration_seconds usando o 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()

Exemplo de Prometheus e Grafana

Este exemplo demonstra como criar uma métrica de histograma personalizada em seu aplicativo de inferência para inference_request_duration_seconds usando a biblioteca de cliente Prometheus em 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)

No Grafana, use a consulta histogram_quantile(0.95, sum(rate(inference_request_duration_seconds_bucket[5m])) by (le, pod)) para visualizar as tendências de latência do P95. Para saber mais, consulte a documentação do histograma do Prometheus e a documentação do cliente do Prometheus.

Rastreie a taxa de transferência de tokens para inferência on-line em tempo real

Conforme discutido no Considere monitorar o treinamento básico e as métricas de ajuste fino tópico, recomendamos monitorar o tempo de processamento do token para avaliar o desempenho do modelo e otimizar as decisões de escalabilidade. Os exemplos a seguir mostram como rastrear uma métrica de histograma personalizada,token_processing_duration_seconds, exposta por seu aplicativo de inferência. Calcule a duração do 95º percentil (P95) para analisar a eficiência do processamento, testar com cargas de solicitações simuladas (por exemplo, 100 a 1000 solicitações/segundo) em um cluster que não seja de produção e ajuste os acionadores KEDA para otimizar o escalonamento.

Exemplo de insights de CloudWatch contêiner nativos da AWS

Este exemplo demonstra como criar uma métrica de histograma personalizada em seu aplicativo de inferência para token_processing_duration_seconds usando o AWS Embedded Metric Format. CloudWatch Ele usa a ) with a custom `get_duration_bucket função dimensions (`set_dimension) para categorizar durações em compartimentos (por exemplo, “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

Exemplo de Prometheus e Grafana

Este exemplo demonstra como criar uma métrica de histograma personalizada em seu aplicativo de inferência para token_processing_duration_seconds usando a biblioteca de cliente Prometheus em 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)

No Grafana, use a consulta histogram_quantile(0.95, sum(rate(token_processing_duration_seconds_bucket[5m])) by (le, pod))` para visualizar as tendências do tempo de processamento do P95. Para saber mais, consulte a documentação do histograma do Prometheus e a documentação do cliente do Prometheus.

Meça a latência de restauração do Checkpoint

Conforme discutido no Considere monitorar o treinamento básico e as métricas de ajuste fino tópico, a latência do ponto de verificação é uma métrica crítica durante várias fases do ciclo de vida do modelo. Os exemplos a seguir mostram como rastrear uma métrica de histograma personalizada,checkpoint_restore_duration_seconds`, exposta pelo seu aplicativo. Calcule a duração do 95º percentil (P95) para monitorar o desempenho da restauração, testar com interrupções pontuais em um cluster de não produção e definir limites de alerta (por exemplo, <30 segundos) para detectar atrasos.

Exemplo de insights de CloudWatch contêiner nativos da AWS

Este exemplo demonstra como instrumentar seu aplicativo em lote para expor checkpoint_restore_duration_seconds como um histograma usando o 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")

Exemplo de Prometheus e Grafana

Este exemplo demonstra como instrumentar seu aplicativo em lote para expor checkpoint_restore_duration_seconds como um histograma usando a biblioteca cliente Prometheus em 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"))

No Grafana, use a consulta histogram_quantile(0.95, sum(rate(checkpoint_restore_duration_seconds_bucket[5m]) by (le)) para visualizar as tendências de latência de restauração do P95. Para saber mais, consulte a documentação do histograma do Prometheus e a documentação do cliente do Prometheus.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Armazenamento

Performance