En esta guía de prácticas recomendadas se muestran las métricas disponibles y cómo seleccionar las métricas adecuadas para configurar la herramienta de autoescalado horizontal de pods (HPA) para tus cargas de trabajo de inferencia en GKE. HPA es una forma eficiente de asegurarse de que los servidores de modelos 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 GPUs 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 LLM con GPUs y Kubernetes.
Después de leer esta guía, podrás hacer lo siguiente:
- Familiarízate con las métricas de escalado automático para la inferencia de LLMs.
- 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 LLMs
Las siguientes métricas están disponibles en GKE:
Métricas del servidor
Los servidores de inferencia de LLMs populares, como TGI, vLLM y NVIDIA Triton, emiten métricas de rendimiento específicas de las cargas de trabajo. GKE simplifica el raspado y el escalado automático de cargas de trabajo en función de estas métricas a nivel de servidor. Puedes usar estas métricas para obtener visibilidad de los indicadores de rendimiento, como el tamaño del lote, el tamaño de la cola y las latencias de decodificación.
En función de estas métricas, puede dirigir el autoescalado a los indicadores de rendimiento más relevantes. Entre las métricas clave a nivel de servidor para el autoescalado se incluyen las siguientes:
- Tamaño de la cola: el número de solicitudes pendientes de procesamiento en la cola del servidor. Usa el tamaño de la cola para maximizar el rendimiento y minimizar los costes dentro de un umbral de latencia objetivo determinado. Para obtener más información, consulta la sección de prácticas recomendadas.
- Tamaño del lote: número de solicitudes que se están sometiendo a inferencia. Usa el tamaño de lote para alcanzar umbrales de latencia objetivo más bajos que el tamaño de la cola. Para obtener más información, consulta la sección de prácticas recomendadas.
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 GPU.
Métricas de GPU
Las GPUs emiten varias métricas de uso y rendimiento, lo que ofrece un escalado automático independiente de la carga de trabajo para cualquier tarea basada en GPU, incluidas las cargas de trabajo de inferencia que no tienen métricas personalizadas. Para saber cómo configurar la recogida de DCGM, consulta Configurar la recogida de DCGM.
Entre las métricas de GPU habituales de GKE se incluyen las siguientes:
| Métrica de GPU | Uso | Limitaciones |
|---|---|---|
Uso de GPU (DCGM_FI_DEV_GPU_UTIL) |
Mide el ciclo de actividad, que es el tiempo que la GPU está activa. | No mide la cantidad de trabajo que se realiza mientras la GPU está activa. Esto dificulta la asignación de métricas de rendimiento basadas en inferencias, como la latencia y el rendimiento, a un umbral de utilización de la GPU. |
Uso de memoria de la GPU (DCGM_FI_DEV_FB_USED) |
Mide la cantidad de memoria de la GPU que se está usando en un momento dado. Esto resulta útil para cargas de trabajo que implementan la asignación dinámica de memoria de GPU. | En el caso de las cargas de trabajo que preasignan memoria de GPU o que nunca desasignan memoria (como las cargas de trabajo que se ejecutan en TGI y vLLM), esta métrica solo funciona para aumentar la escala y no se reducirá cuando disminuya el tráfico. |
Métricas de CPU
En GKE, HPA funciona de forma predeterminada con el autoescalado basado en CPU y memoria. En el caso de las cargas de trabajo que se ejecutan en CPUs, las métricas de utilización de CPU y memoria suelen ser las principales métricas de autoescalado.
En el caso de las cargas de trabajo de inferencia que se ejecutan en GPUs, no recomendamos utilizar la CPU y la memoria como únicos indicadores de la cantidad de recursos que consume un trabajo, ya que las cargas de trabajo de inferencia dependen principalmente de los recursos de la GPU. Por lo tanto, usar solo las métricas de CPU para el autoescalado puede dar lugar a un rendimiento y unos costes no óptimos.
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 los objetivos de rendimiento de tu carga de trabajo de inferencia.
Práctica recomendada: Usa el tamaño de la cola para maximizar el rendimiento y minimizar los costes dentro de un umbral de latencia objetivo determinado
Recomendamos el escalado automático del tamaño de la cola al optimizar el rendimiento y el coste, y cuando se puedan alcanzar los objetivos de latencia con el rendimiento máximo del tamaño de lote máximo del servidor del modelo.
El tamaño de la cola se correlaciona directamente con la latencia de las solicitudes. Las solicitudes entrantes se ponen en cola en el servidor 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 minimiza el tiempo de espera de la cola aumentando la escala cuando hay carga y disminuyéndola cuando la cola está vacía. Este enfoque es relativamente fácil de implementar y, en gran medida, independiente de la carga de trabajo, ya que el tamaño de la cola no depende del tamaño de la solicitud, del modelo ni del hardware.
Si quieres maximizar el rendimiento y, al mismo tiempo, respetar la configuración del servidor de tu modelo, te recomendamos que te centres en el tamaño de la cola. El tamaño de la cola registra las solicitudes pendientes, no las que se están procesando. vLLM y TGI usan la creación de lotes continua, lo que maximiza las solicitudes simultáneas y mantiene la cola baja cuando hay espacio disponible en el lote. La cola crece de forma notable cuando el espacio de los lotes es limitado, por lo que debes usar el punto de crecimiento como señal para iniciar el escalado vertical. Si combinas el ajuste automático de la escala del tamaño de la cola con el procesamiento optimizado de lotes, puedes maximizar el procesamiento de solicitudes.
Determinar el valor de umbral de tamaño de cola óptimo para HPA
Ten en cuenta la tolerancia de HPA, que tiene un valor predeterminado de 0,1 en el intervalo de inacción alrededor del valor objetivo para reducir la oscilación.
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
El tamaño de la cola 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 máximo del lote. Como solución alternativa, puede reducir manualmente el tamaño máximo del lote o escalar automáticamente el tamaño del lote.
Práctica recomendada: Usa el tamaño del lote para alcanzar umbrales de latencia objetivo más bajos que el tamaño de la cola
Te recomendamos que elijas el autoescalado basado en el tamaño de los lotes 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 tamaño del lote se correlaciona directamente con el rendimiento y la latencia de una solicitud entrante. El tamaño del lote es un buen indicador de los picos de carga, ya que un aumento de la carga provoca que se añadan más solicitudes al lote, lo que hace que el tamaño del lote sea mayor. Por lo general, cuanto mayor sea el tamaño del lote, mayor será la latencia. El autoescalado en función del tamaño del lote asegura que tu carga de trabajo se escale 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.
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, el tamaño del lote es valioso para las cargas de trabajo sensibles a la latencia. Los tamaños de lote más grandes aumentan el rendimiento, pero también la latencia, ya 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 tu servidor de modelos lo permite, te recomendamos que personalices el tamaño máximo del lote como mecanismo de ajuste adicional. También puedes combinarlo con el escalado automático basado en colas.
Determinar el valor de umbral de tamaño de lote óptimo para HPA
Ten en cuenta la tolerancia de HPA, que es un intervalo predeterminado de 0,1 alrededor del valor objetivo en el que no se realiza ninguna acción para reducir la oscilación.
Para elegir el umbral de tamaño de lote adecuado, aumenta experimentalmente la carga de tu servidor y observa dónde alcanza el tamaño de lote su punto máximo. También te recomendamos que uses la herramienta locust-load-inference para hacer pruebas. Una vez que hayas identificado el tamaño máximo del lote, define el valor de destino inicial ligeramente por debajo de este máximo 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
El autoescalado del tamaño de lote, aunque es útil para controlar la latencia, tiene limitaciones. Las variaciones en el tamaño de las solicitudes y las limitaciones de hardware dificultan la tarea de encontrar el umbral de tamaño de lote adecuado.
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 que el número de réplicas cambie rápidamente debido a las fluctuaciones de las métricas. Los valores predeterminados son 5 minutos para reducir la escala (para evitar que se reduzca prematuramente) y 0 para aumentarla (para asegurar la capacidad de respuesta). Ajusta el valor en función de la volatilidad de tu carga 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 han cambiado 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.