LLM服务冷启动优化：预热策略降低延迟

可视化演示

展示不同卷积核对图像的滤波效果：边缘检测、锐化、模糊和浮雕，动态演示3×3卷积核在图像上的滑动卷积过程。

冷启动成因：为什么第一串等四十分钟

烧烤店开业第一天的混乱，就是冷启动的完整写照。你回想一下那天：客人点单后，你才发现肉还在冷库里，当场解冻要二十分钟；炭火从零开始点，熏得眼睛疼，又花了十几分钟；连烤串的先后顺序都没定，三个人挤在案板前手忙脚乱。客人没有等待的耐心，四十多分钟后第一串才送上桌。

LLM 服务的“开业第一天”对应的是副本刚刚启动的时刻。一个 7B 参数的模型，权重文件有十几 GB 到几十 GB，从对象存储拉下来再加载进显存，这是第一道坎；紧接着，推理框架要把 Python 描述的计算图翻译成 GPU 可执行算子，触发算子融合和内存规划，这是第二道坎；第三道坎是显存里什么都没有——没有 KV 缓存、没有分配好的页、采样器也未初始化，第一个请求被迫承担所有“首次初始化”的成本。

用一条加法描述这段“冷”时间：

只要服务不重启、不扩容，这种“冷”的代价只出现一次；但流量高峰一来需要扩容，新副本就要再经历一次“点火”，相当于每次扩张都要重开一家分店。

模型预加载：开店前把肉搬上案板

开店第二天，你学到的第一课是提前备货。凌晨五点到店，把肉从冷库搬到案板上切好、腌好，客人来时直接就能上烤架。对应到推理服务，就是“模型预加载”：权重不等到第一个请求才拉取，而是在副本创建时就加载进显存。

预加载最朴素的做法是在容器启动阶段执行加载逻辑，比如用 initContainer 先拉权重，或者服务进程用 startup 钩子主动完成加载。更彻底的做法是把权重常驻在共享显存或节点本地缓存里，新副本直接读取，省掉大部分网络传输。与此同时，内存规划也要提前做：给模型权重、KV 缓存和激活值分别预留空间，避免运行时动态分配造成额外停顿。

把预加载从冷启动总时间里剥离出来，用户能感知的时间就变成了：

预加载不是把问题变没，而是把问题移到没人的时候解决。就像烧烤店半夜备料，客人看不见，也就不会抱怨。

权重预热：让炭火先烧到最旺

肉切好了，炭却没点着，客人来了依然要等。烧烤店真正的秘诀是提前两小时点火，让炭烧到通红、炉温均匀，食材一放上去就能听到滋滋声。

推理服务里的“炭火”是那些按需加载的 CUDA 内核。PyTorch 等框架默认懒加载：第一个请求经过某个算子时，它才编译并装载对应的 kernel。预热就是在服务启动后立刻发一个虚拟推理请求，把前向计算涉及的算子全部触发一遍，同时初始化 KV 缓存页和采样器。这样真正的用户请求到达时，所有“炉眼”都已经是热的。

一个普通请求不能替代预热，因为短 prompt 只触达少量算子，batch 形状一变，新的内核又得现场编译。预热请求要覆盖有代表性的输入长度和 batch 配置。预热完成度用已装载内核占全部内核的比例来衡量：

预热不是一次性的仪式，而是每次副本拉起、每次滚动更新都必须重复的动作。服务就该安静地待在预热区，直到炉火全红再迎客。

图编译缓存：菜谱写一次，下次直接翻本子

烧烤店的菜单如果每天重新画一遍，开店前几小时就耗在写菜单上了。聪明的老板会把经典菜单打印好，客人点单时直接拿出来用。

大模型服务同样会“从零画菜单”：每次新副本启动，都要把计算图重新编译一遍，这在深模型上可能耗费几十秒甚至几分钟。图编译缓存就是把编译产物序列化到磁盘或共享存储，下次启动直接读取，跳过重新编译。一个天然的问题是：什么时候能复用？答案取决于“菜单”是否变了。模型架构、GPU 型号、驱动和 CUDA 版本、推理框架版本，任何一个变化都会导致编译产物不兼容，因此要用哈希指纹校验，匹配成功才读取。

引入缓存后，副本启动时的平均编译开销由命中率决定：

有了编译缓存，每次扩容都像翻出旧菜单直接下单，而不是让新厨师重新发明菜谱。

弹性伸缩：高峰期前先开分店

烧烤店周末晚市会爆满，有经验的老板会在下午四点就开始支第二套炉子、叫临时工来帮忙，而不是等店门口排起长队再手忙脚乱。

弹性伸缩策略就是给服务“提前开分店”。常见的做法是基于流量预测扩容：利用历史请求曲线预测高峰时段，提前把副本从 10 个扩到 20 个。关键的约束是“扩容前置”——新副本必须完成加载、编译、预热才能接流量。如果流量到了才开始扩容，新副本还在点火，请求全部压在旧副本上，延迟照样爆炸。

