Descripción general de las prácticas recomendadas para la inferencia en GKE

En este documento, se proporciona una descripción general de alto nivel de las prácticas recomendadas para ejecutar cargas de trabajo de inferencia en GKE.

Este documento está dirigido a administradores de datos, operadores y desarrolladores que desean adoptar prácticas recomendadas para sus cargas de trabajo de inferencia con aceleradores, como GPUs y TPU, con Kubernetes y GKE. Para obtener más información sobre los roles comunes, consulta Roles y tareas comunes de los usuarios de GKE.

Prepárate para la entrega de inferencias en GKE

En esta sección, se describen las prácticas recomendadas fundamentales que debes seguir cuando te preparas para implementar una carga de trabajo de inferencia. Estas prácticas incluyen el análisis de tu caso de uso, la elección de modelos y la selección de aceleradores.

Analiza las características de tu caso de uso de inferencia

Antes de implementar una carga de trabajo de inferencia, analiza sus requisitos específicos. Este análisis te ayuda a tomar decisiones de arquitectura que equilibran el rendimiento, el costo y la confiabilidad. Comprender tu caso de uso te ayuda a seleccionar los modelos, los aceleradores y las configuraciones adecuados para cumplir con tus objetivos de nivel de servicio (SLO).

Para guiar tu análisis, evalúa las siguientes dimensiones clave de tu carga de trabajo:

  • Define los requisitos de rendimiento y latencia: Determina los SLO de latencia y capacidad de procesamiento de tu aplicación. Las métricas clave que se deben definir incluyen las solicitudes por segundo (RPS), la latencia de respuesta, la longitud de los tokens de entrada y salida, y la tasa de acierto de caché de prefijos. Para obtener más información, consulta Métricas de rendimiento de la inferencia.
  • Evalúa los requisitos y la escala del modelo: Las características del modelo que elijas influyen directamente en tus necesidades de infraestructura. Considera la longitud de contexto máxima que admite el modelo y compárala con lo que requiere tu carga de trabajo. Si tu caso de uso no requiere el contexto máximo, reducir la longitud de contexto máxima puede liberar memoria del acelerador para una caché de KV más grande, lo que podría aumentar el rendimiento.
  • Establece restricciones comerciales y de costos: Tu presupuesto y tus objetivos comerciales son factores clave para diseñar un servicio de inferencia sostenible y rentable. Define tu costo por millón de tokens objetivo para la entrada y la salida, y tu presupuesto mensual total para esta carga de trabajo. Identifica tu objetivo de optimización, como la relación precio-rendimiento, la latencia más baja o el mayor rendimiento, y si tu app puede tolerar la latencia variable.

Elige los modelos adecuados para tus casos de uso de inferencia

Seleccionar el modelo adecuado influye directamente en el rendimiento, el costo y la viabilidad de tu aplicación de inferencia. Para seleccionar el modelo óptimo, evalúa los candidatos según los siguientes criterios:

  • Alineación de tareas y modalidades: Evalúa los modelos según las tareas designadas y las modalidades admitidas. Un modelo optimizado para una tarea específica casi siempre supera a un modelo de propósito más general.
  • Características técnicas: La arquitectura y la precisión del tipo de datos de un modelo, como FP16, FP8 y FP4, son factores clave para determinar sus requisitos de recursos y rendimiento. Esta evaluación te ayuda a determinar si necesitas aplicar técnicas de cuantización. Verifica la precisión admitida para los pesos del modelo, asegúrate de que el framework sea compatible y verifica la longitud máxima del contexto admitida por el modelo.
  • Rendimiento y rentabilidad: Para tomar una decisión basada en datos, compara los modelos preseleccionados con comparativas disponibles públicamente y tus propias pruebas internas. Usa tablas de clasificación, como Chatbot Arena, para comparar modelos y evaluar el costo por millón de tokens de cada modelo en el hardware objetivo.

Aplica la cuantización al modelo

La cuantización es una técnica para optimizar tus cargas de trabajo de inferencia reduciendo el espacio en memoria de tu modelo. Convierte los pesos, las activaciones y la caché de clave-valor (KV) del modelo de formatos de punto flotante de alta precisión (como FP16, FP32 y FP64) a formatos de menor precisión (como FP8 y FP4). Esta reducción de la memoria puede generar mejoras significativas en el rendimiento y la rentabilidad.

La cuantización reduce la huella de memoria del modelo, lo que, a su vez, reduce la sobrecarga de transferencia de datos y libera memoria para una caché de KV más grande.

Para aplicar la cuantización de manera eficaz a tus modelos, sigue estas recomendaciones:

  • Evalúa la compensación de la precisión: A veces, la cuantización puede provocar una pérdida de precisión del modelo. Cuando evalúes la compensación de la precisión de la cuantización, ten en cuenta que la cuantización de 8 bits a menudo puede generar una pérdida mínima de precisión. En cambio, la cuantización de 4 bits puede reducir hasta cuatro veces los requisitos de memoria del acelerador, pero también puede causar una mayor pérdida de precisión en comparación con la cuantización de 8 bits. Evalúa el rendimiento del modelo cuantizado en tu caso de uso específico para asegurarte de que la precisión siga dentro de un rango aceptable. Para evaluar la pérdida de exactitud, puedes usar herramientas como OpenCompass y Language Model Evaluation Harness.
  • Evalúa la compatibilidad con la aceleración por hardware: Para aprovechar al máximo la cuantificación, usa aceleradores que proporcionen aceleración por hardware para los formatos de datos que usa el modelo cuantificado. Por ejemplo:
    • Las GPU NVIDIA H100 proporcionan aceleración de hardware para las operaciones de FP8 y FP16.
    • Las GPUs NVIDIA B200 proporcionan aceleración por hardware para las operaciones FP4, FP8 y FP16.
    • Cloud TPU v5p proporciona aceleración de hardware para las operaciones de FP8.
  • Verifica si hay modelos pre cuantificados: Antes de cuantificar un modelo por tu cuenta, consulta repositorios de modelos públicos, como Hugging Face. Lo ideal sería encontrar un modelo que se haya entrenado de forma nativa con una precisión más baja, ya que esto puede proporcionar beneficios de rendimiento sin la posible pérdida de exactitud de la cuantificación posterior al entrenamiento.
  • Usa una biblioteca de cuantificación: Si no hay un modelo cuantificado previamente disponible, usa una biblioteca para realizar la cuantificación por tu cuenta. Los servidores de inferencia, como vLLM, admiten la ejecución de modelos que se cuantificaron con diversas técnicas. Puedes usar herramientas como llm-compressor para aplicar técnicas de cuantización a un modelo no cuantizado.
  • Considera la cuantización de la caché de KV: Además de cuantizar los pesos del modelo, también puedes cuantizar la caché de KV. Esta técnica reduce aún más la memoria necesaria para la caché de KV en el tiempo de ejecución, lo que puede mejorar el rendimiento.

