En entornos de Kubernetes en producción, la discrepancia entre los requisitos de los modelos y el tamaño de las GPU genera ineficiencias. Modelos ligeros de reconocimiento automático de voz (ASR) o síntesis de voz (TTS) pueden requerir solo 10 GB de VRAM, pero ocupan toda una GPU en despliegues estándar de Kubernetes. Esto sucede porque el programador asigna un modelo a una o más GPUs y no puede compartir fácilmente entre modelos.
Resolver esto no solo implica reducir costos, sino también optimizar la densidad del clúster para atender a más usuarios concurrentes en el mismo hardware de alta gama. Esta guía detalla cómo implementar y evaluar estrategias de particionamiento de GPU, específicamente NVIDIA Multi-Instance GPU (MIG) y el time-slicing, para utilizar completamente los recursos de computación.
Fragmentación de recursos de GPU
Por defecto, el plugin de dispositivo NVIDIA para Kubernetes muestra las GPUs como recursos enteros. Un pod solicita nvidia.com/gpu: 1, y el programador lo vincula a un dispositivo físico.
Modelos de lenguaje grandes (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 una tubería de IA generativa, como modelos de incrustación, ASR y TTS, 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 computación de la GPU suele estar entre el 0-10%.
- Expansión del clúster: se necesitan más nodos para ejecutar la misma cantidad de pods.
- Fricción en la escalabilidad: agregar una nueva capacidad requiere una nueva GPU física.
Para solucionar esto, debemos romper la relación 1:1 entre pods y GPUs.
Estrategias de particionamiento
Evaluamos dos estrategias principales para el particionamiento de GPU soportadas por el Operador de GPU de NVIDIA.
Particionamiento basado en software: time-slicing y MPS
El time-slicing permite que múltiples procesos CUDA de NVIDIA compartan una GPU al intercalar la ejecución, funcionando de manera similar a un programador de CPU.
- Mecanismo: programación a nivel de software a través del controlador CUDA.
- Ventajas: maximiza la utilización. Permite “bursting”: si el Pod A está inactivo, el Pod B puede utilizar el 100% de los núcleos de computación de la GPU.
- Desventajas: sin aislamiento de hardware. Un desbordamiento de memoria en un pod puede afectar el contexto de ejecución compartido, y un uso intensivo en un pod puede limitar a los vecinos (el efecto del “vecino ruidoso”).
Además del time-slicing, el Servicio de Múltiples Procesos de NVIDIA (MPS) ofrece un enfoque alternativo basado en software. MPS permite que múltiples procesos compartan recursos de GPU simultáneamente mediante 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.
MIG: Enfoque de hardware para particionamiento
MIG particiona físicamente la GPU en instancias separadas, cada una con su propia memoria dedicada, caché y multiprocesadores de streaming (SMs). Para el SO y Kubernetes, estas parecen dispositivos PCI separados.
En entornos de producción, MIG es preferido donde se requiere un estricto aislamiento de fallos a nivel de hardware para cumplir con los acuerdos de nivel de servicio empresariales. El particionamiento de hardware asegura que un error de memoria en un modelo no cause una falla en cascada a través de la GPU compartida, lo cual es un requisito crítico para la IA de voz en misiones.
Resultados
Para evaluar la fragmentación de recursos, probamos el sistema con dos patrones de tráfico distintos:
- Carga ligera: 5 usuarios concurrentes simulando ~135 segundos de interacción sostenida.
- Carga pesada: 50 usuarios concurrentes simulando ~375 segundos de interacción sostenida.
