模型加载慢在哪：推理冷启动预热的工程账

扩容事件平均 40 秒，其中 28 秒花在权重落盘到显存这一段。剩下 12 秒也未必好过：进程初始化、CUDA 上下文、编译缓存和 CUDA Graph 捕获抢同一段时间。做预热优化，第一件事不是找加速器，而是把这条时间线拆开。拆不开就没法判断该买带宽、改格式，还是干脆留常驻实例。

把冷启动拆成四段，每段性质不同

按 vLLM 那套工程复盘里的分法，模型推理服务从调度到可服务，大致经过：容器和运行时拉起、模型权重加载、框架初始化（含编译与 CUDA Graph）、首请求处理。前三段可以并行化，但每一段的制约因素不同：容器镜像大小、存储带宽、主机到设备拷贝、以及串行的依赖顺序。

对照相关 serverless 的研究结论，图片镜像从网络传输到容器创建完成，100MB 级别要 20 秒左右；而装进 Pod 池的 Node.js 特化实例能在 15 毫秒完成——这条差距用一百多倍形容都算保守。读起来像大数字，实际含义是：绝大部分开销不在你我擅长的应用层代码里。调 loader、改 YAML 参数影响的是后面那几秒，前面十几二十秒通常在镜像、调度、磁盘上。

我的习惯是先画一根水槽图：从调度开始，每个阶段在哪结束，测量手段不同。排查这个流程花过一两天，比后面反复试参数要省事得多。

权重重传：把 I/O 和 H2D 重叠掉

基线是串行的：先读整份检查点进 host 内存，再以一个个 memcpy 送进 GPU。如果 checkpoint 是 pickle 分片格式，还要占据额外的主机内存峰值，读的时候别人只能在边上看着。

改善路径有两条。一条是格式层：流式加载器从存储里并发读取分片，直接送进显存，让存储读取和主机到设备拷贝重叠；商用侧案例中，声称利用 GPU 内存和本地存储做多级检查点加载，能把启动时间缩短到原来的六分之一到八分之一。这类数字的测试条件需要单独确认——测的是热缓存还是冷读，网络是随机读还是顺序读。

另一条在存储层。公开案例显示，某团队配置 Alluxio 之后，从云存储加载模型峰值吞吐做到约 2 Gbps，比原先的 200 Mbps 提高 10 倍；5GB 模型在热读下加载约 2 秒、冷读约 9 秒，原先约 24 秒；24GB 模型热读约 8 秒、冷读约 35 秒，此前对照的方案是约 50 秒。这里需要看明白的一层差异：6 到 12 倍的压缩，大半来自“旁边有缓存”，靠的是持续占用的存储节点和热数据命中。这属于容量换时间的取舍，规模有限做不起。

工程默认值先问：量化之后模型多重？如果 4-bit 只有 35GB，那么 2 Gbps 对整份权重的理论时间下限是 140 秒附近（换算细节取决于配置）。真实存储带宽做不到理论上限十倍，瓶颈其实先出现在网络，并非 loader。

对 MoE 大模型更烦的问题：切数据并行后每张卡要的权重体积翻倍，载入时钟整体贴着带宽。也有缓解办法，例如只加载需要尽快成为活跃者那部分，剩下的懒加载，但端到端首 token 的延迟曲线更差。

编译缓存和 CUDA Graph：先热个代码，不一定马上抓图

权重虽主角，也往往被高估。torch.compile 这种路径，首次命中的编译要花多少取决于形状核和内核数量；而 CUDA Graph 的捕获时间与捕获区域的规模成比例。业内的做法之一是把 CUDA Graph 改为懒捕获：先响应流量，在请求空闲期完成捕获，靠修改推理循环或加版本门禁处理图上多下来的请求。公开资料给的说法是适配“对首请求时延敏感而整体稳态需要优化”的两种场景都能用，代价是实现复杂度超过其设置选项。

此外还存在跨实例中间状态复用的路线：编译缓存、预填充过的 kernel 状态通过共享存储直接接续，避免每个节点都要从第一次启动处开始。执行细节没有开放评估的工具，我只能说，凡是有“共享状态”都好，但版本升级、次版本编译 ABI 一旦不匹配很容易引爆 debug 现场，生产灰度必须按镜像和模型两个维度划分兼容域。

守护实例预铺：最土但最稳的方案

工业界已经有一套熟得不能再熟的硬件流水线方案：保持少量热工作节点常年占用，骤增流量先打到它们身上，网络延迟不触用户，后面的慢扩容接上。Snowpark、Serverless GPU 队列等早期都不太重视一点。2025 年开始，主流 AI 编排框架多数开放了最小副本和最小预热参数，但改参数的时候，看单一的数字还不够。算清一笔账：留一或两个满载基础副本的费用于用户满意度比例。- 适合：流量曲线不定期脉冲，付费频率尚可；- 别适用：p99 尾延迟敏感，但常规请求不会只用 10% 算力，因为那几个机器占在那只发完第一次请求就开始摸鱼。

取舍写清楚。运维监控里必须有一个例外阈值是：如果某个预铺实例过去的高负载命中率低，就要做缩容决策；否则基建支出变成“沉默惯例”，谁也没动力动。

我实际踩过的几个坑

• 只看平均耗时没意义。 冷启动对具体请求是 0/1 事件：过了几分钟就过了，但用户那里是秒到分钟级等待。该盯 p99 首请求时延和启动事件分布，而非服务整体 avg latency。
• 模型内容拼装配件，网络是共享的。 大量排 concurrently 拉模型时，多个 pod 竞争同一网卡和存储出口，加载速度会线性分解。实测才能看见压力点叫“并行度爬坡撑不住”。
• 显存峰值过载可破坏预热正确性。 权重大片预取打满卡，需要预留 slab，否则与后续 KV Cache 竞争连续块，并且可能触发非预期抢占。
• 冷加载下的量化和正确性要重新验。 不确定流式加载时打到的 tensors 有不尽对齐的分片情况，仍需在整份载入后校验随机抽子集输出。

把上面列几条线收尾，结论不像营销页那么清晰：先从测量搭好可观测流程，永远留全部配置参数对照组；接着尝试把磁盘和主机拷贝的重叠拉满，改成共享对象缓存来省网络；对非根须避免串行重复的工具类 hot state，有条件再启用；最后，业务场景允许 SLA 宽限时，常驻少量预热副本。它结构简单、有效，出问题的外部面最少。