模型推理服务怎样运行在 Kubernetes：版本、KServe、灰度与回滚

1. 训练成功以后，模型还不能直接上线

训练任务完成时，平台得到一个模型产物。它可能在离线评估中达到预期，也可能已经通过人工检查。真正对外提供推理，还要补齐运行镜像、预处理、资源、网络和发布策略。

text9 行

Training Job
  → Model Artifact
  → Model Version
  → Release Approval
  → KServe InferenceService
  → Predictor Pod
  → Request / Response
  → Trace / Metrics
  → Evaluation

因此，“训练成功”“模型可发布”“推理实例 Ready”“业务流量已经切换”应该是不同状态。

2. 模型版本需要包含完整运行契约

只保存一个权重路径不够。推理结果还取决于：

text8 行

权重和配置
模型格式与框架版本
Tokenizer 或图像预处理
输入输出 Schema
运行镜像摘要
CPU / GPU / 内存需求
批处理与超时配置
来源训练任务和数据版本

可以让 ModelVersion 保存这些内容的引用和校验值，让 DeploymentRevision 表达一次具体发布：

text11 行

ModelVersion v12
  ├─ artifact_uri
  ├─ runtime_image_digest
  ├─ input_schema_version
  └─ evaluation_id

DeploymentRevision r31
  ├─ environment: staging
  ├─ model_version: v12
  ├─ resource_profile: gpu-small
  └─ status: READY

同一模型版本可以发布到测试和生产环境，两个环境的资源和流量状态分别记录。

3. KServe 把推理服务变成 Kubernetes 资源

KServe 使用 CRD 描述模型推理工作负载。控制面根据 InferenceService 创建 Kubernetes Deployment、Service 和网络资源，数据面负责接收推理请求。

下面是省略大量配置后的示例：

yaml13 行

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: vision-model-v12
spec:
  predictor:
    model:
      modelFormat:
        name: onnx
      storageUri: s3://model-registry/vision/v12/
      resources:
        limits:
          nvidia.com/gpu: "1"

URI、格式和 GPU 数量仅用于说明资源关系。实际清单要匹配 KServe 版本、ServingRuntime、存储凭据和模型需求。

Java 平台不必自己创建所有 Deployment 细节。它可以根据经过校验的模板生成或更新 InferenceService，再同步 CRD 状态到发布记录。

4. Ready 必须等模型真正可用

大型模型容器启动后还要下载或挂载模型、分配显存并加载权重。进程已经监听端口时，模型可能仍不能处理请求。

Kubernetes 的探针解决不同问题：

探针	推理服务中要回答的问题
startupProbe	较长的模型加载阶段是否结束
readinessProbe	当前实例能否接受新请求
livenessProbe	进程是否进入需要重启的状态

Readiness 应覆盖模型加载和必要依赖。Liveness 不宜因为短时高负载就频繁杀死实例，否则可能形成反复加载模型的故障循环。

平台还要区分：

text6 行

资源已创建
Pod 已调度
容器已启动
模型已加载
路由已生效
验证请求已通过

只有完成约定的发布门槛，业务状态才进入 SERVING。

5. 灰度发布需要绑定明确版本

直接替换全部实例，一旦新模型或新运行镜像出现问题，影响范围会迅速扩大。灰度发布让一部分流量进入候选版本：

text2 行

stable v11  ── 90% traffic
canary v12  ── 10% traffic

比例只是示意。KServe 0.20 的 API 包含 Canary 配置和流量比例，实际使用要核对部署模式与版本能力。

每个请求需要留下服务版本、模型版本和运行修订号，才能比较两组结果：

text6 行

request_id
deployment_revision
model_version
latency
result_status
evaluation_feedback

不能只比较平均延迟。错误率、超时、尾延迟、资源占用和业务效果需要分别观察，并绑定相同的流量条件。

6. 回滚对象要提前定义

发布问题可能来自不同层：

问题	可能的回滚对象
模型效果下降	模型版本或流量路由
预处理错误	运行镜像和配置
资源不足	资源规格与副本配置
网络路由错误	Gateway、Service 或路由规则
上游请求不兼容	API Schema 或调用方版本

“回滚模型”如果只修改 storageUri，却保留不兼容的预处理镜像，服务仍然可能失败。一个 DeploymentRevision 应把模型、镜像、配置和接口版本固定在一起。

回滚也要作为新动作留下操作者、原因和目标版本，避免平台只显示最后状态。

7. 自动扩缩不能只看 CPU

推理服务的瓶颈可能来自 GPU 显存、并发序列、队列等待、批处理或模型加载时间。CPU 使用率未必能代表容量。

扩缩容策略至少要考虑：

请求速率和并发数。
排队时间与超时率。
GPU 利用率和显存。
单实例安全并发。
新实例从创建到 Ready 的时间。

缩容时还要处理正在执行的请求。Scale-to-zero 适合能够接受冷启动的场景，不应默认用于所有在线服务。

8. Java 控制面怎样管理发布

Spring Boot 可以提供面向业务的发布流程：