Kubernetes Archives

El equipo de Azure Kubernetes Service (AKS) ha publicado una guía detallada sobre cómo utilizar la Asignación Dinámica de Recursos (DRA) con la tecnología NVIDIA vGPU en AKS. Esta actualización mejora el control y la eficiencia para el uso compartido de GPU en tareas de IA y medios.

La Asignación Dinámica de Recursos (DRA) es ahora el estándar para el uso de recursos de GPU en Kubernetes. En lugar de recursos estáticos como nvidia.com/gpu, las GPU se asignan dinámicamente utilizando DeviceClasses y ResourceClaims. Este cambio mejora la programación e integra mejor las tecnologías de virtualización como NVIDIA vGPU.

La razón para combinar estas tecnologías es clara: los aceleradores virtuales como NVIDIA vGPU a menudo manejan tareas más pequeñas. Permiten que una GPU física se divida entre muchos usuarios o aplicaciones. Esta configuración es útil para el desarrollo empresarial de IA/ML, el ajuste fino y el procesamiento de audio y video. VGPU ofrece un rendimiento predecible al tiempo que proporciona capacidades CUDA a las cargas de trabajo en contenedores.

En el lado de la infraestructura, esta función se basa en la serie de máquinas virtuales NVadsA10_v5 de Azure. En lugar de asignar toda la GPU a una sola VM, la tecnología vGPU la divide en múltiples segmentos de tamaño fijo en la capa del hipervisor. Desde la perspectiva de Kubernetes, cada VM muestra un dispositivo GPU claro. El hipervisor establece los límites de capacidad y memoria, no el software.

La configuración requiere Kubernetes 1.34 o superior. En este momento, los primitivos DRA como deviceclasses y resourceslices están disponibles. Los equipos aprovisionan un grupo de nodos con instancias NVadsA10_v5 y aplican una etiqueta (nvidia.com/gpu.present=true) para el plugin kubelet NVIDIA DRA como su selector de nodos. Luego, implementan el controlador NVIDIA DRA a través de Helm. La publicación destaca tres banderas importantes de Helm para escenarios vGPU. La bandera gpuResourcesEnabledOverride=true omite una verificación que impide que el controlador NVIDIA DRA se instale con el plugin de dispositivo heredado debido a diferentes nombres de GPU. FeatureGates.IMEXDaemonsWithDNSNames=false deshabilita una función IMEX que requiere una versión del controlador GRID más reciente que la compatible en la serie A10 en Azure.

Una vez que el controlador está activo, escanea cada nodo, detecta el único dispositivo vGPU de la VM de Azure y lo registra en el plano de control de Kubernetes como un dispositivo administrado por DRA. Cada nodo registra un dispositivo asignable porque eso es lo que presenta la VM. Los operadores pueden verificar la configuración buscando la gpu.nvidia.com DeviceClass y ResourceSlices. De esta manera, pueden confirmar que el plano de control ha encontrado el hardware disponible.

Además del segmento base de un sexto (Standard_NV6ads_A10_v5), la serie ofrece un perfil de un tercio con 8 GB de memoria aceleradora y un perfil de la mitad con 12 GB. Los límites se aplican en la capa del hipervisor, por lo que AKS ve un único dispositivo GPU con una capacidad predecible. Esto brinda a los equipos de plataforma la flexibilidad de dimensionar la asignación de GPU según las necesidades de la carga de trabajo sin sobreaprovisionar los nodos.

El equipo de AKS enmarca la importancia general como direccional. A medida que las GPU se convierten en recursos de primera clase en Kubernetes, combinar la GPU virtualizada con DRA ofrece una forma práctica de ejecutar cargas de trabajo compartidas y de nivel de producción. Para las implementaciones de AKS a gran escala, especialmente en industrias reguladas o sensibles a los costos, la ubicación y utilización óptimas de la GPU impactan directamente en el rendimiento del trabajo y la eficiencia de la infraestructura. El uso de DRA con vGPU ayuda a las organizaciones a pasar de la asignación a nivel de nodo gruesa a un uso de GPU controlado y basado en la carga de trabajo a escala.

Google Cloud está siguiendo un camino similar en GKE, centrándose en DRA como un primitivo de programación tanto para GPU como para TPU. El soporte de DRA de GKE permite a las cargas de trabajo utilizar expresiones CEL para filtrar dispositivos con atributos específicos. Esto permite que un único manifiesto se implemente en diferentes clústeres con varios tipos de GPU sin cambios. Específicamente para vGPU, Google recientemente presentó de forma preliminar VM G4 fraccionadas que utilizan la tecnología NVIDIA vGPU basada en la GPU RTX PRO 6000 Blackwell, administrada a través de GKE y combinada con el empaquetamiento de contenedores para una mayor utilización. Cuando se programa a través del Programador de Carga de Trabajo Dinámica de Google, las prioridades de respaldo pueden mejorar el acceso a los recursos.

Amazon EKS adopta un enfoque diferente, utilizando DRA principalmente para simplificar la complejidad de su hardware GPU de alta gama en lugar de compartirlo fraccionadamente. Amazon EKS hizo que DRA estuviera disponible de forma general a partir de la versión de Kubernetes 1.33. Esta tecnología es esencial para las instancias P6e-GB200 UltraServer, donde la programación estática tradicional de GPU no puede modelar la interconexión NVLink e IMEX necesaria para las cargas de trabajo de varios nodos. Para los equipos que ejecutan cargas de trabajo más pequeñas que desean compartir GPU en EKS, DRA ahora admite solicitudes basadas en atributos estructuradas. Esto permite a los programadores responder a solicitudes como «una partición MIG de 10 GB con al menos 1/7 de capacidad de cómputo» en lugar de tratar las GPU como simples recuentos. En todos los tres proveedores de la nube, el cambio de los plugins de dispositivos estáticos a DRA se está acelerando, impulsado por la necesidad de una programación de GPU más expresiva y consciente de la topología a medida que la infraestructura de IA crece en complejidad y costo.

