NVIDIA Dynamo: La capa de servicio distribuida alrededor de los motores de inferencia

El video comienza con Ron, un ingeniero de plataforma cuyo equipo ya ejecuta modelos en producción con un motor de inferencia saludable. Su pregunta es la correcta: si el motor responde, ¿qué problema está resolviendo Dynamo realmente?

La respuesta radica en el posicionamiento: el framework de código abierto de NVIDIA no es otro motor de inferencia, sino una capa de servicio distribuida que los envuelve. Mientras SGLang, TensorRT-LLM o vLLM siguen generando tokens, Dynamo enruta las solicitudes, coordina a los trabajadores, reduce el trabajo desperdiciado y compone una configuración multi-GPU en una sola arquitectura.

Las implementaciones pequeñas no necesitan nada de esto: un cliente envía una solicitud, el servidor ejecuta el prellenado y la decodificación, la respuesta regresa. Pero a medida que los usuarios, la longitud de las indicaciones y la variedad de modelos crecen y los objetivos de latencia se ajustan, los problemas difíciles van más allá de ejecutar el modelo: decidir quién ejecuta qué, dónde, en una costosa capacidad de GPU.

El primer trabajo de la capa es coordinar el prellenado y la decodificación entre grupos de trabajadores separados. El prellenado procesa la indicación de entrada y construye la caché KV, mientras que la decodificación utiliza esa caché para producir tokens de salida. Debido a que las dos fases desean recursos diferentes, ejecutarlas en grupos dedicados vale la pena a medida que la carga crece.

El segundo trabajo es reducir el desperdicio: una pila que trata cada solicitud como aislada vuelve a calcular los prefijos de indicación compartidos, pierde la reutilización de la caché KV y deja las costosas GPU inactivas. Dynamo tiene como objetivo cerrar esa brecha haciendo el trabajo compartido una vez y compartiendo el resultado.

Los trabajos tres y cuatro son el enrutamiento y la tolerancia a fallos. Con más de un trabajador, el envío de solicitudes necesita un cerebro que conozca la capacidad, el estado del trabajador y dónde se encuentra cada modelo. Y cuando los trabajadores fallan y los nodos se reinician en producción, la capa de servicio monitorea la salud y dirige el tráfico alrededor de las partes defectuosas.

El quinto trabajo es la componibilidad: clientes, lógica de enrutamiento, trabajadores del motor, planificadores, piezas del plano de control y operadores de Kubernetes se encuentran en un solo framework en lugar de código "pegamento" personalizado. Las piezas son modulares, por lo que un equipo puede comenzar con el frontend, un motor o un enrutamiento más inteligente y agregar el resto a medida que crece la implementación.

El momento no es casual: los modelos siguen creciendo, los diseños de mezcla de expertos se extienden, y los sistemas a escala de rack como el GB200 NVL72 hacen que la velocidad máxima de una sola GPU sea la pregunta equivocada. La nueva pregunta es si una flota multi-GPU escala de manera eficiente, se recupera de manera confiable, reutiliza el trabajo y sigue siendo comprensible, y Dynamo 1.0 responde con una ganancia de rendimiento reclamada de 7x en hardware Blackwell.