Kthena AI 推理平台面试题库
30 道题- 分类
- Kubernetes
- 子分类
- llm
- 题目数
- 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 Plane | CRD Controllers | 声明式管理推理工作负载、路由规则、伸缩策略 |
| Control Plane | CRDs | 6 个核心 CRD 定义推理拓扑 |
| Data Plane | Kthena Router | 推理请求的认证、限流、调度、转发 |
| Data Plane | Scheduler 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 | 说明 |
|---|---|---|
| Initialized | Initialized=True | Controller 完成子资源创建,Pod 开始拉取模型 |
| Active | Active=True | 所有 Pod Ready,Service 可接收流量 |
| Failed | Failed=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 Agent | Sidecar | 指标采集、LoRA 适配器生命周期管理、模型下载协调 |
| Downloader | Init 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
| 插件类型 | 插件名 | 功能 |
|---|---|---|
| Filter | Least Requests | 过滤请求量超过阈值的 Pod |
| Filter | LoRA Affinity | 将请求路由至已加载对应 LoRA 适配器的 Pod |
| Score | KV Cache Aware | 优先选择 KV Cache 命中率高的 Pod |
| Score | Least Latency | 优先选择历史延迟最低的 Pod |
| Score | Prefix Cache | 优先选择已有相同前缀缓存的 Pod |
| Score | GPU 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/>返回最终响应"]
| 维度 | Prefill | Decode |
|---|---|---|
| 计算特征 | 计算密集(矩阵运算) | 显存密集(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"]
| 概念 | 说明 |
|---|---|
| PodGroup | Volcano CRD,将相关 Pod 打组,保证 Gang Scheduling 语义 |
| minMember | PodGroup 最小成员数,低于此数不调度 |
| 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/>成本最优调度"]
| 维度 | Homogeneous | Heterogeneous |
|---|---|---|
| 实例类型 | 单一类型 | 多种类型混合 |
| 调度策略 | 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 接口屏蔽引擎差异,用户可按场景选择最适合的引擎。
| 推理引擎 | 核心优势 | 适用场景 |
|---|---|---|
| vLLM | PagedAttention、连续批处理、高吞吐 | 通用 LLM 推理、高并发场景 |
| SGLang | RadixAttention、低延迟、结构化输出 | 低延迟推理、函数调用 |
| Triton | 多框架支持(TensorRT/PyTorch/ONNX) | 非 LLM 模型、多框架混合 |
| TorchServe | PyTorch 原生、模型版本管理 | 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 | 华为云对象存储 | 华为云环境 |
| PVC | Kubernetes 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
| 维度 | GPU | NPU |
|---|---|---|
| 设备资源 | nvidia.com/gpu | huawei.com/ascend |
| 通信库 | NCCL | HCCL |
| 推理引擎 | vLLM/SGLang | MindSpore/PyTorch |
| 驱动 | NVIDIA Driver | Ascend 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 分离场景、大规模部署 |
| NIXL | NVIDIA 高速 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 | 云厂商负载均衡器 | 生产环境、外部访问 |
| Ingress | HTTP/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_second | Token 生成速率 |
| 性能 | kthena_time_to_first_token_seconds | 首 Token 延迟(TTFT) |
| 资源 | kthena_gpu_memory_utilization | GPU 显存利用率 |
| 资源 | kthena_kv_cache_utilization | KV 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 | 引擎启动参数 |
resources | GPU、内存等资源请求 |
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 Role | Decode Role |
|---|---|---|
| GPU 数量 | 4(高算力) | 2(大显存) |
| 副本数 | 2 | 4 |
| 引擎参数 | --role=prefill | --role=decode |
| KV 连接器 | MoonCake | MoonCake |
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/>缺点:架构复杂度高"]
| 维度 | Aggregated | PD 分离 |
|---|---|---|
| 架构复杂度 | 低(单角色) | 高(双角色 + 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/>公平分配"]
| 概念 | 说明 |
|---|---|
| Queue | Volcano 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 长期 Pending | GPU 资源不足或 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 内自动切换 |