扩容数量需要科学计算。副本太少，请求排队；副本太多，资源浪费。最小副本数可以由排队理论估算：

扩出来的新副本还要配“慢启动”保护：刚就绪时只分配少量流量，让模型服务和底层缓存逐渐热透，而不是被瞬间流量冲垮。

就绪探针：门开之前先试炉子

新分店支好炉子、码好肉串，怎么知道可以开门接客了？聪明的老板会先试烤一串：炭有没有热、串会不会散、调料够不够。全部通过，才挂出“营业中”的牌子。

Kubernetes 里的就绪探针（readiness probe）就是这个试炉动作。服务需要暴露三个关键的预热指标：权重加载进度、计算图编译完成数、预热请求执行状态。副本只有在这三项全部达标时，/readyz 才返回 200，负载均衡才会把流量导进来。探针没过，流量就不会进副本，用户也就不会体验到冷启动的漫长等待。

就绪判定可以用一个逻辑表达式描述：

就绪探针是 SLA 的看门人。有了它，滚动更新和弹性扩容才能放心自动执行—新副本没准备好之前，流量永远只流向老店。

落地实践：开业彩排与流程固化

把前面所有招数串起来，就是一套完整的开业彩排：提前备料、炭火烧红、菜单备好、分店到位、探针把关。最后一步是验证整套流程真的有效。

落地时有三件事最容易踩坑。第一是资源配额：预加载和预热阶段需要额外的 CPU 和内存，Kubernetes 的 Pod 资源请求要预留这份余量，否则预热请求会被系统 OOM 杀掉。第二是调度亲和性：如果每个节点都要重新拉一遍几十 GB 权重，扩容就变成了串行下载，因此要让新副本调度到已缓存权重的节点上。第三是压测验证：发布前对比预热前后副本从创建到就绪的时间，用数字确认策略有效。

整体加速比是衡量所有优化手段的综合指标：

烧烤店从第一天的手忙脚乱到第二天的从容不迫，靠的是一整套流程。LLM 服务的冷启动治理也一样—它不是某一个魔法开关，而是把加载、编译、预热、探针、扩缩容串成一条完整流水线。

AI 应用场景

Python 演示

"""演示预热如何降低 LLM 服务的首个 token 延迟"""import time  class FakeLLMService:    def __init__(self, model_name="llama-7b"):        self.model_name = model_name        self._loaded = False        self._warm_done = False        self._kernel_count = 0        self._kv_pages = 0     def load_weights(self):        start = time.time()        time.sleep(0.8)  # 模拟几十 GB 权重从磁盘搬入显存        self._loaded = True        return time.time() - start     def _infer(self, prompt):        if not self._loaded:            raise RuntimeError("model not loaded")        time.sleep(0.05)  # 模拟正常推理耗时        return len(prompt)     def warm_up(self):        for _ in range(4):            time.sleep(0.05)            self._kernel_count += 1        self._kv_pages = 16        self._infer("[warmup]")        self._warm_done = True     def is_ready(self):        return self._warm_done and self._kv_pages > 0     def serve(self, prompt):        start = time.time()        if not self._warm_done:            time.sleep(0.2)  # 冷启动: 内核未装载, 额外付出编译时间        self._infer(prompt)        return round((time.time() - start) * 1000, 1)  def main():    svc = FakeLLMService()    print("[冷启动阶段]")    load_t = svc.load_weights()    print("权重加载耗时: %.1f s" % load_t)     print("\n[服务已启动, 但还没预热]")    cold = svc.serve("hello, what is the weather?")    print("首个请求(冷): %.1f ms" % cold)     print("\n[执行预热]")    svc.warm_up()    print("就绪状态:", svc.is_ready())     print("\n[预热后连续请求]")    for i in range(3):        print("第 %d 个请求: %.1f ms" % (i + 1, svc.serve("tell me a story")))  if __name__ == "__main__":    main()

1. time.sleep(0.8)模拟几十 GB 权重从磁盘读入显存，是冷启动最直观的耗时来源。
2. if not self._warm_done:模拟真实服务内核未装载时的现场编译开销，冷请求因此额外多等 200ms。
3. self._kernel_count += 1每执行一次虚拟请求就多装载一个内核，对应真实场景中算子的懒加载机制。
4. self._infer("[warmup]")发送一次假的推理请求，把前向链路完整跑一遍，内核和 KV 缓存随之就位。
5. svc.warm_up()部署脚本在接流量前调用预热接口，是“烧烤店开门前点火”的直接体现。
6. svc.is_ready()对应 Kubernetes 就绪探针，只有返回 True 才允许副本进入负载均衡池。

常见误区

面试题