Kthena：云原生 LLM 推理架构与调度系统深度解析本文深入分析 Volcano 社区新推出的 Kthena 项目，

Kthena：云原生 LLM 推理架构与调度系统深度解析

摘要：本文深入分析 Volcano 社区新推出的 Kthena 项目，这是一个面向 Kubernetes 的云原生 LLM 推理路由与编排调度系统。本文从架构设计、关键技术、性能优化、调度策略等维度，全面解析 Kthena 如何通过 KV Cache 感知调度、Prefill-Decode 分离路由、Gang 调度等核心技术，解决 LLM 服务部署中的资源利用率低、时延迟与吞吐量难以兼顾、多模型管理复杂等核心挑战。本文面向云原生 AI 基础设施工程师、系统架构师以及 LLM 服务运维人员。

1. 引言与背景

1.1 LLM 服务化生产环境的核心挑战

大语言模型正在以前所未有的速度重塑各行各业，将其高效、经济地部署在生产环境中，特别是基于 Kubernetes 的云原生平台上，仍然面临复杂系统工程的挑战。开发者和运维人员在 LLM 服务化过程中主要面临以下四个核心困境：

1. 低资源利用率

LLM 推理，尤其是其独特的 KV Cache 机制，对 GPU、NPU 显存的占用是动态且巨大的。传统负载均衡算法（如 Round-Robin）无法感知这种负载特性，导致 GPU、NPU 资源闲置与请求排队并存的现象同时存在，成本高昂。KV Cache 在多轮对话、模板化生成等场景中具有高度复用价值，但传统调度策略完全忽略了这一特性。

2. 时延迟与吞吐量难以兼顾

LLM 推理分为两个阶段：

Prefill（预填充）：处理输入提示词，计算密集型阶段
Decode（解码）：生成输出 Token，访存密集型阶段

将两者混合调度常常导致无法针对性优化，影响整体服务的响应速度和吞吐能力。因此 Prefill-Decode（PD）分离部署已成为主流实践，但如何实现高效的请求路由和 Pod 调度仍然是业界难题。

3. 多租户与多模型管理复杂

在企业环境中，通常需要同时提供多个不同模型、不同版本或经过 LoRA 微调的模型。如何实现请求的公平调度、优先级管理以及动态路由，是一个复杂的工程难题。业界甚至出现了一些方案将 AI 网关与大模型一一对应，这在大规模场景下显然不具备可扩展性。

4. 缺乏 K8s 原生集成

许多现有的解决方案要么是外部系统，与 Kubernetes 生态割裂；要么过于复杂，无法满足生产级所需的简单易用性和灵活运维。

1.2 云原生 LLM 推理的发展趋势

随着 AI 工作负载向云原生架构演进，LLM 推理平台呈现以下发展趋势：

趋势维度	传统方案	云原生演进方向
部署架构	单体部署、手动运维	容器化、声明式 API、自动扩缩容
调度策略	简单负载均衡	模型感知、拓扑感知、Gang 调度
多模型管理	分散部署、独立网关	统一路由、流量控制、动态编排
资源利用	静态分配、利用率低	智能调度、成本驱动、混部优化

Kthena 作为 Volcano 项目的子项目，正是顺应这一趋势，将 Volcano 在批处理和 AI 训练调度领域积累的拓扑感知、Gang 调度等核心经验，精准地应用到了 LLM 在线推理这一关键场景。

1.3 本文研究范围与目标读者

本文研究范围：

Kthena 的 Kubernetes 原生架构设计原理
KV Cache 感知调度、Prefill-Decode 分离路由等核心技术的实现机制
Gang 调度与网络拓扑感知在 LLM 推理场景中的应用
智能路由插件架构与负载均衡策略
实际部署配置与性能优化实践

目标读者：

云原生 AI 基础设施工程师
Kubernetes 集群运维工程师
LLM 推理服务开发者和运维人员
对云原生调度算法感兴趣的系统架构师

本文不涵盖：

LLM 模型训练相关技术
推理引擎（如 vLLM、SGLang）的内部实现
MLOps 流水线（模型训练、微调、评估）的完整生命周期

2. Kthena 架构概览

2.1 整体架构设计

Kthena 实现了一个 Kubernetes 原生的 LLM 推理平台，其架构采用了经典的控制平面（Control Plane）与数据平面（Data Plane）分离设计。

架构核心设计原则：

控制平面与数据平面解耦：Kthena-controller-manager 负责声明式资源管理和调度决策，Kthena-router 负责高性能请求路由。两个组件可以独立部署和扩展。
声明式 API 设计：通过 CRD 定义 LLM 工作负载，实现版本管理、回滚审计等企业级特性。
模型感知调度：调度决策充分考虑 LLM 推理的 KV Cache 特性、Prefill-Decode 分离等场景特性。
插件化扩展：路由调度算法、流量治理策略均采用插件化设计，支持自定义扩展。

