企业官网建设流程全解析

• 人工智能
• 大模型
• MLOps
• LLMOps
• 模型推理服务
• 云原生
• 后端

本篇技术指南面向使用 Seldon Core 2 部署机器学习模型的工程师，系统讲解"推理制品（Inference Artifacts）"从训练产物到线上推理的完整链路：Seldon Core 2 支持哪些制品类型、各类模型应保存为什么格式、如何通过 Model 资源的requirements标签把制品正确调度到 MLServer 或 Triton 推理服务器上，以及何时需要自定义model-settings.json或config.pbtxt。读完本文，你将能把自己的 SKLearn、XGBoost、PyTorch、TensorFlow、HuggingFace 等模型制品一键部署到 Seldon Core 2，并理解其背后的"制品下载—能力匹配—模型加载"调度原理。

一、推理制品与两大推理引擎

在 Seldon Core 2 中，要让模型在线上运行，必须提供一个可被下载并在推理服务器上执行的推理制品（inference artifact）。Seldon Core 2 内置的两类推理服务器分别为：

• MLServer：以 Python 生态为主，支持 SKLearn、XGBoost、LightGBM、MLFlow、HuggingFace、Alibi-Detect / Alibi-Explain 以及自定义 Python 模型；
• Triton Inference Server：以高性能推理为主，支持 ONNX、PyTorch、TensorFlow、TensorRT、OpenVINO、DALI、FIL 以及自定义 Triton Python 模型。

从源码结构看，两类服务器在集群内的定义分别对应 MLServer ServerConfig 与 Triton ServerConfig。每个 ServerConfig 都通过环境变量SELDON_SERVER_CAPABILITIES声明了该服务器具备的"能力标签（capabilities）"，例如 MLServer 声明了：

mlserver,alibi-detect,alibi-explain,huggingface,lightgbm,mlflow,python,sklearn,spark-mlib,xgboost

而 Triton 声明了：

triton,dali,fil,onnx,openvino,python,pytorch,tensorflow,tensorrt

这两个能力列表与下文"制品类型总表"中的 Tag 一一对应——这正是制品得以被正确加载到兼容服务器的关键。

二、支持的推理制品类型总表

Seldon Core 2 按字母序支持的推理制品类型如下表所示，其中 Tag 一列即制品在Model资源requirements中需要填写的标签，Example 指向仓库中可复用的示例：

可以看到：多数经典训练框架的制品都已被官方支持，仓库 samples/models 目录下也存放了大量对应的可直接使用的 Model 资源示例，例如 mnist-onnx.yaml、mnist-pytorch.yaml、tfsimple1.yaml、cifar10.yaml、hf-sentiment.yaml、wine-mlflow.yaml 与 income-lgb.yaml。

三、requirements 标签：制品与服务器的"能力匹配"机制

tag字段代表你需要在Model资源的requirements部分添加的标签，用于让制品被加载到兼容的服务器上。以 SKLearn 模型为例：

# samples/models/sklearn-iris-gs.yaml apiVersion: mlops.seldon.io/v1alpha1 kind: Model metadata: name: iris spec: storageUri: "gs://seldon-models/scv2/samples/mlserver_1.6.0/iris-sklearn" requirements: - sklearn memory: 100Ki

3.1 底层匹配原理

从源码看，requirements的匹配逻辑位于调度器的 ServerRequirementsFilter：调度器会遍历模型声明的每个 requirement，并检查候选服务器的 replica 能力集合是否全部包含这些 requirement，只有全部满足的服务器才会被选为模型的宿主。

而在 CRD 层面，ModelSpec 中Requirements []string字段的注释明确写道："List of extra requirements for this model to be loaded on a compatible server"（模型加载到兼容服务器所需的额外需求列表）。也就是说，requirements本质上是一组"能力断言"，调度器据此把模型制品路由到具备对应 capabilities 的服务器。

值得注意的两个补充细节（均可从 AsSchedulerModel 转换逻辑确认）：

• 若在spec中显式填写了modelType字段，它会被自动追加到requirements列表尾部；
• 若填写了server字段（例如server: mlserver-134，见 iris-custom-server.yaml），则制品会被直接调度到指定名称的服务器，而不依赖能力匹配。

3.2 一个更完整的实际示例

XGBoost 模型部署示例（取自 model-zoo 文档）：

apiVersion: mlops.seldon.io/v1alpha1 kind: Model metadata: name: income-xgb spec: storageUri: "gs://seldon-models/scv2/samples/mlserver_1.3.5/income-xgb" requirements: - xgboost

