第 13 章 — 自動擴縮與冷啟動緩解

發佈於: 2026-05-05 最後更新於: 2026-07-08 版本: 1
第 13 章 — 自動擴縮與冷啟動緩解

第 13 章 — 自動擴縮與冷啟動緩解

LLM Primer VI:擴展 AI 系統》章節走讀的第十三篇。這一章解釋為什麼預設的 Kubernetes 自動擴縮器在 LLM 流量下會製造中斷,以及 KEDA、Knative、CRIU 如何組合成修補方案。


這一章為什麼存在

一個聊天助理一天內尖峰對比谷底能差 30 倍。一個開發者工具週末歸零。一個消費性產品追著一波從太平洋到歐洲的浪跑。以尖峰配置在谷底是浪費錢;以谷底配置在尖峰是丟請求。自動擴縮讓部署跟流量走在一起;冷啟動緩解則讓自動擴縮 — 尤其是 scale-to-zero — 快到使用者感覺不到。第 13 章解釋為什麼標準的 Kubernetes HPA 是 LLM 錯的擴縮器、KEDA 拿什麼訊號來擴縮、Knative 如何表達 scale-to-zero、以及要把 60 到 180 秒的冷啟動壓成個位數秒需要什麼。

一句話總結:以使用者感受到的東西擴縮 — 佇列深度、第一個 token 時間、KV 佔用 — 而不是以 GPU 驅動程式回報的東西擴縮,並且把擴縮器搭配基於 CRIU 的暖回復,讓新副本在尖峰結束之前就到位。

13.1 HPA 在 LLM 流量下用四種特定方式失敗

預設 HPA 以 CPU 或 GPU 利用率擴縮。它在 LLM 上有四種失敗方式。第一,GPU 利用率是錯的訊號 — nvidia-smi 回報的是某個 kernel 正在跑的時間比例,不是批次有沒有塞好、或請求有沒有在前進。一個 95% 利用的伺服器,若後面排著八個長 prefill 加一個 decode,那是過載;一個 60% 利用的伺服器,若跑著健康的連續批次,那是好的。第二,LLM 請求的持續時間(數秒到幾十秒)跟 HPA 控制迴圈(15 秒)相比是長的,所以擴縮會晚整整一個請求的生命週期。第三,容量的單位不是 pod;解耦部署以 clique 為單位擴縮,而 HPA 不懂 clique。第四,冷啟動:新 pod 60 到 180 秒後才上線,遠晚於觸發它的那個尖峰不是壓垮了機群、就是自己以逾時退場了。典型的失敗模式是在流量翻倍時中斷兩分鐘,接著出現一次縮容,讓部署對下一個尖峰配置不足。

13.2 KEDA 以佇列深度、TTFT、KV 佔用來擴縮

KEDA 用 ScaledObject CRD 擴充 HPA,把一個目標工作量跟一或多個把外部指標轉成目標副本數的擴縮器綁在一起。三個訊號對 LLM 服務很重要。佇列深度最直接:引擎的等待請求數是「到達的工作」超過「服務容量」的部分;vLLM 以 vllm:num_requests_waiting 對外提供。第一個 token 的時間 — 特別是滑動視窗上的 p95 或 p99 — 捕捉使用者可見的品質下滑,並抓住佇列深度會漏掉的不對稱過載(prefill 飽和但 decode 好、或反過來)。KV 快取佔用是前瞻的;當佔用越過 80% 時,新副本應該在既有副本開始搶佔或拒絕請求之前上線。一個生產級的 ScaledObject 通常把這三者組起來,以最積極的為勝。Knative Serving 在上面加一層做 scale-to-zero:低於一個小的啟用門檻時,所有 pod 都被移除;新進來的請求會被一個 activator 保留,由它按需啟動一個 pod — 這只在冷啟動夠快時才划算。

13.3 CRIU 把 90 秒的冷啟動壓到 3 到 6 秒

一個 70B 的冷啟動可以分解成:映像檔拉取(10 到 60 秒)、Python 初始化(2 到 5 秒)、權重載入(60 到 120 秒)、CUDA 上下文初始化(5 到 15 秒)、CUDA graph 捕捉(10 到 30 秒)、KV 暖機(2 到 10 秒),合計 90 到 250 秒。CRIU(Checkpoint/Restore In Userspace)把一個完全暖起來的行程 — 權重載入、CUDA 上下文起來、graph 捕捉完、KV 池配置好、健康檢查過 — 快照下來,以後從磁碟幾秒內就能回復。NVIDIA 的 cuda-checkpoint 工具(2024)把 CRIU 擴充到能處理 GPU 狀態:裝置記憶體池、CUDA 上下文、被快取的 PTX、被捕捉的 graph。一份熱好的 vLLM 快照從本地 NVMe 3 到 6 秒就能回復。一份 DaemonSet 把 checkpoint 預備在每個節點的 NVMe 上,讓 Knative 從本地檔案回復、而不是從網路抓。搭配映像檔串流(下載還沒完就開始拉)與惰性權重載入,5 秒以內的冷啟動在生產環境是做得到的 — 這個數字底下,scale-to-zero 對使用者取向應用而言就在經濟上站得住腳。

值得記住:Scale-to-zero 是在谷底不付錢的代價,冷啟動則是 scale-to-zero 的代價。你在冷啟動上刮下的每一秒,都會把「始終溫熱」與「有時冷卻」的損益兩平點往運維者這一側推。

第 13 章鋪陳出來的東西

第 1 到 13 章走過了 LLM 服務的實體堆疊 — 硬體、引擎、平台、解耦、擴縮。這本書的其餘部分轉到錢。第 14 章解釋為什麼 token 是計費單位、為什麼輸出定價是輸入的兩到五倍、以及看不見的 reasoning tokens 如何跑到帳單上。第 15 章走自架與 API 提供商之間的損益兩平算術,加上大多數團隊低估的那條平台工程項目。第 16 章是那些會複利累積的降本動作目錄。


下一篇 — 第 14 章:Token 經濟學與 API 定價為什麼帳單長那樣,以及沒人在看的時候計費表是怎麼跳的。

想看完整的全貌?書中章節包含 LLM 三訊號擴縮器的 KEDA ScaledObject YAML、scale-to-zero 的 Knative Revision manifest、完整的冷啟動剖析、CRIU 預備 DaemonSet,以及自動擴縮部署走過一天日夜流量曲線的「day in the life」追蹤。在 Amazon 查看 LLM Primer VI →

下田 昌平
下田 昌平
RECEIPTROLLER 的 CTO 與創辦人。專注於數據、驅動創新、始終保持好奇心。