MLflow is one of the most widely used open-source tools implementing the experiment tracking practices from the previous note, plus model packaging and a model registry — a practical, concrete example of the broader concept.
MLflow's Core Components
| Component | Purpose |
|---|---|
| Tracking | Logging parameters, metrics, and artifacts for each experiment run (as shown in the previous note) |
| Projects | Packaging code in a reusable, reproducible format with its dependencies |
| Models | A standard format for packaging models, supporting many frameworks (PyTorch, TensorFlow, scikit-learn, and more) uniformly |
| Model Registry | A centralized store for managing model versions and their deployment stage (staging, production, archived) — covered fully in the next note |
Code — A Complete MLflow-Tracked Training Run
import mlflow
import mlflow.pytorch
mlflow.set_experiment("image_classifier_v2")
with mlflow.start_run(run_name="resnet50_lr0.001"):
mlflow.log_params({
"architecture": "resnet50",
"learning_rate": 0.001,
"batch_size": 64,
"epochs": 20
})
for epoch in range(20):
train_loss = train_one_epoch(model, train_loader, optimizer)
val_loss, val_acc = evaluate(model, val_loader)
mlflow.log_metrics({"train_loss": train_loss, "val_acc": val_acc}, step=epoch)
mlflow.log_metric("final_test_accuracy", test_accuracy)
mlflow.pytorch.log_model(model, "model", registered_model_name="image_classifier")Viewing and Comparing Runs
# Launch the MLflow tracking UI locally (or point it at a shared tracking server)
# $ mlflow ui
# Then browse to http://localhost:5000 to see every logged run: filter by
# parameters, sort by metrics, and visually compare training curves across runsThis UI directly implements the "compare runs systematically" capability described in Experiment Tracking — no manual spreadsheet maintenance required.
Why a Shared Tracking Server Matters for Teams
MLflow can run with a shared, centralized tracking server (rather than purely local file storage) so an entire team's experiments are visible in one place — essential once more than one person is training models for the same project, avoiding siloed, hard-to-compare individual tracking setups.
Common Mistakes
- Using MLflow's local file-based tracking for a multi-person team project — this fragments experiment history across individual machines rather than providing one shared, comparable view.
- Logging a model to MLflow without
registered_model_namewhen the intent is later deployment — without registration, the model doesn't get versioned through the model registry workflow covered next.
Interview Relevance
Q: "What's the difference between MLflow's tracking component and its model registry component?" Tracking logs the details of individual experiment runs — parameters, metrics, and artifacts for each attempt — primarily useful during the experimentation and model development phase. The model registry sits one level above this: it manages specific, promoted model versions through defined deployment stages (staging, production, archived), providing governance and a clear record of exactly which model version is currently live — a distinct concern from tracking individual training runs.
Practice Question
Why would a team of five ML engineers benefit from a shared MLflow tracking server rather than each engineer using local file-based tracking independently?