提交并等待就绪：

kubectl apply -f ./models/income-xgb.yaml -n ${NAMESPACE} kubectl wait --for condition=ready --timeout=300s model income-xgb -n ${NAMESPACE}

随后即可通过 Seldon 推理入口按 KServe v2 协议发起推理：

curl --location 'http://${SELDON_INFER_HOST}/v2/models/income-xgb/infer' \ --header 'Content-Type: application/json' \ --data '{ "parameters": {"content_type": "pd"}, "inputs": [{"name": "Age", "shape": [1, 1], "datatype": "INT64", "data": [47]},{"name": "Workclass", "shape": [1, 1], "datatype": "INT64", "data": [4]},{"name": "Education", "shape": [1, 1], "datatype": "INT64", "data": [1]},{"name": "Marital Status", "shape": [1, 1], "datatype": "INT64", "data": [1]},{"name": "Occupation", "shape": [1, 1], "datatype": "INT64", "data": [1]},{"name": "Relationship", "shape": [1, 1], "datatype": "INT64", "data": [3]},{"name": "Race", "shape": [1, 1], "datatype": "INT64", "data": [4]},{"name": "Sex", "shape": [1, 1], "datatype": "INT64", "data": [1]},{"name": "Capital Gain", "shape": [1, 1], "datatype": "INT64", "data": [0]},{"name": "Capital Loss", "shape": [1, 1], "datatype": "INT64", "data": [0]},{"name": "Hours per week", "shape": [1, 1], "datatype": "INT64", "data": [40]},{"name": "Country", "shape": [1, 1], "datatype": "INT64", "data": [9]}]}'

四、保存模型制品：按类型选择正确的保存格式

对大多数机器学习制品而言，只需将模型保存到一个文件夹中，即可直接加载进 Seldon Core 2。下表汇总了各类型制品的保存要点；当默认规则无法满足需求时，可以按表格中的 Custom Model Settings 指引创建自定义模型设置文件（详见后文两个章节）：

4.1 制品保存格式在源码中的印证

上述扩展名约定并非文档空谈，而是直接编码在 MLServer 制品处理逻辑中。在 scheduler/pkg/agent/repository/mlserver/settings.go 里可以看到：

var ( sklearnExtensions = []string{"joblib", "pkl", "pickle"} xgboostExtensions = []string{"json", "bst"} lightgbmExtensions = []string{"bst"} )

agent 会在模型目录中按这些扩展名查找制品文件，并据此自动生成对应的model-settings.json：

