Kubeflow a fondo: qué piezas valen la pena en una plataforma LLM on-premise y cuáles ya tienes

· Por José Manuel Román

Segundo artículo de la tanda de plataforma y autoservicio, después de Backstage y antes de Knative. Aquí la pregunta no es qué es Kubeflow, sino qué partes de Kubeflow siguen teniendo sentido cuando ya has montado media plataforma por tu cuenta.

TL;DR

Kubeflow graduó en la CNCF el 17 de agosto de 2026, y esa noticia esconde la importante: ya no es una plataforma monolítica, es un paraguas de subproyectos independientes, cada uno con su repositorio, su versión y su vida propia. Eso cambia por completo cómo hay que evaluarlo. La pregunta de 2020, ¿instalo Kubeflow?, se ha convertido en la de 2026, ¿qué pieza de Kubeflow instalo, y a costa de qué?

Para una plataforma que ya tiene RKE2, vLLM, KServe, Flux y Volcano o Kueue, la respuesta honesta es que Kubeflow entero duplica casi todo lo que ya tienes. KServe ya no vive bajo Kubeflow: se fue, y desde noviembre de 2025 es proyecto CNCF por su cuenta, así que quien sirve modelos con KServe no necesita Kubeflow para servir. El Trainer se apoya en Volcano y Kueue, no los reemplaza. Y el manifiesto completo arrastra Istio, Dex y cert-manager como dependencias duras que chocan con lo que ya operas. Lo único que puede valer la pena instalar suelto es Pipelines, como orquestador de flujos de datos y entrenamiento, y quizá el Trainer por sus plantillas de fine-tuning. El resto, o ya lo tienes, o no lo necesitas.

La analogía: el hipermercado y la tienda especializada

Kubeflow nació como un hipermercado: un solo edificio con todo lo que un equipo de ML podía necesitar, desde los cuadernos hasta el servidor de inferencia, pasando por los pipelines y el ajuste de hiperparámetros. Tenía sentido en 2019, cuando montar cada pieza por separado era un proyecto en sí mismo y no había estándares.

En 2026 el hipermercado se ha reconvertido en una calle de tiendas especializadas. La sección de carnicería, KServe, se independizó, abrió su propio local y le va mejor sola. La de pescadería, el Trainer, ahora depende del mercado central de al lado, Volcano y Kueue, en vez de tener su propia cámara. Y el edificio común sigue exigiendo que pongas su instalación eléctrica, su fontanería y su sistema de seguridad (Istio, cert-manager, Dex) aunque tú ya tengas los tuyos.

Quien llega hoy con la nevera medio llena, que es el caso de cualquiera con una plataforma en marcha, no necesita el hipermercado entero. Necesita saber a qué tienda entrar por lo que le falta, y evitar comprar dos veces lo que ya tiene en casa.

Qué es Kubeflow en 2026

Kubeflow lo creó Google en 2017 y graduó en la CNCF el 17 de agosto de 2026, alcanzando el nivel máximo junto a Kubernetes o Prometheus. Las cifras de la graduación son serias: más de 6.600 contribuidores de más de mil organizaciones, y adoptantes como Bloomberg, NVIDIA, Red Hat o Spotify.

El cambio estructural es el que importa para decidir. La distribución completa, la Kubeflow Community Distribution, se numera por año y mes (la vigente es la 26.03, de marzo de 2026, con cadencia semestral), pero cada componente es ya un subproyecto con su propio repositorio y su propio ciclo, usable de forma independiente. La distribución solo los empaqueta. Eso significa que “instalar Kubeflow” ya no es una decisión atómica: es una lista de la compra.

Componente a componente

Kubeflow Pipelines: la pieza que quizá sí quieras

Pipelines orquesta flujos de trabajo de ML en contenedores. Se escriben en Python con su SDK, que compila a una representación intermedia en YAML para que sean portables, y por debajo se ejecutan sobre Argo Workflows. Es la pieza con más posibilidades de aportar valor a una plataforma existente: un flujo de “ingesta, embeddings, fine-tuning, evaluación, despliegue” es exactamente lo que hace falta para operar RAG y adapters de forma repetible.

La letra pequeña tiene dos partes. La primera, que si ya usas Argo Workflows a pelo, Pipelines añade una capa de SDK, interfaz y metadatos sobre el mismo motor: no trae un planificador nuevo, trae el modelo de componentes tipados y la interfaz de ejecuciones. La segunda, que su sistema de metadatos y linaje, MLMD, está en proceso de eliminación del propio Pipelines, así que no conviene construir la trazabilidad de la plataforma sobre esa pieza concreta.

Kubeflow Trainer: se apoya en tu planificador, no lo sustituye

