kthena

开源项目分析报告：Kthena — Kubernetes 原生的企业级 LLM 推理平台

volcano-sh/kthena · 396★ · Apache-2.0 · Go

图1：Kthena 系统架构图，展示了控制平面（Kthena Controller Manager）与数据平面（Kthena Router）的分离设计，以及与 Volcano Scheduler 的集成关系。

---

一、痛点切入：当大模型遇上 Kubernetes

想象这样的场景：你的团队刚刚微调了一个 70B 参数的Llama模型，效果非常好，但接下来需要把这个模型部署到生产环境，让 100 个并发用户同时使用。很快，问题接踵而至——

如何在多个 GPU 节点上高效调度推理请求？Prefill（计算密集）和 Decode（内存密集）两个阶段对硬件需求差异巨大，能否分开处理？LoRA 适配器需要热切换，但模型权重有 140GB 之巨，如何做到不停服更新？KV-Cache 能否跨推理实例共享，避免重复计算？

这些问题不是小打小闹的工程挑战，而是每家部署 LLM 到生产环境的企业都在面对的真实困境。传统的模型部署方案要么太简陋（直接 torchrun 跑脚本），要么太封闭（各家云厂商的闭源推理平台）。

Kthena 的诞生，正是为了填补 Kubernetes 生态在 LLM 推理领域的系统性空白。

---

二、项目背景：Volcano 社区的 AI 基础设施雄心

Kthena 由 Volcano 项目 团队开发和维护。Volcano 是面向高性能计算场景的 Kubernetes 调度器增强项目，在批量调度、作业管理领域有深厚积累，支撑了 Kubeflow、Spark、Flink 等众多数据科学平台的调度需求。

随着 LLM 浪潮席卷全球，Volcano 团队敏锐地意识到：大模型推理与传统的批处理作业有本质区别——推理需要低延迟、高吞吐、弹性伸缩、流量路由等能力，而这些恰恰是 Volcano 多年沉淀的优势方向。于是，Kthena 作为 Volcano 生态的 LLM 推理扩展项目正式立项，目标是将 Kubernetes 原生的扩展性、声明式管理与大模型推理的工程需求深度融合。

项目当前处于活跃开发阶段，GitHub 最新更新为 2026 年 7 月 25 日，社区通过双周会议（Asia 16:00 UTC+8 周三）保持同步。

---

三、核心功能：五个维度的企业级推理能力

3.1 声明式模型生命周期管理

Kthena 通过 Kubernetes CRD（Custom Resource Definitions）将 LLM 推理抽象为标准资源。开发者只需编写 YAML 文件，声明式地定义模型来源、副本数量、GPU 配置、扩缩容策略，Controller Manager 自动完成部署、健康检查、滚动更新等全生命周期操作。

CRD 支持两种核心资源：

• Model：定义推理服务本身，包括模型路径、推理引擎（vLLM/SGLang/Triton/TorchServe）、资源需求等
• ServingRuntime：定义推理引擎的具体配置，支持自定义运行时镜像

这种设计的最大价值在于：平台的运维人员不需要理解模型的内部细节，只需掌握 Kubernetes YAML 规范即可管理复杂的 LLM 推理服务。

图2：Kthena Pod 控制器架构，展示了 Model CRD 到实际 Pod 的映射与调度流程。

3.2 Prefill-Decode 分离调度（xPyD）

这是 Kthena 最有技术含量的特性之一。LLM 推理的两个阶段——Prefill（处理用户输入 prompt，GPU 计算密集）和 Decode（自回归生成 token，HBM 带宽密集）——对硬件的需求差异极大：Prefill 适合 A100/H100 等高算力卡，Decode 适合 H20/L40S 等大显存卡。

Kthena 支持将这两个阶段拆分到不同的节点组，通过 River（Prefill）和 Lake（Decode）角色实现异构调度。这一能力依赖于 Volcano Scheduler 的 gang scheduling 机制——必须保证一组相关 Pod 同时调度成功，否则宁可一起等待，避免部分启动导致的资源浪费。

对于部署 70B+ 超大模型的团队，xPyD 分离可以将 GPU 利用率提升 30-50%，同时显著降低推理延迟。

3.3 KV-Cache 感知的智能路由

推理过程中的 Key-Value Cache（KV-Cache）是注意力机制的中间结果，相同的 prompt 前缀对应的 KV-Cache 可以跨请求复用。Kthena Router 内置了 KV-Cache 感知路由策略，当新请求的 prompt 与已有缓存匹配时，优先路由到持有对应 Cache 的推理实例，从而避免重复计算。

此外，Router 还支持：

• 多模型路由：按模型名称/header/URI 模式分发流量
• LoRA 适配器感知路由：根据请求中的 adapter name 路由到加载了对应 LoRA 的实例，热切换无中断
• 金丝雀发布与流量权重：支持灰度放量和 A/B 测试
• 令牌级别限流：基于 token 数量的精确速率控制

3.4 动态 LoRA 热切换

LoRA（Low-Rank Adaptation）是当下最流行的模型微调方法之一，一个 7B 模型对应一个 LoRA adapter 文件只有几十到几百 MB，远小于完整模型权重。Kthena 允许在推理服务运行期间动态加载和切换 LoRA adapter，无需重启推理 Pod，也不需要重新分配 GPU 显存。

这一特性对多租户 SaaS 平台和多任务服务场景极具吸引力——同一组推理实例可以根据请求动态适配不同的微调版本，实现真正的「一张卡，多种能力」。

3.5 成本驱动的弹性伸缩

Kthena Autoscaler 支持基于多种指标的扩缩容策略：CPU、GPU 利用率、内存、队列深度，甚至自定义 Prometheus 指标。结合成本约束（budget limit），系统可以在满足延迟 SLO 的前提下尽量减少资源占用，降低推理成本。

