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 技術路線。定性評估，實際表現因叢集規模與調參而異。
| 維度 | Kubernetes HPA | Kubernetes VPA | Cluster Autoscaler | Karpenter | KEDA | Knative Serving |
|---|---|---|---|---|---|---|
| 伸縮粒度 | Pod 副本數 | Pod 資源 requests/limits（推薦值） | 叢集節點數 | 節點數（例項選擇更靈活） | Pod 副本數（工作負載級別） | Revision 副本數 |
| 觸發訊號 | CPU、記憶體、自定義指標 | 歷史使用量分析（離線推薦） | 待排程 Pod 的資源缺口 | 待排程 Pod 的資源缺口 | 外部事件（Kafka、Prometheus、Azure Queue 等） | 併發請求數 |
| 響應速度（典型） | 15–60 秒 | 非即時，建議慢迴圈 | 分鐘級（節點啟動主導） | 秒級（快速選擇例項並啟動） | 秒級–分鐘級 | 毫秒–秒級（結合緩衝） |
| 縮容能力 | 可縮容，含冷卻期 | 可調整上限，不縮小 requests | 排空節點後縮容 | 快速縮容，支援優雅終止 | 支援縮至零 | 支援縮至零 |
| GPU 親和性 | 間接，通過自定義指標/排程器 | 不支援直接修改 GPU 請求 | 感知 GPU 資源型別 | 感知 GPU 例項型別，可選擇最優 GPU 例項 | 可通過 Prometheus 採集 DCGM 實現 | 通過 Activator 佇列代理感知 |
| 成本最佳化 | 無內建成本模型 | 無 | 無 | 支援 Spot 例項、多樣化例項選擇 | 無 | 無 |
| 適用場景 | 常規微服務、小規模推論 | 資源利用率長期最佳化 | 叢集級水位調節 | 大規模、成本敏感、多例項型別叢集 | 事件驅動、批次處理、離線推論 | 無伺服器風格、高彈性推論 |
此外，垂直擴縮容（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 感知”“成本驅動”“預測伸縮”等維度對比：
| 玩家 | 型別 | 跨雲端支援 | GPU 感知 | 成本驅動 (Spot/預留套利) | 預測伸縮 | 縮至零 | 關鍵特色 |
|---|---|---|---|---|---|---|---|
| AWS Auto Scaling + Karpenter | 公有雲端內建/開源 | 僅 AWS | 通過例項型別感知 GPU | 中等（Karpenter 最佳化 Spot） | 否（2024 年未預設提供） | 否 | Karpenter 快速節點選擇，支援自定義 AMI |
| GKE Autopilot | 公有雲端全託管 | 僅 GCP | 支援 GPU 節點池 | 自動選擇最優惠例項 | 是（2023 年推出預測性自動縮放預覽） | 是（應用層） | 全託管，無需管理節點 |
| Azure VMSS + AKS CA | 公有雲端內建 | 僅 Azure | 支援 NCas_T4 等 GPU 節點 | 通過 VMSS 的 Spot VM 支援 | 是（2023 年 GA 預測式自動縮放） | 否 | 與 Azure 監控深度整合 |
| CAST AI | 獨立 SaaS | AWS/GCP/Azure | 感知 GPU 例項型別與庫存 | 強，即時競價最佳化 | 否，基於反應式 + 成本最佳化 | 否 | 專注 K8s 成本，提供 Cost Monitoring |
| Spot by NetApp | 獨立 SaaS | AWS/Azure/GCP | 部分支援 | 極強，Spot 中斷預測 | 否（主要依賴排程） | 否 | 海洋 (Ocean) 產品負責節點彈性，宣稱節省 60%+ |
| KEDA | 開源（CNCF 孵化） | 任何 K8s 叢集 | 通過 Prometheus+DCGM 可間接支援 | 無 | 無，可結合預測模型但非內建 | 是 | 事件驅動，可基於 Kafka 延遲等伸縮 |
| Knative Serving | 開源 | 任何 K8s 叢集 | 通過 K8s 排程器間接支援 | 無 | 無 | 是 | 請求驅動，配合 Activator 實現冷啟動最佳化 |
由此可見，雲端廠商內建能力在整合度和資料來源上有優勢，獨立 ISV 則靠跨雲端和高階成本最佳化建立壁壘，開源專案則在標準化與事件驅動上不斷擴充套件。
風險
儘管 Autoscaling 是成本與效率的利器，若設計或配置不當，可能引發多重風險：
- 振盪與過度伸縮：伸縮引數設定不合理（如冷卻期過短、步長過大），導致系統陷入“擴-縮-擴-縮”的抖晃迴圈，增加延遲抖動和記賬碎度，嚴重時可引發級聯故障。
- 冷啟動延遲與服務質量下降：模型服務副本冷啟動耗時常在 30 秒到 5 分鐘之間，期間如無緩衝佇列或預熱池，P99 延遲可能飆升，觸發客戶端超時或上游限流。對於大語言模型，GPU 視訊記憶體中無 KV Cache 預熱，冷啟動後需逐步快取，服務質量在數分鐘內波動。
- 庫存與容量不足：GPU 例項規格（如 p4d、NC96ads A100 v5）在特定區域經常缺貨，即使 Autoscaler 決策正確，也無法分配資源，導致請求積壓。尤其在 Spot 例項被大規模回收時，突發置換需求可能無法滿足。
- 成本異常升高：錯誤的高目標利用率或對 Spot 價格波動預估不足，可能導致使用高價按需例項，反而推高賬單。若未設合理最大副本數，還可能出現因流量攻擊或 Bug 導致無限擴容的“賬單攻擊”。
- 多租戶資源爭用：在共享 Kubernetes 叢集中，一個租戶的自動擴容可能擠壓其他租戶資源，需要配合 ResourceQuota、LimitRange 和優先順序搶佔策略。
- 安全與合規風險：自動建立新節點時，可能未正確註冊安全組、映象漏洞或合規配置（如日誌審計）被遺漏，形成盲區。需將自動伸縮流程納入 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 進行成本歸因，持續追蹤上述指標。
信源
本頁綜合公開技術文件、雲端廠商產品說明、開源專案實踐及研究論文，核心來源包括：
- Kubernetes 官方文件：Horizontal Pod Autoscaling、Cluster Autoscaler、Karpenter 設計思想（訪問 2024 年初）。
- Google, “Autopilot: workload autoscaling at Google scale,” EuroSys 2020.
- NVIDIA DCGM 使用者指南 (2023)，GPU 監控指標與最佳實踐。
- Fortune Business Insights, “GPU Cloud Market Size, Share & COVID-19 Impact Analysis,” 2023.
- Gartner, “Predicts 2023: Cloud Infrastructure and Platform Services,” 2023.
- Flexera, “2023 State of the Cloud Report,” 2023.
- CAST AI 新聞稿，2023 年 3 月 20 日，B 輪融資。
- NetApp 公告：“NetApp Acquires Spot,” 2020 年 6 月。
- Google Cloud Blog, “Predictive Autoscaling for GKE now in public preview,” 2023 年 5 月.
- Azure 更新日誌，“VMSS predictive autoscale now generally available,” 2023 年 11 月.
- CNCF, “KEDA moves to incubation,” 2023 年 8 月.
- Karpenter GitHub Releases (v0.29)，2023 年 7 月.
- CNCF DevStats 及專案儀表板，社群貢獻資料參考。
- 多家雲端廠商與獨立 ISV 的技術部落格與白皮書，用於定性對比與趨勢分析。
（因資訊檢索截止 2024 年初，部分規模資料為相鄰市場測算，建議通過上述來源交叉驗證。）