7.3.1 · блок 7

Seldon Core как оркестратор

Зачем это нужно

MLServer обслуживает одну модель в Pod. Этот урок показывает legacy Seldon Core 1: Kubernetes operator для ML graphs с CRD SeldonDeployment. Для новых production-систем выбирайте Seldon Core 2 или KServe как golden path; Core 1 оставляйте для миграции и поддержки существующих установок. Это оркестратор inference, не замена Triton для GPU batching.

MLOps-инженер выбирает Seldon, когда нужны multi-step pipelines на inference без написания custom gateway.

Основные идеи

Seldon vs plain Deployment.

| Возможность | Deployment | Seldon Core |

|-------------|------------|-------------|

| Single model REST | ✓ | ✓ |

| Pre/post processing chain | manual | graph spec |

| A/B, canary traffic split | manual Istio | built-in |

| Multi-model ensemble | hard | declarative |

| Standard metrics | DIY | default Prometheus |

SeldonDeployment — legacy Core 1 example. Ниже — пример для миграции существующего Core 1, не шаблон для нового greenfield production.


apiVersion: machinelearning.seldon.io/v1
kind: SeldonDeployment
metadata:
  name: churn
  namespace: ml-prod
spec:
  name: churn
  predictors:
    - name: default
      graph:
        name: classifier
        type: MODEL
        implementation: SKLEARN_SERVER
        modelUri: "s3://ml-models/churn/v44/"
      componentSpecs:
        - spec:
            containers:
              - name: classifier
                resources:
                  limits:
                    memory: 1Gi
      replicas: 2
      traffic: 100

Graph node types.

MODEL — inference (MLServer, TensorFlow, custom).
TRANSFORMER — input transform.
ROUTER — split traffic (AB test).
COMBINER — ensemble aggregation.
OUTPUT_TRANSFORMER — post-process response.

Traffic management. Несколько predictors с traffic: 90 / traffic: 10 — canary без ручного VirtualService (Istio integration optional).

Protocol. REST и gRPC; Seldon microservice API или V2 inference если runtime supports.

Operator pattern. Seldon controller watches CRD → создаёт Deployments, Services, ConfigMaps. GitOps: SeldonDeployment YAML в repo → Argo sync.

Explainer (optional). Anchor, SHAP — отдельный container in graph; latency ↑, use for debug not every request.

Limitations (честно).

Для новых production-развёртываний используйте Seldon Core 2 или KServe; Core 1 SeldonDeployment — legacy и требует отдельного migration plan.
Complex graphs harder to debug than plain code.
LLM serving — чаще vLLM + KServe напрямую, не Seldon graph.

When to pick Seldon Core 1. Legacy install, migration или существующая команда с этим стеком. Для greenfield выберите Seldon Core 2 либо KServe; KServe — golden path курса для обычного Kubernetes serving.

Как это выглядит на практике

Pipeline: transform → predict → transform


graph:
  name: churn-transformer
  type: TRANSFORMER
  implementation: SKLEARN_SERVER
  modelUri: "s3://ml-models/churn/preprocess/v2/"
  children:
    - name: classifier
      type: MODEL
      implementation: SKLEARN_SERVER
      modelUri: "s3://ml-models/churn/v44/"

Canary release v44 → v45:


predictors:
  - name: v44
    traffic: 90
    graph: { ... modelUri v44 ... }
  - name: v45
    traffic: 10
    graph: { ... modelUri v45 ... }

Monitor error rate / business metric → shift traffic in Git.

Metrics. Default seldon_api_executor_client_requests_seconds etc. — dashboards in module 5.

Install on MDP (legacy). Helm seldon-core-operator in platform namespace; teams deploy SeldonDeployment in ml-*.

Что сделать после занятия

[ ] Нарисуйте graph: transformer → model для capstone preprocessing.
[ ] Объясните, как SeldonDeployment связан с Pod'ами Kubernetes.
[ ] Когда вы бы выбрали KServe вместо Seldon (2 причины)?

Официальные материалы

Открыть интерактивную версию