Para obtener más información, consulta Optimiza las cargas de trabajo de inferencia de LLM en GPUs.

Elige los aceleradores adecuados

Seleccionar el acelerador adecuado afecta directamente el rendimiento, el costo y la experiencia del usuario de tu servicio de inferencia. La mejor opción depende de un análisis de los requisitos de memoria del modelo, los objetivos de rendimiento y el presupuesto.

Para elegir el acelerador adecuado para tu caso de uso específico, sigue estos pasos:

  1. Calcula tus requisitos de memoria: Primero, calcula la memoria mínima del acelerador que se requiere para cargar y ejecutar tu modelo. La memoria total es la suma de la memoria requerida para los pesos del modelo, la sobrecarga del motor de inferencia, las activaciones intermedias y la caché de KV.

    Para estimar la memoria requerida, usa la siguiente ecuación:

    \[ \begin{aligned} \text{Required accelerator memory} = {} & (\text{Model weights} + \text{Overhead} + \text{Activations}) \\ & + (\text{KV cache per batch} \times \text{Batch size}) \end{aligned} \]

    Los términos de la ecuación son los siguientes:

    • Pesos del modelo: Es el tamaño de los parámetros del modelo.
    • Sobrecarga: Es un búfer para el servidor de inferencia y otra sobrecarga del sistema, por lo general, de 1 a 2 GB.
    • Activación: Es la memoria requerida para las activaciones intermedias durante la ejecución de un modelo.
    • Caché de KV por lote: Es la memoria necesaria para la caché de KV de una sola secuencia, que se ajusta según la longitud del contexto y la configuración del modelo.
    • Tamaño del lote: Es la cantidad de secuencias (max_num_sequences) que procesará el motor de inferencia de forma simultánea.

    Ejemplo: Cómo calcular los requisitos de memoria del acelerador para Gemma 3

    Para calcular la memoria del acelerador necesaria para implementar un modelo de Gemma 3 con 27,000 millones de parámetros y una precisión de BF16 para un caso de uso de generación de texto, puedes usar los siguientes valores.

    Para obtener una guía interactiva de este cálculo, consulta ¿Cuánta VRAM necesita mi modelo?. Notebook de Colab

    • Entradas:
      • Pesos del modelo: 54 GB
      • Tamaño del lote (max_num_sequences): 1
      • Longitud promedio de la entrada: 1,500 tokens
      • Longitud promedio del resultado: 200 tokens
      • Sobrecarga del motor de inferencia: 1 GB (estimado)
      • Tamaño del tipo de datos de la caché de KV: 2 (para BF16)
      • Vectores KV: 2 (uno para la clave y otro para el valor)
    • Configuración del modelo para un modelo de Gemma 3 27B ajustado con base en instrucciones:
      • hidden_size: 5376
      • intermediate_size: 21504
      • num_attention_heads: 32
      • num_hidden_layers: 62
      • num_key_value_heads: 16
    • Cálculo de memoria:
      • sequence_length = avg_input_length + avg_output_length = 1,500 + 200 = 1,700 tokens
      • pytorch_activation_peak_memory = (max_num_sequences * sequence_length * (18 * hidden_size + 4 * intermediate_size)) / (1,000^3) = ~0.31 GB (estimado).
      • head_dims = hidden_size / num_attention_heads = 5376 / 32 = 168
      • kv_cache_memory_per_batch = (kv_vectors * max_num_sequences * sequence_length * num_key_value_heads * head_dims * num_hidden_layers * kv_data_type_size) / (1,000^3) = (2 * 1 * 1,700 * 16 * 168 * 62 * 2) / (1,000^3) = ~1.13 GB
      • Memoria del acelerador requerida = Model weights + Overhead + Activations + KV cache per batch = 54 + 1 + 0.31 + 1.13 = ~56.44 GB

    La memoria total estimada del acelerador que necesitas para implementar el modelo es de aproximadamente 57 GB.

  2. Evalúa las opciones de aceleradores: Una vez que estimes tus requisitos de memoria, evalúa las opciones de GPU y TPU disponibles en GKE.

    Además de la cantidad de memoria del acelerador, ten en cuenta los siguientes requisitos del modelo para tu evaluación:

    • En el caso de los modelos que requieren más de un acelerador, verifica la compatibilidad con la conectividad de alta velocidad, como NVLINK y GPUDirect, para reducir la latencia de comunicación.
    • En el caso de los modelos cuantizados, usa aceleradores con aceleración de hardware nativa para los tipos de datos de menor precisión, como FP8 y FP4, para obtener los mayores beneficios de rendimiento.

    Tu elección implica una compensación entre estas funciones, el rendimiento, el costo y la disponibilidad.

    Sugerencia: Para obtener las recomendaciones más recientes sobre aceleradores basadas en comparativas de rendimiento de la entrega y análisis de costos, también puedes usar la herramienta de inicio rápido de GKE Inference. Para obtener más detalles, consulta la documentación de la guía de inicio rápido de GKE Inference.

    Para ayudarte a elegir los aceleradores adecuados para tu carga de trabajo, en la siguiente tabla se resumen las opciones más adecuadas para los casos de uso de inferencia comunes. Estos casos de uso se definen de la siguiente manera:

    • Inferencia de modelos pequeños: Para modelos con unos pocos miles de millones de parámetros, en los que la carga computacional se limita a un solo host.
    • Inferencia de modelos grandes en un solo host: Para modelos con decenas o cientos de miles de millones de parámetros, en los que la carga computacional se comparte entre varios aceleradores en una sola máquina anfitrión.
    • Inferencia de modelos grandes con varios hosts: Para modelos con cientos de miles de millones o billones de parámetros, en los que la carga computacional se comparte entre varios aceleradores en varias máquinas host.
    Caso de uso Aceleradores recomendados Serie de máquinas Características clave
    Inferencia de modelos pequeños NVIDIA L4 G2 Opción rentable para modelos pequeños (24 GB de memoria por GPU).
    NVIDIA RTX Pro 6000 G4 Es rentable para modelos con menos de 30,000 millones de parámetros y generación de imágenes (96 GB de memoria por GPU). Admite la comunicación directa de GPU punto a punto, lo que la hace adecuada para la inferencia de varias GPU en un solo host.
    TPU v5e - Optimizado para la eficiencia en costos.
    TPU v6e - Ofrece el mayor valor para los modelos de transformadores y de texto a imagen.
    Inferencia de modelos grandes en un solo host NVIDIA A100 A2 Adecuado para la mayoría de los modelos que caben en un solo nodo (hasta 640 GB de memoria total).
    NVIDIA H100 A3 Son ideales para cargas de trabajo de inferencia que caben en un solo nodo (hasta 640 GB de memoria total).
    NVIDIA B200 A4 Opción a prueba del futuro para modelos exigentes que se ajustan en un solo nodo (hasta 1,440 GB de memoria total).
    TPU v4 - Ofrece un buen equilibrio entre costo y rendimiento.
    TPU v5p - Opción de alto rendimiento para cargas de trabajo exigentes.
    Inferencia de modelos grandes con varios hosts NVIDIA H200 A3 Ultra Adecuado para modelos grandes que requieren mucha memoria (hasta 1,128 GB de memoria total).
    NVIDIA B200 / GB200 A4 y A4X Para las cargas de trabajo más exigentes, con uso intensivo de procesamiento y vinculadas a la red. Las máquinas A4X usan CPUs basadas en Arm, lo que puede requerir la refactorización de la carga de trabajo (cambios de código más allá de una simple recompilación del contenedor) si tu carga de trabajo usa optimizaciones o funciones específicas de x86.
    TPU v5e - Está optimizada para la eficiencia de costos y el rendimiento en la publicación de LLM medianos y grandes.
    TPU v5p - Es una opción de alto rendimiento para la inferencia en varios hosts que requiere una paralelización a gran escala.
    TPU v6e - Está optimizada para la entrega de transformadores, modelos de texto a imagen y CNN.

    Ejemplo: Elige un acelerador para un modelo de 260 GB

    Supongamos que necesitas implementar un modelo que requiere 260 GB de memoria total del acelerador (200 GB para el modelo, 50 GB para la caché de KV y 10 GB para la sobrecarga).

    Solo en función de los requisitos de memoria, puedes excluir las GPUs NVIDIA L4, ya que la máquina G2 más grande ofrece un máximo de 192 GB de memoria del acelerador. Además, debido a que las GPUs L4 no admiten conectividad de alta velocidad y baja latencia entre aceleradores, distribuir la carga de trabajo en varios nodos no es una opción viable para lograr el rendimiento deseado.

    Si deseas evitar refactorizar tus cargas de trabajo x86-64 (es decir, tener que modificar tu código para que se pueda ejecutar en un tipo diferente de procesador), también excluirías los aceleradores NVIDIA GB200 y GB300, que usan CPU basadas en Arm.

    Esto te deja con las siguientes opciones:

    • NVIDIA A100
    • NVIDIA RTX Pro 6000
    • NVIDIA H100
    • NVIDIA H200
    • NVIDIA B200

    Todos estos aceleradores tienen suficiente memoria. El siguiente paso es evaluar su disponibilidad en las regiones objetivo. Supongamos que descubres que solo las GPU NVIDIA A100 y NVIDIA H100 están disponibles en una región en particular. Después de comparar la relación precio-rendimiento de estas dos opciones, es posible que elijas la NVIDIA H100 para tu carga de trabajo.

    GPU de varias instancias

    Para aumentar el uso de la GPU y optimizar los costos de la GPU, puedes usar configuraciones de GPU de varias instancias. Con esta configuración, particionas una GPU compatible para compartir una sola GPU en varios contenedores en GKE. Cuando aprovisionas una GPU de varias instancias, solo adjuntas GPU completas a tus nodos de GKE y estás sujeto a los precios correspondientes de las GPU. Te recomendamos que uses GPU de varias instancias solo con cargas de trabajo confiables.

    Por ejemplo, puedes conectar una NVIDIA RTX PRO 6000 y hacer lo siguiente:

    • Particiónala en cuatro instancias (cada instancia proporciona 24 GB de memoria del acelerador) y ejecuta modelos de difusión o cargas de trabajo de inferencia de modelos pequeños, como modelos que tienen aproximadamente 8, 000 millones de parámetros y usan la precisión del formato de datos FP16 para los pesos del modelo. Esta partición podría tener una mejor relación precio-rendimiento en comparación con una NVIDIA L4.
    • Particiónala en dos instancias (cada instancia proporciona 48 GB de memoria del acelerador) y ejecuta cargas de trabajo de inferencia de modelos pequeños, como modelos que tienen aproximadamente 15, 000 millones de parámetros y usan una precisión de formato de datos FP16 para los pesos del modelo. Esta partición puede ser una alternativa para ejecutar cargas de trabajo de inferencia en una GPU NVIDIA A100 de 40 GB.

    Para obtener más información, consulta Cómo ejecutar GPUs de varias instancias.

    Para obtener más información, consulta Tipos de máquinas con GPU y Familia de máquinas optimizadas para aceleradores en la documentación de Compute Engine.

  3. Selecciona una estrategia de distribución de inferencia: Si tu modelo es demasiado grande para un solo acelerador, selecciona una estrategia de distribución según los requisitos de tu carga de trabajo.

    Primero, elige una estrategia de distribución según la topología de tu hardware:

    • Un solo acelerador: Si tu modelo cabe en un solo acelerador, este es el enfoque más simple y recomendado.
    • Un solo nodo y varios aceleradores: Si tu modelo cabe en un solo nodo con varios aceleradores, puedes usar el paralelismo de tensor para distribuir el modelo entre los aceleradores de ese nodo.
    • Varios nodos y varios aceleradores: Si tu modelo es demasiado grande para un solo nodo, puedes usar una combinación de paralelismo de tensor y de canalización para distribuirlo en varios nodos.

    Para implementar estas estrategias, puedes usar las siguientes técnicas de paralelismo:

    • Paralelismo de tensor: Esta técnica fragmenta las capas de un modelo en varios aceleradores. Es muy eficaz dentro de un solo nodo con interconexiones de alta velocidad, como NVLINK o PCIe directa de igual a igual, pero requiere una comunicación significativa entre los aceleradores.

      Ejemplo: Paralelismo de tensores

      Por ejemplo, considera que necesitas implementar un modelo con 109 mil millones de parámetros. Con su precisión BF16 (16 bits) predeterminada, cargar los pesos del modelo en la memoria del acelerador requiere aproximadamente 113 GB. Una sola GPU NVIDIA H100 proporciona 80 GB de memoria. Por lo tanto, incluso sin tener en cuenta otros requisitos de memoria, como la caché de KV, necesitas al menos dos GPU NVIDIA H100 para cargar el modelo, con un tamaño de paralelismo de tensores de dos.

    • Paralelismo de canalización: Esta técnica particiona las capas de un modelo de forma secuencial en varios nodos. Es adecuado para distribuir un modelo en varios nodos en una implementación de varios hosts y requiere menos comunicación entre los rangos del modelo que el paralelismo de tensores.

      Ejemplo: Paralelismo híbrido (tensor y canalización)

      En el caso de un modelo muy grande con más de 600,000 millones de parámetros, el requisito de memoria puede superar los 1.1 TB. En una situación con dos nodos a3-megagpu-8g (cada uno con ocho GPU NVIDIA H100), el clúster total tiene 1.28 TB de memoria del acelerador. Para ejecutar el modelo, implementarías una estrategia híbrida: paralelismo de tensores de 8 vías dentro de cada nodo y paralelismo de canalización de 2 vías en los dos nodos. El modelo se dividiría en dos etapas, con la primera mitad de las capas en el primer nodo y la segunda mitad en el segundo nodo. Cuando llega una solicitud, el primer nodo la procesa y envía los datos intermedios a través de la red al segundo nodo, que completa el cálculo.

    Para obtener más instrucciones sobre cómo elegir una estrategia de inferencia distribuida para una réplica de un solo modelo, consulta Paralelismo y escalamiento en la documentación de vLLM.

  4. Selecciona un tipo de máquina optimizado para aceleradores: Según tu elección de acelerador y la cantidad que necesites, selecciona un tipo de máquina que proporcione esos recursos. Cada tipo de máquina ofrece una combinación específica de CPU virtuales, memoria del sistema y ancho de banda de red, lo que también puede afectar el rendimiento de tu carga de trabajo. Por ejemplo, si necesitas 16 GPUs NVIDIA H100, debes seleccionar el tipo de máquina a3-megagpu-16g.

  5. Ejecuta tus propias comparativas: El rendimiento de tu carga de trabajo de inferencia depende en gran medida de tu caso de uso específico. Ejecuta tus propias comparativas para validar tus elecciones y ajustar la configuración.

