Autoscaling

3 秒看懂

Autoscaling（自动扩缩容）是一套以工作负载实时需求驱动计算资源弹性供给的闭环控制系统。在 AI 产业链中，它直接对齐“训练任务能吃到 GPU、推理服务扛得住流量、且不为闲置资源买单”的核心矛盾。Autoscaling 不只是运维工具，而是云计算“弹性”承诺的技术兑现层，承载着 FinOps、集群利用率和业务连续性的三重诉求。

3 分钟产业解释

Autoscaling 并非单点技术，而是一个决定“何时加机器、加多少、何时撤掉”的多层控制体系。在大模型与高并发推理时代，其产业含义被重新书写：

• 训练侧：千卡 GPU 集群若依赖人工调度，资源利用率常在 30–60% 徘徊（行业经验值，如公开分享的 MLPerf 训练集群利用率）。Autoscaling 允许训练平台根据作业队列深度、空闲 GPU 数、Spot 实例价格自动扩缩节点，将算力成本压缩至“必要支出”区间。
• 推理侧：AI 推理的调用量波动可比传统微服务剧烈一个数量级——一次热点事件可能令 QPS 瞬间翻 10 倍。Autoscaling 需在“模型预热的冷启动延迟”与“为保平峰而过度供给”之间找到秒级均衡，并通常与模型瘦身、请求队列调度联动。
• 产业走向：从参照 CPU/内存的粗粒度伸缩（Kubernetes HPA），进化到事件驱动（KEDA）、预测式伸缩、以及感知 GPU 利用率与显存带宽的智能伸缩。头部云厂商和独立软件商正将 Autoscaling 包装为“自治集群”或“零运维 AI 平台”的核心模块，成为上云拼成本的基准能力。

技术原理

Autoscaling 的实质是一个以反馈回路为核心的控制器，其通用框架可抽象如下：

[监控指标源] ──→ [决策引擎（含镇定机制）] ──→ [资源调度器] ──→ [工作负载实例]
      ↑                                              │
      └──────────────── 状态反馈 ──────────────────┘

1. 指标采集与滤波

• 资源层：CPU/内存利用率、GPU 核心利用率、显存带宽占用（NVIDIA DCGM）、节点可分配量。
• 应用层：每秒请求数（RPS）、P50/P99 延迟、队列长度（如 KServe 推理积压数）、自定义业务指标。
• 滤波与去噪：滑动窗口平均（典型 1–2 分钟）、峰值抑制、离群值剔除，避免瞬时尖峰触发过度扩容。

2. 决策算法与镇定机制 经典目标利用率公式（Kubernetes HPA 风格）：

期望副本数 = ceil( 当前副本数 × ( 当前指标值 ÷ 目标指标值 ) )

为避免颠簸，引入多层镇定：

• 扩容冷却期（如 3 分钟）：一次扩容后，该期间不再触发新扩容（但允许缩容）。
• 缩容冷却期（如 5 分钟）：防止刚缩完又立即扩容。
• 步长限制：单次最大增减百分比（如 50%），或绝对增量上限。
• 最小/最大边界：副本数始终限制在 [min, max] 内。 对于 AI 推理，延迟是核心约束，常见策略是将 P99 延迟作为主控信号：若 P99 > 目标值 × 系数 且 RPS 上升，则触发扩容；若 P99 持续低于目标值一定幅度且流量平稳，则触发缩容。

3. 资源拓扑感知与 GPU 生态 在 GPU 环境中，伸缩需考虑“多少卡”与“什么拓扑”：

• 训练 Autoscaler 需感知 NVLink/NVSwitch 域、机间高速网络（如 InfiniBand），确保新增节点可与现有节点组成高速通信组，避免跨交换机通信降速。
• 推理 Autoscaler 可利用 MIG（Multi-Instance GPU）做更细粒度弹性。但 MIG 配置变更需停机或重建实例，当前无法在线实时切换，因此多以预定义 MIG 规格在调度层实现软弹性。