---

四、技术架构：控制平面与数据平面的深度解耦

图3：Kthena 全局存储架构，支持分布式文件系统共享模型权重和 KV-Cache。

Kthena 的架构可以概括为「一个平台，两套组件」：

Kthena Controller Manager（控制平面）

作为 Kubernetes Operator 运行，持续监听 Model、ServingRuntime 等 CRD 资源，通过 reconcile loop 确保集群实际状态与声明式期望状态一致。核心技术栈：

• Controller Runtime：Kubernetes Operator 标准框架，处理 Informer、WorkQueue、Leader Election
• Volcano Scheduler 集成：利用 gang scheduling 确保分布式推理 Pod 的原子性调度
• 模型存储抽象：支持 NFS、CephFS、JuiceFS 等分布式存储挂载模型权重

Kthena Router（数据平面）

作为独立代理服务运行，接收外部推理流量，通过策略引擎分发到后端推理实例。核心技术栈：

• Gin Web 框架：高性能 HTTP 路由，基于 Go 语言
• Redis：分布式缓存，存储路由规则、限流计数器、LoRA adapter 元信息
• xxHash：高效哈希算法，用于请求指纹和 Cache 键计算
• Prometheus 客户端：暴露推理 QPS、延迟、GPU 利用率等监控指标

关键依赖一览：

• 推理引擎：vLLM（主流）、SGLang（长上下文优化）、Triton（TensorRT 加速）、TorchServe（PyTorch 原生）
• 调度增强：Volcano Scheduler（gang scheduling、Triton-binpack）、Istio（服务网格集成）
• 通信协议：Gateway API（Kubernetes SIG 标准化 Ingress）、LWS（LoRA Weight Service）

图4：Kthena 角色级扩缩容示意，展示 River（Prefill）和 Lake（Decode）角色的独立伸缩能力。

---

五、部署体验：Helm Chart 一键安装，但门槛不低

Kthena 提供 Helm Chart 安装，配置项覆盖 Controller Manager、Router、Prometheus metrics、Redis 等组件。对于已有 Kubernetes 集群的团队，整个部署流程约 30-60 分钟。

但需要注意的是，这套方案的目标用户是有 Kubernetes 运维经验的团队，而非 AI 爱好者。安装前提条件包括：

• Kubernetes 1.27+ 集群
• 已配置 kubectl
• Helm 3.x
• GPU 节点池（使用推理功能时）

项目还提供了 ./hack/local-up-kthena.sh 脚本，支持一键在本地搭建 MiniKube/Kind + Kthena 的完整测试环境，方便开发者快速上手验证。

值得注意的是，Kthena 本身不提供 Web UI，所有操作通过 kubectl 和 YAML 配置完成。这既是优势（Kubernetes 工程师无需学习新工具），也是门槛（非 K8s 用户需要额外的学习成本）。

---

六、争议与局限：成熟度与复杂度的博弈

局限性一：Router 仍为参考实现

项目文档明确指出，Kthena Router 是「reference implementation」——由于 Gateway Inference Extension 目前不支持原生 prefill-decode 分发路由，Router 的 PD 分离路由能力仍在活跃迭代中，生产环境使用前需谨慎评估。

局限性二：上手门槛较高

虽然 Helm Chart 降低了部署难度，但要真正用好 Kthena，团队需要同时具备 Kubernetes 运维能力和大模型推理工程经验。没有 K8s 基础的小团队几乎无法驾驭这套平台。

局限性三：vLLM 生态锁定

目前 Kthena 对 vLLM 的集成最为成熟，对其他推理引擎的支持程度参差不齐。选择 Kthena 意味着部分绑定于 vLLM 生态。

局限性四：项目相对年轻

作为 2025-2026 年兴起的项目，Kthena 的生产案例和社区规模相比 KServe、Triton Inference Server 等老牌方案还有差距，生态工具链（监控告警、日志收集、故障自愈）尚在完善中。

---

七、行业意义：Kubernetes 生态的 LLM 推理基建之战

LLM 推理的工程化是 2025-2026 年 AI Infra 领域最热门的赛道之一。从 vLLM、SGLang 等推理引擎的爆发，到 KServe、Triton 再到 Kthena 等平台层方案的涌现，整个生态正在经历从「能跑模型」到「能管模型」的范式升级。

Kthena 的差异化定位在于「深度拥抱 Kubernetes 生态」——它不试图替代 vLLM 或 SGLang，而是作为上层调度编排层，将这些推理引擎纳入 Kubernetes 的声明式管理体系。对于已经深度使用 Kubernetes 的企业（国内大量金融、政务、运营商客户），Kthena 提供了一条低迁移成本的 LLM 生产化路径。

随着 Volcano Scheduler 在 AI 调度领域的持续深耕，以及 Gateway API 标准的成熟，Kthena 有望成为 Kubernetes 生态中 LLM 推理的事实标准之一。

---

报告摘要

维度	评估
架构类型	云原生控制平面 + 数据平面分离架构
核心技术栈	Go, Kubernetes CRD, Gin, Redis, Volcano Scheduler
AI 框架集成	vLLM, SGLang, Triton, TorchServe
容器化程度	Dockerfile + Helm Chart，部署支持度 4/5
Web UI	无（纯 YAML/CLI 管理）
上手难度	较难（需 K8s 基础）
快速部署	部分支持（Helm Chart，但需 K8s 集群）
代码质量	高（完整 CI/CD、golangci-lint、自动化测试）
文档质量	高（官方文档站、架构图、多语言示例）
适用场景	企业级 LLM 推理平台、多模型管理、PD 分离优化、LoRA 热切换