El antiguo Training Operator, el de PyTorchJob y TFJob, se ha reescrito como Kubeflow Trainer, con una única API TrainJob que unifica todos los frameworks. La versión 2.2 se posiciona explícitamente para entrenamiento distribuido y fine-tuning de LLM, con soporte de PyTorch, DeepSpeed, HuggingFace y compañía.

Aquí hay que corregir una expectativa común. El Trainer no reemplaza a Volcano ni a Kueue: se apoya en ellos. El TrainJob lleva un campo podGroupPolicy que crea automáticamente los PodGroup de Volcano para el gang scheduling, y se integra con las colas de Kueue. Si ya montaste ese planificador, como vimos en su artículo, el Trainer añade la abstracción TrainJob y unas plantillas de fine-tuning por encima de lo que ya tienes, no una capa de planificación nueva. Puede valer la pena por las plantillas; no por el planificador.

Katib: relevante solo a medias

Katib hace AutoML nativo de Kubernetes: optimización de hiperparámetros con algoritmos como optimización bayesiana, TPE o Hyperband, más búsqueda de arquitecturas. En la era de los LLM se ha reposicionado, con documentación oficial para ajustar hiperparámetros de fine-tuning y hasta para afinar pipelines de RAG.

La lectura práctica es tibia. La búsqueda de arquitecturas es irrelevante para quien hace LoRA y RAG. La optimización de hiperparámetros sí puede servir para barridos de tasa de aprendizaje o de rango de LoRA, pero compite con hacerlo desde el propio SDK del runbook de QLoRA o con Ray Tune, y rara vez justifica arrastrar Katib solo por eso.

KServe: la pieza que ya no está en Kubeflow

Este es el dato que decide media evaluación. KServe se fue de Kubeflow. Nació dentro del proyecto en 2019, se donó a la Linux Foundation en 2022, se renombró de KFServing a KServe y graduó de Kubeflow ese mismo año, y desde noviembre de 2025 es proyecto incubado de la CNCF por su cuenta. En la taxonomía de 2026 aparece como proyecto del ecosistema, externo, no como componente del núcleo.

La consecuencia es directa: quien ya sirve con KServe no necesita Kubeflow para servir. Y KServe es justo donde está la acción de LLM: su versión 0.15 reforzó el backend de vLLM e introdujo un recurso LLMInferenceService con serving desagregado, caché de prefijos, autoescalado por variante y APIs compatibles con OpenAI. Si tu capa de serving es vLLM sobre KServe, esa capa ya la tienes completa y Kubeflow no le añade nada.

Model Registry, Notebooks y el resto

El Model Registry, reorganizado ahora bajo el nombre de Kubeflow Hub, es un índice de modelos, versiones y metadatos. Guarda punteros y estados, no los bytes. Frente a MLflow, le falta el seguimiento de experimentos y métricas que es el fuerte de MLflow, hasta el punto de que las guías recomiendan combinarlos en vez de sustituir uno por otro; y frente a un registro OCI, no empaqueta el binario, que sigue viviendo donde lo pusiste. Es un componente todavía joven, por debajo de la versión 1.0.

Los Notebooks conviven en dos versiones, la 1 estable y una 2 rediseñada sobre CRDs que sigue en alfa. El Spark Operator continúa en el núcleo; Feast, en cambio, ha salido del núcleo y hoy es proyecto del ecosistema, un matiz que hay que tener claro antes de contar con él.

El multi-tenancy: potente y atado a Istio

El aislamiento entre equipos se hace con Profiles, un CRD que envuelve un namespace y le pone RoleBindings, ServiceAccounts y políticas de autorización de Istio que validan una cabecera de identidad derivada de OIDC. Es un modelo completo, pero tiene un talón de Aquiles: depende por entero del sidecar de Istio y de esa cabecera. Si el tráfico esquiva la malla o alguien falsifica la cabecera, el aislamiento se rompe, y toda la seguridad multi-tenant queda acoplada a Istio, lo que choca de frente si ya operas otra malla o ningún service mesh.

El coste de instalarlo entero

Aquí está la razón principal para no instalar la distribución completa sobre una plataforma existente. El manifiesto de la versión 26.03 arrastra como dependencias duras: Istio, cert-manager, Dex para OIDC, OAuth2-Proxy, y Knative Serving y Eventing para KServe. Recomienda 16 GB de RAM y 8 vCPU como mínimo, y el agregado de todos los componentes ronda los 4,4 núcleos de CPU y 12 GB de memoria solo para el plano de control.

El propio proyecto reconoce el problema. Hay un hilo abierto en su repositorio, titulado sin rodeos “opiniones de la comunidad sobre la complejidad de Kubeflow”, donde se admite que Kubeflow prácticamente obliga a un cluster dedicado por las suposiciones que hace sobre qué hay instalado, que Istio y Dex deberían ser intercambiables y no dependencias fijas, y que se echa en falta un Helm más ligero que instale solo lo necesario. Para quien ya opera cert-manager, un ingress y GitOps con Flux, el manifiesto completo no convive: duplica y pisa la infraestructura base.