4. 冷启动压制与缓冲池 推理副本从拉取镜像、加载模型到就绪常耗时数十秒至数分钟。典型对策：

• 预热池：保持少量空闲热备副本，吸收瞬时流量尖刺。
• 请求队列：在扩容窗口期内暂存请求，待新副本就绪后集中消费（可能引入延迟抖动）。
• 模型缓存与快照：利用内存缓存、Model Store 预热与格式转换加速加载。
• 镜像分层：将基础环境与模型权重分离，降低启动时的传输量。

关键参数

Autoscaling 系统的行为由一组可调参数支配，参数设置直接影响成本与稳定性：

• 目标利用率/目标延迟（如 CPU 目标 60%、P99 目标 200ms）：越高，资源利用率越高但爆风险越大；越低，缓冲越足但浪费越大。
• 冷却期（扩容冷却/缩容冷却）：冷却是防抖振的核心。过短引发抖动，过长导致供给调整滞后。
• 步长限制：单次扩容最大副本数或百分比。限制过大可能引发资源瞬时需求冲击；过小则无法跟上激增流量。
• 最小/最大副本数：硬天花板与地板，即使是异常工作负载也不得逾越。
• 缩容保护期（Stabilization Window）：指标必须在连续 N 秒内均低于阈值才允许缩容，避免瞬时低谷导致过度缩容。
• GPU 专用阈值：如 DCGM 报告的 GPU 引擎利用率目标、显存带宽占用百分比，通常设置 70–85% 为舒适区（来源：NVIDIA 最佳实践指南，2023）。
• 预热时间：预估新实例从启动到就绪的时长，用于触发预扩容的提前量。
• 预测模型置信度（如预测式伸缩）：仅当预测可信度高于阈值时生效，否则退化为反应式伸缩。
• 最大节点数/节点池抗预算线：与云厂商 Spot 中断率、预留实例组合挂钩的预算限制。

上述参数的具体值高度依赖应用画像，不存在“银弹”，各参数的敏感度需通过混沌工程与历史回放测试验证。

技术路线

以下从伸缩粒度、触发信号、响应速度、GPU 亲和性等维度，对比主流 Autoscaling 技术路线。定性评估，实际表现因集群规模与调参而异。

此外，垂直扩缩容（VPA）常与 HPA 配合使用，形成“水平伸缩+垂直调优”组合。在多租户 AI 平台中，Volcano、Kueue 等调度器提供面向作业队列的弹性伸缩，弥补上述工具在批量训练场景的不足。

上游

Autoscaling 的决策质量与响应速度深度依赖上游系统：

• 监控与遥测：Prometheus、NVIDIA DCGM、Datadog、OpenTelemetry。指标采集精度、延迟与覆盖度决定了伸缩信号的可信度。DCGM 能提供 SM 占用率、帧缓冲占用等 GPU 关键指标（来源：NVIDIA DCGM 文档，2023）。
• 度量 API 层：Kubernetes Metrics API（CPU/内存）、Custom Metrics API、External Metrics API（外部事件）。错误配置或延迟过大的度量管线会直接损伤伸缩反应速度。
• 云实例与容量 API：AWS EC2 Auto Scaling groups、Azure VMSS、GCP MIG。需感知实例库存、Spot 中断率、可用区资源状态，以避免扩容至无法调度的区域。
• 成本信号源：Spot 实例价格历史、预留实例折扣率、承诺使用折扣策略。这些信号可输入基于成本最优的 Autoscaler（如 CAST AI、Karpenter 的 Spot 优化逻辑）。
• 镜像与模型仓库：容器镜像仓库（ECR、ACR）、模型仓库（Hugging Face Hub、S3）的下载速度直接影响冷启动时长。

下游

Autoscaling 的伸缩决策需在调度层与应用层兑现，主要下游有：

