跳转到内容

Kthena AI 推理平台面试题库

30 道题
分类
Kubernetes
子分类
llm
题目数
30 道
已阅读 0 / 30 题
1 Kthena 是什么?它与 Volcano 的关系是什么?

答案:

Kthena 是由 Volcano(CNCF 孵化项目)社区推出的 Kubernetes 原生 AI 推理服务平台,专为 LLM(大语言模型)推理工作负载设计。Kthena 在 Volcano 批调度能力之上,构建了完整的推理生命周期管理,包括模型部署、流量路由、弹性伸缩、Prefill-Decode 分离等核心能力。

[核心定位]

维度说明
项目归属Volcano 社区子项目
核心定位Kubernetes 原生 LLM 推理平台
调度基础复用 Volcano Gang Scheduling 与 PodGroup
目标工作负载LLM 推理(vLLM/SGLang/Triton/TorchServe)
核心能力一键部署、PD 分离、弹性伸缩、智能路由

[架构关系]

graph LR
    A["Volcano<br/>批调度引擎"] --> B["Kthena<br/>AI 推理平台"]
    B --> C["Control Plane<br/>CRD 控制器"]
    B --> D["Data Plane<br/>Router 路由网关"]
    C --> E["ModelBooster<br/>一键部署"]
    C --> F["ModelServing<br/>工作负载管理"]
    C --> G["AutoScaling<br/>弹性伸缩"]
    D --> H["Scheduler Pipeline<br/>智能调度"]
    D --> I["Load Balancer<br/>负载均衡"]
2 Kthena 的两层架构(Control Plane + Data Plane)如何分工?

答案:

Kthena 采用经典的两层架构:Control Plane 负责 CRD 生命周期管理与工作负载编排,Data Plane 负责推理请求的智能路由与负载均衡。两层通过 Kubernetes API 解耦,可独立演进。

[两层架构职责]

graph LR
    A["用户提交 CRD"] --> B["Control Plane"]
    B --> C["ModelBooster Controller"]
    B --> D["ModelServing Controller"]
    B --> E["ModelRoute Controller"]
    B --> F["AutoScaling Controller"]
    C --> G["创建 Pod/Service/ConfigMap"]
    D --> G
    G --> H["Data Plane"]
    H --> I["Kthena Router"]
    I --> J["Auth → Rate Limiting<br/>→ Fairness → Scheduling<br/>→ Load Balancing → Proxy"]
    J --> K["推理 Pod<br/>vLLM/SGLang/Triton"]
层级组件职责
Control PlaneCRD Controllers声明式管理推理工作负载、路由规则、伸缩策略
Control PlaneCRDs6 个核心 CRD 定义推理拓扑
Data PlaneKthena Router推理请求的认证、限流、调度、转发
Data PlaneScheduler Plugins基于负载/延迟/缓存评分的智能调度
3 Kthena 的 6 个核心 CRD 分别是什么?各自职责是什么?

答案:

Kthena 定义了 6 个核心 CRD,覆盖从模型部署到流量管理的完整推理生命周期。

CRD职责核心功能
ModelBooster一站式模型部署自动创建 ModelServing + ModelServer + ModelRoute,开箱即用
ModelServing推理工作负载管理管理 ServingGroup → Role → Pod 的层级工作负载
ModelServer服务暴露创建 Service/Ingress,将推理工作负载暴露为可访问端点
ModelRoute流量路由规则定义加权路由、Canary 发布、故障转移策略
AutoScalingPolicy伸缩策略定义定义同构/异构伸缩的指标、阈值、行为
AutoScalingPolicyBinding伸缩策略绑定将伸缩策略绑定到具体的 ModelServing

[CRD 依赖关系]

graph LR
    A["ModelBooster"] --> B["ModelServing"]
    A --> C["ModelServer"]
    A --> D["ModelRoute"]
    E["AutoScalingPolicy"] -.-> F["AutoScalingPolicyBinding"]
    F --> B
    B --> G["ServingGroup"]
    G --> H["Role<br/>Prefill/Decode/Aggregated"]
    H --> I["Entry Pod + Worker Pod"]
4 ModelBooster 如何实现一键模型部署?它的生命周期有哪些阶段?

答案:

ModelBooster 是 Kthena 的顶层 CRD,用户只需定义模型名称、推理引擎、资源配置等核心参数,Controller 自动创建下游的 ModelServing、ModelServer、ModelRoute 资源,完成完整的部署编排。

[ModelBooster 生命周期]

graph LR
    A["用户创建 ModelBooster CRD"] --> B["Initialized<br/>控制器初始化子资源"]
    B --> C["Active<br/>所有子资源就绪"]
    B --> D["Failed<br/>创建失败"]
    D -.->|修复后重试| B
阶段Condition说明
InitializedInitialized=TrueController 完成子资源创建,Pod 开始拉取模型
ActiveActive=True所有 Pod Ready,Service 可接收流量
FailedFailed=True子资源创建失败或 Pod 异常

