Зачем это нужно
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 причины)?