Deep Research: [63] KServe：把推理服务当成可运维的工作负载

• Source: https://kserve.github.io/website/
• Note: ../notes/ref-063-kserve.md
• Snapshot: ../sources/md/kserve-github-io-website-1fb96b32d9c9.md

TL;DR

KServe 将 AI 模型推理从单纯的脚本运行升级为标准的 Kubernetes 可运维工作负载，通过统一的 InferenceService 抽象，为生成式和预测性 AI 提供开箱即用的自动扩缩容（含缩容到零）、金丝雀发布及标准化 API 接口。

核心观点

1. 推理即服务（Inference as a Service）：通过 Custom Resource Definition (CRD) 封装模型服务的复杂性（网络、自动扩缩、健康检查），开发者只需声明我要跑什么模型而非怎么配置 Nginx/Gunicorn。
2. 统一的控制平面：在同一个集群内同时管理 生成式 AI（LLM，支持 vLLM/TGI 等运行时）和 预测性 AI（XGBoost/TensorFlow），避免维护两套基础设施。
3. 成本优先的弹性伸缩：原生支持基于请求量的自动扩缩容（Autoscaling），特别是 Scale-to-Zero（缩容到零）能力，能在无流量时释放昂贵的 GPU 资源，显著降低云成本。
4. 标准化的推理协议：支持开放推理协议（KServe V2 Dataplane）和 OpenAI 兼容协议，使得客户端调用与后端具体的推理引擎解耦，便于无缝替换模型。
5. 原生的高级部署策略：无需修改代码即可通过配置实现金丝雀发布（Canary Rollout）、流量镜像（Shadow）和 A/B 测试，降低模型上线风险。
6. 模型与基础设施分离：支持通过 Storage URI（如 hf:// 或 S3 路径）动态加载模型，实现推理服务镜像的通用化，避免一个模型打一个 Docker 镜像的臃肿模式。
7. 可观测性内置：默认集成指标收集、日志管理和链路追踪，为白盒化运维模型服务提供基础数据。

可落地做法

1. 工程侧：构建标准推理底座

• Step 1 环境准备：在 K8s 集群上部署 KServe 及其依赖（通常为 Istio 和 Knative Serving）。
• Step 2 镜像通用化：构建或选用通用的 Serving Runtime 镜像（如 KServe 官方提供的 Sklearn/PyTorch Server 或 vLLM 适配器），确保该镜像不包含具体模型权重。
• Step 3 声明式部署：编写 YAML 文件，定义 InferenceService，指定模型存储路径（storageUri）和资源配额（GPU/内存）。
• Step 4 流量配置：配置 Istio VirtualService 实现对外暴露服务，并设置金丝雀流量比例（如新版本先走 10% 流量）。

2. 产品侧：定义服务等级

• 定义冷启动容忍度：针对非核心业务开启 Scale-to-Zero 以节省成本，明确告知用户可能的首次请求延迟。
• 统一 API 规范：强制要求前端或网关层使用 KServe 标准 API 或 OpenAI 兼容接口，确保后端模型更换时前端无感。

3. 评测侧：线上 AB 实验

• 利用 KServe 的流量分割功能，将线上 5% 的真实流量路由到新模型（Experiment），对比新旧模型的业务指标转化率，而非仅依赖离线评测数据。

检查清单：推理服务平台化成熟度自查

• [ ] 部署标准化：是否所有模型都通过统一的 YAML 模板部署，而非各自编写 Dockerfile 和 Shell 脚本？
• [ ] 版本控制：是否能通过一行命令回滚到上一个模型版本？是否有清晰的版本修订记录？
• [ ] 弹性能力：深夜低峰期，推理服务的 Pod 数量是否会自动减少？完全无流量时是否占用 GPU？
• [ ] 可观测性：是否拥有统一的 Dashboard 查看所有模型的 QPS、P99 延迟和错误率？
• [ ] 发布安全：新模型上线是否必须经过金丝雀阶段？是否有自动化的健康检查机制阻止坏版本 100% 上线？
• [ ] 资源隔离：不同业务线的模型是否通过 Namespace 隔离，且有明确的资源配额（ResourceQuota）限制？

常见坑与对策

• 坑 1：过度引入复杂性
  • 现象：对于只有 1-2 个小模型的团队，引入 K8s + Istio + Knative + KServe 极其沉重，运维负担远超收益。
  • 对策：小规模起步时，直接使用 Docker 或云厂商的 Serverless 容器服务。只有当模型数量 > 5 或需要复杂编排时再引入 KServe。
• 坑 2：冷启动延迟（Cold Start）
  • 现象：Scale-to-Zero 虽然省钱，但模型（特别是大模型）加载权重需要数秒甚至数分钟，导致首个请求超时。
  • 对策：对核心链路设置 minReplicas: 1 保证至少有一个实例在线；使用 PVC 预加载或模型缓存加速加载过程。
• 坑 3：调试困难
  • 现象：请求在 Istio、Knative 网关、Queue Proxy 之间流转，报错难以定位。
  • 对策：熟练掌握 kubectl logs -c 查看特定容器（如 user-container vs queue-proxy）日志；利用 Request ID 进行全链路追踪。
• 坑 4：GPU 资源碎片化
  • 现象：多个小模型各自占用一张 GPU 卡，导致资源利用率极低。
  • 对策：利用 KServe 的 Multi-Model Serving (MMS) 模式，或配置 NVIDIA MPS / MIG 技术在同一 GPU 上运行多个推理服务。

可用于丰富《AI 辅助软件产品》的写作点

• 第 11 章 推理部署 - 脚本 vs 平台的决策点：
  • 对比裸跑 Python 脚本 / FastAPI与使用 KServe的优劣。可以用 KServe 作为成熟期架构的代表，强调当企业需要管理模型资产库而非单一模型时，平台化的必要性。
  • 引用 KServe 的架构图，解释控制面（管理生命周期）与数据面（处理请求）分离的设计原则。
• 第 12 章 计费与成本 - Serverless 推理的经济账：
  • 利用 KServe 的 Scale-to-Zero 特性，探讨如何计算闲置 GPU 成本的节省。可以给出一个假设的成本模型：如果业务只在白天运行，Scale-to-Zero 能节省约 60% 的基础设施费用。
• 第 20 章 治理 - 模型上线门禁：
  • 介绍如何结合 KServe 的 Canary Rollout 和自动化测试（如 LLM-as-a-Judge）构建模型上线的质量门禁（Quality Gate）。如果新模型在金丝雀阶段的错误率飙升，自动触发回滚。