搜尋意圖： 如果你在找「自動擴展 是什麼」或「自動擴展 和相近概念差在哪」，先看這頁的短定義、完整說明與延伸比較。
TL;DR： 自動擴展根據系統負載自動調整計算資源，動態增加或減少伺服器數量，確保應用程式效能，同時優化成本。
實用情境： 適合用在閱讀 AI 文章、產品文件或和同事討論時，先用一頁快速對齊概念。
下一步： 先讀完定義，再往下看延伸比較與對應工具，把概念轉成實際應用。
網站在促銷時流量突然暴增，平常的伺服器數量撐得住嗎？ 你可以把自動擴展想成會看負載調機器數量的系統，忙的時候加人手，閒的時候收回來。 它能讓服務在尖峰時不掛掉，在低峰時不浪費資源。
你可以把它想成一個把抽象概念拉回日常判斷的提示，先知道它解決什麼問題，再看技術細節。
容易混淆
自動擴展 vs 負載平衡？ 自動擴展：依負載自動增減資源 負載平衡：把現有流量分散到多台機器 最關鍵的區別：擴展是增減容量，平衡是分配現有流量
水平擴展 vs 垂直擴展？ 水平擴展：增加機器數量 垂直擴展：升級單台機器規格 最關鍵的區別：自動擴展通常以水平擴展最常見
自動擴展 vs 快取？ 自動擴展：根據指標自動動作 快取：把熱門資料先存起來 最關鍵的區別：快取降低壓力，擴展增加容量，作用不同
記住這句就好
流量上來加資源，流量下來省成本
實際案例
購物節尖峰 晚間下單暴增時，平台把 Pod 數量拉高，等活動結束後再縮回來
夜間批次 凌晨工作量低，系統自動縮小資源，白天再依需求補回來
算法與應用
重點 你要看什麼 為什麼重要 指標 CPU、記憶體、請求數 用來判斷現在是不是太忙 策略 閾值、排程、預測 決定何時擴展與縮減 風險 抖動與冷啟動 避免一直加減造成不穩定
三種擴展策略
| 策略 | 觸發依據 | 適合 |
|---|---|---|
| 反應式（reactive） | 目前的指標超過門檻就擴 | 流量變化平緩、可容忍幾分鐘延遲 |
| 排程式（scheduled） | 依時間表，例如每天九點擴 | 尖峰時間可預測，例如上班打卡、每週報表 |
| 預測式（predictive） | 用歷史資料預測未來需求提前擴 | 尖峰陡峭、開機時間長的服務 |
三種常常一起用：用排程式處理已知的每日尖峰，反應式當作兜底，預測式再往前補一段暖機時間。
挑指標與設參數，這是實務上最容易出錯的地方
挑錯指標是最常見的問題。 CPU 使用率是預設選項，但很多服務的瓶頸不在 CPU。佇列長度、每秒請求數、回應時間 P95、GPU 記憶體用量，往往比 CPU 更能反映真實壓力。AI 推論服務尤其明顯，等待中的請求數通常是最直接的訊號。
冷卻時間（cooldown）沒設好會震盪。 擴出來的機器需要時間開機、載入模型、通過健康檢查，這段期間指標還是高的。如果沒有冷卻時間，系統會以為擴得不夠而繼續擴，等到全部就緒又發現過剩開始縮，縮完壓力又上來，來回震盪叫做 thrashing。
縮的門檻要比擴的門檻低很多。 兩個門檻靠太近同樣會震盪。常見做法是擴的門檻 70%、縮的門檻 30%，中間留一大段死區。
一定要設下限與上限。 下限保證半夜沒流量時仍有機器接住突發請求；上限保證程式出錯造成的假性負載不會把帳單燒穿。這一條在 AI 服務上特別重要，GPU 執行個體的單價高一個量級。
AI 推論的特殊考量：模型載入時間。 一般 Web 服務新機器幾秒就能服務，載入一個大模型可能要數分鐘。這代表反應式擴展幾乎一定來不及，必須靠預測式或保留一批熱備份。
情境判斷
Q1：如果 CPU 長時間超過門檻，自動擴展該不該啟動？ → 通常該啟動，因為這代表目前容量可能不夠
Q2：流量忽高忽低時，一直擴展和縮減都很頻繁，這代表什麼？ → 代表門檻或冷卻時間可能設太敏感，需要調整策略避免抖動
常見問題
自動擴展和自動伸縮是一樣嗎？
大致上是同一類概念，實務上常拿來指依負載自動調整資源。
擴展一定要搭配雲端嗎？
不是，但雲端平台通常最方便做自動化擴縮。
自動擴展會不會增加成本？
短時間看起來可能會增加，但通常是為了避免更大的故障成本與長期浪費。