Kthena：LLM 推理的 GPU 调度与控制面

草稿

推理平台的核心竞争力在于能否将模型语义、显存状态与请求路径统一纳入治理，实现可观测、可控与可演进的 GPU 调度闭环。

本章以 Kthena 为案例，重点讨论 大语言模型（LLM）在线推理如何将 GPU 治理从“资源分配”升级为“语义调度”。推理请求进入集群后，调度决策必须同时感知模型、显存（KV Cache）、阶段（Prefill/Decode）以及多租户治理策略，否则在规模化场景下，吞吐、尾延迟与成本会出现系统性失控。

推理为何放大了 GPU 治理难度

推理与训练的系统工程特性存在显著差异。训练更像“批处理吞吐问题”，而在线推理则是“请求路径上的系统工程”。推理的复杂性主要体现在以下几个方面：

  • KV Cache 显存占用具有强状态性与动态性。同一张卡在不同时间的可服务能力差异极大，传统负载均衡（如 Round-Robin）无法感知显存状态，导致“有卡不敢用/有卡用不了/排队抖动并存”。
  • Prefill 与 Decode 的资源画像差异显著。Prefill 更偏算力密集，Decode 更偏访存密集。混合运行会抹平优化空间，并放大尾延迟。
  • 多模型、多版本、多 LoRA 适配器成为常态。请求路由与公平性、优先级、限流策略必须纳入统一治理，否则平台只能通过“一个模型一套网关/一套部署”硬拆，运维复杂度不可控。

因此，推理侧的 GPU 调度已不再是简单的“把 Pod 放到节点上”，而是将请求路由、模型生命周期、弹性伸缩与资源调度组合成一个闭环控制系统。

推理侧需要哪些“新调度语义”

为了让推理在规模化场景下可控，平台需要引入一些 Kubernetes 原生调度难以表达、但对推理至关重要的语义：

Prefill/Decode 分离（PD Disaggregation）

图 1: Prefill/Decode 分离架构
图 1: Prefill/Decode 分离架构
  • 目标：将不同资源画像的阶段拆开部署与独立伸缩，并通过路由保持端到端语义一致。
  • 关键：路由必须具备“PD group aware”能力，否则分离部署会转化为新的排队与抖动。

KV Cache / Prefix Cache 感知

  • 目标：让请求进入“最合适”的实例，而不是“下一个轮到的实例”。
  • 关键：将显存状态纳入负载均衡与限流策略，否则吞吐与 TTFT（Time To First Token）/E2E 会在高并发时快速劣化。

多模型与 LoRA 亲和

  • 目标：在同一平台上支持基础模型与 LoRA（Low-Rank Adaptation）适配器的热插拔、灰度发布与路由策略，降低“模型爆炸”带来的运维成本。
  • 关键：请求分类（model name/header/URI）与后端实例状态（已加载哪些适配器）需要在路由面汇合。

拓扑与 Gang 语义进入推理

  • 目标：在多实例并行（如 TP/PP/EP 等）或 xPyD 组合下，将一组实例作为“原子单元”部署与调度，并尽可能置于同一网络域/更优拓扑中，降低通信成本与尾延迟风险。

这些语义共同指向一个结论：推理需要自己的控制面与数据面协同。

Kthena 架构：控制面与数据面的分工

图 2: Kthena 架构：控制面与数据面
图 2: Kthena 架构：控制面与数据面

Kthena 的创新之处在于将推理平台拆分为两类核心组件，实现控制面与数据面的协作：

Kthena Controller Manager（控制面）

  • 负责 LLM 工作负载的声明式编排与生命周期管理，包括部署、升级、扩缩容、故障恢复等。
  • 通过 CRD（Custom Resource Definition，自定义资源定义）将“推理特有语义”变成可治理对象，并将部分调度策略对接 Volcano 调度能力。

Kthena Router（数据面）

  • 位于请求路径入口，根据 model name、headers、URI 等规则对请求分类，并执行可插拔的负载均衡与流量治理策略。
  • 原生支持 PD 分离路由，并可实现 KV-cache 感知等策略，弥补通用网关在推理场景下的能力缺口。

这种分工使 Kthena 更接近一个“推理侧的控制闭环”：控制面负责“系统应该长成什么样”，数据面负责“每个请求该去哪里”。

CRD 抽象：让推理生命周期成为 Kubernetes 一等公民

Kthena 的核心思路是通过 CRD 将推理工作负载抽象为 Kubernetes 可声明对象（如 ModelServing），平台因此能够：

  • 用声明式 API 表达推理部署形态（单体、PD 分离、并行范式等）。
  • 用策略对象表达自动伸缩与成本约束。
  • 用路由对象表达多模型、灰度、权重与故障转移。

从 GPU Infra 的角度看，这一步的价值在于：将推理的“业务语义”显式化，让调度与治理不再依赖脚本与人肉经验。

路由与流量治理：调度策略进入请求路径

推理与训练的最大差异之一在于：推理的调度结果必须体现在“每一次请求”的路径上。

因此，Kthena Router 的能力可以理解为“将调度策略下沉到请求级别”，具体包括：

  • 多模型路由（兼容 OpenAI API 风格的请求形态）。
  • 可插拔负载均衡策略（如最少请求、最小时延、KV-cache 感知等）。
  • PD 分离与 xPyD 组的请求分配。
  • 金丝雀、权重、token 级限流、failover 等流量治理。

在更长周期里，推理平台的竞争力通常不来自“能不能跑起来”，而在于这些策略能否在真实业务负载下持续演进、可观测、可回滚。

生态定位：Kthena 与 Volcano / Kueue / vLLM 的关系

为避免“清单式盘点”，可用职责边界来理解这些组件的协作关系：

  • vLLM / SGLang / Triton：推理引擎（执行层），负责模型执行效率、KV cache 管理等内部机制。
  • Kthena：推理平台层（控制面 + 路由面），负责将推理引擎纳入 Kubernetes 的声明式治理，并在请求路径执行调度与流量策略。
  • Volcano：通用调度增强（偏批处理与成组语义），为复杂工作负载补齐 gang、queue、公平性等调度语义。
  • Kueue：组织治理与准入（配额、承诺、队列化），解决“谁能用多少、何时能用”的平台运营问题。

换句话说，Kthena 将推理的“在线语义”补进了 GPU 控制面地图，这是 Volcano（训练/批处理取向）与 vLLM（执行层取向）之间原本缺失的层。

可观测与验收：推理指标纳入 GPU 平台口径

推理侧建议至少将以下指标纳入统一验收口径，并与后续章节（观测与计量、验收与容量）对齐：

  • 吞吐（req/s 或 tokens/s）
  • TTFT（Time To First Token）
  • E2E Latency（尤其是 P95/P99）
  • GPU 利用率与显存占用曲线（含 KV cache 占用）
  • 丢弃率、限流命中率、重试与 failover 次数

这些指标不仅用于性能对比，更用于验证策略是否真正改善了尾延迟与成本结构。

总结

Kthena 作为 Volcano 生态中的推理平台案例，最重要的启示在于：当推理成为主流工作负载后，GPU Infra 必须具备将模型语义、显存状态与请求路径统一纳入治理的能力。否则平台会退化为“能跑但不可控”，吞吐与延迟被负载随机性主导，成本被资源空转与排队抖动吞噬。

下一章（vLLM）将从执行层解释 KV cache 如何放大共享与干扰问题；实验章节则会进一步用可复现基线验证：在缺乏语义调度的情况下，尾延迟如何被系统性放大。

创建于 2026/01/05 更新于 2026/01/05 2545 字 阅读约 6 分钟