[核心特性]

  • 通过 OwnerReference 实现级联删除,删除 ModelBooster 自动清理所有子资源
  • 默认启用 Volcano Gang Scheduling,确保 Prefill/Decode 角色同时调度
  • 支持 NPU(华为 Ascend)与 GPU 混合部署
5 Kthena 的 Pod 架构包含哪些组件?Entry Pod 和 Worker Pod 的区别是什么?

答案:

Kthena 推理 Pod 由 Entry Pod 和 Worker Pod 两类组成,形成主从协作模式。Entry Pod 负责请求接收与调度,Worker Pod 负责实际的模型推理计算。

[Pod 组件架构]

graph LR
    A["Entry Pod"] --> B["Runtime Agent<br/>Sidecar"]
    A --> C["LLM Engine<br/>vLLM/SGLang"]
    A --> D["Downloader<br/>Init Container"]
    D --> E["HuggingFace / S3<br/>/ OBS / PVC"]
    B --> F["指标采集<br/>LoRA 生命周期<br/>模型下载管理"]
    G["Worker Pod"] --> H["Runtime Agent<br/>Sidecar"]
    G --> I["LLM Engine<br/>推理引擎"]
    A -->|内部调度| G
组件类型职责
Entry Pod长驻接收 Router 转发的推理请求,调度至 Worker Pod
Worker Pod长驻执行实际推理计算(Token 生成)
Runtime AgentSidecar指标采集、LoRA 适配器生命周期管理、模型下载协调
DownloaderInit Container从 HuggingFace/S3/OBS/PVC 下载模型权重

[Worker Pod 伸缩]

  • Worker Pod 数量可独立于 Entry Pod 横向扩展
  • 结合 AutoScalingPolicy 实现基于负载的自动伸缩
  • Aggregated 角色下 Entry Pod 兼任 Worker,无需额外 Worker Pod
6 Kthena Router 的架构与调度流水线如何工作?

答案:

Kthena Router 是独立部署的推理网关,采用可插拔的调度流水线(Scheduler Pipeline)处理每个推理请求。流水线按固定顺序依次执行认证、限流、公平调度、请求调度、负载均衡和代理转发。

[Router 调度流水线]

graph LR
    A["推理请求"] --> B["Auth<br/>认证插件"]
    B --> C["Rate Limiting<br/>令牌桶限流"]
    C --> D["Fairness<br/>公平调度"]
    D --> E["Scheduling<br/>请求调度"]
    E --> F["Load Balancing<br/>负载均衡"]
    F --> G["Proxy<br/>转发至目标 Pod"]
    G --> H["推理引擎<br/>返回结果"]
阶段功能说明
Auth身份认证API Key / Token 校验
Rate Limiting速率控制基于 Token 数的令牌桶限流
Fairness公平调度多租户场景下的请求公平分配
Scheduling请求调度Filter + Score 两阶段选择最优 Pod
Load Balancing负载均衡加权轮询 / 最少连接策略
Proxy请求转发将请求代理至目标推理 Pod
7 Kthena Router 的调度插件有哪些?Filter 和 Score 插件如何协作?

答案:

Kthena Router 的 Scheduling 阶段采用 Filter + Score 两阶段机制,与 Kubernetes 调度器设计理念一致。Filter 插件过滤不可用 Pod,Score 插件对剩余 Pod 打分排序,选择最优目标。

[两阶段调度]

graph LR
    A["候选 Pod 列表"] --> B["Filter 阶段"]
    B --> C["Least Requests<br/>过滤过载 Pod"]
    B --> D["LoRA Affinity<br/>过滤无适配器 Pod"]
    C --> E["Score 阶段"]
    D --> E
    E --> F["KV Cache Aware<br/>KV 缓存感知评分"]
    E --> G["Least Latency<br/>最低延迟评分"]
    E --> H["Prefix Cache<br/>前缀缓存评分"]
    E --> I["GPU Cache<br/>GPU 缓存评分"]
    F --> J["加权合并得分<br/>选择最优 Pod"]
    G --> J
    H --> J
    I --> J
插件类型插件名功能
FilterLeast Requests过滤请求量超过阈值的 Pod
FilterLoRA Affinity将请求路由至已加载对应 LoRA 适配器的 Pod
ScoreKV Cache Aware优先选择 KV Cache 命中率高的 Pod
ScoreLeast Latency优先选择历史延迟最低的 Pod
ScorePrefix Cache优先选择已有相同前缀缓存的 Pod
ScoreGPU Cache优先选择 GPU 缓存利用率最优的 Pod
8 什么是 Prefill-Decode(PD)分离架构?Kthena 如何实现?

答案:

PD 分离是 LLM 推理领域的架构优化,将 Prefill(预填充,计算密集)和 Decode(解码,显存密集)两个阶段分配到不同角色的 Pod 执行,实现独立扩缩容和资源利用率最大化。

