KServe：标准化模型推理服务

为什么需要 KServe：模型上线的重复劳动 → 标准化交付

传统模型服务上线流程中，每个团队要重复完成四类工作：为不同框架编写镜像与 HTTP 包装层；为每个服务手工配置 Service、Ingress 和 HPA；为灰度发布临时修改流量规则；为监控单独暴露指标端口。当模型数量到达几十个、框架到三四种时，这套「手工操作 + 各自约定」的方式会产生大量维护成本，并且客户端调用格式五花八门，一个模型换框架后调用方就要改代码。

KServe 将上述工作标准化为平台能力。用户只声明 InferenceService 资源，指定模型格式（modelFormat.name）、模型文件地址（storageUri）与弹性策略，KServe 控制器自动创建 Deployment、Service 并接入统一网关。内置模型服务器（sklearnserver、xgboostserver、pytorchserver、tensorflowserver、onnxruntime 等）由 kserve-runtime.yaml 注册为 ServingRuntime，用户提交模型文件即可拉起带健康检查、指标采集和协议转换的推理工作负载，无需自行写 HTTP 服务。对外统一暴露 v2 推理协议，客户端只需适配一套 API。

与同类工具的气质差异在于：Seldon Core 强调推理图与业务流程引擎，Triton 专注 GPU 性能优化，而 KServe 从一开始就为 Kubeflow 这类的 ML 平台提供「开箱即用的标准推理底座」，它解决的问题更多在发布、流量与弹性层，而非单次推理的极致延迟。

安装与环境配置：4 步就绪

前置条件：一个 Kubernetes 集群（1.26+，建议 1.30+），生产环境按 KServe 官方兼容矩阵核对版本。默认安装模式使用 Istio 作为网关，KServe 0.13+ 支持不依赖 Knative 的独立网关模式。以下为 v0.15.0 的安装步骤：

1. 安装 Istio 基础网关（若集群未安装）：

2. 部署 KServe 控制器与 CRD，资源清单来自官方 Release 附件：

3. 部署内置模型运行时（SKLearn、XGBoost、PyTorch、TensorFlow、ONNX、Triton 等）：

4. 验证控制器与 CRD 就绪：

