Kubeflow vs. Union AI
KFP v2 is a popular pipeline-orchestration subsystem that brings Kubernetes-native support, typed artifacts, ML Metadata, and caching. Union AI is a broad, durable runtime for AI that enhances pipelines with reusable containers, cold-boot optimizations, managed image building, distributed compute, apps, and inference. Here’s a capability-by-capability look for the platform and DevOps teams that own the cluster.
About Kubeflow KFP
Kubeflow is a CNCF Graduated (as of August 2026), genuinely open ML toolkit with a large community and no vendor in the loop. Its core is Kubeflow Pipelines (KFP v2), a capable orchestrator with typed artifacts, ML Metadata lineage, and default caching built in. Around it sit independently-governed subprojects (KServe, Katib, Trainer, Notebooks, Spark Operator, Model Registry), each on its own release cycle.
KFP can be deployed on its own; the full distribution adds Istio, Knative, cert-manager, Dex, OAuth2-proxy, and Argo. Either way the platform team owns the integration, the upgrades, and the on-call for whatever it assembles.
About Union AI
Union (built on Flyte 2) is a single AI runtime: one Python SDK, one control plane. It orchestrates, places compute, recovers from logic and infrastructure failures, and serves batch and real-time inference in the same program, in your own cloud.
The team operates one integrated product rather than composing several, with enterprise plumbing (SSO, fine-grained RBAC, zero-trust, and support for regulated environments) built in. Flyte 2 is open source (Apache-2.0), and the identical code runs on it, so there is no rewrite to leave.
Scope noteThis compares Union's integrated runtime with the equivalent capabilities of a composable Kubernetes ML platform centered on KFP v2. KFP v2 natively provides compiled pipeline orchestration, typed artifacts, ML Metadata lineage, and execution caching. Capabilities shown as built into Union can often be delivered on Kubernetes through adjacent Kubeflow projects, operators, or cloud services, with availability, operational ownership, and developer experience varying by deployment.
| Capability | Union AI (Flyte 2) | Kubeflow (KFP v2 + composable stack) | Why it matters to the platform team |
|---|---|---|---|
| Operating model & coordination | |||
| Shape of the product | One runtime, one SDK, global control plane. BYOC, Self-Managed, Self-Hosted/Airgapped | KFP v2 orchestrator, plus adjacent subprojects on their own release cycles. Self-Hosted/Airgapped | Union edgeThe distinction is an integrated runtime vs. a composable platform architecture: one on-call rotation and upgrade path, versus integrating and operating the pieces you assemble. |
| Install & dependencies | Deploys into your cluster; no forced Istio / Dex / Knative | KFP deployable standalone; the full distribution adds Istio, Dex, Argo (Knative only if KServe uses it) | Union edgeUnion deploys alongside infrastructure you already run. A community operator has observed that the full Kubeflow distribution "virtually necessitates its own dedicated cluster." Standalone KFP is lighter. |
| Upgrades & maintenance | Single versioned platform; managed upgrade path | Coordinate versions across the components you run | Union edgeEvery component you add is another release cycle to track. Maintenance hours are the cost a license-only comparison misses. |
| Local → prod parity | Author and run pure Python locally, track local runs remotely, run remotely in your cloud, no Docker required. Union & open-source Flyte 2 are identical |
KFP v2 runs pipelines locally DockerRunner / SubprocessRunner; prod services aren't reproduced locally |
EvenBoth support local iteration; the difference is the development-to-production path. With Union, local operates without Docker, in your pure Python runtime. Union also supports Tracked Runs, where you track local runs in the control plane and see them in the UI. |
| Compute-backend breadth & scale | |||
| Multi-cloud / multi-silicon | Runs on any cloud, including Nebius, Crusoe. NVIDIA, Google TPU and other accelerators | Runs on any Kubernetes, but the multi-cloud / multi-silicon integration is platform-selected | Union edgeWhen accelerator capacity is scarce, running where the capacity is matters; on Kubeflow that integration is the platform team's to build and own. |
| Multi-cluster runs | Submit once and the control plane routes the run based on User metadata across clusters and queues automatically; clusters group into cluster pools | +A KFP deployment targets the cluster it runs in; spanning clusters means one deployment per cluster plus a federation or routing layer you add | Union edgeGPU capacity is rarely all in one place. Union treats many clusters as one pool of compute, so a run lands where there is room without the author naming a cluster or the platform team building a scheduler across them. |
| Scale ceiling | Published ceilings: 1M fanout, 1M concurrent actions, ~1k/s submission, 300k+ actions/run | Kubernetes / etcd limits appear under extreme fanout; mitigated by sharding across clusters | Union edgeHigh-fanout evaluation and batch inference eventually meet Kubernetes control-plane limits. Union publishes tested headroom (figures and conditions in the notes below); your ceiling depends on cluster sizing. |
| Image build / CI-CD | Remote image builder builds using User inputs, no Docker / CI boilerplate; prebuilt / BYO (CI/CD) images still supported | +Platform-selected build path: BuildKit / Kaniko / cloud build + registry and supply-chain policy | Union edgeImage build is a common source of "pipeline is broken" tickets. A built-in builder removes CI/CD glue the team would otherwise choose and operate, while leaving BYO images available. |
| GPU & token optimization | |||
| GPU idle time | Reusable Containers remove container stop/start between steps. Both bath and non-batch pipelines | +Pod per task in KFP orchestration; warm reuse comes from the serving layer (KServe, Ray Serve, Triton) | Union edge4.1× faster on a GPU pipeline in Union's reuse benchmark (406s with Reusable vs 1,665s without Reusable). |
| GPU effective utilization | DynamicBatcher / TokenBatcher auto-batch by cost or token count | +No batcher in KFP core; batching via the serving layer you select (KServe, Ray Serve, vLLM, Triton) | Union edge3.3× peak decode throughput in Union's benchmark; batching keeps accelerators saturated without hand-rolled backpressure. |
| Token throughput & data streaming | Batch by tokens; JsonlDir streams datasets from object storage | +Token batching and data sharding via the serving / runtime layer you select | Union edgeMaximize tokens per GPU-second and run 100M+ LLM calls from a simple Python loop, with no custom sharding. |
| Cost of reruns | Caching + checkpointing + infra-aware retry, so an OOM retries with more memory | Task-level caching (on by default) + retries; a lost node restarts the work | Union edgeBoth cache. The difference is checkpointing and infra-aware recovery: a failure costs one step, not the whole GPU run from zero. |
| Authoring & durability | |||
| Authoring model | Pure Python; dynamic branching, loops, recursion at runtime | KFP SDK compiles a DAG before it runs | Union edgeNative support for dynamic brnaching-- RL, agents, and data-driven fan-out decide their shape at runtime. A pre-compiled DAG expresses this only with added glue and escape hatches. |
| Durability / self-heal | Recovers from logic and infra faults; an OOM retries with more memory | Infra-aware recovery isn't built in (e.g. OOM → more memory = failure) | Union edgeUnion recovers from infrastructure faults, not just logic. An OOM becomes a retry with more memory rather than a failed overnight run. |
| Inference / serving | Batch + real-time native, in the same program as training | +Mature serving via KServe (a separate component to wire and operate) | Union edgeTrain, evaluate, and serve from one codebase and one lineage. KServe is capable, but it's a separate serving stack to stand up and keep in sync with the pipeline that produced the model. |
| Debug experience | Launch VSCode Remote or SSH to debug to a live task in your pipeline | Reproduce locally / inspect pod logs | Union edgeAttaching to a live task shortens MTTR on distributed jobs versus reproducing locally or chasing pod logs. |
| Governance, lineage & cost | |||
| Data lineage & reproducibility | Typed artifacts, caching, checkpointing, versioned data, plus cross-workflow discovery via Artifact Hub | +KFP v2 has typed artifacts + ML Metadata lineage built in; broader cross-workflow discovery adds a registry / catalog | EvenBoth track typed artifacts and lineage. The difference is reusable artifact discovery across workflows, not artifacts vs. none. |
| Experiment tracking | +Integrates external trackers: Weights & Biases, MLflow | +Integrates external trackers: MLflow, or Katib for sweep metrics | EvenNeither ships a full experiment-tracking UI; both wire in W&B or MLflow. A wash. Use whichever tracker your team already runs. |
| Enterprise plumbing | Fine-grained RBAC, custom SSO, zero-trust; built for regulated (SOC 2 / HIPAA) environments | +Dex / OAuth2-proxy; RBAC wired per component | Union edgeSecurity review is where deals stall. Union clears it as one product rather than a per-component assembly to secure and defend. |
| Cost & usage visibility | Per-project / domain cost & utilization; hierarchical resource defaults | +Assemble from Prometheus / Grafana yourself | Union edgeLeaders ask "what are we spending, and is it used?" Union answers it natively instead of as a separate dashboards project. |
| Cost of ownership | Commercial platform; the operate-and-maintain work is absorbed | No license cost, paid instead in operate-and-maintain time | Kubeflow edgeOpen source has no license cost but is paid in platform-engineering time to assemble and run. The honest comparison is total cost of ownership, not license cost. |
| Shared Resources, Multi-Cluster & Multi-Cloud | Union natively supports multi-cloud and multi-cluster, providing users a single entry point with transparent routing and queues. Queues govern quotas, run parallelism, and ensure teams can collaborate and work together while competing over shared resources | Kubeflow requires Kueue MultiKueue, which uses a manager cluster to select a worker cluster and mirrors the job there for actual execution. | Union edgeAlthough Kubeflow can achieve multi-cluster, Platform teams must implement additional tooling and expand the failure zone. Union provides seemless, zero-ops routing and multi-cluster by default. |
| Openness, community & ecosystem | |||
| Openness & licensing | Flyte 2 is 100% open source under Apache-2.0. Union AI is a managed commercial platform. | Fully open under CNCF governance; no commercial license anywhere in the stack | Kubeflow edgeIf a purely open, no-vendor stack is a hard requirement, Kubeflow is open end-to-end. Union runs open-source Flyte 2 as its core, but the managed product is commercial. |
| Community & talent | 7.2K GitHub stars on flyteorg/flyte, where essentially the whole community sits |
4.2K on kubeflow/pipelines; the rest is spread across separately-starred subprojects (kubeflow/kubeflow 15.8K, KServe 5.8K, Spark Operator 3.1K) |
EvenOn the orchestrators themselves Flyte draws more interest than KFP (7.2K vs 4.2K stars). Kubeflow's total reach is wider, but it is split across subprojects you adopt separately, which is the same trade-off as the rest of this page. Its CNCF graduation (Aug 2026) is a real signal of maturity and staying power. |
| Component choice / breadth | Opinionated, integrated set with fewer knobs by design | Swap components to taste: Katib / Optuna, KServe / Seldon, Spark Operator / KubeRay | Kubeflow edgeTeams that want to pick best-of-breed per layer and avoid a single opinionated stack get more freedom on Kubeflow, at the cost of integrating and owning the choices. |
Scale figures (1M fanout / concurrent, ~1k/s submission, 300k+ actions per run, <100ms warm start) are Union's published external ceilings: tested headroom, not a guarantee for any given cluster sizing. Throughput and call-volume figures are from Union's public reuse benchmark and feature docs (conditions cited under the section below). KFP v2 capabilities (typed artifacts, ML Metadata lineage, default caching, local runners) per kubeflow.org. Kubeflow is a CNCF Graduated project (graduated August 2026). GitHub star counts are per-repository from the GitHub API on 22 August 2026, comparing the two orchestrators on the same basis: flyteorg/flyte 7,226 vs kubeflow/pipelines 4,192. Kubeflow is starred per subproject (kubeflow/kubeflow 15,826, kserve/kserve 5,817, kubeflow/spark-operator 3,148, and a long tail), so any org-wide total depends on which repositories and orgs are counted; we cite individual repositories rather than an aggregate.
GPU efficiency & velocity
The most expensive thing in the cluster is an idle GPU
Most AI spend is GPU time, and much of it leaks between and inside runs: cold starts, half-full batches, and expensive work re-run from scratch after a failure. Union pulls these levers as platform features, not per-team scripts.
GPU idle time
Keep replicas live across actions instead of starting a new pod per task, so GPUs stop paying a cold-start penalty between runs. Warm start under 100ms, and 4.1× faster wall-clock on the same GPU in Union's reuse benchmark (404s vs 1,665s).
Kubeflow: a new pod / container per task, so a cold start on every action.
GPU effective utilization
Auto-batch requests by cost or token count to keep the accelerator saturated, instead of hand-writing batching and backpressure logic that leaves GPUs half-idle.
Kubeflow: no native batcher, so saturation is a per-team concern.
Token use & throughput
Batch by tokens to maximize tokens processed per GPU-second, and stream datasets straight from object storage, running 100M+ LLM calls from a simple Python loop with no custom sharding code.
Kubeflow: bring your own batching and data-sharding logic.
The cost of reruns
Unchanged steps reuse cached results, long runs resume from a checkpoint on spot reclaim, and an OOM retries with more memory, so a failure costs one step, not the whole GPU run from zero.
Kubeflow: step-level retries only; a lost node restarts the work.
Reuse figures: Qwen2.5-7B under vLLM on one NVIDIA L4; Reusable Containers vs a fresh pod per call. Union public benchmark ↗. Warm-start figures are Union's published external ceilings; JsonlDir call volume per Union feature docs.
FAQ
Common questions about Kubeflow & Union AI
What is the difference between Kubeflow and Union AI?
At its core Kubeflow is Kubeflow Pipelines (KFP v2), a capable orchestrator (part of a CNCF Graduated project as of August 2026) with typed artifacts, ML Metadata lineage, and caching built in, surrounded by independently-governed projects (KServe, Katib, Trainer, Model Registry, and more) that a platform team composes on Kubernetes. Union AI, built on the open-source Flyte 2 runtime, is a broader durable runtime with one Python SDK and one control plane in your own cloud, adding managed image building, distributed compute, apps, and inference. The practical difference is an integrated runtime versus a composable platform you assemble and own.
Is Kubeflow Pipelines (KFP) hard to operate?
KFP is a capable orchestrator and can be deployed on its own. The operating cost grows with the full Kubeflow distribution, which also pulls in Istio, Dex, and Argo (plus Knative if KServe is configured for it). One community operator observed that this setup "virtually necessitates its own dedicated cluster." Whichever you run, each upgrade coordinates changes across separately-released components, so the ongoing cost is platform-engineering time rather than a license fee.
Can Kubeflow Pipelines run dynamic or agentic workflows?
KFP compiles a static DAG before execution, so the shape of the work must be known up front. Adaptive patterns such as reinforcement-learning loops and agents, which decide their next step at runtime, need an external controller or a recompile each round. On Flyte 2 the same logic is ordinary async Python inside a task.
What are the alternatives to Kubeflow for ML orchestration?
Common alternatives include Union AI / Flyte, Airflow, Prefect, Dagster, Argo Workflows, and managed platforms such as Amazon SageMaker and Google Vertex AI. For GPU-heavy training and inference, teams typically evaluate on compute-backend breadth, durability under infrastructure failure, and GPU-utilization features such as reusable containers and dynamic batching.
Is Flyte open source, and does Union AI lock you in?
Flyte 2 is open source under Apache-2.0 and is a graduated project of the LF AI & Data Foundation. Union runs the identical code in your own cloud (BYOC), so there is no rewrite required to adopt it, or to leave.
Like for like
Required Kubeflow & other open-source tools
Union's surface arrives as one product. To reach the same surface on Kubernetes, a team assembles the components below, then owns the integration, the upgrade order, and the on-call for each. This is the honest shape of the trade-off: not that Kubernetes cannot do the work, but that someone has to select, wire, secure, and keep these pieces in step.
Orchestration & execution2 tools
Union: one runtime, one SDK, one control plane.
- Kubeflow Pipelines (KFP v2)compiled pipeline DAGs, typed artifacts, caching
- Argo Workflowsthe workflow engine KFP v2 executes on
Distributed compute4 tools
Union: Spark and Ray orchestrated from the runtime; resources set per task.
- Kubeflow Trainerdistributed PyTorch / TensorFlow / XGBoost training
- MPI OperatorMPI-style multi-node jobs
- Spark OperatorSpark job and cluster lifecycle
- KubeRayRay cluster lifecycle
Tuning & search1 tool
Union: sweeps as ordinary runtime Python; Hydra plus Optuna integration.
Serving & inference3 tools
Union: batch and real-time inference native, in the same program as training.
Artifacts, lineage & registry3 tools
Union: typed artifacts, caching and Artifact Hub built in; trackers integrate.
- ML Metadata (MLMD)execution and artifact lineage, built into KFP v2
- Kubeflow Model Registrymodel versioning and promotion
- MLflow or Weights & Biasesexperiment tracking (external on both sides)
Developer experience3 tools
Union: Pure Python, local TUI, local DevBox, track local runs remotely. Plus a managed image builder from the SDK.
- Kubeflow Notebookshosted development environments
- BuildKit, Kaniko or cloud buildcontainer image build inside the cluster
- Registry plus CI/CDpublish images and deploy pipeline definitions
Identity, networking & security5 tools
Union: SSO, fine-grained RBAC and zero-trust in the product.
- Istioingress, service mesh, mTLS between components
- DexOIDC identity provider
- OAuth2-proxyauthenticating gateway in front of the UIs
- cert-managerTLS certificate lifecycle
- Vault or a cloud KMSsecret storage and rotation
Observability & cost3 tools
Union: per-project and per-domain cost and utilization reporting native.
- Prometheusmetrics collection
- Grafanadashboards
- OpenCost or KubecostGPU and workload cost attribution
Read this fairly. Few teams need every layer: scope it to the workloads you actually run, and a pipelines-only deployment needs a fraction of this. Several entries (Prometheus, Grafana, cert-manager, Istio, a registry, CI/CD) are general Kubernetes platform tooling many teams already operate, so they are not Kubeflow-specific overhead. Knative applies only if KServe runs in Serverless mode, and where alternatives are listed you pick one rather than all. Union is not zero on every row either: experiment tracking is an external integration on both sides. The point is not the count, it is who owns the integration and the upgrade path.