AIBrix 基于指标的自动扩缩容Metric-based Autoscaling实战指南HPA、KPA 与 APA 的配置与原理【免费下载链接】aibrixCost-efficient and pluggable Infrastructure components for GenAI inference项目地址: https://gitcode.com/GitHub_Trending/ai/aibrix导读本文围绕 AIBrix 的PodAutoscaler自定义资源系统讲解其内置的三种基于指标的自动扩缩容机制——Knative 风格的 KPA、Kubernetes 原生 HPA以及 AIBrix 专为 LLM 推理服务设计的 APAAdvanced Pod Autoscaler。你将学会如何通过一份 YAML 配置完成 autoscaler 的部署、如何调优 metric window、scheduled replica bounds、annotation 参数如何使用 Kubernetes external metrics API 进行跨组件扩缩容以及如何对 StormService 的 prefill/decode 角色做细粒度独立扩缩容。读完本文你可以直接在 AIBrix 集群中复制并运行所有示例并理解底层控制器controller的判定逻辑与日志排查方法。三种扩缩容机制概览AIBrix 的 autoscaler 组件隶属于 aibrix controller manager支持多种基于指标的扩缩容机制用户只需在PodAutoscaler的spec.scalingStrategy字段中选择即可切换策略来源特点HPAKubernetes 原生 Horizontal Pod Autoscaler与原生 HPA 行为一致基于 CPU 等指标缩放 Deployment 副本响应较慢但生态成熟KPA灵感来自 Knative维护stable window稳定窗口与panic window恐慌窗口两个时间窗口基于短窗口测量对流量突增快速扩容与依赖 Prometheus 拉取指标的方案不同AIBrix 内部自行拉取并维护指标响应更快APAAIBrix 自研专为 LLM 推理优化与 HPA 类似但引入 fluctuation波动容忍参数作为触发扩容/缩容前的最小缓冲防止震荡oscillation从源码类型定义看三种策略在 api/autoscaling/v1alpha1/podautoscaler_types.go 中被建模为ScalingStrategyType枚举const ( HPA ScalingStrategyType HPA // Kubernetes 原生 Horizontal Pod Autoscaler KPA ScalingStrategyType KPA // KNative Pod Autoscaling Algorithm APA ScalingStrategyType APA // AiBrix Pod Autoscaling Algorithm )HPA 与 KPA 虽被广泛使用但并非针对 LLM 推理服务的独特优化点而设计。AIBrix 的自研 APA 方案正在逐步引入以下能力部分仍在开发中基于 AI Runtime 指标标准化选择适合 LLM 服务的专用指标进行扩缩容前瞻式proactive扩缩容算法而非纯反应式reactiveWIPProfiling 与 SLO 驱动的扩缩容方案Testing Phase。支持的指标MetricsAIBrix 支持 vLLM 暴露的全部指标。这些指标通过 vLLM 的/metrics端点以 Prometheus 格式暴露例如本文示例中反复出现的gpu_cache_usage_percGPU KV cache 使用率、num_requests_waiting等待中的请求数等均属于 vLLM 运行时指标。配合 pkg/metrics 下的实现AIBrix 也可以消费网关侧指标如aibrix_running_requests和自定义指标用于更贴合 LLM 场景的扩缩容决策。如何部署扩缩容策略部署 autoscaler 非常简单直接应用一份PodAutoscalerYAML 即可。一个关键约束是scaleTargetRef中的 name 必须与目标 Deployment 的名称完全一致AIBrix 的 PodAutoscaler 正是通过这一名称找到正确的扩缩容对象。所有示例文件都位于仓库的 samples/autoscaling 目录下本文后续示例均可在该目录中找到对应文件。HPA 示例配置文件samples/autoscaling/hpa.yamlapiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: deepseek-r1-distill-llama-8b-hpa namespace: default labels: app.kubernetes.io/name: aibrix app.kubernetes.io/managed-by: kustomize spec: scalingStrategy: HPA minReplicas: 1 maxReplicas: 10 metricsSources: - metricSourceType: pod protocolType: http port: 8000 path: /metrics targetMetric: gpu_cache_usage_perc targetValue: 50 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: deepseek-r1-distill-llama-8bKPA 示例配置文件samples/autoscaling/kpa.yamlapiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: deepseek-r1-distill-llama-8b-kpa namespace: default labels: app.kubernetes.io/name: aibrix app.kubernetes.io/managed-by: kustomize annotations: autoscaling.aibrix.ai/scale-down-cooldown-window: 3m spec: scalingStrategy: KPA minReplicas: 1 maxReplicas: 8 metricsSources: - metricSourceType: pod protocolType: http port: 8000 path: metrics targetMetric: gpu_cache_usage_perc targetValue: 0.5 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: deepseek-r1-distill-llama-8bAPA 示例配置文件samples/autoscaling/apa.yamlapiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: deepseek-r1-distill-llama-8b-apa namespace: default labels: app.kubernetes.io/name: aibrix app.kubernetes.io/managed-by: kustomize annotations: autoscaling.aibrix.ai/up-fluctuation-tolerance: 0.1 autoscaling.aibrix.ai/down-fluctuation-tolerance: 0.2 apa.autoscaling.aibrix.ai/window: 30s spec: scalingStrategy: APA minReplicas: 1 maxReplicas: 8 metricsSources: - metricSourceType: pod protocolType: http port: 8000 path: metrics targetMetric: gpu_cache_usage_perc targetValue: 0.5 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: deepseek-r1-distill-llama-8b注意 APA 使用了三组特有的 annotationup-fluctuation-tolerance向上触发扩容前允许的波动比例、down-fluctuation-tolerance向下触发缩容前允许的波动比例以及apa.autoscaling.aibrix.ai/windowAPA 的观察窗口时长。被扩缩容的目标工作负载以上示例中的scaleTargetRef指向同名 Deployment。配套的工作负载示例见 samples/autoscaling/deploy.yaml它通过vllm serve启动 DeepSeek-R1-Distill-Llama-8B暴露 8000 端口的/metrics与/health探针并在 Pod 注解中声明prometheus.io/scrape: true、prometheus.io/port: 8000、prometheus.io/path: /metrics从而让指标可以被正常采集。Configurable metric windows可配置的指标窗口PodAutoscaler在spec下支持两个可选的指标窗口字段用于控制 autoscaler 在做扩缩容决策时保留多少最近的指标历史字段默认值合法范围说明observeWindowSeconds1801~3600稳定指标窗口用于常规扩缩容建议。增大可平滑噪声指标减小可让 autoscaler 对近期负载变化反应更快panicWindowSeconds601~3600KPA 恐慌模式使用的短指标窗口。必须小于等于observeWindowSeconds若任一字段省略AIBrix 使用上表默认值。校验规则会拒绝非正值、大于3600的值以及panicWindowSeconds大于observeWindowSeconds的配置。该校验在比较时会对省略的字段使用默认值因此如果你把observeWindowSeconds设到60以下也必须同时把panicWindowSeconds设为相同或更小的值。这些字段在 API 类型中的定义位于 api/autoscaling/v1alpha1/podautoscaler_types.go带有kubebuilder:validation:Minimum1与kubebuilder:validation:Maximum3600的 CRD 校验注解与文档描述的规则完全对应。下面是一个10 分钟稳定窗口 1 分钟恐慌窗口的 KPA 示例apiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: example-kpa-windows spec: scalingStrategy: KPA minReplicas: 1 maxReplicas: 8 observeWindowSeconds: 600 panicWindowSeconds: 60 metricsSources: - metricSourceType: pod protocolType: http port: 8000 path: metrics targetMetric: gpu_cache_usage_perc targetValue: 0.5 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: deepseek-r1-distill-llama-8bScheduled replica bounds按时间调度副本上下限PodAutoscaler还支持在spec.schedules下配置按时间调度的副本上下限。每条 schedule 定义一个循环的每日墙钟时间窗口包含startTime与endTime严格使用零填充的HH:MM格式start 时间含、end 时间不含。在窗口生效期间schedule 会覆盖基础的spec.minReplicas和/或spec.maxReplicas。行为约定如下省略timezone时按 UTC 评估设置时必须为合法的 IANA 时区如America/Los_Angeles省略daysOfWeek时每天生效设置时接受英文三字母星期名Mon到Sun每条 schedule 可只设置minReplicas、只设置maxReplicas或两者都设置部分覆盖时缺失的边界继承自基础 PodAutoscaler spec校验会拒绝以下配置未设置任一边界、有效最小值大于有效最大值、非法时区、非法时间格式、跨午夜span midnight、或与其他 schedule 窗口重叠。重叠窗口会被直接拒绝而不是依赖隐式优先级。在调度模型中PodAutoscalerSchedule结构体定义于 api/autoscaling/v1alpha1/podautoscaler_types.go其中startTime/endTime均带^([01][0-9]|2[0-3]):[0-5][0-9]$正则校验name遵循 Kubernetes DNS label 风格。HPA、KPA、APA 三种策略都会使用生效后的调度边界。对于 HPA 策略AIBrix 会把生效边界写入生成的 KubernetesHorizontalPodAutoscaler对象如果有效最小值是0生成的 HPA 会省略spec.minReplicas以保持与原生 Kubernetes HPA 兼容行为相关实现见 pkg/controller/podautoscaler/hpa_resources.go。下面是带工作日业务时段边界的 APA 示例文件samples/autoscaling/scheduled-bounds-apa.yamlapiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: deepseek-r1-distill-llama-8b-scheduled-apa namespace: default labels: app.kubernetes.io/name: aibrix app.kubernetes.io/managed-by: kustomize spec: scalingStrategy: APA minReplicas: 1 maxReplicas: 10 schedules: - name: weekday-business-hours timezone: America/Los_Angeles daysOfWeek: [Mon, Tue, Wed, Thu, Fri] startTime: 09:00 endTime: 18:00 minReplicas: 4 maxReplicas: 12 metricsSources: - metricSourceType: pod protocolType: http port: 8000 path: metrics targetMetric: gpu_cache_usage_perc targetValue: 0.5 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: deepseek-r1-distill-llama-8b使用 Kubernetes external metrics API除了直接抓取 metrics 端点PodAutoscaler还可以从 Kubernetes 的external.metrics.k8s.ioAPI 读取目标指标。这样你就能基于外部 metrics adapter例如 Prometheus Adapter 或自研 adapter发布的任意指标进行扩缩容AIBrix 无需自行访问工作负载的 metrics 端口。这在目标信号不在 Pod 上时非常有用例如Broker 中的队列深度或者已被现有监控栈聚合好的指标。如何选择 external metrics API当metricSourceType为external且不设置endpoint时该 metric source 就使用 Kubernetes external metrics API一旦设置了endpoint同一 source 类型会切回抓取该 HTTP 端点此时protocolType、endpoint、path均必填。因此使用 external metrics API 时只需要指定指标及其目标值metricsSources: - metricSourceType: external targetMetric: aibrix_running_requests targetValue: 100这里省略endpoint、path和protocolType是有意为之并非示例不完整。注意MetricSourceType中external与已废弃的domain的枚举定义见 api/autoscaling/v1alpha1/podautoscaler_types.go。使用前提集群中必须安装 external metrics adapter并对外提供external.metrics.k8s.ioAPI groupadapter 必须在目标工作负载所在的 namespace中暴露targetMetric指定的指标AIBrix controller 需要对external.metrics.k8s.io拥有get和list权限——仓库自带的 RBAC 已默认授予。排障提示如果 controller 启动时无法构造 external metrics clientcontroller 只会记录一条 warning 并继续运行此时 external metrics 不可用。因此如果一个使用该模式的PodAutoscaler始终不扩缩容请先检查 controller 的日志。external metrics KPA 示例文件samples/autoscaling/external-metrics-kpa.yamlapiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: deepseek-r1-distill-llama-8b-external-kpa namespace: default labels: app.kubernetes.io/name: aibrix app.kubernetes.io/managed-by: kustomize annotations: autoscaling.aibrix.ai/scale-down-cooldown-window: 3m spec: scalingStrategy: KPA minReplicas: 1 maxReplicas: 8 metricsSources: # Uses Kubernetes external.metrics.k8s.io. Do not set endpoint, path, or # protocolType for this mode. - metricSourceType: external targetMetric: aibrix_running_requests targetValue: 100 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: deepseek-r1-distill-llama-8bexternal metrics APA 示例文件samples/autoscaling/external-metrics-apa.yamlapiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: deepseek-r1-distill-llama-8b-external-metrics namespace: default labels: app.kubernetes.io/name: aibrix app.kubernetes.io/managed-by: kustomize annotations: autoscaling.aibrix.ai/up-fluctuation-tolerance: 0.1 autoscaling.aibrix.ai/down-fluctuation-tolerance: 0.2 apa.autoscaling.aibrix.ai/window: 30s spec: scalingStrategy: APA minReplicas: 1 maxReplicas: 8 metricsSources: # Uses Kubernetes external.metrics.k8s.io. An external metrics adapter must # expose this metric in the same namespace as the target workload. - metricSourceType: external targetMetric: aibrix_queue_depth targetValue: 40 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: deepseek-r1-distill-llama-8bPodAutoscaler 支持的注解annotations基于指标的 autoscaler 可以通过PodAutoscaler对象上的注解进行调优。controller 目前识别以下autoscaling.aibrix.ai/前缀的通用注解键。注解值是 Kubernetes metadata 中的字符串因此在 YAML 中需要对数值与时长加引号。时长使用 Go duration 语法解析如30s、5m浮点值按十进制数解析如0.1、2.0。这些注解键的源码常量定义在 pkg/controller/podautoscaler/types/annotations.go与下表一一对应注解值类型默认值适用策略说明autoscaling.aibrix.ai/max-scale-up-ratefloat2HPA, KPA, APA限制单次扩缩容决策中副本可以增加的速率。例如2.0表示建议副本数最多增长到当前副本数的 2 倍autoscaling.aibrix.ai/max-scale-down-ratefloat2HPA, KPA, APA限制单次决策中副本减少的速率。例如2.0防止单次决策缩到当前副本数的一半以下autoscaling.aibrix.ai/scale-up-tolerancefloat0.1KPA, APA避免对微小指标波动触发扩容。0.1表示指标须超过目标值 10% 以上才会扩容autoscaling.aibrix.ai/scale-down-tolerancefloat0.1KPA, APA避免对微小指标波动触发缩容。0.1表示指标须低于目标值 10% 以上才会缩容autoscaling.aibrix.ai/panic-thresholdfloat2.0KPA设置进入 KPA panic 模式的阈值当短窗口需求相对稳定窗口需求偏高时触发autoscaling.aibrix.ai/scale-up-cooldown-windowduration0sHPA, KPA, APA扩容建议的稳定窗口stabilization windowautoscaling.aibrix.ai/scale-down-cooldown-windowduration300sHPA, KPA, APA缩容建议的稳定窗口默认 5 分钟autoscaling.aibrix.ai/scale-to-zeroboolfalseKPA, APA开启 scaling context 的 scale-to-zero 标志最终副本数仍受spec.minReplicas约束注解示例apiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: example-kpa annotations: autoscaling.aibrix.ai/max-scale-up-rate: 3.0 autoscaling.aibrix.ai/max-scale-down-rate: 2.0 autoscaling.aibrix.ai/scale-up-tolerance: 0.2 autoscaling.aibrix.ai/scale-down-tolerance: 0.1 autoscaling.aibrix.ai/panic-threshold: 2.5 autoscaling.aibrix.ai/scale-up-cooldown-window: 30s autoscaling.aibrix.ai/scale-down-cooldown-window: 5m autoscaling.aibrix.ai/scale-to-zero: false spec: scalingStrategy: KPA从代码注释pkg/controller/podautoscaler/types/annotations.go可以进一步确认语义max-scale-up-rate的2.0表示单步可翻倍副本panic-threshold的2.0表示短期需求超过长期均值 2 倍时进入恐慌模式。这些注解最终会被 controller 读取并注入各策略的 scaling context 中参见 pkg/controller/podautoscaler/podautoscaler_controller.go。StormService 角色级Role-Level自动扩缩容对于 Pooled 模式的 StormServicespec.mode: Pooledprefill 与 decode 等不同角色role可以独立扩缩容每个角色基于自身指标做细粒度伸缩。关键用法使用subTargetSelector字段在 StormService 内选中特定角色在 StormService 上声明spec.modePooled表示扩缩容选中的角色Replica表示扩缩容spec.replicas。autoscaler 读取spec.mode来决定角色级扩缩容——仅靠replicas1无法区分两种模式PodAutoscaler注解autoscaling.aibrix.ai/storm-service-mode已废弃仅在目标 StormService 未声明spec.mode时作为兼容性回退被采纳。核心能力每个角色拥有独立的 PodAutoscaler、独立指标与独立扩缩容策略适用于 Pooled 模式replicas1的 StormService每个角色可选用不同策略HPA、KPA、APA每个角色可设置不同的 min/max 副本数与扩缩容行为。适用场景Pooled 模式replicas1的 StormService 需要各角色独立伸缩不同负载模式prefill 与 decode 的资源需求与流量特征不同独立指标每个角色有自己的指标如队列长度、batch 利用率。subTargetSelector在 API 类型中对应SubTargetSelector结构体api/autoscaling/v1alpha1/podautoscaler_types.go通过roleName选择 StormService/RoleSet 内的角色。完整示例见 samples/autoscaling/stormservice-pool.yaml其中 prefill 角色以prefill_queue_length为目标targetValue10decode 角色以decode_batch_utilization为目标targetValue70且 decode 额外设置了更保守的stabilizationWindowSeconds: 600缩容行为--- # PodAutoscaler for prefill role apiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: ss-pool-prefill namespace: default spec: scaleTargetRef: apiVersion: orchestration.aibrix.ai/v1alpha1 kind: StormService name: ss-pool subTargetSelector: roleName: prefill minReplicas: 2 maxReplicas: 20 scalingStrategy: APA metricsSources: - metricSourceType: pod protocolType: http port: 8000 path: /metrics targetMetric: prefill_queue_length targetValue: 10 --- # PodAutoscaler for decode role apiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: ss-pool-decode namespace: default spec: scaleTargetRef: apiVersion: orchestration.aibrix.ai/v1alpha1 kind: StormService name: ss-pool subTargetSelector: roleName: decode minReplicas: 3 maxReplicas: 30 scalingStrategy: APA metricsSources: - metricSourceType: pod protocolType: http port: 8000 path: /metrics targetMetric: decode_batch_utilization targetValue: 70 behavior: scaleDown: stabilizationWindowSeconds: 600 # More conservative scale-down多指标Multi-Metric自动扩缩容AIBrix 支持在单个PodAutoscaler中定义多个扩缩容指标。这对 LLM 推理服务尤其重要——单一指标如 GPU cache 使用率可能无法完整反映系统压力将其与队列类指标如等待请求数组合能做出更稳健、更灵敏的扩缩容决策。工作原理当spec.metricsSources下指定多个指标时autoscaler 会独立评估所有指标最终期望副本数由要求副本数最高的那个指标决定即max策略。配置示例APA 策略同时使用两个指标文件samples/autoscaling/multimetrics-apa.yamlapiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: deepseek-r1-mock-llama2-7b-multi-metrics namespace: default labels: app.kubernetes.io/name: aibrix app.kubernetes.io/managed-by: kustomize annotations: autoscaling.aibrix.ai/up-fluctuation-tolerance: 0.1 autoscaling.aibrix.ai/down-fluctuation-tolerance: 0.2 apa.autoscaling.aibrix.ai/window: 30s spec: scalingStrategy: APA minReplicas: 1 maxReplicas: 3 metricsSources: - metricSourceType: pod protocolType: http port: 8000 path: metrics targetMetric: gpu_cache_usage_perc targetValue: 0.5 - metricSourceType: pod protocolType: http port: 8000 path: metrics targetMetric: num_requests_waiting targetValue: 100 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: mock-llama2-7b补充说明从 api/autoscaling/v1alpha1/podautoscaler_types.go 看metricsSources带有MinItems1校验即至少需要一个指标源而辅助函数GetPaMetricSources仍保留了当前仅支持单个 MetricSource的旧有约束注释api/autoscaling/v1alpha1/podautoscaler_types.go多指标场景由 controller 主循环直接消费整个列表完成聚合评估。查看扩缩容日志与自定义资源状态PodAutoscaler 日志Pod autoscaler 是 aibrix controller manager 的一部分负责从每个 Pod 采集指标。查看日志kubectl logs aibrix-controller-manager-podname -n aibrix-system -f期望的日志输出会展示当前使用的指标例如gpu_cache_usage_perc并逐一显示每个 Pod 的当前指标值便于定位指标是否采到各 Pod 负载是否均衡等问题。controller manager 的部署与权限配置可在 config/manager/manager.yaml 与 config/rbac 中查看。查看自定义资源状态使用以下命令查看 PodAutoscaler 的详细状态kubectl describe podautoscaler podautoscaler-name如输出所示describe 结果会展示该 PodAutoscaler 的 Spec策略、min/max、指标源、目标引用与 Status 事件流如KPA algorithm run, currentReplicas: 1, desiredReplicas: 1, rescale: false以及指标抓取失败、扩缩容成功等 Normal/Warning 事件可据此判断算法是否运行、指标是否成功获取、副本是否按预期变化。此外PodAutoscalerStatus还包含desiredScale、actualScale、conditions、scalingHistory最近 N 次扩缩容决策与scheduledBounds当前生效的调度边界等字段定义见 api/autoscaling/v1alpha1/podautoscaler_types.go可通过kubectl get podautoscaler -o yaml进一步查看。不同 autoscaler 的初步对比实验AIBrix 提供了一套初步实验数据展示不同扩缩容机制与配置对**性能延迟与成本计算成本**的影响。在 AIBrix 中用户只需 apply K8s YAML 即可轻松切换不同 autoscaler。实验设置模型Deepseek 7B 聊天模型GPU 类型V100GPU 最大数量8目标指标与值指标gpu_kv_cache_utilization目标值50%工作负载整体 RPS 趋势从低 RPS 开始在 T500 前较快上升用于评估不同 autoscaler 对快速负载增长的响应随后快速回落到低 RPS 以评估缩容行为再缓慢回升。平均 RPS 趋势1 RPS → 4 RPS → 8 RPS → 10 RPS → 2 RPS → 6 RPS性能延迟HPA 因响应慢而延迟最高KPA 因 panic 模式响应最快APA 使用较小的延迟窗口以节省成本确实省了成本但从 T700 到 T1000 因缩容过于激进延迟高于 KPA。成本累积成本 时间 × 单位成本本例单位成本为 1实际计算成本可用实际每单位时间成本相乘得到。HPA 因更长的缩容延迟窗口而成本最高APA 响应最快、最节省成本可以看到其波动比其他两者更明显需要说明的是缩容窗口并不是各扩缩容机制的内在特性而是可配置变量本实验对 HPA 使用了默认值300s。结论没有一种 autoscaler 能在所有指标延迟、成本上全面胜出结果还取决于工作负载形态。基础设施应当提供简单的方式让用户按需选择扩缩容机制并保持高度可配置因为不同用户偏好不同——有人更看重成本有人更看重性能。上图为实验可视化结果包含延迟 CDF、负载RPS、运行中 Pod 数、累积成本的时间序列以及平均延迟、P99 延迟、总成本、失败请求数的汇总柱状图。实验原始脚本与配套场景可参考 benchmarks/scenarios/autoscaling 目录。小结AIBrix 的 metric-based autoscaling 通过一个统一的PodAutoscalerCRD 封装了 HPA、KPA、APA 三种机制并在此基础上叠加了 metric window、scheduled replica bounds、external metrics、多指标聚合、StormService 角色级扩缩容等面向 LLM 推理场景的增强能力。所有示例配置集中在 samples/autoscaling核心类型定义在 api/autoscaling/v1alpha1/podautoscaler_types.go注解常量在 pkg/controller/podautoscaler/types/annotations.go。你可以先从一个单指标 APA 配置起步再逐步引入多指标、调度边界与角色级扩缩容并通过kubectl describe podautoscaler和 controller 日志持续观察与调优。【免费下载链接】aibrixCost-efficient and pluggable Infrastructure components for GenAI inference项目地址: https://gitcode.com/GitHub_Trending/ai/aibrix创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 AIBrix 基于指标的自动扩缩容（Metric-based Autoscaling）实战指南：HPA、KPA 与 APA 的配置与原理
AIBrix 基于指标的自动扩缩容Metric-based Autoscaling实战指南HPA、KPA 与 APA 的配置与原理【免费下载链接】aibrixCost-efficient and pluggable Infrastructure components for GenAI inference项目地址: https://gitcode.com/GitHub_Trending/ai/aibrix导读本文围绕 AIBrix 的PodAutoscaler自定义资源系统讲解其内置的三种基于指标的自动扩缩容机制——Knative 风格的 KPA、Kubernetes 原生 HPA以及 AIBrix 专为 LLM 推理服务设计的 APAAdvanced Pod Autoscaler。你将学会如何通过一份 YAML 配置完成 autoscaler 的部署、如何调优 metric window、scheduled replica bounds、annotation 参数如何使用 Kubernetes external metrics API 进行跨组件扩缩容以及如何对 StormService 的 prefill/decode 角色做细粒度独立扩缩容。读完本文你可以直接在 AIBrix 集群中复制并运行所有示例并理解底层控制器controller的判定逻辑与日志排查方法。三种扩缩容机制概览AIBrix 的 autoscaler 组件隶属于 aibrix controller manager支持多种基于指标的扩缩容机制用户只需在PodAutoscaler的spec.scalingStrategy字段中选择即可切换策略来源特点HPAKubernetes 原生 Horizontal Pod Autoscaler与原生 HPA 行为一致基于 CPU 等指标缩放 Deployment 副本响应较慢但生态成熟KPA灵感来自 Knative维护stable window稳定窗口与panic window恐慌窗口两个时间窗口基于短窗口测量对流量突增快速扩容与依赖 Prometheus 拉取指标的方案不同AIBrix 内部自行拉取并维护指标响应更快APAAIBrix 自研专为 LLM 推理优化与 HPA 类似但引入 fluctuation波动容忍参数作为触发扩容/缩容前的最小缓冲防止震荡oscillation从源码类型定义看三种策略在 api/autoscaling/v1alpha1/podautoscaler_types.go 中被建模为ScalingStrategyType枚举const ( HPA ScalingStrategyType HPA // Kubernetes 原生 Horizontal Pod Autoscaler KPA ScalingStrategyType KPA // KNative Pod Autoscaling Algorithm APA ScalingStrategyType APA // AiBrix Pod Autoscaling Algorithm )HPA 与 KPA 虽被广泛使用但并非针对 LLM 推理服务的独特优化点而设计。AIBrix 的自研 APA 方案正在逐步引入以下能力部分仍在开发中基于 AI Runtime 指标标准化选择适合 LLM 服务的专用指标进行扩缩容前瞻式proactive扩缩容算法而非纯反应式reactiveWIPProfiling 与 SLO 驱动的扩缩容方案Testing Phase。支持的指标MetricsAIBrix 支持 vLLM 暴露的全部指标。这些指标通过 vLLM 的/metrics端点以 Prometheus 格式暴露例如本文示例中反复出现的gpu_cache_usage_percGPU KV cache 使用率、num_requests_waiting等待中的请求数等均属于 vLLM 运行时指标。配合 pkg/metrics 下的实现AIBrix 也可以消费网关侧指标如aibrix_running_requests和自定义指标用于更贴合 LLM 场景的扩缩容决策。如何部署扩缩容策略部署 autoscaler 非常简单直接应用一份PodAutoscalerYAML 即可。一个关键约束是scaleTargetRef中的 name 必须与目标 Deployment 的名称完全一致AIBrix 的 PodAutoscaler 正是通过这一名称找到正确的扩缩容对象。所有示例文件都位于仓库的 samples/autoscaling 目录下本文后续示例均可在该目录中找到对应文件。HPA 示例配置文件samples/autoscaling/hpa.yamlapiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: deepseek-r1-distill-llama-8b-hpa namespace: default labels: app.kubernetes.io/name: aibrix app.kubernetes.io/managed-by: kustomize spec: scalingStrategy: HPA minReplicas: 1 maxReplicas: 10 metricsSources: - metricSourceType: pod protocolType: http port: 8000 path: /metrics targetMetric: gpu_cache_usage_perc targetValue: 50 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: deepseek-r1-distill-llama-8bKPA 示例配置文件samples/autoscaling/kpa.yamlapiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: deepseek-r1-distill-llama-8b-kpa namespace: default labels: app.kubernetes.io/name: aibrix app.kubernetes.io/managed-by: kustomize annotations: autoscaling.aibrix.ai/scale-down-cooldown-window: 3m spec: scalingStrategy: KPA minReplicas: 1 maxReplicas: 8 metricsSources: - metricSourceType: pod protocolType: http port: 8000 path: metrics targetMetric: gpu_cache_usage_perc targetValue: 0.5 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: deepseek-r1-distill-llama-8bAPA 示例配置文件samples/autoscaling/apa.yamlapiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: deepseek-r1-distill-llama-8b-apa namespace: default labels: app.kubernetes.io/name: aibrix app.kubernetes.io/managed-by: kustomize annotations: autoscaling.aibrix.ai/up-fluctuation-tolerance: 0.1 autoscaling.aibrix.ai/down-fluctuation-tolerance: 0.2 apa.autoscaling.aibrix.ai/window: 30s spec: scalingStrategy: APA minReplicas: 1 maxReplicas: 8 metricsSources: - metricSourceType: pod protocolType: http port: 8000 path: metrics targetMetric: gpu_cache_usage_perc targetValue: 0.5 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: deepseek-r1-distill-llama-8b注意 APA 使用了三组特有的 annotationup-fluctuation-tolerance向上触发扩容前允许的波动比例、down-fluctuation-tolerance向下触发缩容前允许的波动比例以及apa.autoscaling.aibrix.ai/windowAPA 的观察窗口时长。被扩缩容的目标工作负载以上示例中的scaleTargetRef指向同名 Deployment。配套的工作负载示例见 samples/autoscaling/deploy.yaml它通过vllm serve启动 DeepSeek-R1-Distill-Llama-8B暴露 8000 端口的/metrics与/health探针并在 Pod 注解中声明prometheus.io/scrape: true、prometheus.io/port: 8000、prometheus.io/path: /metrics从而让指标可以被正常采集。Configurable metric windows可配置的指标窗口PodAutoscaler在spec下支持两个可选的指标窗口字段用于控制 autoscaler 在做扩缩容决策时保留多少最近的指标历史字段默认值合法范围说明observeWindowSeconds1801~3600稳定指标窗口用于常规扩缩容建议。增大可平滑噪声指标减小可让 autoscaler 对近期负载变化反应更快panicWindowSeconds601~3600KPA 恐慌模式使用的短指标窗口。必须小于等于observeWindowSeconds若任一字段省略AIBrix 使用上表默认值。校验规则会拒绝非正值、大于3600的值以及panicWindowSeconds大于observeWindowSeconds的配置。该校验在比较时会对省略的字段使用默认值因此如果你把observeWindowSeconds设到60以下也必须同时把panicWindowSeconds设为相同或更小的值。这些字段在 API 类型中的定义位于 api/autoscaling/v1alpha1/podautoscaler_types.go带有kubebuilder:validation:Minimum1与kubebuilder:validation:Maximum3600的 CRD 校验注解与文档描述的规则完全对应。下面是一个10 分钟稳定窗口 1 分钟恐慌窗口的 KPA 示例apiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: example-kpa-windows spec: scalingStrategy: KPA minReplicas: 1 maxReplicas: 8 observeWindowSeconds: 600 panicWindowSeconds: 60 metricsSources: - metricSourceType: pod protocolType: http port: 8000 path: metrics targetMetric: gpu_cache_usage_perc targetValue: 0.5 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: deepseek-r1-distill-llama-8bScheduled replica bounds按时间调度副本上下限PodAutoscaler还支持在spec.schedules下配置按时间调度的副本上下限。每条 schedule 定义一个循环的每日墙钟时间窗口包含startTime与endTime严格使用零填充的HH:MM格式start 时间含、end 时间不含。在窗口生效期间schedule 会覆盖基础的spec.minReplicas和/或spec.maxReplicas。行为约定如下省略timezone时按 UTC 评估设置时必须为合法的 IANA 时区如America/Los_Angeles省略daysOfWeek时每天生效设置时接受英文三字母星期名Mon到Sun每条 schedule 可只设置minReplicas、只设置maxReplicas或两者都设置部分覆盖时缺失的边界继承自基础 PodAutoscaler spec校验会拒绝以下配置未设置任一边界、有效最小值大于有效最大值、非法时区、非法时间格式、跨午夜span midnight、或与其他 schedule 窗口重叠。重叠窗口会被直接拒绝而不是依赖隐式优先级。在调度模型中PodAutoscalerSchedule结构体定义于 api/autoscaling/v1alpha1/podautoscaler_types.go其中startTime/endTime均带^([01][0-9]|2[0-3]):[0-5][0-9]$正则校验name遵循 Kubernetes DNS label 风格。HPA、KPA、APA 三种策略都会使用生效后的调度边界。对于 HPA 策略AIBrix 会把生效边界写入生成的 KubernetesHorizontalPodAutoscaler对象如果有效最小值是0生成的 HPA 会省略spec.minReplicas以保持与原生 Kubernetes HPA 兼容行为相关实现见 pkg/controller/podautoscaler/hpa_resources.go。下面是带工作日业务时段边界的 APA 示例文件samples/autoscaling/scheduled-bounds-apa.yamlapiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: deepseek-r1-distill-llama-8b-scheduled-apa namespace: default labels: app.kubernetes.io/name: aibrix app.kubernetes.io/managed-by: kustomize spec: scalingStrategy: APA minReplicas: 1 maxReplicas: 10 schedules: - name: weekday-business-hours timezone: America/Los_Angeles daysOfWeek: [Mon, Tue, Wed, Thu, Fri] startTime: 09:00 endTime: 18:00 minReplicas: 4 maxReplicas: 12 metricsSources: - metricSourceType: pod protocolType: http port: 8000 path: metrics targetMetric: gpu_cache_usage_perc targetValue: 0.5 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: deepseek-r1-distill-llama-8b使用 Kubernetes external metrics API除了直接抓取 metrics 端点PodAutoscaler还可以从 Kubernetes 的external.metrics.k8s.ioAPI 读取目标指标。这样你就能基于外部 metrics adapter例如 Prometheus Adapter 或自研 adapter发布的任意指标进行扩缩容AIBrix 无需自行访问工作负载的 metrics 端口。这在目标信号不在 Pod 上时非常有用例如Broker 中的队列深度或者已被现有监控栈聚合好的指标。如何选择 external metrics API当metricSourceType为external且不设置endpoint时该 metric source 就使用 Kubernetes external metrics API一旦设置了endpoint同一 source 类型会切回抓取该 HTTP 端点此时protocolType、endpoint、path均必填。因此使用 external metrics API 时只需要指定指标及其目标值metricsSources: - metricSourceType: external targetMetric: aibrix_running_requests targetValue: 100这里省略endpoint、path和protocolType是有意为之并非示例不完整。注意MetricSourceType中external与已废弃的domain的枚举定义见 api/autoscaling/v1alpha1/podautoscaler_types.go。使用前提集群中必须安装 external metrics adapter并对外提供external.metrics.k8s.ioAPI groupadapter 必须在目标工作负载所在的 namespace中暴露targetMetric指定的指标AIBrix controller 需要对external.metrics.k8s.io拥有get和list权限——仓库自带的 RBAC 已默认授予。排障提示如果 controller 启动时无法构造 external metrics clientcontroller 只会记录一条 warning 并继续运行此时 external metrics 不可用。因此如果一个使用该模式的PodAutoscaler始终不扩缩容请先检查 controller 的日志。external metrics KPA 示例文件samples/autoscaling/external-metrics-kpa.yamlapiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: deepseek-r1-distill-llama-8b-external-kpa namespace: default labels: app.kubernetes.io/name: aibrix app.kubernetes.io/managed-by: kustomize annotations: autoscaling.aibrix.ai/scale-down-cooldown-window: 3m spec: scalingStrategy: KPA minReplicas: 1 maxReplicas: 8 metricsSources: # Uses Kubernetes external.metrics.k8s.io. Do not set endpoint, path, or # protocolType for this mode. - metricSourceType: external targetMetric: aibrix_running_requests targetValue: 100 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: deepseek-r1-distill-llama-8bexternal metrics APA 示例文件samples/autoscaling/external-metrics-apa.yamlapiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: deepseek-r1-distill-llama-8b-external-metrics namespace: default labels: app.kubernetes.io/name: aibrix app.kubernetes.io/managed-by: kustomize annotations: autoscaling.aibrix.ai/up-fluctuation-tolerance: 0.1 autoscaling.aibrix.ai/down-fluctuation-tolerance: 0.2 apa.autoscaling.aibrix.ai/window: 30s spec: scalingStrategy: APA minReplicas: 1 maxReplicas: 8 metricsSources: # Uses Kubernetes external.metrics.k8s.io. An external metrics adapter must # expose this metric in the same namespace as the target workload. - metricSourceType: external targetMetric: aibrix_queue_depth targetValue: 40 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: deepseek-r1-distill-llama-8bPodAutoscaler 支持的注解annotations基于指标的 autoscaler 可以通过PodAutoscaler对象上的注解进行调优。controller 目前识别以下autoscaling.aibrix.ai/前缀的通用注解键。注解值是 Kubernetes metadata 中的字符串因此在 YAML 中需要对数值与时长加引号。时长使用 Go duration 语法解析如30s、5m浮点值按十进制数解析如0.1、2.0。这些注解键的源码常量定义在 pkg/controller/podautoscaler/types/annotations.go与下表一一对应注解值类型默认值适用策略说明autoscaling.aibrix.ai/max-scale-up-ratefloat2HPA, KPA, APA限制单次扩缩容决策中副本可以增加的速率。例如2.0表示建议副本数最多增长到当前副本数的 2 倍autoscaling.aibrix.ai/max-scale-down-ratefloat2HPA, KPA, APA限制单次决策中副本减少的速率。例如2.0防止单次决策缩到当前副本数的一半以下autoscaling.aibrix.ai/scale-up-tolerancefloat0.1KPA, APA避免对微小指标波动触发扩容。0.1表示指标须超过目标值 10% 以上才会扩容autoscaling.aibrix.ai/scale-down-tolerancefloat0.1KPA, APA避免对微小指标波动触发缩容。0.1表示指标须低于目标值 10% 以上才会缩容autoscaling.aibrix.ai/panic-thresholdfloat2.0KPA设置进入 KPA panic 模式的阈值当短窗口需求相对稳定窗口需求偏高时触发autoscaling.aibrix.ai/scale-up-cooldown-windowduration0sHPA, KPA, APA扩容建议的稳定窗口stabilization windowautoscaling.aibrix.ai/scale-down-cooldown-windowduration300sHPA, KPA, APA缩容建议的稳定窗口默认 5 分钟autoscaling.aibrix.ai/scale-to-zeroboolfalseKPA, APA开启 scaling context 的 scale-to-zero 标志最终副本数仍受spec.minReplicas约束注解示例apiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: example-kpa annotations: autoscaling.aibrix.ai/max-scale-up-rate: 3.0 autoscaling.aibrix.ai/max-scale-down-rate: 2.0 autoscaling.aibrix.ai/scale-up-tolerance: 0.2 autoscaling.aibrix.ai/scale-down-tolerance: 0.1 autoscaling.aibrix.ai/panic-threshold: 2.5 autoscaling.aibrix.ai/scale-up-cooldown-window: 30s autoscaling.aibrix.ai/scale-down-cooldown-window: 5m autoscaling.aibrix.ai/scale-to-zero: false spec: scalingStrategy: KPA从代码注释pkg/controller/podautoscaler/types/annotations.go可以进一步确认语义max-scale-up-rate的2.0表示单步可翻倍副本panic-threshold的2.0表示短期需求超过长期均值 2 倍时进入恐慌模式。这些注解最终会被 controller 读取并注入各策略的 scaling context 中参见 pkg/controller/podautoscaler/podautoscaler_controller.go。StormService 角色级Role-Level自动扩缩容对于 Pooled 模式的 StormServicespec.mode: Pooledprefill 与 decode 等不同角色role可以独立扩缩容每个角色基于自身指标做细粒度伸缩。关键用法使用subTargetSelector字段在 StormService 内选中特定角色在 StormService 上声明spec.modePooled表示扩缩容选中的角色Replica表示扩缩容spec.replicas。autoscaler 读取spec.mode来决定角色级扩缩容——仅靠replicas1无法区分两种模式PodAutoscaler注解autoscaling.aibrix.ai/storm-service-mode已废弃仅在目标 StormService 未声明spec.mode时作为兼容性回退被采纳。核心能力每个角色拥有独立的 PodAutoscaler、独立指标与独立扩缩容策略适用于 Pooled 模式replicas1的 StormService每个角色可选用不同策略HPA、KPA、APA每个角色可设置不同的 min/max 副本数与扩缩容行为。适用场景Pooled 模式replicas1的 StormService 需要各角色独立伸缩不同负载模式prefill 与 decode 的资源需求与流量特征不同独立指标每个角色有自己的指标如队列长度、batch 利用率。subTargetSelector在 API 类型中对应SubTargetSelector结构体api/autoscaling/v1alpha1/podautoscaler_types.go通过roleName选择 StormService/RoleSet 内的角色。完整示例见 samples/autoscaling/stormservice-pool.yaml其中 prefill 角色以prefill_queue_length为目标targetValue10decode 角色以decode_batch_utilization为目标targetValue70且 decode 额外设置了更保守的stabilizationWindowSeconds: 600缩容行为--- # PodAutoscaler for prefill role apiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: ss-pool-prefill namespace: default spec: scaleTargetRef: apiVersion: orchestration.aibrix.ai/v1alpha1 kind: StormService name: ss-pool subTargetSelector: roleName: prefill minReplicas: 2 maxReplicas: 20 scalingStrategy: APA metricsSources: - metricSourceType: pod protocolType: http port: 8000 path: /metrics targetMetric: prefill_queue_length targetValue: 10 --- # PodAutoscaler for decode role apiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: ss-pool-decode namespace: default spec: scaleTargetRef: apiVersion: orchestration.aibrix.ai/v1alpha1 kind: StormService name: ss-pool subTargetSelector: roleName: decode minReplicas: 3 maxReplicas: 30 scalingStrategy: APA metricsSources: - metricSourceType: pod protocolType: http port: 8000 path: /metrics targetMetric: decode_batch_utilization targetValue: 70 behavior: scaleDown: stabilizationWindowSeconds: 600 # More conservative scale-down多指标Multi-Metric自动扩缩容AIBrix 支持在单个PodAutoscaler中定义多个扩缩容指标。这对 LLM 推理服务尤其重要——单一指标如 GPU cache 使用率可能无法完整反映系统压力将其与队列类指标如等待请求数组合能做出更稳健、更灵敏的扩缩容决策。工作原理当spec.metricsSources下指定多个指标时autoscaler 会独立评估所有指标最终期望副本数由要求副本数最高的那个指标决定即max策略。配置示例APA 策略同时使用两个指标文件samples/autoscaling/multimetrics-apa.yamlapiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: deepseek-r1-mock-llama2-7b-multi-metrics namespace: default labels: app.kubernetes.io/name: aibrix app.kubernetes.io/managed-by: kustomize annotations: autoscaling.aibrix.ai/up-fluctuation-tolerance: 0.1 autoscaling.aibrix.ai/down-fluctuation-tolerance: 0.2 apa.autoscaling.aibrix.ai/window: 30s spec: scalingStrategy: APA minReplicas: 1 maxReplicas: 3 metricsSources: - metricSourceType: pod protocolType: http port: 8000 path: metrics targetMetric: gpu_cache_usage_perc targetValue: 0.5 - metricSourceType: pod protocolType: http port: 8000 path: metrics targetMetric: num_requests_waiting targetValue: 100 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: mock-llama2-7b补充说明从 api/autoscaling/v1alpha1/podautoscaler_types.go 看metricsSources带有MinItems1校验即至少需要一个指标源而辅助函数GetPaMetricSources仍保留了当前仅支持单个 MetricSource的旧有约束注释api/autoscaling/v1alpha1/podautoscaler_types.go多指标场景由 controller 主循环直接消费整个列表完成聚合评估。查看扩缩容日志与自定义资源状态PodAutoscaler 日志Pod autoscaler 是 aibrix controller manager 的一部分负责从每个 Pod 采集指标。查看日志kubectl logs aibrix-controller-manager-podname -n aibrix-system -f期望的日志输出会展示当前使用的指标例如gpu_cache_usage_perc并逐一显示每个 Pod 的当前指标值便于定位指标是否采到各 Pod 负载是否均衡等问题。controller manager 的部署与权限配置可在 config/manager/manager.yaml 与 config/rbac 中查看。查看自定义资源状态使用以下命令查看 PodAutoscaler 的详细状态kubectl describe podautoscaler podautoscaler-name如输出所示describe 结果会展示该 PodAutoscaler 的 Spec策略、min/max、指标源、目标引用与 Status 事件流如KPA algorithm run, currentReplicas: 1, desiredReplicas: 1, rescale: false以及指标抓取失败、扩缩容成功等 Normal/Warning 事件可据此判断算法是否运行、指标是否成功获取、副本是否按预期变化。此外PodAutoscalerStatus还包含desiredScale、actualScale、conditions、scalingHistory最近 N 次扩缩容决策与scheduledBounds当前生效的调度边界等字段定义见 api/autoscaling/v1alpha1/podautoscaler_types.go可通过kubectl get podautoscaler -o yaml进一步查看。不同 autoscaler 的初步对比实验AIBrix 提供了一套初步实验数据展示不同扩缩容机制与配置对**性能延迟与成本计算成本**的影响。在 AIBrix 中用户只需 apply K8s YAML 即可轻松切换不同 autoscaler。实验设置模型Deepseek 7B 聊天模型GPU 类型V100GPU 最大数量8目标指标与值指标gpu_kv_cache_utilization目标值50%工作负载整体 RPS 趋势从低 RPS 开始在 T500 前较快上升用于评估不同 autoscaler 对快速负载增长的响应随后快速回落到低 RPS 以评估缩容行为再缓慢回升。平均 RPS 趋势1 RPS → 4 RPS → 8 RPS → 10 RPS → 2 RPS → 6 RPS性能延迟HPA 因响应慢而延迟最高KPA 因 panic 模式响应最快APA 使用较小的延迟窗口以节省成本确实省了成本但从 T700 到 T1000 因缩容过于激进延迟高于 KPA。成本累积成本 时间 × 单位成本本例单位成本为 1实际计算成本可用实际每单位时间成本相乘得到。HPA 因更长的缩容延迟窗口而成本最高APA 响应最快、最节省成本可以看到其波动比其他两者更明显需要说明的是缩容窗口并不是各扩缩容机制的内在特性而是可配置变量本实验对 HPA 使用了默认值300s。结论没有一种 autoscaler 能在所有指标延迟、成本上全面胜出结果还取决于工作负载形态。基础设施应当提供简单的方式让用户按需选择扩缩容机制并保持高度可配置因为不同用户偏好不同——有人更看重成本有人更看重性能。上图为实验可视化结果包含延迟 CDF、负载RPS、运行中 Pod 数、累积成本的时间序列以及平均延迟、P99 延迟、总成本、失败请求数的汇总柱状图。实验原始脚本与配套场景可参考 benchmarks/scenarios/autoscaling 目录。小结AIBrix 的 metric-based autoscaling 通过一个统一的PodAutoscalerCRD 封装了 HPA、KPA、APA 三种机制并在此基础上叠加了 metric window、scheduled replica bounds、external metrics、多指标聚合、StormService 角色级扩缩容等面向 LLM 推理场景的增强能力。所有示例配置集中在 samples/autoscaling核心类型定义在 api/autoscaling/v1alpha1/podautoscaler_types.go注解常量在 pkg/controller/podautoscaler/types/annotations.go。你可以先从一个单指标 APA 配置起步再逐步引入多指标、调度边界与角色级扩缩容并通过kubectl describe podautoscaler和 controller 日志持续观察与调优。【免费下载链接】aibrixCost-efficient and pluggable Infrastructure components for GenAI inference项目地址: https://gitcode.com/GitHub_Trending/ai/aibrix创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考