[PD 分离流程]

graph LR
    A["用户请求<br/>Prompt + max_tokens"] --> B["Prefill Role<br/>计算密集"]
    B --> C["处理 Prompt tokens<br/>生成初始 KV Cache"]
    C --> D["KV Cache 传输<br/>LMCache/MoonCake/NIXL"]
    D --> E["Decode Role<br/>显存密集"]
    E --> F["逐 Token 解码<br/>返回最终响应"]
维度PrefillDecode
计算特征计算密集(矩阵运算)显存密集(KV Cache 存储)
资源需求高算力 GPU(H100)大显存 GPU(A100 80G)
扩缩容策略按 Prompt 吞吐量按 Token 生成速率
瓶颈GPU 计算能力显存带宽

[Kthena PD 分离实现]

  • 通过 ModelServing 的 Role 定义,分别为 Prefill 和 Decode 角色配置独立副本数与资源
  • KV Cache 跨角色传输支持 LMCache、MoonCake、NIXL 三种连接器
  • Prefill 和 Decode 角色通过 Volcano Gang Scheduling 保证同时调度
9 ModelServing 的层级工作负载模型(ServingGroup → Role → Pod)如何组织?

答案:

ModelServing 采用三级层次结构管理推理工作负载:ServingGroup(服务组)→ Role(角色)→ Pod(实例)。每级可独立配置资源、副本数和调度策略。

[层级模型]

graph LR
    A["ModelServing"] --> B["ServingGroup"]
    B --> C["Role: Prefill<br/>副本数: 2"]
    B --> D["Role: Decode<br/>副本数: 4"]
    B --> E["Role: Aggregated<br/>副本数: 3"]
    C --> F["Entry Pod + Worker Pod"]
    D --> G["Entry Pod + Worker Pod × N"]
    E --> H["Entry Pod(兼任 Worker)"]
层级说明可配置项
ServingGroup逻辑服务单元模型名称、推理引擎、调度策略
Role角色定义Prefill / Decode / Aggregated,独立副本数、资源、GPU 类型
Pod实际运行实例Entry Pod + Worker Pod,Runtime Agent Sidecar

[Role 类型对比]

Role 类型适用场景Pod 结构
Aggregated中小规模、延迟不敏感Entry Pod 兼任 Worker,无需分离
Prefill大规模、计算密集型 Prompt独立 Entry + Worker
Decode大规模、高并发 Token 生成独立 Entry + 多 Worker
10 Kthena 如何实现 Gang Scheduling?与 Volcano PodGroup 的关系是什么?

答案:

Kthena 默认启用 Gang Scheduling,通过 Volcano 的 PodGroup 和 subGroupPolicy 机制确保同一推理服务的所有角色(Prefill/Decode)Pod 同时被调度,避免部分角色启动导致资源浪费。

[Gang Scheduling 流程]

graph LR
    A["ModelBooster 创建"] --> B["创建 Volcano PodGroup<br/>minMember = 总 Pod 数"]
    B --> C["创建 Prefill Role Pods<br/>subGroupPolicy"]
    B --> D["创建 Decode Role Pods<br/>subGroupPolicy"]
    C --> E{"Volcano 调度器<br/>检查资源是否满足全部 Pod"}
    D --> E
    E -->|资源充足| F["全部 Pod 同时启动<br/>PodGroup Running"]
    E -->|资源不足| G["全部 Pod 等待<br/>PodGroup Pending"]
概念说明
PodGroupVolcano CRD,将相关 Pod 打组,保证 Gang Scheduling 语义
minMemberPodGroup 最小成员数,低于此数不调度
subGroupPolicy按角色划分子组,每个角色可独立设置 minMember
Gang Scheduling要么全部调度,要么全部等待,避免部分启动

[配置示例]

apiVersion: serving.kthena.volcano.sh/v1alpha1
kind: ModelBooster
metadata:
  name: llama3-70b
spec:
  scheduling:
    gangScheduling:
      enabled: true
      minAvailable: 6
    subGroupPolicy:
      - role: prefill
        minAvailable: 2
      - role: decode
        minAvailable: 4
11 Kthena 的弹性伸缩(AutoScaling)机制有哪些模式?

答案:

Kthena 通过 AutoScalingPolicy 和 AutoScalingPolicyBinding 两个 CRD 实现推理工作负载的弹性伸缩,支持同构伸缩(Homogeneous)和异构伸缩(Heterogeneous)两种模式。

[伸缩模式对比]

graph LR
    A["AutoScalingPolicy"] --> B["Homogeneous<br/>同构伸缩"]
    A --> C["Heterogeneous<br/>异构伸缩"]
    B --> D["单一实例类型<br/>如全部 A100"]
    D --> E["Stable Mode<br/>平稳扩缩"]
    D --> F["Panic Mode<br/>突发扩容"]
    C --> G["多实例类型混合<br/>如 H100 + A100"]
    G --> H["optimizerConfiguration<br/>成本最优调度"]
