每秒萬次推論請求，什麼架構撐得住？
原題
某 AI 服務系統每次推論請求需約 1 秒完成，且必須支援高達 10,000 次請求每秒（RPS）的流量。為確保系統具備高可用性且能穩定應付流量峰值，下列哪一種架構方案最為合適？
白話
一個 AI 推論服務，每次請求要花 1 秒處理，而且尖峰時刻每秒有 10,000 個請求進來（10,000 RPS）。
問你：什麼架構方案最能同時確保高可用性（不容易掛掉）且能應付流量峰值？
先自己選一個答案，再看完整解析。
一句話總結
每秒 1 萬個推論請求，每次要 1 秒，最好的架構是：容器化部署 + 水平擴展多個服務實例 + Auto Scaling（自動彈性伸縮），可以根據流量動態增減機器，流量大就自動加機器，流量小就縮回去省錢，且不會有單點故障。
情境
先感受問題：10,000 RPS 是什麼規模
假設「星雲 AI 公司」提供一個圖片辨識 API，每張圖片辨識要花 1 秒。
先算一下規模：
每秒 10,000 個請求進來
每個請求要花 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）：同時跑多個容器實例：
容器 1：處理請求 #1~100
容器 2：處理請求 #101~200
容器 3：處理請求 #201~300
... 依此類推，直到塞滿 10,000 RPS
Auto Scaling（自動彈性伸縮）：系統監控 CPU 使用率和請求隊列長度，自動決定要開幾個容器：
凌晨 3 點：流量 50 RPS → 自動縮到 5 個容器
中午 12 點：流量 8,000 RPS → 自動擴到 85 個容器
下班後：流量回落 → 自動縮回
任何一個容器掛掉，其他容器繼續服務，Kubernetes 或 ECS 自動補一個新的上來，做到高可用性。
這就是選項 B 講的：採用容器化部署並水平擴展服務實例，結合自動彈性伸縮機制（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% 就擴Step 1 純故事版
- AI 推論服務打包成 Docker 容器（像便當盒，可以複製）
- Kubernetes 負責管理這些容器：排程到哪台機器、確保數量、自動重啟掛掉的
- HPA 監控 CPU 使用率：用超過 70% 就多開幾個容器，低於 30% 就縮回去
- Load Balancer（負載平衡器）把進來的請求平均分給所有健康的容器
Step 2 中文 ↔ 程式碼對照
| 故事 | 設定 |
|---|---|
| 一開始開 10 個容器 | replicas: 10 |
| 最少維持 5 個（不能縮太少） | minReplicas: 5 |
| 最多擴到 200 個 | maxReplicas: 200 |
| CPU 用超過 70% 就擴 | averageUtilization: 70 |
Step 3 符號角色表
- RPS（Requests Per Second）：每秒請求數。10,000 RPS 代表每秒有一萬個用戶送請求進來，是衡量系統負載的核心指標。
- Horizontal Scaling（水平擴展）：加更多台機器（或容器）分擔工作。相對於 Vertical Scaling（垂直擴展，把一台機器加強）。水平擴展的上限是機器數量，理論上可以無限擴展。
- Container / Docker：把應用程式和它所需的環境打包在一起的技術。容器比虛擬機輕量、啟動快，是現代雲端服務的標準部署方式。
- Auto Scaling / HPA：根據指標（CPU、記憶體、請求隊列長度）自動增減容器數量的機制。讓系統能彈性應對流量波動，不用人工介入。
Step 4 完整公式對應
計算需要幾個容器的基本公式：
# 若每個容器每秒能處理 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 個容器
這就是為什麼需要大量容器水平擴展，單台機器完全不可能撐住。
Step 5 自我複述
蓋住設定檔，說出 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）。兩者有時相互衝突，批次處理犧牲了延遲換取吞吐量，對即時服務不合適。
變形題
同個考點下次怎麼變形
30 秒一次推論，需要同時持有 300,000 個請求，容器數量要求更驚人？
答案
數學上可行但成本極高，而且 Auto Scaling 的擴展速度可能追不上流量峰值（容器啟動需要幾秒到幾十秒）。實務解法是：把 30 秒的推論改成非同步架構，請求進來後立刻回傳一個 job_id，讓用戶去輪詢或 webhook 接收結果，這樣 API 層不需要持有連線 30 秒，大幅降低同時持有的請求數。
水平擴展不是幾乎都更好嗎？
答案
有幾個情況垂直擴展更合適：1. 應用程式本身難以拆分（例如需要共享大型記憶體狀態的任務）；2. 資料庫層：讀寫資料庫很難水平擴展，主要依靠更大的記憶體和更快的 SSD；3. 流量本來就不大，水平擴展的複雜性不值得；4. 某些深度學習推論需要單一 GPU 存放完整模型，無法切分。垂直擴展的天花板是真實存在的，但在規模較小時是合理選擇。
一般服務用 CPU 使用率觸發擴縮，AI 推論服務也一樣嗎？
答案
CPU 使用率不夠，AI 推論服務需要更細緻的指標：1. 如果推論是 GPU-bound，要監控 GPU 使用率（DCGM、NVML 指標）；2. 請求隊列長度（Queue Length）比 CPU 更能即時反映負載；3. P99 延遲（第 99 百分位的回應時間），延遲升高時觸發擴展比等 CPU 到 100% 更及時；4. 模型載入時間：GPU 容器啟動要把模型載入記憶體，可能需要 30-60 秒，要預留餘量提前擴展而不是等到滿載才擴。
雙 11 的瞬間流量更極端，架構應該更複雜？
答案
類似但有幾個額外挑戰：1. 瞬間峰值：流量在幾秒內從 100 RPS 暴增到 500,000 RPS，Auto Scaling 反應速度不夠，通常要提前手動「預熱」（Pre-warming）；2. 混合流量：用戶同時在做瀏覽、搜尋、下單、支付，不同服務的負載特性不同；3. 資料庫熱點：秒殺商品的庫存表被幾十萬人同時讀寫，需要專門的庫存架構（Redis 快取 + 非同步扣減）。所以電商的大促架構比這題複雜得多，但容器化 + 水平擴展的核心原則是一樣的。
系統沒有掛掉就算好了嗎？
答案
有幾個關鍵指標：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）
將訓練完成的模型上線到生產環境的完整流程，容器化 + 水平擴展是當前主流部署策略。