En entornos de producción con Kubernetes, la diferencia entre los requisitos de modelos y el tamaño de las GPU genera ineficiencias. Modelos ligeros como el reconocimiento automático de voz (ASR) o el texto a voz (TTS) pueden requerir solo 10 GB de VRAM, pero ocupan una GPU completa en despliegues estándar. Esto provoca que los recursos de computación costosos permanezcan subutilizados.
La solución no solo se relaciona con la reducción de costos, sino también con la optimización de la densidad del clúster para atender a más usuarios concurrentes usando el mismo hardware de alta calidad. Esta guía describe cómo implementar y evaluar estrategias de partición de GPU, específicamente NVIDIA Multi-Instance GPU (MIG) y la técnica de time-slicing para utilizar completamente los recursos de computación.
Utilizando una pipeline de voz AI de grado de producción como nuestro banco de pruebas, mostramos cómo combinar modelos para maximizar el retorno de inversión de infraestructura manteniendo una fiabilidad superior al 99% y estrictas garantías de latencia.
Abordando la fragmentación de recursos de GPU
Por defecto, el plugin de dispositivo NVIDIA para Kubernetes muestra las GPU como recursos enteros. Un pod solicita nvidia.com/gpu: 1, y el programador lo vincula a un dispositivo físico.
Modelos de lenguaje grande (LLMs) como NVIDIA Nemotron, Llama 3 o Qwen 7B/8B requieren computación dedicada para mantener un bajo tiempo hasta el primer token (TTFT) y un alto rendimiento por lote. Sin embargo, los modelos de soporte en un pipeline de AI generativa, como modelos de incrustación, ASR, TTS o guardrails, a menudo utilizan solo una fracción de una tarjeta. Ejecutar estos modelos ligeros en GPUs dedicadas resulta en:
- Baja utilización: La utilización de la GPU suele estar cerca del 0-10%.
- Inflación del clúster: Se requieren más nodos para ejecutar el mismo número de pods.
- Fricción en la escalabilidad: Añadir una nueva capacidad requiere una nueva GPU física.
Para resolver esto, debemos romper la relación 1:1 entre pods y GPUs.
Arquitectura: Estrategias de partición
Evaluamos dos estrategias principales para la partición de GPU soportadas por el operador de GPU de NVIDIA.
Partición basada en software: Time-slicing y MPS
El time-slicing permite que múltiples procesos NVIDIA CUDA compartan una GPU mediante la interleaving de la ejecución. Funciona de manera similar a un programador de CPU: el contexto A se ejecuta, se pausa, y luego se ejecuta el contexto B.
- Mecanismo: Programación a nivel de software a través del controlador CUDA.
- Ventajas: Maximiza la utilización. Permite el “bursting”: si el Pod A está inactivo, el Pod B puede usar el 100% de los núcleos de computación de la GPU.
- Desventajas: Sin aislamiento de hardware. Un desbordamiento de memoria (OOM) en un pod puede afectar el contexto de ejecución compartido, y un alto cómputo en un pod puede limitar a los vecinos (el efecto de “vecino ruidoso”).
Además del time-slicing, el NVIDIA Multi-Process Service (MPS) ofrece un enfoque alternativo basado en software. MPS permite que múltiples procesos compartan recursos de GPU de manera concurrente utilizando una arquitectura de servidor-cliente. Esto proporciona más flexibilidad que MIG y es más resistente a ciertos problemas como fugas de memoria en comparación con el time-slicing estándar.