• 调度器与编排器：Kubernetes Scheduler、Volcano、Kueue。扩缩出的 Pod/节点请求需由调度器绑定到具体节点，且需遵守亲和性、拓扑分布约束。
• 工作负载与元数据：应用必须暴露正确的就绪探针（Readiness Probe）、优雅终止处理（PreStop Hook）以及资源 requests/limits。配置错误将导致扩缩无效或服务中断。
• 负载均衡与服务网格：新副本就绪后，需尽快被纳入流量分发；Istio、Linkerd 等 Sidecar 注入可能增加预热延迟，需配合预热功能。
• FinOps 与成本报表：伸缩行为直接影响云账单，需将扩缩记录与资源标签关联，支撑按成本中心分账和异常告警。
• 告警与稳定性监控：扩缩容失败、冷却循环、长时间不可调度等异常必须触发告警，防止静默故障。

受益公司

Autoscaling 作为提升云资源效率的核心机制，使多类公司受益，但受益逻辑与商业模式各异。

• 公有云提供商：AWS、微软 Azure、Google Cloud 将 Auto Scaling 作为 IaaS/PaaS 的标配，提升实例消耗量与客户黏性。例如，Amazon EC2 Auto Scaling 和 GKE Autopilot 均通过自动化增加负载托管量。云厂商不会单独披露自动伸缩贡献收入，但其提高了整体计算服务的使用率。
• 独立 Autoscaling ISV：
  • CAST AI：定位 Kubernetes 成本自动化，通过实时分析 Spot、预留及按需实例价格信号进行跨实例类型最优化伸缩。2023 年 3 月，公司完成 2000 万美元 B 轮融资（来源：CAST AI 新闻稿）。
  • Spot by NetApp（原 Spotinst）：利用 Spot 实例中断预测和价格信号驱动伸缩，宣称可降低工作负载成本 60–80%（厂商宣称值，需针对具体环境验证）。NetApp 于 2020 年以 4.5 亿美元收购 Spot（来源：NetApp 公告）。
  • 其他如 ScaleOps、KubeCost 等 FinOps 工具也将智能伸缩作为节省成本的关键卖点。
• AI 平台与 MLOps 公司：Anyscale、Domino Data Lab、Run:ai 等提供的 AI 训练/推理平台内置弹性伸缩，作为“算力管理”的核心功能，提升 GPU 利用率和多租户体验。
• 开源项目与基金会：CNCF 孵化的 KEDA（事件驱动自动伸缩）、Karpenter（节点生命周期管理）项目获得云厂商广泛集成，生态参与者（如 Red Hat、VMware）将之整合进商业发行版，形成技术服务收入。

市场规模

市场研究机构通常未将“Autoscaling”单独列为独立品类，然而与其直接相关的云弹性基础设施市场和 GPU 云市场显示了高速增长。

• GPU 云市场：根据 Fortune Business Insights 2023 年发布的报告，全球 GPU 云市场规模在 2022 年约 32 亿美元，预计至 2030 年将增至约 494 亿美元，年复合增长率（CAGR）达到 36.3%。其中，AI 训练和推理对弹性 GPU 的需求是主要驱动因素，自动伸缩是使 GPU 云成为可运营服务的必要技术层（来源：Fortune Business Insights, 2023；公开报告未见单独拆分 Autoscaling 工具占比）。
• 云成本优化市场：Gartner 在 2023 年预测，到 2025 年 70% 的大型企业将部署某种形式的云基础设施自动化与成本优化工具，涵盖预测性自动伸缩（来源：Gartner, 2023；具体市场规模未公布）。Flexera 2023 年云状况报告指出，超过 80% 的企业将“优化云成本”列为最高优先级，而自动伸缩是落地成本优化的前三大措施之一（来源：Flexera 2023 State of the Cloud Report）。
• 开源生态采纳：CNCF 的 KEDA 项目到 2023 年底已有超过 50 家企业贡献者，Karpenter 自 2021 年开源以来社区增长迅速，间接反映产业需求（来源：CNCF DevStats, 2023）。

公开资料未见针对 Autoscaling 软件和服务的独立市场规模，但结合上述相邻市场可判断其增长显著。