Optimiza la configuración de tu servidor de inferencia

Para lograr un rendimiento óptimo cuando implementes tu carga de trabajo de inferencia, te recomendamos un ciclo de comparación y ajuste:

  1. Comienza con la Guía de inicio rápido de GKE Inference para obtener una configuración de Kubernetes optimizada como base para tu caso de uso.
  2. Ejecuta comparativas para capturar las métricas de referencia de capacidad de procesamiento y latencia.
  3. Ajusta la configuración de tu servidor de inferencia.
  4. Vuelve a ejecutar las comparativas y compara los resultados para validar los cambios.

Las siguientes recomendaciones se basan en el servidor de inferencia vLLM, pero los principios también se aplican a otros servidores. Para obtener orientación detallada sobre todos los parámetros de configuración disponibles, consulta la documentación de Ajuste y optimización de vLLM:

  • Configura el paralelismo:
    • Paralelismo de tensor (tensor_parallel_size): Establece este parámetro en la cantidad de aceleradores en un solo nodo para fragmentar la carga de trabajo. Por ejemplo, establecer tensor_parallel_size=4 distribuirá la carga de trabajo en cuatro aceleradores. Ten en cuenta que aumentar este valor puede generar una sobrecarga de sincronización excesiva.
    • Paralelismo de canalización (pipeline_parallel_size): Establece este parámetro en la cantidad de nodos en los que distribuyes tu modelo. Por ejemplo, si realizas la implementación en dos nodos con ocho aceleradores cada uno, deberías establecer tensor_parallel_size=8 y pipeline_parallel_size=2. Aumentar este valor puede generar penalizaciones por latencia.
  • Ajusta la caché de KV (gpu_memory_utilization): Este parámetro controla el porcentaje de memoria de GPU reservado para las activaciones, las ponderaciones del modelo y la caché de KV. Un valor más alto aumenta el tamaño de la caché de KV y puede mejorar el rendimiento. Te recomendamos que establezcas un valor entre 0.9 y 0.95. Si te quedas sin memoria (OOM), reduce este valor.
  • Configura la longitud máxima del contexto (max_model_len): Para reducir el tamaño de la caché de KV y los requisitos de memoria, puedes establecer una longitud máxima del contexto más baja que la predeterminada del modelo. Esto te permite usar GPUs más pequeñas y rentables. Por ejemplo, si tu caso de uso solo requiere un contexto de 40,000 tokens, pero el valor predeterminado de tu modelo es de 256,000, establecer max_model_len en 40,000 liberará memoria para una caché de KV más grande, lo que podría generar un mayor rendimiento.
  • Configura la cantidad de solicitudes simultáneas (max_num_batched_tokens, max_num_seqs): Ajusta la cantidad máxima de solicitudes que vLLM procesa de forma simultánea para evitar la apropiación cuando la caché de KV tiene poco espacio. Los valores más bajos para max_num_batched_tokens y max_num_seqs reducen los requisitos de memoria, mientras que los valores más altos pueden mejorar la capacidad de procesamiento con el riesgo de errores de OOM. Para encontrar los valores óptimos, te recomendamos que ejecutes experimentos de rendimiento y observes la cantidad de solicitudes de interrupción en las métricas de Prometheus que exporta vLLM.

