From MLOps to LLMOps: what changes

LLMOps is MLOps for a different kind of model. The operational frame carries straight over; what changes is that the model is usually one you call rather than train, its output varies run to run, and the things you version and evaluate are prompts, vectors and fuzzy answers rather than weights and accuracy.

Last updated: 15 Oct, 2026 · LLMOps

The LLMOps overview named the lifecycle stages. This lesson sets the starting point most readers come from. If you know MLOps, the LLMOps Project Lifecycle video makes the point directly: the tools are much the same, with some added for working with LLM models, so moving across is a short step rather than a new field.

What carries over from MLOps

The operational backbone does not change. You still plan against a use case, collect and prepare data, pick and build a model, evaluate it, deploy it, monitor it and version everything. The induction video keeps the same stage names it used for MLOps a year earlier, and the same supporting tools reappear: MLflow for tracking, DVC for data version control, Docker for packaging, a CI/CD pipeline, and logging, metrics and alerting for observability.

What is new for LLMs

• You call a model more often than you train one. The common shape is an API call to a provider, so a lot of the work moves from training runs to prompts, retrieval and the cost of each call.
• The output is not fixed. The same input can give a different answer each run, so a test that checks for one exact string stops working and evaluation has to judge quality instead.
• Cost is measured in tokens. Every call spends input and output tokens, and the induction video tells of token use jumping by orders of magnitude in a single day, so watching spend is a first-class operational task.
• The data is vectors or fine-tuning sets. Instead of a feature table, the data you prepare is documents turned into embeddings in a vector database for retrieval, or example pairs for fine-tuning a model.
• Evaluation is fuzzy. There is rarely one right answer, so you reach for scored metrics, A/B comparisons and bias checks rather than a single accuracy number.
• Prompts are part of the system. A prompt is code you iterate, store and version, not a one-off string, because changing it changes behaviour as much as changing a parameter would.

MLOps and LLMOps side by side

Where this framing helps

• Reusing an MLOps stack, where MLflow, DVC, Docker and CI/CD already in place carry most of the load and you add the LLM-specific pieces on top.
• Scoping a first LLM project, where knowing what is new keeps you from re-solving problems MLOps already handled.
• Hiring and team design, where an MLOps engineer moves into LLMOps with the stages they know and a short list of additions to learn.

Related

• Previous: LLMOps overview
• Next: Why an LLM app needs ops