01 — Deploy & Serve

Model Packaging & Containers#

Deployment✓ Mathematical
◆ The PatternExporting models into portable, versioned artifacts

A trained model sitting in a notebook is not production-ready. Model packaging wraps your model, its dependencies, and inference code into a self-contained artifact — a Docker image, an ONNX file, or an MLflow model directory — that can be deployed anywhere identically.

Artifact = Model + Dependencies + Inference Code + Config
Packaging ensures every deployment gets the exact same model, libraries, and preprocessing — no "works on my machine" surprises.
// Interactive — packaging pipeline flow
FormatProsBest for
Docker ImageFull environment isolationMicroservice deployments
ONNXFramework-agnostic, optimized runtimeCross-platform inference
MLflow ModelVersioned, metadata-richMLflow ecosystem
BentoML BundleBuilt-in API serverQuick API endpoints
Pickle / JoblibSimple, native PythonPrototyping only
# Python — export model as ONNX + Docker
import onnx, torch

# Export PyTorch model to ONNX
dummy = torch.randn(1, 10)
torch.onnx.export(model, dummy, "model.onnx",
                  input_names=["features"],
                  output_names=["prediction"])

# Dockerfile
# FROM python:3.11-slim
# COPY model.onnx requirements.txt serve.py .
# RUN pip install -r requirements.txt
# CMD ["python", "serve.py"]
Avoid pickle in production: Pickle files are Python-version-specific, not human-readable, and pose security risks (arbitrary code execution). Use ONNX or framework-native formats for anything beyond prototypes.
Pattern bridge: Model packaging is the deployment equivalent of cross-validation — both enforce separation between what you build and where you test it. In markets, backtesting discipline enforces the same boundary.
Open in the full reader, with the topic sidebar →