Para obtener más información, consulta los siguientes recursos:

Optimiza para la latencia y la disponibilidad

Para garantizar que tu servicio de inferencia sea confiable y responda rápidamente, debes optimizarlo para que tenga una baja latencia de inicio y una alta disponibilidad de recursos.

Optimiza la latencia de inicio en frío de la carga de trabajo de inferencia

Minimizar el tiempo que tardan en iniciarse tus cargas de trabajo de inferencia es fundamental tanto para la eficiencia en los costos como para la experiencia del usuario. Una latencia de inicio en frío baja permite que tu clúster escale rápidamente para satisfacer la demanda, lo que garantiza un servicio responsivo y minimiza la necesidad de un aprovisionamiento excesivo costoso.

Optimiza el tiempo de inicio de los Pods

El tiempo que tarda un Pod en estar listo está determinado en gran medida por el tiempo que tarda en extraer la imagen del contenedor y descargar los pesos del modelo. Para optimizar ambos, considera las siguientes estrategias:

  • Acelera la carga del modelo con un cargador de datos optimizado: El método que usas para almacenar y cargar los pesos del modelo tiene un impacto significativo en el tiempo de inicio. Para las versiones 0.10.2 y posteriores de vLLM, el enfoque recomendado es usar Run:ai Model Streamer para cargar modelos transmitiéndolos directamente desde un bucket de Cloud Storage.

    Si el transmisor no está disponible para tu caso de uso, puedes activar un bucket de Cloud Storage con Cloud Storage FUSE y ajustar su rendimiento habilitando los espacios de nombres jerárquicos y usando técnicas como las descargas paralelas y la recuperación previa. Para obtener más información sobre estas técnicas, consulta Cómo optimizar el controlador de CSI de Cloud Storage FUSE para el rendimiento de GKE. En cualquier caso, te recomendamos que uses Anywhere Cache para crear cachés de lectura zonales de alto rendimiento para tus buckets y que habilites el acceso uniforme a nivel del bucket para controlar de manera uniforme el acceso a tus buckets.

    Si ya usas Managed Lustre para el almacenamiento de archivos de alto rendimiento en tus cargas de trabajo de entrenamiento, también puedes usarlo para cargar pesos del modelo para la inferencia. Este enfoque ofrece acceso de baja latencia cuando la localidad de los datos y la compatibilidad con POSIX son fundamentales.

  • Habilita la transmisión de imágenes: Para reducir el tiempo que lleva extraer tus imágenes de contenedor, habilita la transmisión de imágenes en tu clúster de GKE. La transmisión de imágenes permite que los contenedores se inicien antes de que se descargue toda la imagen, lo que puede reducir drásticamente el tiempo de inicio del Pod.

