MLOps & Model Deployment: Lifecycle, Serving & Drift

Q: How is MLOps different from regular DevOps?

DevOps ships and operates code; MLOps also has to manage data and models as first-class, versioned artifacts, and contend with a failure mode software doesn't have: silent quality decay. A deployed model can run flawlessly while becoming wrong because the input distribution shifted. So MLOps adds data/feature versioning, model registries, reproducible training pipelines, and quality monitoring (drift, accuracy) on top of standard CI/CD and infrastructure concerns.

Q: Online serving or batch scoring?

Use online serving (a real-time API) when predictions are needed on demand with low latency — recommendations, fraud checks, personalization. Use batch scoring when you can precompute predictions on a schedule — nightly churn scores, lead ranking — which is simpler and cheaper to operate. Many systems do both: batch for bulk precomputation, online for fresh, request-time predictions.

MLOps & Model Deployment

MLOps is the discipline of reliably getting ML models into production and keeping them healthy. A model that scores well in a notebook is only the beginning — the hard parts are reproducible training, versioning data and models, deploying safely, and monitoring the things that actually degrade: data drift and prediction quality, not just CPU and uptime.

The defining difference from regular software: an ML system can be silently wrong while perfectly healthy. The code runs, the API responds, latency is fine — but the world shifted and the model's predictions quietly decayed. MLOps exists to catch that.

TL;DR

Treat models as versioned artifacts with reproducible training.
Separate training pipelines from serving systems.
Monitor data drift and model quality, not just uptime.
Have a rollback plan and watch for training/serving skew.

Quick Example

A model registry pins exactly which artifact is serving — and lets you roll back:

A Practical MLOps Lifecycle

Collect / validate data — check schema, ranges, and quality.
Train the model with reproducible pipelines.
Evaluate and compare against a baseline (Model Evaluation).
Register the model artifact with its metadata.
Deploy with a safe rollout strategy.
Monitor and retrain when quality degrades.

Key Components

Data & feature versioning — track exactly which datasets and features trained each model.
Model registry — store versions, metrics, and metadata; the source of truth for what's deployable.
Serving — an online API for low-latency predictions, or batch scoring for bulk jobs.
Monitoring — operational signals (latency, errors) and model-quality signals (drift, accuracy).

Deployment Patterns

Canary — route a small % of traffic to the new model, watch metrics, then ramp up.
Shadow mode — run the new model alongside production on real traffic without using its outputs, to compare safely.
A/B test — split traffic between models to measure business impact, where appropriate.

These mirror general deployment strategies but add model-quality comparison.

Best Practices

Make training reproducible — pin data versions, seeds, code, and environment.
Register every model with its metrics and lineage; deploy from the registry.
Keep features consistent between training and serving (one feature definition).
Monitor drift and quality, not just system health.
Always have a rollback — re-promote the previous model version instantly.

Common Mistakes

Training/serving skew

No drift or quality monitoring

FAQ

How is MLOps different from regular DevOps?

DevOps ships and operates code; MLOps also has to manage data and models as first-class, versioned artifacts, and contend with a failure mode software doesn't have: silent quality decay. A deployed model can run flawlessly while becoming wrong because the input distribution shifted. So MLOps adds data/feature versioning, model registries, reproducible training pipelines, and quality monitoring (drift, accuracy) on top of standard CI/CD and infrastructure concerns.

What is data drift and how do I detect it?

Data drift is when the statistical distribution of production inputs diverges from the training data (e.g. user behavior changes, a sensor recalibrates), degrading model accuracy. Detect it by monitoring feature distributions over time and comparing against the training baseline with statistical tests (PSI, KS test) or drift-detection tools. When labels eventually arrive, also track live accuracy directly. Significant drift is the signal to retrain.

What is training/serving skew?

It's a mismatch between how features are computed during training versus in production serving — different code, different data sources, or different timing. The model then receives inputs that subtly differ from what it learned on, hurting performance in ways offline evaluation never reveals. The fix is a single shared feature definition/pipeline (often a feature store) used by both paths, so the model sees identical features everywhere.

Online serving or batch scoring?

Use online serving (a real-time API) when predictions are needed on demand with low latency — recommendations, fraud checks, personalization. Use batch scoring when you can precompute predictions on a schedule — nightly churn scores, lead ranking — which is simpler and cheaper to operate. Many systems do both: batch for bulk precomputation, online for fresh, request-time predictions.