La optimización del uso de recursos en entornos de Kubernetes es crucial para mejorar la eficiencia. En este contexto, los modelos de reconocimiento automático de voz (ASR) y de texto a voz (TTS) suelen requerir menos memoria de video de la que un GPU puede ofrecer, lo que da lugar a un uso ineficaz de los recursos.
Este artículo explora cómo implementar y evaluar estrategias de particionamiento de GPU, como NVIDIA Multi-Instance GPU (MIG) y el uso de técnicas de time-slicing. Estas estrategias buscan maximizar la utilización de los recursos computacionales, permitiendo manejar más usuarios concurrentes en hardware de alto rendimiento.
Utilizando un pipeline de voz AI como caso de estudio, se demuestra cómo combinar modelos para optimizar el retorno de inversión (ROI) de la infraestructura, manteniendo una alta fiabilidad y bajos tiempos de latencia.
Fragmentación de recursos de GPU
Por defecto, el Plugin de Dispositivo NVIDIA para Kubernetes presenta 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 (LLM) como NVIDIA Nemotron o Llama 3 requieren recursos dedicados para mantener bajos tiempos de respuesta. Sin embargo, los modelos de soporte en un pipeline de IA generativa, como ASR y TTS, a menudo utilizan solo una fracción de la capacidad de la GPU, lo que resulta en una baja utilización de recursos.
- Utilización baja: La utilización de GPU a menudo se encuentra entre 0-10%.
- Exceso de nodos: Se necesitan más nodos para ejecutar el mismo número de pods.
- Dificultades para escalar: Añadir capacidades nuevas requiere una nueva GPU física.
Es necesario romper la relación 1:1 entre pods y GPUs para resolver esta problemática.
Estrategias de particionamiento
Se evaluaron dos estrategias principales de particionamiento de GPU soportadas por el NVIDIA GPU Operator.
Particionamiento basado en software
El time-slicing permite que múltiples procesos CUDA de NVIDIA compartan una GPU mediante la ejecución intercalada. Funciona de manera similar a un programador de CPU, donde se pausa un contexto y se ejecuta otro.
- Mecanismo: Programación a nivel de software a través del controlador CUDA.
- Ventajas: Maximiza la utilización. Permite “bursting”, donde si el Pod A está inactivo, el Pod B puede usar el 100% de las cores de la GPU.
- Desventajas: Sin aislamiento físico. Un desbordamiento de memoria en un pod puede afectar el contexto de ejecución compartido.
Además del time-slicing, el NVIDIA Multi-Process Service (MPS) ofrece un enfoque alternativo basado en software, permitiendo que múltiples procesos compartan recursos de GPU simultáneamente.
Sin embargo, ambos métodos comparten un único contexto de ejecución, limitando el aislamiento.
MIG: El enfoque hardware
MIG particiona físicamente la GPU en instancias separadas, cada una con su propia memoria dedicada. Para el sistema operativo y Kubernetes, estas instancias parecen dispositivos PCI separados.
- Mecanismo: Aislamiento a nivel de hardware.
- Ventajas: Estricto control de calidad. Un trabajo no puede afectar el rendimiento de otro.
- Desventajas: Tamaños rígidos. Si una partición está inactiva, sus recursos no pueden ser “tomados” por un vecino.
El particionamiento hardware es preferido en entornos de producción donde se requiere un aislamiento estricto.
Configuración experimental
Para validar estas estrategias, se utilizó un pipeline de voz AI multimodal. Este tipo de carga de trabajo es ideal para la evaluación, ya que mezcla distintos patrones de tráfico.
Antes de optimizar, es fundamental entender el perfil de latencia. En nuestro pipeline, el LLM representa el principal cuello de botella, especialmente bajo cargas pesadas.
Consolidar modelos de soporte como ASR y TTS ofrece un camino estratégico para maximizar la utilización del hardware manteniendo la capacidad de respuesta.
Nuestra hipótesis
Consolidar las cargas de trabajo de ASR y TTS en una sola GPU preserva la latencia mientras libera recursos para instancias adicionales de LLM.
Experimento
Se diseñaron tres configuraciones distintas para las pruebas, utilizando un clúster de Kubernetes y modelos gestionados por el NVIDIA NIM Operator.
- Experimento 1: Línea base con tres GPUs.
- Experimento 2: Time-slicing con dos GPUs.
- Experimento 3: Particionamiento MIG con dos GPUs.
Las configuraciones específicas se aplicaron dentro del NVIDIA GPU Operator para lograr estas topologías.
Resultados
Se evaluó la fragmentación de recursos bajo dos patrones de tráfico distintos: carga ligera y carga pesada.
Los resultados muestran cómo el particionamiento afecta el rendimiento a medida que aumenta la concurrencia. El Experimento 3 con MIG alcanzó la mayor eficiencia.
Métricas de latencia media
El análisis evalúa cómo las distintas estrategias de particionamiento de GPU impactan la eficiencia del sistema.
Recomendaciones para el particionamiento
Con base en los datos obtenidos, se recomienda lo siguiente:
- Optar por MIG para entornos de producción.
- Utilizar time-slicing para desarrollo o aplicaciones de baja concurrencia.
Comenzar
- Experimentar más: Probar el repositorio.
- Implementar particionamiento: Seguir nuestra Guía de Implementación.
- Escalar con NIM: Desplegar pipelines NVIDIA NIM.
