AI & Machine Learning Topic
Deploy an ML Model: A Small API with Clear Checks
Deployment makes a model available to another program or a user. A useful deployment also needs valid inputs, a known model version, monitoring and recovery. Putting a notebook behind a URL is only the beginning.
Choose the simplest useful path
Some predictions can run as a scheduled batch. Others need an API response. Start from how quickly the result is needed and how many requests you expect. A live endpoint adds availability and security work that a batch job may not need.
Build a local API
This example uses FastAPI and the Iris teaching model from the supervised-learning lesson. Save supervised.py from that guide beside this file, named model_api.py. Install fastapi, uvicorn and scikit-learn in your practice environment.
from contextlib import asynccontextmanager
from typing import Annotated
from fastapi import FastAPI
from pydantic import BaseModel, ConfigDict, Field
from supervised import train_demo
VERSION = "iris-demo-1"
PositiveMeasurement = Annotated[float, Field(gt=0, le=30, allow_inf_nan=False)]
class Flower(BaseModel):
model_config = ConfigDict(extra="forbid")
measurements: list[PositiveMeasurement] = Field(min_length=4, max_length=4)
@asynccontextmanager
async def lifespan(app):
model, _, _, _, names = train_demo()
app.state.model = model
app.state.names = names
yield
app = FastAPI(lifespan=lifespan)
@app.get("/health")
def health():
return {"status":"ok","model_version":VERSION}
@app.post("/predict")
def predict(flower: Flower):
index = int(app.state.model.predict([flower.measurements])[0])
return {"class_index":index,"flower":str(app.state.names[index]),"model_version":VERSION}
python -m uvicorn model_api:app --host 127.0.0.1 --port 8014
Open http://127.0.0.1:8014/docs for the local API form. This port is separate from the Lecturre website. The model is trained once during startup for this small lab, not on each request. A production service would normally load a reviewed, versioned artifact instead.
Send a prediction
curl http://127.0.0.1:8014/health
curl -X POST http://127.0.0.1:8014/predict -H 'Content-Type: application/json' -d '{"measurements":[5.1,3.5,1.4,0.2]}'
The four numbers mean sepal length, sepal width, petal length and petal width, in centimetres, in that order. The response includes a class index, flower name and model version. The example should predict setosa for these measurements.
Send three values or a negative measurement and the request should be rejected with a validation error. Input bounds here are teaching checks, not a scientifically complete validation policy. A plausible number can still be the wrong unit.
Keep training and serving consistent
The model pipeline includes scaling, so requests use the same learned transformation as training. Record feature order, units, missing-value policy and dependency versions. Save the training-data version and evaluation results with the artifact.
Do not load an untrusted pickle or joblib file. Such files can execute code when loaded. Use trusted artifacts and an appropriate persistence format and verification process for your environment.
What this lab does not provide
It has no public authentication, distributed rate limiting or production traffic controls. Keep it bound to loopback for practice. Before exposing a real endpoint, add appropriate identity, request-size limits, timeouts, transport security and permissions. Run serving code with a suitable deployment setup.
Check predictive quality, latency and error rate after release. Track input changes and missing fields without logging private data unnecessarily. Data drift means input distributions changed; it does not by itself prove accuracy fell. Quality checks need suitable outcomes or reviewed samples.
Release and recovery
Test the exact artifact you will serve. Keep a previous compatible version and define when to roll back. Check compatibility with clients and data preparation. A model rollback cannot undo decisions already made by downstream systems.
Practice
Test the valid request, a missing field and a wrong-length list. Explain what /health can confirm and what it cannot. A healthy process does not prove that new real-world predictions are accurate. Read the DevOps reliability guide for the next operating steps.
Official references
Reviewed on 25 October 2026. Use documentation for your installed versions.
Comments (0)
No comments yet. Be the first to comment!