维度HomogeneousHeterogeneous
实例类型单一类型多种类型混合
调度策略Stable/Panic 双模式成本驱动优化
适用场景负载稳定的推理服务多 GPU 型号集群、成本优化
扩缩指标请求速率、队列深度、GPU 利用率综合考虑成本、延迟、可用性

[Stable/Panic 双模式]

  • Stable Mode:基于时间窗口的平均指标值平稳调整副本数,避免抖动
  • Panic Mode:当指标突增超过 Panic 阈值时,快速扩容以应对突发流量,窗口期内自动回退至 Stable
12 Kthena 的异构伸缩(Heterogeneous Autoscaling)如何实现成本优化?

答案:

异构伸缩允许在同一个 ModelServing 中混合使用不同 GPU 型号(如 H100 + A100),通过 optimizerConfiguration 配置成本优化策略,根据实时负载动态选择最具性价比的实例类型。

[异构伸缩架构]

graph LR
    A["AutoScalingPolicyBinding"] --> B["optimizerConfiguration<br/>成本优化配置"]
    B --> C["实例类型优先级<br/>A100 > H100(成本维度)"]
    B --> D["伸缩策略<br/>先扩低成本实例"]
    C --> E["ModelServing<br/>创建混合副本"]
    D --> E
    E --> F["A100 Pod × N<br/>成本优先"]
    E --> G["H100 Pod × M<br/>性能优先"]

[配置示例]

apiVersion: autoscaling.kthena.volcano.sh/v1alpha1
kind: AutoScalingPolicyBinding
metadata:
  name: llama3-hetero
spec:
  modelServingRef:
    name: llama3-70b
  policyName: llama3-policy
  optimizerConfiguration:
    strategy: cost-driven
    instanceTypes:
      - type: nvidia-a100-80g
        priority: 1
        maxReplicas: 8
      - type: nvidia-h100
        priority: 2
        maxReplicas: 4

[成本优化策略]

  • cost-driven:优先扩容低优先级(低成本)实例,高负载时再启用高优先级实例
  • 基于实时 GPU 利用率与请求延迟动态调整各类型实例比例
  • 缩容时优先缩高优先级(高成本)实例,保留低成本实例
13 Kthena 如何实现流量路由与 Canary 发布?

答案:

Kthena 通过 ModelRoute CRD 定义流量路由规则,支持加权路由、Canary 发布和自动故障转移。Router 根据 ModelRoute 配置将推理请求按比例分发到不同版本的推理服务。

[Canary 发布流程]

graph LR
    A["推理请求"] --> B["Kthena Router"]
    B --> C["ModelRoute<br/>路由规则匹配"]
    C -->|"90% 流量"| D["ModelServing v1<br/>稳定版本"]
    C -->|"10% 流量"| E["ModelServing v2<br/>Canary 版本"]
    E --> F{"指标验证<br/>延迟/错误率"}
    F -->|通过| G["逐步提升 v2 流量比例"]
    F -->|不通过| H["回退至 v1"]
功能说明
加权路由按百分比分配流量至不同版本
Canary 发布新版本小流量灰度,逐步放量
故障转移主版本异常时自动切换至备用版本
基于模型路由根据 model name 字段路由至对应推理服务

[ModelRoute 配置示例]

apiVersion: serving.kthena.volcano.sh/v1alpha1
kind: ModelRoute
metadata:
  name: llama3-route
spec:
  routes:
    - modelServingRef: llama3-v1
      weight: 90
    - modelServingRef: llama3-v2-canary
      weight: 10
  failover:
    enabled: true
    targetRef: llama3-v1-fallback
14 Kthena 如何实现 Token 级别的速率限制?

答案:

Kthena Router 的 Rate Limiting 阶段支持基于 Token 数量的令牌桶限流,可按租户、模型、API Key 维度设置独立的 QPM(Queries Per Minute)和 TPM(Tokens Per Minute)配额。

[限流架构]

graph LR
    A["推理请求<br/>含 Prompt + max_tokens"] --> B["Rate Limiting 插件"]
    B --> C["令牌桶算法<br/>按 Tenant/Model/Key 匹配规则"]
    C -->|"配额充足"| D["放行请求"]
    C -->|"配额不足"| E["返回 429 Too Many Requests"]
    B --> F["Token 计量<br/>Prompt tokens + Completion tokens"]
    F --> G["实时扣减配额"]
限流维度说明
QPM每分钟查询数,按请求次数计数
TPM每分钟 Token 数,按 Prompt + Completion 总 Token 数计数
Tenant租户级配额,控制团队总用量
Model模型级配额,控制单模型并发
API Key密钥级配额,控制单用户用量
15 Kthena 如何实现 LoRA 适配器的热加载与管理?

