La consolidación de cargas de trabajo GPU infrautilizadas es esencial para maximizar el rendimiento en entornos Kubernetes. Los modelos de reconocimiento automático de voz (ASR) o de texto a voz (TTS) requieren solo 10 GB de VRAM, pero pueden ocupar una GPU completa en implementaciones estándar, creando ineficiencias. El programador asigna un modelo a una o más GPUs, lo que a menudo resulta en recursos de cómputo costosos subutilizados.
Este problema no se limita a la reducción de costos; también es crucial para optimizar la densidad del clúster y atender a más usuarios concurrentes con hardware de alta calidad. Esta guía describe cómo implementar y evaluar estrategias de particionado de GPU, específicamente NVIDIA Multi-Instance GPU (MIG) y el uso de time-slicing para aprovechar al máximo los recursos de cómputo.
Usando un pipeline de voz AI de grado de producción como base de prueba, se demuestra cómo combinar modelos para maximizar el retorno de inversión (ROI) de la infraestructura, manteniendo más del 99% de fiabilidad 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 baja la latencia y alta la capacidad de procesamiento por lotes. Sin embargo, los modelos de soporte en un pipeline de AI generativa, como modelos de incrustación, ASR y TTS, a menudo utilizan solo una fracción de una GPU. Esto resulta en:
- Baja utilización: La utilización de computación de GPU suele estar entre el 0-10%.
- Exceso de nodos: Se requieren más nodos para ejecutar el mismo número de pods.
- Dificultades de escalado: Añadir una nueva capacidad requiere una nueva GPU física.
Para solucionar esto, es necesario romper la relación 1:1 entre pods y GPUs.
Arquitectura: Estrategias de particionado
Se evaluaron dos estrategias primarias para el particionado de GPU compatibles con el operador de GPU de NVIDIA.
Particionado basado en software: Time-slicing y MPS
El time-slicing permite que múltiples procesos CUDA de NVIDIA compartan una GPU mediante la intercalación de ejecución. Funciona de manera similar a un programador de CPU: el contexto A se ejecuta, 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 y permite el “estallido”; si el Pod A está inactivo, el Pod B puede usar el 100% de los núcleos de cómputo de la GPU.
- Desventajas: Sin aislamiento de hardware; un desbordamiento de memoria en un pod puede afectar el contexto de ejecución compartido.
Además del time-slicing, el Servicio de Múltiples Procesos (MPS) de NVIDIA ofrece un enfoque alternativo basado en software. MPS permite que múltiples procesos compartan recursos de GPU simultáneamente mediante una arquitectura cliente-servidor. 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: El enfoque hardware para el particionado
El MIG particiona físicamente la GPU en instancias separadas, cada una con su propia memoria dedicada, caché y multiprocesadores de streaming (SMs). Para el sistema operativo y Kubernetes, estas se ven como dispositivos PCI separados.
- Mecanismo: Aislamiento a nivel de hardware.
- Ventajas: Calidad de servicio (QoS) estricta; un trabajo no puede afectar el rendimiento o la estabilidad de otro.
- Desventajas: Tamaño rígido; si una partición está inactiva, sus recursos de cómputo no pueden ser “tomados prestados” por otro.
Si bien el time-slicing ofrece flexibilidad, MIG es preferido en entornos de producción donde se requiere un estricto aislamiento de fallos a nivel de hardware para cumplir con los acuerdos de nivel de servicio (SLA) empresariales. El particionado de hardware garantiza que un error de memoria en un modelo no pueda causar una falla en cascada en la GPU compartida, un requisito crítico para AI de voz en entornos de misión crítica.
