AI 原生开放教材

外观

AI 工程从零到一（中文）源码研读·中文原文 ↗原件 ↓仓库 ↗

Serverless LLM 的冷启动缓解 ​

一个 20 GB 的模型镜像从冷到能服务要花 5-10 分钟（7B）到 20+ 分钟（70B）。在一个真正的 serverless 世界里，那不是预热 —— 那是一次宕机。缓解手段在五层运作：预播种节点镜像（AWS 上的 Bottlerocket、双卷架构）、模型流式加载（NVIDIA Run:ai Model Streamer，vLLM 里原生）、GPU 内存快照（Modal checkpoint，重启最多快 10 倍）、warm pool（min_workers=1）、分层加载（ServerlessLLM 的 NVMe→DRAM→HBM 流水线，延迟降 10-200 倍），以及搬运输入 token（KB 级）而非 KV cache（GB 级）的 live migration。Modal 公布 2-4 秒冷启动作为下限；Baseten 默认 5-10 秒，预热后亚秒级。这一课教你测量、预算并叠加这五层。

类型： Learn 语言： Python（标准库，一个玩具级冷启动路径模拟器） 前置要求： 阶段 17 · 02（推理平台经济学）、阶段 17 · 03（GPU 自动扩缩） 预计时间： ~60 分钟

学习目标 ​

  • 列举冷启动缓解的五层，并为每层说出一个工具或模式。
  • 把一个 70B 模型的总冷启动时间算成 (节点供给) + (权重下载) + (权重加载进 HBM) + (引擎初始化) 之和。
  • 解释为什么 live migration 搬运的是输入 token（KB）而不是 KV cache（GB），以及代价是什么（重算）。
  • 说出 warm pool 的权衡（为闲置 GPU 付费 vs 接受冷启动尾部），以及 min_workers > 0 变成强制项的 SLA 门槛。

问题背景 ​

你的 serverless LLM 端点夜里缩到零。早上 8 点流量飙升。第一个请求要等以下这些：

  1. Karpenter 供给一个 GPU 节点：45-60 秒。
  2. 容器拉取一个 30 GB 带权重的镜像：120-300 秒。
  3. 引擎把权重加载进 HBM：取决于模型规模和存储速度，45-120 秒。
  4. vLLM 或 TRT-LLM 初始化 CUDA graph、KV cache 池、分词器：10-30 秒。

合计：220-510 秒（大致 3-8 分钟）才回来一个 token。你的 SLA 是 2 秒。你上了一个 warm pool（min_workers=1），问题看起来消失了 —— 但现在你 7×24 为一块闲置 GPU 付费。如果你的服务有 5 个产品、各一个 warm 副本，那就是 5 × 24 × 30 = 3,600 GPU 小时/月，无论有没有一个用户调用过。

冷启动缓解就是在保住 serverless 经济性的同时，逼近常开的延迟。

核心概念 ​

第 1 层 —— 预播种节点镜像（Bottlerocket） ​

在 AWS 上，Bottlerocket 的双卷架构把操作系统和数据分开。给数据卷做快照、把容器镜像预拉好；在你的 EC2NodeClass 里引用快照 ID。新节点开机时权重已经在本地 NVMe 上 —— 第 2 步和第 3 步的一部分消失了。原生配合 Karpenter。典型节省：大模型每次冷启动 2-4 分钟。

GCP 上的对应物：预烘焙容器层的自定义 VM 镜像。Azure 上：用同样模式的托管磁盘快照。

第 2 层 —— 模型流式加载（Run:ai Model Streamer） ​

不在回答第一个请求前加载完整文件，而是把权重逐层流进 GPU 内存，第一个 transformer block 一常驻就开始处理。NVIDIA Run:ai Model Streamer 在 vLLM 2026 里原生发布。配合 S3、GCS 和本地 NVMe。通过把 I/O 与计算设置重叠，把大模型的权重加载时间大致砍半。

第 3 层 —— GPU 内存快照（Modal） ​

Modal 在首次加载后对 GPU 状态（权重、CUDA graph、KV cache 区域）做一个 checkpoint。后续重启直接反序列化进 HBM —— 比重新初始化快 10 倍。这是最接近"2 秒启动一块热 GPU"的东西。权衡：快照是按 GPU 拓扑的，所以如果 Karpenter 把你迁到另一个 SKU，你得重做 checkpoint。

第 4 层 —— warm pool（min_workers=1） ​