2.2 核心组件详解

2.2.1 Kthena-controller-manager（控制平面）

Kthena-controller-manager 是平台的控制平面核心组件，负责管理 LLM 推理工作负载的完整生命周期。其主要功能模块包括：

控制器	核心职责	管理的 CRD
ModelServing Controller	编排 ServingGroup 与 Prefill/Decode 角色分组	ModelServing, ServingGroup, Role
ModelRoute Controller	生成/更新路由配置	ModelRoute, ModelServer
Autoscaler Controller	基于策略扩缩容	AutoscalingPolicy, AutoscalingPolicyBinding
GangScheduler Controller	管理 Volcano PodGroup 生命周期	PodGroup
ModelBooster Controller	开箱即用的模型上线模板	ModelBooster

工作流程：

// 伪代码：Kthena-controller-manager 的核心 Reconcile 逻辑
func (r *ModelServingReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    // 1. 获取 ModelServing 资源
    ms := &workloadv1alpha1.ModelServing{}
    if err := r.Get(ctx, req.NamespacedName, ms); err != nil {
        return ctrl.Result{}, client.IgnoreNotFound(err)
    }

    // 2. 调谐 ServingGroup
    if err := r.reconcileServingGroups(ctx, ms); err != nil {
        return ctrl.Result{}, err
    }

    // 3. 调谐 Role（LeaderWorkerSet）
    if err := r.reconcileRoles(ctx, ms); err != nil {
        return ctrl.Result{}, err
    }

    // 4. Gang 调度：创建/更新 Volcano PodGroup
    if ms.Spec.GangPolicy != nil {
        if err := r.reconcilePodGroup(ctx, ms); err != nil {
            return ctrl.Result{}, err
        }
    }

    // 5. 更新状态
    if err := r.updateStatus(ctx, ms); err != nil {
        return ctrl.Result{}, err
    }

    // 6. Requeue 如果需要继续观测
    return ctrl.Result{}, nil
}

2.2.2 Kthena-router（数据平面）

Kthena-router 是数据平面的入口组件，负责接收所有推理请求并根据 ModelRoute 规则进行智能分发。其核心特性包括：

多模型路由：根据请求头、Body 内容或 URI 模式将流量调度到不同模型
插件化调度算法：支持最少请求、最小时延、KV Cache 感知、Prefix Cache 感知、LoRA 亲和等多种负载均衡算法
PD Group 感知路由：对 Prefill-Decode 分离部署的流量进行智能分发
流量治理：基于权重的金丝雀发布、Token 级流控、故障转移

路由处理流程：

flowchart LR
    A[请求到达] --> B{请求解析}
    B --> C[模型识别<br/> Headers/Body/URI]
    C --> D[ModelRoute 匹配]
    D --> E[Load Balancer 选择<br/> 插件化算法]
    E --> F{Pod 打分}
    F --> G[KV Cache 感知评分]
    F --> H[最少请求评分]
    F --> I[延迟评分]
    G --> J[综合分数排序]
    H --> J
    I --> J
    J --> K[流量策略检查<br/> 限流/金丝雀/故障转移]
    K --> L[转发到目标 Pod]

2.3 组件间交互流程

Kthena 的核心交互流程涉及用户请求、路由组件、控制平面、Kubernetes API 以及实际的推理服务 Pod：

sequenceDiagram
    participant Client as 客户端
    participant Router
    participant Controller
    participant Scheduler as Volcano Scheduler
    participant Pods as Prefill/Decode Pods

    Client->>Router: 发起请求
    Router->>Controller: 识别模型
    Router->>Scheduler: 评分Pods
    Scheduler->>Pods: 调度决策
    Pods->>Pods: 创建Pod
    Pods-->>Scheduler: 调度结果
    Router->>Controller: 转发请求
    Controller-->>Client: 返回
    Pods-->>Scheduler: 上报指标
    Scheduler-->>Controller: 观测状态

3. 关键技术深度解析

3.1 KV Cache 感知调度

KV Cache（Key-Value Cache）是 LLM 推理中的核心优化技术，用于存储推理过程中的注意力计算中间结果。当新的请求与历史上已处理的请求具有相似的前缀时，复用 KV Cache 可以大幅减少计算量。

3.1.1 技术背景

在 LLM 推理的 Attention 计算中，对于序列 $\boldsymbol{x} = (x_1, x_2, \dots, x_n)$ ，第 $t$ 步的 hidden state 为：

\boldsymbol{h}_t = \text{Attention}(\boldsymbol{h}_{t-1}, \boldsymbol{x}_t)

KV Cache 存储的是位置 $t$ 之前的 Key 和 Value 矩阵：

