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 Horizontal Pod Autoscaler (HPA) para tus cargas de trabajo de inferencia de JetStream de un solo host con TPU en GKE. El HPA es una forma eficiente de garantizar que los servidores de tu modelo se escalen de forma adecuada con la carga. El ajuste fino de la configuración de la HPA es la forma principal de alinear el costo 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 Cómo configurar el ajuste de escala automático para cargas de trabajo de LLM en TPUs con GKE.
Objetivos
Esta guía está dirigida a clientes de IA generativa, usuarios nuevos o existentes de GKE, ingenieros de AA y, también, ingenieros de LLMOps (DevOps) que estén interesados en optimizar sus cargas de trabajo de JetStream de host único con TPU con Kubernetes.
Después de leer esta guía, deberías poder hacer lo siguiente:
- Comprende las métricas clave del ajuste de escala automático para la inferencia de JetStream de host único.
- Comprende las compensaciones de alto nivel cuando consideres en qué métricas realizar el ajuste de escala automático.
Descripción general de las métricas de ajuste de escala automático para la inferencia de JetStream
Recomendamos usar las siguientes métricas:
Métricas del servidor
JetStream, como muchos otros servidores de inferencia de LLM, proporciona métricas de rendimiento. GKE simplifica la supervisión y el ajuste de escala automático de JetStream según estas métricas a nivel del servidor. Para configurar cualquier ajuste de escala automático, primero debes comprender cómo la canalización de solicitudes de JetStreams influye en los indicadores clave de rendimiento. Todas las solicitudes entrantes se mueven por una cola de llenado previo, una cola de transferencia, generan una cola y, luego, se convierten en una solicitud de decodificación. JetStream acepta solicitudes de decodificación de forma continua y las procesa de forma simultánea con una cantidad fija de subprocesos de decodificación. El porcentaje de motores de decodificación ocupados con el manejo de una solicitud de decodificación en un momento determinado se mide como la métrica jetstream_slots_used_percentage.
Para el escalamiento de JetStream de host único, esto tiene dos implicaciones para la latencia y la capacidad de procesamiento:
- Las solicitudes no se quedarán atrasadas en las listas si la tasa de solicitudes que ingresan es menor que la velocidad en la que las ranuras de decodificación pueden procesar las solicitudes. Si JetStream no tiene tareas pendientes, la capacidad de procesamiento será proporcional a la tasa de solicitudes entrantes. La latencia seguirá siendo constante, pero aumentará ligeramente y proporcionalmente a la cantidad 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 una vez que la tasa de solicitudes que ingresen supere la velocidad a la que las ranuras decodificadas pueden procesar las solicitudes. Si JetStream tiene un trabajo pendiente, la latencia de la solicitud aumentará de forma más significativa y proporcional a la cantidad de solicitudes en cola, mientras que la capacidad de procesamiento permanecerá constante.
Las siguientes métricas de servidor tendrán la correlación más sólida con estos indicadores de rendimiento relevantes. Te recomendamos que las uses para el ajuste de escala automático:
jetstream_prefill_backlog_size: La cantidad de solicitudes en espera de procesamiento en la cola del servidor (tareas pendientes). Esta métrica tiene una fuerte correlación con la latencia. Para obtener más información, consulta la sección de prácticas recomendadas relacionada.jetstream_slots_used_percentage: La cantidad de solicitudes que se someten a inferencia como un porcentaje de la cantidad total de solicitudes que JetStream puede manejar. Esta métrica tiene una fuerte correlación con la capacidad de procesamiento. Para obtener más información, consulta la sección de prácticas recomendadas relacionada.
Estas métricas suelen ser resilientes a las fluctuaciones de rendimiento y tráfico, lo que las convierte en un punto de partida confiable para el ajuste de escala automático en diversas configuraciones de hardware de TPU.
Métricas de TPU
Dado que la entrega de LLM tiene un cuello de botella por la memoria y no por el procesamiento, te recomendamos que escales JetStream con el uso de memoria en lugar de con otras métricas de TPU, ya que refleja mejor el uso de recursos del hardware. Para obtener más información, consulta la sección de prácticas recomendadas relacionada.
Consideraciones para elegir tus métricas de ajuste de escala automático
Usa las siguientes consideraciones y prácticas recomendadas para seleccionar la mejor métrica para el ajuste de escala automático en GKE para cumplir con tus objetivos de rendimiento de la carga de trabajo de inferencia.
Práctica recomendada: Usa el tamaño de las tareas pendientes (cola) de llenado preivo para maximizar la capacidad de procesamiento y minimizar el costo dentro de un umbral de latencia objetivo determinado
Te recomendamos que uses el ajuste de escala automático del tamaño de la cola de reabastecimiento cuando optimices la capacidad de procesamiento y el costo, y cuando tus objetivos de latencia se puedan alcanzar con la capacidad de procesamiento máxima del tamaño del lote por dispositivo del servidor de modelos.
El tamaño de la cola de llenado previo se correlaciona directamente con la latencia de la solicitud. Las solicitudes entrantes se ponen en cola en la cola de llenado previo de los servidores del modelo antes de que se procesen, y este tiempo de cola se agrega a la latencia general. El tamaño de la cola es un indicador sensible de los aumentos repentinos de carga, ya que el aumento de la carga llena rápidamente la cola.
El ajuste de escala automático basado en el tamaño de la cola de llenado previo minimiza el tiempo de la cola mediante el escalamiento vertical bajo carga y el escalamiento vertical 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, el modelo o el hardware.
Considera enfocarte en el tamaño de la cola de reabastecimiento si deseas maximizar la capacidad de procesamiento de cada réplica del servidor de modelos. El tamaño de la cola de llenado previo hace seguimiento de las solicitudes pendientes, sin procesar. JetStream usa el procesamiento por lotes continuo, que maximiza las solicitudes simultáneas y mantiene la cola baja cuando hay espacio de lote disponible. La cola crece de forma notable cuando el espacio por lote es limitado, por lo que debes usar el punto de crecimiento como un indicador para iniciar el escalamiento. Si combinas el ajuste de escala automático del tamaño de las colas con la capacidad de procesamiento por lotes optimizada, puedes maximizar la capacidad de procesamiento de la solicitud.
Determina el valor de umbral de tamaño de cola óptimo para HPA
Para elegir el umbral de tamaño correcto de la cola, comienza 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 realizar pruebas. Para umbrales inferiores a 10, ajusta la configuración de escalamiento vertical del HPA a fin de controlar los aumentos repentinos de tráfico.
También puedes crear un panel personalizado de Cloud Monitoring para visualizar el comportamiento de la métrica.
Limitaciones
Ten en cuenta la tolerancia del HPA, que se establece de forma predeterminada en un rango de no acción de 0.1 alrededor del valor objetivo para disminuir la oscilación.
El tamaño de la cola de llenado previo no controla directamente las solicitudes simultáneas, por lo que su umbral no puede garantizar una latencia más baja que 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 ajustar el escalamiento automático en función del tamaño del lote.
Práctica recomendada: Usa el porcentaje de slots_used para alcanzar los umbrales de latencia objetivo más bajos que el tamaño de la cola
Recomendamos elegir el ajuste de escala automático basado en slots_used si tienes cargas de trabajo sensibles a la latencia en las que el escalamiento basado en colas no es lo suficientemente rápido para cumplir con tus requisitos.
El ajuste de escala automático en slots_used garantiza que el la capacidad de procesamiento de tus cargas de trabajo aumente para maximizar la cantidad de solicitudes que se procesan en paralelo a la vez y disminuya cuando haya menos solicitudes que se procesen en paralelo. Esto tiene dos implicaciones para la latencia. En primer lugar, debido a que el ajuste de escala automático basado en slots_used se escala para garantizar una ranura para cada solicitud entrante, el nivel de cercanía entre el umbral establecido y 1 corresponderá a la probabilidad de que una solicitud pase un tiempo en cola y, por lo tanto, tenga una latencia más alta. En segundo lugar, los tamaños de lote más grandes aumentan la capacidad de procesamiento, pero también aumentan la latencia debido a la fase de llenado previo de algunas solicitudes que interrumpe la fase de decodificación de otras en los servidores de modelos de procesamiento por lotes continuo. Puedes supervisar los patrones de tamaño del lote y usar el ajuste de escala automático para minimizar las solicitudes simultáneas durante los aumentos repentinos de carga.
Si el tamaño de la cola ya cumple con tus objetivos de latencia, priorízalo para el ajuste de escala automático. Esto maximiza la capacidad de procesamiento y la rentabilidad. Sin embargo, slot_used es valioso para las cargas de trabajo sensibles a la latencia.
También recomendamos ajustar el tamaño del lote por dispositivo a un valor adecuado antes de explorar el ajuste de escala automático basado en slots_used. De manera opcional, también puedes vincularlo con el ajuste de escala automático basado en filas.
Determina el valor de umbral óptimo de slots_used para el HPA
Para elegir el umbral de tamaño de lote correcto, aumenta de forma experimental la carga en tu servidor y observa el punto máximo que alcanza el tamaño de lote. También te recomendamos que uses la herramienta locust-load-inference para realizar pruebas. Una vez que hayas identificado un tamaño de lote óptimo por dispositivo en el que se maximiza el uso de la memoria, puedes configurar tu objetivo de porcentaje de slots_used. Establece el valor objetivo inicial un poco por debajo de 1 y disminúyelo hasta que se alcance la latencia preferida.
También puedes crear un panel personalizado de Cloud Monitoring para visualizar el comportamiento de la métrica.
Limitaciones
Ten en cuenta la tolerancia del HPA, que es un rango predeterminado de no acción de 0.1 alrededor del valor objetivo para disminuir la oscilación.
El ajuste de escala automático en el porcentaje de slots_used, si bien es útil para el control de la latencia, tiene limitaciones. Los diversos tamaños de solicitudes y restricciones de hardware dificultan la búsqueda del umbral de porcentaje correcto de slots_used. Tener una regla de escalamiento que intenta mantener el porcentaje promedio de slots_used por debajo del 100% significa que la regla de escalamiento intenta mantener un número de ranuras disponibles distinto de cero. Estos espacios disponibles corresponden a la capacidad de procesamiento disponible que no se está utilizando, lo que no es ideal si deseas aprovechar al máximo tus TPU disponibles.
Práctica recomendada: Usa la memoria de ancho de banda alto (HBM) de TPU para maximizar el uso de hardware
El uso de memoria de gran ancho de banda (HBM) de TPU tiene la correspondencia más directa con el uso de hardware, incluso en comparación con las métricas del sistema, ya que no tienen en cuenta los tamaños de las solicitudes. Si bien el escalamiento con el tamaño de la cola maximiza mejor el uso de hardware, lo hará a expensas de la latencia. Si prefieres usar métricas del sistema en lugar de métricas del servidor, te recomendamos que uses HBM como la mejor alternativa para el ajuste de escala automático con slots_used, ya que ambas corresponden con la capacidad de procesamiento. Para obtener más información sobre la memoria de las TPU, consulta Cómo funciona una TPU.
Aumentar el tamaño del lote más allá del punto óptimo mejora la capacidad de procesamiento, pero también aumenta el riesgo de errores de memoria insuficiente (OOM). Recomendamos el escalamiento basado en la métrica de HBM para equilibrar la capacidad de procesamiento y la estabilidad. Te recomendamos que no escales con el tamaño de la cola de reabastecimiento y el uso de HBM al mismo tiempo, ya que, a medida que aumenta la carga, el uso de HBM aumentará y activará la escala primero.
Determina el valor óptimo del umbral de uso de HBM de TPU para HPA
Antes de elegir el umbral de uso de memoria, te recomendamos que configures el tamaño del lote por dispositivo en un valor que maximice la memoria utilizada cuando se opera con la carga máxima esperada. Ten en cuenta que este valor deberá determinarse de forma experimental y dependerá en gran medida de HBM total, así como de las longitudes de instrucciones y respuestas esperadas. Te recomendamos usar la herramienta locust-load-inference para experimentar y realizar pruebas.
Al igual que con el tamaño del lote por dispositivo, configura el umbral para maximizar el uso de memoria de TPU y, al mismo tiempo, minimizar el riesgo de comportamiento de OOM.
También puedes crear un panel personalizado de Cloud Monitoring para visualizar el comportamiento de la métrica.
Limitaciones
Hay dos advertencias que disminuyen la intensidad con la que la latencia y la capacidad de procesamiento se corresponden con el uso de HBM, es decir, la volatilidad del uso de HBM y la menor tasa de muestreo de las métricas de TPU en general. Además, aunque todavía hay una correspondencia entre el uso de HBM y la latencia, los aumentos en la latencia de impacto de uso de HBM son mucho menores que los aumentos en la cantidad de solicitudes en cola.
Práctica recomendada: Optimiza la configuración del HPA
Recomendamos establecer estas opciones de configuración del HPA:
- Período de estabilización: Usa esta opción de configuración del HPA para evitar cambios rápidos en el recuento de réplicas debido a métricas fluctuantes. Los valores predeterminados son de 5 minutos para la reducción de escala (lo que evita una reducción de escala prematura) y 0 para escalamiento vertical (lo que garantiza la capacidad de respuesta). Ajusta el valor según la volatilidad de tus cargas de trabajo y tu capacidad de respuesta preferida.
- Políticas de escalamiento: Usa esta opción de configuración de HPA para ajustar el comportamiento de escalamiento vertical y horizontal. Puedes establecer el límite de la política "Pods" para especificar la cantidad absoluta de réplicas que se cambiaron por unidad de tiempo y el límite de la política "Porcentaje" para especificarlo por el cambio porcentual.
Para obtener más información sobre estas opciones, consulta Ajuste automático de escala horizontal de Pods en la documentación de código abierto de Kubernetes.