Microsoft abre el código de TauGrid: una capa de IA nativa de Kubernetes para equipos que todavía no se atrevían con Kubernetes gestionado

# Microsoft abre el código de TauGrid: una capa de IA nativa de Kubernetes para equipos que todavía no se atrevían con Kubernetes gestionado

El 16 de septiembre de 2026, Microsoft publicó en su blog de ingeniería de AKS el código abierto de TauGrid, una plataforma pensada para correr cargas de trabajo de IA sobre clústeres de Kubernetes con GPU. La noticia llega en un momento incómodo para muchos equipos de plataforma: la conversación sobre orquestación de IA se ha ido fragmentando entre proveedores cloud — Vertex AI, SageMaker, Azure ML, Bedrock — y opciones self-hosted como Slurm o Run:ai, cada una con su propio modelo mental, su propia facturación y sus propias trampas. TauGrid no reemplaza ninguna de las dos; ocupa un tercer espacio que Microsoft llama explícitamente "infraestructura de IA nativa de la nube para equipos", y que en la práctica significa: dame las ventajas operativas de un servicio gestionado sin entregar mis datos, mis GPUs, ni mis costes recurrentes a un hyperscaler.

Este reportaje analiza qué resuelve TauGrid, qué no resuelve, qué decisiones arquitectónicas tomó Microsoft que vale la pena mirar con detalle, y por qué un equipo de platform engineering debería probarlo antes que cualquier otra opción nueva de orquestación de IA en 2026.

El problema que TauGrid quiere tapar

Kubernetes se convirtió, casi por defecto, en el sistema operativo del entrenamiento y la inferencia de IA en producción. No porque sea perfecto para esa tarea — no lo es — sino porque ya estaba desplegado, ya tenía un ecosistema de operadores maduro, y ya tenía el talento humano para operarlo en equipos que llevan años trabajando con microservicios. El problema es que Kubernetes fue diseñado para servicios sin estado corriendo en CPUs, y la IA moderna exige exactamente lo contrario: estados masivos, GPUs con topologías de red específicas, scheduling por afinidad al hardware y un modelo de colas que Kubernetes no trae por defecto.

Durante los últimos tres años, los equipos han ido parcheando esa brecha con piezas sueltas. Para el scheduling con awareness de topología, Kueue o Volcano. Para el entrenamiento distribuido, KubeRay o el operador de MPI. Para el monitoreo de GPU, el NVIDIA GPU Operator o exporters hechos a mano. Para el tracking de experimentos, MLflow o Weights & Biases corriendo fuera del clúster. Cada pieza resuelve su problema; el problema es la integración. Cada componente necesita su propio deployment, su propia versión, su propia política de upgrades, y su propia página de GitHub Issues donde buscar cuando algo se rompe a las tres de la mañana.

TauGrid es, literalmente, la respuesta de Microsoft a esa fragmentación. En lugar de seguir publicando guías que digan "instala Kueue, después KubeRay, después el GPU Operator, después Prometheus con estos exporters", Microsoft empaqueta todas esas decisiones en un único stack que se instala como un chart de Helm y se opera como una sola unidad. El equipo de plataforma sigue siendo responsable del clúster y de las GPUs; el resto lo trae TauGrid.

Qué hay dentro del stack

El repositorio público en github.com/Azure/taugrid lo deja claro desde el README. TauGrid combina cinco componentes abiertos y los une con una capa de orquestación propia llamada `tau`. Los componentes son:

**Kueue** para la cola y admisión de workloads. Kueue introduce el concepto de `ClusterQueue` y `LocalQueue` que los equipos ya conocen de otros sistemas HPC: los trabajos no se ejecutan cuando se crean, se encolan y se admiten cuando hay recursos. Esto es crítico para entornos multi-tenant donde varios equipos comparten el mismo pool de GPUs y la justicia en la asignación no puede ser "first come, first served".

**KubeRay** para la orquestación de clústeres Ray sobre Kubernetes. Ray se ha convertido, por buenas razones, en el runtime estándar para entrenamiento distribuido y para agentes de IA con estado. KubeRay traduce las primitivas de Ray al mundo de Custom Resources de Kubernetes: cuando un usuario pide un clúster Ray de cuatro nodos con dos A100 cada uno, KubeRay levanta los pods, configura la red entre ellos y los apaga cuando el trabajo termina.

**El NVIDIA GPU Operator** (a través del operador de dispositivos) para la gestión a nivel de nodo del software de GPU — drivers, runtime de container, device plugins, mig manager, DCGM para telemetría. Sin esto, cada nuevo nodo GPU requiere configuración manual que nadie quiere hacer dos veces.

**El `tau` CLI** como interfaz de usuario. Esta es la decisión más interesante. En vez de pedir a los investigadores que escriban YAML de Kubernetes directamente — algo que en muchos equipos genera fricción política entre el equipo de ML y el equipo de plataforma — `tau` expone un subconjunto más pequeño: un archivo `tau.yaml` con `schema_version`, `name`, y un bloque `run` que describe el workload. El equipo de plataforma sigue siendo dueño del clúster y de los límites; el equipo de ML escribe manifests cortos sin tener que aprender qué es un `Pod`, un `Service`, o un `PersistentVolumeClaim`.

