MLflow

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

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 runs

This 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_name when 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?

Related DL Notes

• Experiment Tracking
• Model Registry
• Model Versioning