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

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

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

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

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

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

▍2. 架构概览

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

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推理！