**Observabilidad** centralizada para el stack completo. TauGrid incluye configuración pre-armada de Prometheus y Grafana con dashboards específicos para GPU, para colas de Kueue, y para el estado de los clústeres Ray. No es magia; es el mismo Prometheus que cualquier equipo conoce, pero con las queries y los paneles ya pensados.

La decisión arquitectónica que más importa

De todas las elecciones que Microsoft hizo en TauGrid, la que más me parece que merece atención es el uso explícito de Kueue como capa de admisión. Hay otras opciones para scheduling con awareness de hardware en Kubernetes — el propio scheduler de Kubernetes extendido con plugins, Volcano, YuniKorn — pero Kueue tiene una propiedad que encaja particularmente bien con cargas de IA: separa el momento en que un trabajo se envía del momento en que se ejecuta, y permite definir políticas de admisión que combinan cuotas por equipo, prioridades por proyecto, y tiempos máximos de espera.

En la práctica esto significa que un equipo de ML puede enviar un trabajo de fine-tuning a las dos de la tarde, sabiendo que el clúster está lleno entrenando el modelo grande del equipo vecino, y que su trabajo va a arrancar cuando se libere capacidad según las reglas que el equipo de plataforma haya configurado. Sin TauGrid, esa misma operación requiere que alguien en plataforma haya escrito la lógica de admisión a mano, o que el equipo de ML haga polling del scheduler de Kubernetes hasta que aparezca capacidad, o — el caso más común — que el equipo de ML compre sus propias GPUs en otro lado porque la cola del clúster compartido nunca les toca.

Esta separación entre admisión y ejecución es lo que los schedulers de HPC tradicionales como Slurm llevan haciendo treinta años, y es una de las razones por las que muchos equipos con experiencia en HPC se resistían a Kubernetes para IA. TauGrid no reinventa el concepto; lo trae al ecosistema cloud-native con la implementación que los equipos de plataforma ya saben operar.

Lo que TauGrid no resuelve

Conviene leer el README con ojo crítico, porque hay cosas que TauGrid deliberadamente no intenta hacer.

**No es un orquestador de feature stores, lineage, ni governance de modelos.** Eso sigue siendo responsabilidad de Feast, de MLflow, de Unity Catalog, o de las plataformas internas que cada empresa ya tenga. TauGrid se queda en la capa de "mis trabajos corren sobre mis GPUs"; no entra en "mis features están versionadas y mi modelo cumple con la regulación del sector financiero".

**No abstrae el hardware subyacente.** Si tu clúster tiene H100s con NVLink y quieres topology-aware scheduling, TauGrid te ayuda a declarar las afinidades a través de Kueue y KubeRay, pero no te ahorra el trabajo de configurar el network fabric, los MIG slices, ni los drivers. Los equipos con hardware heterogéneo van a seguir teniendo que escribir su propia lógica.

**No incluye entrenamiento federado ni differential privacy por defecto.** Esas son capas adicionales que se montan sobre la infraestructura, no la infraestructura misma. TauGrid puede correrlas, pero no las provee.

**No es un reemplazo de Slurm para HPC tradicional.** Si tu organización ya corre Slurm para simulaciones numéricas y considera moverlo a Kubernetes, TauGrid es una opción razonable, pero la migración es no trivial. Slurm tiene décadas de comportamiento refinado para HPC que el ecosistema cloud-native todavía está replicando pieza por pieza.

**No es, y Microsoft lo dice explícitamente, un competidor directo de Vertex AI o SageMaker.** Esos servicios gestionados ofrecen valor donde el equipo no quiere operar infraestructura; TauGrid ofrece valor donde el equipo sí quiere o necesita operarla. Son productos para clientes distintos.

Casos de uso donde TauGrid brilla

Dicho lo anterior, hay cuatro perfiles de equipo para los que TauGrid encaja particularmente bien.

**Equipos de plataforma en empresas reguladas.** Banca, salud, defensa. Estos equipos a menudo no pueden enviar datos a servicios cloud gestionados por razones de compliance, pero necesitan la productividad operacional que ofrecen. TauGrid les permite montar el equivalente interno de un servicio gestionado de IA sobre su propio hardware, en su propio centro de datos, con las políticas de red y auditoría que su regulación exige.

**Equipos de ML en universidades y centros de investigación.** Las GPUs son caras y los presupuestos son ajustados. Un cluster compartido con admisión justa y visibilidad de uso es exactamente lo que estos equipos necesitan, y construirlo a mano con piezas sueltas es exactamente lo que no tienen tiempo para hacer.

**Empresas con compromiso de soberanía de datos.** Si el contrato con tu cliente final dice que sus datos no pueden salir de una región o un país específico, las opciones de IA gestionada se reducen drásticamente. TauGrid permite desplegar el stack dentro del perímetro que la regulación exige.