Habilita nodos de inicio rápido

Para las cargas de trabajo que requieren un escalamiento rápido, puedes aprovechar los nodos de inicio rápido en GKE. Los nodos de inicio rápido son recursos de hardware preinicializados que tienen un tiempo de inicio significativamente más corto que los nodos estándar. Si tu clúster cumple con los requisitos, GKE habilita automáticamente los nodos de inicio rápido.

Planifica la capacidad y maximiza la disponibilidad de los aceleradores

Los aceleradores de alta demanda, como las GPU y las TPU, pueden tener disponibilidad limitada, por lo que es fundamental contar con una estrategia de planificación de capacidad proactiva.

Planifica y reserva capacidad

Los aceleradores de alta demanda pueden tener disponibilidad limitada, por lo que es fundamental contar con una estrategia de planificación de capacidad proactiva. Para garantizar el acceso a los recursos que necesitas, sigue estas recomendaciones:

  • Determina la capacidad de referencia y el control de picos: Planifica la capacidad de referencia del acelerador que necesitas reservar. El importe que se debe reservar depende de tu caso de uso. Por ejemplo, puedes reservar el 100% de la capacidad requerida para las cargas de trabajo críticas que no toleran demoras, o bien puedes reservar un determinado percentil (como el 90 o el 95) y adquirir el resto según demanda para controlar los picos.

  • Reserva capacidad de referencia: Para obtener recursos con un alto nivel de garantía, crea reservas. Puedes elegir un tipo de reserva según tus necesidades. Por ejemplo, para reservar recursos de alta demanda, como aceleradores, para un período futuro específico, puedes crear reservas futuras en el modo de calendario.

  • Organiza la capacidad para los picos: Para la demanda que supera tus reservas de referencia, puedes implementar una estrategia de respaldo con otros tipos de capacidad, como la capacidad a pedido, las VM Spot o el Programador dinámico de cargas de trabajo (DWS). Puedes automatizar esta estrategia de resguardo con clases de procesamiento personalizadas para definir un orden de prioridad para el aprovisionamiento de diferentes tipos de capacidad.

  • Obtén acceso a precios con descuento: Para tu capacidad básica, compra descuentos por compromiso de uso (CUD) para obtener precios con grandes descuentos a cambio de un compromiso de uno o tres años.

Usa el programador dinámico de cargas de trabajo con el modo de aprovisionamiento de inicio flexible si tus cargas de trabajo toleran demoras en la adquisición de capacidad

Para las cargas de trabajo que pueden tolerar cierta demora en la adquisición de capacidad, el programador dinámico de cargas de trabajo (DWS) con el modo de aprovisionamiento de inicio flexible es una opción para obtener aceleradores a un precio con descuento. DWS te permite poner en cola solicitudes de capacidad por hasta siete días.

Cuando uses DWS con el modo de aprovisionamiento de inicio flexible, te recomendamos lo siguiente:

  • Incorpórala en una clase de procesamiento personalizada: Usa una clase de procesamiento personalizada para definir DWS como parte de una estrategia de resguardo priorizada para adquirir capacidad.
  • Establece una duración máxima del tiempo de ejecución: El parámetro maxRunDurationSeconds establece el tiempo de ejecución máximo para los nodos solicitados a través de DWS. Si configuras este parámetro en un valor inferior al valor predeterminado de siete días, puedes aumentar las probabilidades de obtener los nodos solicitados.
  • Habilita el reciclaje de nodos: Para evitar el tiempo de inactividad de tus cargas de trabajo, habilita el reciclaje de nodos. Esta función comienza a aprovisionar un nodo nuevo antes de que venza el anterior, lo que garantiza una transición más fluida.
  • Minimiza las interrupciones: Para minimizar las interrupciones por desalojo y actualizaciones de nodos, configura períodos de mantenimiento y exclusiones, inhabilita la reparación automática de nodos y aprovecha la estrategia de actualizaciones de corta duración.

Usa clases de procesamiento personalizadas

