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

随着大语言模型LLM成为现代 AI 应用的核心引擎支撑其运行的基础设施范式也随之进化。在解决了“智能路由”与“模型编排”等空间维度的请求分发问题后运维的核心焦点转向了时间维度的资源博弈如何实时、动态地确定最佳推理实例规模Kthena Autoscaler便是针对这一命题的标准答案。作为内置于kthena-controller-manager的核心控制器它深度集成于 Kubernetes 生态能够基于实时负载特征自动平滑地调整推理服务实例数。其核心价值在于在严守业务 SLO服务等级目标红线的同时最大化榨取计算资源的利用效率。本文将深入剖析 Kthena Autoscaler 的架构拓扑、通用策略逻辑以及多样化的绑定形态。▍1. 为什么 LLM 推理需要专用弹性伸缩LLM 推理工作负载具有独特的特征对传统弹性伸缩方案提出挑战特征对伸缩的影响业务指标驱动相比于 CPU/内存利用率推理引擎如 vLLM暴露的队列长度、KV Cache 利用率等业务指标更能直接反映服务饱和度。突发流量模式用户请求突然激增时需要快速扩容以维持延迟 SLOPrefill/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_percKV 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: 1m3.3 成本感知优化算法当伸缩涉及多个实例类型或硬件时Policy 底层的算法引擎会执行带倍增策略的贪心算法。该算法根据每种实例类型的单位成本 (Cost)将容量划分为指数级批次基于costExpansionRate并按成本升序排序生成伸缩序列。这确保了成本效率优先选择低成本实例。减少冷启动序列在周期内保持稳定优先复用已运行的实例。▍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: 104.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. 最佳实践与故障排查配置建议保守起步初始配置使用较宽容差带 (15-20%) 和较长稳定窗口。角色差异化目标在 PD 异构场景下为 decode 角色设置比 prefill 更敏感的阈值。成本校准异构伸缩时根据实际云定价或 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推理