答案:

Kthena 支持在推理 Pod 运行期间动态加载和卸载 LoRA 适配器,无需重启服务。Runtime Agent Sidecar 负责 LoRA 适配器的生命周期管理,Router 的 LoRA Affinity 插件将请求路由至已加载对应适配器的 Pod。

[LoRA 热加载流程]

graph LR
    A["用户创建/更新<br/>LoRA 适配器 CRD"] --> B["Runtime Agent<br/>检测到适配器变更"]
    B --> C["下载适配器权重<br/>从 Storage 加载"]
    C --> D["热加载至推理引擎<br/>vLLM/SGLang"]
    D --> E["上报适配器状态<br/>至 Router"]
    E --> F["LoRA Affinity 插件<br/>更新路由表"]
    F --> G["后续请求自动路由<br/>至已加载的 Pod"]
能力说明
热加载运行中动态加载新适配器,无需重启
热卸载运行中移除不再使用的适配器,释放显存
适配器路由LoRA Affinity 插件按 adapter_id 路由请求
多适配器共驻单 Pod 可同时加载多个 LoRA 适配器
16 Kthena 支持哪些推理引擎?如何选择?

答案:

Kthena 支持主流 LLM 推理引擎,通过统一的 CRD 接口屏蔽引擎差异,用户可按场景选择最适合的引擎。

推理引擎核心优势适用场景
vLLMPagedAttention、连续批处理、高吞吐通用 LLM 推理、高并发场景
SGLangRadixAttention、低延迟、结构化输出低延迟推理、函数调用
Triton多框架支持(TensorRT/PyTorch/ONNX)非 LLM 模型、多框架混合
TorchServePyTorch 原生、模型版本管理PyTorch 生态、传统推理

[引擎选择决策]

graph LR
    A["推理引擎选型"] --> B{"工作负载类型"}
    B -->|LLM 高并发| C["vLLM<br/>PagedAttention + Continuous Batching"]
    B -->|LLM 低延迟| D["SGLang<br/>RadixAttention + KV Cache 复用"]
    B -->|多框架混合| E["Triton<br/>TensorRT + PyTorch + ONNX"]
    B -->|PyTorch 生态| F["TorchServe<br/>原生 PyTorch 部署"]
17 Kthena 如何实现模型权重的下载与管理?

答案:

Kthena 通过 Downloader Init Container 在 Pod 启动前下载模型权重,支持多种存储源。Runtime Agent Sidecar 负责模型下载状态的上报和异常处理。

[模型下载架构]

graph LR
    A["Pod 启动"] --> B["Downloader<br/>Init Container"]
    B --> C{"模型来源"}
    C -->|"HuggingFace"| D["HF Hub API<br/>下载权重"]
    C -->|"S3"| E["S3 SDK<br/>下载权重"]
    C -->|"OBS"| F["华为 OBS SDK<br/>下载权重"]
    C -->|"PVC"| G["从 PVC 挂载<br/>直接读取"]
    D --> H["权重写入共享存储"]
    E --> H
    F --> H
    G --> H
    H --> I["Runtime Agent<br/>校验权重完整性"]
    I --> J["启动推理引擎"]
存储源说明适用场景
HuggingFace从 HF Hub 直接下载公开模型公开模型、快速验证
S3兼容 S3 协议的对象存储私有模型、大规模生产
OBS华为云对象存储华为云环境
PVCKubernetes PersistentVolumeClaim预加载模型、离线环境
18 Kthena 的网络拓扑感知调度(HyperNode)是什么?

答案:

Kthena 支持基于 HyperNode CRD 的网络拓扑感知调度,在 Prefill-Decode 分离架构中,确保 Prefill 和 Decode Pod 被调度到网络延迟最低的节点,优化 KV Cache 传输性能。

[拓扑感知调度]

graph LR
    A["HyperNode CRD<br/>定义网络拓扑"] --> B["节点分组<br/>Rack / AZ / Region"]
    B --> C["Volcano 调度器<br/>感知拓扑标签"]
    C --> D["Prefill Pod<br/>调度至 Node A"]
    C --> E["Decode Pod<br/>调度至同 Rack Node B"]
    D -->|"低延迟网络<br/>KV Cache 传输"| E
概念说明
HyperNode自定义 CRD,描述集群节点的网络拓扑关系
拓扑层级Rack → AZ → Region 三级拓扑
调度策略同一 ServingGroup 的 Pod 优先调度至低延迟拓扑域
性能收益KV Cache 跨节点传输延迟降低 30%-60%
19 Kthena 如何支持华为 NPU(Ascend)?与 GPU 混合部署如何实现?

答案:

Kthena 通过华为 HCCL(Huawei Collective Communication Library)支持 Ascend NPU 推理,可在同一集群中混合部署 GPU 和 NPU 推理 Pod,实现异构算力统一管理。

[异构算力架构]

