从 KServe 到 Kthena:云原生模型服务平台的技术演进

在 Kubernetes 上部署一个模型服务,为什么需要专门的平台?本文从 Serverless 的本质出发,深入拆解 KServe 的拓扑架构与技术细节,并对比 2026 年新晋的 LLM 推理专用平台 Kthena,梳理云原生推理领域的技术选型思路。

一、为什么需要模型服务平台

在 KServe 出现之前,在 Kubernetes 上部署一个推理服务,意味着手动拼装 Deployment、Service、HPA、Ingress、ConfigMap 等一堆资源。而模型服务还有其独特的痛点:

框架异构:PyTorch、TensorFlow、XGBoost、ONNX、vLLM、TGI……每个引擎的部署方式各不相同;
成本压力:GPU 极其昂贵,闲置时的空转是巨大的浪费;
运维复杂:版本灰度、流量切分、可解释性、日志审计,每一项都需要额外的工程投入。

KServe(前身是 Kubeflow 下的 KFServing,2022 年独立,2025 年 9 月进入 CNCF 孵化)给出的答案是:用一个 InferenceService CRD 把这一切声明式地抽象掉。Google、IBM、Bloomberg、NVIDIA 等公司共同发起了这个项目,如今 Bloomberg、Zillow、AT&T、SAP、Tesla 等企业在生产环境使用,Red Hat OpenShift AI、Google Cloud GKE、阿里云 ACK 都将其产品化为 AI 推理平台的底座。

二、理解 Serverless:KServe 的核心卖点之一

先澄清一个常见误解:Serverless 不是"没有服务器",而是"你不需要操心服务器"。底层依然由真实的服务器、容器或 microVM 承载计算,只是运维责任从开发者完全转移到了平台。

Serverless 的三大特征:

声明式提交——你只提交业务逻辑(或模型描述),不写基础设施配置;
按请求自动伸缩——流量突增时瞬时拉起成百上千个实例;
缩容至零——没有请求时不占用任何资源,按实际执行次数和毫秒级时长付费。

在传统 FaaS(如 AWS Lambda)中,“函数 + 事件触发"是基本单元。KServe 的 Serverless 模式做了一次精妙的替换:把"函数"换成"模型容器”,把"事件源"换成"HTTP 推理请求"。你提交的不是代码函数,而是一份描述模型存放位置、运行框架的 YAML。

三、KServe 的拓扑架构:控制面 + 数据面 + 推理图

3.1 整体拓扑

flowchart TB
    Client[客户端 REST/gRPC/OpenAI API] --> GW[Gateway API / Istio]
    subgraph CP[控制面]
        CM[KServe Controller Manager]
        IGC[InferenceGraph Controller]
        LMC[LocalModel Controller]
        LMN[LocalModelNode Agent]
        WH[Admission Webhooks]
        KPA[Knative Autoscaler]
    end
    subgraph DP[数据面]
        IGR[InferenceGraph router]
        subgraph Pod[InferenceService Pod]
            SI[storage-initializer]
            QP[queue-proxy]
            PD[Predictor]
            TF[Transformer]
            EX[Explainer]
        end
    end
    ST[(模型仓库 S3/HF/OCI)]
    GW --> IGR --> Pod
    CM --> Pod
    SI --> ST
    KPA -.->|按请求扩缩/缩至零| Pod

3.2 控制面:标准的 Operator 模式

KServe 控制面遵循 Kubernetes watch-reconcile 控制器范式:

组件	职责
Controller Manager	监听并调和 InferenceService(v1beta1)与 LLMInferenceService(v1alpha1)CRD,翻译为底层 K8s 资源
InferenceGraph Controller	管理 InferenceGraph CRD,部署 graph-router 容器,支持 4 种路由节点:Sequence(串行链)、Switch(条件分支)、Ensemble(并行集成)、Splitter(按权重分流)
LocalModel Controller + Node Agent	管理 LocalModelCache,以 DaemonSet + PVC 形式把大模型权重预取到节点本地盘,加速冷启动
Admission Webhooks	校验 schema、注入默认值与安全上下文

关键设计在于双模式输出:Serverless 模式产出 Knative Service 并配合 KPA 实现缩容至零;Raw Deployment 模式产出原生 Deployment + HPA/KEDA,后者是当前 LLM 生产部署的推荐方式。

3.3 数据面:Pod 内的容器组合

一个 InferenceService Pod 内的组合是 KServe 最精巧的设计:

Predictor(必需):加载模型、执行推理的运行时,由 ServingRuntime CRD 定义可插拔的引擎镜像,对接 vLLM、Triton、TorchServe、TGI、MLServer 等;
Transformer(可选):前后处理,可对接 Feast 做实时特征工程;
Explainer(可选):集成 Alibi、TrustyAI 做模型可解释性;
storage-initializer:常驻 initContainer,Pod 启动前从 S3/GCS/Azure/HuggingFace 拉取模型权重,支持以 OCI 镜像形式打包模型的 Modelcar 机制;
queue-proxy:常驻 sidecar,负责并发控制、请求排队,并把模型容器的 Prometheus 指标以 Knative 标签重新暴露,供 KPA 扩缩决策。

3.4 一次 Serverless 请求的完整链路

你提交 InferenceService YAML;
Controller 将其翻译为 Knative Service 并创建 KPA;
推理请求到达 Istio/Kourier 网关,若副本数为 0,请求先被 Activator 缓冲,同时通知 Autoscaler 拉起模型 Pod;
请求经 queue-proxy 转入模型容器执行;
流量归零后,KPA 将副本缩至 0,GPU 完全释放。

Knative 的 Activator + KPA + Queue-Proxy 三件套,正是承担了 FaaS 平台背后那套冷启动与调度机制。

