FRENES

Glossary · Deploying and hosting

MLOps

MLOps is a set of practices for developing, deploying, and maintaining machine learning systems in an organized way. It connects work on data and models with everyday operation through methods for version tracking, validation, monitoring, and managing changes to a service over its working life.

MLOps: the explanation

A machine learning system includes more than a model. Teams need to prepare data, preserve settings, compare results, and make the service usable. MLOps organizes those activities so people can identify what was used and repeat the operations that matter. Practices may include automated tests, a model registry, and a deployment procedure. The appropriate level of automation depends on the project's size and on how a change could affect the people who rely on the resulting service in their daily work.

MLOps adapts software development and operations practices to the particular needs of machine learning. Data and models may change even when the application code remains similar, so several elements need coordinated checks. The documentation at https://docs.cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning discusses automation and monitoring for these systems. The practical goal is to keep a service working over time, beyond a successful demonstration on a few examples. That also requires clear responsibilities and procedures that the people maintaining the application can realistically follow when conditions change.

For language model applications, related practices are sometimes called LLMOps. Teams may track instructions, evaluations, reference documents, and calls to external services alongside other application components. Not every organization trains its own models: using an API still leaves changes to manage. MLOps is neither a single product nor a guarantee that every result will be correct. Its value comes from procedures that suit the actual work, the available team, and the consequences of errors in the deployed service.

A concrete example

Your organization uses a model to direct requests to the right department. Before replacing the current version, the team compares a proposed update using representative examples. It preserves the evaluation material, settings, and results. The rollout is gradual, with error monitoring and a way to restore the previous version. These practices reduce the chance of introducing changes that are difficult to explain or reverse when problems appear.

Why it matters

For users, MLOps mainly concerns consistency and ongoing maintenance. A tool may perform well in a demonstration and deteriorate after an update. Ask how changes are evaluated, how incidents are detected, and whether previous versions can be restored. Technical vocabulary matters less than clear responsibilities and practical procedures for dealing with problems that affect the service you depend on in your everyday work.

Common misconceptions

  • MLOps is not only about training models faster, because it also covers data, versions, deployment, monitoring, and maintenance throughout the period when a system provides a service to people who depend on it for their work.
  • Adopting MLOps does not require automating every decision, because human reviews can remain appropriate or necessary, while the level of automation should reflect the project's constraints and the consequences that mistakes could have for the people using it.

Related terms: deploying and hosting

self-hosting
Self-hosting means running software on infrastructure whose administration you manage or control.
local AI
Local AI is artificial intelligence that runs its calculations on your device or on infrastructure controlled by your organisation.
LLM observability
LLM observability is the set of methods used to understand an application built with language models through its recorded events and measurements.
OpenAI-compatible API
An OpenAI-compatible API is a programming interface that reproduces some or all of an OpenAI API's exchange formats so existing software can connect to it.

Where this site covers it

The term appears on 52 pages of this site. A few of them:

Go further

Frequently asked questions

Must we train our own model?

No. An application using an external model still needs version management, evaluations, and change controls. The relevant practices differ from a training project, but organizing maintenance and tracking how the service behaves remain useful responsibilities for the team.

How does it differ from DevOps?

DevOps brings software development and operations closer together. MLOps applies related principles while adding data, experiment, and model management. Those elements require additional checks because changes to them can alter behavior even when application code stays similar.

Does a small project benefit?

Yes, at a suitable level of complexity. Preserving versions, using representative evaluations, and planning a rollback can already help. You do not need a large infrastructure to apply basic practices that make a service easier to maintain and change.

Neutrality. No affiliate links. No vendor pays to be reviewed, rated or ranked. Reviews are directed by François Chollet, neutral and factual, and every data point is dated and sourced. How we score