用 Serverless 跑 AI 模型，第一次请求经常要等一分多钟，后面就快很多。这个差异让很多人困惑：为什么不能一直这么快？
这篇拆一下冷启动的技术过程，以及能优化到什么程度。
一、冷启动里发生了什么
一次冷启动大致经历四个阶段：
1. 调度分配 GPU 实例 （秒级）
2. 拉取容器镜像 （十秒级，取决于镜像大小）
3. 加载模型权重到显存 （十秒级到分钟级）
4. 初始化推理框架 / 工作流 （秒级到十秒级）
把一个 32GB 内存 + 16GB GPU 的实例从零拉起来，60 秒并不夸张——光模型权重从存储读到显存就要时间，几 GB 的 Flux 模型、加 Lora、加 VAE，逐个加载。
热启动为什么快：实例已经在跑，模型已经在显存里，请求进来直接推理。所以从 60 秒降到 5 秒，差距全在前面那四步。
二、镜像大小是隐形杀手
很多人只关注模型加载，忽略了镜像拉取。如果镜像里打进了模型权重，镜像会变成十几 GB，每次冷启动都要拉一遍。
正确做法是模型与镜像分离：
- 镜像只装运行时和代码（几百 MB 到 1 GB）
- 模型权重放对象存储或 NAS，启动时挂载或下载
- 用 NAS 做共享存储时，多个实例可以共享同一份权重，不用重复下载
这个改动通常能把冷启动时间缩短一半以上。
三、缓存与预热策略
平台层面能做的优化：
最小实例数（常驻实例）。 配置至少 N 个实例常驻不销毁，请求直接打到热实例。代价是常驻期间持续计费，适合有稳定流量的场景。
预热请求。 定期发一个轻量请求保持实例活跃。很多平台在实例空闲一段时间后销毁，定期预热能避免反复冷启动。
模型缓存层。 首次加载后把模型留在内存/显存里，只要实例不销毁就一直可用。这是热实例的本质。
分层加载。 如果模型很大，可以先加载主干预测部分，其他部分延迟加载。代价是首次请求可能要等部分加载。
四、什么场景适合接受冷启动
冷启动不是缺陷，是"不用时不占资源"的代价。判断标准是：能不能接受首请求延迟。
适合：
- 批处理型任务：一次提交一批图片，第一张慢，后面都快
- 低频调用：一天用几次，不在乎等一分钟
- 内部工具：开发者自己用，能接受等待
- 异步任务：用户提交后等通知，不阻塞交互
不适合：
- 在线对话类应用：用户问一句等 60 秒会直接放弃
- 高频 API 服务：每次冷启动的成本比常驻还高
- 实时交互场景（语音对话、实时生图预览）
对在线场景，正确方案是配常驻实例 + 弹性扩容：常态跑 N 个热实例，流量高峰自动扩。
五、按量计费背后的计量单位
Serverless GPU 的计费通常按"实例运行时长 × 规格单价"算。技术含义是：
费用 = 活跃时长（秒）× 单价/秒
所以冷启动的 60 秒也是计费的——这段时间实例确实在占 GPU。这解释了为什么"调用 100 次，第一张贵，后面便宜"：第一张承担了冷启动成本，后续都是热推理。
理解这个计量方式，你就能算清楚"常驻 vs 按量"哪个更合适：
常驻成本 = 常驻时长 × 单价
按量成本 = (冷启动次数 × 冷启动时长 + 总推理时长) × 单价
如果调用频率很低（比如一天 10 次），按量明显更划算；如果持续有请求，常驻更稳定也更省。
六、几个实操建议
1. 先测冷启动基线。 部署完先测一次冷启动耗时，作为优化基准。不同模型差异很大——小模型 10 秒，大模型可能 2 分钟。
2. 优先瘦身镜像。 这是收益最高、改动最小的优化。
3. 模型权重放共享存储。 NAS 或对象存储，避免打进镜像。
4. 用批量请求摊薄冷启动。 一次提交 20 张图，冷启动成本摊到 20 张上，单张成本大幅下降。反之一次提交 1 张最亏。
5. 监控 P99 延迟。 平均延迟会掩盖冷启动问题，要看长尾。
七、写在最后
Serverless GPU 的技术本质是"资源按需分配"，冷启动是这个机制的自然结果。与其抱怨首请求慢，不如理解它的构成——镜像、权重、初始化三段，每一段都有明确的优化手段。真正的决策点是：你的业务能不能接受延迟，如果能，按量最划算；如果不能，就该上常驻。
函数计算部署 AI 模型的技术方案可以看官方页面——查看函数计算 Serverless GPU 部署 AIGC 应用的方案。具体资源配置与计费以页面实际展示为准。
你们的 AI 服务冷启动要多久？有没有为了压冷启动做过什么改造？评论区聊聊。
