Serverless LLM 的冷启动缓解

Serverless LLM 的冷启动缓解

本节摘要:一个 20 GB 的模型镜像从冷到可服务,要花 510 分钟(7B)到 20 分钟以上(70B)。在真正的 serverless 世界里,这不算预热——这是故障。缓解手段分五层运作:预置节点镜像(AWS 上的 Bottlerocket、双卷架构)、模型流式加载(NVIDIA Run:ai Model Streamer,vLLM 2026 原生支持)、GPU 内存快照(Modal checkpoints,重启快至 10 倍)、暖池(min_workers=1)、分层加载(ServerlessLLM 的 NVMe→DRAM→HBM 流水线,延迟降 10200 倍),外加一条把输入 token(KB)而非 KV 缓存(GB)搬走的实时迁移。Modal 公开 24 秒冷启动为下限;Baseten 默认 510 秒,预热后亚秒级。本节教你怎么测、怎么预算、怎么把这五层叠起来。

对应原课程:Phase 17 · Lesson 10 · 10-cold-start-mitigation(原英文 phases/17-infrastructure-and-production/10-cold-start-mitigation/docs/en.md)。

学习目标

阅读完本节,你应当能够:

1. 列出冷启动缓解的五层,并说出每层一个工具或模式。
2. 把 70B 模型的总冷启动时间算成(节点供给)+(权重下载)+(权重载入 HBM)+(引擎初始化)之和。
3. 解释为什么实时迁移传的是输入 token(KB)而非 KV 缓存(GB),代价是什么(重计算)。
4. 说出暖池权衡(付空闲 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 缓存池、分词器:10~30 秒。

合计:220510 秒(约 38 分钟)才返回一个 token。你的 SLA 是 2 秒。你上个暖池(min_workers=1),问题好像消失了——但现在你 24×7 为一块闲置 GPU 付钱。如果你的服务有 5 个产品各一个暖副本,那就是 5 × 24 × 30 = 每月 3600 GPU 小时,无论有没有用户调过。

冷启动缓解,就是在保住 serverless 经济性的同时,逼近常驻服务的延迟。

二、核心概念

第一层 —— 预置节点镜像(Bottlerocket)

在 AWS 上,Bottlerocket 的双卷架构把 OS 与数据分开。把你的容器镜像(已预拉)打进数据卷快照,在 EC2NodeClass 里引用快照 ID。新节点开机时,权重已在本地 NVMe 上——步骤 2 与步骤 3 的一部分消失。与 Karpenter 原生配合。典型节省:大模型每次冷启动省 2~4 分钟。

GCP 等价:自定义 VM 镜像预烘容器层。Azure:托管磁盘快照,同模式。

第二层 —— 模型流式加载(Run:ai Model Streamer)

不等整个文件加载完才应答第一个请求,而是按层把权重流式灌进 GPU 内存,第一个 transformer block 一进 HBM 就开始处理。NVIDIA Run:ai Model Streamer 在 2026 年 vLLM 原生集成,支持 S3、GCS、本地 NVMe。把权重加载时间大致砍半——靠 I/O 与计算初始化重叠。

第三层 —— GPU 内存快照(Modal)

Modal 在首次加载后对 GPU 状态(权重、CUDA graph、KV 缓存区)打检查点。后续重启直接反序列化进 HBM——比重初始化快 10 倍。这是最接近「2 秒启动一块暖 GPU」的东西。权衡:快照按 GPU 拓扑绑定,若 Karpenter 把你迁到不同 SKU,要重打检查点。

第四层 —— 暖池(min_workers=1)

最简单的缓解:始终保一个副本就绪。成本是一块 GPU 的小时费 24×7。算术对小模型残酷(付 0.85~1.50 美元/小时去避免 30 秒冷启动),对大模型友好(付 4 美元/小时避免 5 分钟冷启动)。暖池变强制的 SLA 阈值:典型是 70B+ 模型 TTFT P99 < 60 秒。

第五层 —— 分层加载(ServerlessLLM)

ServerlessLLM 把存储当成层次结构:NVMe(快但大)、DRAM(中、可分层)、HBM(小但瞬时)。权重预载到 DRAM,按需载入 HBM。论文报告,相对朴素的盘到 HBM,冷加载延迟降 10~200 倍。生产采用尚早,但已有与 vLLM 的集成。

第六层 —— 实时迁移(加赠模式)

当一个节点不可用(spot 回收、节点排空),传统模式是冷启另一个副本并排干请求队列。实时迁移把**输入 token(几千字节)**搬到一个已加载模型的目的地,在目的地上重算 KV 缓存。重算比在网上传 GB 级 KV 缓存便宜。适用于分离式部署。

暖池算术

对一个 P99 TTFT SLA 2 秒的服务,问题不是「要不要暖池」,而是「几个暖副本,哪些路径配」。

• 高价值交互路径(实时聊天、语音 Agent):min_workers=1~2。
• 后台批处理路径(夜间分类):可接受缩到零,5~10 分钟冷启动可忍。
• 高级层:按租户配 min_workers,专属容量。

先测再优化

70B 模型在全新节点上的冷启动解剖(示意):

你该记住的数字

• Modal 冷启动:2~4 秒(配 GPU 快照)。
• Baseten 默认冷启动:5~10 秒;预热后亚秒。
• 裸 70B 冷启动:3~8 分钟。
• Run:ai Model Streamer:约 2 倍权重加载提速。
• ServerlessLLM 分层加载:10~200 倍延迟下降(论文数字)。

三、从零实现:冷启动路径模拟器

原课程 code/main.py 建模带/不带每种缓解的冷启动路径,报告总冷启动时间、暖池成本、以及「暖副本比付冷启动税更划算」的盈亏请求数。下面给最小可读的预算骨架。

def cold_start_total(node_s, image_pull_s, weights_to_hbm_s, engine_init_s,
                     mitigations=None):
    """叠加各缓解后的冷启动墙钟。

    mitigations: 集合,可含 'preseed'(消除镜像拉取 + 砍节点供给)
                              'stream'(权重加载砍半)
                              'snapshot'(消除权重加载 + 砍引擎初始化)
    """
    m = mitigations or set()
    n = node_s * (0.5 if "preseed" in m else 1.0)
    p = 0 if "preseed" in m else image_pull_s
    w = 0 if "snapshot" in m else (weights_to_hbm_s * (0.5 if "stream" in m else 1.0))
    i = engine_init_s * (0.3 if "snapshot" in m else 1.0)
    return round(n + p + w + i, 1)


def warm_pool_break_even(gpu_hour_cost, cold_start_seconds, sla_ttf_t_seconds,
                         dropped_request_value):
    """估算暖副本『划算』的最低请求数。

    参数:
      gpu_hour_cost:          单 GPU 每小时成本(美元)
      cold_start_seconds:     冷启动秒数
      sla_ttf_t_seconds:      SLA 的 TTFT 阈值
      dropped_request_value:  每个超时请求损失(美元)
    返回: 每小时至少 N 个超时请求才抵得过暖池成本
    """
    warm_hourly = gpu_hour_cost
    # 冷启动期间,所有请求都超时;冷启动相当于一次『故障窗口』
    return round(warm_hourly / max(dropped_request_value, 1e-6), 1)


# 案例:70B 模型,节点 50s + 镜像 180s + 权重 75s + 引擎 20s
base = cold_start_total(50, 180, 75, 20)
stacked = cold_start_total(50, 180, 75, 20, {"preseed", "stream", "snapshot"})
print(f"裸冷启动 {base}s → 叠缓解 {stacked}s")
print("暖池盈亏(4 美元/h GPU, 每超时请求损失 0.5 美元):",
      warm_pool_break_even(4, base, 2, 0.5), "次超时/小时")
​

💡 暖池不是「要不要」的二选一,而是「哪条路径要、要几个」。把交互路径配暖副本、批处理路径缩到零,你就把 serverless 经济性与常驻延迟同时拿到了。

四、框架对比:五层缓解横向对照

叠加心法:交互路径 = 暖池 + 预置镜像 + 流式/快照;批处理路径 = 仅预置镜像 + 接受冷启动。两层策略比一刀切更省。

五、可复用产物

本节产出 outputs/skill-cold-start-planner.md(原课程目录)。给定 SLA、模型大小、流量形状,它选出叠哪些缓解:

1. 冷启动预算:四阶段时间分解 + 目标 SLA。
2. 缓解栈:交互/批处理路径各配哪几层。
3. 暖池策略:min_workers 按路径分级,含月度 GPU 小时成本。
4. 实时迁移判定:是否值得为分离式部署引入 token 搬迁。

六、练习

1. 跑通模拟器:运行 code/main.py。算出「暖副本比付冷启动税更划算」的盈亏请求数。

2. 最小栈:你部署一个 13B 模型,P99 TTFT SLA 3 秒。选出达成它的最少缓解层组合。

3. 快照墙钟:Bottlerocket 预置消除了镜像拉取,但权重仍要从快照 NVMe 读进 HBM。70B 模型、NVMe 读 7 GB/s,墙钟多少?

4. 快照与隐私:你的 serverless 供应商提供 GPU 快照(Modal),团队以「快照泄漏 PII」为由拒绝。两边的论证各是什么?现实风险是什么,缓解有哪些(临时快照、加密、命名空间隔离)?

5. 分层暖池:为付费用户、试用用户、批处理工作负载各设计暖副本数,展示算术。

本节要点回顾

1. 裸 70B 冷启动 3~8 分钟:节点供给 + 镜像拉取 + 权重入 HBM + 引擎初始化。
2. 五层缓解:预置镜像、模型流式、GPU 快照、暖池、分层加载,可叠加。
3. 预置镜像(Bottlerocket)消除镜像拉取:数据卷快照预烘容器,省 2~4 分钟。
4. Run:ai Model Streamer 把权重加载砍半:I/O 与计算初始化重叠,vLLM 2026 原生。
5. GPU 快照(Modal)重启快 10 倍:但按 GPU 拓扑绑定,迁 SKU 要重打。
6. 暖池是最简单也最贵:min_workers=1 保路径就绪,24×7 付 GPU 钱,SLA < 60 秒时强制。
7. ServerlessLLM 分层加载降 10~200 倍:NVMe→DRAM→HBM 流水线,生产采用尚早。
8. 实时迁移传 token 不传 KV:输入 KB vs KV 的 GB,代价是目的地上重算 KV。
9. 叠加优于一刀切:交互路径配暖池+预置+快照,批处理路径接受缩到零。

下一节,我们把视角拉到全球——看多区域 LLM 服务如何借助 KV 缓存局部性,让一个对话在区域间迁移时不丢上下文。