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.