\boldsymbol{K}_{1:t} = [\boldsymbol{K}_1, \boldsymbol{K}_2, \dots, \boldsymbol{K}_t], \quad \boldsymbol{V}_{1:t} = [\boldsymbol{V}_1, \boldsymbol{V}_2, \dots, \boldsymbol{V}_t]

当新请求的前缀与已缓存的序列匹配时，可以跳过前缀的计算，直接从第 $k+1$ 步开始推理。

3.1.2 令牌级块匹配算法

Kthena 的 KV Cache 感知插件采用令牌级块匹配（Token-level Block Matching）而非字节级匹配，通过以下步骤实现智能路由： KV Cache 感知调度流程

输入提示词
    ↓
Tokenizer (模型特定)
    ↓
Token 序列分割为固定块 (默认 128 tokens/block)
    ↓
每个块生成 SHA-256 哈希
    ↓
Redis 批量查询: 哪些 Pod 缓存了这些块
    ↓
连续块匹配评分
    ↓
Pod 排序和选择

关键参数配置：

# KVCacheAware 配置
blockSizeToHash: 128      # 每个 block 的 token 数
maxBlocksToMatch: 128     # 最多处理的 block 数量
redis:
  addr: "redis-service:6379"
  timeout: 100ms

3.1.3 评分算法

KV Cache 感知插件的评分算法基于连续块匹配原则：

核心思想：只有当一个 Pod 具有从第一个块开始的连续匹配块时，该 Pod 才会被认为是"命中"的候选。这种设计确保了实际可用的 KV Cache 复用。

评分公式：

\text{Score(pod)} = \frac{\text{consecutive\_matches}}{\text{total\_blocks}} \times 100

其中：

consecutive_matches：从第一个块开始的连续匹配块数
total_blocks：输入提示词的总 block 数
评分范围：0-100，分数越高表示 KV Cache 命中潜力越大

第一块过滤优化：首先筛选出只具有第一个 token block 的 Pod，然后逐个检查后续块是否连续命中。若无 Pod 满足连续匹配，则立即终止并采用次优算法。

3.1.4 Redis 数据结构设计

KV Cache 感知插件使用 Redis Hash 结构存储 block 到 pod 的映射关系：

Key 格式：matrix:kv:block:{model}@{hash}

示例：

Key: "matrix:kv:block:deepseek-ai/DeepSeek-R1-Distill-Qwen-7B@e2d8c3a4b5f6..."
Fields: {
  "pod-name-1.namespace.svc.cluster.local": "1703123456",   # 时间戳
  "pod-name-2.namespace.svc.cluster.local": "1703123789"
}

批查询优化：使用 Redis Pipeline 一次性查询所有 block，减少网络往返次数。

3.1.5 Chat Template 支持

针对 Chat Completion 请求，插件支持自动解析 ChatML 格式并提取 role 和 content：

# 伪代码：Chat Template 处理
def process_chat_completion(messages):
    tokens = []
    for msg in messages:
        # ChatML 格式处理
        tokens.extend(tokenizer.encode(f"<|{msg['role']}|>\n"))
        tokens.extend(tokenizer.encode(msg['content']))
        tokens.extend(tokenizer.encode("<|end|>\n"))
    return tokens

3.1.6 性能优化策略

优化策略	原理	参数配置
Block 大小调优	大 block 减少 Redis 查询，小 block 提高匹配粒度	`blockSizeToHash: 128` (默认)
最大块数限制	防止超长提示词过度计算	`maxBlocksToMatch: 128`
Pipeline 批查询	单次网络往返查询所有 block	内置实现
提前终止	无连续匹配时立即停止评分	内置实现

3.2 Prefill-Decode 分离路由

3.2.1 推理阶段特性分析

Prefill 阶段（预填充）：

特性：计算密集型，矩阵乘法运算量大
硬件需求：高算力 GPU（如 NVIDIA A100/H100）
延迟特点：与输入长度线性相关

Decode 阶段（解码）：

特性：访存密集型，频繁读写 KV Cache
硬件需求：高显存带宽 GPU（如 NVIDIA A40, RTX 4090）
延迟特点：每个 token 的延迟相对稳定

资源利用率优化机会：将 Prefill 和 Decode 分离部署到不同类型的节点上，可以最大化硬件利用率并优化端到端时延。

3.2.2 Kthena 的 PD 分离架构

Kthena 通过三层次架构支持 Prefill-Decode 分离部署：

Prefill-Decode 分离路由架构转存失败，建议直接上传图片文件

ModelServing 架构图

ModelServing (顶层)
    ↓
ServingGroup (中间层，xPyD 分组)
    ↓
Role (底层，Prefill/Decode 角色)

层次说明：