graph LR
    A["ModelBooster CRD"] --> B["Controller"]
    B --> C["GPU Role<br/>nvidia.com/gpu"]
    B --> D["NPU Role<br/>huawei.com/ascend"]
    C --> E["vLLM + CUDA"]
    D --> F["MindSpore / PyTorch<br/>+ HCCL"]
    E --> G["推理服务<br/>统一暴露"]
    F --> G
维度GPUNPU
设备资源nvidia.com/gpuhuawei.com/ascend
通信库NCCLHCCL
推理引擎vLLM/SGLangMindSpore/PyTorch
驱动NVIDIA DriverAscend Driver + CANN

[混合部署配置]

spec:
  servingGroups:
    - roles:
        - name: gpu-prefill
          resource:
            nvidia.com/gpu: 4
          replicas: 2
        - name: npu-decode
          resource:
            huawei.com/ascend: 8
          replicas: 3
20 Kthena 的 KV Cache 协调机制支持哪些连接器?

答案:

在 PD 分离架构中,Prefill 和 Decode 角色之间需要传输 KV Cache。Kthena 支持三种 KV Cache 连接器,适配不同的缓存传输和共享场景。

连接器说明适用场景
LMCache本地 KV Cache 管理库,支持缓存持久化和跨请求复用单节点缓存优化、Prefix Caching
MoonCake分布式 KV Cache 传输协议,支持跨节点高效传输PD 分离场景、大规模部署
NIXLNVIDIA 高速 KV Cache 传输库,利用 GPU Direct RDMA低延迟跨节点传输、GPU 直通

[KV Cache 传输流程]

graph LR
    A["Prefill Role<br/>生成 KV Cache"] --> B["KV Cache 连接器<br/>LMCache/MoonCake/NIXL"]
    B --> C["传输至<br/>Decode Role"]
    C --> D["Decode Role<br/>加载 KV Cache<br/>继续解码"]
    A --> E["KV Cache 复用<br/>相同 Prefix 的请求<br/>可跳过 Prefill"]
21 Kthena 的 ModelServer CRD 如何暴露推理服务?

答案:

ModelServer 负责将 ModelServing 的推理工作负载暴露为可访问的网络端点,自动创建和管理 Kubernetes Service、Ingress 等网络资源。

[服务暴露架构]

graph LR
    A["ModelServer CRD"] --> B["Controller"]
    B --> C["Kubernetes Service<br/>ClusterIP / NodePort / LoadBalancer"]
    B --> D["Ingress<br/>域名路由 + TLS"]
    B --> E["ModelRoute<br/>流量路由规则"]
    C --> F["Kthena Router<br/>Service 后端"]
    F --> G["推理 Pod<br/>实际处理请求"]
暴露方式说明适用场景
ClusterIP集群内访问内部服务调用、Router 转发
NodePort节点端口暴露开发测试、无 LoadBalancer 环境
LoadBalancer云厂商负载均衡器生产环境、外部访问
IngressHTTP/HTTPS 域名路由需 TLS 终结、域名管理场景
22 Kthena 如何实现自动故障转移?

答案:

Kthena 通过 ModelRoute 的 failover 配置和 Router 的健康检查机制实现自动故障转移。当主服务实例异常时,Router 自动将流量切换至备用实例。

[故障转移流程]

graph LR
    A["Router 定期健康检查<br/>探测推理 Pod 状态"] --> B{"主实例健康"}
    B -->|"健康"| C["正常转发流量"]
    B -->|"异常"| D["标记主实例不可用"]
    D --> E["查询 failover 配置"]
    E --> F["切换至备用实例<br/>或同角色其他 Pod"]
    F --> G["持续探测主实例<br/>恢复后自动回切"]
机制说明
健康检查HTTP/HTTPS 探针定期检测推理引擎 /health 端点
Pod 级故障转移同 Role 内其他 Ready Pod 自动接管
Service 级故障转移ModelRoute failover 切换至备用 ModelServing
自动回切主实例恢复后,流量逐步回切
23 Kthena 的可观测性方案包含哪些指标?

答案:

Kthena 通过 Runtime Agent Sidecar 采集推理引擎指标,暴露为 Prometheus 格式的 metrics 端点,覆盖模型性能、资源利用、请求质量三个维度。

指标类别指标名说明
性能kthena_request_duration_seconds请求延迟分布(Prefill/Decode/End-to-End)
性能kthena_tokens_per_secondToken 生成速率
性能kthena_time_to_first_token_seconds首 Token 延迟(TTFT)
资源kthena_gpu_memory_utilizationGPU 显存利用率
资源kthena_kv_cache_utilizationKV Cache 使用率
资源kthena_active_requests当前并发请求数
质量kthena_request_success_total成功请求数
质量kthena_request_error_total失败请求数(按错误码分类)

[监控架构]

