Implementation:SeldonIO Seldon core Seldon Model Load For Experiment

Field	Value
Type	External Tool Doc
Overview	Concrete CLI tool for deploying candidate model variants for Seldon Core 2 experiments.
Domains	MLOps, Experimentation
Related Principle	SeldonIO_Seldon_core_Candidate_Model_Deployment
Source	samples/models/sklearn1.yaml:L1-8, samples/models/sklearn2.yaml:L1-8, samples/local-experiments.md:L42-63
Knowledge Sources	Repo, Doc
Last Updated	2026-02-13 00:00 GMT

Description

This implementation provides the concrete steps for deploying candidate model variants in preparation for A/B testing or traffic mirroring experiments in Seldon Core 2. Each candidate model is defined as a Kubernetes custom resource of kind Model and loaded via the seldon model load CLI command.

Code Reference

Candidate Model 1: iris (sklearn1.yaml)

apiVersion: mlops.seldon.io/v1alpha1
kind: Model
metadata:
  name: iris
spec:
  storageUri: "gs://seldon-models/mlserver/iris"
  requirements:
  - sklearn

Candidate Model 2: iris2 (sklearn2.yaml)

apiVersion: mlops.seldon.io/v1alpha1
kind: Model
metadata:
  name: iris2
spec:
  storageUri: "gs://seldon-models/mlserver/iris"
  requirements:
  - sklearn

CLI Commands

# Load candidate model 1
seldon model load -f sklearn1.yaml

# Load candidate model 2
seldon model load -f sklearn2.yaml

# Verify model readiness
seldon model status iris -w ModelAvailable
seldon model status iris2 -w ModelAvailable

I/O Contract

Direction	Description
Inputs	Model CRD YAML files for each candidate variant. Each file must define apiVersion, kind: Model, metadata.name, spec.storageUri, and spec.requirements.
Outputs	Two or more models loaded and ready for experimentation. Each model is registered with the Seldon scheduler and available for inference at its named endpoint.

Key Parameters

Parameter	Description	Required
metadata.name	Unique name for the candidate model	Yes
spec.storageUri	URI to the model artifact (GCS, S3, local)	Yes
spec.requirements	Runtime dependencies (e.g., sklearn, xgboost)	Yes
-f / --file-path	Path to the model YAML manifest (CLI flag)	Yes
--scheduler-host	Scheduler address (default 0.0.0.0:9004)	No

Usage Examples

Basic: Load Two sklearn Candidates

# Load both candidates sequentially
seldon model load -f samples/models/sklearn1.yaml
seldon model load -f samples/models/sklearn2.yaml

# Wait for both to be available
seldon model status iris -w ModelAvailable
seldon model status iris2 -w ModelAvailable

Using kubectl

# Apply model manifests via kubectl
kubectl apply -f samples/models/sklearn1.yaml
kubectl apply -f samples/models/sklearn2.yaml

# Check model status
kubectl get models iris iris2

Custom Model Candidates

# candidate-v1.yaml
apiVersion: mlops.seldon.io/v1alpha1
kind: Model
metadata:
  name: my-model-v1
spec:
  storageUri: "gs://my-bucket/models/v1"
  requirements:
  - sklearn
---
# candidate-v2.yaml
apiVersion: mlops.seldon.io/v1alpha1
kind: Model
metadata:
  name: my-model-v2
spec:
  storageUri: "gs://my-bucket/models/v2"
  requirements:
  - sklearn

External Dependencies

• seldon CLI — Command-line tool for interacting with Seldon Core 2 scheduler
• kubectl — Kubernetes CLI for applying CRD manifests
• Seldon scheduler — Orchestrates model loading and readiness
• GCS storage (or S3, local) — Hosts model artifacts referenced by storageUri

Related Pages

• SeldonIO_Seldon_core_Candidate_Model_Deployment — principle for this implementation — Deploying multiple model variants as candidates for A/B testing or traffic mirroring experiments.
• SeldonIO_Seldon_core_Seldon_Experiment_CRD — next step — Declaring the Experiment resource that references these candidates.
• SeldonIO_Seldon_core_Seldon_Experiment_Start — next step — Starting the experiment after candidates are loaded.