KServe：Kubernetes 原生的模型推理平台——把 vLLM/TGI/Triton 变成 Serverless

LLM 推理服务系列 · 第 4 篇

前三篇讲的 vLLM、TGI、Triton 都是"推理引擎"——负责把模型变成进程，处理请求。单机推理它们足够好。但当你需要服务几十个模型、上百个 GPU、多租户共享集群——你会撞上一堆平台层的问题：自动扩缩容、金丝雀发布、流量治理、配额管理、监控告警。

KServe 解决的是这一层的问题——它不做模型推理，它管理推理引擎。把 vLLM 或 TGI 打包进 Kubernetes，加上 Serverless 的能力——有请求时自动扩容，没请求时缩到零。

---

KServe 是什么

KServe 的前身是 Kubeflow KFServing，2021 年独立出来捐给 CNCF。它的核心模型是一个叫 InferenceService 的 Kubernetes CRD（自定义资源）：

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: llama-8b-instruct
spec:
  predictor:
    model:
      modelFormat:
        name: huggingface
      runtime: vllm                # ← 底层用 vLLM
      args:
        - --model-id=meta-llama/Llama-3.1-8B-Instruct
        - --tensor-parallel-size=2
        - --max-model-len=4096
      resources:
        limits:
          nvidia.com/gpu: 2        # ← 2 张 GPU

kubectl apply 这一下，KServe 自动做了：

1. 创建一个 Deployment 运行 vLLM 进程
2. 创建一个 Service 暴露 HTTP 端点
3. 挂载模型（从 S3/OSS/PVC 自动下载）
4. 注册 Prometheus 指标
5. 配置 Istio/Knative 流量管理

你不需要写 Deployment YAML、Service YAML、ConfigMap、Istio VirtualService——KServe 一个 CRD 全包了。

---

核心架构：Control Plane + Data Plane

                      ┌──────────────────────┐
                      │   KServe Control Plane│
                      │                       │
                      │  - InferenceService   │
                      │    Controller         │
                      │  - 调和循环            │
                      │  - 自动创建 Deployment │
                      │    / Service / Route   │
                      └──────────────────────┘
                               │
                               ▼
┌──────────────────────────────────────────────┐
│              Data Plane                      │
│                                              │
│  ┌───────────┐  ┌──────────┐  ┌───────────┐ │
│  │ Predictor │  │Transformer│  │  Explainer │ │
│  │ (推理主体)  │  │(预处理/后  │  │  (模型解释) │ │
│  │            │  │ 处理)     │  │            │ │
│  │  vLLM     │  │ Python    │  │  Alibi     │ │
│  │  TGI      │  │ 转换代码  │  │  SHAP      │ │
│  │  Triton   │  │            │  │            │ │
│  └───────────┘  └──────────┘  └───────────┘ │
│                                              │
│  ┌──────────────────────────────────────┐    │
│  │        Knative / Istio              │    │
│  │  - 自动扩缩容 (Scale to Zero)        │    │
│  │  - 流量分割 (金丝雀)                 │    │
│  │  - 请求队列管理                      │    │
│  └──────────────────────────────────────┘    │
└──────────────────────────────────────────────┘

三个组件各司其职：

• Predictor：核心，运行实际的推理引擎（vLLM/TGI/Triton）。必须有。
• Transformer：可选。在请求到达 Predictor 之前做预处理（Tokenization、格式转换），在响应返回之后做后处理。Python 代码，不需要 GPU。
• Explainer：可选。模型可解释性（特征重要性、SHAP 值）。生产环境很少用。

---

自动扩缩容（Scale to Zero）

这是 KServe 最强的能力——继承自 Knative：

没有请求 → 0 个 Pod → 0 GPU 消耗 → 0 成本
请求来了 → Knative Activator 缓存请求
         → 拉起 Pod（冷启动 30s-2min，取决于模型大小）
         → Pod Ready → 请求转发过去
持续有请求 → HPA 按 QPS/并发数扩缩
一段时间无请求 → 缩回到 0

注意：LLM 的 Scale to Zero 有个实际困难——加载模型到 GPU 需要 30 秒至几分钟不等。这段时间请求排队。如果你无法接受冷启动延迟——可以设置 minReplicas: 1 保持常驻，只用 Scale to Zero 给低频模型省成本。