最简单的缓解：永远留一个副本就绪。成本是一块 GPU 7×24 的小时费率。对小模型这笔账很残酷（你付 $0.85-$1.50/小时来避免 30 秒冷启动），对大模型很友好（付 $4/小时来避免 5 分钟冷启动）。warm pool 变强制的 SLA 门槛：通常是 70B+ 模型上 TTFT P99 < 60 秒。

第 5 层 —— 分层加载（ServerlessLLM） ​

ServerlessLLM 把存储当成一个层级：NVMe（快但大）、DRAM（中但分层）、HBM（小但即时）。权重预加载到 DRAM；按需加载进 HBM。论文报告冷加载相比朴素的磁盘到 HBM 延迟降 10-200 倍。生产采用尚早，但与 vLLM 的集成已存在。

第 6 层 —— live migration（加分模式） ​

当一个节点变得不可用时（spot 驱逐、节点排空），传统模式是冷启动另一个副本、排空请求队列。Live migration 把输入 token（千字节）搬到一个已加载模型的目标，在目标上重算 KV cache。重算比在网络上传输几 GB 的 KV cache 更便宜。适用于分离式部署。

warm pool 的账 ​

对一个 P99 TTFT SLA 为 2 秒的服务，问题不是"要不要 warm pool"，而是"多少 warm 副本，哪些路径配它"。

  • 高价值交互路径（实时聊天、语音 agent）：min_workers=1-2。
  • 后台批处理路径（夜间分类）：接受缩到零，5-10 分钟冷启动可忍。
  • 高级档：每租户配 min_workers，专属算力。

先测量再优化 ​

一个 70B 模型在全新节点上的冷启动解剖（示意）：

阶段时间缓解
节点供给50sBottlerocket + 预播种镜像、warm pool
镜像拉取180s预播种数据卷（消除）
权重到 HBM75s模型流式加载（砍半）；GPU 快照（消除）
引擎初始化20s持久化 CUDA graph 缓存
第一次 forward3s最小固有延迟
冷启动合计328s
带缓解合计~15s降 22 倍

你该记住的数字 ​

  • Modal 冷启动：2-4 秒（带 GPU 快照）。
  • Baseten 默认冷启动：5-10 秒；预热后亚秒级。
  • 裸 70B 冷启动：3-8 分钟。
  • Run:ai Model Streamer：约 2 倍权重加载提速。
  • ServerlessLLM 分层加载：延迟降 10-200 倍（论文数字）。
figure
cold-start-pipeline

实际使用 ​

code/main.py 对带和不带每种缓解的冷启动路径建模。报告总冷启动时间、warm pool 成本，以及 warm pool 开始划算的盈亏平衡请求速率。

拿去用 ​

这一课产出 outputs/skill-cold-start-planner.md。给定 SLA、模型规模和流量形态，挑出该叠哪些缓解。

练习 ​

  1. 跑 code/main.py。算出那个盈亏平衡请求速率 —— 高于它时，一个 warm 副本比通过在 SLO 上多丢请求来交"冷启动税"更便宜。
  2. 你部署一个 13B 模型，P99 TTFT SLA 为 3 秒。挑出能达成它的最小缓解栈（层数最少）。
  3. Bottlerocket 预播种消除了镜像拉取，但权重仍要从快照加载到 HBM。如果快照支撑的 NVMe 以 7 GB/s 读取，算一个 70B 模型的墙钟时间。
  4. 你的 serverless 供应商提供 GPU 快照（Modal），你的团队拒绝，理由是"快照会泄露 PII"。两边都论证一下 —— 现实风险是什么，缓解是什么（临时快照、加密、命名空间隔离）？
  5. 设计一个分层 warm pool 策略：付费用户、试用用户、批处理工作负载各配多少 warm 副本？给出算账。

关键术语 ​

术语大家嘴上怎么说它实际是什么
冷启动"那个大停顿"在一个全新副本上从请求到首 token 的时间
Warm pool"常开下限"min_workers >= 1，至少留一个副本就绪
预播种镜像"烘焙好的 AMI"容器权重已常驻的节点镜像
Bottlerocket"AWS 节点 OS"AWS 容器优化操作系统，支持双卷快照
模型流式加载"流式加载"把权重 I/O 与计算设置重叠
GPU 快照"checkpoint 到 HBM"序列化加载后的 GPU 状态；重启时反序列化
分层加载"NVMe + DRAM + HBM"存储层级；按需加载
Live migration"搬运 token"传输输入（KB），在目标上重算 KV
min_workers"warm 副本"serverless 最小保活数
缩到零"完全 serverless"闲置时无成本；接受全额冷启动税

延伸阅读 ​