07 · Serving-платформа7.1–7.7 · Runtime и оркестраторы7.3.1сложный

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 причины)?

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