spec:
  predictor:
    minReplicas: 1       # 至少保留 1 个实例（消除冷启动）
    maxReplicas: 5       # 最多扩展到 5 个实例
    scaleTarget: 10      # 每个 Pod 最多同时处理 10 个请求
    scaleMetric: concurrency

---

金丝雀发布：一个 YAML 完成

更新模型版本时，可以先切 10% 流量到新版本验证：

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: llama-8b-instruct
spec:
  predictor:
    canaryTrafficPercent: 10    # ← 10% 流量给 canary
    model:
      modelFormat:
        name: huggingface
      runtime: vllm
      args:
        - --model-id=meta-llama/Llama-3.1-8B-Instruct-FP8  # ← 新模型

已有旧版本继续服务 90% 流量，新版本服务 10% 流量。验证通过后把 canaryTrafficPercent 调到 100，切完删除旧版本 Deployment——无宕机更新。

---

多模型服务：ModelMesh

当你有几百个模型时（不是几百个请求——是几百个不同的模型），每个模型一个 Deployment 会炸——几百个 Pod，大部分时间在等请求。KServe 提供了 ModelMesh 模式：

传统模式：每个模型 = 一个 Deployment = 至少一个 GPU Pod
  llama-8b    → GPU 0（Pod 常驻，可能大部分时间空闲）
  mistral-7b  → GPU 1（Pod 常驻，可能大部分时间空闲）
  bert-ner    → GPU 2（Pod 常驻，CPU 不够）
  ...

ModelMesh 模式：多个模型共享同一个 GPU Pod
  ┌────────────────────┐
  │   一个 Triton Pod   │
  │  ┌───────────────┐  │
  │  │ llama-8b      │  │ ← 模型在显存中，空闲时不卸载
  │  │ mistral-7b    │  │
  │  │ bert-ner      │  │
  │  │ ...共 50 个    │  │ ← 按 LRU 在显存和本地磁盘之间换入换出
  │  └───────────────┘  │
  └────────────────────┘

低延迟模型热数据留在显存，低频模型换出到本地 SSD。请求到来时 LRU 命中 → 直接用显存中的模型，未命中 → 从磁盘加载到显存（比从 S3 下载快 100 倍）。

底层用 Triton 做运行时——因为 Triton 支持单进程加载多个模型，且 ModelMesh 利用了 Triton 的 Backend 架构做模型动态装卸。

---

运行时可插拔

KServe 不写死用哪个推理引擎——所有引擎都是可插拔的：

InferenceService
     │
     ├── runtime: vllm       → 底层跑 vLLM
     ├── runtime: tgi        → 底层跑 TGI
     ├── runtime: triton     → 底层跑 Triton
     ├── runtime: sklearn    → 底层跑 scikit-learn
     ├── runtime: xgboost    → 底层跑 XGBoost
     └── runtime: custom     → 任意的 Docker 镜像，你自己掌控

社区提供了主流引擎的 Runtime YAML，你也可以自己写——本质是一个 Kubernetes Deployment 模板。

---

什么时候选 KServe

场景	推荐
单模型、单机	vLLM / TGI 直接跑就够了
多模型、多团队、共享集群	首选 KServe
需要自动扩缩容（含 Scale to Zero）	KServe 原生支持
需要金丝雀发布、AB 测试	canaryTrafficPercent 一行搞定
已有 Kubernetes 集群	直接安装，无额外依赖
裸机部署、非容器环境	不适用
几百个模型，大部分低频使用	ModelMesh 模式

---

一句话总结

KServe 不做推理——它管理推理引擎。把 vLLM、TGI、Triton 封进 Kubernetes CRD，加上 Knative 做 Serverless 扩缩容、Istio 做流量管理、ModelMesh 做多模型共享 GPU。单机推理你用 vLLM，平台化管理你用 KServe。两者的差异不是"性能"，是"运维规模和自动化程度"。

下一篇：Ray Serve——跟 KServe 思路不同。KServe 把推理装进 Kubernetes 原语，Ray Serve 把推理当作"分布式 Actor"来调度。Python 原生、毫秒级调度、LLM + 在线特征 + 强化学习全在一个 Ray Cluster 里跑。