Machine Learning Model Serving
Machine learning model serving is the infrastructure and practice of deploying trained models so they can receive input data and return predictions in real time or in batch. It bridges the gap between a model that works in a notebook and one that runs reliably in production at scale.
itArtificial intelligence and machine learning | OpenSkills.info
Intro
Machine Learning Model Serving
Training a model is half the job. The other half is making that model available to applications that need its predictions. Model serving is the infrastructure layer that takes a trained model artifact and exposes it as a service — accepting input, running inference, and returning results with the reliability, latency, and throughput that production systems demand.
Why model serving is a distinct discipline
A model in a Jupyter notebook runs on one machine, processes one request at a time, and has no availability requirement. A model in production must handle concurrent requests, meet latency SLAs, survive hardware failures, scale under load, manage multiple model versions, and integrate with the rest of your software architecture.
These requirements push model serving beyond "export and call the predict function." You need standardized APIs, request batching, hardware-aware optimization, load balancing, versioning, canary deployments, and observability — the same concerns that exist for any production service, plus ML-specific concerns like model warmup, dynamic batching, and framework compatibility.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://www.tensorflow.org/tfx/serving/architecture
Supports
- TensorFlow Serving is a flexible, high-performance serving system for machine learning models designed for production environments
- https://github.com/tensorflow/serving
Supports
- TensorFlow Serving provides versioned access to models via a high-performance, reference-counted lookup table
- https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/
Supports
- NVIDIA Triton Inference Server supports TensorFlow, PyTorch, ONNX, TensorRT, and custom backends with dynamic batching
- https://docs.aws.amazon.com/sagemaker/latest/dg/deploy-model.html
Supports
- Amazon SageMaker provides a broad selection of ML infrastructure and model deployment options for real-time and batch inference
- https://cloud.google.com/vertex-ai/docs/general/deployment
Supports
- Vertex AI requires deploying a model to an endpoint before getting online predictions
- https://www.tensorflow.org/tfx/serving/serving_basic
Supports
- SavedModel format saves a snapshot of the trained model to reliable storage for later inference loading
- https://www.tensorflow.org/tfx/serving/architecture
Supports
- Dynamic batching groups multiple incoming requests into a single forward pass to maximize GPU utilization
- https://docs.vllm.ai/en/latest/
Supports
- vLLM uses PagedAttention for efficient KV cache memory management in LLM serving
- https://onnxruntime.ai/docs/
Supports
- ONNX Runtime is a cross-platform inference engine optimized for models exported to the ONNX format
- https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/
Supports
- Quantization reduces numerical precision (e.g., FP32 to INT8) to decrease memory footprint and accelerate inference
- https://docs.aws.amazon.com/sagemaker/latest/dg/deploy-model.html
Supports
- Canary deployment routes a small fraction of traffic to a new model version while the old version handles the rest
- https://kserve.github.io/website/
Supports
- KServe provides Kubernetes-based serverless inference with autoscaling including scale-to-zero
- https://www.tensorflow.org/tfx/serving/architecture
Supports
- Model serving requires handling concurrent requests, meeting latency SLAs, managing versions, and integrating with software architecture