ModelServing：表示一个模型服务实例，可包含多个 ServingGroup
ServingGroup：表示一个完整的推理单元（如 1P3D 配置），包含一组 Role
Role：表示具体的推理角色（prefill 或 decode），每个 Role 对应一个 LeaderWorkerSet

配置示例（1P3D 分离部署）：

apiVersion: workload.serving.volcano.sh/v1alpha1
kind: ModelServing
metadata:
  name: deepseek-r1-inference
spec:
  replicas: 2  # 创建 2 个 ServingGroup
  model:
    name: "deepseek-ai/DeepSeek-R1-Distill-Qwen-7B"
    framework: vllm
  template:
    roles:
      - name: prefill
        replicas: 1  # 每个 ServingGroup 1 个 prefill pod
        resources:
          requests:
            nvidia.com/gpu: "1"
          limits:
            nvidia.com/gpu: "1"
        nodeSelector:
          gpu-type: "compute-optimized"  # 高算力节点

      - name: decode
        replicas: 3  # 每个 ServingGroup 3 个 decode pod
        resources:
          requests:
            nvidia.com/gpu: "1"
          limits:
            nvidia.com/gpu: "1"
        nodeSelector:
          gpu-type: "memory-optimized"  # 高带宽节点

上述配置将创建 2 个 ServingGroup（每个包含 1 prefill + 3 decode 的 Pod 组）。

3.2.3 PD 流量路由策略

Kthena-router 原生支持 Prefill-Decode 分离的流量路由：

流量类型	路由目标	策略说明
新请求	Prefill Pods	需要全量计算，路由到 prefill
延续请求	Decode Pods	KV Cache 已存在，路由到 decode
混合场景	动态选择	根据 KV Cache 命中情况选择

路由决策伪代码：

func (r *Router) routeRequest(req *InferenceRequest) *Pod {
    // 1. 检查KV Cache命中情况
    cacheHits := r.checkKVCache(req.Prompt)

    if len(cacheHits) > 0 {
        // 有KV Cache命中，路由到decode
        return r.selectDecodePod(req, cacheHits)
    } else {
        // 无KV Cache命中，路由到prefill
        return r.selectPrefillPod(req)
    }
}

3.2.4 并行计算模式支持

Kthena 支持多种并行计算模式，可根据模型规模和资源情况进行配置：

并行模式	缩写	适用场景	Kthena 支持
Tensor Parallelism	TP	单机多卡，小模型	✅ (通过 workerReplicas)
Pipeline Parallelism	PP	多机流水线，大模型	✅ (通过 ServingGroup 串联)
Data Parallelism	DP	多副本，服务扩容	✅ (通过 replicas)
Expert Parallelism	EP	MoE 模型	✅ (通过自定义配置)

3.3 Gang 调度与拓扑感知

3.3.1 Gang 调度的必要性

在 Prefill-Decode 分离部署场景下，一个推理单元需要同时调度一组 Pod（如 1 prefill + 3 decode）。传统 Kubernetes 调度器无法保证这些 Pod 约束地、完整地调度到集群中，可能导致以下问题：

资源碎片化：部分 Pod 调度成功，部分 Pod 持续 Pending
性能下降：分散在不同网络域的 Pod 间通信延迟高
SLO 违约：推理服务无法完整启动，影响用户可用性

Gang 调度确保相关 Pod 作为一个原子单元被调度，要么全部成功，要么全部重新尝试。

Gang 调度流程

3.3.2 Kthena 的 Gang 调度实现

Kthena 复用 Volcano 的 PodGroup 机制实现 Gang 调度：

PodGroup 配置：

apiVersion: scheduling.volcano.sh/v1beta1
kind: PodGroup
metadata:
  name: {modelinfer-name}-{inferGroup-index}
  namespace: {modelinfer-namespace}
  labels:
    modelinfer.volcano.sh/name: {modelinfer-name}
  annotations:
    scheduling.k8s.io/group-name: {modelinfer-name}
spec:
  # minTaskMember 定义每个 role replica 需要的最小 pod 数
  minTaskMember:
    "prefill-0": 4     # 1 entry + 3 workers for prefill role replica 0
    "decode-0": 12     # 1 entry + 3 workers × 3 replicas for decode role
  minResources:
    nvidia.com/gpu: "4"
  ttlSecondsAfterFinished: 3600

minTaskMember 计算规则：

未配置 MinRoleReplicas：
$\text{minMember} = \text{replicas} \times \sum(\text{role.replicas} \times (1 + \text{role.workerReplicas}))$
已配置 MinRoleReplicas：仅包含 index 从 0 到 MinRoleReplicas[roleName] - 1 的 role replicas

Pod 注解策略：

每个被 ModelServing Controller 创建的 Pod 都会被注解 PodGroup 信息：

metadata:
  annotations:
    scheduling.k8s.io/group-name: "deepseek-r1-inference"
    volcano.sh/task-spec: |-
      {"name":"prefill-0","minMember":4}

