三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

告别低效 HPA：深度解析 Kthena Autoscaler 如何重塑大模型服务弹性

发布时间：2026/10/8 1:07:16 三亩地 编程学习日记
告别低效 HPA：深度解析 Kthena Autoscaler 如何重塑大模型服务弹性

随着大语言模型（LLM）成为现代 AI 应用的核心引擎，支撑其运行的基础设施范式也随之进化。在解决了“智能路由”与“模型编排”等空间维度的请求分发问题后，运维的核心焦点转向了时间维度的资源博弈：如何实时、动态地确定最佳推理实例规模？

Kthena Autoscaler便是针对这一命题的标准答案。作为内置于kthena-controller-manager的核心控制器，它深度集成于 Kubernetes 生态，能够基于实时负载特征自动平滑地调整推理服务实例数。其核心价值在于：在严守业务 SLO（服务等级目标）红线的同时，最大化榨取计算资源的利用效率。

本文将深入剖析 Kthena Autoscaler 的架构拓扑、通用策略逻辑以及多样化的绑定形态。

▍1. 为什么 LLM 推理需要专用弹性伸缩？

LLM 推理工作负载具有独特的特征，对传统弹性伸缩方案提出挑战：

特征

对伸缩的影响

业务指标驱动

相比于 CPU/内存利用率，推理引擎（如 vLLM）暴露的队列长度、KV Cache 利用率等业务指标更能直接反映服务饱和度。

突发流量模式

用户请求突然激增时需要快速扩容以维持延迟 SLO

Prefill/Decode 不对称

PD 解耦部署需要对预填和解码角色进行独立且灵活的伸缩。

异构硬件与成本

不同实例类型（GPU/NPU）提供不同的性能/成本权衡，需要精细化调度。

传统的 Kubernetes HPA 或 KEDA 缺乏针对 LLM 工作负载的模型感知能力。Kthena Autoscaler 通过直连 Pod 采集业务指标、角色级伸缩支持以及成本感知优化算法弥合了这一差距。

▍2. 架构概览

Kthena Autoscaler 遵循控制器模式，作为kthena-controller-manager的子控制器运行。它通过直接采集 Pod 业务指标，结合用户定义的策略进行闭环控制。

▍3. 通用策略 (AutoscalingPolicy)：定义“如何缩容”

AutoscalingPolicy是一个通用的逻辑模板，定义了计算副本需求的核心大脑。

3.1 核心指标与容差

Autoscaler 允许直接从 Pod 的/metrics端点抓取推理专属指标。这意味着它能感知到 vLLM 内部的请求队列状态。常见指标包括：

  • vllm:num_requests_waiting：等待队列长度（最核心指标）。

  • vllm:kv_cache_usage_perc：KV Cache 利用率。

通过targetValue设置目标值，并利用tolerancePercent（容差带）防止在目标值附近的微小抖动触发频繁伸缩。

3.2 伸缩行为：稳定模式与紧急模式

为了应对推理场景的流量特性，Policy 支持双模式策略：

  • 稳定模式 (Stable Mode)：使用较长的稳定窗口（如 1 分钟）观察持续趋势，避免对瞬时波动过度反应。

  • 紧急模式 (Panic Mode)：当指标严重偏离目标（如超过 150%）时触发，绕过稳定窗口实现秒级快速扩容。

apiVersion: workload.serving.volcano.sh/v1alpha1 kind:AutoscalingPolicy metadata: name:vllm-queue-policy spec: metrics: - metricName:vllm:num_requests_waiting targetValue:100 tolerancePercent:50 behavior: scaleUp: stablePolicy: stabilizationWindow:1m period:30s scaleDown: stabilizationWindow:5m period: 1m

3.3 成本感知优化算法

当伸缩涉及多个实例类型或硬件时，Policy 底层的算法引擎会执行带倍增策略的贪心算法。

该算法根据每种实例类型的单位成本 (Cost)将容量划分为指数级批次（基于costExpansionRate），并按成本升序排序生成伸缩序列。这确保了：

  1. 成本效率：优先选择低成本实例。

  2. 减少冷启动：序列在周期内保持稳定，优先复用已运行的实例。

▍4. 伸缩绑定 (AutoscalingPolicyBinding)：定义“缩容什么”

AutoscalingPolicyBinding是连接通用策略与具体目标的“粘合剂”。通过不同的绑定目标，可以实现完全不同的伸缩形态。

4.1 作用于 ServingGroup：实现固定 PD 比例伸缩