• SKLearn：在目录中匹配*.joblib/*.pkl/*.pickle，生成Implementation: "mlserver_sklearn.SKLearnModel"；
• XGBoost：匹配*.json/*.bst，生成Implementation: "mlserver_xgboost.XGBoostModel"；
• LightGBM：匹配*.bst，生成Implementation: "mlserver_lightgbm.LightGBMModel"；
• Alibi-Detect：生成Implementation: "mlserver_alibi_detect.AlibiDetectRuntime"；
• Alibi-Explain：在目录中寻找保存了解释器模型的子文件夹，生成Implementation: "mlserver_alibi_explain.AlibiExplainRuntime"；
• MLFlow：直接以目录根作为模型 URI，生成Implementation: "mlserver_mlflow.MLflowRuntime"；
• 自定义 Python：扫描目录下所有.py文件，用正则.*class (.*)\(MLModel\):找出继承MLModel的类，自动生成对应Implementation与Uri。

也就是说，对于大多数 MLServer 系模型，你只需要按上表格式保存制品，agent 在下载制品后会自动补齐加载配置，无需手工编写。

五、Custom MLServer Model Settings：手写 model-settings.json

针对 MLServer 系的模型，你可以创建model-settings.json文件并放在制品旁边，帮助 MLServer 正确加载模型。当制品格式超出上述自动识别规则（例如 HuggingFace 需要声明任务类型、自定义 Python 需要指定具体类）时，这个文件就是必选项。

一个典型的model-settings.json结构（字段含义可参考 MLServer 的 Model Settings 参考文档）：

{ "name": "my-model", "implementation": "mlserver_sklearn.SKLearnModel", "parameters": { "uri": "./iris.joblib", "version": "v1" } }

核心字段说明：

• name：模型名称，会作为推理请求中的模型标识；
• implementation：MLServer runtime 的完整类路径，决定了使用哪种 runtime 加载制品；
• parameters.uri：制品在模型目录中的相对路径，例如./iris.joblib、./model.onnx；
• parameters.version：模型版本标识。

以 HuggingFace 为例（可参考 huggingface 示例文档），需要在model-settings.json中声明 HuggingFace 模型所需的信息，再配合 Model 资源中的requirements: [huggingface]使用；仓库中的 hf-sentiment.yaml 与 hf-whisper.yaml 都是可直接参考的成品示例。

六、Custom Triton Configuration：手写 config.pbtxt

针对 Triton 推理服务器系的模型，你需要在制品旁边创建 config.pbtxt 来描述模型。Triton 的模型仓库采用"每个模型一个文件夹 + 版本号子文件夹"的布局，典型结构如下：

models/ └── my_model/ ├── 1/ │ ├── model.pt # 或 model.onnx / model.savedmodel 等 │ └── (其他后端要求的文件) └── config.pbtxt

config.pbtxt中需要声明：

• name：模型名称；
• backend：使用的后端类型（如pytorch、onnxruntime、tensorflow、python）；
• input/output：每个输入输出张量的name、data_type、dims；
• max_batch_size：允许的最大批量大小；
• platform（旧版本字段）或backend（新版本字段）：后端标识。

以 PyTorch 为例：你需要创建描述输入输出的 Tritonconfig.pbtxt，并将 traced torchscript 以model.pt放入编号子文件夹（通常为1/）。对于 ONNX，将模型保存为model.onnx即可（示例见 mnist-onnx.yaml）；对于 TensorFlow，使用 "Saved Model" 格式保存为model.savedmodel，若使用 graphdef 格式则需创建config.pbtxt并将模型放入编号子文件夹，注意HDF5 格式不受支持。

七、制品存储、版本与下载流程

Model 资源通过spec中内联的InferenceArtifactSpec描述制品来源（定义见 model_types.go）：

存储相关的几种典型写法均可在 samples/models 中找到：

• GCS 公有桶：sklearn-iris-gs.yaml（storageUri: "gs://seldon-models/scv2/samples/mlserver_1.6.0/iris-sklearn"）；
• 本地路径：sklearn-iris-local.yaml（storageUri: "/mnt/models/iris"）；
• S3 + Secret：sklearn-iris-minio.yaml（storageUri: "s3://models/iris"+secretName: "minio-secret"）。

在下载环节，从源码看，agent 会为每个模型启动一个名为 "Model Repository (rclone)" 的子服务，通过 rclone 把制品从storageUri拉取到本地模型目录（见 agent_svc_manager.go 与 agent_svc_manager_test.go 中的 rclone 配置与 Secret 处理测试用例）。若secretName被指定，其内容会作为 rclone 的存储配置用于认证；下载完成后，agent 再依据requirements生成加载配置并交给 MLServer / Triton 加载。这也解释了为何本地模型的 sklearn-iris-local.yaml 中只需填写storageUri与requirements两个字段即可完成一次最小化部署。

八、从制品到就绪：一次完整的部署串联

将以上各环节串联起来，一次完整的推理制品部署流程为：

1. 保存制品：按第四节表格，把训练产物保存为对应格式并上传到storageUri指向的存储位置；
2. 编写 Model 资源：填写storageUri、requirements（必要时加memory、secretName、server等字段）；
3. 提交资源：kubectl apply -f model.yaml或使用seldon model load -f model.yaml；
4. 调度匹配：调度器依据 ServerRequirementsFilter 将模型路由到 capabilities 覆盖全部 requirements 的服务器；
5. 制品下载：agent 通过 rclone 拉取制品，并按需自动生成model-settings.json（MLServer）或利用已有的config.pbtxt（Triton）；
6. 加载就绪：推理服务器加载模型，kubectl wait --for condition=ready ... model <name>等待就绪后即可通过/v2/models/<name>/infer发起推理。

对自定义制品（自定义 MLServer Python 类或自定义 Triton Python backend），核心差异仅在第一步：前者需编写继承MLModel的 Python 文件，后者需按 Triton 规范编写config.pbtxt与 backend 脚本。仓库 samples/models 与 docs-gb/examples 下的各示例文档（如 income、pandasquery、cifar10、model-zoo）提供了从训练脚本到部署推理的端到端可运行参考，可直接作为落地模板使用。

• 人工智能
• 大模型
• MLOps
• LLMOps
• 模型推理服务
• 云原生
• 后端