ML Model Serving

Model serving is the production stage where a trained model answers prediction requests. An inference server (e.g. NVIDIA Triton, TorchServe, TensorFlow Serving, KServe) loads the model, exposes an endpoint, and handles incoming inputs, returning predictions with low latency and high throughput. Serving concerns differ sharply from training: you care about latency percentiles, throughput, autoscaling, versioning, and cost-per-inference rather than training loss. Serving is where the model actually delivers business value, so reliability and performance here are critical.

Dynamic batching exploits the fact that GPUs are far more efficient processing a batch than single inputs one at a time. The server waits a tiny window (e.g. a few milliseconds) to collect concurrent requests, then runs them as one batch through the model. This dramatically increases throughput and GPU utilization. The trade-off is a small added latency from the batching window. Servers expose tunables for max batch size and max wait time so you can balance throughput against your latency SLO.

A model registry (e.g. MLflow Model Registry, SageMaker Model Registry) is the system of record for trained models. It versions each model, stores metadata — training metrics, data lineage, hyperparameters, the code/commit that produced it — and tracks lifecycle stages (e.g. Staging, Production, Archived). It enables governed promotion ("promote v7 to production"), reproducibility, rollback to a prior version, and audit. The registry decouples which model is in production from the serving infrastructure, so deployments become a controlled metadata change.

Champion/challenger safely evaluates a new model against the incumbent on live traffic. The champion serves production; the challenger receives a copy of (or a slice of) traffic, and its predictions are scored against actual outcomes. If the challenger demonstrably outperforms the champion on the metrics that matter, it is promoted to champion. This is the ML analog of A/B testing or canary deployment, and it guards against the common failure where a model that looked better offline performs worse on real production data.

Model drift is the silent degradation of a deployed model as the world changes. Data drift means the input distribution shifts (new user behavior, seasonality); concept drift means the relationship between inputs and the target changes (e.g. fraud patterns evolve). A model that was accurate at launch can quietly become wrong. Because the model code did not change, only monitoring of live inputs and outcomes catches it: tracking prediction distributions, input statistics, and (where available) ground-truth feedback. Detected drift triggers retraining or rollback.