同一个推理服务，第一个请求要等十几秒甚至更久，后续请求却只要几十毫秒——这种「第一次特别慢」的现象，几乎每个做大模型部署的人都踩过。

这就是大模型服务的冷启动。它和缓存是两件事：缓存管「重复请求怎么省钱」，冷启动和预热管「第一次请求怎么快起来」。

这篇文章就用大白话，把「大模型服务冷启动和预热」讲清楚：冷启动为什么慢、慢在哪几环、预热有哪些手段，以及弹性伸缩场景下它为什么是核心矛盾。

一、一句话定义

大模型服务冷启动，是指推理服务从「进程启动 / 实例就绪」到「真正能高效响应请求」的升温过程；预热（Warmup），则是提前把升温期要做的事做完，让首个请求不再背锅。

关键区别在于：服务「起来了」≠「能用了」。一个容器可能健康检查都通过了，但第一个推理请求照样卡上十几秒——因为真正影响首请求延迟的那些「热场」工作，还没发生。

二、冷启动慢在哪：把「启动」拆成五步

从进程启动到能快速出 Token，中间隔着五件事，每一件都在拖时间：

阶段	在做什么	为什么慢
模型权重加载	把几十 GB 到上百 GB 的权重，从磁盘 / 对象存储读进 GPU 显存	数据量最大，是冷启动的最大头
CUDA 上下文初始化	建立 GPU 计算上下文	涉及驱动与显存初始化，一次性开销
算子编译	JIT 编译推理算子，CUDA Graph 固化关键路径	首次才做，编译本身耗时
KV Cache 预分配	为注意力机制按 max_model_len 预留显存	一次性大块分配
预热推理	跑一次或几次前向，激活所有组件	不跑一次，首个请求就会「卡」

这五步加起来，通常是 5~20 秒量级；在容器化、Serverless 场景下，再叠加镜像拉取与调度，冷启动很容易到分钟级。

所以「冷启动」不是一个点，而是一条链：权重加载是最大头，但它只是起点，后面每一步没走完，首个请求都会慢。

三、先分清：冷启动、预热、缓存是三件事

这三个词经常被混在一起，其实是三个不同的东西：

• 冷启动：是「问题」——服务处于冷态时，首个请求延迟飙高
• 预热（Warmup）：是「解法」——提前把启动步骤做完，让首请求正常
• 缓存：是另一条线——复用「已经算过的结果」，管的是省钱

比如预热时注入的典型前缀，既是让首请求不卡，也可能顺便把前缀缓存建好——但这是两笔账，别混。

四、延迟都花在哪了：一张分解表

以 vLLM 这类主流推理框架为例（量级综合 NVIDIA、vLLM 与行业实测，作为参考）：

环节	耗时量级	说明
权重加载	秒 ~ 分钟	与模型大小强相关，7B 约十几 GB，数百 B 上百 GB
CUDA 上下文初始化	秒级	一次性，与硬件驱动相关
算子编译 / CUDA Graph	秒级	首次编译，产物可缓存复用
KV Cache 预分配	秒级	按上下文长度预留显存
未预热的首个请求 TTFT	1000ms+	P99 可能上千 ms，对比预热后几十 ms

这里的核心指标是 TTFT（首 Token 延迟）：用户对「反应速度」的第一印象就来自它。未预热的服务，TTFT 可能从几十毫秒飙到数秒，这就是用户体感上的「卡」。另一个指标 TPOT（单 Token 生成耗时）决定「打字是否流畅」，它受冷启动影响较小，主要在解码阶段体现。

五、预热怎么做：五种常用手段

冷启动的问题拆清楚了，预热就是对症下药。业内常用的有五板斧：

手段	在做什么	适用场景
模型预加载	把 load_model 与服务启动解耦，进程起来就同步加载权重	通用，必做
Warmup 请求	用典型对话 / 业务请求「空跑」一次，激活 JIT、填充 KV Cache、固化 CUDA Graph	通用，必做
CUDA Graph 固化	把关键计算路径提前固化成图，跳过动态图构建	延迟敏感场景
快照 / 热迁移	把已预热实例的内存状态做成快照，新实例直接恢复	弹性扩容、Serverless
权重缓存加速 + 预测性弹性	用缓存加速权重分发（如 Fluid），配合流量预测提前扩容（如 AHPA）	K8s 大规模弹性

这五条不是互斥的，生产环境往往「组合拳」：启动即预加载 → 自动跑 warmup 请求 → 关键路径固化成图 → 扩容时用快照热迁移 → 必要时预测性提前扩容。

六、为什么弹性伸缩里冷启动是核心矛盾

弹性扩容的初衷是「流量来了加机器」，但冷启动让新加的机器「几分钟内都是摆设」——等它加载完权重、跑完预热，流量高峰可能已经过去了。

这就逼出了两条路线：

• Scale-to-zero（闲时缩到零）：能省最多成本，但每次唤起都要付冷启动的代价，实时性场景受不了
• 快照热迁移 + 预测性扩容：把冷启动压到秒级，才敢把弹性做得更激进

七、工程实践：把预热做对的四条原则

预热不是「跑一次就行」，做不对等于白热。四条经验：

1. 启动即预热：服务一起来就自动跑 warmup，别等第一个真实用户来「踩雷」
2. 用真实流量形态预热：预热请求要接近真实 prompt 长度、batch 大小、采样参数，否则关键路径没覆盖到，首请求照样慢
3. 分「热 / 温 / 冷」模型：多模型部署时，热模型常驻预热，温模型后台异步预热，冷模型懒加载
4. 复用中间状态：跨实例共享权重缓存与编译产物，减少重复加载与重复编译

八、写在最后

把全文收成三句话：

1. 冷启动是推理服务从「就绪」到「高效」的升温过程，最大的一头是模型权重加载
2. 预热是解法——模型预加载、Warmup 请求、CUDA Graph 固化、快照热迁移、预测性弹性，五板斧把冷启动从分钟级压到秒级
3. 冷启动时长决定弹性策略——想省成本做 Scale-to-zero，就得先把冷启动做快

也就是说，首请求快不快，看的是预热做没做对。同样的模型、同样的机器，预不预热，TTFT 能差出几十倍。

附：开发者怎么把「首请求体验」和「成本」一起拿住

预热解决的是「快」，成本解决的是「省」。对于直接调 API 的开发者，这两件事更多交给了服务端：

• 成熟云平台（火山方舟等）在实例层做了权重预加载与缓存预热机制，把冷启动的影响尽量挡在用户感知之外
• 通过向量云（向量云南京科技有限公司）获取字节跳动火山方舟官方 API 与官方 Key，可拿到低折扣 Token、按量计费、即用即扣、不设账期，注册充值 10 元起，让首请求的「快」建立在更低的单价上