Optimiza el uso de GPUs en Kubernetes consolidando cargas de trabajo subutilizadas

La optimización de la infraestructura de inteligencia artificial (IA) es crucial en los entornos de Kubernetes. En este contexto, los modelos ligeros de reconocimiento automático de voz (ASR) o texto a voz (TTS) requieren menos recursos, pero pueden desperdiciar GPU enteras en despliegues estándar. Esto sucede porque el programador asigna un modelo a una o más GPUs y no puede compartir fácilmente los recursos.

Resolver esta ineficiencia implica no solo reducir costos, sino también optimizar la densidad del clúster para atender a más usuarios concurrentes con el mismo hardware de alta calidad. Este artículo presenta cómo implementar y evaluar estrategias de particionamiento de GPU, como NVIDIA Multi-Instance GPU (MIG) y time-slicing, para maximizar el uso de los recursos computacionales.

Utilizando una pipeline de voz AI de grado de producción como banco de pruebas, demostramos cómo combinar modelos para maximizar el retorno de la inversión (ROI) de la infraestructura, manteniendo una fiabilidad superior al 99% y garantizando estrictos tiempos 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 de gran tamaño (LLMs) como NVIDIA Nemotron, Llama 3, o Qwen 7B/8B requieren computación dedicada para mantener un bajo tiempo de respuesta. Sin embargo, los modelos de soporte en una pipeline de IA generativa, como ASR, TTS o guardrails, suelen utilizar solo una fracción de una tarjeta. Ejecutar estos modelos ligeros en GPUs dedicadas resulta en:

• Baja utilización: La utilización de la GPU suele estar entre el 0-10%.
• Exceso de nodos: Se requieren más nodos para ejecutar el mismo número de pods.
• Dificultades para escalar: 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 particionamiento

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: un contexto A se ejecuta, se pausa y un contexto B se ejecuta.

• Mecanismo: Programación a nivel de software a través del controlador CUDA.
• Ventajas: Maximizan la utilización. Permiten “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 en un pod puede impactar el contexto de ejecución compartido, y una carga pesada en un pod puede afectar a sus vecinos.

Además del time-slicing, el Servicio de Múltiples Procesos (MPS) de NVIDIA ofrece un enfoque alternativo. MPS permite que múltiples procesos compartan recursos de GPU de manera concurrente mediante una arquitectura de servidor-cliente. Esto proporciona más flexibilidad que MIG y es más resistente a problemas como pérdidas de memoria.

No obstante, 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 aisladas, carece de aislamiento de fallos a nivel de hardware.

MIG: El enfoque de hardware para el particionamiento

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 estricta. Un proceso no puede afectar el rendimiento o la estabilidad de otro.
• Desventajas: Tamaño rígido. Si una partición está inactiva, sus recursos computacionales no pueden ser “tomados” por un vecino.

Mientras que el time-slicing ofrece flexibilidad, MIG es preferido para entornos de producción donde se requiere un estricto aislamiento de fallos a nivel de hardware. Esto asegura que un error de memoria en un modelo no cause un fallo en cascada en la GPU compartida.

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 entender 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; escenarios de alta entrada o historiales de conversación en crecimiento aumentan la sobrecarga de procesamiento.

Consolidar modelos de soporte como ASR y TTS proporciona una vía estratégica 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.

Nuestra hipótesis

Consolidar las cargas de trabajo de ASR y TTS en una sola GPU preserva la latencia y la variabilidad mientras libera recursos computacionales para instancias adicionales de LLM.

Experimento

Diseñamos tres configuraciones distintas para probar. En cada ronda, utilizamos tres muestras de voz, esperando la primera respuesta de LLM+TTS. La configuración utilizó un clúster de Kubernetes, modelos desplegados utilizando NVIDIA NIM, y gestionados por el operador NVIDIA NIM. El nodo de trabajo tenía acceso a tres GPUs NVIDIA A100 Tensor Core.

• Experimento 1: Línea base con tres GPUs
  • Configuración: Una GPU dedicada para cada modelo (LLM, ASR, TTS).
  • Objetivo: Establecer el “estándar de oro” para la latencia y el rendimiento.
  • Recurso: nvidia.com/gpu: 1 por pod.
• Experimento 2: Time-slicing con dos GPUs
  • Configuración: LLM retiene una GPU dedicada. ASR y TTS comparten la GPU 0 usando time-slicing.
  • Objetivo: Probar si la programación dinámica puede manejar la contención entre ASR y TTS.
  • Recurso: nvidia.com/gpu: 1 (Compartido a través de replicas: 2).