Microsoft y NVIDIA han lanzado la Parte 2 de su colaboración para ejecutar NVIDIA Dynamo para la inferencia de modelos de lenguaje grandes en Azure Kubernetes Service (AKS). El primer anuncio apuntaba a un rendimiento bruto de 1.2 millones de tokens por segundo en sistemas de GPU distribuidos. Esta última versión se centra ahora en ayudar a los desarrolladores a trabajar más rápido y mejorar la eficiencia operativa, a través de la planificación automatizada de recursos y funciones de escalado dinámico.

Las nuevas capacidades se centran en dos componentes integrados: el Dynamo Planner Profiler y el Dynamo Planner basado en SLO (Service Level Objective). Estas herramientas trabajan juntas para resolver el desafío de la «igualación de tasas» en el servicio desagregado. Los equipos utilizan este término cuando dividen las cargas de trabajo de inferencia, separando las operaciones de prellenado, que procesan el contexto de entrada, de las operaciones de decodificación que generan tokens de salida. Estas tareas se ejecutan en diferentes grupos de GPU. Sin las herramientas adecuadas, los equipos dedican mucho tiempo a determinar la asignación óptima de GPU para estas fases.

El Dynamo Planner Profiler es una herramienta de simulación previa al despliegue que automatiza la búsqueda de las mejores configuraciones. Los desarrolladores pueden omitir las pruebas manuales de diversas estrategias de paralelización y recuentos de GPU, ahorrando horas de utilización de GPU. En su lugar, definen sus necesidades en un manifiesto DynamoGraphDeploymentRequest (DGDR). El profiler ejecuta un barrido automatizado del espacio de configuración, probando diferentes tamaños de paralelismo de tensores tanto para las etapas de prellenado como de decodificación. Esto ayuda a encontrar configuraciones que aumenten el rendimiento sin superar los límites de latencia.

El profiler incluye un modo AI Configurator que puede simular el rendimiento en aproximadamente 20 a 30 segundos basándose en datos de rendimiento premedidos. Esta capacidad permite a los equipos iterar rápidamente en las configuraciones antes de asignar recursos de GPU físicos. El resultado proporciona una configuración optimizada para aumentar lo que los equipos denominan «Goodput«, que es el mayor rendimiento posible manteniendo los límites establecidos para el Tiempo hasta el Primer Token y la Latencia Inter-Token.

Una vez que un sistema entra en producción, el Dynamo Planner basado en SLO se encarga de la orquestación en tiempo de ejecución. Este componente es «consciente de LLM», lo que significa que, a diferencia de los balanceadores de carga tradicionales, supervisa el estado del clúster. Realiza un seguimiento de elementos como la carga de la caché clave-valor en el grupo de decodificación y la profundidad de la cola de prellenado. El Planner utiliza los límites de rendimiento del profiler para escalar los trabajadores de prellenado y decodificación, ayudando a cumplir los objetivos de nivel de servicio a medida que cambian los patrones de tráfico.

El anuncio ilustra estas capacidades a través de un escenario detallado de asistente de aerolíneas. En este caso, un modelo Qwen3-32B-FP8 soporta una aplicación móvil de una aerolínea, cumpliendo estrictos acuerdos de nivel de servicio: 500 milisegundos para el Tiempo hasta el Primer Token y 30 milisegundos para la Latencia Inter-Token. Durante las operaciones normales con consultas cortas de los pasajeros, el sistema funciona con un trabajador de prellenado y un trabajador de decodificación. Cuando una interrupción meteorológica provoca que 200 usuarios envíen solicitudes complejas de cambio de ruta, el Planner detecta el aumento y escala a dos trabajadores de prellenado, manteniendo uno de decodificación. Los equipos informan que el nuevo trabajador se pone en línea en cuestión de minutos, lo que permite al sistema mantener los objetivos de latencia durante el aumento del tráfico.

Este lanzamiento se basa en el marco introducido en el anuncio original de Dynamo, que InfoQ cubrió en diciembre de 2024. En ese artículo, Azure y NVIDIA explicaron cómo el diseño de Dynamo divide las tareas que consumen muchos recursos computacionales y las tareas que consumen mucha memoria en varias GPU, lo que permite a los equipos optimizar cada fase de forma independiente, adaptando los recursos a las necesidades de la carga de trabajo. Por ejemplo, la tarea de prellenado de una aplicación de comercio electrónico puede procesar miles de tokens, mientras que su tarea de decodificación solo genera descripciones cortas.

La transición de la configuración manual a la gestión automatizada de recursos basada en SLO demuestra cómo los equipos pueden manejar mejor el despliegue de modelos de lenguaje grandes en Kubernetes. Los componentes del Planner proporcionan herramientas que transforman las necesidades de latencia en opciones de asignación y escalado de GPU, con el objetivo de reducir la carga operativa de ejecutar arquitecturas de inferencia desagregadas. Las herramientas de automatización pueden ayudar a las organizaciones con modelos LLM que requieren mucho razonamiento o un contexto largo, facilitando la gestión de configuraciones complejas de GPU multinodo y apoyando el cumplimiento de los objetivos de nivel de servicio durante los cambios en los patrones de tráfico.

Kubernetes

AKS: Asignación Dinámica de GPU con vGPU de NVIDIA

NVIDIA Dynamo en Azure AKS: Optimización IA con Escalado Automático