Inferencia en Kubernetes: valida el runtime completo

El 30 de octubre de 2026, dos días calendario antes de esta publicación en America/Lima, NVIDIA publicó un flujo para desplegar y validar Dynamo sobre Kubernetes con AI Cluster Runtime (AICR). La noticia no es un benchmark de modelo: es una forma de tratar drivers, descubrimiento y asignación de GPU, scheduler, coordinación de workloads, métricas e ingress como una sola dependencia versionada. La receta descrita fija componentes y expectativas; luego contrasta el cluster real con checks de configuración y comportamiento antes de instalar la aplicación. Para un CTO, la decisión concreta es separar tres aprobaciones: la receta es compatible con el entorno capturado, el runtime desplegado satisface sus checks y el endpoint cumple el SLO y la calidad del producto. Ninguna sustituye a las otras. Un HTTP 200 solo demuestra que una ruta respondió; no confirma que el workload pueda reprogramarse, que una GPU degradada quede fuera, que el router vea el estado real del caché o que las métricas permitan diagnosticar una regresión.

El artículo oficial muestra una receta de inferencia para Dynamo que incluye el chart de plataforma fijado en la versión 1.4.2 y dependencias como GPU Operator, Dynamic Resource Allocation, KAI Scheduler, Grove, Prometheus y una ruta opcional de Gateway API. Esa lista no debe copiarse como arquitectura universal. Su valor es revelar el contrato oculto debajo del servidor de modelo y convertirlo en artefactos que pueden revisarse, reproducirse y volver a validar.

El flujo comienza capturando un snapshot normalizado del cluster. Ese artefacto describe distribución de Kubernetes, aceleradores, sistema operativo y señales de topología que el resolver puede observar. La intención del workload —por ejemplo, inferencia con Dynamo— se añade de forma explícita. Con ambos insumos, AICR selecciona una receta que fija versiones, compatibilidad, placement, checksums y expectativas de validación. Después renderiza un bundle para la herramienta de despliegue elegida. La separación importa: el snapshot describe lo que existe, la receta declara lo que debería existir y el bundle expresa cómo materializarlo.

Validar sin conexión contra otro snapshot permite detectar restricciones declarativas antes de tocar un cluster, pero omite checks conductuales. La validación en vivo debe comprobar recursos, acceso a aceleradores, salud de operadores, scheduling, scaling, observabilidad e ingress. Luego la aplicación instala su propio grafo de inferencia y ejecuta pruebas del endpoint. Este orden evita mezclar un fallo de plataforma con un fallo del modelo. También deja una cadena auditable: snapshot, receta, bundle, reporte de validación, manifiesto de aplicación y resultado de aceptación.

La procedencia es parte del mecanismo, no un adorno. El repositorio de AICR describe recetas versionadas, artefactos de release, SBOM y attestations verificables. Aun así, una firma prueba origen e integridad dentro de su alcance; no demuestra que el runtime sea seguro para cualquier política de red ni que la aplicación cumpla su calidad. El consumidor debe registrar exactamente qué identidad firmó, qué hashes cubre y qué fases del reporte fueron ejecutadas o saltadas.

Imagina una plataforma hipotética que sirve un agente para operaciones B2B. Cada sesión reutiliza un system prompt extenso, definiciones de herramientas y contexto recuperado. El equipo quiere aprovechar routing consciente del KV cache para reducir reprocesamiento, pero también necesita que los workers se reprogramen cuando un nodo falla. El piloto declara dos rutas: un frontend propio de Dynamo para un endpoint dedicado y una alternativa futura con Gateway API para ingress compartido. No intenta demostrar de entrada cuál es más rápida; primero fija quién selecciona el worker, quién aplica timeout y retry, y quién conserva el estado que alimenta esa selección.

La receta despliega la base compatible y el reporte confirma sus checks. Después, una prueba de caos acotada drena un nodo, una prueba de routing repite prefijos conocidos y una prueba de observabilidad exige correlacionar solicitud, worker, caché, latencia y error. La aceptación de aplicación usa conversaciones sintéticas y casos de negocio aprobados para medir respuesta correcta, parada segura y costo por tarea aceptada. Si el runtime pasa pero el modelo falla calidad, no se modifica el cluster para esconderlo. Si la calidad pasa pero el scheduler no recupera capacidad, tampoco se promueve. Las dos señales llegan al mismo release gate, pero conservan dueños y diagnósticos separados.