graph LR
    A["Runtime Agent<br/>Sidecar"] --> B["采集推理引擎指标"]
    B --> C["Prometheus<br/>metrics 端点"]
    C --> D["Grafana Dashboard<br/>推理监控面板"]
    C --> E["告警规则<br/>延迟/错误率/资源"]
24 如何配置 Kthena 的 ModelBooster 实现一键部署 LLM 模型?

答案:

ModelBooster 是 Kthena 的核心入口 CRD,通过一份 YAML 配置即可完成模型下载、Pod 创建、服务暴露、路由配置的全流程。

[完整部署示例]

apiVersion: serving.kthena.volcano.sh/v1alpha1
kind: ModelBooster
metadata:
  name: llama3-8b
spec:
  model:
    name: meta-llama/Meta-Llama-3-8B-Instruct
    source:
      type: huggingface
      repoID: meta-llama/Meta-Llama-3-8B-Instruct
  engine:
    type: vllm
    version: 0.6.0
    args:
      - --max-model-len=8192
      - --gpu-memory-utilization=0.9
  resources:
    nvidia.com/gpu: 1
    memory: 16Gi
  replicas: 2
  scheduling:
    gangScheduling:
      enabled: true
  service:
    type: ClusterIP
    port: 8000

[关键配置项]

字段说明
model.name模型标识符,用于路由匹配
model.source模型来源(huggingface/s3/obs/pvc)
engine.type推理引擎(vllm/sglang/triton/torchserve)
engine.args引擎启动参数
resourcesGPU、内存等资源请求
scheduling.gangScheduling是否启用 Gang Scheduling
25 Kthena 如何配置 Prefill-Decode 分离部署?

答案:

PD 分离部署通过 ModelServing 的多 Role 配置实现,分别为 Prefill 和 Decode 角色定义独立的副本数、资源、推理引擎参数。

[PD 分离配置示例]

apiVersion: serving.kthena.volcano.sh/v1alpha1
kind: ModelServing
metadata:
  name: llama3-70b-pd
spec:
  model:
    name: meta-llama/Meta-Llama-3-70B-Instruct
    source:
      type: s3
      endpoint: s3.amazonaws.com
      bucket: my-models
  servingGroups:
    - name: pd-group
      roles:
        - name: prefill
          engine:
            type: vllm
            args:
              - --role=prefill
              - --kv-connector=mooncake
          resources:
            nvidia.com/gpu: 4
          replicas: 2
        - name: decode
          engine:
            type: vllm
            args:
              - --role=decode
              - --kv-connector=mooncake
          resources:
            nvidia.com/gpu: 2
          replicas: 4
  scheduling:
    gangScheduling:
      enabled: true
    topologyAware:
      enabled: true
      topologyKey: topology.kubernetes.io/zone
配置项Prefill RoleDecode Role
GPU 数量4(高算力)2(大显存)
副本数24
引擎参数--role=prefill--role=decode
KV 连接器MoonCakeMoonCake
26 Kthena 的 Aggregated 角色与 PD 分离角色如何选择?

答案:

Kthena 提供三种 Role 类型:Aggregated(合并)、Prefill(预填充)和 Decode(解码)。选择取决于模型规模、延迟要求和集群资源。

[角色类型对比]

graph LR
    A{"选择 Role 类型"} -->|"模型 < 30B<br/>延迟要求一般"| B["Aggregated<br/>Prefill + Decode 合并"]
    A -->|"模型 ≥ 30B<br/>高并发场景"| C["PD 分离<br/>Prefill + Decode 独立"]
    B --> D["优点:简单<br/>缺点:资源利用率受限"]
    C --> E["优点:独立扩缩容<br/>缺点:架构复杂度高"]
维度AggregatedPD 分离
架构复杂度低(单角色)高(双角色 + KV 传输)
资源利用率Prefill 阶段 GPU 空闲等待各角色资源独立、利用率高
扩缩容整体扩缩Prefill/Decode 独立扩缩
适用模型规模< 30B 参数≥ 30B 参数
网络开销KV Cache 跨角色传输
部署成本高(需额外网络和存储)
27 Kthena 如何与 Volcano 的队列调度(Queue)集成?

答案:

Kthena 可与 Volcano 的队列调度(Queue)集成,实现多租户场景下的推理资源配额管理和公平调度。不同团队或项目的推理工作负载通过 Queue 分配资源配额,避免资源争抢。

[队列调度集成]

graph LR
    A["Team A<br/>ModelBooster"] --> B["Queue: team-a<br/>配额: 16 GPU"]
    C["Team B<br/>ModelBooster"] --> D["Queue: team-b<br/>配额: 8 GPU"]
    B --> E["Volcano 调度器<br/>按 Queue 配额分配"]
    D --> E
    E --> F["节点资源池<br/>公平分配"]
概念说明
QueueVolcano CRD,定义资源配额和优先级
配额管理每个 Queue 限制 CPU/GPU 等资源上限
公平调度多 Queue 间按权重或公平算法分配资源
优先级高优先级 Queue 可抢占低优先级 Queue 的资源

