En entornos de producción de Kubernetes, 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 texto a voz (TTS) pueden requerir solo 10 GB de VRAM, pero ocupan una GPU completa en despliegues estándar de Kubernetes. Esto ocurre porque el programador asigna un modelo a una o más GPUs y no puede compartir fácilmente entre GPUs, lo que provoca que recursos computacionales costosos permanezcan subutilizados.
Resolver esta situación no solo implica reducir costos, sino optimizar la densidad del clúster para atender a más usuarios concurrentes con el mismo hardware de clase mundial. Esta guía detalla cómo implementar y evaluar estrategias de particionamiento de GPU, específicamente NVIDIA Multi-Instance GPU (MIG) y el uso de tiempo compartido, para aprovechar al máximo los recursos computacionales.
Utilizando una tubería de voz AI de grado de producción como nuestro campo de prueba, mostramos cómo combinar modelos para maximizar el retorno de inversión (ROI) de la 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 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. No obstante, los modelos de soporte en una tubería de IA 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 computación de GPU a menudo oscila entre el 0-10%.
- Sobreabundancia en el clúster: Se necesitan 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 solucionar esto, debemos romper la relación 1:1 entre pods y GPUs.
Arquitectura: Estrategias de particionamiento
Evaluamos dos estrategias principales para el particionamiento de GPU soportadas por el Operador de GPU de NVIDIA.
Particionamiento basado en software: Tiempo compartido y MPS
El tiempo compartido permite que múltiples procesos CUDA de NVIDIA compartan una GPU intercalando 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 la “explosión”: si el Pod A está inactivo, el Pod B puede usar el 100% de los núcleos de computación de la GPU.
- Desventajas: No hay aislamiento de hardware. Un desbordamiento de memoria (OOM) en un pod puede afectar el contexto de ejecución compartido, y un alto consumo computacional en un pod puede ralentizar a los vecinos (el efecto “vecino ruidoso”).
