Deploying AI Models: From Notebook to Production (MLOps)

You've trained a model that works beautifully in your notebook. Here's the uncomfortable truth: right now, it's useless to everyone but you. A model only creates value when real people or real software can actually use it. Bridging that gap — from a .ipynb on your laptop to a reliable service handling real traffic — is called deployment, and keeping it healthy over time is MLOps. This lesson walks the whole path, practically.

The notebook-to-production gap

Notebooks are for exploration; production is a different world. In production your model must respond fast, handle many users, stay available, recover from errors, and keep working as the world changes. A model that scores 99% in a notebook but can't be called by an app, or silently degrades after launch, has delivered nothing. Closing that gap is where a lot of real AI work actually happens.

Step 1: Save your model (persistence)

First, get the trained model out of memory and into a file you can load anywhere. This is serialization. Here's the full save-and-reload cycle in runnable Python:

import pickle
from sklearn.linear_model import LogisticRegression

# Train a tiny model
X = [[0], [1], [2], [3], [4], [5]]
y = [0, 0, 0, 1, 1, 1]
model = LogisticRegression().fit(X, y)

# SAVE it to a file (this is what you deploy)
with open("model.pkl", "wb") as f:
    pickle.dump(model, f)

# ...later, on a server, LOAD it back — no retraining needed
with open("model.pkl", "rb") as f:
    loaded = pickle.load(f)

print(loaded.predict([[4]]))   # [1]  — works from the file

That model.pkl file is your deployable artifact. Everything downstream just loads it and calls predict().

Step 2: Serve it as an API

To let other software use your model, you wrap it in a web API — a URL that takes input and returns a prediction. The model becomes a service anything can call: a website, a mobile app, another backend. In Python, FastAPI is the popular choice (conceptual sketch; needs pip install fastapi uvicorn):

from fastapi import FastAPI
import pickle

app = FastAPI()
model = pickle.load(open("model.pkl", "rb"))   # load once at startup

@app.post("/predict")
def predict(value: float):
    result = model.predict([[value]])
    return {"prediction": int(result[0])}

# Run:  uvicorn app:app --reload
# Now POST to http://localhost:8000/predict — anything can use it.

Step 3: Package it (Docker)

"It works on my machine" is the classic deployment curse — different Python versions, missing libraries, mismatched settings. Docker solves this by packaging your app and its exact environment into a container that runs identically anywhere. You don't need to master it today, but know that most production ML services ship as containers.

Where to host it

For learning and portfolios, Hugging Face Spaces or Streamlit get you a live, shareable link fastest — exactly the "deploy at least one project" advice from Lesson 26.

MLOps: keeping it alive

Deployment isn't the finish line — it's the start of a loop. Unlike normal software, ML systems can decay silently as the world changes. MLOps is the practice of running ML reliably over time:

The essentials of that loop:

• Monitoring: track accuracy, latency and errors in production, not just at training time.
• Versioning: track versions of data, code and models, so you can reproduce and roll back.
• CI/CD for ML: automate testing and redeployment when the model or data changes.
• Retraining: refresh the model on new data on a schedule or when performance drops.

Model drift: why models decay

A model learns patterns from data at one moment in time. When the world shifts — new customer behaviour, new slang, new fraud tactics — the live data drifts away from the training data, and accuracy quietly falls. This is model drift, and it's why deployment without monitoring is dangerous: your model can be failing for weeks before anyone notices. Catching drift and retraining is the heartbeat of MLOps.

The mindset shift: training a model is a project; running one is a process. Deployment is the beginning of that process, not the end.

Early on I thought the hard part of ML was training the model — then my first deployed model quietly got worse over a couple of months and taught me otherwise. Watching that accuracy line drift down while nothing in my code had changed is what made "monitoring and retraining" stop being buzzwords for me. If you deploy anything, set up even a basic check on how it's doing in the wild; future-you will be grateful.

Key takeaways

• A model only creates value once it's deployed — usable by real people or software.
• The core path: save the model → serve it as an API → package (Docker) → host it.
• For demos/portfolios, Hugging Face Spaces or Streamlit give you a live link fastest.
• MLOps keeps it healthy: monitoring, versioning, CI/CD and retraining, as a continuous loop.
• Watch for model drift — models decay as the world changes, so deployment is the start, not the end.

Continue the series: ← Lesson 29: Fine-Tuning LLMs  ·  Next: Lesson 31 — Build a RAG App Step by Step (Hands-On Project) →