KServe v0.21.0 于 2026 年 9 月 25 日发布：162 项改动含 10 个 CVE 修复，官方首次实测 140 GB 模型在预热节点 11.7 秒完成首推理、走 s3:// 需 41 分钟，前置部署 Forward Deployed Engineer（FDE）可据此做隔离环境模型交付选型

KServe v0.21.0 于 2026 年 9 月 25 日发布：162 项改动含 10 个 CVE 修复，官方首次实测 140 GB 模型在预热节点 11.7 秒完成首推理、走 s3:// 需 41 分钟，前置部署 Forward Deployed Engineer（FDE）可据此做隔离环境模型交付选型 KServe 于 2026 年 9 月 25 日发布 v0.21.0：162 项改动含 10 个 CVE，140 GB 模型预热节点 11.7 秒起推理。 本条属 前置部署 Forward Deployed Engineer（FDE） 关注的云与基础设施交付面：KServe 是客户自有 Kubernetes 集群上托管预测与 LLM 推理的常用基座，模型体积、拉取路径与伸缩策略直接决定交付后的上线时长与节点成本，模型交付路径选型属于 Forward Deployed Engineer 在部署前必须写进方案书的决策项。 【一、发布事实与规模】 KServe 项目于 2026 年 9 月 25 日 17:05 UTC 发布 v0.21.0，版本页为 releases/tag/v0.21.0 上一个正式版 v0.20.0 发布于 2026 年 8 月 6 日，两版相隔 50 天 本次的两个候选版 v0.21.0-rc0 发布于 2026 年 9 月 10 日，v0.21.0-rc1 发布于 2026 年 9 月 23 日 发布说明的 What's Changed 段落列出 162 个去重后的 PR 编号 按提交前缀统计：fix 类 84 条、feat 类 32 条、chore 类 11 条、test 类 10 条 其余前缀为 ci 类 7 条、refactor 类 6 条、docs 类 5 条、release 类 4 条、deps 类 2 条、build 类 1 条 发布说明没有独立的 Breaking Changes 或 Deprecation 章节，升级风险主要来自 CRD 与依赖版本变化 本版计入 15 位首次贡献者，含 aneeshkp、ugiordan、noah4477、xrwang8、mateenali66 等 发布说明中出现 10 个互不相同的 CVE 编号与 2 个 GHSA 编号，安全修复是本次最大的单一类别 【二、核心实测：官方首批 OCI 模型交付启动基准】 前置部署 Forward Deployed Engineer（FDE） 用这组数字回答的问题很具体：在客户集群上多起一个副本，是等 12 秒还是等 41 分钟 本次发布新增的文档首次给出 OCI 模型交付路径的实测启动数据，文件是 docs/samples/storage/oci-image-volume/README.md 该文档在本次修改前明确写着没有基准数据、不要假设性能有优势，v0.21.0 把这个空白补上了 实测环境是单节点 kind 集群、Kubernetes v1.36.1、containerd 2.3.1 控制面、镜像仓库、MinIO 对象存储与 predictor Pod 同机部署，测的是交付架构本身而非广域网影响 机器规格是 AWS m6i.2xlarge，8 vCPU、32 GB 内存，1 TB gp3 EBS 默认配置 3000 IOPS 与 125 MiB/s 被测模型产物分 2 GB、14 GB、140 GB 三档，对应 1B、7B、70B 级模型的 fp16 权重 指标口径是从 InferenceService 提交到首次预测成功的中位耗时，单位为秒 oci+native:// 路径的冷启动耗时是 2 GB 用 38.6 秒、14 GB 用 443.4 秒、140 GB 用 4585.5 秒 oci+native:// 路径的热启动耗时是 2 GB 用 11.5 秒、14 GB 用 11.4 秒、140 GB 用 11.7 秒 modelcar 即 oci:// 路径的冷启动耗时是 59.6 秒、363.3 秒、4603.0 秒，热启动是 15.4 秒、15.2 秒、15.8 秒 s3:// 路径的冷启动耗时是 39.6 秒、137.8 秒、2318.8 秒，热启动是 30.0 秒、128.4 秒、2441.6 秒 热启动的定义是模型镜像已在节点 containerd 存储中；s3:// 没有节点级缓存，每次 Pod 启动都要重新下载 第一条结论是 OCI 路径的热启动耗时与模型大小无关，2 GB 与 140 GB 都在约 12 秒量级 在预热节点上为 140 GB 模型加一个副本约 11.7 秒，同样操作走 s3:// 需要重新下载约 41 分钟 第二条结论是首次冷拉取比纯下载更贵，140 GB 档约为两倍 根因是 containerd 要先把层 blob 写入磁盘再解包成快照，对磁盘写两遍，而 storage initializer 只流式读一次对象 节点若不止一次服务同一模型，缓存拉取的额外开销会很快被摊平 第三条结论是 modelcar 的拉取行为与 OCI 原生一致，另有每 Pod 约 4 秒的 sidecar 生命周期固定开销 文档自己声明绝对值随磁盘与网络吞吐变化，可迁移的只有三条路径之间的相对关系 作者公开了测试工具与原始数据，仓库地址是 kliukovkin/oci-model-delivery-bench，可拿到自有环境复测 【三、四条模型交付路径怎么选】 前置部署 Forward Deployed Engineer（FDE） 做路径选型要问清三件事：集群是否支持 ImageVolume、同一模型是否会被该节点反复加载、镜像仓库能否随交付物摆渡 oci+native:// 走 Kubernetes ImageVolume，由容器运行时直接拉取与缓存，不需要 sidecar，前提是集群支持 ImageVolume modelcar 即 oci:// 由 sidecar 承担镜像托管，兼容性最好，代价是每 Pod 约 4 秒额外开销 v0.21.0 新增 oci+fetch:// 路径，由 KServe 的 storage-initializer 使用 oras-py 拉取镜像层，PR 编号 5739 oci+fetch:// 只把镜像内 /models/ 子树解出到共享的 /mnt/models 卷，其余 rootfs 直接丢弃 oci+fetch:// 不要求集群支持 ImageVolume，也不像 modelcar 那样让 sidecar 伴随 Pod 整个生命周期 启用 oci+fetch:// 需要把 KServe 配置项 enableOciModelSupport 设为 true 镜像内模型文件必须放在 /models/ 目录下，这是 modelcar 约定；没有该目录会以明确报错中止拉取 多架构镜像即 OCI image index 会按 init 容器架构解析为 linux/<GOARCH> 的单架构清单 私有仓库需要 imagePullSecret，示例用 kubectl create secret docker-registry 在目标命名空间建密钥 s3:// 路径的冷启动在三档里都最快，2 GB 用 39.6 秒、14 GB 用 137.8 秒、140 GB 用 2318.8 秒 s3:// 的短板在热启动：没有节点缓存，140 GB 每次都要 2441.6 秒 决策规则是同一模型会在节点上被反复加载时选 OCI 路径，只加载一次且产物不大时 s3:// 更省 物理隔离环境没有可达的对象存储，镜像仓库可随交付物一起摆渡，OCI 路径天然合适 物理隔离环境的镜像摆渡要连带把镜像签名与校验链一起带进去，否则离线侧的完整性验证无从谈起 【四、KEDA 直连伸缩与真正的 scale-to-zero】 v0.21.0 新增 KEDA 直连伸缩能力，PR 编号 5839，作者 0-Zaid-0 本次把 idleReplicaCount 字段的校验下限从 Minimum=1 放宽到 Minimum=0，PR 编号 5996 字段注释写明设为 0 即真正的 scale-to-zero，空闲时 KEDA 把副本数缩到 0，触发器恢复后立刻回到 minReplicas 在此之前的版本该字段最小值为 1，交付方无法把闲置推理服务压到零副本 发布同时把内置 KEDA 依赖升级到 v2.20.2，PR 编号 6153 PR 6004 放开了 KEDA 的 triggerAuthName 在不写 authModes 时的用法 PR 6018 为独立 KEDA 自动伸缩补齐了端到端测试覆盖 局限是缩到零副本后首个请求要承担冷启动时间，本文第二节的冷启动数字就是这项代价的参照 【五、TLS：集群安全档位与两个新开关】 v0.21.0 新增集群 TLS 安全档位集成，PR 编号 5791，核心代码在 pkg/tls/tls.go 新增命令行开关 --tls-min-version，取值 VersionTLS12 或 VersionTLS13，默认 VersionTLS12 新增命令行开关 --tls-cipher-suites，取逗号分隔的 Go 密码套件名称列表，留空则用 Go 默认值 本次把 --enable-http2 标记为弃用，理由是 CVE-2023-44487 在 Go 1.21.3 以上已修复，建议改用上面两个开关 PR 6106 让组件在证书轮换后重新加载，不必重启控制面 这两个开关在 llmisvc、localmodel、localmodelnode 与 manager 四个二进制上都可用 适用条件是客户安全基线要求 TLS 1.3 或指定密码套件；改动前要先确认上游网关与客户端兼容 【六、安全修复清单与对交付的含义】 本次修掉 10 个 CVE：cryptography 提到 50.0.0 对应 CVE-2026-69247 Pillow 提到 12.3.0 对应 CVE-2026-54058 与 CVE-2026-59200 pyasn1 提到 0.6.4 对应 CVE-2026-59885，urllib3 提到 2.6.3 对应 CVE-2026-21441 opentelemetry-go 提到 1.43.0 对应 CVE-2026-39883，golang.org/x/crypto 提到 0.52.0 对应 CVE-2026-46595 black 提到 26.3.1 对应 CVE-2026-32274，setuptools 提到 78.1.1 对应 CVE-2025-47273 Pillow 另修 CVE-2026-40192，其 GHSA 编号为 GHSA-whj4-6x5x-4v2j go-jose 提到 v4.1.4，对应 GHSA-78h2-9frx-2jm8 python/storage 的 aiohttp 提到 3.13.3，修复 zip bomb 型拒绝服务 kin-openapi 的请求校验空指针崩溃被修掉，PR 编号 5992 autogluon 侧修了两个路径穿越问题，PR 编号 5802 与 5803 对交付方的含义是升级到 v0.21.0 可一次性清掉这批依赖告警，但仍需在交付前重跑镜像扫描器确认 【七、安装形态与 CRD 拆分】 v0.21.0 重构了 CRD 管理，使各组件可以独立安装，PR 编号 5843 CRD 被拆到四套 Helm chart：kserve-crd、kserve-crd-minimal、kserve-llmisvc-crd、kserve-llmisvc-crd-minimal chart 内容由 kustomize 构建后用 yq 按 metadata.name 抽取，覆盖 inferenceservices、trainedmodels、clusterservingruntimes、servingruntimes、inferencegraphs 本次新增 kustomize 校验工作流，PR 编号 5878 对离线交付的意义是可以只装需要的 CRD 子集，减少在客户集群里创建的 API 面 【八、工具链与平台面变更】 Go 工具链升级到 1.26，PR 编号 6127 新增 Python 3.13 支持，PR 编号 5897；pmmlserver 的 pyjnius 提到 1.7.0 即为配合该升级 storage-initializer 新增 Power 架构支持，PR 编号 5235 新增 ModelScope 存储下载支持，使用 ms:// URI 方案，PR 编号 5330 ServingRuntime 新增 DRA resourceClaims 支持，PR 编号 5828 Envoy AI Gateway 升级到 v1.1.0，PR 编号 6122；llm-d 镜像升到 0.10 版本，PR 编号 6026 kernelcache 引入签名校验框架与签名契约，PR 编号 6099、6103、6118，面向模型完整性校验 llmisvc 新增 InferencePool 引用自动打标，PR 编号 5624 InferenceService 新增链路追踪配置项，PR 编号 6108 【九、可直接照抄的升级验收清单】 前置部署 Forward Deployed Engineer（FDE） 把这七步写成可复跑脚本，比在方案书里写结论更有说服力 第一步：在非生产集群用 Helm 或 kustomize 安装 v0.21.0，先跑通一次预测请求 第二步：核对本次拆分的 CRD chart 是否覆盖存量资源，重点看 clusterservingruntimes 与 servingruntimes 第三步：按 2 GB、14 GB、140 GB 三档在本集群复测冷热启动，不要直接套用 kind 单节点数字 第四步：若要用 scale-to-zero，把 idleReplicaCount 设为 0，并确认 KEDA 版本不低于 v2.20.2 第五步：若客户基线要求 TLS 1.3，加 --tls-min-version VersionTLS13 并验证上游网关与客户端兼容 第六步：重跑镜像与依赖扫描，确认 10 个 CVE 与 2 个 GHSA 已清 第七步：确认 storage-initializer 的架构覆盖，Power 环境需要 v0.21.0 及以上 回滚方式：重新 apply 上一版 manifest 与 CRD；CRD 是集群级资源，降级后新增字段可能残留 回滚前先备份 Inferenceservice 等自定义资源清单，这是唯一可靠的回退依据 适用条件：本清单适用于自管的 Kubernetes 集群，托管推理服务不适用 退出方式：把复测得到的冷热启动秒数与 CVE 清单写进交付验收报告，作为后续容量规划的输入 【十、局限与未覆盖场景】 OCI 基准是单节点 kind 集群上的同机置放测试，控制面、仓库、对象存储与 Pod 共用一个 VM，不代表多节点或跨广域网表现 140 GB 档的耗时受默认 gp3 磁盘吞吐限制，换更高吞吐盘会改变绝对数字 实测未覆盖多节点共享缓存、跨可用区拉取与多副本并发冷拉取三种场景 s3:// 在 140 GB 冷启动上优于 OCI，与 OCI 的热启动优势方向相反，只记住一半会选错路径 本次发布说明没有独立的 Breaking Changes 章节，不等于没有不兼容变更 CRD 管理重构改变安装布局，原有的安装脚本可能不再适用 本账号此前没有发布过 KServe 相关条目，本文是该主体首次出现 原始来源： https://github.com/kserve/kserve/releases/tag/v0.21.0 https://github.com/kserve/kserve/pull/5852 https://github.com/kliukovkin/oci-model-delivery-bench https://github.com/kserve/kserve/pull/5739 https://github.com/kserve/kserve/pull/5791 https://github.com/kserve/kserve/pull/5843 https://github.com/kserve/kserve/pull/5996 https://github.com/kserve/kserve/pull/5839