玩家对比

将主要 Autoscaling 厂商/项目按照“跨云支持”“GPU 感知”“成本驱动”“预测伸缩”等维度对比：

由此可见，云厂商内置能力在集成度和数据源上有优势，独立 ISV 则靠跨云和高级成本优化建立壁垒，开源项目则在标准化与事件驱动上不断扩展。

风险

尽管 Autoscaling 是成本与效率的利器，若设计或配置不当，可能引发多重风险：

1. 振荡与过度伸缩：伸缩参数设置不合理（如冷却期过短、步长过大），导致系统陷入“扩-缩-扩-缩”的抖晃循环，增加延迟抖动和记账碎度，严重时可引发级联故障。
2. 冷启动延迟与服务质量下降：模型服务副本冷启动耗时常在 30 秒到 5 分钟之间，期间如无缓冲队列或预热池，P99 延迟可能飙升，触发客户端超时或上游限流。对于大语言模型，GPU 显存中无 KV Cache 预热，冷启动后需逐步缓存，服务质量在数分钟内波动。
3. 库存与容量不足：GPU 实例规格（如 p4d、NC96ads A100 v5）在特定区域经常缺货，即使 Autoscaler 决策正确，也无法分配资源，导致请求积压。尤其在 Spot 实例被大规模回收时，突发置换需求可能无法满足。
4. 成本异常升高：错误的高目标利用率或对 Spot 价格波动预估不足，可能导致使用高价按需实例，反而推高账单。若未设合理最大副本数，还可能出现因流量攻击或 Bug 导致无限扩容的“账单攻击”。
5. 多租户资源争用：在共享 Kubernetes 集群中，一个租户的自动扩容可能挤压其他租户资源，需要配合 ResourceQuota、LimitRange 和优先级抢占策略。
6. 安全与合规风险：自动创建新节点时，可能未正确注册安全组、镜像漏洞或合规配置（如日志审计）被遗漏，形成盲区。需将自动伸缩流程纳入 CI/CD 与策略即代码体系。

误读纠偏

误读 1：“只要开启了 Autoscaling，就不会再有资源浪费或性能问题。” 纠偏：Autoscaling 解决的是供给与需求动态匹配问题，但无法弥补底层应用架构缺陷（如模型推理效率低下）或配置错误（如 HPA 目标 CPU 设为 90%，缩容空间极窄）。此外，不当的参数组合导致抖晃，本身就能恶化延迟和成本。必须通过系统性性能工程与参数调优方可发挥效能。

误读 2：“无服务器（Serverless）等于 Autoscaling 的终极形态，可以完全替代。” 纠偏：Serverless 平台（如 AWS Lambda、Knative）底层依赖 Autoscaling 系统，只是将复杂性隐藏起来。对于大模型推理（持久 GPU 缓存、大镜像），冷启动问题决定纯白盒 Serverless 不太现实。行业主流做法是将“预热池+请求队列”与 Autoscaling 结合，构建务实的弹性推理架构，而非抛弃底层伸缩控制。

误读 3：“引入 GPU 自动伸缩后，GPU 利用率自然就上去了，无需额外优化。” 纠偏：GPU 伸缩信号（如 DCGM SM 占用率）是滞后的聚合指标。若应用代码未能有效流水线化、或模型加载时间太久，利用率依然难提高。自动伸缩只是提高利用率的手段之一，需与内存格式优化、批处理大小调整及模型并发能力协同。

最新事件

