KServe SKLearnModel 部署报 NotFound 的根本原因是默认不自动拉取私有存储模型且路径格式敏感：模型必须为 model.joblib 或 model.pkl 且位于归档根目录，storageUri 需带 s3:// 前缀，并通过 KServeStorageSecret 注入凭证。
KServe 的 SKLearnModel 部署为什么一直报 NotFound 错误
根本原因不是模型没上传，而是 KServe 默认不自动拉取私有存储（比如 S3、MinIO）里的模型文件，且对路径格式极其敏感。它要求模型必须放在 model.joblib 或 model.pkl，且必须在归档包根目录下——不能套在 models/ 或 sklearn/ 子目录里。
- 检查你的
storageUri是否带协议前缀：s3://my-bucket/my-model/是对的，my-bucket/my-model/会静默失败 - 确认 MinIO/S3 的 endpoint、access key、secret key 已通过
KServeStorageSecret注入，而不是写死在 YAML 里 - 用
aws s3 ls s3://my-bucket/my-model/手动验证路径存在且可读，KServe 不会返回权限错误，只会卡在ModelNotReady - 本地测试时别用
file://路径——KServe v0.12+ 已弃用，改用local:///mnt/models/并挂载 hostPath
如何让 Python sklearn 模型支持 KServe 的 v2 协议推理
默认 SKLearnModel 只走 KServe 内置的旧版预处理逻辑，不兼容 Triton 或 KFServing v2 接口。要启用 v2，必须显式指定 protocolVersion: v2，并确保模型导出时保留原始输入结构（比如不把 numpy.ndarray 强制转成 pandas.DataFrame）。
- 部署 YAML 中必须加字段：
protocolVersion: v2，漏掉就走不了/v2/models/{name}/infer - 模型代码里不要重写
predict()方法——KServe v2 依赖原生 sklearn 的predict()签名，自定义方法会导致 input/output schema 解析失败 - 如果用
joblib.dump(model, "model.joblib")，确保 model 是纯 sklearn estimator，不含自定义 wrapper 类或 lambda 预处理 - v2 协议下，请求 body 必须是严格 JSON，
numpy.float64会直接报Invalid input type，前端需先转float
InferenceService 创建后始终卡在 Unknown 状态
这不是模型问题，大概率是 KServe 控制平面没正确识别你集群的 Istio 或 Knative 配置。KServe v0.13+ 默认依赖 knative-serving 的 activator 组件做冷启动，但很多用户只装了 Istio，忘了开 Knative。
- 运行
kubectl get pods -n knative-serving，缺activator或autoscaler就得补装 Knative Serving - 检查
InferenceService的status.conditions：如果出现Failed to create Revision，说明底层 Knative 没就绪 - 用
kubectl describe inferenceservice my-model查最后一行Events，常见提示是FailedCreateRevision: unable to resolve service——本质是 Istio Gateway 和 VirtualService 没生效 - 跳过 Knative 直接跑？可以，但得把
spec.predictor.serviceAccountName设为有istio-system权限的账号，并手动配VirtualService
Python 模型热更新时为何新版本不生效
KServe 不支持“替换模型文件后自动 reload”，它靠的是 revision 机制：每次改 storageUri 或 modelFormat 才触发新 Pod 启动。直接覆盖 S3 上的 model.joblib，旧 Pod 还在用缓存的副本。
立即学习“Python免费学习笔记（深入）”；
- 热更新必须改
storageUri，比如从s3://bucket/model-v1/改成s3://bucket/model-v2/，哪怕只是加个时间戳 - 不要指望
kubectl edit isvc修改storageUri后立刻生效——KServe 会先滚动删旧 Pod，等新 Pod Ready 后才切流量，中间有几秒不可用 - 想零停机？得配合
canary策略，用traffic字段分流量，但注意canary仅在v2协议下稳定，v1容易出现 schema 不一致 - 本地调试时，用
ksctl apply -f model.yaml --force强制重建比反复 edit 更可靠
真正麻烦的是模型和 KServe 版本耦合：v0.12 的 SKLearnModel 不认 v0.13 的 v2 schema，升级前务必查清 modelFormat.version 对应关系，文档里藏得深，但错一个字符就进 CrashLoopBackOff。
