新版模型先接 10% 请求，KServe 把灰度流量写进服务配置

模型更新通过了离线检查，下一步仍有一个实际选择：直接替换全部请求，还是先让新版本接一小部分流量？KServe 的灰度示例，用一个模型服务的两份权重位置，把这个选择写进配置。

它适合已经维护 Kubernetes 模型服务的平台工程师。这里介绍的是预测模型 InferenceService 路径，不能把这份配置自动套到所有生成式服务资源上。

一份服务名，两份模型版本

官方案例先部署 sklearn-iris，声明模型格式为 sklearn，storageUri 指向第一份模型。更新时仍使用同一个服务名，存储位置改为 model-2，并设置 canaryTrafficPercent: 10。

这样，新版被配置为接收10%的预测请求，稳定版本继续承接其余流量。这个比例是官方演示用值，不是所有团队都应采用的发布规则。

对开发者，配置留下了可以检查的版本关系：模型文件来自哪里，本次创建了哪个修订，哪个版本仍是稳定版本。服务地址相同，也不意味着背后始终只有一份模型。

示例继续连接 Prometheus 指标，用稳定修订和新修订的名称区分请求。它通过 Iter8 检查准备状态、取得指标，再评估平均延迟、较高分位延迟与错误数。

这段材料说明，灰度不是只改一个百分比。新旧版本需要有可区分的观察结果，才能决定继续扩大、保持或撤回流量。示例里的具体阈值与旧版 Iter8 安装命令属于该教学环境，不能直接当成今天所有集群的部署清单。

延迟与错误数也不是模型内容质量。一个服务能稳定返回200，仍可能给出不合适的预测；真正的业务效果，需要另外定义评价材料和观察方式。

当前 README明确区分标准 Kubernetes、Knative 与 ModelMesh 等安装路径。标准 Kubernetes 安装较轻，却不支持这里的灰度部署和按请求缩到零；Knative 模式用于相应的 serverless InferenceService。

所以，这不是往任意集群的 YAML 加一行就一定生效的功能。先对准部署模式，再理解服务修订和流量比例，才知道这份案例能否接上已有系统。

KServe代码采用Apache-2.0，模型、监控组件与集群资源各有条件。它在这项任务中的价值很具体：让升级过程留下新旧版本和流量安排，并给指标比较一个明确对象。10%只是起点，是否继续扩大发布，应由这些版本实际交出的结果决定。