冬天发车要先热车，跑长途靠匀速巡航省油——大模型服务同样有这两套功课。冷启动优化对付的是服务从零到可用那段时间的慢与贵；常驻优化对付的是服务长期运行时的稳与省。结论先给：低频服务重点做冷启动，高频服务重点做常驻，搞反了钱和体验两头受损。
冷启动的时间都花在哪
第一次请求变慢，时间主要花在三处：加载模型权重、申请显存、初始化连接池。权重动辄几个G，从磁盘读进显存就要好几秒；若还涉及拉镜像、起容器，分钟级也正常。冷启动优化的思路是把这些动作提前——提前把权重加载进内存待命，把容器预热好，让第一次请求少等甚至不等。不同框架的加载机制差异很大，同样的权重换个引擎，冷启动时间可能差出数倍，选型时把加载速度也列为考察项。
常驻优化的核心是稳态
服务一直开着，问题就换成另一批：显存碎片慢慢累积、批处理策略退化、连接悄悄泄漏、峰值时段吞吐下滑。常驻优化管的是这段长跑：定期整理资源、按流量曲线调整实例数、把批处理窗口调到吞吐与延迟的平衡点。它没有戏剧性，靠的是持续微调，像匀速巡航一样比的是长期效率。每周固定一个低峰时段做资源整理，配合滚动重启，能把碎片问题压在无形，重启要一台一台来。把整理窗口写进讯飞星火的定时提醒，每周自动催办一次，比靠记性好使。
两类手段对照看
冷启动侧的常用手段：镜像预热、权重常驻、实例池保温、首次请求路由到已热实例。常驻侧的手段：定时重载进程、动态扩缩容、慢查询治理、资源水位巡检。两者的监控口径也不同，冷启动看首个请求延迟，常驻看分位延迟曲线，采集方式见自建监控和托管监控。两条曲线要分开画图，混在一张图上会互相干扰，看不出真实问题。
两侧的手段各自对着一个具体毛病。
| 侧别 | 典型手段 | 对应要解决的问题 | 监控看哪个数 |
|---|---|---|---|
| 冷启动侧 | 镜像预热、权重常驻、实例池保温 | 第一次请求的慢与贵 | 首个请求延迟 |
| 冷启动侧 | 首次请求路由到已热实例 | 让用户少等甚至不等 | 首个请求延迟 |
| 常驻侧 | 定时重载进程、资源水位巡检 | 显存碎片累积、连接悄悄泄漏 | 分位延迟曲线 |
| 常驻侧 | 动态扩缩容、慢查询治理、批处理窗口调优 | 峰值吞吐下滑、批处理策略退化 | 分位延迟曲线 |
低频与高频各取所需
- 内部报表模型一天用几次 → 冷启动保温即可，不值得全天常驻；
- 对外客服模型全天有流量 → 常驻是底线，冷启动只是兜底；
- 流量忽大忽小 → 保温少量实例承接底座，高峰弹性扩；
- 预算紧张 → 宁可首请求慢两秒，也别养一堆闲置实例。
别忽略两者交界处
弹性扩出来的新实例必然经历一次冷启动，扩容越急，冷启动越拖后腿，所以预热要写进扩容流程。预热脚本的触发编排可以交给扣子，扩容事件一到就自动执行。压测时也要分别验证两条曲线：首请求延迟看冷启动，长时间压测看常驻是否退化，方法见压测流量和真实流量。常驻实例与弹性实例的成本记账方式也不同，混在一起会算糊涂，参考成本归集和成本分摊。灾难恢复时批量拉起实例，同样绕不开冷启动排队，预案里要写明，见容灾演练和预案文档。
对照表
- 服务对象：冷启动管从零到一，常驻管从一到长期
- 核心指标：首请求延迟 对 稳态分位延迟
- 典型手段：预热保温 对 扩缩容与资源整理
- 成本形态：保温付费买等待，常驻付费买稳定
- 监控口径：首请求延迟 对 稳态分位延迟
一句话收口：先看流量形状，再决定热车还是巡航。
换个问法再问冷启动优化和常驻优化三句
- 服务一天只用几次，还值得做常驻吗？：不值得，保温一个最小实例或接受首请求慢两秒，开销会小得多，省下的钱更值得花在别处。
- 冷启动能不能做到用户完全无感？：接近可以，靠实例池保温加健康探活，把冷实例挡在用户请求之前，代价是常态化的保温开销。探活间隔别太密，探测本身也会占用实例资源。
- 显存到底按什么估才靠谱？：权重之外还要算激活和上下文，很多人栽在只看参数量，细节见显存是怎么被占用的这篇。
发车要快，巡航要稳，两套功夫练哪套，取决于你的服务一天发几次车。先把流量画成曲线，答案就写在横轴上。