Las clases de procesamiento personalizadas (CCC) son una función de GKE que te permite definir una lista priorizada de configuraciones de infraestructura para tus cargas de trabajo. Los CCC proporcionan capacidades clave diseñadas para mejorar la obtención de aceleradores:

  • Prioridades de procesamiento de resguardo: Puedes definir una lista priorizada de configuraciones. Si tu opción preferida no está disponible durante un evento de escalamiento, el escalador automático recurre automáticamente a la siguiente opción de la lista, lo que aumenta significativamente la probabilidad de adquirir capacidad con éxito.
  • Migración activa a nodos de prioridad más alta: Cuando configuras esta función, GKE reemplaza automáticamente los nodos que se ejecutan en configuraciones de menor prioridad por nodos de configuraciones de mayor prioridad a medida que están disponibles. Esto ayuda a garantizar que tus Pods se ejecuten en los nodos que prefieras (y que, a menudo, sean los más rentables).

Con las clases de procesamiento personalizadas (CCC), puedes crear una estrategia de resguardo para adquirir nodos. Esta estrategia usa una lista priorizada de diferentes tipos de capacidad, como VMs bajo demanda, VMs Spot o reservas. Cada uno de estos tipos de capacidad tiene un nivel de disponibilidad diferente:

  • Reservas: Proporcionan el nivel más alto de garantía para obtener capacidad. Cuando consumas reservas con CCC, ten en cuenta sus restricciones. Por ejemplo, algunos tipos de reservas limitan los tipos de máquinas que puedes reservar o la cantidad máxima de máquinas que puedes solicitar.
  • On demand: Es el modelo de aprovisionamiento estándar, que ofrece flexibilidad, pero puede estar sujeto a restricciones de capacidad regionales para los recursos de alta demanda.
  • VMs Spot: Usan capacidad de reserva a un precio más bajo, pero se pueden interrumpir. Cuando ocurre un evento de interrupción, GKE proporciona un período de finalización ordenado de hasta 30 segundos para los Pods afectados según el mejor esfuerzo. Para aprovechar esta ventaja, haz que tus cargas de trabajo toleren los eventos de interrupción implementando puntos de control y mecanismos de reintento.
  • Programador dinámico de cargas de trabajo (DWS): Te permite poner en cola solicitudes de recursos escasos a precios con descuento. Esta función es ideal para las cargas de trabajo que pueden tolerar demoras en la adquisición de capacidad.

El orden de tu lista de prioridad debe cambiar según si tu objetivo principal es minimizar la latencia o realizar optimizaciones para reducir los costos. Por ejemplo, puedes configurar las siguientes listas de prioridad para diferentes requisitos de carga de trabajo:

Prioridad Cargas de trabajo de baja latencia Cargas de trabajo optimizadas para los costos (tolerantes a la latencia)
1 Reservas (específicas y, luego, cualquiera) Reservas (específicas y, luego, cualquiera)
2 A pedido VMs Spot
3 VMs Spot Programador dinámico de cargas de trabajo
4 Programador dinámico de cargas de trabajo A pedido

Para los casos de uso de baja latencia, la capacidad a pedido se prioriza después de las reservas, ya que informa rápidamente las deficiencias de capacidad, lo que permite que el CCC recurra rápidamente a la siguiente opción.

En el caso de los casos de uso optimizados para los costos, se priorizan las VMs Spot y DWS con inicio flexible después de las reservas para aprovechar los costos más bajos. La capacidad a pedido se usa como resguardo final.

Configura la política de ubicación de tus clústeres y grupos de nodos de GKE

La política de ubicación del escalador automático de clústeres controla cómo GKE distribuye los nodos en las zonas durante un evento de escalamiento vertical. Este parámetro de configuración es especialmente importante cuando se usan clases de procesamiento personalizadas, ya que determina qué zonas tendrá en cuenta el escalador automático del clúster antes de aplicar la lista de prioridad de la CCC.

Para aumentar las probabilidades de obtener aceleradores, configura la política de ubicación según los requisitos de tu carga de trabajo:

  • location-policy=ANY: Prioriza la obtención de capacidad por sobre el equilibrio de los nodos de manera uniforme en las zonas. Este parámetro de configuración es especialmente pertinente cuando tu CCC incluye VMs Spot o tipos de máquinas con disponibilidad variable, ya que ANY permite que el Cluster Autoscaler elija la zona con la mayor probabilidad de satisfacer los tipos de nodos priorizados del CCC. Usa este parámetro de configuración también para priorizar el uso de las reservas sin usar. Cuando uses esta política, te recomendamos que comiences con num-nodes=0 para brindarle al Cluster Autoscaler la máxima flexibilidad a la hora de encontrar capacidad.

  • location-policy=BALANCED: Intenta distribuir los nodos de manera uniforme en todas las zonas disponibles. Usa esta política cuando tus cargas de trabajo utilicen recursos fáciles de obtener y desees mantener la redundancia zonal para lograr una alta disponibilidad.

Puedes configurar este parámetro cuando crees o actualices un grupo de nodos.

Optimiza la eficiencia y los costos

Si supervisas cuidadosamente tus aceleradores y ajustas de forma inteligente tus cargas de trabajo, puedes reducir significativamente el desperdicio y disminuir tus costos operativos.

Observa tus aceleradores y servidores de inferencia

Una estrategia de observabilidad integral es esencial para comprender el rendimiento y la utilización de tus cargas de trabajo de inferencia. GKE proporciona un conjunto de herramientas para ayudarte a supervisar tus aceleradores y servidores de inferencia:

  • Supervisa las métricas de DCGM para las GPUs de NVIDIA: Para supervisar el estado y el rendimiento de tus GPUs de NVIDIA, configura GKE para que envíe las métricas del administrador de GPU del centro de datos de NVIDIA (DCGM) a Cloud Monitoring.
  • Habilita la supervisión automática de aplicaciones: Para simplificar el proceso de supervisión de tus servidores de inferencia, habilita la supervisión automática de aplicaciones en GKE.
  • Instrumenta tus cargas de trabajo con OpenTelemetry: Para las cargas de trabajo que no son compatibles con la supervisión automática de aplicaciones, usa OpenTelemetry para recopilar métricas y seguimientos personalizados.

Ajusta la escala de tus Pods automáticamente

Para asegurarte de que tus cargas de trabajo de inferencia puedan adaptarse de forma dinámica a los cambios en la demanda, usa un Horizontal Pod Autoscaler (HPA) para ajustar automáticamente la cantidad de Pods. Para las cargas de trabajo de inferencia, es fundamental basar las decisiones de escalamiento en métricas que reflejen directamente la carga en el servidor de inferencia, en lugar de en métricas estándar de CPU o memoria.