3.5 推理协议的三代演进

V1 协议::predict、:explain,纯 REST;
V2(Open Inference Protocol):/v2/models/<model>/infer,支持 gRPC,被 Triton、TF Serving、TorchServe 共同认可;
OpenAI 兼容 API:/v1/chat/completions 等,支持 SSE 流式输出,服务生成式场景。

针对 LLM,KServe 0.2x 还引入了 Envoy AI Gateway + Gateway API Inference Extension:endpoint-picker 基于负载、QoS、KV-Cache 感知做智能路由,配合 KEDA LLM Autoscaler 与 prefill/decode 分离部署,构成完整的生成式推理拓扑。

四、Kthena:LLM 推理调度的"专科医生"

2026 年 1 月,Volcano 社区(华为云主导)推出了子项目 Kthena。它不与 KServe 正面竞争,而是切入了 KServe 相对薄弱的一环:LLM 推理的调度、编排与智能路由。关于 Kthena 在主流推理调度器谱系中的定位与对比(与 AIBrix、llm-d、Dynamo 等),见同日另一篇推理调度器调研报告。

维度	KServe	Kthena
定位	全场景模型服务平台(预测式 + 生成式)	LLM 推理专用调度编排层
出身	CNCF 孵化,Google/IBM/Bloomberg 等发起	Volcano 子项目,华为云牵头发起
核心 CRD	InferenceService、InferenceGraph、ServingRuntime	ModelServing、ModelBooster、ModelRoute、AutoScalingPolicy
架构分层	单层 InferenceService,LLM 路由需外接 Envoy AI Gateway	ModelServing → ServingGroup → Role 三层结构,内置一体化 Router
调度能力	标准 K8s 调度 + DRA 扩展	深度集成 Volcano:Gang 调度、拓扑感知、原生 PD 分离
智能路由	Envoy AI Gateway 的 endpoint-picker	可插拔评分插件:KV Cache 感知、Prefix Cache 匹配、LoRA 亲和路由、token 级限流
硬件生态	主流 GPU	GPU + NPU(昇腾)异构混布
Serverless	支持(缩容至零、金丝雀发布)	不支持缩容至零,聚焦调度效率
成熟度	大量生产案例与厂商产品化	发布约半年,主要在中国云原生生态推进

几个值得注意的深层差异:

PD 分离的实现深度。Prefill(计算密集)与 Decode(访存密集)两阶段对硬件的需求截然不同。KServe 需要 DIY 组装,Kthena 则将其上升为架构一等公民:一个 ModelServing 下管理多个 ServingGroup,Prefill 组调度到高算力节点、Decode 组调度到高带宽显存节点,支持独立扩缩比例。
路由的性能收益。Kthena 内置路由省去了 Envoy 网关的运维成本,官方基准显示:在长系统提示(4096 token)场景下,"KV Cache 感知 + Least Request"策略相比随机路由可将吞吐提升约 2.73 倍、TTFT 降低 73.5%。

延伸:Kthena 作为 Volcano 子项目,本质是集群里"第二个调度器"在 LLM 推理场景的具体形态——它通过 schedulerName 路由接管推理负载,与 kube-scheduler 共存。多调度器共存的机制、模式与坑(资源双重记账、抢占不知情、拓扑不互通),见一个集群,多个调度器:Kubernetes 多调度器共存实践指南。

五、选型建议

综合来看,两者的选择可以归结为三个问题:

是否需要同时服务预测式和生成式模型? 是 → KServe。它的 Transformer/Explainer 组件化、InferenceGraph 推理图、统一推理协议对传统 ML 场景依然无可替代。
流量是否波动大、空闲成本是否敏感? 是 → KServe 的 Serverless 模式(注意冷启动代价:大模型拉起可能需要几十秒甚至几分钟,所以 LLM 场景建议切换到 Raw Deployment)。
是否为纯 LLM 场景、追求极致 GPU/NPU 利用率? 是 → Kthena。尤其当你已经在用 Volcano 做训练调度时,它能形成训练-推理统一的调度栈。若涉及多 LoRA 并存、PD 分离、异构混布,Kthena 的原生抽象会更省力。

两者并非严格互斥——Kthena 的定位是"vLLM/SGLang 等引擎之上的编排层",理论上可与 KServe 组合使用,但目前尚无官方集成方案。

六、总结

云原生推理领域正在经历一次清晰的分工演进:

KServe 代表了"平台标准化"路线——用声明式 API 和统一协议抹平框架差异,用 Knative 带来 Serverless 弹性,覆盖从 XGBoost 到多模态 LLM 的全谱系场景;
Kthena 代表了"垂直纵深"路线——直面 LLM 推理特有的 KV Cache 调度、PD 分离、异构算力问题,把通用平台难以做深的系统优化做到极致。

对工程团队的启示是:推理基础设施没有银弹。理解每个抽象层(网关、路由、调度、运行时)各自解决的问题,比追逐某一个"最佳平台"更重要。随着 LLM 工作负载持续演化,这两个项目的走向——KServe 如何深化 LLM 支持、Kthena 如何扩展生态边界——都值得持续关注。

参考:KServe 官方文档与 Adopters 名单、Volcano 社区 Kthena 发布公告、Knative 架构文档、CNCF 博客及各厂商官方案例。

文章作者: Roger-Lv

文章链接: http://example.com/2026/08/23/2026-08-23-%E4%BB%8EKServe%E5%88%B0Kthena%E4%BA%91%E5%8E%9F%E7%94%9F%E6%A8%A1%E5%9E%8B%E6%9C%8D%E5%8A%A1%E5%B9%B3%E5%8F%B0%E6%BC%94%E8%BF%9B/