大模型推理冷启动如何优化？
简化版
大模型冷启动不是单一步骤，而是“拉取镜像与权重 → 创建进程/GPU 上下文 → 加载并反序列化权重 → 建立并行通信 → 编译或捕获 Kernel → 预热 → 通过健康检查”的总和。几十 GB 权重与运行时初始化通常是主因。
优化要先分段计时，再针对瓶颈处理：镜像瘦身、权重本地化或分片并行加载、内存映射、复用编译产物、并行组初始化、代表性预热，并保留 Warm Pool。发布采用先预热后接流量，扩容信号应领先冷启动时间，不能等队列超时才扩容。
详细版
冷启动优化分为“缩短单副本启动”和“减少用户遇到冷启动”两条线。前者优化 I/O、CPU 反序列化、H2D、通信与 JIT；后者通过最小暖副本、预测扩容、滚动发布和流量门控隐藏启动过程。
image -> weight download -> deserialize -> H2D -> distributed init
-> compile/graph capture -> warm-up -> ready -> traffic必须明确 Ready 的定义：进程存活不代表能稳定服务，应在目标模型、Tokenizer、Adapter 和关键 Batch Shape 预热后才注册。验收看各阶段耗时、端到端 Ready 时间、首次请求 TTFT、扩容成功率和启动峰值网络/内存；不能只优化容器创建时间。
完整版教学
1. 先定义冷启动边界
冷启动可从调度器决定扩容开始，直到新副本能够在 SLO 内接收真实请求。若只统计容器 Running，会漏掉权重加载、图编译和首次请求抖动。
T_ready = T_schedule + T_image + T_weights + T_runtime
+ T_compile + T_warmup + T_healthcheck每一段都应埋点，否则只能看到总耗时，无法判断投入方向。
2. 镜像为什么会拖慢启动
镜像包含不必要编译工具、多个框架和重复 CUDA 库时，拉取与解压会占用网络和磁盘。分层设计不稳定还会导致每次版本都失去缓存。
使用多阶段构建、固定基础运行时层、删除无关依赖，并让高频不变层靠前。镜像瘦身后仍需验证驱动、CUDA、推理引擎和模型插件兼容。
3. 权重加载为何通常最重
大模型权重可达几十到数百 GB，路径包含对象存储下载、本地读取、CPU 解析与复制到 GPU。瓶颈可能在任一环节。
| 阶段 | 典型瓶颈 | 优化方向 |
|---|---|---|
| 远端下载 | 网络与对象存储限速 | 节点缓存、并行分片、P2P 分发 |
| 本地读取 | 磁盘吞吐 | NVMe、本地化、顺序读取 |
| 反序列化 | CPU 与内存复制 | 安全张量格式、内存映射 |
| H2D | PCIe/NVLink | Pinned Memory、并行加载 |
优化前先测每段吞吐，不能把远端慢误判为 GPU 初始化慢。
4. 本地缓存如何设计
把热点模型权重预置到节点 NVMe，可避免每个 Pod 从对象存储重复下载。缓存键必须包含模型版本、量化格式和校验和，下载完成前不能暴露半成品。
节点磁盘有限，应按启动频率、权重大小和重新下载成本淘汰。缓存命中率高但旧版本无法及时清理，也会造成调度失败。
5. 分片并行加载有哪些边界
张量并行模型的各 Rank 可并行读取各自分片，减少单点串行时间。若所有 Rank 从同一存储热点读取，反而可能打满共享带宽。
需要让分片布局与部署并行方式一致，并限制启动并发。校验每个分片后再建立通信组，避免某一 Rank 加载失败时其他 Rank 永久等待。
6. JIT 编译和 CUDA Graph 怎么处理
推理引擎可能在首次遇到某种形状时编译 Kernel，CUDA Graph 也需按 Batch/序列形状捕获。若把这些成本留给第一个用户请求，首请求 TTFT 会异常高。
可缓存与硬件、驱动、引擎版本匹配的编译产物，并在 Ready 前预热高频形状。不能预热所有可能形状，否则启动时间和图内存反而膨胀。
7. 预热请求应代表真实流量
只用一个短 Prompt 预热，无法覆盖长 Prefill、连续 Decode、量化 Kernel 和多卡通信。应选择少量代表性长度与 Batch Shape，并完成若干 Decode 步。
预热还要触发 Tokenizer、采样和流式输出链路。其目标是消除首次路径惰性开销，不是跑一套完整性能压测。
8. Ready 检查不能只看端口
进程监听端口时，权重可能尚未加载或通信组尚未建立。Readiness 应至少验证模型版本、GPU 内存、各 Rank 状态和一次轻量推理。
Liveness 与 Readiness 要分开：暂时未准备好不应立即重启；真正死锁或不可恢复错误才触发进程替换，避免启动抖动循环。
9. Warm Pool 如何隐藏冷启动
保留少量已加载模型的空闲副本，可在突发时立即接流量。代价是空闲 GPU 成本，因此 Warm Pool 大小应结合流量波动和启动时间确定。
对多模型平台，可保留通用运行时热进程，再按需加载 Adapter；但若基础模型也不同，单纯热容器无法消除权重加载。
10. 自动扩容为什么要提前
若完整冷启动需要 5 分钟，等 P99 已超标再创建副本必然来不及。扩容信号应基于队列 Token、预计等待、流量趋势和在途启动容量。
required_lead_time >= p95_cold_start_time + routing_propagation_time周期性业务可预测预扩容；不可预测突发则依赖 Warm Pool、准入控制和降级共同保护。
11. 发布过程如何避免冷启动暴露
滚动发布先启动新副本、完成预热与健康检查，再逐步导入流量；旧副本排空在途请求后下线。最大不可用副本数应根据现有容量余量设定。
模型大版本发布若同时清空节点缓存，可能形成下载风暴。可分批预置权重并限制并发更新，保留旧版本快速回滚。
12. Serverless 场景如何取舍
缩到零节省空闲成本，但首请求必须承担完整启动。适合低频、可异步或允许较长等待的任务，不适合严格实时 SLA。
折中方案包括延迟缩容、最低一个暖副本、快慢模型回退和请求先入有界队列。需要用节省的空闲成本与冷启动导致的流失、超时成本比较。
13. 如何压测和验收
分别测冷节点无缓存、热节点有权重缓存、同版本重启和版本升级四类路径；每类重复多次，报告 P50/P95/P99，而非最好一次。
同时记录镜像、下载、加载、H2D、通信、编译、预热时间以及首次请求 TTFT。模拟多副本同时扩容，验证存储和网络不会因启动风暴退化。
冷启动优化的终点不是容器更快启动，而是新容量在用户 SLO 失守之前真正可用。
14. 常见误区与追问
- 误区：Pod 进入 Running 就算启动完成。 模型加载和预热可能尚未结束。
- 误区：只把镜像做小就够了。 大模型权重和运行时初始化通常更重。
- 误区：缓存权重无需版本校验。 错配模型或量化格式可能导致错误甚至崩溃。
- 误区：用一个短 Prompt 预热所有路径。 长 Prefill、Decode 和图形状可能仍在首次触发。
- 误区：有自动扩容就能应对突发。 扩容有分钟级滞后，仍需暖池与准入。
- 追问：Ready 探针检查什么？ 模型版本、GPU/各 Rank 状态和轻量真实推理。
- 追问：如何避免权重下载风暴？ 节点预置、P2P 分发、并发限制和分批发布。
15. 加强记忆
- 先拆阶段：调度、镜像、权重、运行时、编译、预热、Ready。
- 再找大头：逐段计时，不凭感觉优化。
- 再减 I/O：本地缓存、分片加载、内存映射。
- 再消首次成本：缓存编译产物，预热代表性形状。
- 再藏延迟：Warm Pool、预测扩容、先热后接流量。
- 再防风暴：并发限制、预置权重、保留回滚版本。
- 最后验收：以 Ready 时间和首次请求 SLO 为准。