Primero, inventario: captura cloud, versión de Kubernetes, sistema operativo, GPU, topología, storage y red sin completar datos por intuición. Segundo, compatibilidad: resuelve una receta explícita para ese entorno e intención; si no hay match soportado, el resultado es no compatible, no «casi compatible». Tercero, procedencia: verifica binario, charts, imágenes, SBOM, firmas y hashes antes de desplegar. Cuarto, materialización: comprueba que el bundle aplicado corresponde a la receta revisada y que no aparecieron overrides fuera del contrato.

Quinto, conformance: ejecuta checks vivos de GPU, operadores, scheduling, scaling, métricas e ingress y conserva los pasos saltados. Sexto, comportamiento del tráfico: demuestra selección de worker, límites de retry, manejo de timeout, recuperación y señales de caché con cargas representativas. Séptimo, aceptación y rollback: mide SLO, calidad, costo y operación del producto; fija umbrales antes del ensayo y conserva una ruta de reversión que incluya manifests, imágenes y datos compatibles. La promoción ocurre solo cuando las siete evidencias apuntan al mismo artefacto candidato.

Empieza con un cluster o pool aislado que represente la combinación objetivo. Guarda el snapshot y resuelve la receta sin overrides improvisados. Ejecuta primero validación declarativa, revisa los checks omitidos y solo entonces materializa el bundle. La validación viva debe producir un reporte legible por máquina y una vista humana de diferencias. Después instala un único workload de inferencia, no toda la cartera. Verifica arranque, readiness, asignación de GPU, placement, drenado, autoscaling dentro del alcance soportado, métricas e ingress. Cualquier skip queda como riesgo abierto con dueño y fecha, no como pass.

La fase de tráfico usa dos conjuntos. El primero prueba la plataforma con solicitudes deterministas, fallos inducidos y límites conocidos; su pregunta es si el runtime enruta y se recupera según contrato. El segundo prueba el producto con prompts, herramientas y distribuciones representativas; su pregunta es si la tarea se acepta con calidad, latencia y costo suficientes. Registra versión de receta, imágenes, modelo, servidor, configuración de routing, dataset y ventana de observación. Sin esa identidad compuesta, una mejora no puede reproducirse y un rollback puede restaurar solo media plataforma.

Una combinación validada envejece. Un parche de seguridad, cambio de driver, CRD o versión de Kubernetes puede romper compatibilidad, mientras mantener todo fijado puede retener vulnerabilidades. La respuesta no es actualizar a ciegas ni congelar para siempre: genera un nuevo candidato, conserva el anterior y repite los gates afectados. La documentación de Dynamo advierte además que validar con AICR no reemplaza las comprobaciones directas de componentes y que, tras cambiar la versión de plataforma, los runtimes de cada deployment deben mantenerse alineados.

La cobertura también tiene fronteras. Una receta puede soportar un cloud, GPU y sistema operativo concretos pero no la topología exacta de otra empresa. Un attestation puede ser válido y aun corresponder a un cluster diferente. Prometheus disponible no significa alertas útiles; un scheduler saludable no garantiza fairness; routing consciente del caché no garantiza menor costo en tu mezcla de sesiones. Nombra cada inferencia como hipótesis y mídela localmente. La evidencia del proveedor reduce el espacio de duda, pero la aceptación final pertenece al operador.

Adopta una receta validada cuando el costo de integrar y comprobar manualmente el stack supera el valor de personalizar cada capa, y cuando existe cobertura explícita para tu entorno. Conserva una plataforma más pequeña si un servidor de modelo, un scheduler y observabilidad básica satisfacen el workload; agregar componentes solo para parecer enterprise aumenta superficie de fallo. En ambos casos, define el mismo contrato: inventario, compatibilidad, procedencia, materialización, conformance, tráfico y aceptación del producto.

El aporte del flujo publicado el 30 de octubre no es prometer Kubernetes sin incidentes. Es mostrar que un endpoint de inferencia pertenece a una cadena versionada que puede inspeccionarse y volver a probarse. Ese cambio mejora la conversación de compra: en lugar de preguntar «¿corre el modelo?», pregunta «¿qué combinación fue validada, contra qué estado real, con qué checks, qué se omitió y cómo volvemos atrás?». Si necesitas diseñar ese contrato alrededor de un agente o producto específico, el servicio a medida de Wasyra puede convertir el stack, los evals y la operación en un piloto con criterios de aceptación explícitos.