3.3.3 网络拓扑感知调度

现代 AI 集群的网络架构呈现多样化特征（如 CLOS、Spine-Leaf、Full Mesh、Torus 等），不同拓扑下的网络性能差异显著。Kthena 集成 Volcano 的 NetworkTopology 功能，支持基于 HyperNode 的拓扑约束调度。

HyperNode 概念：HyperNode 是 Volcano 引入的一种抽象，用于表示具有相似网络拓扑特性的节点集合。

拓扑约束配置：

spec:
  gangPolicy:
    minRoleReplicas:
      prefill: 2
      decode: 1
    networkTopology:
      mode: hard              # 约束模式
      highestTierAllowed: 2   # 最高允许的层级

模式说明：

模式	约束类型	适用场景
hard	硬约束	低延迟需求的推理服务
soft	软约束	尽量拓扑优化的场景

网络拓扑架构对比：

拓扑类型	特点	调度策略
CLOS / Spine-Leaf	层次化，可扩展良好	限制在同一 Pod 或 Rack
Full Mesh / NVLink	全互联，零阻塞	Pod 必须在相同 SuperPOD
Ring / Torus	高维连接，短路径	调度到低跳数相邻节点

3.3.4 调度流程

sequenceDiagram
    participant C as Client
    participant S as Kthena Controller
    participant V as Volcano Scheduler
    participant K as K8s API Server

    C->>S: 创建 ModelServing
    S->>S: 计算 ServingGroup 和 Role
    S->>V: 创建 PodGroup (minTaskMember 配置)
    S->>K: 创建 Pod (带 group-name 注解)
    V->>V: Gang 调度决策
    V->>V: 拓扑约束检查
    V->>K: 调度结果 (原子化)
    K->>C: Pod 状态更新

3.4 成本驱动自动扩缩容

3.4.1 同构伸缩与异构部署

Kthena 的 Autoscaler 支持两种伸缩模式：

同构伸缩：

在相同的硬件配置上进行 Pod 数量扩容或缩容
适用于训练硬件资源均匀的场景 -伸缩依据：业务指标（CPU/GPU/内存利用率）或自定义指标

异构部署优化：

在多推理引擎（vLLM、SGLang、Triton）和异构加速器（NVIDIA GPU、昇腾 NPU）组合下实现成本-能力优化
伸缩决策考虑硬件成本、推理性能、SLO 约束

贪心分配算法（简化描述）：

输入: 计算能力需求 C, 成本约束 B
输出: 异构部署方案 Plan

for each 加速器类型 accelerator in sorted_by_cost:
    compute 每单位成本的推理收益 throughput_per_cost
    select accelerator(s) maximizing throughput_per_cost
    if total_cost <= B:
        include in Plan
    else:
        continue to next accelerator

return Plan

3.4.2 AutoscalingPolicy 配置

apiVersion: workload.serving.volcano.sh/v1alpha1
kind: AutoscalingPolicy
metadata:
  name: deepseek-autoscaling
spec:
  # 扩缩容触发指标
  metrics:
    - type: gpu
      target:
        type: Utilization
        averageUtilization: 70
    - type: custom
      target:
        type: AverageValue
        averageValue: "1000"  # requests per second

  # 扩缩容配置
  minReplicas: 1
  maxReplicas: 10

  # 成本约束（异构部署）
  costBudget:
    currency: USD
    limit: 1000  # 月预算上限
    priority: ["nvidia.com/gpu:a40", "nvidia.com/gpu:h100"]

  # 扩容策略
  scaleUp:
 stabilizationWindowSeconds: 300
 policies:
   - type: Pods
     value: 2
     periodSeconds: 60

  scaleDown:
 stabilizationWindowSeconds: 900
 policies:
   - type: Percent
     value: 30
     periodSeconds: 300

3.4.3 绑定配置

AutoscalingPolicy 通过 AutoscalingPolicyBinding 绑定到目标资源：

apiVersion: workload.serving.volcano.sh/v1alpha1
kind: AutoscalingPolicyBinding
metadata:
  name: deepseek-binding
spec:
  policyRef:
    name: deepseek-autoscaling
  targetRef:
    name: deepseek-r1-inference
    kind: ModelServing

4. 智能路由与流量控制

4.1 路由插件架构

Kthena-router 采用插件化架构设计，支持多种负载均衡算法的灵活组合和热插拔。

插件接口定义（简化）：

type ScorePlugin interface {
    Name() string
    Score(ctx *Context, pods []*PodInfo) map[*PodInfo]int
    Normalize(ctx *Context, scores map[*PodInfo]int)
}

内置插件清单：