Para configurar el ajuste de escala automático para tus cargas de trabajo de inferencia, te recomendamos lo siguiente:

  • Configura el HPA según las métricas que tienen en cuenta la inferencia: Para obtener un rendimiento óptimo, configura el HPA para que se escale según las métricas de tu servidor de inferencia. La mejor métrica depende de si realizas la optimización para una latencia baja o una capacidad de procesamiento alta.

    • Para las cargas de trabajo sensibles a la latencia, tienes dos opciones principales:

      • Utilización de la caché de KV (por ejemplo, vllm:gpu_cache_usage_perc): Esta métrica suele ser el mejor indicador de los picos de latencia inminentes. El uso elevado de la caché de KV indica que el motor de inferencia se acerca a su capacidad máxima. El HPA puede usar este indicador para agregar réplicas de forma preventiva y mantener una experiencia del usuario estable.
      • Cantidad de solicitudes en ejecución (tamaño del lote) (por ejemplo,vllm:num_requests_running): Esta métrica se relaciona directamente con la latencia, ya que los tamaños de lote más pequeños suelen generar una latencia más baja. Sin embargo, usarlo para el ajuste de escala automático puede ser difícil, ya que maximizar la capacidad de procesamiento depende del tamaño de las solicitudes entrantes. Es posible que debas elegir un valor inferior al tamaño de lote máximo posible para garantizar que el HPA aumente su escala verticalmente de forma adecuada.

    • Para las cargas de trabajo sensibles a la capacidad de procesamiento, realiza el ajuste de escala en función del tamaño de la cola (por ejemplo, vllm:num_requests_waiting). Esta métrica mide directamente el trabajo pendiente y es una forma sencilla de hacer coincidir la capacidad de procesamiento con la demanda entrante. Dado que esta métrica solo considera las solicitudes que están en espera y no las que se están procesando, es posible que no logre la latencia más baja posible en comparación con el ajuste según el tamaño del lote.

  • Establece una cantidad mínima de réplicas: Para garantizar una disponibilidad coherente y una experiencia del usuario de referencia, siempre establece una cantidad mínima de réplicas para tu implementación de inferencia.

  • Habilita el perfil de HPA de rendimiento: En las versiones 1.33 o posteriores de GKE, el perfil de HPA de rendimiento está habilitado de forma predeterminada en los clústeres aptos para mejorar el tiempo de reacción del HPA.

Para obtener más información, consulta Configura el HPA para cargas de trabajo de LLM en GPUs y Ajusta la escala automáticamente de las cargas de trabajo de inferencia de LLM en TPUs.

Acerca los datos a tus cargas de trabajo

El tiempo que tardan tus cargas de trabajo en cargar datos, como los pesos del modelo, puede ser una fuente importante de latencia. Si acercas tus datos a tus recursos de procesamiento, puedes reducir los tiempos de transferencia de datos y mejorar el rendimiento general.

  • Crea cachés de lectura zonales con Anywhere Cache: Si usas Cloud Storage para almacenar datos para tus cargas de trabajo de IA/AA, habilita Anywhere Cache. Anywhere Cache crea cachés de lectura zonales de alto rendimiento para tus buckets de Cloud Storage.
  • Almacena en caché los datos a los que se accede con frecuencia en SSDs locales: Para las cargas de trabajo que requieren acceso de latencia extremadamente baja a datos temporales, usa SSDs locales como una caché de alto rendimiento. Usar SSDs locales como almacenamiento temporal de baja latencia para conservar los datos que se usan con frecuencia te ayuda a reducir el tiempo de inactividad de los recursos costosos, como los aceleradores, ya que reduce drásticamente el tiempo que los aceleradores esperan a que se completen las operaciones de E/S. Ten en cuenta que no todas las series de máquinas admiten SSDs locales, lo que puede afectar tu elección de aceleradores.
  • Administra cachés con GKE Data Cache: Para las cargas de trabajo que leen datos de discos persistentes con frecuencia, habilita GKE Data Cache. GKE Data Cache usa SSD locales para crear una caché administrada de alto rendimiento para tus discos persistentes. Para la mayoría de las cargas de trabajo de producción, recomendamos usar el modo Writethrough para evitar la pérdida de datos escribiendo datos de forma síncrona en la caché y en el disco persistente subyacente.

Optimiza para arquitecturas de escalamiento avanzadas

Para satisfacer las demandas de las aplicaciones a gran escala o distribuidas a nivel global, puedes adoptar arquitecturas de escalamiento avanzadas para mejorar el rendimiento, la confiabilidad y la administración del tráfico.

Balancea el tráfico de cargas con la puerta de enlace de inferencia de GKE

Para las cargas de trabajo de inferencia en un solo clúster, te recomendamos que uses la puerta de enlace de inferencia de GKE. La puerta de enlace de inferencia es un balanceador de cargas con reconocimiento de IA que supervisa las métricas de inferencia para enrutar las solicitudes al extremo más óptimo. Esta función mejora el rendimiento y el uso del acelerador.

Cuando uses la puerta de enlace de inferencia de GKE, te recomendamos que sigas estas prácticas recomendadas:

  • Agrupa los Pods de procesamiento en un InferencePool: Define un InferencePool para cada grupo de Pods que procesan tus cargas de trabajo de inferencia. Para obtener más información, consulta Personaliza la configuración de GKE Inference Gateway.
  • Multiplexa cargas de trabajo críticas para la latencia: Define InferenceObjectives para especificar las propiedades de la entrega de tu modelo, como su nombre y prioridad. GKE Inference Gateway prioriza las cargas de trabajo con mayor prioridad, lo que te permite multiplexar cargas de trabajo sensibles a la latencia y tolerantes a la latencia, y, además, implementar políticas de reducción de carga durante el tráfico intenso.
  • Usa el enrutamiento que tiene en cuenta el modelo: Para enrutar solicitudes según el nombre del modelo en el cuerpo de la solicitud, usa el enrutamiento basado en el cuerpo. Cuando uses el enrutamiento basado en el cuerpo, asegúrate de que tus backends tengan alta disponibilidad. La puerta de enlace devolverá un error si la extensión no está disponible, lo que evitará que las solicitudes se enruten de forma incorrecta.
  • Permite que la puerta de enlace distribuya el tráfico automáticamente: La puerta de enlace de inferencia de GKE enruta el tráfico de forma inteligente supervisando las métricas clave de los servidores de inferencia en InferencePool, como la utilización de la caché de KV, la longitud de la cola y los índices de la caché de prefijos. Este balanceo de cargas en tiempo real optimiza el uso del acelerador, reduce la latencia final y aumenta la capacidad de procesamiento general en comparación con los métodos tradicionales.
  • Integración con Apigee y Model Armor: Para mejorar la seguridad y la administración, integra Apigee para la administración de APIs y Model Armor para las verificaciones de seguridad.