这是最常见的形态。通过target将 Policy 绑定到ModelServing或其中的ServingGroup。

  • 逻辑：Autoscaler 将整组作为一个整体进行扩缩。

  • 效果：系统会严格保持定义的 Role 比例（如 prefill:decode = 1:2）同步增减。这适用于 PD 拓扑固定的标准部署场景。

# 绑定到 ModelServing (整组同步伸缩) apiVersion:workload.serving.volcano.sh/v1alpha1 kind:AutoscalingPolicyBinding metadata: name:vllm-group-binding spec: policyRef: name:vllm-queue-policy homogeneousTarget: target: targetRef: kind:ModelServing name:vllm-llama3 minReplicas:1 maxReplicas: 10

4.2 作用于 Role：实现独立 PD 异构伸缩

AutoScaler通过subTargets，能够将 Policy 绑定到ModelServing内特定的Role（如仅绑定decode角色）。

  • 逻辑：Autoscaler 仅针对该特定角色计算并修改副本数。

  • 效果：可以实现 prefill 副本保持稳定，而 decode 副本根据长输出负载独立增加。反过来说，也可以实现decode副本保持稳定，扩缩prefill副本数。这种PD 异构伸缩能极大提高资源利用率。

# 包含 Role 定义的 ModelServing 示例 apiVersion:workload.serving.volcano.sh/v1alpha1 kind:ModelServing metadata: name:deepseek-serving spec: template: roles: - name:prefill replicas:1 # ... 容器配置 ... - name:decode replicas:2 # ... 容器配置 ... --- # 独立绑定到 Role 的示例 apiVersion:workload.serving.volcano.sh/v1alpha1 kind:AutoscalingPolicyBinding metadata: name:decode-independent-binding spec: policyRef: name:llm-scaling-policy homogeneousTarget: target: targetRef: kind:ModelServing name:deepseek-serving subTargets: kind:Role name:decode# 仅针对 decode 角色独立伸缩 minReplicas:2 maxReplicas: 8

▍5. 最佳实践与故障排查

配置建议

  1. 保守起步：初始配置使用较宽容差带 (15-20%) 和较长稳定窗口。

  2. 角色差异化目标：在 PD 异构场景下，为 decode 角色设置比 prefill 更敏感的阈值。

  3. 成本校准：异构伸缩时，根据实际云定价或 TCO 调整cost值。

可观测性

Kthena Autoscaler 在/metrics暴露以下指标：

  • kthena_autoscaler_desired_replicas：决策后的目标副本数。

  • kthena_autoscaler_current_replicas：实际观测到的副本数。

  • kthena_autoscaler_scaling_events_total：伸缩动作计数器。

▍6. 进阶：成本感知优化与异构伸缩示例

在实际生产中，我们往往拥有不同规格的 GPU 资源。Kthena Autoscaler 的heterogeneousTarget允许在多个目标之间进行成本优先的伸缩分配。

# 跨硬件成本优化绑定示例 apiVersion:workload.serving.volcano.sh/v1alpha1 kind:AutoscalingPolicyBinding metadata: name:heterogeneous-cost-binding spec: policyRef: name:vllm-queue-policy heterogeneousTarget: params: - target: targetRef: kind:ModelServing name:deepseek-h100# 性能高，成本高 cost:100 minReplicas:1 maxReplicas:10 - target: targetRef: kind:ModelServing name:deepseek-a100# 成本低，优先扩容 cost:50 minReplicas:1 maxReplicas:20 # 定义成本扩张率，影响算法对成本与容量的权衡 costExpansionRatePercent: 200

通过配置不同的cost值，Autoscaler 的算法引擎会优先尝试在低成本资源上扩容，而在缩容时则优先保留高效率或特定成本的实例，从而在满足性能需求的同时实现最优 TCO。

▍总结

Kthena Autoscaler 通过将“伸缩逻辑 (Policy)”与“伸缩目标 (Binding)”解耦，提供了极大的灵活性。通过 ServingGroup 绑定可以实现稳定的固定比例扩缩，而通过 Role 绑定则能实现精细的异构扩缩。结合内置控制器的架构和成本感知算法，它为构建高效、低成本的 LLM 推理平台提供了坚实基础。

相关链接

[1] Kthena 官方文档:https://kthena.volcano.sh
[2] GitHub 仓库: https://github.com/volcano-sh/kthena

欢迎Star★，Fork，来 Kthena 社区一起玩转LLM推理！

编程学习 学习日记 实战经验
← 返回列表