第 13 章 — 自动扩缩与冷启动缓解

发布于: 2026-05-05 最后更新于: 2026-07-08 版本: 1
第 13 章 — 自动扩缩与冷启动缓解

第 13 章 — 自动扩缩与冷启动缓解

LLM Primer VI: Scaling AI Systems》章节走读的第十三篇。这一章要说的是:为什么默认 Kubernetes 扩缩器在 LLM 流量下会产出故障,以及 KEDA、Knative、CRIU 怎么合起来把它修好。


这一章为什么存在

chat 助手一天内峰谷 30 倍摇摆。开发者工具周末归零。消费级产品跟着从太平洋到欧洲这道浪走。按峰值配容量在低谷浪费钱,按低谷配在峰值丢请求。自动扩缩让部署跟着流量走;冷启动缓解让扩缩 —— 特别是 scale-to-zero —— 快到用户感觉不到。第 13 章解释为什么标准 Kubernetes HPA 是错的 LLM 扩缩器、KEDA 应该按什么信号扩缩、Knative 怎么表达 scale-to-zero,以及要把 60–180 秒的冷启动压到个位数秒需要什么。

一句话:按用户能感受到的东西扩缩 —— 队列深度、time-to-first-token、KV 占用 —— 不按 GPU 驱动汇报的数字扩缩,再把扩缩器和一份基于 CRIU 的温存恢复配起来,让新副本在这一波尖峰结束前到位。

13.1 HPA 在四个具体地方对 LLM 流量失灵

默认 HPA 按 CPU 或 GPU 利用率扩缩。它对 LLM 失灵在四处。第一,GPU 利用率是错的信号 —— nvidia-smi 报告的是"某个"kernel 在跑的时间比例,不是 batch 排得好不好、请求有没有进展。一台 95% 利用率的服务器,后面排着八条长 prefill、前面一条 decode,那是过载;一台 60% 利用率、有一份健康 continuous batch 的服务器,是没问题。第二,LLM 请求时长(几秒到几十秒)比 HPA 控制循环(15 秒)长得多,扩缩滞后一整个请求生命周期。第三,容量单位不是 pod;拆分部署按 clique 扩缩,HPA 不懂 clique。第四,冷启动:一个新 pod 60–180 秒后才上线,那时候触发它的那波尖峰要么把 fleet 打垮了、要么超时自己散了。典型失灵形态是:流量翻倍时两分钟停摆,接着一次缩容,把部署留在下一波尖峰不够用的水位上。

13.2 KEDA 按队列深度、TTFT、KV 占用扩缩

KEDA 通过一份 ScaledObject CRD 扩展 HPA,把目标 workload 绑到一或多个把外部指标换算成期望副本数的扩缩器。LLM serving 关心三个信号。队列深度最直接:engine 里等待请求数,就是到达工作量对服务能力的盈余;vLLM 以 vllm:num_requests_waiting 的名字暴露它。Time-to-first-token —— 尤其是一段滑动窗口上的 p95 或 p99 —— 抓住用户能感受到的退化,还能抓住队列深度漏掉的非对称过载(prefill 满、decode 好,或者反过来)。KV cache 占用是前瞻的;当占用越过 80% 时,新副本应该在现有那些开始抢占或拒绝请求之前上线。生产的 ScaledObject 通常把三个组合起来,谁最激进谁赢。Knative Serving 叠在上面做 scale-to-zero:低于一个小的激活阈值,所有 pod 被移除;进来的请求由一个 activator 抓住,按需启一个 pod —— 这只有冷启动快的时候才经济。

13.3 CRIU 把 90 秒的冷启动压到 3–6 秒

70B 的冷启动分解成:镜像拉取(10–60 s)、Python 初始化(2–5 s)、权重加载(60–120 s)、CUDA context 初始化(5–15 s)、CUDA graph 捕获(10–30 s)、KV 预热(2–10 s) —— 合计 90–250 s。CRIU(Checkpoint/Restore In Userspace)对一个已完全预热的进程 —— 权重已加载、CUDA context 已起、graph 已捕获、KV 池已分配、健康检查已过 —— 做快照,之后从磁盘几秒钟内恢复。NVIDIA 的 cuda-checkpoint(2024)把 CRIU 扩展到 GPU 状态:显存池、CUDA context、缓存的 PTX、捕获的 graph。一份温存 vLLM 快照从本地 NVMe 恢复 3–6 秒。一个 DaemonSet 把 checkpoint 预置到每一个节点的 NVMe 上,让 Knative 从本地文件恢复,不用走网络拉。加上镜像 streaming(边拉边启)、懒权重加载,5 秒以下的冷启动在生产里是可达到的 —— 这也是让面向用户应用做 scale-to-zero 在经济上说得通的那道数字。

值得记住:Scale-to-zero 是在低谷不花钱的代价,而冷启动就是 scale-to-zero 的代价。你从冷启动里砍掉的每一秒,都在把"总是常温"和"有时冷起"之间的盈亏平衡点往运营者这一侧推。

第 13 章为下面铺了什么

第 1 到 13 章走了 LLM serving 的物理栈 —— 硬件、engine、平台、拆分部署、扩缩。本书剩下的转向钱。第 14 章解释为什么 token 是计费单位、为什么输出比输入贵两到五倍,以及看不见的 reasoning token 是怎么爬上账单的。第 15 章走自建对比 API 供应商之间的那道盈亏平衡算术,以及大多数团队低估的那笔平台工程账。第 16 章是那份会复利叠加的降本目录。


下一章 — 第 14 章:Token 经济学与 API 定价账单为什么长成那个样子,以及没人在看的时候计价表怎么在跑。

想看完整的全貌?书里这一章包括一份三信号 LLM 扩缩器的 KEDA ScaledObject YAML、scale-to-zero 的 Knative Revision 清单、完整的冷启动解剖、CRIU 预置 DaemonSet,以及一份走过日夜流量曲线的自动扩缩部署"一天生活"追踪。在 Amazon 上查看 LLM Primer VI →

下田 昌平
下田 昌平
作为株式会社Receipt Roller的CEO兼CTO,目前负责开发电子收据服务以及自动将对话分类并生成行动任务的系统「ACTIONBRIDGE」。从小便接触编程,1996年参与开发测量仪器的相关程序,始终保持着对技术的深刻探索与热情。 在此前的职业生涯中,曾担任日本最大呼叫中心行业企业的子公司——一家研究开发公司的CEO/CTO,领导了多个技术开发项目。目前,我依然活跃在编程的最前沿,持续书写代码。