Principle:SeldonIO Seldon core Monitoring Component Deployment

Property	Value
Principle Name	Monitoring Component Deployment
Overview	Deploying classifier, preprocessor, drift detector, and outlier detector as independent model components for a monitoring pipeline
Domains	MLOps, Kubernetes
Related Implementation	SeldonIO_Seldon_core_Seldon_Model_Load_For_Monitoring
Knowledge Sources	Repo (https://github.com/SeldonIO/seldon-core), Doc (https://docs.seldon.io/projects/seldon-core/en/v2/)
Last Updated	2026-02-13 00:00 GMT

Description

A production monitoring pipeline requires four independently deployed models:

Classifier (income) - The main inference model producing predictions
Preprocessor (income-preprocess) - Transforms raw features into the format expected by detectors
Drift Detector (income-drift) - Tests for distribution shift using batched requests
Outlier Detector (income-outlier) - Flags anomalous individual inputs

Each model uses a different MLServer runtime:

sklearn runtime for the classifier and preprocessor (scikit-learn models serialized with joblib)
alibi-detect runtime for the drift and outlier detectors (alibi-detect models serialized with save_detector)

All four components must be loaded and ready before the pipeline can be created and activated.

Decomposing monitoring into independent services follows the microservices pattern. This architecture provides several advantages:

Independent scaling - Each detector has different compute and memory requirements. The VAE-based outlier detector may need GPU resources, while the drift detector primarily needs CPU for statistical tests.
Selective updates - Retraining the drift detector (e.g., with updated reference data) does not require redeploying the classifier or outlier detector.
Fault isolation - If the outlier detector fails, the classifier continues producing predictions. Monitoring degradation does not cause inference degradation.
Runtime heterogeneity - Different model frameworks (sklearn, alibi-detect, TensorFlow) can coexist through MLServer's pluggable runtime architecture.

Each model is defined as a Seldon Model CRD (Custom Resource Definition) with:

The Seldon scheduler handles downloading artifacts, instantiating the correct runtime, and registering the model for inference.

Use this principle when setting up a production monitoring pipeline with drift and outlier detection capabilities. The deployment sequence is:

Upload trained model artifacts to cloud storage (GCS, S3, or local)
Define a Model CRD YAML for each component specifying storageUri and requirements
Load each model using the seldon CLI
Wait for all models to reach ModelAvailable state
Proceed to pipeline definition

SeldonIO_Seldon_core_Seldon_Model_Load_For_Monitoring (implements this principle) - Concrete CLI tool for deploying monitoring pipeline component models
SeldonIO_Seldon_core_Drift_And_Outlier_Detection_Training (prerequisite) - Training the detectors that will be deployed
SeldonIO_Seldon_core_Alibi_Detect_Training (produces artifacts) - Concrete training code that produces the model artifacts
SeldonIO_Seldon_core_Monitoring_Pipeline_Definition (next step) - Composing deployed components into a monitoring pipeline
SeldonIO_Seldon_core_Model_Resource_Definition (related principle) - General model resource definition concepts

Double-click a node to navigate. Hold to expand connections.

Principle

Implementation

Heuristic

Environment