若使用其他版本，将 URL 中的 v0.15.0 替换为对应 tag（见 [GitHub Releases](https://github.com/kserve/kserve/releases/download/v0.15.0/kserve.yaml)）。kserve.yaml 只在 kserve 命名空间部署控制器组件；kserve-runtime.yaml 负责注册各类 ServingRuntime，漏装会导致模型提交后找不到对应运行时。

# 1. 安装 Istio（KServe 默认网关依赖）istioctl install --set profile=default --skip-confirmation # 2. 安装 KServe 控制器与 CRDkubectl apply -f https://github.com/kserve/kserve/releases/download/v0.15.0/kserve.yaml # 3. 安装内置模型运行时kubectl apply -f https://github.com/kserve/kserve/releases/download/v0.15.0/kserve-runtime.yaml # 4. 验证kubectl get pods -n kservekubectl get crd inferenceservices.serving.kserve.io

快速上手：10 分钟跑通 sklearn 推理

最小可用流程是「提交一个 InferenceService → 等待 READY → 从网关发推理请求」。官方用 SKLearn 训练好的 iris 模型演示：模型文件存放在 GCS 公共路径。

1. 提交推理服务，模型格式声明为 sklearn，存储地址指向官方示例模型，副本数默认 1：

2. 查看状态，等待 READY 变为 True，URL 列出现访问地址（形如 http://sklearn-iris.default.example.com，域名取决于网关配置）：

3. 向 /v2/models/sklearn-iris/infer 发送推理请求，请求体遵循 v2 推理协议，声明输入张量的 name、shape、datatype 与 data：

正常响应示例为 {"model_name":"sklearn-iris","outputs":[{"name":"output-0","datatype":"INT64","shape":[2],"data":[1,2]}]}。进阶技巧：将 storageUri 换成自己 S3/GCS/OSS 桶路径即可复用同一份 YAML 部署任意 sklearn 模型；需要 GPU 时在 predictor 中加 tolerations 和 nodeSelector；需要金丝雀发布时给 spec 增加 canaryTrafficPercent 字段。

# 1. 创建 InferenceServicekubectl apply -f - <<EOFapiVersion: serving.kserve.io/v1beta1kind: InferenceServicemetadata:  name: sklearn-irisspec:  predictor:    model:      modelFormat:        name: sklearn      storageUri: gs://kfserving-examples/models/sklearn/1.1EOF # 2. 查看服务状态（等待 READY=True，记录 URL 列）kubectl get inferenceservice sklearn-iris -w # 3. 发送 v2 协议推理请求curl -s -X POST "http://sklearn-iris.default.example.com/v2/models/sklearn-iris/infer" \  -H "Content-Type: application/json" \  -d '{"inputs":[{"name":"input-0","shape":[2,4],"datatype":"FP32","data":[[6.8,2.8,4.8,1.2],[6.0,2.2,5.0,1.5]]}]}'

核心能力详解：5 大支柱

支柱一：InferenceService CRD 声明式编排。InferenceService 是 KServe 的核心抽象，包含 predictor（必选）、transformer（可选，请求前后处理）、explainer（可选，用 Alibi 对结果提供解释）三个组件。控制器根据声明创建对应 Deployment 与 Service，并自动创建 InferenceGraph 可观测入口。

支柱二：多框架内置运行时。通过 ServingRuntime 机制注册模型服务器，目前官方内置 SKLearn、XGBoost、PyTorch、TensorFlow、ONNX Runtime、Triton 等。用户只提供模型文件路径，不必维护镜像；非内置框架可自定义容器镜像实现 KServe 协议接入。

支柱三：v2 推理协议（Open Inference Protocol）。一套与框架无关的推理 API，同时支持 REST 与 gRPC，规定 /v2/models、/v2/models/{model}/infer 等端点的请求响应结构。客户端侧的显式张量描述（shape/datatype/data）使网络传输与后端框架解耦。

支柱四：流量管理与发布。原生支持金丝雀发布，canaryTrafficPercent 指定发往新版本的流量百分比，KServe 自动创建 canary 副本并按权重路由；配合 Istio/网关的流量策略可做逐步放量与快速回滚。

支柱五：弹性与可观测性。支持 Knative autoscaler 与 KServe 原生 autoscaler，可配置并发数、GPU 利用率等指标触发扩缩容，支持缩容到零以节省空闲成本；每个推理工作负载自动暴露 Prometheus /metrics 指标，包括请求数、延迟、GPU 利用率等。

生产部署与监控：从上线到运维

部署方式一：自建 Kubernetes + 网关。在自建集群上安装 Istio（或 KServe 0.13+ 支持的独立网关），随后按上文安装 KServe。建议将安装清单纳管进 GitOps 流程，把 kserve.yaml、kserve-runtime.yaml 的版本固定为 Release tag，升级采用「先集群兼容性检查、再按序替换清单」的策略。

部署方式二：云上 Kubernetes + 对象存储。EKS/GKE/ACK 等托管集群上安装 KServe 后，将模型统一存放在 S3/GCS/OSS，通过 storageUri 引用并设置密钥挂载。需要 GPU 时配合云厂商的 Node Pool 与 taint/toleration 将推理 Pod 调度到 GPU 节点，并将云监控对接到 Prometheus 体系。Kubeflow 用户可在 Kubeflow 内一键安装 KServe，获得统一 Dashboard 管理入口。

可观测性。KServe 暴露三类观测面：每个 Pod 的 Prometheus 指标端点（请求数、延迟、批处理大小、GPU 指标）；标准 stdout 日志（建议接入 EFK/Loki 收集）；网关层访问日志（用于追踪每一条推理请求的流量切分情况）。生产环境至少配置三类告警：服务不可用（Pod 多次重启）、P95 延迟超阈值、GPU/CPU 利用率持续高位未扩容。

<p class="para-label">避坑清单：</p>

<ul class="dash-list"><li>版本匹配：KServe 各版本对 Kubernetes 版本有要求，安装前必须对照官方兼容表，K8s 太旧会导致 Webhook 注册失败。</li><li>漏装 kserve-runtime.yaml：只有控制器没有 ServingRuntime 时，InferenceService 会一直卡在 Pending，报错提示找不到对应运行时。</li><li>默认网关依赖：0.13 之前默认安装绑定 Knative，若你按旧教程部署并升级，需要先清理 Knative 相关资源再切换独立网关模式。</li><li>外部访问域名：生产环境需在网关层配置自定义域名与证书，默认 .example.com 域名无法真正对外提供服务。</li></ul>

版本迭代

KServe 的演进主线是「从 Kubeflow 附属走向独立基础设施」——逐步弱化对 Knative 的强依赖、强化 v2 协议与 ServingRuntime 机制、持续跟随 Kubernetes 版本更新。（截至训练数据，最新正式版为 v0.15.0，安装请以官方 Releases 为准。）

AI 应用场景

常见误区

面试题

参考来源

• webpageKServe 官方网站官方文档、快速开始与 API 参考入口
• webpageKServe GitHub 仓库源码、示例与贡献指南