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
sugerencia
Explore
Supervisión y observabilidad
Explicación de las métricas de GPU
La métrica de utilización de la GPU muestra si la GPU realizó algún trabajo durante la ventana de muestra. Esta métrica captura el porcentaje de tiempo que la GPU ejecutó al menos una instrucción, pero no revela la eficiencia con la que la GPU utilizó su hardware. Una GPU contiene varios multiprocesadores de transmisión (SMs), que son las unidades de procesamiento en paralelo que ejecutan las instrucciones. Una lectura de utilización del 100% puede significar que la GPU ejecutó cargas de trabajo paralelas pesadas en todas sus SMs unidades, o puede significar que una sola instrucción pequeña activó la GPU durante el período de muestra. Para comprender el uso real, es necesario examinar las métricas de la GPU en varios niveles de la arquitectura del hardware. Cada multiprocesador de streaming está creado a partir de distintos tipos de núcleos y cada capa presenta características de rendimiento diferentes. Las métricas de nivel superior (utilización de la GPU, utilización de la memoria, potencia de la GPU y temperatura de la GPU, visibles a través de nvidia-smi) muestran si el dispositivo está activo. Las métricas más detalladas (uso del SM, actividad del SM y uso del núcleo tensor) revelan la eficiencia con la que la GPU utiliza sus recursos.
Concéntrese en un uso elevado de la energía
La subutilización GPUs desperdicia la capacidad de cómputo y aumenta los costes porque las cargas de trabajo no utilizan todos los componentes de la GPU de forma simultánea. Para AI/ML las cargas de trabajo en Amazon EKS, realice un seguimiento del uso de energía de la GPU como proxy para identificar la actividad real de la GPU. El uso de la GPU indica el porcentaje de tiempo que la GPU ejecuta cualquier núcleo, pero no revela si los multiprocesadores de streaming, los controladores de memoria y los núcleos tensoriales están todos activos al mismo tiempo. El uso de energía pone de manifiesto esta brecha, ya que el hardware totalmente utilizado consume mucha más energía que el hardware que utiliza núcleos livianos o permanece inactivo entre tareas. Compare el consumo de energía con la potencia de diseño térmico (TDP) de la GPU para detectar la infrautilización y, a continuación, investigue si su carga de trabajo se ve obstaculizada por el preprocesamiento de la CPU, las E/S de la red o los tamaños de lote ineficientes.
CloudWatch Configure Container Insights en Amazon EKS para identificar los pods, los nodos o las cargas de trabajo con bajo consumo de energía de la GPU. Esta herramienta se integra directamente con Amazon EKS y le permite supervisar el consumo de energía de la GPU y ajustar la programación de los pods o los tipos de instancias cuando el consumo de energía cae por debajo de los niveles objetivo. Si necesita una visualización avanzada o paneles personalizados, utilice el exportador DCGM de NVIDIA con Prometheus y Grafana para la supervisión nativa de Kubernetes. Ambos enfoques muestran métricas clave de NVIDIA, como (consumo de energía de la GPU) y (temperatura de la GPU). nvidia_smi_power_draw nvidia_smi_temperature_gpu Para ver una lista de métricas, consulta https://docs.aws.amazon.com/AmazonCloudWatch/ latest/monitoring/CloudWatch -Agent-NVIDIA-GPU.htm. Busque patrones como el bajo consumo de energía constante durante horas específicas o para trabajos específicos. Estas tendencias le ayudan a identificar dónde consolidar las cargas de trabajo o ajustar la asignación de recursos.
Los límites estáticos de los recursos en Kubernetes (como el número de CPU, memoria y GPU) suelen provocar un aprovisionamiento excesivo o una subutilización, especialmente en el caso de las cargas de trabajo dinámicas AI/ML , como las inferencias, en las que la demanda fluctúa. Analice sus tendencias de uso y consolide las cargas de trabajo en un menor número. GPUs Asegúrese de que cada GPU alcance su máxima utilización antes de asignar otras adicionales. Este enfoque reduce el desperdicio y los costos. Para obtener una guía detallada sobre cómo optimizar las estrategias de programación y uso compartido, consulte las prácticas recomendadas de cálculo y escalado automático de EKS
Observabilidad y métricas
Uso de herramientas de monitoreo y observabilidad para sus cargas de trabajo AI/ML
Los AI/ML servicios modernos requieren la coordinación entre la infraestructura, el modelado y la lógica de las aplicaciones. Los ingenieros de plataformas administran la infraestructura y el conjunto de observabilidad. Recopilan, almacenan y visualizan las métricas. AI/ML los ingenieros definen métricas específicas del modelo y supervisan el rendimiento en condiciones variables de carga y distribución de datos. Los desarrolladores de aplicaciones consumen APIs, direccionan las solicitudes y realizan un seguimiento de las métricas de nivel de servicio y las interacciones de los usuarios. Sin prácticas de observabilidad unificadas, estos equipos trabajan en silos y pasan por alto las señales críticas sobre el estado y el rendimiento del sistema. Establecer una visibilidad compartida en todos los entornos garantiza que todas las partes interesadas puedan detectar los problemas a tiempo y mantener un servicio fiable.
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 se enfrentan a errores out-of-memory (OOM), ineficiencias de recursos y costes innecesarios. Un monitoreo efectivo garantiza un mejor rendimiento, resiliencia y menores costos para los clientes de EKS. Utilice un enfoque holístico que combine tres capas de monitoreo. En primer lugar, supervise las métricas granulares de la GPU con el exportador DCGM de NVIDIA
Herramientas y marcos
Varias herramientas y marcos proporcionan out-of-the-box métricas nativas para monitorear las AI/ML cargas de trabajo. Estas métricas integradas eliminan la necesidad de una instrumentación personalizada y reducen el tiempo de configuración. Las métricas 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. El uso de métricas nativas le permite empezar a monitorizar de forma inmediata sin necesidad de crear canales de recopilación personalizados.
-
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
Tras instalar Container Insights, detecta CloudWatch automáticamente a NVIDIA GPUs en su entorno y recopila métricas críticas de estado y rendimiento. Estas métricas aparecen en out-of-the-box paneles seleccionados. También puede integrar Ray
Para obtener una lista completa de las métricas disponibles, consulte las métricas de Amazon EKS y Kubernetes Container Insights. Para obtener step-by-step orientación sobre la implementación de la supervisión de GPU, 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 necesita paneles personalizados y funciones de visualización avanzadas, implemente Prometheus con el exportador de DCGM de NVIDIA y Grafana para la supervisión nativa de Kubernetes.
Puede ampliar este conjunto de monitoreo integrando marcos de código abierto como Ray y vLLM Ray y vLLM
Para obtener step-by-step orientación sobre la implementación de esta pila de monitoreo, consulte Monitorización de 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
Supervise las métricas de entrenamiento principales para realizar un seguimiento del estado y el rendimiento de su clúster de Amazon EKS y de las cargas de trabajo de aprendizaje automático que se ejecutan en él. Las cargas de trabajo de entrenamiento tienen requisitos de monitoreo diferentes a los de las cargas de trabajo de inferencia porque se ejecutan durante períodos prolongados, consumen los recursos de manera diferente y requieren visibilidad de la convergencia de modelos y la eficiencia de la canalización de datos. Las siguientes métricas le ayudan a identificar los cuellos de botella, optimizar la asignación de recursos y garantizar que los trabajos de formación se completen correctamente. Para obtener step-by-step orientación sobre la implementación de este enfoque de monitoreo, 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
Supervise las métricas de uso de recursos para validar que sus recursos se consumen correctamente. Estas métricas le ayudan a identificar los cuellos de botella y las causas principales de los problemas de rendimiento.
-
CPU, memoria, red, potencia de la GPU y temperatura de la GPU: supervise estas métricas para asegurarse de que los recursos asignados satisfagan las demandas de carga de trabajo e identificar las oportunidades de optimización. Realiza un seguimiento de métricas como gpu_memory_usage_bytes para identificar los patrones de consumo de memoria y detectar los picos de uso. Calcula percentiles como el percentil 95 (P95) para comprender las demandas de memoria más altas durante el entrenamiento. Este análisis le ayuda a optimizar los modelos y la infraestructura para evitar errores de OOM y reducir los costes.
-
Ocupación de SM, FPxx actividad de SM, actividad: supervise estas métricas para comprender cómo se utiliza el recurso subyacente de la GPU. Como regla general
, márcate como meta 0,8 para SM Activity. -
Utilización de recursos de nodo y pod: realice un seguimiento del uso de los recursos a nivel de nodo y pod para identificar la contención de recursos y los posibles cuellos de botella. Supervise si los nodos se acercan a los límites de capacidad, lo que puede retrasar la programación de los módulos y ralentizar las tareas de entrenamiento.
-
Utilización de recursos en comparación con las solicitudes y los límites: compare el uso real de los recursos con las solicitudes y los límites configurados para determinar si su clúster puede gestionar las cargas de trabajo actuales y adaptarse a las futuras. Esta comparación revela si es necesario ajustar las asignaciones de recursos para evitar errores de OOM o desperdiciar recursos.
-
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, como TensorFlow y. PyTorch Estas métricas incluyen las curvas de pérdida, la tasa de aprendizaje, el tiempo de procesamiento por lotes y la duración de los pasos de entrenamiento. Visualice estas métricas con herramientas TensorBoard o herramientas similares para realizar un seguimiento de la convergencia de los modelos e identificar las ineficiencias de la formación.
Modele las métricas de rendimiento
Supervise las métricas de rendimiento de los modelos para validar que su proceso de formación produzca modelos que cumplan con los requisitos empresariales y de precisión. Estas métricas le ayudan a determinar cuándo interrumpir la formación, comparar las versiones de los modelos e identificar la degradación del rendimiento.
-
Exactitud, precisión, recuperación y puntuación de F1: realice un seguimiento de estas métricas para comprender el rendimiento de su modelo con los datos de validación. Calcule la puntuación F1 en un conjunto de validación después de cada período de entrenamiento para evaluar si el modelo está mejorando y cuándo alcanza los niveles de rendimiento aceptables.
-
Métricas específicas de la empresa y KPIs: defina y realice un seguimiento de las métricas que midan directamente el valor empresarial de sus iniciativas. AI/ML En el caso de un sistema de recomendaciones, haz un seguimiento de métricas como la tasa de clics o la tasa de conversión para asegurarte de que el modelo genere los resultados empresariales esperados.
-
Rendimiento a lo largo del tiempo: compare las métricas de rendimiento entre las versiones del modelo y las sesiones de entrenamiento para identificar las tendencias y detectar la degradación. Realice un seguimiento de si las versiones más recientes de los modelos mantienen o mejoran el rendimiento en comparación con los modelos de referencia. Esta comparación histórica le ayuda a decidir si desea implementar nuevos modelos o investigar los problemas de formación.
Calidad de los datos y métricas de desviación
Supervisa la calidad de los datos y las métricas de desviación para asegurarte de que los datos de entrenamiento sean consistentes y representativos. La desviación de los datos puede provocar que el rendimiento del modelo se degrade con el tiempo, mientras que los problemas de calidad de los datos pueden impedir la convergencia de los modelos o producir resultados poco fiables.
-
Propiedades estadísticas de los datos de entrada: realice un seguimiento de las propiedades estadísticas, como la media, la desviación estándar y la distribución de las entidades de entrada a lo largo del tiempo, para detectar desviaciones o anomalías en los datos. Supervisa si las distribuciones de las funciones varían significativamente con respecto a tus datos de entrenamiento de referencia. Por ejemplo, si la media de una característica crítica cambia en más de dos desviaciones estándar, investigue si su flujo de datos ha cambiado o si la fuente de datos subyacente ha cambiado.
-
Detección de desviaciones de datos y alertas: Implemente mecanismos automatizados para detectar y alertar sobre los problemas de calidad de los datos antes de que afecten a la formación. Usa pruebas estadísticas, como la prueba de Kolmogorov-Smirnov o la prueba de chi-cuadrado, para comparar las distribuciones de datos actuales con tus datos de entrenamiento originales. Configura alertas cuando las pruebas detecten una desviación significativa para poder volver a entrenar los modelos con datos actualizados o investigar los problemas relacionados con la canalización de datos.
Métricas de latencia y rendimiento
Supervisa las métricas de latencia y rendimiento para identificar los cuellos de botella en tu proceso de formación y optimizar la utilización de los recursos. Estas métricas te ayudan a entender a qué se dedica el tiempo durante la formación y dónde centrar los esfuerzos de optimización.
-
End-to-End Latencia de los procesos de formación en aprendizaje automático: mide el tiempo total que tardan los datos en fluir por todo el proceso de formación, desde la ingesta de datos hasta la actualización del modelo. Realiza un seguimiento de esta métrica en todas las sesiones de entrenamiento para identificar si los cambios en el proceso mejoran o degradan el rendimiento. Una latencia alta suele indicar cuellos de botella en la carga de datos, el preprocesamiento o la comunicación de red entre los nodos.
-
Rendimiento y tasa de procesamiento de la formación: haga un seguimiento del volumen de datos que procesa su proceso de formación por unidad de tiempo para garantizar una utilización eficiente de los recursos. Supervisa métricas como las muestras procesadas por segundo o los lotes completados por minuto. El bajo rendimiento en relación con la capacidad del hardware sugiere ineficiencias en la carga de datos, el preprocesamiento o la computación de modelos que desperdician los ciclos de la GPU.
-
Latencia de almacenamiento y restauración de puntos de control: supervise el tiempo necesario para guardar los puntos de control del modelo en el almacenamiento (S3, EFS FSx) y restaurarlos en la memoria de la GPU o la CPU cuando se reanuden los trabajos o se recuperen de errores. Las operaciones lentas de los puntos de control prolongan el tiempo de recuperación del trabajo y aumentan los costes. Realice un seguimiento del tamaño de los puntos de control, ahorre la duración, la duración de la restauración y el recuento de errores para identificar oportunidades de optimización, como la compresión o los niveles de almacenamiento más rápidos.
-
Tiempo de carga y preprocesamiento de los datos: mida el tiempo dedicado a cargar los datos del almacenamiento y a aplicar las transformaciones previas al procesamiento. Compare este tiempo con el tiempo de cálculo del modelo para determinar si su entrenamiento se basa en los datos o en el cómputo. Si la carga de datos consume más del 20% del tiempo total de entrenamiento, considere la posibilidad de optimizar la canalización de datos mediante el almacenamiento en caché, la captura previa o un almacenamiento más rápido.
Tasas de errores y errores
Supervise las tasas de error y las fallas a lo largo de su proceso de capacitación para mantener la confiabilidad y evitar el desperdicio de recursos informáticos. Los errores no detectados pueden provocar que los trabajos de formación fallen silenciosamente, que se produzcan modelos no válidos o que se desperdicien horas de tiempo en la GPU antes de que se detecten problemas.
-
Supervisión de errores en la canalización: realiza un seguimiento de los errores en todas las etapas de tu proceso de aprendizaje automático, incluido el preprocesamiento de datos, el entrenamiento con modelos y las operaciones de puntos de control. Registra los tipos de errores, las frecuencias y los componentes afectados para identificar rápidamente los problemas. Entre los errores más comunes se incluyen las discordancias en el formato de los datos, out-of-memory los errores durante el preprocesamiento y los errores en los puntos de control debidos a los límites de almacenamiento. Configure alertas cuando las tasas de error superen los umbrales de referencia para poder investigar antes de que los errores se generen en cascada.
-
Análisis de errores recurrentes: identifique e investigue los patrones de los errores recurrentes para evitar futuros fallos y mejorar la fiabilidad de las tuberías. Analice los registros para determinar si las muestras de datos específicas, los tamaños de los lotes o las configuraciones de entrenamiento causan errores de manera constante. Por ejemplo, si algunos tipos de datos de entrada provocan errores de preprocesamiento, añada comprobaciones de validación en una fase más temprana del proceso o actualice la lógica de limpieza de datos. Realiza un seguimiento del tiempo medio entre fallos (MTBF) para medir si la fiabilidad de tu canalización mejora con el tiempo. »
Métricas específicas de Kubernetes y EKS
Supervise las métricas de Kubernetes y EKS para garantizar que la infraestructura de su clúster se mantenga en buen estado y pueda soportar sus cargas de trabajo de formación. Estas métricas le ayudan a detectar problemas de infraestructura antes de que provoquen fallos en las tareas de formación o una degradación del rendimiento.
-
Métricas del estado de los clústeres de Kubernetes: supervise el estado y el estado de los objetos de Kubernetes, incluidos los pods, los nodos, las implementaciones y los servicios. Realice un seguimiento del estado de los pods para identificar los pods que se encuentran en estado pendiente, fallido o en bucle de bloqueo. Supervisa el estado de los nodos para detectar problemas como la presión del disco, la presión de la memoria o la falta de disponibilidad de la red. Usa kubectl o las herramientas de monitoreo para comprobar estas métricas de forma continua y configurar alertas cuando los pods no se inicien o los nodos no se puedan programar.
-
Métricas de ejecución de la canalización de formación: realice un seguimiento de las ejecuciones de canalizaciones correctas y fallidas, la duración de los trabajos, los tiempos de finalización de los pasos y los errores de orquestación. Supervise si los trabajos de formación se completan dentro de los plazos esperados y si las tasas de fallos aumentan con el tiempo. Realice un seguimiento de métricas como la tasa de éxito laboral, la duración media del trabajo y el tiempo transcurrido hasta el fracaso. Estas métricas le ayudan a identificar si los problemas de infraestructura, los problemas de configuración o los problemas de calidad de los datos provocan fallos en la formación.
-
Estadísticas de servicios de AWS: realice un seguimiento de las métricas de los servicios de AWS que respaldan su infraestructura de EKS y sus cargas de trabajo de formación. Supervise las métricas de S3, como la latencia de las solicitudes, las tasas de error y el rendimiento, para garantizar que el rendimiento de la carga de datos se mantenga constante. Realice un seguimiento de las métricas de volumen de EBS, incluidas las IOPS, el rendimiento y la longitud de las colas, para detectar cuellos de botella en el almacenamiento. Supervise los registros de flujo de la VPC y las métricas de la red para identificar los problemas de conectividad entre los nodos o con los servicios externos.
-
Métricas del plano de control de Kubernetes: supervise el servidor de la API, el programador, el administrador del controlador y la base de datos, etc., para detectar problemas o fallas de rendimiento que afecten a las operaciones del clúster. Realice un seguimiento de la latencia de las solicitudes del servidor API, la tasa de solicitudes y la tasa de errores para garantizar que el plano de control responda rápidamente a las solicitudes de programación. Supervise el tamaño de la base de datos etcd, la duración de las confirmaciones y los cambios principales para detectar problemas de estabilidad. La alta latencia del servidor API o los cambios frecuentes de líderes de etcd pueden retrasar la programación de los módulos y prolongar los tiempos de inicio de los trabajos de formación.
Registros de aplicaciones e instancias
Recopile y analice los registros de aplicaciones e instancias para diagnosticar problemas que las métricas por sí solas no pueden explicar. Los registros proporcionan un contexto detallado sobre los errores, los cambios de estado y los eventos del sistema que le ayudan a comprender por qué los trabajos de formación fallan o tienen un rendimiento deficiente. Al correlacionar los registros con las métricas, puede identificar las causas fundamentales con mayor rapidez.
-
Registros de aplicaciones: Recopile los registros de las aplicaciones de sus trabajos de formación, flujos de datos y marcos de aprendizaje automático para identificar los cuellos de botella y diagnosticar los fallos. Estos registros recopilan información detallada sobre la ejecución de los trabajos, incluidos los errores de carga de datos, los errores de inicialización del modelo, los errores al guardar los puntos de control y las advertencias específicas del marco. Correlaciona las marcas temporales del registro con los picos de las métricas para entender qué causó la degradación o los fallos del rendimiento. Por ejemplo, si el uso de la GPU disminuye repentinamente, compruebe los registros de la aplicación para ver si hay errores que indiquen un estancamiento en la canalización de datos o errores de preprocesamiento. Utilice herramientas de registro centralizadas, como CloudWatch Logs o Fluent Bit, para agregar los registros de todos los pods y hacer que se puedan buscar en ellos.
-
Registros de instancias: Recopile registros a nivel de instancia, como los registros del diario del sistema y los resultados de dmesg, para detectar problemas de hardware y problemas a nivel de núcleo. Estos registros revelan problemas como los errores del controlador de la GPU, los errores de asignación de memoria, los errores de disco I/O y los problemas de la interfaz de red, que pueden no aparecer en los registros de las aplicaciones. Correlaciona los registros de las instancias con los registros y las métricas de las aplicaciones para determinar si los errores de entrenamiento se deben a problemas de hardware o a problemas con las aplicaciones. Por ejemplo, si un trabajo de entrenamiento no funciona debido a un out-of-memory error, compruebe en los registros dmesg los mensajes que indican si el sistema se ha quedado sin memoria o si la aplicación ha superado sus límites de contenedores. Configura alertas en caso de errores de hardware críticos, como errores XID de la GPU o fallos de disco, para poder sustituir las instancias defectuosas antes de que provoquen interrupciones generalizadas en el entrenamiento.
En las siguientes secciones se muestra cómo recopilar las métricas descritas anteriormente mediante dos enfoques recomendados por AWS: CloudWatch Container Insights y Amazon Managed Prometheus Amazon Managed Prometheus with Amazon Managed Grafana. Elija CloudWatch Container Insights si prefiere herramientas nativas de AWS con una configuración mínima y paneles prediseñados. Elija Amazon Managed Prometheus con Amazon Managed Grafana si necesita paneles personalizados, capacidades de visualización avanzadas o si desea integrarlos con la infraestructura de monitoreo existente basada en Prometheus. Para obtener una lista completa de las métricas de Container Insights disponibles, consulte las métricas de Amazon EKS y Kubernetes Container Insights.
Considere la posibilidad de monitorear las métricas de inferencias 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é: en el caso de 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. Los siguientes ejemplos muestran 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
