每秒萬次推論請求，什麼架構撐得住？
某 AI 服務系統每次推論請求需約 1 秒完成，且必須支援高達 10,000 次請求每秒（RPS）的流量。為確保系統具備高可用性且能穩定應付流量峰值，下列哪一種架構方案最為合適？
一個 AI 推論服務，每次請求要花 1 秒處理，而且尖峰時刻每秒有 10,000 個請求進來（10,000 RPS）。
問你：什麼架構方案最能同時確保高可用性（不容易掛掉）且能應付流量峰值？
一句話總結
每秒 1 萬個推論請求，每次要 1 秒，最好的架構是：容器化部署 + 水平擴展多個服務實例 + Auto Scaling（自動彈性伸縮），可以根據流量動態增減機器，流量大就自動加機器，流量小就縮回去省錢，且不會有單點故障。
先感受問題：10,000 RPS 是什麼規模
假設「星雲 AI 公司」提供一個圖片辨識 API，每張圖片辨識要花 1 秒。
先算一下規模：
每個請求要花 1 秒才能跑完
同時需要處理中的請求數 = 10,000 × 1 秒 = 10,000 個併發
也就是說，任意一個時刻，系統要同時「hold 住」10,000 個正在處理中的請求。
一台超強的伺服器，就算有 128 核心 CPU，同時只能跑 128 個執行緒，根本塞不下 10,000 個。要應付這個規模，必須把工作分散到許多台機器。
再加上「高可用性」的要求：如果只有一台機器，那台壞了整個服務就停了。要做到「掛了一台，其他台繼續跑」，就必須有多台機器並行提供服務。
單機垂直擴展或限流為什麼做不好
- 垂直擴展（加強單台機器）有天花板：就算買一台最強的伺服器，RAM 最多幾 TB，CPU 最多幾百核，永遠有上限。當流量超過單台上限，就只能加機器（水平擴展）。而且一台機器壞了，服務就全掛。
- 超強伺服器成本非常高：能同時處理 10,000 個 AI 推論請求的單台機器，如果存在的話，售價可能是幾十台普通機器的總和，而且備援成本更高。用很多台中等機器，性價比遠高於一台超強機。
- 限流根本是反其道而行：限制最大連線數，等於主動拒絕部分用戶的請求，在商業上不可接受。尖峰時刻本來就是服務最需要支撐的時候，直接關門等於放棄業務。
- 批次處理增加延遲：把 1000 個請求排成一批再一起處理，第 1 個請求要等 999 個請求都進來才開始跑，等待時間大幅增加，對需要即時回應的 AI API 服務不可行。
- 固定數量的機器無法應對峰谷：一天 24 小時流量不同，晚上 3 點可能只有 100 RPS，中午可能有 10,000 RPS。如果固定開 100 台機器，晚上 99 台在閒置浪費錢；如果固定開 5 台，中午完全撐不住。
容器化 + 水平擴展 + Auto Scaling，怎麼解
回到星雲 AI 公司。正確架構：
容器化部署（Containerization）：把 AI 推論服務打包成 Docker 容器，每個容器是一個獨立的推論實例，可以快速複製出來。容器啟動只要幾秒鐘（相比傳統虛擬機的幾分鐘），能快速應對流量變化。
水平擴展（Horizontal Scaling）：同時跑多個容器實例：
容器 2：處理請求 #101~200
容器 3：處理請求 #201~300
... 依此類推，直到塞滿 10,000 RPS
Auto Scaling（自動彈性伸縮）：系統監控 CPU 使用率和請求隊列長度，自動決定要開幾個容器：
中午 12 點：流量 8,000 RPS → 自動擴到 85 個容器
下班後：流量回落 → 自動縮回
任何一個容器掛掉，其他容器繼續服務，Kubernetes 或 ECS 自動補一個新的上來，做到高可用性。
這就是選項 B 講的：採用容器化部署並水平擴展服務實例，結合自動彈性伸縮機制（Auto Scaling）。
技術版：Kubernetes + HPA 的 Auto Scaling 實際設定
中級考試大概率會考程式碼跟公式，所以這部分你還是要學。但如果現在學起來很痛苦，可以先跳過，等讀完其他題目回頭再來。
用 Kubernetes 的 HPA（Horizontal Pod Autoscaler，水平 Pod 自動擴縮）：
# deployment.yaml — 部署 AI 推論服務
apiVersion: apps/v1
kind: Deployment
metadata:
name: ai-inference-service
spec:
replicas: 10 # 初始 10 個容器
selector:
matchLabels:
app: ai-inference
template:
spec:
containers:
- name: inference
image: starcloud/ai-inference:v3.2
resources:
requests:
cpu: "2" # 每個容器需要 2 CPU
memory: "4Gi"
limits:
cpu: "4"
memory: "8Gi"
---
# hpa.yaml — 自動擴縮設定
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: ai-inference-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: ai-inference-service
minReplicas: 5 # 最少 5 個容器
maxReplicas: 200 # 最多 200 個容器
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70 # CPU 用到 70% 就擴- AI 推論服務打包成 Docker 容器（像便當盒，可以複製）
- Kubernetes 負責管理這些容器：排程到哪台機器、確保數量、自動重啟掛掉的
- HPA 監控 CPU 使用率：用超過 70% 就多開幾個容器，低於 30% 就縮回去
- Load Balancer（負載平衡器）把進來的請求平均分給所有健康的容器
| 故事 | 設定 |
|---|---|
| 一開始開 10 個容器 | replicas: 10 |
| 最少維持 5 個（不能縮太少） | minReplicas: 5 |
| 最多擴到 200 個 | maxReplicas: 200 |
| CPU 用超過 70% 就擴 | averageUtilization: 70 |
- RPS（Requests Per Second）
- 每秒請求數。10,000 RPS 代表每秒有一萬個用戶送請求進來，是衡量系統負載的核心指標。
- Horizontal Scaling（水平擴展）
- 加更多台機器（或容器）分擔工作。相對於 Vertical Scaling（垂直擴展，把一台機器加強）。水平擴展的上限是機器數量，理論上可以無限擴展。
- Container / Docker
- 把應用程式和它所需的環境打包在一起的技術。容器比虛擬機輕量、啟動快，是現代雲端服務的標準部署方式。
- Auto Scaling / HPA
- 根據指標（CPU、記憶體、請求隊列長度）自動增減容器數量的機制。讓系統能彈性應對流量波動，不用人工介入。
計算需要幾個容器的基本公式：
# 若每個容器每秒能處理 C 個請求，目標 RPS = R
# 需要的容器數 = ceil(R / C)
target_rps = 10000 # 目標每秒請求數
latency_sec = 1 # 每次推論耗時 1 秒
threads_per_container = 4 # 每個容器 4 個工作執行緒
# 每個容器每秒能完成的請求數
capacity_per_container = threads_per_container / latency_sec # = 4
# 需要最少幾個容器
import math
min_containers = math.ceil(target_rps / capacity_per_container)
# = ceil(10000 / 4) = 2500 個容器這就是為什麼需要大量容器水平擴展，單台機器完全不可能撐住。
蓋住設定檔，說出 B 選項的 3 個關鍵要素：
- 容器化：讓服務可以快速複製和部署
- 水平擴展：同時跑多個容器分擔請求
- Auto Scaling：根據流量自動決定容器數量，不浪費也不超載
為什麼其他選項是錯的
A依賴單台超高效能伺服器進行垂直擴展，提升硬體規格
買一台規格最強的伺服器（更多 CPU、更多 RAM、更快的 GPU），靠它一台機器扛住所有請求。
兩個根本問題：1. 物理上限：再強的單台機器也有 CPU 核心數上限，同一時間能處理的請求數有限，10,000 RPS 每次耗時 1 秒，代表需要同時持有 10,000 個請求，超過任何現有單機的能力；2. 單點故障：一台機器壞了，整個服務就掛了，完全違背「高可用性」的要求。題目明確說「高可用性」，垂直擴展天然不符合。
對雲端架構不熟悉、直覺認為「機器規格越強越好」的考生。傳統思維是「一台伺服器扛住一切」，但現代大流量服務的標準答案幾乎都是水平擴展。記住：垂直擴展有天花板，且高可用性只能靠多台機器達成。
C限制最大併發連線數，以避免系統過載
設定一個最大連線數限制，例如最多同時處理 1,000 個請求，超過的直接拒絕或排隊等待。
這不是解決問題，是迴避問題。限流（Rate Limiting）確實是保護系統的手段，但前提是「系統容量本來就不夠，需要保護」。題目問的是「如何讓系統支援 10,000 RPS」，限制連線數只是讓 9,000 個請求被拒絕，業務損失極大。正確做法是擴展容量，而不是縮減服務量。
知道「限流是防護機制」的考生，誤以為這是「穩定應付峰值」的正確做法。限流是最後的熔斷手段，不是主動架構設計策略。一個能支援 10,000 RPS 的健康系統，不需要靠限流保護自己。
D增加批次處理大小，一次同時處理上千筆請求
不一個一個處理，而是等 1,000 個請求都進來了，一起打包送進模型處理，利用 GPU 的並行能力提升吞吐量。
批次處理（Batch Processing）對吞吐量有幫助，但對延遲是傷害。題目說每次推論「需約 1 秒完成」，批次大小 1,000 意味著第 1 個請求要等 999 個後來者都進來才開始跑，等待時間可能長達好幾秒，嚴重違反即時 API 服務的延遲要求。批次處理適合離線任務，不適合即時線上推論服務。
知道「GPU 批次推論效率高」、也知道「大 batch size 能提升 throughput」的考生，在吞吐量優化和延遲要求之間判斷失誤。記住：即時 API 服務的核心約束是延遲（Latency），不是純粹的吞吐量（Throughput）。兩者有時相互衝突，批次處理犧牲了延遲換取吞吐量，對即時服務不合適。
同個考點下次怎麼變形
如果 AI 模型每次推論需要 30 秒，Auto Scaling 還有辦法應對 10,000 RPS 嗎？
30 秒一次推論，需要同時持有 300,000 個請求，容器數量要求更驚人？
數學上可行但成本極高，而且 Auto Scaling 的擴展速度可能追不上流量峰值（容器啟動需要幾秒到幾十秒）。實務解法是：把 30 秒的推論改成非同步架構，請求進來後立刻回傳一個 job_id，讓用戶去輪詢或 webhook 接收結果，這樣 API 層不需要持有連線 30 秒，大幅降低同時持有的請求數。
什麼情況下，垂直擴展反而比水平擴展更合適？
水平擴展不是幾乎都更好嗎？
有幾個情況垂直擴展更合適：1. 應用程式本身難以拆分（例如需要共享大型記憶體狀態的任務）；2. 資料庫層：讀寫資料庫很難水平擴展，主要依靠更大的記憶體和更快的 SSD；3. 流量本來就不大，水平擴展的複雜性不值得；4. 某些深度學習推論需要單一 GPU 存放完整模型，無法切分。垂直擴展的天花板是真實存在的，但在規模較小時是合理選擇。
AI 推論服務的 Auto Scaling 要監控什麼指標？CPU 夠用嗎？
一般服務用 CPU 使用率觸發擴縮，AI 推論服務也一樣嗎？
CPU 使用率不夠，AI 推論服務需要更細緻的指標：1. 如果推論是 GPU-bound，要監控 GPU 使用率（DCGM、NVML 指標）；2. 請求隊列長度（Queue Length）比 CPU 更能即時反映負載；3. P99 延遲（第 99 百分位的回應時間），延遲升高時觸發擴展比等 CPU 到 100% 更及時；4. 模型載入時間：GPU 容器啟動要把模型載入記憶體，可能需要 30-60 秒，要預留餘量提前擴展而不是等到滿載才擴。
電商的「雙 11 瞬間流量」跟這題場景一樣嗎？怎麼處理？
雙 11 的瞬間流量更極端，架構應該更複雜？
類似但有幾個額外挑戰：1. 瞬間峰值：流量在幾秒內從 100 RPS 暴增到 500,000 RPS，Auto Scaling 反應速度不夠，通常要提前手動「預熱」（Pre-warming）；2. 混合流量：用戶同時在做瀏覽、搜尋、下單、支付，不同服務的負載特性不同；3. 資料庫熱點：秒殺商品的庫存表被幾十萬人同時讀寫，需要專門的庫存架構（Redis 快取 + 非同步扣減）。所以電商的大促架構比這題複雜得多，但容器化 + 水平擴展的核心原則是一樣的。
導入 Auto Scaling 後，怎麼評估它運作得好不好？
系統沒有掛掉就算好了嗎？
有幾個關鍵指標：1. P99 延遲：在各種負載下都維持在 SLA 要求內（例如 2 秒），這是服務品質的黃金指標；2. 可用性（Availability）：99.9%（三個 9）意味著每個月最多停機 43 分鐘；3. 資源使用率：Auto Scaling 期間的平均 CPU/GPU 使用率是否在 60-80% 的合理區間（太低浪費錢，太高容易超載）；4. Scale-out Time：從觸發擴展到新容器能接受請求的時間，越短越好；5. 成本效益：相比固定機器數量，Auto Scaling 每月省了多少費用。
想再往下看，這 5 個
- 自動擴展（Auto Scaling）根據 CPU 使用率、請求量等指標自動增減服務實例數，是本題正解架構的核心機制。
- 容器化技術（Containerization）用 Docker 把推論服務打包成可快速複製的容器，啟動只需幾秒，是水平擴展的基礎。
- AI負載平衡（Load Balancing for AI）把進來的推論請求平均分配給多個健康容器，避免單一實例過載，常與 Auto Scaling 搭配。
- 模型服務化（Model Serving）把訓練好的模型封裝成可被呼叫的線上 API，需要考量延遲、吞吐量和可用性，是本題情境的核心工程問題。
- 模型部署（Model Deployment）將訓練完成的模型上線到生產環境的完整流程，容器化 + 水平擴展是當前主流部署策略。