Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Observabilidad
Monitoreo y observabilidad
Tenga como objetivo un uso elevado de la GPU
La GPUs infrautilización indica que las cargas de trabajo no están aprovechando al máximo los recursos de la GPU asignados, lo que se traduce en un desperdicio de capacidad informática. Para AI/ML las cargas de trabajo en Amazon EKS, recomendamos supervisar el uso de la GPU para centrarse en un uso elevado de la GPU y optimizar la eficiencia de los recursos. La GPUs subutilización desperdicia la capacidad de cómputo y aumenta los costos, mientras que la programación excesiva puede provocar contención y una degradación del rendimiento.
Recomendamos configurar Cloudwatch Container Insights en Amazon EKS para identificar pods, nodos o cargas de trabajo específicos con métricas de bajo uso de la GPU. Se integra fácilmente con Amazon EKS, lo que le permite supervisar el uso de la GPU y ajustar la programación de los pods o los tipos de instancias si el uso cae por debajo de los niveles objetivo. Como alternativa, si esto no cumple con sus requisitos específicos (por ejemplo, visualización avanzada), considere la posibilidad de utilizar el exportador DCGM de NVIDIA junto con Prometheus y Grafana para la supervisión nativa de Kubernetes. Ambos enfoques proporcionan información sobre las métricas de la GPU, lo que permite ajustar la programación de los módulos o los tipos de instancias si la utilización cae por debajo de los niveles objetivo. Comprueba las métricas de NVIDIA, como nvidia_smi_utilization_gpu (uso de cómputo de la GPU) y nvidia_smi_utilization_memory (uso de memoria de la GPU), a través del exportador DCGM o CloudWatch Busca tendencias, como una baja utilización constante durante determinadas horas o para trabajos específicos.
Los límites estáticos de los recursos en Kubernetes (por ejemplo, el número de CPU, memoria y GPU) pueden provocar un aprovisionamiento excesivo o una infrautilización, especialmente en el caso de cargas de trabajo dinámicas como las de inferencia. AI/ML Recomendamos analizar las tendencias de uso y consolidar las cargas de trabajo en un menor número GPUs, asegurándose de que cada GPU se utilice al máximo antes de asignar otras nuevas. Si GPUs están infrautilizadas, considere las siguientes estrategias para optimizar la programación y el uso compartido. Para obtener más información, consulte las prácticas recomendadas de cálculo y escalado automático de EKS para obtener más información.
Observabilidad y métricas
Uso de herramientas de monitoreo y observabilidad para sus cargas de trabajo AI/ML
Los AI/ML servicios modernos funcionan en la intersección de la infraestructura, el modelado y la lógica de las aplicaciones. Los ingenieros de plataformas administran la infraestructura, el conjunto de observabilidad y se aseguran de que las métricas se recopilen, almacenen y visualicen. AI/ML Los ingenieros definen métricas específicas del modelo y se centran en el rendimiento bajo cargas y distribuciones variables. Los desarrolladores de aplicaciones utilizan la API, envían las solicitudes y realizan un seguimiento de las métricas de nivel de servicio y de las interacciones de los usuarios. El éxito depende de establecer prácticas de observabilidad unificadas en todos los entornos que brinden a todas las partes interesadas una visibilidad del estado y el rendimiento del sistema.
La optimización de los clústeres de Amazon EKS para AI/ML las cargas de trabajo presenta desafíos de supervisión únicos, especialmente en lo que respecta a la administración de la memoria de la GPU. Sin una supervisión adecuada, las organizaciones suelen enfrentarse a errores out-of-memory (OOM), ineficiencias de recursos y costes innecesarios. Para los clientes de EKS, el monitoreo efectivo garantiza un mejor rendimiento, resiliencia y menores costos. Un enfoque holístico que combina la monitorización pormenorizada de la GPU mediante el exportador DCGM de NVIDIA
Herramientas y marcos
Algunas herramientas y marcos ofrecen out-of-the-box métricas nativas para monitorear las AI/ML cargas de trabajo, lo que permite una integración más sencilla sin una configuración personalizada adicional. Se centran en aspectos del rendimiento, como la latencia, el rendimiento y la generación de tokens, que son fundamentales para la elaboración de inferencias y la evaluación comparativa. Entre los ejemplos se incluyen:
-
vLLM: un motor de servidor de alto rendimiento para modelos de lenguaje de gran tamaño (LLMs) que proporciona métricas nativas, como la latencia de las solicitudes y el uso de memoria.
-
Ray: un marco de computación distribuida que emite métricas para cargas de trabajo de IA escalables, incluidos los tiempos de ejecución de las tareas y la utilización de los recursos.
-
Hugging Face Text Generation Inference (TGI): un conjunto de herramientas para implementar y LLMs servir, con métricas integradas para el rendimiento de las inferencias.
-
NVIDIA genai-perf: una herramienta de línea de comandos para comparar modelos de IA generativa y medir el rendimiento, la latencia y las métricas específicas de la LLM, como las solicitudes completadas en intervalos de tiempo específicos.
Métodos de observabilidad
Recomendamos implementar cualquier mecanismo de observabilidad adicional de una de las siguientes maneras.
CloudWatch Container Insights Si su organización prefiere herramientas nativas de AWS con una configuración mínima, le recomendamos CloudWatch Container Insights. Se integra con el exportador DCGM de NVIDIA
Una vez incorporado a Container Insights, detecta CloudWatch automáticamente la presencia de NVIDIA GPUs en su entorno, recopila las métricas críticas de estado y rendimiento de su NVIDIA GPUs como CloudWatch métricas y las pone a disposición en paneles seleccionados. out-of-the-box Además, Ray
Para obtener más información y ver una lista completa de las métricas disponibles, consulte las métricas de Amazon EKS y Kubernetes Container Insights. Consulte Obtenga información operativa para las cargas de trabajo de GPU de NVIDIA mediante Amazon CloudWatch Container Insights
Prometheus y Grafana gestionados Si su organización se siente cómoda con las herramientas de código abierto y los paneles personalizados, le recomendamos implementar Prometheus con el exportador de DCGM de NVIDIA y Grafana para una supervisión nativa de Kubernetes con visualizaciones avanzadas
Además, puede usar marcos de código abierto como Ray y vLLM
Para obtener más información, consulte Supervisión de las cargas de trabajo de GPU en Amazon EKS mediante los servicios de código abierto gestionados por AWS
Considere la posibilidad de monitorizar la formación básica y ajustar las métricas
Para las métricas de entrenamiento principales para las AI/ML cargas de trabajo en EKS, considere una combinación de métricas que indiquen el estado y el rendimiento de su clúster de Amazon EKS y las cargas de trabajo de aprendizaje automático que se ejecutan en él. Consulte Introducción a la observación de las cargas de trabajo de aprendizaje automático en Amazon EKS
Métricas de uso de recursos:
-
Uso de CPU, memoria, GPU y memoria de GPU: la supervisión de estas métricas para las cargas de trabajo de aprendizaje automático le permite garantizar que los recursos asignados son suficientes e identificar oportunidades de optimización. Por ejemplo, mediante el seguimiento de métricas
gpu_memory_usage_bytes, puedes identificar los patrones de consumo de memoria, detectar los picos de uso y calcular percentiles, como el percentil 95 (P95), para comprender las mayores demandas de memoria durante el entrenamiento. Esto ayuda a optimizar los modelos y la infraestructura para evitar errores de OOM y reducir los costes. -
Utilización de recursos de nodos y pods: el seguimiento del uso de los recursos a nivel de nodo y pod le ayuda a identificar la contención de recursos y los posibles cuellos de botella. Por ejemplo, compruebe si algún nodo está sobreutilizado, lo que podría afectar a la programación de los pods.
-
Comparación de la utilización de los recursos con las solicitudes y los límites: esto proporciona información sobre si su clúster puede gestionar las cargas de trabajo actuales y adaptarse a las futuras. Por ejemplo, compare el uso de memoria real con los límites para evitar out-of-memory errores.
-
Métricas internas de los marcos de aprendizaje automático: capture las métricas internas de formación y convergencia de los marcos de aprendizaje automático (TensorFlow, PyTorch), como las curvas de pérdidas, la tasa de aprendizaje, el tiempo de procesamiento por lotes y la duración de los pasos de entrenamiento, que a menudo se visualizan con o de forma similar. TensorBoard
Métricas de rendimiento del modelo:
-
Exactitud, precisión, recuperación y puntuación de F1: son fundamentales para comprender el rendimiento de sus modelos de aprendizaje automático. Por ejemplo, después del entrenamiento, calcula la puntuación F1 en un conjunto de validación para evaluar el rendimiento.
-
Métricas específicas de la empresa y KPIs: defina y realice un seguimiento de las métricas directamente relacionadas con el valor empresarial de sus iniciativas. AI/ML Por ejemplo, en un sistema de recomendaciones, haz un seguimiento del aumento de la participación de los usuarios.
-
Hacer un seguimiento de estas métricas a lo largo del tiempo: esto ayuda a identificar cualquier degradación en el rendimiento del modelo. Por ejemplo, compare las métricas de rendimiento de las distintas versiones del modelo para detectar tendencias.
Métricas de calidad y desviación de los datos:
-
Propiedades estadísticas de los datos de entrada: monitorícelas a lo largo del tiempo para detectar desviaciones de datos o anomalías que puedan afectar al rendimiento del modelo. Por ejemplo, realice un seguimiento de la media de las entidades de entrada para detectar cambios.
-
Detección de desviaciones de datos y alertas: implemente mecanismos para detectar y alertar automáticamente sobre los problemas de calidad de los datos. Por ejemplo, usa pruebas para comparar los datos actuales con los datos de entrenamiento y alertar en caso de desviaciones significativas.
Métricas de latencia y rendimiento:
-
End-to-End Latencia de los procesos de formación en aprendizaje automático: monitorea el tiempo que tardan los datos en fluir por todo el proceso de formación. Por ejemplo, mida el tiempo total desde la ingesta de datos hasta la actualización del modelo.
-
Rendimiento y tasa de procesamiento de la capacitación: realice un seguimiento del volumen de datos procesados durante la capacitación para garantizar la eficiencia. Por ejemplo, supervise las muestras positivas y negativas procesadas por segundo.
-
Latencia de restauración de puntos de control: supervise el tiempo que se tarda en cargar un punto de control del modelo guardado desde una ubicación de almacenamiento (S3, EFS, FSx etc.) a la GPU/CPU memoria al reanudar un trabajo, recuperarse de un error o inicializar. Esta métrica afecta directamente al tiempo de recuperación de las tareas, al rendimiento del arranque en frío y a la eficiencia general de las tuberías de interferencia. En los servicios de inferencia de autoescalado, la carga lenta de los puntos de control puede provocar retrasos en el arranque en frío y deteriorar la experiencia del usuario. Estas métricas relacionadas también se suelen utilizar para mejorar los puntos de control de los modelos: la latencia del tiempo de inactividad de los puntos de control, el tiempo de deserialización del modelo, el tamaño de los puntos de control y el recuento de errores en la restauración de los puntos de control.
-
Duración de la solicitud de inferencia: monitorea el tiempo que se tarda en completar una solicitud de inferencia. Este es el tiempo desde que se recibe la solicitud inicial hasta que se completa la respuesta del modelo.
-
Rendimiento de los tokens: supervise el tiempo de procesamiento de los tokens para evaluar el rendimiento del modelo y optimizar las decisiones de escalado. Un procesamiento lento puede indicar ineficiencias o recursos infrautilizados, lo que repercute en la rentabilidad. El seguimiento de métricas, como las entradas por segundo y las fichas que salen por segundo, junto con el tiempo de procesamiento, pueden ayudar a identificar los cuellos de botella en el rendimiento, las ralentizaciones y los factores de costes.
-
Identificación de los cuellos de botella en el rendimiento: utilice estas métricas para identificar las áreas que deben optimizarse en el proceso de formación. Por ejemplo, analice el tiempo dedicado a la carga de datos en comparación con el cálculo del modelo.
Tasas de errores y errores:
-
Supervisión de los errores en todo el proceso de aprendizaje automático: esto incluye el preprocesamiento de datos, el entrenamiento de modelos y la inferencia. Por ejemplo, registre los errores en el preprocesamiento para identificar rápidamente los problemas.
-
Identificar e investigar los errores recurrentes: esto ayuda a mantener un modelo de alta calidad y a garantizar un rendimiento uniforme. Por ejemplo, analice los registros para encontrar patrones, como datos específicos que provocan errores.
Métricas específicas de Kubernetes y EKS:
-
Métricas del estado del clúster de Kubernetes: supervise el estado y el estado de varios objetos de Kubernetes, incluidos los módulos, los nodos y el plano de control. Por ejemplo, usa herramientas como las de comprobar el estado de los módulos.
kubectl -
Ejecuciones de canalización exitosas o fallidas: realice un seguimiento de las ejecuciones de successful/failed canalizaciones, la duración de los trabajos, los tiempos de finalización de los pasos y los errores de orquestación (por ejemplo, al usar Kubeflow/Mlflow/Argo eventos).
-
Estadísticas de servicios de AWS: realice un seguimiento de las métricas de otros servicios de AWS que respaldan su infraestructura de EKS y las aplicaciones que se ejecutan en ella. Por ejemplo, si utiliza Amazon S3, supervise el tamaño del depósito para realizar un seguimiento del uso del almacenamiento.
-
Métricas del plano de control de Kubernetes: supervise el servidor de API, el programador, el administrador del controlador y la base de datos, etc., para detectar problemas o fallas de rendimiento. Por ejemplo, realiza un seguimiento de la latencia de las solicitudes del servidor API para comprobar la capacidad de respuesta.
En los temas siguientes, demostraremos la recopilación de datos para algunas de las métricas mencionadas anteriormente. Proporcionaremos ejemplos con los dos enfoques recomendados por AWS: CloudWatch Container Insights, nativo de AWS, y Prometheus gestionado por Amazon de código abierto con Amazon Managed Grafana. Escogería una de estas soluciones en función de sus necesidades generales de observabilidad. Consulte las métricas de Amazon EKS y Kubernetes Container Insights para ver la lista completa de métricas de Container Insights.
Considere la posibilidad de monitorear las métricas de inferencia en línea en tiempo real
En los sistemas en tiempo real, la baja latencia es fundamental para proporcionar respuestas oportunas a los usuarios u otros sistemas dependientes. La alta latencia puede degradar la experiencia del usuario o infringir los requisitos de rendimiento. Los componentes que influyen en la latencia de inferencia incluyen el tiempo de carga del modelo, el tiempo de preprocesamiento, el tiempo de predicción real, el tiempo de posprocesamiento y el tiempo de transmisión de la red. Recomendamos monitorear la latencia de inferencia para garantizar que las respuestas de baja latencia cumplan con los acuerdos de nivel de servicio (SLAs) y desarrollar métricas personalizadas para lo siguiente. Realice pruebas con la carga esperada, incluya la latencia de la red, contabilice las solicitudes simultáneas y realice pruebas con lotes de distintos tamaños.
-
Tiempo transcurrido hasta el primer token (TTFT): tiempo transcurrido desde que un usuario envía una solicitud hasta que recibe el principio de la respuesta (la primera palabra, símbolo o fragmento). Por ejemplo, en los chatbots, debes comprobar cuánto tiempo se tarda en generar el primer resultado (token) después de que el usuario haga una pregunta.
-
End-to-End Latencia: es el tiempo total desde que se recibe una solicitud hasta que se devuelve la respuesta. Por ejemplo, mida el tiempo transcurrido desde la solicitud hasta la respuesta.
-
Producción de fichas por segundo (TPS): indica la rapidez con la que su modelo genera nuevas fichas una vez que comienza a responder. Por ejemplo, en los chatbots, harías un seguimiento de la velocidad de generación de los modelos de lenguaje para un texto de referencia.
-
Tasa de errores: hace un seguimiento de las solicitudes fallidas, lo que puede indicar problemas de rendimiento. Por ejemplo, supervisa las solicitudes fallidas de documentos grandes o de determinados caracteres.
-
Rendimiento: mida la cantidad de solicitudes u operaciones que el sistema puede gestionar por unidad de tiempo. Por ejemplo, realice un seguimiento de las solicitudes por segundo para gestionar los 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/Vo una sesión (uso de caché):
-
hit/miss Proporción de caché: para las configuraciones de inferencia que utilizan el almacenamiento en caché (cachés K/V o incrustadas), mida la frecuencia con la que la caché ayuda. Las bajas tasas de aciertos pueden indicar cambios en la carga de trabajo o en la configuración de la caché que no son óptimos, lo que puede aumentar la latencia.
En los temas siguientes, demostraremos la recopilación de datos para algunas de las métricas mencionadas anteriormente. Proporcionaremos ejemplos con los dos enfoques recomendados por AWS: CloudWatch Container Insights, nativo de AWS, y Prometheus gestionado por Amazon de código abierto con Amazon Managed Grafana. Escogería una de estas soluciones en función de sus necesidades generales de observabilidad. Consulte las métricas de Amazon EKS y Kubernetes Container Insights para ver la lista completa de métricas de Container Insights.
Seguimiento del uso de la memoria de la GPU
Como se explica en el Considere la posibilidad de monitorizar la formación básica y ajustar las métricas tema, el uso de la memoria de la GPU es esencial para evitar errores out-of-memory (OOM) y garantizar un uso eficiente de los recursos. En los siguientes ejemplos, se muestra cómo configurar una aplicación de entrenamiento para mostrar una métrica de histograma personalizada y cómo calcular el uso de memoria del P95 para identificar los picos de consumo. gpu_memory_usage_bytes Asegúrese de realizar la prueba con un ejemplo de trabajo de formación (por ejemplo, ajustar un modelo de transformador) en un entorno de ensayo.
Ejemplo de AWS Native CloudWatch Container Insights
En este ejemplo se muestra cómo instrumentar su aplicación de formación para exponerla gpu_memory_usage_bytes como un histograma utilizando el enfoque nativo de AWS. Tenga en cuenta que su AI/ML contenedor debe estar configurado para emitir registros estructurados en formato CloudWatch Embedded Metrics Format (EMF). CloudWatch registra, analiza los EMF y publica las métricas. Usa 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()
Ejemplo de Prometheus y Grafana
En este ejemplo se muestra cómo instrumentar su aplicación de entrenamiento para que se exponga gpu_memory_usage_bytes` como un histograma mediante la biblioteca cliente Prometheus en 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()
Realice un seguimiento de la duración de la solicitud de inferencia para realizar inferencias en línea en tiempo real
Como se discutió en el Considere la posibilidad de monitorizar la formación básica y ajustar las métricas tema, la baja latencia es fundamental para proporcionar respuestas oportunas a los usuarios u otros sistemas dependientes. En los siguientes ejemplos, se muestra cómo realizar un seguimiento de una métrica de histograma personalizadainference_request_duration_seconds, expuesta por la aplicación de inferencia. Calcule la latencia del percentil 95 (P95) para centrarse en los peores escenarios posibles, realice pruebas con solicitudes de inferencias sintéticas (por ejemplo, mediante Locust) en un entorno de ensayo y establezca umbrales de alerta (por ejemplo, más de 500 ms) para detectar las infracciones del SLA.
Ejemplo de AWS Native CloudWatch Container Insights
En este ejemplo se muestra cómo crear una métrica de histograma personalizada en su aplicación de inferencia para inference_request_duration_seconds con el formato de métricas integradas de AWS. 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()
Ejemplo de Prometheus y Grafana
En este ejemplo se muestra cómo crear una métrica de histograma personalizada en la aplicación de inferencia para inference_request_duration_seconds mediante la biblioteca cliente de Prometheus en 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)
En Grafana, utilice la consulta histogram_quantile(0.95, sum(rate(inference_request_duration_seconds_bucket[5m])) by (le, pod)) para visualizar las tendencias de latencia del P95. Para obtener más información, consulte la documentación del histograma de Prometheus
Realice un seguimiento del rendimiento de los tokens para obtener inferencias en línea en tiempo real
Como se discutió en el Considere la posibilidad de monitorizar la formación básica y ajustar las métricas tema, recomendamos monitorear el tiempo de procesamiento de los tokens para evaluar el rendimiento del modelo y optimizar las decisiones de escalado. Los siguientes ejemplos muestran cómo realizar un seguimiento de una métrica de histograma personalizadatoken_processing_duration_seconds, expuesta por su aplicación de inferencia. Calcule la duración del percentil 95 (P95) para analizar la eficiencia del procesamiento, realice pruebas con cargas de solicitudes simuladas (por ejemplo, de 100 a 1000 solicitudes por segundo) en un clúster que no sea de producción y ajuste los activadores de KEDA para optimizar el escalado.
Ejemplo de AWS Native CloudWatch Container Insights
En este ejemplo, se muestra cómo crear una métrica de histograma personalizada en su aplicación de inferencia para token_processing_duration_seconds con el formato de métricas integradas de AWS. CloudWatch Utiliza dimensiones () with a custom `get_duration_bucketfunción `set_dimension») para clasificar las duraciones en grupos (p. ej., «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
Ejemplo de Prometheus y Grafana
En este ejemplo, se muestra cómo crear una métrica de histograma personalizada en la aplicación de inferencia para token_processing_duration_seconds mediante la biblioteca cliente Prometheus en 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)
En Grafana, utilice la consulta histogram_quantile(0.95, sum(rate(token_processing_duration_seconds_bucket[5m])) by (le, pod))` para visualizar las tendencias del tiempo de procesamiento del P95. Para obtener más información, consulte la documentación del histograma de Prometheus
Mida la latencia de restauración de los puntos de control
Como se explica en el Considere la posibilidad de monitorizar la formación básica y ajustar las métricas tema, la latencia de los puntos de control es una métrica fundamental durante varias fases del ciclo de vida del modelo. Los siguientes ejemplos muestran cómo realizar un seguimiento de una métrica de histograma personalizadacheckpoint_restore_duration_seconds`, expuesta por su aplicación. Calcule la duración del percentil 95 (P95) para supervisar el rendimiento de la restauración, realice pruebas con interrupciones puntuales en un clúster que no esté en producción y establezca umbrales de alerta (por ejemplo, menos de 30 segundos) para detectar retrasos.
Ejemplo de AWS Native CloudWatch Container Insights
En este ejemplo, se muestra cómo instrumentar una aplicación por lotes para mostrar checkpoint_restore_duration_seconds como un histograma mediante 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")
Ejemplo de Prometheus y Grafana
En este ejemplo se muestra cómo instrumentar una aplicación por lotes para que se exponga checkpoint_restore_duration_seconds como un histograma mediante la biblioteca cliente Prometheus en 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"))
En Grafana, utilice la consulta histogram_quantile(0.95, sum(rate(checkpoint_restore_duration_seconds_bucket[5m]) by (le)) para visualizar las tendencias de latencia de restauración del P95. Para obtener más información, consulte la documentación del histograma de Prometheus