Implementa cargas de trabajo de inferencia en varios nodos

Para los modelos muy grandes que no caben en un solo nodo, debes distribuir tu carga de trabajo de inferencia en varios nodos. Esto requiere una arquitectura que minimice la latencia de comunicación entre nodos y garantice que todos los componentes de la carga de trabajo distribuida se administren como una sola unidad.

Considera estas prácticas recomendadas:

  • Maximiza el ancho de banda y la capacidad de procesamiento de la red del acelerador: Cuando una carga de trabajo se distribuye en varios nodos, la red se convierte en un factor de rendimiento crítico. Para minimizar la latencia de comunicación entre nodos, usa tecnologías de redes de alto rendimiento, como NVIDIA GPUDirect. Según la escala de tu clúster y la intensidad de comunicación que requiere tu carga de trabajo, puedes elegir entre las siguientes opciones:

    • GPUDirect-TCPX: Es eficaz para una variedad de cargas de trabajo de inferencia de varios nodos que se ejecutan en A3 High.
    • GPUDirect-TCPXO: Ofrece un rendimiento mejorado con mayor descarga y mayor ancho de banda, lo que resulta beneficioso para clústeres más grandes en comparación con TCPX estándar, y se ejecuta en máquinas A3 Mega.
    • RDMA de GPUDirect: Proporciona el mayor ancho de banda entre nodos y la latencia más baja, ya que permite el acceso directo a la memoria entre las GPUs de diferentes nodos, sin pasar por la CPU. Es ideal para los casos de inferencia a gran escala más exigentes en máquinas A3 Ultra y A4.

    Para obtener más información, consulta las secciones siguientes:

    Para validar que la configuración de tu red de varios nodos funcione según lo esperado, te recomendamos que ejecutes pruebas con herramientas como la biblioteca de comunicación colectiva de NVIDIA (NCCL).

  • Usa LeaderWorkerSet para administrar cargas de trabajo distribuidas: Cuando implementas una carga de trabajo distribuida con estado, como un servicio de inferencia de varios nodos, es fundamental administrar todos sus componentes como una sola unidad. Para ello, usa LeaderWorkerSet, una API nativa de Kubernetes que te permite administrar un grupo de Pods relacionados como una sola entidad. Un LeaderWorkerSet garantiza que todos los Pods del conjunto se creen y borren juntos, lo que es fundamental para mantener la integridad de una carga de trabajo distribuida.

  • Coloca los nodos cerca físicamente con la posición compacta: La distancia física entre los nodos de tu carga de trabajo distribuida puede tener un impacto significativo en la latencia de red entre nodos. Para minimizar esta latencia, usa una política de posición compacta para tus grupos de nodos de GKE. Una política de posición de compactación le indica a GKE que coloque los nodos en un grupo de nodos lo más cerca posible entre sí dentro de una zona.

Implementa cargas de trabajo de inferencia en varias regiones

Para las aplicaciones distribuidas a nivel global que requieren alta disponibilidad y baja latencia, implementar tus cargas de trabajo de inferencia en varias regiones es una práctica recomendada fundamental. Una arquitectura multirregional puede ayudarte a aumentar la confiabilidad, mejorar la disponibilidad de los aceleradores, reducir la latencia percibida por el usuario y cumplir con los requisitos reglamentarios específicos de la ubicación.

Para implementar y administrar de manera eficaz un servicio de inferencia multirregional, sigue estas recomendaciones:

  • Aprovisiona clústeres de GKE en varias regiones en las que tengas capacidad reservada o preveas que necesitarás capacidad para controlar las cargas máximas.
  • Elige la estrategia de almacenamiento adecuada para los pesos de tu modelo. Para optimizar la eficiencia operativa, crea un bucket multirregional de Cloud Storage. Para optimizar los costos, crea un bucket regional en cada región y replica los pesos de tu modelo.
  • Usa Anywhere Cache para crear cachés de lectura zonales para tus buckets de Cloud Storage y, así, reducir la latencia de red y los costos de salida de datos.

Resumen de prácticas recomendadas

En la siguiente tabla, se resumen las prácticas recomendadas de este documento.

Tema Tarea
Implementación y configuración
  • Analiza las características de tu caso de uso de inferencia
  • Elige los modelos adecuados para tus casos de uso de inferencia
  • Aplica la cuantización al modelo
  • Elige los aceleradores adecuados
  • Elige tu estrategia de distribución de inferencia
  • Optimiza la configuración de tu servidor de inferencia
Latencia de inicio en frío
  • Optimiza el tiempo de inicio del Pod
  • Habilita nodos de inicio rápido
Planificación de la capacidad y disponibilidad de los aceleradores
  • Planifica y reserva capacidad
  • Usa el programador dinámico de cargas de trabajo
  • Usa clases de procesamiento personalizadas
  • Configura la política de ubicación de tus clústeres y grupos de nodos de GKE
Eficiencia de los recursos y los aceleradores
  • Observa tus aceleradores y servidores de inferencia
  • Cómo ajustar la escala de tus Pods automáticamente
  • Acerca los datos a tus cargas de trabajo
Balanceo de cargas
  • Usa la puerta de enlace de inferencia de GKE para implementaciones de un solo clúster
Implementaciones de varios nodos
  • Maximiza el ancho de banda y la capacidad de procesamiento de la red del acelerador
  • Usa LeaderWorkerSet para agrupar Pods
  • Coloca nodos en proximidad física con la ubicación compacta
Implementaciones multirregionales
  • Aprovisiona clústeres de GKE en varias regiones
  • Balancea la carga del tráfico entre regiones
  • Almacena las ponderaciones del modelo en buckets de Cloud Storage
  • Almacena datos en caché con Anywhere Cache

¿Qué sigue?