MLOps Tools · Cluster 3 hub
MLOps Tools and Platforms: Build the Right Production Stack
The systems around a model are not a shopping list. Each tool should own one production responsibility and expose a clean handoff to the next stage. This hub maps the lifecycle to tool categories, compares five stack archetypes, and frames the build-versus-buy decision so ownership and failure boundaries stay explicit.
Direct answer
MLOps tools are the systems that own a specific production responsibility — versioning, experiment tracking, orchestration, serving, or monitoring — and expose a clean handoff to the next stage. The right stack is not the longest list of popular tools; it is the smallest set that makes ownership and failure boundaries explicit, survives an upgrade, and can roll a model back when monitoring signals degrade.
What MLOps tools need to own
An MLOps tool is not a feature checklist. It is a system that owns a single production responsibility end to end: the data it stores, the failures it contains, and the handoff it exposes to the next stage. When a tool owns a responsibility, it is the source of truth for that concern and the first place an engineer looks when something breaks.
Ownership has three parts. The tool is the system of record for its artefacts, it defines the failure boundary so an incident in one stage does not cascade into every other stage, and it produces a typed handoff — a version pointer, a registered model alias, a container digest, a metrics export — that the next tool can consume without human glue code.
- Versioning owns dataset and code identity, not training execution.
- Tracking owns experiment metadata and model lineage, not pipeline scheduling.
- Orchestration owns the DAG, retries and step state, not the model artefact itself.
- Serving owns request handling, batching and scaling, not model quality.
- Monitoring owns drift and performance signals, not remediation decisions.
Tool, framework and platform: the practical difference
A library or framework is code you call inside your process. A tool is a system you operate with its own storage, API and failure modes. A platform is a product that bundles multiple tools behind one control plane, often with a managed offering and a billing relationship.
The distinction matters for ownership. Calling Ray Train is a framework decision inside a pipeline step. Running MLflow is a tool decision with a database and artefact store to back up. Adopting a managed MLOps platform is a platform decision that offloads upgrades and backup to a vendor but locks in a data model and a cost curve. Cluster 3 evaluates tools and platforms; frameworks are covered where they change a tool's boundary.
MLOps lifecycle and tool-category map
Each lifecycle stage maps to one tool category that owns it and a handoff that the next category consumes.
| Category | Owning tool | Responsibility | Handoff |
|---|---|---|---|
| Data versioning | DVC or object-store versioning | Pin the exact dataset version tied to a code commit so training is reproducible. | Versioned dataset pointer passed into the training step. |
| Experiment tracking | MLflow, W&B, ClearML | Record runs, parameters, metrics and artefacts; own model lineage. | Registered model version or alias consumed by deployment. |
| Pipeline orchestration | Kubeflow Pipelines, Airflow, Dagster, Prefect | Schedule, retry and track pipeline steps; own DAG state and artefact lineage. | Step outputs as artefacts in a pipeline root. |
| Model serving | KServe, Ray Serve, Triton, BentoML | Load the artefact, handle requests, batch, autoscale and manage traffic. | Predictions and telemetry exported to monitoring. |
| Model monitoring | Evidently, Arize, WhyLabs, Fiddler | Detect data-quality issues, feature drift, prediction drift and performance degradation. | Drift and performance signals that trigger retraining or rollback. |
| Retraining and rollback | CI/CD/CT gates + registry aliases | Decide whether to retrain or roll back based on monitoring signals. | New model version or restored alias fed back to serving. |
The smallest stack that can work
The smallest production stack covers five responsibilities with five owners: a data version layer, an experiment tracker, an orchestrator, a serving runtime and a monitor. Fewer than five means one tool is silently owning two responsibilities, which is where handoffs break and incidents cascade.
A minimal stack might use DVC for data, MLflow for tracking and registry, a single orchestrator (Kubeflow Pipelines, Airflow, Dagster or Prefect), Ray Serve or a containerised FastAPI process for serving, and Evidently for drift. Every component is replaceable because each owns exactly one boundary and exposes a typed handoff.
MLOps stack archetypes compared
Five recurring archetypes, ordered from least to most operational burden. Each states who should choose it, what it owns, and why not to choose it.
Minimal self-hosted stack
- Team condition
- One or two ML engineers, a handful of models, no dedicated platform team.
- Lifecycle ownership
- DVC + MLflow + one orchestrator + a serving runtime + Evidently, all on a single cluster or VM.
- Minimum components
- • data-versioning
- • experiment-tracking
- • orchestration
- • serving
- • monitoring
- Source of truth
- MLflow runs and registry aliases are the model source of truth.
- Operational owner
- The ML engineers who build the models.
- Failure boundary
- Each tool owns one stage; a serving outage does not corrupt tracking data.
- Scale-up trigger
- More than two teams or a regulated environment requiring RBAC and air-gapped operation.
- Reason not to choose
- No dedicated platform team means upgrades, backup and secrets are owned by people who also ship models.
Composable open-source stack
- Team condition
- A small platform team, need for full data control or air-gapped operation, willingness to operate each component.
- Lifecycle ownership
- Separate open-source tools per stage, self-hosted, integrated through typed artefact handoffs.
- Minimum components
- • DVC
- • MLflow
- • Kubeflow Pipelines or Airflow
- • Ray Serve or KServe
- • Evidently
- Source of truth
- Each tool is the system of record for its stage; MLflow aliases bridge tracking to serving.
- Operational owner
- A dedicated platform or ML infrastructure team.
- Failure boundary
- Clean per-stage boundaries, but the team owns the integration glue and every upgrade.
- Scale-up trigger
- Kubernetes-native concerns (multi-tenant scheduling, GPU sharing) outgrow ad-hoc deployment.
- Reason not to choose
- Engineering cost of operating, securing and upgrading each component exceeds the value of full control.
Kubernetes-native stack
- Team condition
- Already running Kubernetes, need multi-tenant scheduling, GPU sharing and declarative rollouts.
- Lifecycle ownership
- Kubeflow Pipelines and KServe on Kubernetes, with MLflow for tracking and Evidently for monitoring.
- Minimum components
- • Kubernetes
- • Kubeflow Pipelines
- • KServe
- • MLflow
- • Evidently
- Source of truth
- Kubernetes manifests and pipeline DAGs declare the system state; MLflow holds model lineage.
- Operational owner
- A platform team that already operates Kubernetes.
- Failure boundary
- Kubernetes isolates workloads; pipeline retries and KServe rollbacks contain failures per stage.
- Scale-up trigger
- The team wants to stop operating Kubernetes control planes and move to a managed control plane.
- Reason not to choose
- Kubernetes operational burden is high and unjustified if you have only a few models and no multi-tenant scheduling needs.
Managed-cloud stack
- Team condition
- Cloud-native organisation, small or no platform team, preference for offloading upgrades and backup to a vendor.
- Lifecycle ownership
- Managed MLOps services (e.g. cloud-native tracking, pipeline and serving services) own each stage.
- Minimum components
- • managed-tracking
- • managed-orchestration
- • managed-serving
- • managed-monitoring
- Source of truth
- Vendor-managed services hold the system of record within the cloud account.
- Operational owner
- The cloud provider operates the platform; your team owns configuration and cost.
- Failure boundary
- Vendor service-level agreements define boundaries; cross-service failures are the vendor's incident.
- Scale-up trigger
- Cost scales super-linearly with usage, or data-residency rules require moving some stages on-prem.
- Reason not to choose
- Vendor lock-in, egress cost and loss of control over the data model outweigh the operational savings.
Hybrid stack
- Team condition
- Regulated or data-residency constraints where some stages must stay on-prem and others can use managed services.
- Lifecycle ownership
- Self-hosted stages for sensitive data (training, tracking) combined with managed stages for serving or monitoring.
- Minimum components
- • self-hosted-tracking
- • self-hosted-orchestration
- • managed-or-self-hosted-serving
- • managed-or-self-hosted-monitoring
- Source of truth
- Split across on-prem tools and cloud services; the registry alias bridges the two halves.
- Operational owner
- A platform team owning the on-prem half plus a vendor relationship for the managed half.
- Failure boundary
- Network boundaries between on-prem and cloud define the trust boundary; handoffs are explicit.
- Scale-up trigger
- One half grows complex enough to standardise entirely on-prem or entirely managed.
- Reason not to choose
- Operating two deployment models doubles integration, networking and security work.
Composable open-source MLOps stack
A composable open-source stack assembles one self-hosted tool per stage and connects them through typed artefact handoffs rather than a monolithic platform. The strength is replaceability: each component can be swapped without rewriting the others because the contracts between them are explicit.
The trade-off is operational burden. License cost is zero, but the team owns installation, upgrades, secrets, backup and disaster recovery for every component. This archetype suits organisations that need full data control, air-gapped operation or deep customisation, and that have a platform team to absorb the engineering cost. See the open-source stack page for the reference architecture and ownership layer map.
Kubernetes-native stack
A Kubernetes-native stack runs the orchestrator and serving control plane on Kubernetes so scheduling, GPU sharing, retries and rollouts are declarative. Kubeflow Pipelines owns the DAG on Kubernetes; KServe owns serving autoscaling and traffic splitting; MLflow and Evidently can run on or off the cluster.
This archetype is justified when you already operate Kubernetes and need multi-tenant scheduling or progressive rollouts. It is not justified by tool popularity alone: the operational cost of a Kubernetes control plane is high, and a few models on a single cluster do not earn it back. The pipeline orchestration and model serving pages cover the per-tool decisions.
Managed-cloud and hybrid stacks
A managed-cloud stack offloads upgrades, backup and capacity to a vendor. It suits organisations with a small or no platform team and no hard data-residency constraint. The cost model shifts from engineering hours to usage-based fees, which can scale super-linearly as model count and traffic grow.
A hybrid stack splits stages across on-prem and managed services when only some stages are sensitive. Training and tracking may stay self-hosted for data control while serving or monitoring use a managed service. The registry alias or artefact handoff bridges the two halves, and the network boundary between them becomes the trust boundary.
Build versus buy decision
The decision is rarely all-build or all-buy. Each stage can be decided separately against team capacity, data control and cost trajectory.
| Condition | Managed | Self-hosted | Hybrid |
|---|---|---|---|
| Small team, no platform capacity, no data-residency constraint | Default — offload upgrades, backup and capacity to a vendor. | Avoid unless the team wants to learn platform engineering. | Only if cost grows faster than platform capacity. |
| Regulated data or air-gapped requirement | Only for non-sensitive stages behind a strict network boundary. | Default for sensitive stages where data cannot leave the boundary. | Common — sensitive stages self-hosted, the rest managed. |
| Large model fleet, multi-tenant GPU scheduling | Viable if the vendor's scheduling meets the SLA and cost curve. | Viable on Kubernetes with Kubeflow and KServe if a platform team exists. | Viable if training stays on-prem and serving uses a managed control plane. |
| Need to own the data model and avoid lock-in | Avoid — vendor data models are hard to export at scale. | Default — open-source tools give full control of the data model. | Possible if export contracts are negotiated for managed stages. |
| Cost growing super-linearly with usage | Re-evaluate — managed fees often scale faster than self-hosted cost. | Favoured — fixed engineering cost amortises over usage. | Move the most expensive stage to self-hosted first. |
How to evaluate an MLOps platform
Evaluate a platform against the ownership boundaries it draws, not the features it advertises. Start from the lifecycle map and ask, for each stage, whether the platform is the system of record, what handoff it exposes, and who operates upgrades and backup.
Run the platform through a concrete lifecycle: version a dataset, record a run, register a model, promote it through an alias, serve it, inject drift, and roll back. The decisions that are hard to reverse — data model, authentication model, export capability — deserve the most scrutiny. Each comparison page in this cluster publishes a scope boundary, an evaluation protocol and a capability matrix so the same dimensions are checked consistently across tools.
- Does the platform own the stage or merely integrate with the owner?
- What is the typed handoff in and out of the platform?
- Who operates upgrades, backup and disaster recovery?
- Can data and artefacts be exported without the platform?
- What is the cost trajectory as models and traffic grow?
Common tool-selection mistakes
The most common mistake is choosing tools because they are popular rather than because they own the right boundary for the team. A popular orchestrator that does not fit how the team reasons about pipelines becomes friction, not leverage.
The second mistake is conflating layers: treating a Kubernetes control plane, a Python serving framework and an inference server as interchangeable. They solve different problems and often stack together. The third is ignoring operational burden: license cost is visible, but the cost of upgrades, backup, secrets and on-call is hidden until the first incident.
- Choosing by popularity instead of by ownership boundary.
- Conflating a control plane, a serving framework and an inference server.
- Ignoring upgrade, backup and on-call cost beyond license cost.
- Assuming a managed platform removes all operational ownership.
- Letting one tool silently own two lifecycle stages.
Choose the next decision guide
- Related decisionOpen-source MLOps stackReference self-hosted stack, ownership layer map and operational burden.
- Related decisionExperiment tracking toolsMLflow, Weights & Biases and ClearML compared across tracking dimensions.
- Related decisionPipeline orchestration toolsKubeflow Pipelines, Airflow, Dagster and Prefect compared across orchestration dimensions.
- Related decisionModel serving toolsKServe, Ray Serve, Triton and BentoML compared across serving dimensions.
- Related decisionML model monitoring toolsEvidently, Arize, WhyLabs and Fiddler compared across monitoring dimensions.
Sources and last verification
Tool capabilities on this hub are grounded in official documentation and the School of Core AI reference MLOps architecture. Per-tool sources and verification dates are listed on each comparison page.
Limitations
- Capability claims are documented from official sources as of August 2026 and are not runtime benchmarks.
- Stack archetypes are reference patterns; actual deployments vary by team and infrastructure.
- Cost trajectory claims are directional and depend on negotiated vendor pricing.
Re-verification cadence: 2026-11-21
Sources and last verification
Every claim is linked to a source. Sources are re-verified on a cadence. See the note on limitations and re-verification cadence at the end of the page.
- View source →01Tier 4School of Core AI
Practical MLOps Architecture — Reference Implementation
Version: August 2026
First-party reference implementation documenting tool integration in the SCAI MLOps architecture.
Supports claims:
- SCAI reference MLOps architecture
- MLflow + Kubeflow + Ray + KServe integration
Last verified:
- View source →02Tier 4School of Core AI
End-to-End MLOps Project
Version: August 2026
Cluster 2 project proof.
Supports claims:
- End-to-end MLOps project proof
- AWS SageMaker capstone
Last verified:
Learn to integrate the full MLOps tool stack end to end
This cluster maps which tool owns which responsibility. Building the stack so the pieces actually connect — data versioning, MLflow, Kubeflow, Ray Serve and Evidently in one reproducible pipeline — is covered in the guided MLOps program, where you wire multiple tools together in a graded end-to-end project.
#guided-mlops-tool-stack