En entornos de producción de Kubernetes, la diferencia 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 de 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 GPU y no puede compartir fácilmente recursos entre varios modelos.
Resolver este problema no solo se trata de reducir costos, sino de optimizar la densidad del clúster para atender más usuarios concurrentes en el mismo hardware de alta calidad. 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 aprovechar al máximo los recursos computacionales.
Fragmentación de recursos de GPU
Por defecto, el Plugin de Dispositivos NVIDIA para Kubernetes muestra las GPU 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 tiempo bajo para el primer token (TTFT) y un alto rendimiento por lotes. Sin embargo, los modelos de soporte en una pipeline de IA generativa, como modelos de incrustación, ASR, TTS o guardrails, a menudo utilizan solo una fracción de una tarjeta.
Estrategias de particionamiento de arquitectura
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 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.
Además, el Servicio de Múltiples Procesos de NVIDIA (MPS) ofrece un enfoque alternativo basado en software, permitiendo que múltiples procesos compartan recursos de GPU de manera concurrente mediante una arquitectura de servidor-cliente. Esto proporciona más flexibilidad que el MIG y es más resistente a ciertos problemas como fugas de memoria en comparación con el time-slicing.
Configuración experimental: La pipeline de voz AI
Para validar estas estrategias en un escenario realista de producción, utilizamos una pipeline multimodal de voz a voz AI. Esta carga de trabajo es ideal para la evaluación porque mezcla tres patrones de tráfico distintos.
Antes de optimizar, es crucial comprender nuestro perfil de latencia. En nuestra pipeline de voz a voz, el LLM es el principal cuello de botella. Bajo cargas pesadas, el LLM representa aproximadamente 9 segundos del tiempo total de procesamiento. Esta demora puede fluctuar significativamente según la longitud del contexto.
Resultados
Para evaluar la fragmentación de recursos, probamos el sistema con dos patrones de tráfico distintos: carga ligera y carga pesada.
La Figura 5 compara el rendimiento de inferencia de IA generativa en diferentes patrones de tráfico. Los datos muestran cómo el particionamiento afecta las solicitudes de proceso a medida que aumenta la concurrencia, en comparación con la línea base, el time-slicing y el MIG bajo cargas ligeras y pesadas.
