MLOps Highlights Summary

Every highlight bullet from the 11 pages in this section, gathered on one page and grouped by the page it came from.

The Notebook-to-Production Lifecycle

• MLOps is a lifecycle, not a single deployment step
• Experiment tracking turns messy notebook runs into comparable records
• A model registry is the contract between training and serving
• Serving and monitoring are the two halves of 'production' most teams skip
• Drift is the reason a model that shipped correctly can still go stale
• Every stage exists to answer one question: can we reproduce this result?

MLOps Basics

• Version data, code, and models together
• Track experiments before tuning hyperparameters
• Package models as reproducible inference artifacts
• Monitor predictions for drift after deployment

Experiment Tracking

• Log params, metrics, and artifacts for every training run
• MLflow provides local and server-backed tracking
• Compare runs to find the best hyperparameters
• Link runs to git commit and data version

Model Registries & Versioning

• Model registry tracks versions with stage labels
• Promote Staging -> Production after validation
• Rollback by redeploying a previous version
• Every version links to training run and data

Data & Model Versioning (DVC)

• DVC tracks large files outside git with .dvc pointers
• Pipeline stages define reproducible DAGs
• dvc repro reruns only changed stages
• Remote storage (S3, GCS) for team sharing

Serving with FastAPI

• Load model once at startup with lifespan handler
• Pydantic models validate request and response schemas
• Health endpoint for load balancer checks
• Return model version with predictions for traceability

Dedicated Serving (BentoML / Triton / TorchServe)

• Triton serves multiple models with GPU batching
• BentoML packages models with pre/post processing
• TorchServe handles PyTorch model lifecycle
• Use dedicated servers when FastAPI throughput is insufficient

Batch & Streaming Inference

• Batch inference scores large datasets offline
• Streaming inference processes events in real time
• Feature stores share features between training and serving
• Match preprocessing exactly between batch and online paths

Monitoring and Drift

• Data drift: input feature distributions change over time
• Concept drift: relationship between features and target changes
• Monitor prediction distributions and error rates
• Alert on drift; retrain when metrics degrade

GPU Infrastructure & Cost

• Right-size GPU for workload: inference vs training
• Spot/preemptible instances cut training cost 60-80%
• Mixed precision reduces GPU memory and speeds training
• Compare cloud GPU vs API cost at your query volume

MLOps Best Practices

• Version data, code, and models together
• Scripts over notebooks for production training
• Load models once at API startup
• Monitor drift and retrain on schedule or alert