En entornos de producción de Kubernetes, la diferencia entre los requisitos del modelo y el tamaño de la GPU genera ineficiencias. Modelos livianos 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 implementaciones estándar de Kubernetes. Esto ocurre porque el programador asigna un modelo a una o más GPUs y no puede compartir fácilmente recursos entre modelos.
Resolver esta situación no solo implica una reducción de costos; es fundamental para optimizar la densidad del clúster y atender a más usuarios concurrentes con el mismo hardware de alta calidad. Esta guía detalla cómo implementar y evaluar estrategias de partición de GPU, específicamente NVIDIA Multi-Instance GPU (MIG) y time-slicing, para utilizar completamente los recursos computacionales.
Utilizando una pipeline de voz AI de calidad de producción como nuestro banco de pruebas, demostramos 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 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 una pipeline de AI generativa—modelos de incrustación, ASR, TTS, o guardrails—utilizan solo una fracción de una tarjeta. Ejecutar estos modelos livianos en GPUs dedicadas resulta en:
- Baja utilización: La utilización de GPU a menudo oscila entre 0-10%.
- Exceso de nodos: Se necesitan más nodos para ejecutar el mismo número de pods.
- Fricción al escalar: Agregar 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 GPUs 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 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 “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 cálculo intensivo en un pod puede estrangular a los vecinos (el efecto de “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.
Sin embargo, en producción, ambos métodos comparten un único contexto de ejecución, limitando el aislamiento. Aunque el MPS moderno proporciona espacios de direcciones virtuales aislados, carece de aislamiento de fallos a nivel de hardware. Esto significa que un error de ejecución fatal o un acceso ilegal a la memoria en un proceso se propagará a través del contexto compartido, lo que podría llevar a un reinicio de la GPU que afectaría a otros procesos que comparten la tarjeta.
