Ask five vendors what an MLOps platform is and you get five answers shaped like their product. An experiment-tracking company says it is a tracking server with deployment attached. A cloud provider says it is their managed suite. A Kubernetes vendor says it is a set of operators. None of those is wrong, and none of them is a definition you can shop with.
The definition that survives contact with a procurement process is functional: an MLOps platform is whatever system takes a dataset and an idea and turns it into a monitored, versioned, reproducible prediction service, and keeps doing so after the person who built it leaves. That system spans seven layers. Products differ in how many of the seven they cover and how well, not in whether the layers exist.
The seven layers at a glance
| Layer | Answers the question | Failure mode when missing |
|---|---|---|
| Data and feature management | What went into this model, and can serving see the same thing? | Training/serving skew, silent accuracy loss |
| Experiment tracking | What did we try, with which config, and what came out? | Unreproducible results, rediscovered dead ends |
| Pipeline orchestration | How does raw data become a candidate model, repeatably? | Retraining is a manual ritual owned by one person |
| Artifact and data versioning | Which exact bytes produced this model? | A model nobody can rebuild |
| Model registry | What is approved, what is deployed, who signed off? | Nobody can say what is actually in production |
| Serving and inference | How does a prediction reach the caller inside the budget? | Latency and cost surprises after launch |
| Monitoring and evaluation | Is it still working, and how would we know? | Degradation discovered by a customer |
This seven-layer view is what people usually mean by an MLOps framework: a reference architecture you score a product against, not a product itself. Every mature one, from Google’s continuous-delivery guide to Azure’s model-management documentation, describes the same shape with different names. The 2015 NeurIPS paper on hidden technical debt made the underlying point earlier and more bluntly: the model code is a small box in the middle of a much larger diagram, and the rest of the diagram is where systems rot.
Layer 1: data and feature management
This is the layer teams skip first and regret longest. The specific hazard is that training reads features from a warehouse with all of history available, while serving reads them from a low-latency store with only the present available. When those two paths compute a feature even slightly differently, the model degrades in production while every offline metric stays green.
A platform covers this layer properly when feature definitions are written once and consumed by both paths, and when historical retrieval is point-in-time correct by construction rather than by convention. The tooling trade-offs are the subject of our feature store comparison, and the point-in-time correctness problem is the criterion that separates the serious options from the caches with a nice API.
Layer 2: experiment tracking
The cheapest layer to adopt and the one with the clearest payback. A tracking server records parameters, metrics, code version and output artifacts for every run, so that six months later somebody can answer why the current model beat the alternative.
Almost every platform ships something here, and the differences are mostly ergonomic: how much instrumentation the library demands, whether runs are searchable across teams, and whether artifacts are stored where the rest of the stack can reach them. This is a weak axis to choose a platform on, because the switching cost is low and the formats are broadly interoperable.
Layer 3: pipeline orchestration
Orchestration is where a platform stops being a library and starts being infrastructure. The requirement is that the path from raw data to a candidate model runs as a defined graph, on a schedule or a trigger, with per-step resources, retries, caching and lineage.
The open-source orchestrators make genuinely opposite bets, which is why this is a real decision rather than a feature checkbox. Kubernetes-native designs give you scheduling power at the price of cluster expertise; ergonomics-first designs give you adoption at the price of control. The comparison is in pipeline orchestration: Kubeflow vs Metaflow vs Flyte.
Layer 4: artifact and data versioning
Model weights are easy to version. The dataset that produced them is not, because it is large, mutable, and often already living in a warehouse someone else owns. Without a snapshot mechanism, a reproducibility claim reduces to “the query was the same, and hopefully the table was too”.
Two mechanisms dominate: content-addressed pointers stored alongside code, and table formats that keep transaction logs so any commit can be read back. They solve different halves of the problem, and most teams end up with both. Data versioning for production ML covers where each one stops.
Layer 5: model registry
The registry is the seam between engineering and everyone else. It is supposed to be the authoritative answer to what exists, what is approved, what is deployed, and what evidence backs the promotion. In practice most registries drift into being a dumping ground within two quarters, because promotion is a human ritual rather than a gated transition.
A registry that holds up has three properties: promotion requires attached evidence, deployment reads the registry rather than a separate config, and the contents are portable enough to survive changing platforms. Model registry patterns that hold in production works through the ones that fail. If your organisation’s real requirement is portfolio-level control rather than delivery speed, the label you are looking for may be ModelOps instead, which we untangle in ModelOps platform vs MLOps platform.
Layer 6: serving and inference
Serving is the layer where platform choice becomes visible to users and to the finance team on the same day. The questions that matter are not “can it host an endpoint” but how autoscaling decides to add capacity, whether many small models can share hardware, how tightly the endpoint is coupled to the platform’s own data plane, and what the cold-start behaviour is.
Managed serving on the major clouds diverges more than the marketing pages suggest; the differences are laid out in model serving compared. If latency is the constraint, the budget breakdown in online inference latency is the more useful starting point, because model compute is rarely the largest term. If cost is the constraint, idle capacity usually dominates per-request price, which is the argument in inference cost optimization.
Layer 7: monitoring and evaluation
The last layer is the one most often bought as a separate product, and the one where “the platform includes it” most often means a dashboard of request counts. Useful coverage means input distribution monitoring, prediction distribution monitoring, delayed-label accuracy tracking once ground truth arrives, and an alert route that reaches a human who can roll back.
Evaluation is adjacent but distinct: monitoring tells you something changed, evaluation tells you whether a candidate is better before it ships. Continuous integration catches code regressions and almost nothing else, which is the gap evaluation pipeline design addresses.
What an MLOps platform is not
Three products get sold into this category and cover one layer each:
- A hosted notebook service is a compute layer. It does not version, promote, serve or monitor anything.
- An experiment tracker is layer two. Excellent tools here will happily let you deploy an untracked model built on unversioned data.
- A model-serving runtime is layer six. It answers requests; it does not know what should be answering them.
None of these are bad purchases. They become expensive when they are bought as the platform and the other six layers get improvised per team.
Single vendor or assembled stack
Managed suites cover all seven layers at uneven depth, and the depth is usually greatest in serving and weakest in feature management and evaluation. Assembled stacks let you pick the best component per layer and charge you in integration and on-call load instead of licence fees.
The realistic middle, and the most common outcome, is one primary platform plus one or two components filling the layers it handles poorly. The layer-by-layer scoring of the major managed options is in our enterprise MLOps platform comparison; the component-by-component view of replacing a single vendor is in SageMaker alternatives compared; and if the requirement is a fully open-source stack, assembling an open-source MLOps platform covers what each layer costs in operational effort.
Rather than reading a generic ranking, weight the seven axes against your own constraints in the MLOps Platform Selector, which scores each platform per capability and names the gap it forces you to fill with a second tool.
Scoring a vendor against the seven layers
- Score each layer 0 to 3, where 0 is absent, 1 is a thin wrapper, 2 is usable, 3 is a reason to buy the product. Do it from documentation, not from a demo.
- Weight the layers by your failure history. A team that has been burned by training/serving skew should not weight experiment tracking highly.
- Ask what the platform emits automatically versus what depends on engineers remembering. Anything in the second category degrades within two quarters.
- Test portability on the registry and the feature definitions. Those two carry the most institutional knowledge and are the most painful to rebuild.
- Price the layers you will still have to buy. A platform that scores 3 on serving and 0 on monitoring is not cheaper than one that scores 2 on both.
Two constraints override the scoring entirely. If you operate under model-risk regulation, evidence generation outranks every convenience feature, and the ranking changes accordingly in best MLOps platform for regulated industries. If your threat model includes third-party model artifacts, the loading path is an execution path, which is the subject of ML model supply chain attacks.
FAQ
Is an MLOps framework the same as an MLOps platform?
Not quite. An MLOps framework is the conceptual model of what has to be covered: the seven layers above, or an equivalent reference architecture such as Google’s MLOps maturity model. A platform is the tooling that implements some or all of that framework. You use the framework to score platforms, which is exactly what the enterprise MLOps platform comparison does layer by layer. So a search for an “MLOps framework” is usually about the reference architecture, and “MLOps frameworks compared” is really a request to compare the platforms that implement it.
Is an MLOps platform the same as an ML platform?
In casual engineering use, “ML platform” usually means the internal system a company built so data scientists do not each invent their own infrastructure. It is an internal product with internal users. An MLOps platform is the purchasable or assemblable tooling that internal product is built from. Most internal ML platforms are one managed platform plus glue.
Do small teams need all seven layers?
They need all seven functions, not seven products. A two-person team can get versioning from git plus a table format, tracking and registry from one open-source server, orchestration from a scheduler they already run, and monitoring from scheduled queries. What fails is skipping a layer entirely, not implementing it cheaply.
Which layer should be adopted first?
Whichever one has already cost you an incident. Absent that history, experiment tracking plus a registry is the standard first pair, because they are cheap, low-lock-in, and they make every later layer easier to add by giving the rest of the stack something authoritative to read.
Does a feature store count as an MLOps platform?
No. A feature store covers layer one well and nothing else. It is one of the highest-value single components to add to an otherwise assembled stack, which is a different claim from being the platform.
How much of this changes for large language models?
Layers three through six survive almost unchanged. What differs is that the artifact is often a prompt and a retrieval index rather than weights, and that evaluation stops being a metric on a holdout set. That is the split behind the LLMOps label, and it is usually a layer added to an MLOps platform rather than a replacement for one.
