NVIDIA detalla la receta de ejecución de Kubernetes para Dynamo
NVIDIA afirmó que los equipos que despliegan Dynamo en Kubernetes necesitan más que el propio framework de servicio: la pila de controladores de la GPU, las capas de planificación, red y observabilidad también deben estar alineadas antes de que un endpoint de inferencia sea fiable. En una publicación técnica publicada el 30 de octubre de 2026, la compañía describió cómo su NVIDIA IA Cluster Runtime (AICR) empaqueta a Dynamo con recetas de infraestructura validadas para hacer que ese proceso sea repetible.
Evidencia y contexto
La publicación presenta a Dynamo como un marco de inferencia distribuida que coordina el servicio del modelo entre los trabajadores de la GPU, pero dice que el tiempo de ejecución que hay debajo es igualmente importante. NVIDIA dijo que un clúster de inferencia en producción debe confirmar que el operador de la GPU y la pila de controladores coinciden con los nodos, que los nodos de la GPU están etiquetados y son descubribles, Kubernetes expone las GPUs mediante la asignación dinámica de recursos, el planificador puede colocar trabajadores con la topología adecuada y la semántica de planificación en grupo, las señales de salud de los nodos están disponibles antes de que lleguen las cargas de trabajo, Prometheus es accesible para métricas y la ruta de la API Gateway se configura cuando se usa entrada nativa de Kubernetes.
Según el artículo, AICR recoge esos requisitos en una receta. La receta incluye versiones fijadas de componentes, restricciones de compatibilidad, selectores de nodos, tolerancias, sumas de comprobación y expectativas de validación. NVIDIA dijo que la receta de Dynamo incluye la versión 1.4.2 del gráfico de la plataforma Dynamo, incluyendo el operador Dynamo, las imágenes en tiempo de ejecución y la definición de recurso personalizada nvidia.com/v1beta1 DynamoGraphDeployment. La empresa dijo que v1beta1 reemplaza la versión anterior de la API v1alpha1 .
La publicación también decía que la fórmula AICR ya no instala NATS por defecto para Dynamo 1.4; en su lugar, los frontends, los trabajadores y los componentes opcionales de la Extensión de Inferencia de API de Gateway / Endpoint Picker Plugin descubren uno otro a través de recursos de Kubernetes. NVIDIA dijo que NATS sigue disponible como opción opt-in para despliegues que aún lo necesiten.
Rutas de enrutamiento para Dynamo en Kubernetes
NVIDIA describió dos topologías de enrutamiento. La primera utiliza el router Dynamo Frontend detrás de un servicio Kubernetes. En este camino, el frontend tokeniza las solicitudes, puntua a los trabajadores elegibles usando solapamiento de prefijos y carga actual, selecciona un worker y envía la solicitud a través del plano de peticiones TCP de Dynamo. La empresa dijo que esta es la topología más pequeña y es adecuada para un endpoint específico del modelo o un proxy de borde existente que solo reenvíe tráfico al Servicio Frontend de Dynamo.
El segundo camino integra Dynamo con la API de Gateway y la Extensión de Inferencia de la API de Gateway. En esa topología, un gateway como agentgateway resuelve un HTTPRoute a un InferencePool, el operador crea ese pool desde el DynamoGraphDeployment, y Dynamo EPP realiza la selección del endpoint consciente del token. NVIDIA dijo que la pasarela sigue siendo el proxy HTTP, mientras que un sidecar Dynamo Frontend en cada pod de trabajo enrutable funciona en modo directo y reenvía la solicitud al contenedor de trabajo.
La publicación decía que ambos caminos utilizan eventos KV-cache publicados por los trabajadores para decisiones de enrutamiento. También señalaba que Dynamo puede enrutar basándose en el estado de caché previsto, pero la predicción no puede detectar desalojos, por lo que la calidad del enrutamiento puede degradarse bajo presión de memoria. La configuración AICR en el artículo utiliza eventos en tiempo real en su lugar.
Flujo de trabajo de despliegue y validación
NVIDIA diseñó un flujo de trabajo AICR de cinco pasos. Primero, se toma una instantánea de clúster con el comando de instantánea AICR. Segundo, AICR genera una receta para inferencia en la plataforma seleccionada. Tercero, el paquete de tiempo de ejecución se renderiza en manifiestos listos para despliegue y valores de Helm. Cuarto, el tiempo de ejecución se despliega a través de Helmfile u otros despleguadores compatibles. Quinto, el tiempo de ejecución instalado se valida antes de añadir la carga de trabajo de la aplicación.
Para la receta de inferencia Amazon EKS Dynamo para los sistemas NVIDIA GB200 NVL72 y NVIDIA GB300 NVL72 , la publicación listaba versiones fijadas de gráficos incluyendo NVIDIA GPU Operator v26.7.1, Node Feature Discovery 0.19.0, certific-manager v1.20.2, 2.59.0 controlador AWS EBS CSI, AWS EFA v0.5.29, NVSentinel v1.25.0, NodeWright Operator v0.19.0, 0.5.0 controlador de GPU NDidia DRA, v0.16.9 de programador KAI, v0.1.0 de Grove alpha.13, Dynamo Platform 1.4.2, Agent Gateway v1.5.0, CRDs de Agent Gateway v1.5.0, Kube Prometheus Stack 84.4.0, CRDs de Prometheus Operator 28.0.1, Prometheus Adapter 5.3.0 y Kubernetes Ephemeral Storage Metrics 1.19.2.
Las comprobaciones de validación, según el artículo, suelen cubrir la salud base del clúster, el estado del operador GPU, acceso al acelerador, planificación en grupo y comportamiento de escalado automático, observabilidad mediante métricas respaldadas por Prometheus, y la preparación de la API de Gateway y agentgateway para la entrada nativa de Kubernetes. NVIDIA dijo que la validación de rendimiento es separada porque despliega una carga de trabajo temporal de servicio y consume las GPUs bajo prueba.
La empresa cerró diciendo que AICR y Dynamo son componentes de código abierto de la plataforma fábrica NVIDIA DSX IA, con ejemplos de despliegue y recursos comunitarios disponibles a través del NVIDIA DSX IA Factory GitHub y la comunidad de Slack. También se mencionó actividad práctica en talleres en KubeCon + CloudNativeCon Norteamérica, aunque el artículo no especificó una fecha futura de catalizador más allá de esa mención del evento.