• Experimento 3: Particionamiento MIG con dos GPUs
  • Configuración: LLM retiene una GPU dedicada. La GPU 0 está particionada físicamente en dos instancias aisladas.
  • Objetivo: Probar si el aislamiento de hardware proporciona mejor estabilidad que la programación por software.
  • Recurso: nvidia.com/mig-3g.40gb: 1 por pod.

Nota de configuración: Para lograr estas topologías, utilizamos configuraciones específicas dentro del operador NVIDIA GPU.

• Para el Experimento 2, utilizamos la configuración timeSlicing para publicitar múltiples réplicas por GPU física.
• Para el Experimento 3, aplicamos un ConfigMap personalizado mig-configs para particionar la GPU en dos instancias 3g.40gb.

(Para los comandos kubectl y manifiestos YAML exactos utilizados, consulte el Apéndice de Implementación al final de este artículo.)

Resultados

Para evaluar la fragmentación de recursos, probamos el sistema con dos patrones de tráfico distintos:

• Carga ligera: 5 usuarios concurrentes simulando ~135 segundos de interacción sostenida.
• Carga pesada: 50 usuarios concurrentes simulando ~375 segundos de interacción sostenida.

La Figura 5 compara el rendimiento de las inferencias de IA generativa bajo diferentes patrones de tráfico. Los datos muestran cómo el particionamiento afecta las solicitudes de proceso a medida que aumenta la concurrencia, comparando baseline, time-slicing y MIG bajo cargas ligeras y pesadas. Todos los experimentos tuvieron una tasa de éxito del 100%, sin fallos.

Métricas de latencia media

El siguiente análisis evalúa cómo diferentes estrategias de particionamiento de GPU impactan en la eficiencia y capacidad de respuesta del sistema.

Rendimiento comparado con la latencia

Consolidar las cargas de trabajo de ASR y TTS en una sola GPU resulta en una pipeline optimizada, permitiendo al clúster soportar más flujos de IA simultáneos. Sin embargo, nuestros benchmarks revelan una divergencia crítica en el rendimiento entre las dos estrategias de particionamiento:

1. MIG (hardware): Mayor eficiencia

El Experimento 3 logró la mayor productividad por unidad, alcanzando ~1.00 req/s por GPU. Al proporcionar caminos de hardware dedicados para cada instancia, MIG elimina la contención de recursos y permite alcanzar casi toda la capacidad del sistema.

1. Time-slicing (software): Mayor densidad con sobrecarga

El Experimento 2 mostró que el uso compartido a nivel de software también puede mejorar la densidad por GPU, logrando ~0.76 req/s por GPU. Sin embargo, la gestión de cambios de contexto rápidos introduce sobrecarga de programación. Aunque es funcional, este enfoque no alcanza la eficiencia de rendimiento agregada proporcionada por el particionamiento de hardware.

Latencia y el factor de carga intermitente

El time-slicing maneja tareas individuales intermitentes ligeramente más rápido, con una latencia TTS media de 144.7 ms en comparación con los 168.2ms de MIG. Sin embargo, esta diferencia representa una fracción pequeña del tiempo total de respuesta. Dado que el usuario final no puede percibir un delta de 20ms en una respuesta de varios segundos, la estabilidad del throughput de MIG es un métrico más valioso en producción.

Recomendaciones para el particionamiento

Basado en los datos de benchmark, recomendamos la siguiente matriz de decisiones:

1. Optar por MIG para producción y estabilidad
   • El Experimento 3 mostró que MIG maneja mayores volúmenes de solicitudes (2 req/s) con solo un ligero compromiso de latencia.
   • El aislamiento de fallos a nivel de hardware evita que un desbordamiento de memoria en un proceso afecte a otro.
   • Ideal para entornos de producción donde el throughput y la fiabilidad son prioridades.
2. Utilizar time-slicing para aplicaciones de desarrollo o bajo concurrencia
   • Esto implica una reducción del 32% en el throughput total y dependencias de recursos compartidos.
   • Mejor para desarrollo, CI/CD y pruebas de concepto en un hardware mínimo.

Comenzar

1. Experimentar más: Prueba el repositorio.
2. Implementar particionamiento: Sigue nuestra Guía de Implementación para configurar perfiles MIG y utilizar los manifiestos YAML proporcionados.
3. Escalar con NIM: Desplegar pipelines NVIDIA NIM para maximizar el ROI.