插件名称	核心功能	适用场景
KVCacheAware	KV Cache 命中度评分	多轮对话、模板化生成
PrefixCacheAware	Prefix Cache 命中度评分	短提示词、多场景混合
LeastRequest	最少请求数负载均衡	静态负载均衡
LatencyAware	实时延迟评分	低延迟优先场景
LoRAAffinity	LoRA 适配器亲和性	LoRA 微调模型服务
GPUTilizationAware	GPU 利用率分数	资源均衡利用
FairScheduling	基于优先级的公平调度	多租户环境

插件组合示例：

# Router 配置示例
router:
  plugins:
    - name: KVCacheAware
      weight: 0.6
    - name: LeastRequest
      weight: 0.4
  # 加权综合评分
  scoringStrategy: weightedAverage

4.2 负载均衡算法

4.2.1 KV Cache 感知算法

已在 3.1 节详细介绍，此处补充性能对比数据：

场景	策略配置	吞吐	TTFT	E2E 时延
长系统提示词 (4096 tokens)	KVCache + LeastRequest	32.22	9.22	0.57
长系统提示词	PrefixCache + LeastRequest	23.87	12.47	0.83
长系统提示词	Random	11.81	25.23	2.15
提升幅度	-	+2.73x	-73.5%	-60%

4.2.2 最少请求算法

LeastRequest 算法将请求路由到当前请求数最少的 Pod：

\text{Score(pod)} = -\text{active\_requests(pod)}

优势：实现简单的负载均衡，适用于请求均匀分布的场景。

4.2.3 延迟感知算法

LatencyAware 算法基于实时的 P99 延迟数据进行评分：

\text{Score(pod)} = \frac{1}{\text{p99\_latency(pod)} + \epsilon}

其中 $\epsilon$ 避免除零错误。

4.3 流量治理策略

4.3.1 基于权重的模型路由

支持按照权重将流量分发到不同的 ModelServer：

apiVersion: workload.serving.volcano.sh/v1alpha1
kind: ModelRoute
metadata:
  name: deepseek-route
spec:
  model: "deepseek-ai/DeepSeek-R1"
  routes:
    - name: primary
      weight: 80
      server:
        name: deepseek-primary
      trafficPolicy:
        type: baseline

    - name: canary
      weight: 20
      server:
        name: deepseek-canary
      trafficPolicy:
        type: canary

4.3.2 金丝雀发布

通过权重配置实现渐进式发布，降低风险：

阶段	Canary 权重	Primary 权重	观察时长
初始	5%	95%	1 小时
扩大	25%	75%	4 小时
全面	100%	0%	-

4.3.3 Token 级流控

支持基于用户、模型或 Token 长度的精细化流控：

apiVersion: workload.serving.volcano.sh/v1alpha1
kind: TrafficPolicy
metadata:
  name: rate-limit-policy
spec:
  rateLimits:
    - type: user
      limit:
        requestsPerSecond: 10
        tokensPerSecond: 5000
    - type: model
      selector:
        model: "deepseek-ai/DeepSeek-R1"
      limit:
        requestsPerSecond: 100

4.3.4 故障转移

当 ModelServer 健康状态异常时，自动将流量转移到健康实例：

stateDiagram-v2
    [*] --> 正常路由
    正常路由 --> 健康检查: 定期探测
    健康检查 --> 正常路由: 健康
    健康检查 --> 故障状态: 不健康
    故障状态 --> 流量转移: 标记为不可用
    流量转移 --> 正常路由: 恢复健康

5. 部署实践与性能分析

5.1 环境要求与安装部署

5.1.1 前置条件

组件	版本要求	说明
Kubernetes	>= 1.25	支持 CRD 和 LeaderWorkerSet
Volcano	>= v1.11	提供 Gang 调度和拓扑感知功能
GPU 驱动	CUDA 11.8+	NVIDIA GPU 支持
Hugging Face Token	有效	如从 Hugging Face Hub 加载模型

5.1.2 安装 Volcano

# 添加 Volcano Helm 仓库
helm repo add volcano-sh https://volcano-sh.github.io/helm-charts
helm repo update

# 安装 Volcano
helm install volcano volcano-sh/volcano \
  -n volcano-system \
  --create-namespace

# 验证安装
kubectl get pods -n volcano-system

5.1.3 安装 Kthena

# 安装 Kthena（推荐使用 Helm）
helm install kthena oci://ghcr.io/volcano-sh/charts/kthena \
  --version v0.1.0 \
  -n kthena-system \
  --create-namespace

# 验证 CRD 安装
kubectl get crd | grep serving.volcano.sh

# 应该看到：
# modelservings.workload.serving.volcano.sh
# modelroutes.workload.router.kthena.io
# autoscalingpolicies.workload.scale.kthena.io

5.1.4 快速启动（本地）

# 从代码仓库快速启动（开发测试用）
git clone https://github.com/volcano-sh/kthena.git
cd kthena
./hack/local-up-kthena.sh --help

