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 deseen adoptar prácticas recomendadas para sus cargas de trabajo de inferencia con aceleradores, como GPU y TPU, con Kubernetes y GKE. Para obtener más información sobre los roles comunes, consulta Roles y tareas comunes del usuario de GKE.
Para obtener una descripción general consolidada de todas las prácticas recomendadas de GKE, consulta Prácticas recomendadas para 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 analizar tu caso de uso, elegir modelos y seleccionar 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 los parámetros de configuración 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 tu aplicación para la latencia y la capacidad de procesamiento. 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 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 la capacidad de procesamiento.
- Establece restricciones de costos y comerciales: 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 la capacidad de procesamiento más alta, y si tu app puede tolerar una latencia variable.
Elige los modelos adecuados para tus casos de uso de inferencia
Seleccionar el modelo correcto afecta directamente 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 sus tareas designadas y las modalidades admitidas. Un modelo optimizado para una tarea específica casi siempre supera a uno de uso más general.
- Características técnicas: La arquitectura de un modelo y la precisión del tipo de datos, 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 de contexto máxima admitida del modelo.
- Rendimiento y rentabilidad: Para tomar una decisión basada en datos, compara los modelos preseleccionados con comparativas disponibles de forma pública 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 tu hardware de destino.
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 par 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 el espacio en 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 a tus modelos de manera eficaz, sigue estas recomendaciones:
- Evalúa la compensación de exactitud: En ocasiones, la cuantización puede provocar una pérdida de exactitud del modelo. Cuando evalúes la compensación de exactitud de la cuantización, ten en cuenta que la cuantización de 8 bits suele generar una pérdida mínima de exactitud. En cambio, la cuantización de 4 bits puede proporcionar una reducción de hasta cuatro veces en los requisitos de memoria del acelerador, pero también puede causar una mayor pérdida de exactitud 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 exactitud siga estando 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 de hardware: Para aprovechar al máximo la cuantización, usa aceleradores que proporcionen aceleración de hardware para los formatos de datos que usa el modelo cuantizado. Por ejemplo:
- Las GPU NVIDIA H100 proporcionan aceleración de hardware para las operaciones de FP8 y FP16.
- Las GPU NVIDIA B200 proporcionan aceleración de hardware para operaciones FP4, FP8 y FP16.
- Cloud TPU v5p proporciona aceleración de hardware para las operaciones de FP8.
- Verifica si hay modelos cuantizados previamente: Antes de cuantizar un modelo por tu cuenta, consulta los repositorios de modelos públicos, como Hugging Face. Lo ideal es 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 cuantizació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 una variedad de técnicas. Puedes usar herramientas como llm-compressor para aplicar técnicas de cuantificación a un modelo no cuantificado.
- 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 entorno 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 GPU.
Elige los aceleradores adecuados
Seleccionar el acelerador correcto 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 de tu modelo, tus objetivos de rendimiento y tu presupuesto.
Para elegir el acelerador adecuado para tu caso de uso específico, sigue estos pasos:
Calcula tus requisitos de memoria: Primero, calcula la memoria mínima del acelerador necesaria para cargar y ejecutar tu modelo. La memoria total es la suma de la memoria necesaria 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 GB a 2 GB.
- Activación: Es la memoria necesaria 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 escala con la longitud de contexto y la configuración del modelo.
- Tamaño del lote: Es la cantidad de secuencias (
max_num_sequences) que el motor de inferencia procesará de forma simultánea.
Ejemplo: Calcula los requisitos de memoria del acelerador para Gemma 3
Para calcular la memoria del acelerador necesaria para implementar un modelo de Gemma 3 de 27,000 millones de parámetros con una precisión de BF16 para un caso de uso de generación de texto, puedes usar los siguientes valores.
Para obtener una explicación 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 de salida: 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 de KV: 2 (uno para la clave y otro para el valor)
- Configuración del modelo para un modelo Gemma 3 27B ajustado por instrucciones:
hidden_size: 5376intermediate_size: 21504num_attention_heads: 32num_hidden_layers: 62num_key_value_heads: 16
- Cálculo de la memoria:
sequence_length=avg_input_length+avg_output_length= 1,500 + 200 = 1,700 tokenspytorch_activation_peak_memory= (max_num_sequences*sequence_length* (18 *hidden_size+ 4 *intermediate_size)) / (1000^3) = ~0.31 GB (estimado).head_dims=hidden_size/num_attention_heads= 5376 / 32 = 168kv_cache_memory_per_batch= (kv_vectors*max_num_sequences*sequence_length*num_key_value_heads*head_dims*num_hidden_layers*kv_data_type_size) / (1000^3) = (2 * 1 * 1700 * 16 * 168 * 62 * 2) / (1000^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.
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 que se admita 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 tipos de datos de menor precisión, como FP8 y FP4, para obtener los mayores beneficios de rendimiento.
Tu elección implica un equilibrio entre estas funciones, el rendimiento, el costo y la disponibilidad.
Aceleradores recomendados por caso de uso
Sugerencia: Para obtener las recomendaciones de aceleradores más recientes basadas en comparativas de rendimiento de entrega y análisis de costos, también puedes usar la herramienta GKE Inference Quickstart. 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 de procesamiento se limita a un solo host.
- Inferencia de modelos grandes de un solo host: para modelos con decenas a cientos de miles de millones de parámetros, en los que la carga de procesamiento se comparte entre varios aceleradores en una sola máquina anfitrión.
- Inferencia de modelos grandes de varios hosts: para modelos con cientos de miles de millones a billones de parámetros, en los que la carga de procesamiento se comparte entre varios aceleradores en varias máquinas host.
Caso de uso Aceleradores recomendados Serie de máquinas Características principales Inferencia de modelos pequeños NVIDIA L4 G2 Es una opción rentable para modelos pequeños (24 GB de memoria por GPU). NVIDIA RTX Pro 6000 G4 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 entre pares de GPU, lo que la hace adecuada para la inferencia de host único y varias GPU. TPU v5e - Optimizado para mejorar la rentabilidad. TPU v6e - Ofrece el valor más alto para los modelos de Transformer y de texto a imagen. Inferencia de modelos grandes de host único NVIDIA A100 A2 Es adecuado para la mayoría de los modelos que caben en un solo nodo (hasta 640 GB de memoria total). NVIDIA H100 A3 Ideal para cargas de trabajo de inferencia que se ajustan a un solo nodo (hasta 640 GB de memoria total). NVIDIA B200 A4 Opción preparada para el futuro para modelos exigentes que se ajustan a un solo nodo (hasta 1,440 GB de memoria total). TPU v4 - Ofrece un buen equilibrio entre costo y rendimiento. TPU v5p - Es una opción de alto rendimiento para cargas de trabajo exigentes. Inferencia de modelos grandes de varios hosts NVIDIA H200 A3 Ultra Adecuado para modelos grandes con uso intensivo de memoria (hasta 1,128 GB de memoria total). NVIDIA B200 / GB200 / GB300 / Vera Rubin NVL72 A4 / A4X / A4X Max / A5X Para las cargas de trabajo más exigentes, de procesamiento intensivo y vinculadas a la red. Las máquinas A4X, A4X Max y A5X usan CPUs basadas en Arm, lo que podría requerir una 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 funciones u optimizaciones específicas de x86. TPU v5e - Optimizado para mejorar la rentabilidad y el rendimiento de la entrega de LLM medianos a grandes. TPU v5p - Es una opción de alto rendimiento para la inferencia de varios hosts que requiere paralelización a gran escala. TPU v6e - Optimizado para la entrega de transformadores, modelos de texto a imagen y CNN. Ejemplo: Elige un acelerador para un modelo de 260 GB
Imagina 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 GPU NVIDIA L4, ya que la máquina G2 más grande ofrece un máximo de 192 GB de memoria de acelerador. Además, debido a que las GPU L4 no admiten la 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 la refactorización de tus cargas de trabajo x86-64 (es decir, tener que modificar tu código para que se pueda ejecutar en un tipo de procesador diferente), también excluirías los aceleradores NVIDIA GB200, GB300 y Vera Rubin NVL72, que usan CPUs 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 tus regiones de destino. 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, puedes elegir la NVIDIA H100 para tu carga de trabajo.
GPU de instancias múltiples
Para aumentar el uso de GPU y optimizar los costos de GPU, puedes usar configuraciones de GPU de instancias múltiples. Con esta configuración, particionas una GPU compatible para compartir una sola GPU en varios contenedores en GKE. Cuando aprovisionas una GPU de instancias múltiples, conectas solo 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 de confianza.
Por ejemplo, puedes conectar una NVIDIA RTX PRO 6000 y hacer lo siguiente:
- Particiónala en cuatro instancias (cada una 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 una 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 la precisión del formato de datos FP16 para los pesos del modelo. Esta partición podría ser una alternativa a la ejecución de cargas de trabajo de inferencia en una GPU NVIDIA A100 de 40 GB.
Para obtener más información, consulta Ejecuta GPUs de instancias múltiples.
Para obtener más información, consulta Tipos de máquinas de GPU y Familia de máquinas optimizadas para aceleradores en la documentación de Compute Engine.
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:
- Acelerador único: Si tu modelo se ajusta a un solo acelerador, este es el enfoque más simple y recomendado.
- Nodo único, varios aceleradores: Si tu modelo se ajusta a un solo nodo con varios aceleradores, puedes usar el paralelismo de tensores para distribuir el modelo entre los aceleradores de ese nodo.
- Multinodo, multiacelerador: Si tu modelo es demasiado grande para un solo nodo, puedes usar una combinación de paralelismo de tensores y canalizaciones para distribuirlo en varios nodos.
Para implementar estas estrategias, puedes usar las siguientes técnicas de paralelismo:
Paralelismo de tensores: 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 de intercambio de tráfico directo, pero requiere una comunicación significativa entre los aceleradores.
Ejemplo: Paralelismo de tensores
Por ejemplo, considera que necesitas implementar un modelo con 109,000 millones de parámetros. En su precisión predeterminada de BF16 (16 bits), 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 divide las capas de un modelo de forma secuencial en varios nodos. Es ideal 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)
Para 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 GPUs 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: 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 lineamientos sobre cómo elegir una estrategia de inferencia distribuida para una réplica de modelo único, consulta Paralelismo y escalamiento en la documentación de vLLM.
Selecciona un tipo de máquina optimizado para aceleradores: según tu elección de acelerador y la cantidad que necesitas, 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 GPU NVIDIA H100, debes seleccionar el tipo de máquina
a3-megagpu-16g.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 tu configuración.
Optimiza la configuración de tu servidor de inferencia
Para lograr un rendimiento óptimo cuando implementas tu carga de trabajo de inferencia, te recomendamos un ciclo de comparativas y ajustes:
- Comienza con la guía de inicio rápido de inferencia de GKE para obtener una configuración de Kubernetes de referencia optimizada para tu caso de uso.
- Ejecuta comparativas para capturar las métricas de capacidad de procesamiento y latencia de referencia.
- Ajustar la configuración de tu servidor de inferencia
- 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 Optimización y ajuste de vLLM:
- Configura el paralelismo:
- Paralelismo de tensores (
tensor_parallel_size): Establece este valor en la cantidad de aceleradores en un solo nodo para fragmentar la carga de trabajo. Por ejemplo, si configurastensor_parallel_size=4, la carga de trabajo se distribuirá 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): Configura este valor en la cantidad de nodos en los que distribuyes tu modelo. Por ejemplo, si implementas en dos nodos con ocho aceleradores cada uno, debes establecertensor_parallel_size=8ypipeline_parallel_size=2. Aumentar este valor puede generar penalizaciones de latencia.
- Paralelismo de tensores (
- Ajusta la caché de KV (
gpu_memory_utilization): este parámetro controla el porcentaje de memoria de GPU reservada para los pesos del modelo, las activaciones y la caché de KV. Un valor más alto aumenta el tamaño de la caché de KV y puede mejorar la capacidad de procesamiento. Te recomendamos que establezcas este valor entre0.9y0.95. Si encuentras errores de memoria insuficiente (OOM), disminuye 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 de contexto menor que la predeterminada del modelo. Esto puede permitirte 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 256,000, establecermax_model_lenen 40,000 liberará memoria para una caché de KV más grande, lo que podría generar una mayor capacidad de procesamiento. - 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 interrupción cuando la caché de KV tiene poco espacio. Los valores más bajos paramax_num_batched_tokensymax_num_seqsreducen 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:
- Para obtener un análisis detallado de cómo ajustar estos parámetros, consulta Ajuste del rendimiento de vLLM: La guía definitiva para la configuración de inferencia de xPU.
- Para obtener más orientación sobre la optimización de la memoria del modelo, consulta Prácticas recomendadas para optimizar la inferencia de modelos de lenguaje grandes con GPUs en GKE.
- Para obtener un ejemplo completo y que se pueda implementar, consulta la implementación de referencia de inferencia de GKE.
Optimiza la latencia y la disponibilidad
Para garantizar que tu servicio de inferencia sea responsivo y confiable, 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 rentabilidad como para la experiencia del usuario. Una latencia de inicio en frío baja permite que tu clúster escale verticalmente con rapidez para satisfacer la demanda, lo que garantiza un servicio responsivo y, al mismo tiempo, 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 se determina, en gran medida, por el tiempo que tarda en extraer la imagen de contenedor y descargar los pesos del modelo. Para optimizar ambos, considera las siguientes estrategias:
Acelera la carga de modelos con un cargador de datos optimizado: El método que usas para almacenar y cargar los pesos de tu 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 el Run:ai Model Streamer para cargar modelos de IA 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 espacios de nombres jerárquicos y usando técnicas como descargas paralelas y carga previa. Para obtener más información sobre estas técnicas, consulta Optimiza el controlador de CSI de Cloud Storage FUSE para el rendimiento de GKE. En cualquier caso, te recomendamos que uses Rapid Cache para crear cachés de lectura zonales de alto rendimiento para tus buckets y que habilites el acceso uniforme a nivel de bucket para controlar de manera uniforme el acceso a tus buckets.
Si ya usas Managed Lustre para el almacenamiento de archivos de alto rendimiento para tus cargas de trabajo de entrenamiento, también puedes usarlo para cargar pesos de modelos 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 se tarda en extraer las 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 tus contenedores se inicien antes de que se descargue toda la imagen, lo que puede reducir de forma significativa el tiempo de inicio del Pod.
Habilita los 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 mucho 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 flexibilidad, la eficiencia y la disponibilidad de la capacidad de los aceleradores
Los aceleradores de alta demanda, como las GPU y las TPU, pueden tener una disponibilidad limitada, por lo que es esencial contar con una estrategia proactiva de planificación de la capacidad.
Planifica y reserva capacidad
Los aceleradores de alta demanda pueden tener una disponibilidad limitada, por lo que es esencial contar con una estrategia proactiva de planificación de la capacidad. Para garantizar el acceso a los recursos que necesitas, sigue estas recomendaciones:
Determina el modelo de referencia de capacidad y el manejo de picos: planifica la capacidad de referencia del acelerador que necesitas reservar. La cantidad 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 sin tolerancia a los retrasos, o puedes reservar un determinado percentil (como el 90 o el 95) y adquirir el resto a pedido 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 Calendario.
Organiza la capacidad para los picos: En el caso de la demanda que supera tus reservas de referencia, puedes implementar una estrategia de resguardo con otros tipos de capacidad, como las VMs Spot, a pedido o el programador dinámico de cargas de trabajo (DWS). Puedes automatizar esta estrategia de resguardo con ComputeClasses personalizadas para definir un orden de prioridad para aprovisionar diferentes tipos de capacidad.
Obtén acceso a precios con descuento: Para tu capacidad de referencia, 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 Dynamic Workload Scheduler con el modo de aprovisionamiento de inicio flexible si tus cargas de trabajo toleran retrasos 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óralo a una ComputeClass: Usa una ComputeClass 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
maxRunDurationSecondsestablece el tiempo de ejecución máximo para los nodos solicitados a través de DWS. Si estableces este valor en un valor inferior al predeterminado de siete días, puedes aumentar las posibilidades 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 de la expulsión y las 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 ComputeClasses
Las ComputeClasses son una función de GKE que te permite definir una lista priorizada de parámetros de configuración de infraestructura para tus cargas de trabajo. Las ComputeClasses proporcionan funciones clave diseñadas para mejorar la flexibilidad, la eficiencia y la disponibilidad de la capacidad de los aceleradores:
- Prioridades de procesamiento de resguardo: Puedes definir una lista priorizada de parámetros de configuración. Si tu opción preferida no está disponible durante un evento de escalamiento vertical, el escalador automático recurre automáticamente a la siguiente de la lista, lo que aumenta significativamente la probabilidad de adquirir capacidad de forma correcta.
- Migración activa a nodos de mayor prioridad: 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, a menudo, los más rentables).
Con ComputeClasses, puedes crear una estrategia de resguardo para adquirir nodos. Esta estrategia usa una lista priorizada de diferentes tipos de capacidad, como VMs a pedido, 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 ComputeClasses, 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: Usa la capacidad de reserva a un precio más bajo, pero se puede interrumpir. Cuando se produce un evento de interrupción, GKE proporciona un período de finalización ordenado de hasta 30 segundos a los Pods afectados según el mejor esfuerzo. Para aprovechar esto, implementa puntos de control y mecanismos de reintento para que tus cargas de trabajo sean tolerantes a los eventos de interrupción.
- 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 cargas de trabajo que pueden tolerar demoras en la adquisición de capacidad.
El orden de tu lista de prioridades debería 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 prioridades para diferentes requisitos de carga de trabajo:
| Prioridad | Cargas de trabajo de baja latencia | Cargas de trabajo con optimización de 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 | Dynamic Workload Scheduler |
| 4 | Dynamic Workload Scheduler | A pedido |
Para los casos de uso de baja latencia, la capacidad a pedido se prioriza después de las reservas, ya que informa la falta de capacidad con rapidez, lo que permite que la ComputeClass recurra rápidamente a la siguiente opción.
En los casos de uso con optimización de costos, las VMs Spot y DWS con inicio flexible se priorizan 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 de GKE y grupos de nodos
La política de ubicación del escalador automático de clústeres controla cómo GKE distribuye los nodos entre las zonas durante un evento de escalamiento vertical. Este parámetro de configuración es muy importante cuando se usan ComputeClasses, ya que determina qué zonas considerará el escalador automático del clúster antes de aplicar la lista de prioridades de ComputeClass.
Para mejorar tus posibilidades 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 balanceo de nodos de manera uniforme en las zonas. Este parámetro de configuración es especialmente relevante cuando tu ComputeClass incluye VMs Spot o tipos de máquinas con disponibilidad variable, ya queANYpermite que el escalador automático del clúster elija la zona con la mejor probabilidad de cumplir con los tipos de nodos priorizados de ComputeClass. Usa este parámetro de configuración también para priorizar el uso de reservas sin usar. Cuando uses esta política, te recomendamos que comiences connum-nodes=0para darle al escalador automático del clúster la máxima flexibilidad para 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 usen recursos que se puedan obtener con facilidad y quieras mantener la redundancia zonal para obtener alta disponibilidad.
Puedes establecer este parámetro de configuración cuando creas o actualizas un grupo de nodos.
Optimiza la eficiencia y los costos
Si supervisas con cuidado tus aceleradores y escalas de forma inteligente tus cargas de trabajo, puedes reducir de forma significativa el desperdicio y disminuir los costos operativos.
Observa tus aceleradores y servidores de inferencia
Una estrategia de observabilidad integral es esencial para comprender el rendimiento y el uso 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 GPU de NVIDIA: Para supervisar el estado y el rendimiento de tus GPU de NVIDIA, configura GKE para que envíe 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 garantizar 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 escalar automáticamente la cantidad de Pods. Para las cargas de trabajo de inferencia, es fundamental que bases tus 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 de tus cargas de trabajo de inferencia, te recomendamos lo siguiente:
Configura el HPA en función de las métricas que tienen en cuenta la inferencia: Para obtener un rendimiento óptimo, configura el HPA para que escale en función de las métricas de tu servidor de inferencia. La mejor métrica depende de si estás optimizando para obtener una latencia baja o una alta capacidad de procesamiento.
Para las cargas de trabajo sensibles a la latencia, tienes dos opciones principales:
- Uso 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. Un uso alto de la caché de KV indica que el motor de inferencia está cerca de 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 un desafío, 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 máximo posible del lote para asegurarte de que el HPA escale verticalmente de forma adecuada.
- Uso de la caché de KV (por ejemplo,
Para las cargas de trabajo sensibles a la capacidad de procesamiento, escala según el tamaño de la cola (por ejemplo,
vllm:num_requests_waiting). Esta métrica mide directamente la lista de tareas pendientes y es una forma sencilla de hacer coincidir la capacidad de procesamiento con la demanda entrante. Debido a 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 alcance la latencia más baja posible en comparación con el escalamiento 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, establece siempre 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 de los modelos, puede ser una fuente significativa 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 Rapid Cache: Si usas Cloud Storage para almacenar datos de tus cargas de trabajo de IA/AA, habilita Rapid Cache. Rapid 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 SSD locales: Para las cargas de trabajo que requieren un acceso de latencia extremadamente baja a los datos temporales, usa SSD locales como una caché de alto rendimiento. Usar SSDs locales como almacenamiento temporal de baja latencia para guardar datos de uso frecuente te ayuda a reducir el tiempo de inactividad de los recursos costosos, como los aceleradores, ya que disminuye drásticamente el tiempo que esperan los aceleradores para que se completen las operaciones de E/S. Ten en cuenta que no todas las series de máquinas admiten SSD 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 Persistent Disks con frecuencia, habilita
GKE Data Cache. La caché de datos de GKE 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
Writethroughpara 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 de forma global, puedes adoptar arquitecturas de escalamiento avanzadas para mejorar el rendimiento, la confiabilidad y la administración del tráfico.
Balancea las cargas del tráfico con GKE Inference Gateway
Para las cargas de trabajo de inferencia en un solo clúster, recomendamos usar la GKE Inference Gateway. La puerta de enlace de inferencia es un balanceador de cargas que reconoce la IA y 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 GKE Inference Gateway, te recomendamos que sigas estas prácticas recomendadas:
- Agrupa los Pods de entrega en un
InferencePool: Define unInferencePoolpara cada grupo de Pods que entregan 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 con latencia crítica: define
InferenceObjectivespara especificar las propiedades de entrega de tu modelo, como su nombre y prioridad. GKE Inference Gateway da preferencia a las cargas de trabajo con una prioridad más alta, lo que te permite multiplexar las cargas de trabajo con tolerancia a la latencia y las que son críticas para la latencia, y, además, implementar políticas de reducción de carga durante el tráfico intenso. - Usa el enrutamiento adaptado al modelo: Para enrutar las 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 de forma automática:
GKE Inference Gateway enruta el tráfico de forma inteligente supervisando
las métricas clave de los servidores de inferencia en el
InferencePool, como el uso de la caché de KV, la longitud de la cola y los índices de 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 en Apigee y Model Armor: Para mejorar la seguridad y la administración, intégrate en Apigee para la gestión de API y en Model Armor para realizar verificaciones de seguridad.
Implementa cargas de trabajo de inferencia en varios nodos
En el caso de los modelos muy grandes que no caben en un solo nodo, debes distribuir la 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 la comunicación que requiere tu carga de trabajo, puedes elegir entre estas 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 una mayor descarga y un ancho de banda más alto, lo que es beneficioso para clústeres más grandes en comparación con el TCPX estándar, y se ejecuta en máquinas A3 Mega.
- GPUDirect RDMA: 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 GPU en diferentes nodos, lo que omite la CPU, y es más adecuado para las situaciones 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:
- Maximiza el ancho de banda de red de la GPU en clústeres en modo estándar.
- Maximiza el ancho de banda de red de la GPU en clústeres en modo Autopilot.
Para validar que la configuración de red de varios nodos funcione como se espera, te recomendamos que ejecutes pruebas con herramientas como la biblioteca de comunicaciones colectivas 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 en proximidad física 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 compacta 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 de forma 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 flexibilidad, la eficiencia y la disponibilidad de la capacidad del acelerador, reducir la latencia percibida por el usuario y cumplir con los requisitos regulatorios específicos de la ubicación.
Para implementar y administrar de forma eficaz un servicio de inferencia multirregión, 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 de Cloud Storage multirregional. Para optimizar los costos, crea un bucket regional en cada región y replica los pesos de tu modelo.
- Usa Rapid Cache para crear cachés de lectura zonales para tus buckets de Cloud Storage y 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 |
|
| Latencia de inicio en frío |
|
| Planificación de la capacidad, flexibilidad, eficiencia y disponibilidad |
|
| Eficiencia de los recursos y aceleradores |
|
| Balanceo de cargas |
|
| Implementaciones de varios nodos |
|
| Implementaciones multirregionales |
|
¿Qué sigue?
- Consulta la arquitectura de referencia de inferencia de GKE.