**Equipos que ya operan Kubernetes y quieren extenderlo a IA sin añadir otra plataforma.** Para un equipo de plataforma que ya monitorea Prometheus, ya opera con Helm, ya tiene GitOps, TauGrid se siente como una extensión natural en vez de una plataforma nueva que aprender. La barrera de adopción es mucho más baja que para Run:ai, por ejemplo, que requiere cambiar la forma en que el equipo piensa sobre recursos.

Cómo empezar sin romper producción

La recomendación para equipos que estén considerando TauGrid es tratarlo como una capa opcional sobre un clúster Kubernetes que ya sepan operar. El error más común sería intentar adoptarlo como una plataforma monolítica que reemplace todo el stack existente; TauGrid no está diseñado para eso y la experiencia sería frustrante.

El camino razonable es: instalar TauGrid en un clúster de desarrollo o staging, mover uno o dos workloads reales, validar que la cola de Kueue admite y prioriza como se espera, validar que los clústeres Ray se levantan y apagan correctamente, validar que la telemetría de GPU llega a los dashboards pre-armados, y sólo entonces promover a producción. Todo eso se puede hacer en una semana con un equipo de plataforma de tres o cuatro personas que ya conozca Kubernetes.

Hay un punto que Microsoft destaca en su anuncio y que merece atención: TauGrid está pensado para correr sobre AKS, pero la implementación es portable. Si tu clúster vive en EKS, GKE, OpenShift, o k3s en bare-metal, los componentes son los mismos. La documentación de Microsoft asume AKS por defecto, pero el chart de Helm y los Custom Resources no son específicos del proveedor. Esto es deliberado y es, a mi juicio, la mejor señal de madurez arquitectónica del proyecto.

Comparación honesta con la competencia

Run:ai sigue siendo el competidor más directo en el espacio de orquestación de IA self-hosted. La diferencia operativa más importante es que Run:ai es una plataforma comercial con su propio modelo de scheduling propietario, mientras TauGrid es un stack de componentes abiertos. Para equipos cómodos con Kubernetes puro y reacios al lock-in, TauGrid es la opción más atractiva. Para equipos que prefieran una plataforma gestionada con soporte comercial formal, Run:ai sigue teniendo su nicho.

Slurm es la otra alternativa obvia, especialmente para equipos con experiencia en HPC. Slurm tiene décadas de refinamiento en scheduling justo y topology-aware, y sigue siendo el scheduler dominante en los clústeres de las supercomputadoras más grandes del mundo. La desventaja de Slurm es que requiere operar un sistema paralelo a Kubernetes, con su propia base de usuarios, sus propias herramientas, y su propia política de upgrades. Para equipos nuevos en HPC, TauGrid es el camino de menor fricción. Para equipos con Slurm ya desplegado y funcionando, la migración no se justifica.

Las plataformas cloud-nativas gestionadas (Vertex AI, SageMaker, Azure ML) siguen siendo la mejor opción para equipos que no quieren operar infraestructura. TauGrid no compite ahí; compite con la decisión de "compramos GPUs y las operamos nosotros" en lugar de "pagamos por GPUs gestionadas por el cloud". Esa decisión depende de economía unitaria, de requisitos de compliance, y de capacidad operativa del equipo — no de cuál scheduler sea técnicamente superior.

Lo que hay que mirar en los próximos meses

Microsoft ha publicado TauGrid como código abierto bajo la licencia que el repositorio especifica, pero la trayectoria del proyecto depende de tres cosas que todavía no están claras.

La primera es la cadencia de releases. Kueue, KubeRay y el resto de los componentes que TauGrid integra tienen sus propios ciclos de release, a veces descoordinados. Si TauGrid va a ser una plataforma estable a largo plazo, Microsoft necesita publicar una cadencia de versiones propia y mantener compatibilidades testeadas entre componentes. El primer año del proyecto va a ser clave para ver si eso ocurre o si TauGrid se convierte en otro ejemplo de stack open-source que requiere integrar a mano.

La segunda es la adopción fuera de Microsoft. Si en seis meses hay equipos no-Microsoft corriendo TauGrid en producción con contribuciones upstream, el proyecto tiene futuro. Si por el contrario el repo se mantiene como un repositorio de showcase con poca actividad externa, el riesgo de abandono es real.

La tercera es la integración con AI Gateway, con AI governance, y con el resto del ecosistema de Microsoft Fabric. TauGrid aislado es una buena pieza de orquestación; TauGrid como parte del tejido de Azure es algo distinto, y Microsoft todavía no ha detallado la dirección. Estaremos mirando.

Conclusión operativa

TauGrid no es una bala de plata y Microsoft no pretende que lo sea. Es un intento serio y, hasta ahora, bien ejecutado, de reducir la fricción operativa de correr IA sobre Kubernetes. Para los equipos que ya operan Kubernetes y quieren extender su inversión existente a cargas de IA sin añadir una plataforma paralela, TauGrid merece una prueba en serio. Para los equipos que ya adoptaron Run:ai o Slurm, la migración es opcional y debe justificarse caso por caso. Para los equipos que están evaluando por primera vez cómo correr IA en producción, TauGrid es una de las mejores opciones self-hosted disponibles en 2026 — siempre que el equipo esté dispuesto a operar Kubernetes de verdad, con todo lo que eso implica.