5.2 配置示例与实践

5.2.1 单模型基础部署

apiVersion: workload.serving.volcano.sh/v1alpha1
kind: ModelServing
metadata:
  name: llama-3-8b-instruct
spec:
  model:
    name: "meta-llama/Meta-Llama-3-8B-Instruct"
    framework: vllm

  replicas: 1

  template:
    roles:
      - name: worker
        replicas: 2
        resources:
          requests:
            cpu: "4"
            memory: "16Gi"
            nvidia.com/gpu: "1"
          limits:
            cpu: "8"
            memory: "32Gi"
            nvidia.com/gpu: "1"

    containers:
      - name: vllm-server
        image: vllm/vllm-openai:latest
        args:
          - "--model=$(MODEL_NAME)"
          - "--port=8000"
          - "--gpu-memory-utilization=0.9"
        env:
          - name: MODEL_NAME
            value: "meta-llama/Meta-Llama-3-8B-Instruct"
        ports:
          - containerPort: 8000

5.2.2 Prefill-Decode 分离部署（含 Gang 调度）

apiVersion: workload.serving.volcano.sh/v1alpha1
kind: ModelServing
metadata:
  name: deepseek-r1-pd-split
spec:
  replicas: 2  # 创建 2 个 ServingGroup

  model:
    name: "deepseek-ai/DeepSeek-R1-Distill-Qwen-7B"
    framework: vllm

  # Gang 调度配置
  gangPolicy:
    minRoleReplicas:
      prefill: 2
      decode: 2
    networkTopology:
      mode: soft
      highestTierAllowed: 2

  template:
    roles:
      - name: prefill
        replicas: 1  # 每个 ServingGroup 1 个 prefill
        resources:
          requests:
            nvidia.com/gpu: "1"
          limits:
            nvidia.com/gpu: "1"
        nodeSelector:
          gpu-type: compute-optimized
        # 配置 prefill 特定参数
        runtime:
          vllm:
            max-model-len: 32768

      - name: decode
        replicas: 3  # 每个 ServingGroup 3 个 decode
        resources:
          requests:
            nvidia.com/gpu: "1"
          limits:
            nvidia.com/gpu: "1"
        nodeSelector:
          gpu-type: memory-optimized
        # 配置 decode 特定参数
        runtime:
          vllm:
            max-num-seqs: 256
            enable-prefix-caching: true

    containers:
      - name: vllm-engine
        image: vllm/vllm-openai:latest
        args:
          - "--model=$(MODEL_NAME)"
          - "--port=8000"
          - "--tensor-parallel-size=1"
        env:
          - name: MODEL_NAME
            valueFrom:
              configMapKeyRef:
                name: model-config
                key: model-name

5.2.3 ModelRoute 配置

apiVersion: workload.router.kthena.io/v1alpha1
kind: ModelRoute
metadata:
  name: inference-route
spec:
  # 模型选择规则
  selector:
    header:
      - key: X-Model-Name
        default: "default-model"

  # 后端 Server 指定
  backend:
    name: deepseek-r1-inference
    namespace: default

  # 路由策略
  routingPolicy:
    loadBalancer:
      plugins:
        - name: KVCacheAware
          weight: 60
        - name: LeastRequest
          weight: 40

  # 流量策略
  trafficPolicy:
    rateLimits:
      - type: global
        limit:
          requestsPerSecond: 1000
    failover:
      enabled: true
      maxRetries: 3
      retryDelay: 100ms

5.3 性能测试数据与分析

转存失败，建议直接上传图片文件

5.3.1 测试环境

配置项	值
集群规模	4 节点，每节点 4 x NVIDIA A100 (40GB)
模型	DeepSeek-R1-Distill-Qwen-7B
推理引擎	vLLM v0.5.0
测试工具	Locust
提示词长度	4096 tokens (长系统提示词场景)

5.3.2 性能对比数据

调度策略	吞吐 (req/s)	TTFT (s)	E2E 时延 (s)	相对提升
Random (基线)	11.81	25.23	2.15	0%
LeastRequest	18.45	16.87	1.23	+56%
PrefixCacheAware + LeastRequest	23.87	12.47	0.83	+102%
KVCacheAware + LeastRequest	32.22	9.22	0.57	+173%

5.3.3 吞吐-延迟曲线

吞吐量 (req/s)
  ^
  |                   KVCache
  |                  /  |
  |                 /   |
  |          PC    /    |
  |         /     /     |
  |        /     /      |
  |   LR  /     /       |
  |     /     /        |
  |    /     /         |
  |   /_____/___ Random
  |  /
  | /
  +---------------------------> 延迟 (s)

5.3.4 不同提示词长度的适用性分析