• 2023 年 3 月：CAST AI 完成 2000 万美元 B 轮融资，资金将用于推进跨云成本驱动自动伸缩（来源：CAST AI 新闻稿）。
• 2023 年 5 月：Google Cloud 发布 GKE Predictive Autoscaling 的公开预览版，利用机器学习预测 CPU/内存负载并提前扩容，降低高延时敏感型业务抖动（来源：Google Cloud Blog）。
• 2023 年 7 月：Karpenter 发布 v0.29，增强对 Spot 实例中断的响应能力，并优化大规模集群的调度选择速度（来源：Karpenter GitHub Release）。
• 2023 年 8 月：KEDA 成为 CNCF 孵化项目，社区引入更多外部标量器（Scaler），如针对 GPU 指标的 Scaler，强化事件驱动自动伸缩在 AI 推理中的应用（来源：CNCF 博客）。
• 2023 年 11 月：Azure 宣布 VMSS 预测式自动缩放功能正式商用，支持基于历史 CPU 用量的预测，可提前 30 分钟内扩展虚拟机规模（来源：Azure 更新日志）。
• 2024 年初（截至知识截止点）：多家独立 AI 推理平台开始内置“模型预热调度器”，将自动伸缩与模型热备、KV Cache 提前加载结合，以解决大模型冷启动迟缓问题，但各厂商实现细节各异，具体性能数据公开资料未见。

跟踪指标

为有效治理 Autoscaling，建议以下跟踪指标与观测手段：

• 伸缩延迟：从指标越过阈值到新副本开始处理请求的起始耗时。目标值视场景：交互式推理 <30 秒极佳，批处理推理 <3 分钟可接受。
• 抖晃率：单位时间（如 1 小时）内发生“扩→缩→扩”完整循环次数。通过分析 K8s Event 或 HPA status 计算，理想状态接近于 0。
• 过度/不足供给比：实际供给资源与需求资源的累积偏差（积分值），可通过对监控指标与资源分配做差值积分求得，越小越好。
• 容量满足率：因资源库存不足而失败的扩容次数占总扩容尝试次数的比率。可反映 GPU 实例容量可用性，对 Spot 实例依赖高的集群尤为重要。
• GPU 平均利用率：核心利用率（DCGM SM 占用）、显存带宽占用。引入伸缩后预期从基线 40% 升至 60%+，但持续超过 85% 可能意味着安全边际不足。
• 冷却期空闲消耗：缩容窗口内仍为此前扩容而保留的资源量，可通过成本分析工具量化。
• 可用性 SLO：由于扩缩容不足导致的 5xx 或超时比例，建议目标的 99.9% 以上可用性中，伸缩相关错误率 <0.05%。
• 关键工具：结合 Prometheus + Grafana 构建伸缩仪表盘，利用 KEDA 的 Metrics API 暴露事件积压，通过 Kubecost 进行成本归因，持续跟踪上述指标。

信源

本页综合公开技术文档、云厂商产品说明、开源项目实践及研究论文，核心来源包括：

1. Kubernetes 官方文档：Horizontal Pod Autoscaling、Cluster Autoscaler、Karpenter 设计思想（访问 2024 年初）。
2. Google, “Autopilot: workload autoscaling at Google scale,” EuroSys 2020.
3. NVIDIA DCGM 用户指南 (2023)，GPU 监控指标与最佳实践。
4. Fortune Business Insights, “GPU Cloud Market Size, Share & COVID-19 Impact Analysis,” 2023.
5. Gartner, “Predicts 2023: Cloud Infrastructure and Platform Services,” 2023.
6. Flexera, “2023 State of the Cloud Report,” 2023.
7. CAST AI 新闻稿，2023 年 3 月 20 日，B 轮融资。
8. NetApp 公告：“NetApp Acquires Spot,” 2020 年 6 月。
9. Google Cloud Blog, “Predictive Autoscaling for GKE now in public preview,” 2023 年 5 月.
10. Azure 更新日志，“VMSS predictive autoscale now generally available,” 2023 年 11 月.
11. CNCF, “KEDA moves to incubation,” 2023 年 8 月.
12. Karpenter GitHub Releases (v0.29)，2023 年 7 月.
13. CNCF DevStats 及项目仪表板，社区贡献数据参考。
14. 多家云厂商与独立 ISV 的技术博客与白皮书，用于定性对比与趋势分析。

（因信息检索截止 2024 年初，部分规模数据为相邻市场测算，建议通过上述来源交叉验证。）