En entornos de producción con 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, sin embargo, ocupan una GPU completa en implementaciones estándar de Kubernetes. Dado que el programador asigna un modelo a una o más GPU y no puede compartir fácilmente entre modelos, los recursos de cómputo costosos a menudo permanecen subutilizados.
Resolver esto no solo se trata de reducir costos; se trata de optimizar la densidad del clúster para servir a más usuarios concurrentes con el mismo hardware de clase mundial. 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 de cómputo.
Usando una pipeline de voz AI de grado de producción como nuestro banco de pruebas, mostramos cómo combinar modelos para maximizar el retorno de inversión (ROI) de la infraestructura, manteniendo una confiabilidad 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 GPU como recursos enteros. Un pod solicita nvidia.com/gpu: 1, y el programador lo vincula a un dispositivo físico.
Grandes modelos de lenguaje (LLMs) como NVIDIA Nemotron, Llama 3 o Qwen 7B/8B requieren cómputo dedicado para mantener un bajo tiempo de primera 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. Ejecutar estos modelos ligeros en GPUs dedicadas resulta en:
- Utilización baja: la utilización de cómputo de GPU a menudo se mantiene entre el 0-10%.
- Inflación del clúster: se necesitan más nodos para ejecutar la misma cantidad de pods.
- Fricción en la escalabilidad: agregar 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 partición
Evaluamos dos estrategias principales para la partición de GPU soportadas por el Operador de GPU NVIDIA.
Partición basada en software: Time-slicing y MPS
El time-slicing permite que múltiples procesos de 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.
- Pros: Maximiza la utilización. Permite “bursting”: si el Pod A está inactivo, el Pod B puede utilizar el 100% de los núcleos de cómputo de la GPU.
- Contras: Sin aislamiento de hardware. Un desbordamiento de memoria (OOM) en un pod puede afectar el contexto de ejecución compartido, y un cómputo pesado en un pod puede limitar a los vecinos (el efecto de “vecino ruidoso”).
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 concurrentemente utilizando una arquitectura de servidor-cliente. Esto brinda 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 estándar.
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. Este retraso puede fluctuar significativamente según la longitud del contexto; por ejemplo, escenarios de alta entrada (como entrenar usuarios) o historias de conversación en crecimiento aumentan la sobrecarga de procesamiento en comparación con indicaciones cortas. A medida que la historia se acumula, el LLM debe procesar más tokens antes de generar una respuesta, extendiendo el cuello de botella que los modelos de soporte deben enmascarar.
Consolidar modelos de soporte como ASR y TTS proporciona un camino estratégico para maximizar la utilización del hardware mientras se mantiene la capacidad de respuesta de extremo a extremo. Aunque la consolidación puede introducir un ligero ajuste de latencia de 100-200 ms, las ganancias en el rendimiento de la infraestructura y el ROI son significativas.
