En esta guía de prácticas recomendadas se muestran las métricas disponibles y cómo seleccionar las métricas adecuadas para configurar el autoescalador horizontal de pods(HPA) de tus cargas de trabajo de inferencia de JetStream de un solo host con TPUs en GKE. HPA es una forma eficaz de asegurarse de que los servidores de su modelo se escalan adecuadamente en función de la carga. Ajustar la configuración de HPA es la forma principal de alinear el coste del hardware aprovisionado con las demandas de tráfico para alcanzar los objetivos de rendimiento del servidor de inferencia.
Para ver ejemplos de cómo implementar estas prácticas recomendadas, consulta Configurar el autoescalado de cargas de trabajo de LLM en TPUs con GKE.
Objetivos
Esta guía está dirigida a clientes de IA generativa, usuarios nuevos o actuales de GKE, ingenieros de aprendizaje automático e ingenieros de LLMOps (DevOps) que quieran optimizar sus cargas de trabajo de JetStream de un solo host mediante TPUs con Kubernetes.
Después de leer esta guía, podrás hacer lo siguiente:
- Conocer las métricas clave de escalado automático para la inferencia de JetStream de un solo host.
- Conocer las ventajas y desventajas generales a la hora de elegir las métricas para el autoescalado.
Información general sobre las métricas de autoescalado para la inferencia de JetStream
Te recomendamos que utilices las siguientes métricas:
Métricas del servidor
JetStream, al igual que muchos otros servidores de inferencia de LLMs, proporciona métricas de rendimiento. GKE simplifica la monitorización y el escalado automático de JetStream en función de estas métricas a nivel de servidor. Para configurar el autoescalado, primero debes entender cómo influye la canalización de solicitudes de JetStream en los indicadores clave de rendimiento. Todas las solicitudes entrantes pasan por una cola de relleno previo, una cola de transferencia y una cola de generación, y luego se convierten en una solicitud de decodificación. JetStream acepta solicitudes de decodificación de forma continua y las procesa simultáneamente con un número fijo de hilos de decodificación. El porcentaje de motores de decodificación ocupados en gestionar una solicitud de decodificación en un momento dado se mide con la métrica jetstream_slots_used_percentage.
En el caso del escalado de JetStream de un solo host, esto tiene dos implicaciones para la latencia y el rendimiento:
- Las solicitudes no se acumularán en las colas si la frecuencia de las solicitudes entrantes es inferior a la frecuencia con la que las ranuras de decodificación pueden procesarlas. Si JetStream no tiene trabajo pendiente, el rendimiento será proporcional a la tasa de solicitudes entrantes. La latencia se mantendrá prácticamente constante, pero aumentará ligeramente y de forma proporcional al número de solicitudes de decodificación simultáneas, ya que las solicitudes de decodificación recién aceptadas interrumpirán la decodificación.
- Las solicitudes se acumularán en las colas cuando la frecuencia de las solicitudes entrantes supere la frecuencia a la que las ranuras de decodificación puedan procesarlas. Si JetStream tiene un trabajo pendiente, la latencia de las solicitudes aumentará de forma más significativa y proporcional al número de solicitudes pendientes, mientras que el rendimiento se mantendrá constante.
Las siguientes métricas de servidor son las que tienen una mayor correlación con estos indicadores de rendimiento relevantes, por lo que te recomendamos que las uses para el ajuste automático de escala:
jetstream_prefill_backlog_size: número de solicitudes pendientes de procesar en la cola del servidor (trabajo pendiente). Esta métrica tiene una correlación estrecha con la latencia. Para obtener más información, consulta la sección de prácticas recomendadas relacionada.jetstream_slots_used_percentage: número de solicitudes que se están sometiendo a inferencia como porcentaje del número total de solicitudes que JetStream puede gestionar. Esta métrica tiene una correlación sólida con el rendimiento. Para obtener más información, consulta la sección de prácticas recomendadas relacionada.
Estas métricas suelen ser resistentes a las fluctuaciones del rendimiento y del tráfico, por lo que son un punto de partida fiable para el escalado automático en diversas configuraciones de hardware de TPU.
Métricas de TPU
Dado que el servicio de LLMs se ve limitado por la memoria y no por la computación, te recomendamos que escales JetStream con el uso de la memoria en lugar de con otras métricas de TPU, ya que refleja mejor la utilización de los recursos del hardware. Para obtener más información, consulta la sección de prácticas recomendadas relacionada.
Consideraciones para elegir las métricas de autoescalado
Ten en cuenta las siguientes consideraciones y prácticas recomendadas para seleccionar la mejor métrica de autoescalado en GKE y alcanzar tus objetivos de rendimiento de la carga de trabajo de inferencia.
Práctica recomendada: Usa el tamaño de la cartera de pedidos (cola) de relleno automático para maximizar el rendimiento y minimizar los costes dentro de un determinado umbral de latencia objetivo
Recomendamos usar el ajuste automático de la escala del tamaño de la cola de relleno automático cuando se optimizan el rendimiento y el coste, y cuando se pueden alcanzar los objetivos de latencia con el rendimiento máximo del tamaño de lote por dispositivo del servidor del modelo.
El tamaño de la cola de relleno previo se correlaciona directamente con la latencia de las solicitudes. Las solicitudes entrantes se ponen en cola en la cola de relleno previo de los servidores del modelo antes de procesarse, y este tiempo de cola se suma a la latencia general. El tamaño de la cola es un indicador sensible de los picos de carga, ya que el aumento de la carga llena rápidamente la cola.
El autoescalado basado en el tamaño de la cola de relleno previo minimiza el tiempo de espera de la cola aumentando la escala cuando hay carga y reduciéndola cuando la cola está vacía. Este enfoque es relativamente fácil de implementar porque el tamaño de la cola es independiente del tamaño de la solicitud, del modelo o del hardware.
Si quieres maximizar el rendimiento de cada réplica del servidor de modelos, te recomendamos que te centres en el tamaño de la cola de relleno previo. El tamaño de la cola de relleno previo registra las solicitudes pendientes, no las que se están procesando. JetStream usa la creación de lotes continua, lo que maximiza las solicitudes simultáneas y mantiene la cola baja cuando hay espacio disponible en los lotes. La cola aumenta considerablemente cuando el espacio de los lotes es limitado, por lo que debe usar el punto de crecimiento como señal para iniciar el aumento de la escala. Si combinas el autoescalado del tamaño de la cola con el rendimiento optimizado de los lotes, puedes maximizar el rendimiento de las solicitudes.
Determinar el valor de umbral de tamaño de cola óptimo para HPA
Para elegir el umbral de tamaño de cola correcto, empieza con un valor entre 3 y 5 y auméntalo gradualmente hasta que las solicitudes alcancen la latencia preferida. Usa la herramienta locust-load-inference para hacer pruebas. En el caso de los umbrales inferiores a 10, ajusta la configuración de ampliación de HPA para gestionar los picos de tráfico.
También puedes crear un panel de Cloud Monitoring personalizado para visualizar el comportamiento de la métrica.
Limitaciones
Ten en cuenta la tolerancia de HPA, que tiene un valor predeterminado de 0,1 en el intervalo de inactividad alrededor del valor objetivo para reducir la oscilación.
El tamaño de la cola de relleno previo no controla directamente las solicitudes simultáneas, por lo que su umbral no puede garantizar una latencia inferior a la que permite el tamaño de lote por dispositivo. Como solución alternativa, puedes reducir manualmente el tamaño de lote por dispositivo o escalar automáticamente el tamaño de lote.
Práctica recomendada: Usa el porcentaje de slots_used para alcanzar umbrales de latencia objetivo más bajos que el tamaño de la cola
Te recomendamos que elijas el autoescalado basado en slots_used si tienes cargas de trabajo sensibles a la latencia en las que el escalado basado en colas no es lo suficientemente rápido como para cumplir tus requisitos.
El ajuste automático de la escala en slots_used asegura que el rendimiento de tus cargas de trabajo aumente para maximizar el número de solicitudes que se procesan en paralelo a la vez y que se reduzca cuando haya menos solicitudes que se procesen en paralelo. Esto tiene dos implicaciones para la latencia. En primer lugar, dado que el escalado automático basado en slots_used se escala para asegurar un espacio para cada solicitud entrante, la proximidad del umbral a 1 se corresponderá con la probabilidad de que una solicitud pase tiempo en la cola y, por lo tanto, tenga una latencia mayor. En segundo lugar, los tamaños de lote más grandes aumentan el rendimiento, pero también la latencia, debido a que la fase de relleno previo de algunas solicitudes interrumpe la fase de decodificación de otras en los servidores del modelo de procesamiento por lotes continuo. Puedes monitorizar los patrones de tamaño de lote y usar el autoescalado para minimizar las solicitudes simultáneas durante los picos de carga.
Si el tamaño de la cola ya cumple tus objetivos de latencia, priorízala para el escalado automático. De esta forma, se maximizan tanto el rendimiento como la rentabilidad. Sin embargo, slots_used es útil para las cargas de trabajo sensibles a la latencia.
También te recomendamos que ajustes el tamaño de lote por dispositivo a un valor adecuado antes de explorar el autoescalado basado en slots_used. También puedes combinarlo con el escalado automático basado en colas.
Determina el valor de umbral óptimo del porcentaje slots_used para HPA
Para elegir el umbral de tamaño de lote adecuado, aumenta experimentalmente la carga de tu servidor y observa dónde alcanza el máximo el tamaño del lote. También te recomendamos que uses la herramienta locust-load-inference para hacer pruebas. Una vez que haya identificado el tamaño de lote óptimo por dispositivo en el que se maximiza el uso de la memoria, puede configurar el porcentaje objetivo de slots_used. Define el valor objetivo inicial ligeramente por debajo de 1 y redúcelo hasta que se alcance la latencia preferida.
También puedes crear un panel de Cloud Monitoring personalizado para visualizar el comportamiento de la métrica.
Limitaciones
Ten en cuenta la tolerancia de HPA, que es un intervalo de inacción predeterminado de 0,1 alrededor del valor objetivo para reducir la oscilación.
El autoescalado basado en el porcentaje de slots_used, aunque es útil para controlar la latencia, tiene limitaciones. Debido a las variaciones en los tamaños de las solicitudes y a las limitaciones de hardware, es difícil encontrar el umbral de porcentaje de slots_used adecuado. Si una regla de escalado intenta mantener el porcentaje medio de slots_used por debajo del 100 %, significa que está intentando mantener un número de slots disponibles distinto de cero. Estas ranuras disponibles corresponden al rendimiento disponible que no se está utilizando, lo cual no es ideal si quieres aprovechar al máximo tus TPUs disponibles.
Práctica recomendada: Usa la memoria de alto ancho de banda (HBM) de la TPU para maximizar el uso del hardware
El uso de la memoria de alto ancho de banda (HBM) de la TPU es lo que más se corresponde directamente con la utilización del hardware, incluso en comparación con las métricas del sistema, ya que no tienen en cuenta los tamaños de las solicitudes. Aunque el escalado con el tamaño de la cola maximiza mejor la utilización del hardware, lo hará a costa de la latencia. Si prefieres usar métricas del sistema en lugar de métricas del servidor, te recomendamos que uses el uso de HBM como la mejor alternativa para el ajuste de escala automático con slots_used, ya que ambos corresponden al rendimiento. Para obtener más información sobre la memoria de las TPU, consulta Cómo funciona una TPU.
Si aumentas el tamaño del lote más allá del punto óptimo, se mejora el rendimiento, pero también aumenta el riesgo de que se produzcan errores de falta de memoria. Te recomendamos que escales en función de la métrica HBM para equilibrar el rendimiento y la estabilidad. Te recomendamos que no escales al mismo tiempo con el tamaño de la cola de relleno previo y el uso de HBM, ya que, a medida que aumente la carga, el uso de HBM también lo hará y activará el escalado primero.
Determinar el valor de umbral de uso de HBM de TPU óptimo para HPA
Antes de elegir el umbral de uso de memoria, te recomendamos que definas el tamaño de lote por dispositivo en un valor que maximice la memoria utilizada cuando se opere con la carga máxima prevista. Ten en cuenta que este valor se debe determinar de forma experimental y dependerá en gran medida de la HBM total, así como de las longitudes esperadas de las peticiones y las respuestas. Te recomendamos que uses la herramienta locust-load-inference para tus experimentos y pruebas.
Al igual que con el tamaño de lote por dispositivo, define el umbral para maximizar la utilización de la memoria de la TPU y minimizar el riesgo de que se produzca un error de falta de memoria.
También puedes crear un panel de Cloud Monitoring personalizado para visualizar el comportamiento de la métrica.
Limitaciones
Hay dos advertencias que reducen la intensidad con la que la latencia y el rendimiento se corresponden con el uso de HBM: la volatilidad del uso de HBM y la menor frecuencia de muestreo de las métricas de TPU en general. Además, aunque sigue habiendo una correspondencia entre el uso de HBM y la latencia, los aumentos en el uso de HBM afectan a la latencia mucho menos que los aumentos en el número de solicitudes en cola.
Práctica recomendada: optimizar la configuración de HPA
Te recomendamos que definas estas opciones de configuración de HPA:
- Ventana de estabilización: usa esta opción de configuración de HPA para evitar cambios rápidos en el número de réplicas debido a las fluctuaciones de las métricas. Los valores predeterminados son 5 minutos para la reducción (para evitar que se produzca demasiado pronto) y 0 para el aumento (para asegurar la capacidad de respuesta). Ajusta el valor en función de la volatilidad de tus cargas de trabajo y de la capacidad de respuesta que prefieras.
- Políticas de escalado: usa esta opción de configuración de HPA para ajustar el comportamiento de escalado vertical y horizontal. Puedes definir el límite de la política "Pods" para especificar el número absoluto de réplicas que se cambian por unidad de tiempo, y el límite de la política "Porcentaje" para especificar el cambio porcentual.
Para obtener más información sobre estas opciones, consulta Autoescalado horizontal de pods en la documentación de Kubernetes de código abierto.