Start here in MLOps
The most useful guides in this topic, not just the most recent.
MLOps Guides & Tutorials
Operationalise machine learning — MLflow, Docker, Kubernetes, CI/CD, monitoring and production ML system design.
MLOps articles
Model Packaging: From Pickle to Production
A trained model has to leave the notebook as a file, and the format decides how safe, portable and fast it is. This guide shows why loading a pickle can run arbitrary code, then saves one model as pickle, joblib, skops and ONNX and compares their size, their predictions and what each needs to load.
Logging and Observability for ML Systems
Metrics show that something changed; logs and traces show which requests, which step and which model version. This guide logs every prediction of a real intent classifier as JSON, traces each request with OpenTelemetry and joins the true labels later, finding that 9% of requests held 41% of the errors.
Reproducibility in ML: Seeds, Configs and Pipelines
If a training run cannot be repeated, its results cannot be trusted or compared. This guide measures the main sources of variation on a real model, from missing seeds to row order, shows how much results move between seeds, and builds a small run manifest that records what a rerun needs.
MLOps Tools Landscape 2026: What to Learn
The MLOps landscape lists hundreds of tools, but a working platform needs only a handful of jobs done. This guide groups the widely used open-source tools by job, gives their versions, release dates and licences as checked on 8 October 2026, and suggests what to learn first and how to judge the rest.
Feature Stores Explained: Why Teams Need Them
A feature store keeps the features a model trains on and the features it is served the same. This guide builds one with Feast on a year of real retail orders and shows the problem it solves: a naive join that looked better in validation, 0.798 against 0.727, then did worse in production.
Scaling Model Training with Distributed Computing
Distributed training splits the work across machines, but keeping them in step costs time. In real PyTorch data-parallel runs with one, two and four workers, every replica stayed identical, yet small batches trained slower with more workers and only large batches gained, about one and a half times with four.