Kubeflow frente a las alternativas

El campo es amplio y casi toda la literatura comparativa la escriben proveedores con producto propio, así que hay que leerla con pinzas. Con esa cautela:

Argo Workflows a pelo es el motor que Pipelines usa por debajo; si solo necesitas grafos de contenedores, Pipelines es sobrecarga. MLflow es fuerte en seguimiento de experimentos y registro ligero, se instala en minutos, y no orquesta entrenamiento distribuido: es complementario, y de hecho lo usamos en el artículo de versionado de prompts. Flyte es un orquestador tipado que muchos perciben como más ligero de operar que Kubeflow completo. Y Ray sobre Kubernetes es el competidor más serio para cargas de LLM, porque con una sola runtime cubre entrenamiento, servicio y ajuste, solapando a la vez con el Trainer, Katib y KServe.

Donde Kubeflow gana es en amplitud y en gobernanza: un paraguas graduado por la CNCF con adopción de grandes empresas. Donde pierde es en peso operativo, en dependencias duras, y en que sus mejores piezas ya son proyectos independientes que no requieren el resto.

Encaje real con cargas de LLM

El proyecto se ha movido hacia GenAI, y hay que reconocerlo: hay un SDK con plantillas de fine-tuning de LLM, el Trainer añade soporte de métodos de post-entrenamiento por refuerzo, y han aparecido piezas nuevas orientadas a agentes. No es marketing vacío, hay trabajo real.

Pero la pregunta para una plataforma concreta no es si Kubeflow hace LLM: es qué parte no dupliqué ya. Sobre un stack de RKE2, vLLM, KServe, Flux y Volcano o Kueue, el balance queda así:

Componente¿Aporta algo nuevo a tu stack?
KServeNo: ya lo tienes, y ya no es de Kubeflow
TrainerSolo las plantillas de fine-tuning; el planificador ya lo tienes
KatibMarginal: barridos de HP de LoRA, poco más
PipelinesPuede que sí, como orquestador de flujos, pero corre sobre Argo
Model RegistryOpcional: compite con MLflow y con tu registro OCI
NotebooksSegún lo que uses hoy para cuadernos
Multi-tenancyNo, si ya aíslas por namespace sin atar todo a Istio

Trampas operativas y escepticismo honesto

No instales el manifiesto completo sobre una plataforma que ya funciona. Vas a duplicar Istio, cert-manager y el resto, y a librar una guerra de dependencias que no tiene premio. Si algo de Kubeflow te interesa, instálalo como subproyecto suelto.

KServe no es Kubeflow. Es el error de categoría más común de 2026. Si alguien justifica montar Kubeflow entero “para servir modelos”, ya sabes que no ha mirado que KServe se fue hace tiempo y vive solo.

El Trainer no te ahorra el planificador. Necesita Volcano o Kueue por debajo. Si esperabas que resolviera el gang scheduling de las GPU por sí mismo, no lo hace.

El multi-tenancy te ata a Istio. Antes de adoptar Profiles, pregúntate si quieres que la seguridad entre equipos dependa de una malla concreta. Si ya aíslas bien por namespace y RBAC, quizá no necesites esa capa.

MLMD está de salida. No construyas la trazabilidad de tus pipelines sobre el sistema de metadatos que el propio proyecto está retirando.

Para una factoría de inferencia

La conclusión es cómoda de aplicar. Kubeflow en 2026 no es una decisión de sí o no, es un menú del que se pide a la carta. Sobre una plataforma que ya sirve con KServe, planifica con Volcano y despliega con Flux, la carta se reduce mucho.

Si necesitas orquestar flujos de datos y entrenamiento de forma repetible, y no quieres montar Argo Workflows a pelo con su ergonomía, Pipelines es la pieza que vale la pena evaluar, instalada suelta. Si haces fine-tuning distribuido con frecuencia y quieres una abstracción uniforme por encima de tu planificador, el Trainer puede ahorrarte plantillas, sabiendo que se apoya en el Volcano que ya tienes. Todo lo demás, o lo tienes, o lo cubre mejor una pieza especializada.

El error caro sería instalar el hipermercado entero para comprar el pan. Kubeflow dejó de ser eso; trátalo como lo que es, una calle de tiendas, y entra solo en la que te falta. La siguiente pieza de esta tanda, Knative, es justamente una de esas tiendas especializadas, la que decide si apagar la GPU cuando nadie la usa sale a cuenta o te cuesta caro.

Ver también

Fuentes