As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Observabilidade
dica
Explore as
Monitoramento e observabilidade
Explicação das métricas da GPU
A métrica de utilização da GPU mostra se a GPU executou algum trabalho durante a janela de amostra. Essa métrica captura a porcentagem de tempo em que a GPU executou pelo menos uma instrução, mas não revela a eficiência com que a GPU usou seu hardware. Uma GPU contém vários Multiprocessadores de Streaming (SMs), que são as unidades de processamento paralelo que executam instruções. Uma leitura de 100% de utilização pode significar que a GPU executou cargas de trabalho paralelas pesadas em todas as suas SMs, ou pode significar que uma única pequena instrução ativou a GPU durante o período da amostra. Para entender a utilização real, você precisa examinar as métricas da GPU em vários níveis da arquitetura de hardware. Cada multiprocessador de streaming é construído a partir de diferentes tipos de núcleo, e cada camada expõe características de desempenho diferentes. Métricas de alto nível (utilização da GPU, utilização da memória, potência da GPU e temperatura da GPU, visíveis por meio da nvidia-smi) mostram se o dispositivo está ativo. Métricas mais detalhadas (utilização do SM, atividade do SM e uso do tensor core) revelam a eficiência com que a GPU usa seus recursos.
Almeje o alto uso de energia da GPU
A subutilização GPUs desperdiça a capacidade computacional e aumenta os custos porque as cargas de trabalho não conseguem engajar todos os componentes da GPU simultaneamente. Para AI/ML cargas de trabalho no Amazon EKS, monitore o uso de energia da GPU como proxy para identificar a atividade real da GPU. A utilização da GPU relata a porcentagem de tempo em que a GPU executa qualquer kernel, mas não revela se os multiprocessadores de streaming, os controladores de memória e os núcleos tensores estão todos ativos ao mesmo tempo. O uso de energia expõe essa lacuna porque o hardware totalmente engajado consome significativamente mais energia do que o hardware que executa núcleos leves ou fica ocioso entre as tarefas. Compare o consumo de energia com a potência de design térmico (TDP) da GPU para detectar a subutilização e, em seguida, investigue se sua carga de trabalho está limitada pelo pré-processamento da CPU, E/S de rede ou tamanhos de lote ineficientes.
Configure o CloudWatch Container Insights no Amazon EKS para identificar pods, nós ou cargas de trabalho com baixo consumo de energia da GPU. Essa ferramenta se integra diretamente ao Amazon EKS e permite monitorar o consumo de energia da GPU e ajustar o agendamento de pods ou os tipos de instância quando o uso de energia estiver abaixo dos níveis desejados. Se você precisar de visualização avançada ou painéis personalizados, use o DCGM-Exporter da NVIDIA com Prometheus e Grafana para monitoramento nativo do Kubernetes. Ambas as abordagens revelam as principais métricas da NVIDIA, como nvidia_smi_power_draw (consumo de energia da GPU) e nvidia_smi_temperature_gpu (temperatura da GPU). Para ver uma lista de métricas, explore https://docs.aws.amazon.com/AmazonCloudWatch/ latest/monitoring/CloudWatch o -Agent-NVIDIA-GPU.htm. Procure padrões como baixo consumo consistente de energia durante horários específicos ou para trabalhos específicos. Essas tendências ajudam a identificar onde consolidar as cargas de trabalho ou ajustar a alocação de recursos.
Limites estáticos de recursos no Kubernetes (como contagem de CPU, memória e GPU) geralmente levam ao provisionamento excessivo ou à subutilização, especialmente para cargas de trabalho dinâmicas, como inferência, em que a demanda flutua. AI/ML Analise suas tendências de utilização e consolide cargas de trabalho em menos. GPUs Certifique-se de que cada GPU alcance a utilização total antes de alocar outras. Essa abordagem reduz o desperdício e reduz os custos. Para obter orientação detalhada sobre como otimizar as estratégias de agendamento e compartilhamento, consulte as melhores práticas de computação e escalonamento automático do EKS
Observabilidade e métricas
Usando ferramentas de monitoramento e observabilidade para suas cargas de trabalho AI/ML
Os AI/ML serviços modernos exigem coordenação entre infraestrutura, modelagem e lógica de aplicativos. Os engenheiros da plataforma gerenciam a infraestrutura e a pilha de observabilidade. Eles coletam, armazenam e visualizam métricas. AI/ML os engenheiros definem métricas específicas do modelo e monitoram o desempenho sob cargas e distribuição de dados variáveis. Os desenvolvedores de aplicativos consomem APIs, encaminham solicitações e rastreiam métricas de nível de serviço e interações de usuários. Sem práticas unificadas de observabilidade, essas equipes trabalham em silos e perdem sinais críticos sobre a integridade e o desempenho do sistema. Estabelecer visibilidade compartilhada em todos os ambientes garante que todas as partes interessadas possam detectar problemas com antecedência e manter um serviço confiável.
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 enfrentam erros out-of-memory (OOM), ineficiências de recursos e custos desnecessários. O monitoramento eficaz garante melhor desempenho, resiliência e custos mais baixos para os clientes da EKS. Use uma abordagem holística que combine três camadas de monitoramento. Primeiro, monitore as métricas granulares da GPU usando o NVIDIA DCGM Exporter para monitorar o uso de energia da GPU
Ferramentas e estruturas
Várias ferramentas e estruturas fornecem out-of-the-box métricas nativas para monitorar AI/ML cargas de trabalho. Essas métricas integradas eliminam a necessidade de instrumentação personalizada e reduzem o tempo de configuração. As métricas se concentram em aspectos de desempenho, como latência, taxa de transferência e geração de tokens, que são essenciais para o fornecimento de inferências e o benchmarking. O uso de métricas nativas permite que você comece a monitorar imediatamente sem criar canais de coleta personalizados.
-
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
Depois de instalar o Container Insights, detecta CloudWatch automaticamente a NVIDIA GPUs em seu ambiente e coleta métricas críticas de integridade e desempenho. Essas métricas aparecem em out-of-the-box painéis selecionados. Você também pode integrar o Ray
Para obter uma lista completa das métricas disponíveis, consulte as métricas do Amazon EKS e do Kubernetes Container Insights. Para step-by-step obter orientação sobre a implementação do monitoramento de GPU, consulte Obtenha insights operacionais para cargas de trabalho de GPU NVIDIA usando o Amazon CloudWatch
Prometheus e Grafana gerenciados Se sua organização precisa de painéis personalizados e recursos avançados de visualização, implante o Prometheus com o NVIDIA DCGM-Exporter e o Grafana para monitoramento nativo do Kubernetes.
Você pode estender essa pilha de monitoramento integrando estruturas de código aberto como Ray e vLLM Ray e vLLM para exportar suas métricas nativas para o Prometheus
Para step-by-step obter orientação sobre a implantação dessa pilha de monitoramento, consulte Monitoramento de cargas de trabalho de GPU no Amazon EKS usando serviços de código aberto gerenciados pela AWS
Considere monitorar o treinamento básico e as métricas de ajuste fino
Monitore as principais métricas de treinamento para monitorar a integridade e o desempenho do seu cluster Amazon EKS e das cargas de trabalho de aprendizado de máquina em execução nele. As cargas de trabalho de treinamento têm requisitos de monitoramento diferentes das cargas de trabalho de inferência porque são executadas por longos períodos, consomem recursos de forma diferente e exigem visibilidade da convergência do modelo e da eficiência do pipeline de dados. As métricas abaixo ajudam a identificar gargalos, otimizar a alocação de recursos e garantir que os trabalhos de treinamento sejam concluídos com êxito. Para step-by-step obter orientação sobre a implementação dessa abordagem de monitoramento, consulte Introdução à observação de cargas de trabalho de aprendizado de máquina no Amazon EKS
Métricas de uso de recursos
Monitore as métricas de uso de recursos para validar se seus recursos estão sendo consumidos adequadamente. Essas métricas ajudam a identificar gargalos e a causa raiz dos problemas de desempenho.
-
CPU, memória, rede, potência da GPU e temperatura da GPU — monitore essas métricas para garantir que os recursos alocados atendam às demandas da carga de trabalho e identifiquem oportunidades de otimização. Monitore métricas como gpu_memory_usage_bytes para identificar padrões de consumo de memória e detectar picos de uso. Calcule percentis como o 95º percentil (P95) para entender as maiores demandas de memória durante o treinamento. Essa análise ajuda você a otimizar modelos e infraestrutura para evitar erros de OOM e reduzir custos.
-
Ocupação do SM, atividade e FPxx atividade do SM - monitore essas métricas para entender como o recurso subjacente na GPU está sendo usado. Como regra geral, a meta de 0,8 para SM Activity.
-
Utilização de recursos de nós e pods — acompanhe o uso de recursos no nível do nó e do pod para identificar a contenção de recursos e possíveis gargalos. Monitore se os nós se aproximam dos limites de capacidade, o que pode atrasar o agendamento do pod e atrasar os trabalhos de treinamento.
-
Utilização de recursos em comparação com solicitações e limites — Compare o uso real dos recursos com as solicitações e limites configurados para determinar se seu cluster pode lidar com cargas de trabalho atuais e acomodar cargas de trabalho futuras. Essa comparação revela se você precisa ajustar as alocações de recursos para evitar erros de OOM ou desperdício de recursos.
-
Métricas internas de estruturas de ML - Capture métricas internas de treinamento e convergência de estruturas de ML, como e. TensorFlow PyTorch Essas métricas incluem curvas de perda, taxa de aprendizado, tempo de processamento em lote e duração da etapa de treinamento. Visualize essas métricas usando ferramentas semelhantes TensorBoard para rastrear a convergência de modelos e identificar ineficiências de treinamento.
Métricas de desempenho do modelo
Monitore as métricas de desempenho do modelo para validar se seu processo de treinamento produz modelos que atendam à precisão e aos requisitos de negócios. Essas métricas ajudam a determinar quando interromper o treinamento, comparar as versões do modelo e identificar a degradação do desempenho.
-
Exatidão, precisão, recuperação e pontuação F1 — acompanhe essas métricas para entender o desempenho do seu modelo nos dados de validação. Calcule a pontuação F1 em um conjunto de validação após cada período de treinamento para avaliar se o modelo está melhorando e quando atinge níveis de desempenho aceitáveis.
-
Métricas específicas do negócio e KPIs — Defina e acompanhe métricas que medem diretamente o valor comercial de suas AI/ML iniciativas. Para um sistema de recomendação, acompanhe métricas como taxa de cliques ou taxa de conversão para garantir que o modelo gere os resultados comerciais pretendidos.
-
Desempenho ao longo do tempo — compare as métricas de desempenho entre as versões do modelo e as execuções de treinamento para identificar tendências e detectar degradações. Monitore se as versões mais recentes do modelo mantêm ou melhoram o desempenho em comparação com os modelos básicos. Essa comparação histórica ajuda você a decidir se deve implantar novos modelos ou investigar problemas de treinamento.
Qualidade de dados e métricas de desvio
Monitore a qualidade dos dados e altere as métricas para garantir que seus dados de treinamento permaneçam consistentes e representativos. A variação de dados pode fazer com que o desempenho do modelo diminua com o tempo, enquanto problemas de qualidade dos dados podem impedir que os modelos converjam ou produzam resultados não confiáveis.
-
Propriedades estatísticas dos dados de entrada — Acompanhe as propriedades estatísticas, como média, desvio padrão e distribuição dos recursos de entrada ao longo do tempo, para detectar desvios ou anomalias nos dados. Monitore se as distribuições de recursos mudam significativamente em relação aos seus dados básicos de treinamento. Por exemplo, se a média de um recurso crítico mudar em mais de dois desvios padrão, investigue se seu pipeline de dados mudou ou se a fonte de dados subjacente mudou.
-
Detecção e alertas de desvios de dados — implemente mecanismos automatizados para detectar e alertar sobre problemas de qualidade de dados antes que eles afetem o treinamento. Use testes estatísticos, como o teste de Kolmogorov-Smirnov ou o teste qui-quadrado, para comparar as distribuições de dados atuais com seus dados de treinamento originais. Configure alertas quando os testes detectarem desvios significativos para que você possa treinar novamente os modelos com dados atualizados ou investigar problemas no pipeline de dados.
Métricas de latência e taxa de transferência
Monitore as métricas de latência e produtividade para identificar gargalos em seu pipeline de treinamento e otimizar a utilização de recursos. Essas métricas ajudam você a entender onde o tempo é gasto durante o treinamento e onde concentrar os esforços de otimização.
-
End-to-End Latência dos canais de treinamento de ML — meça o tempo total para que os dados fluam por todo o seu pipeline de treinamento, desde a ingestão de dados até a atualização do modelo. Acompanhe essa métrica em todas as sessões de treinamento para identificar se as mudanças no pipeline melhoram ou diminuem o desempenho. A alta latência geralmente indica gargalos no carregamento de dados, no pré-processamento ou na comunicação de rede entre os nós.
-
Rendimento e taxa de processamento do treinamento — Acompanhe o volume de dados que seu pipeline de treinamento processa por unidade de tempo para garantir a utilização eficiente dos recursos. Monitore métricas como amostras processadas por segundo ou lotes concluídos por minuto. A baixa taxa de transferência em relação à capacidade do hardware sugere ineficiências no carregamento de dados, no pré-processamento ou na computação do modelo que desperdiçam ciclos de GPU.
-
Latência de salvamento e restauração do ponto de verificação — Monitore o tempo necessário para salvar os pontos de verificação do modelo no armazenamento (S3 FSx, EFS) e restaurá-los na GPU ou na memória da CPU ao retomar trabalhos ou se recuperar de falhas. As operações lentas do ponto de verificação prolongam o tempo de recuperação do trabalho e aumentam os custos. Monitore o tamanho do ponto de verificação, a duração do salvamento, a duração da restauração e a contagem de falhas para identificar oportunidades de otimização, como compactação ou níveis de armazenamento mais rápidos.
-
Tempo de carregamento e pré-processamento de dados - meça o tempo gasto carregando dados do armazenamento e aplicando transformações de pré-processamento. Compare esse tempo com o tempo de computação do modelo para determinar se seu treinamento está vinculado a dados ou à computação. Se o carregamento de dados consumir mais de 20% do tempo total de treinamento, considere otimizar seu pipeline de dados com armazenamento em cache, pré-busca ou armazenamento mais rápido.
Taxas de erro e falhas
Monitore taxas de erro e falhas em todo o pipeline de treinamento para manter a confiabilidade e evitar o desperdício de recursos computacionais. Erros não detectados podem fazer com que os trabalhos de treinamento falhem silenciosamente, produzam modelos inválidos ou desperdicem horas de tempo de GPU antes que você perceba problemas.
-
Monitoramento de erros do pipeline — acompanhe os erros em todos os estágios do seu pipeline de ML, incluindo pré-processamento de dados, treinamento de modelos e operações de ponto de verificação. Registre os tipos de erros, as frequências e os componentes afetados para identificar problemas rapidamente. Os erros comuns incluem incompatibilidades de formato de dados, out-of-memory falhas durante o pré-processamento e falhas de salvamento no ponto de verificação devido aos limites de armazenamento. Configure alertas quando as taxas de erro excederem os limites básicos para que você possa investigar antes que os erros ocorram em cascata.
-
Análise de erros recorrentes — identifique e investigue padrões em erros recorrentes para evitar futuras falhas e melhorar a confiabilidade do pipeline. Analise os registros para descobrir se amostras de dados específicas, tamanhos de lotes ou configurações de treinamento causam falhas de forma consistente. Por exemplo, se determinados tipos de dados de entrada acionarem erros de pré-processamento, adicione verificações de validação no início do pipeline ou atualize sua lógica de limpeza de dados. Acompanhe o tempo médio entre falhas (MTBF) para medir se a confiabilidade da tubulação melhora com o tempo. ”
Métricas específicas do Kubernetes e do EKS
Monitore as métricas do Kubernetes e do EKS para garantir que sua infraestrutura de cluster permaneça saudável e possa suportar suas cargas de trabalho de treinamento. Essas métricas ajudam você a detectar problemas de infraestrutura antes que eles causem falhas nas tarefas de treinamento ou degradação do desempenho.
-
Métricas do estado do cluster do Kubernetes — monitore a integridade e o status dos objetos do Kubernetes, incluindo pods, nós, implantações e serviços. Acompanhe o status dos pods para identificar os pods presos em estados de loop pendente, com falha ou de falha. Monitore as condições dos nós para detectar problemas como pressão do disco, pressão da memória ou indisponibilidade da rede. Use o kubectl ou as ferramentas de monitoramento para verificar essas métricas continuamente e configurar alertas quando os pods falharem na inicialização ou se tornarem não programáveis.
-
Métricas de execução do pipeline de treinamento — Acompanhe execuções bem-sucedidas e malsucedidas do pipeline, durações de trabalhos, tempos de conclusão de etapas e erros de orquestração. Monitore se os trabalhos de treinamento são concluídos dentro dos prazos esperados e se as taxas de falha aumentam com o tempo. Monitore métricas como taxa de sucesso no trabalho, duração média do trabalho e tempo até o fracasso. Essas métricas ajudam a identificar se problemas de infraestrutura, problemas de configuração ou problemas de qualidade de dados causam falhas no treinamento.
-
Métricas de serviço da AWS — Acompanhe métricas para serviços da AWS que suportam sua infraestrutura EKS e cargas de trabalho de treinamento. Monitore as métricas do S3, como latência da solicitação, taxas de erro e taxa de transferência, para garantir que o desempenho do carregamento de dados permaneça consistente. Acompanhe as métricas de volume do EBS, incluindo IOPS, taxa de transferência e tamanho da fila para detectar gargalos de armazenamento. Monitore os registros de fluxo da VPC e as métricas de rede para identificar problemas de conectividade entre os nós ou com serviços externos.
-
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 para detectar problemas ou falhas de desempenho que afetam as operações do cluster. Acompanhe a latência, a taxa de solicitação e a taxa de erro da solicitação do servidor de API para garantir que o plano de controle responda rapidamente às solicitações de agendamento. Monitore o tamanho do banco de dados etcd, a duração do commit e as mudanças de liderança para detectar problemas de estabilidade. A alta latência do servidor de API ou as frequentes mudanças no líder do etcd podem atrasar o agendamento do pod e estender os tempos de inicialização dos trabalhos de treinamento.
Registros de aplicativos e instâncias
Colete e analise registros de aplicativos e instâncias para diagnosticar problemas que as métricas sozinhas não conseguem explicar. Os registros fornecem um contexto detalhado sobre erros, mudanças de estado e eventos do sistema que ajudam você a entender por que os trabalhos de treinamento falham ou têm um desempenho ruim. A correlação de registros com métricas permite que você identifique as causas-raiz com mais rapidez.
-
Registros de aplicativos — colete registros de aplicativos de seus trabalhos de treinamento, pipelines de dados e estruturas de ML para identificar gargalos e diagnosticar falhas. Esses registros capturam informações detalhadas sobre a execução do trabalho, incluindo erros de carregamento de dados, falhas na inicialização do modelo, erros de salvamento do ponto de verificação e avisos específicos da estrutura. Correlacione registros de data e hora com picos de métricas para entender o que causou degradação ou falhas no desempenho. Por exemplo, se a utilização da GPU cair repentinamente, verifique se há erros nos registros do aplicativo que indiquem paralisações no pipeline de dados ou falhas no pré-processamento. Use ferramentas de registro centralizadas, como CloudWatch Logs ou Fluent Bit, para agregar registros de todos os pods e torná-los pesquisáveis.
-
Registros de instância - Colete registros no nível da instância, como registros do diário do sistema e saída dmesg, para detectar problemas de hardware e problemas no nível do kernel. Esses registros revelam problemas como erros de driver de GPU, falhas de alocação de memória, I/O erros de disco e problemas de interface de rede que podem não aparecer nos registros do aplicativo. Correlacione registros de instâncias com registros e métricas de aplicativos para determinar se as falhas de treinamento resultam de problemas de hardware ou problemas de aplicativos. Por exemplo, se um trabalho de treinamento falhar com um out-of-memory erro, verifique os registros do dmesg em busca de mensagens do kernel OOM killer que indiquem se o sistema ficou sem memória ou se o aplicativo excedeu seus limites de contêiner. Configure alertas para erros críticos de hardware, como erros de GPU XID ou falhas de disco, para que você possa substituir instâncias com falha antes que elas causem interrupções generalizadas no treinamento.
As seções a seguir mostram como coletar as métricas descritas acima usando duas abordagens recomendadas pela AWS: CloudWatch Container Insights e Amazon Managed Prometheus Amazon Managed Prometheus com Amazon Managed Grafana. Escolha o CloudWatch Container Insights se você preferir ferramentas nativas da AWS com configuração mínima e painéis pré-criados. Escolha o Amazon Managed Prometheus com o Amazon Managed Grafana se você precisar de painéis personalizados, recursos avançados de visualização ou quiser se integrar à infraestrutura de monitoramento existente baseada no Prometheus. Para obter uma lista completa das métricas disponíveis do Container Insights, consulte as métricas do Amazon EKS e do Kubernetes 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 malsucedidas, 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.
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.
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
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
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
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