[配置示例]

apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
  name: inference-team-a
spec:
  weight: 2
  capability:
    nvidia.com/gpu: 16
    cpu: "64"
    memory: 256Gi
28 Kthena 的 Runtime Agent Sidecar 有哪些职责?

答案:

Runtime Agent 以 Sidecar 形式注入每个推理 Pod,负责模型下载协调、指标采集、LoRA 适配器生命周期管理和健康状态上报。

[Runtime Agent 架构]

graph LR
    A["Runtime Agent<br/>Sidecar"] --> B["模型下载协调<br/>管理 Downloader 状态"]
    A --> C["指标采集<br/>Prometheus metrics"]
    A --> D["LoRA 生命周期<br/>加载/卸载适配器"]
    A --> E["健康上报<br/>就绪探针"]
    A --> F["引擎适配<br/>vLLM/SGLang 统一接口"]
    C --> G["Prometheus<br/>Server"]
    E --> H["Kthena Controller<br/>状态同步"]
    D --> I["Router<br/>适配器路由表"]
职责说明
模型下载协调监控 Downloader Init Container 状态,处理下载失败重试
指标采集从推理引擎采集延迟、吞吐、资源利用率等指标
LoRA 管理监听 LoRA CRD 变更,动态加载/卸载适配器
健康上报通过 /healthz 端点报告推理引擎状态
引擎适配为 vLLM/SGLang/Triton 提供统一的指标和生命周期接口
29 如何排查 Kthena 推理 Pod 启动失败问题?

答案:

Kthena 推理 Pod 启动失败涉及多个环节:模型下载、资源调度、引擎启动。按层级排查可快速定位根因。

[排查流程]

graph LR
    A["Pod 启动失败"] --> B{"Pod 状态"}
    B -->|"Pending"| C["检查资源<br/>GPU/Memory 是否充足"]
    B -->|"Pending"| D["检查 Gang Scheduling<br/>PodGroup 是否 Running"]
    B -->|"ImagePullBackOff"| E["检查推理引擎镜像<br/>是否可拉取"]
    B -->|"Init:Error"| F["检查 Downloader<br/>模型下载日志"]
    B -->|"CrashLoopBackOff"| G["检查推理引擎<br/>启动日志"]
    C --> H["kubectl describe pod<br/>查看事件"]
    D --> I["kubectl get podgroup<br/>查看调度状态"]
    F --> J["kubectl logs pod<br/>-c downloader"]
    G --> K["kubectl logs pod<br/>-c engine"]

[常见故障与解决方案]

故障现象可能原因排查命令
Pod 长期 PendingGPU 资源不足或 Gang Scheduling 等待kubectl get podgroup -o wide
Init Container 失败HuggingFace 网络不通、S3 凭证错误kubectl logs <pod> -c downloader
引擎 CrashLoop模型权重损坏、显存不足、参数错误kubectl logs <pod> -c vllm
Runtime Agent 异常Sidecar 镜像版本不匹配kubectl logs <pod> -c runtime-agent
Gang Scheduling 超时minMember 设置过大、集群资源不足kubectl describe podgroup <name>
30 Kthena 在生产环境中的最佳实践有哪些?

答案:

基于 Kthena 的架构特性,生产环境部署应从资源规划、高可用、监控告警、安全四个维度构建完整的运维体系。

[高可用架构]

graph LR
    A["客户端请求"] --> B["Load Balancer<br/>多 Router 实例"]
    B --> C["Kthena Router 1"]
    B --> D["Kthena Router 2"]
    C --> E["ModelServing<br/>多副本部署"]
    D --> E
    E --> F["Prefill Role × N"]
    E --> G["Decode Role × M"]
    F --> H["跨 AZ 部署<br/>拓扑感知调度"]
    G --> H

[最佳实践清单]

维度实践
资源规划Prefill 角色选用高算力 GPU(H100),Decode 角色选用大显存 GPU(A100 80G)
高可用Router 至少 2 副本 + LoadBalancer;推理 Pod 跨 AZ 分布
Gang Scheduling生产环境保持启用,minMember 设为实际副本数
PD 分离模型 ≥ 30B 时启用,配合拓扑感知调度降低 KV 传输延迟
弹性伸缩配置 Stable + Panic 双模式,Panic 阈值设为 Stable 的 2 倍
监控告警TTFT > 2s、TTFT P99 > 5s、GPU 利用率 < 30% 告警
流量管理Canary 发布比例从 5% 起步,观察 10 分钟无异常后逐步放量
安全启用 Token 级限流,按租户隔离配额,API Key 轮换周期 ≤ 90 天
模型存储生产环境使用 S3/OBS + PVC 预加载,避免运行时从 HF 下载
故障恢复配置 failover 目标,主实例异常时 5s 内自动切换