TL;DR: DevOps delivers software: code goes through build, test, deploy, and monitor, and the build is deterministic. MLOps delivers models, and three things change. Data becomes a versioned dependency alongside code, the "build" is a training run whose output varies and must be evaluated rather than unit-tested, and the deployed artifact degrades on its own as the world drifts, so monitoring has to trigger retraining. AIOps is a different term entirely: applying machine learning to IT operations (alert correlation, anomaly detection), which is a consumer of MLOps rather than a sibling of it. Below, the pipeline stage by stage, the three terms side by side, and what a DevOps engineer and an ML engineer each need to add to work on the other's side.
A DevOps engineer joins a machine learning team and recognizes everything: containers, CI, Kubernetes, dashboards, on-call. Two weeks in, a deploy goes out with the same code as last week and behaves differently. Nobody changed a line. The training data was refreshed, the model that came out of the pipeline was a different model, and the tests all passed because there were no tests that could fail. That is the moment the difference between DevOps and MLOps stops being vocabulary.
This guide walks the delivery pipeline stage by stage and marks what stays the same and what changes when the artifact is a model. It also clears up AIOps, which sounds like a sibling term and is a different thing, and it ends with the practical question: what do you have to learn to cross from one side to the other.
Start here
For what an MLOps curriculum should contain and the five artifacts that prove the skill, read the MLOps course guide. For the credentials that test it, read MLOps certifications. This article is the conceptual map that both of those assume.
DevOps in one pipeline
DevOps is the practice of delivering software continuously and safely. The pipeline is familiar: code in version control, a build that produces an artifact, automated tests that gate the artifact, a deployment strategy (blue-green, canary, rolling) with a rollback path, and monitoring that watches for errors, latency, and saturation. Two properties make the whole thing work. The build is deterministic, so the same commit produces the same artifact, and the artifact does not change after it ships; if it misbehaves, the cause is a change somebody made.
What changes when the artifact is a model
Data becomes a dependency you must version. A model is a function of code and data. The same training script on a refreshed dataset produces a different model, so reproducibility requires pinning the data version next to the git commit. DevOps has no equivalent, and it is the first thing DevOps engineers underestimate.
The build is an experiment, and its output varies. A training run has hyperparameters, random seeds, and hardware nondeterminism. The pipeline produces candidates, and the question is which candidate is better, which requires experiment tracking (logging every run's parameters, metrics, and artifacts) rather than a single build log.
Tests become evaluation gates. A unit test passes or fails. A model is evaluated against a held-out set with a metric and a threshold, and the threshold is a judgment call that changes as the business does. The promotion rule (which metrics, which thresholds, who approves) replaces the green checkmark.
The artifact needs a registry, with states. A DevOps artifact repository stores versions. A model registry stores versions plus lineage (which data, which run) and a promotion state (staging, production, archived), because several candidates coexist and one of them is live.
The deployment is heavier and often on GPUs. The container includes model weights and a runtime, is frequently gigabytes, and may need GPU drivers and specific hardware. Rollout strategies are the same in name and different in cost.
The artifact degrades without anyone changing it. Inputs drift away from the training distribution and the model's accuracy decays. DevOps monitoring watches for failures caused by changes; MLOps monitoring watches for degradation caused by the world, which means tracking input and prediction distributions, alerting on drift, and wiring the alert to retraining.
The pipeline is a loop. In DevOps, the pipeline ends at monitoring and restarts with the next commit. In MLOps, monitoring feeds retraining, which produces a new candidate, which goes through the evaluation gate, which is why "continuous training" sits next to continuous integration and delivery.
The pipeline, stage by stage
| Stage | DevOps | MLOps |
|---|---|---|
| Versioned inputs | Code | Code and data, pinned together |
| Build | Deterministic compile or package | Training run; output varies; every run tracked |
| Gate | Automated tests pass or fail | Evaluation against a held-out set with thresholds and an approver |
| Artifact store | Artifact repository with versions | Model registry with lineage and promotion states |
| Deployment | Container, canary or blue-green, rollback | Same strategies, larger containers, often GPUs, plus batch vs online serving |
| Monitoring | Errors, latency, saturation | Plus input and prediction drift, model quality over time |
| Trigger for the next cycle | A new commit | A commit, a schedule, or a drift alert that starts retraining |
AIOps is a different thing
AIOps means applying machine learning to IT operations: correlating alerts, detecting anomalies in metrics and logs, predicting capacity, and automating incident response. It is a use of models, and the models it uses are built and operated with MLOps. The confusion comes from the name: AIOps and MLOps sound like two flavors of the same practice, and they are a consumer and a supplier. An AIOps platform's anomaly detector is a model that somebody trained, evaluated, deployed, and monitors for drift.
Three terms that get confused
| Term | What it is | Who does it | Relationship |
|---|---|---|---|
| DevOps | Delivering software continuously and safely | Platform and DevOps engineers | The foundation MLOps builds on |
| MLOps | Delivering and operating models, including data, evaluation, and retraining | ML engineers, AI engineers, ML platform teams | DevOps plus data, experiments, evaluation gates, and drift |
| AIOps | Applying ML to IT operations: alert correlation, anomaly detection, capacity prediction | SRE and operations teams, often via vendor tools | A consumer of models that MLOps produces |
The newest layer: operating language models
Language models keep the MLOps loop and add three things. Evaluation needs a labeled question set and a judge model with bias checks, because there is no single accuracy number for generated text. A prompt or a fine-tuned adapter is a model change and has to be versioned and gated like one. And serving economics (throughput, time to first token, and cost per request on a GPU) become a first-class monitoring concern, because an LLM deployment can be correct and still unaffordable. The term for this layer is usually LLMOps, and it is MLOps with a harder evaluation problem and a more expensive artifact rather than a new discipline. The AI engineer roadmap places it at stage 6.
See the differences on a real GPU
Build, test, ship, and roll back a versioned GPU container (the DevOps half), track experiments and register a model with stage transitions (the MLOps half), then serve a language model on vLLM and measure the economics (the LLMOps layer).
- Open the labsGPU Container Lifecycle: Build, Test, Ship, Rollbackintermediate 40 minGPU sandbox
- Open the labsMLflow Experiment Tracking: From Single Run to Team Workflowintermediate 35 minGPU sandbox
- Open the labsvLLM Production Serving: PagedAttention, Continuous Batching, Prefix Cachingadvanced 55 minGPU sandbox
What a DevOps engineer needs to add
If you come from DevOps, the pipeline mechanics transfer intact and four things are new. Data versioning and the discipline to pin it with the code. Experiment tracking and the idea that a build produces candidates. Evaluation as a gate, including who sets the thresholds. And drift monitoring wired to retraining. The fastest way to learn all four is to run one small model through the whole loop, which is the six-week syllabus in the course guide. DevOps engineers tend to be strong on the deployment and monitoring half within a week and to underestimate the data and evaluation half for a month.
What an ML engineer needs to add
If you come from modeling, the evaluation and data half is familiar and the delivery half is new: containers and CI, deployment strategies with rehearsed rollback, infrastructure as code, and observability beyond accuracy (latency, errors, saturation, cost). ML engineers tend to keep the model in a notebook longer than they should; the corrective is to ship a small model through CI with a rollback in the first week, before the model is good, so the pipeline exists when the model is.
Frequently asked questions
Key takeaways
0/7 completedNext steps
Run one small model through the whole loop this month: track it, register it, ship it through CI with a rollback, watch it drift, retrain it. The MLOps course guide has the six-week version, and the AI Engineer path covers the loop attached to models you build, with the LLM layer on top.
Sources:
- Google Cloud: MLOps, continuous delivery and automation pipelines in machine learning
- MLflow documentation: Model Registry
- Kubernetes documentation: Deployments