This single page covers all of MLOps at working depth. Read it start to finish in about 30 minutes and you will understand the gap between a working notebook and a reliable production system, and the standard toolkit — serving, containers, orchestration, CI/CD, registries, monitoring, drift detection, caching, and LLM-specific gateway concerns — used to close it.

Every section ends with a Go deeper link to a full page on that topic. Read this first, then follow the links for whatever you need in detail.

MLOps is the discipline of making a model's behavior in production as reliable, observable, and controllable as its behavior in a notebook — because a model that works once, on a laptop, on a held-out test set, is not the same thing as a model serving real traffic reliably, month after month, as the world it's making predictions about keeps changing.

A /health endpoint that only checks "is the process running" is not a health check. A process can be alive while its model failed to load, its GPU is out of memory, or its dependency (a vector database, a cache) is unreachable. A real health check exercises the actual prediction path, or at minimum confirms the model and its dependencies are genuinely ready.

Multi-stage builds exist because ML dependencies are large. Compiling and installing packages needs build tools that the final running image doesn't — a multi-stage build keeps those tools out of the image that actually ships, which can be the difference between a multi-gigabyte image and a few hundred megabytes.

GPU workloads scale differently than CPU ones. A GPU-backed pod is expensive and slow to start (loading model weights takes real time), so naive CPU-style autoscaling that spins pods up and down aggressively can cost more in cold-start latency than it saves in idle compute. Scale GPU-backed services more conservatively than stateless CPU services.

"Which model is in production" should be a query, not a Slack thread. Without a registry, that question gets answered by asking whoever deployed it last, if they remember, and if they're still on the team. A registry makes it an auditable fact.

"The service is up" and "the model is still good" are different claims, checked by different signals. A model can return 200 OK on every request while its predictions have quietly become useless because the world it's predicting about changed. System monitoring alone will never catch that — only model-quality and drift monitoring will.

Concept drift is the harder one to catch, because the input distribution can look perfectly normal while the model's predictions quietly become wrong — statistical drift detection on the inputs alone won't see it. Catching it usually needs some feedback signal on actual outcomes, not just monitoring what comes in.

Semantic caching needs a similarity threshold tuned carefully, not just "close enough." "What's the refund window?" and "what's the return window?" should hit the same cache entry; "what's the refund window?" and "how do I cancel my refund request?" should not, even though they're superficially similar. A threshold that's too loose returns confidently wrong cached answers, which is worse than no caching at all.

Multi-armed bandits are the adaptive alternative to a fixed A/B split — they shift traffic toward the better-performing arm as evidence accumulates, rather than waiting for a fixed sample size before deciding. Worth it when the cost of serving the losing variant for the full test duration is high.

Training-serving skew is the classic ML production bug. If a feature is computed one way in an offline training pipeline and a subtly different way in the online serving path — different rounding, a different time window, a different null-handling rule — the model silently sees different inputs than it was trained on, and nobody notices until accuracy quietly drops. A feature store exists specifically to compute a feature once and serve the identical value both ways.