提示词长度	最优策略	性能提升原因
< 512 tokens	LeastRequest	KV Cache 收益有限，简单 LB 足够
512-2048 tokens	PrefixCacheAware	适度长度下 partial hit 效果明显
> 2048 tokens	KVCacheAware	长提示词下连续块匹配收益最大化
多轮对话	KVCacheAware + FairScheduling	上下文复用 + 公平调度

6. 总结与展望

6.1 技术价值总结

Kthena 作为 Volcano 社区推出的云原生 LLM 推理平台，在以下方面提供了显著的技术价值：

1. 云原生集成与声明式管理

通过 CRD 将 LLM 推理工作负载纳入 Kubernetes 原生管理体系
实现了模型生命周期的声明式 API 管理，支持版本管理、滚动更新、故障恢复等企业级特性

2. 智能调度与资源优化

KV Cache 感知调度将传统负载均衡提升到模型语义层面
Prefill-Decode 分离路由实现了计算密集型和访存密集型任务的硬件最优匹配
Gang 调度与网络拓扑感知确保了分布式推理的原子性和性能

3. 性能提升与成本优化

在长提示词场景下，吞吐量提升 2.73 倍，TTFT 降低 73.5%
成本驱动的自动扩缩容实现了异构硬件环境下的最优性价比

6.2 当前局限性与挑战

局限性	说明	潜在改进方向
推理引擎依赖性	当前实现紧耦合于特定推理引擎架构	更通用的模型无关抽象层
拓标感知复杂度	HyperNode 配置和拓扑信息管理复杂	自动拓扑发现和简化配置
多模型路由规模	大规模多模型场景下的路由决策复杂度增加	引入机器学习辅助路由决策
监控可观测性	深度性能指标（如具体的 KV Cache 命中率）采集不完整	增强可观测性与性能诊断能力

6.3 未来发展方向

短期 (6-12 个月)：

支持更多推理引擎（如 TensorRT-LLM、LMDeploy）
增强可观测性，提供更细粒度的性能指标
优化网络拓扑感知，支持更多网络架构

中期 (1-2 年)：

跨集群调度，实现多云、多集群的统一推理管理
引入机器学习辅助的智能路由决策
支持更多 AI 硬件（如 AMD ROCm、Intel Gaudi）

长期 (2 年以上)：

构建完整的云原生 AI 生态，集成训练、推理、数据管理全链路
与 CNCF 其他项目深度集成（如 Istio 服务网格、Prometheus 监控）
推动行业标准制定，促进云原生 AI 基础设施标准化

7. 术语表

术语	全称	定义
KV Cache	Key-Value Cache	LLM 推理中存储注意力计算中间结果的缓存机制
Prefill	-	LLM 推理的第一个阶段，处理输入提示词，计算密集型
Decode	-	LLM 推理的第二个阶段，生成输出 Token，访存密集型
PD 分离	Prefill-Decode Separation	将 Prefill 和 Decode 阶段分离部署的调度策略
xPyD	x-Prefill/y-Decode	自定义的 Prefill-Decode 比例配置（如 1P3D）
Gang Scheduling	组调度	确保相关任务作为一个原子单元一同调度的调度策略
PodGroup	-	Volcano 定义的 CRD，用于实现 Gang 调度
HyperNode	-	Volcano 定义的拓扑抽象，表示具有相似网络特性的节点集合
TP/PP/DP/EP	Tensor/Pipeline/Data/Expert Parallelism	四种主流的模型并行计算模式
SLO	Service Level Objective	服务目标，用于衡量服务质量
TTFT	Time to First Token	首个 Token 响应时间
LoRA	Low-Rank Adaptation	参数高效微调方法
CRD	Custom Resource Definition	Kubernetes 自定义资源定义

8. 参考文献

Volcano 社区. Introducing Kthena: LLM inference for the cloud native era. CNCF Blog, 2026.
Volcano 社区. Introducing Kthena: Redefining LLM Inference for the Cloud-Native Era. Volcano Blog, 2026.
vLLM Team. Kthena Integration. vLLM Documentation, 2025.
GitHub Repository. volcano-sh/kthena. GitHub, 2025.
Kevin Wang. Intelligent Topology for AI Power: Network-Aware Scheduling with Volcano HyperNode. KubeCon NA 2025.
Volcano Project. Network Topology Aware Scheduling. Documentation, 2025.

关注我们

欢迎关注 【维度坍缩】，获取更多云原生 AI、Kubernetes 调度、大模型推理等前沿技术内容！

声明：本文基于公开资料和官方文档撰写，部分配置示例和性能数据来源于 Kthena 官方发布。实际部署性能可能因环境配置、模型选择、业务场景等因素有所不同，建议在生产部署前进行充分的性能测试和调优。

Kthena：云原生 LLM 推理架构与调度系统深度解析