Principle:SeldonIO Seldon core Component Model Deployment

Field	Value
Principle Name	Component Model Deployment
Overview	The process of deploying multiple individual models as building blocks for a multi-step inference pipeline.
Domains	MLOps, Kubernetes
Related Implementation	Implementation:SeldonIO_Seldon_core_Seldon_Model_Load_For_Pipeline
Last Updated	2026-02-13 00:00 GMT

Description

Before a pipeline can be created, all component models referenced in its steps must be deployed and available. Each model is independently loaded via its Model CRD, and the pipeline references them by name. In Seldon Core 2, the Model custom resource defines everything the scheduler needs to fetch, load, and serve a model: the storage URI, framework requirements, and resource constraints. Each model is loaded onto an inference server that matches its requirements (e.g., Triton for TensorFlow models).

The pipeline topology references models by their metadata.name field. The scheduler must report each referenced model as ModelAvailable before the pipeline can transition to PipelineReady. This decoupling means models can be versioned, scaled, and updated independently of the pipelines that consume them.

Theoretical Basis

Pipeline systems decompose complex inference into independent, composable model services. Each service is deployed independently, enabling horizontal scaling, independent versioning, and fault isolation. This follows the microservices architecture pattern applied to ML inference:

• Single Responsibility: Each model serves one inference function (e.g., feature extraction, classification, post-processing).
• Independent Deployment: Models can be updated, rolled back, or scaled without affecting other pipeline components.
• Fault Isolation: If one model fails or becomes unavailable, other models in the system remain operational. The pipeline itself will report an unhealthy state, but unrelated pipelines are unaffected.
• Resource Optimization: Each model declares its own resource requirements (memory, GPU), allowing the scheduler to bin-pack models efficiently across inference servers.

This design is analogous to Unix pipelines where small, focused tools are composed into complex workflows, but applied to ML inference with Kubernetes-native resource management and Kafka-based data flow.

When to Use

Use this principle when setting up the prerequisite models for a Seldon Core 2 Pipeline. Specifically:

• When deploying a new inference pipeline that references multiple models.
• When adding a new model step to an existing pipeline.
• When replacing or upgrading a model version that is consumed by one or more pipelines.
• When pre-loading models across inference servers before pipeline activation.

Structure

The typical deployment sequence for component models is:

1. Define each model as a Model CRD YAML manifest specifying storageUri, requirements, and memory.
2. Load each model using seldon model load -f <model.yaml>.
3. Verify each model reaches ModelAvailable status using seldon model status <modelName> -w ModelAvailable.
4. Proceed to pipeline definition and deployment only after all component models are confirmed available.

Related Pages

• Implementation:SeldonIO_Seldon_core_Seldon_Model_Load_For_Pipeline - implements - Concrete CLI tool for deploying multiple component models as pipeline prerequisites.
• Principle:SeldonIO_Seldon_core_Pipeline_Topology_Definition - related principle - Declarative specification of DAG topologies that reference these deployed models.
• Principle:SeldonIO_Seldon_core_Pipeline_Deployment_Execution - next step - Deploying and activating the pipeline after all models are loaded.

Implementation:SeldonIO_Seldon_core_Seldon_Model_Load_For_Pipeline