vLLM 冷启动为什么慢到怀疑人生？一篇 MLSys 2026 论文把它拆成了六个清晰的阶段

  • 关联论文：2606.07362

你有没有这样的经历：

  • 早上 9 点业务高峰来了，K8s 自动扩容了 50 个 vLLM 推理副本
  • 但首请求平均等 40 秒才出第一个 token
  • 用户在客户端狂点「重新生成」，P99 延迟直接飙到 3 分钟

「Cold start（冷启动）」是大模型部署里最容易被低估、又最影响用户体验的一段——首请求延迟（Time-To-First-Token, TTFT）里，冷启动可能占一半。

但社区里关于「vLLM 启动到底慢在哪」的讨论一直停留在三个层面：

  • 「反正就是慢」
  • 「换更贵的 GPU 应该能缓解」
  • 「试试 torch.compile 吧」（然后发现启动更慢了）

直到 MLSys 2026 出现了一篇论文——《Demystifying the Cold Start Latency of vLLM》，第一次把整条冷启动流水线拆成六个清晰的阶段，给出每一步耗时、CPU/GPU 瓶颈归属、和一个用参数就能算出来的解析预测模型。工程师拿到硬件配置，代入公式就能估出冷启动耗时。

这篇科普用 5 分钟把它讲透。

一句话先抛：vLLM 冷启动是 CPU 受限，加 GPU 没用

作者在 22 个开源模型 × H100/L40S × vLLM v0.10.1.1 上做了系统化 profile，得到一个反直觉的结论：

vLLM 冷启动 90% 以上的时间花在 CPU 端（权重反序列化、进程 fork、worker spawning），与 GPU 利用率几乎无关。

这就解释了为啥「升级到 H100」对冷启动帮助有限——你加了 10 倍算力，启动时间却只缩了一两秒。真正的杠杆点在 CPU 主频、NVMe 顺序读吞吐、和反序列化效率。

六个阶段拆解：拿到这份清单就能逐项优化

作者把 vLLM 从「命令行拉起」到「OpenAI 兼容 API 就绪」的整段流程，精确切成六个连续阶段：

  1. Model loading（模型权重加载） - 从磁盘/HuggingFace Hub 读 safetensors 文件 - 做格式校验、分片合并 - CPU 受限，近线性于参数量 N

  2. Tokenizer loading（分词器加载） - 加载分词器 + 对话模板 - 构造 preprocessor - 近常数项，秒级以内

  3. Memory allocation（显存/内存分配） - 在 CPU/GPU 上划分 KV cache 区域 - 划分激活显存、workspace - 与 PagedAttention 的 block 数相关

  4. Cache engine init（KV cache block 池初始化） - 构建并初始化 PagedAttention 的 block 池 - 构造 prefix cache 的元数据结构 - 近常数项，秒级以内，但一旦启用长上下文会显著拉长

  5. Worker spawning（推理 worker 进程拉起） - 拉起 Tensor Parallel / Pipeline Parallel / Speculative Decoding 的多进程拓扑 - CPU 受限，含进程 fork + CUDA init 的固定开销

  6. API readiness（HTTP server 就绪） - 启动 OpenAI 兼容 HTTP server - 注册路由、ZMQ 通信、Metrics 上报 - 近常数项，秒级以内

这套分解的最大价值不是「步骤名好听」，而是它给了工程团队一套共同语言——你说「我们现在慢在 step 3」，所有人都知道你在说显存分配。下次做容量规划、跨团队吐槽、SLO 优化，都能锚到同一个颗粒度。

三条工程金句：用这套框架能立刻省钱

金句 1：90% 的时间在 CPU 端，别把钱砸在 GPU 上

同样是 70B 模型，H100 与 L40S 的启动时间差距远小于「按 GPU 价格预期」的差距。意思是「只要有钱买 H100」的采购逻辑对冷启动是失效的。

正确的优化排序：

  1. 换更快的 NVMe SSD（甚至考虑 RAM disk）
  2. CPU pinning + 提高主频（不是加核数）
  3. 预热权重到 OS page cache（但要先关掉 fadvise(DONTNEED)，否则容器重启一次就冷）
  4. 最后才考虑升级 GPU

金句 2：把冷启动预算写进 K8s 副本策略，不要藏进 SLO 误差

很多团队的 HPA 配置用「CPU 利用率 >70% 触发扩容」，但扩容本身要 30–60 秒。这段窗口期的首请求延迟是用户能感知到的，但被 SLO 统计掩盖了。

论文给的解析公式可以直接拿来算：

T_cold_startup ≈ f(N, L, H, B, hardware)

代入你的模型参数量 + 目标硬件配置，就能预估「扩容一个副本到首请求就绪要多长时间」，然后在 HPA 里给扩容速率留出对应 buffer：

# K8s HPA 思路（伪代码）
desired_replicas = ceil(current_qps / per_replica_capacity)
warmup_seconds = analytical_cold_start(model_size, hardware_spec)
target_buffer = warmup_seconds * qps_growth_rate_per_second

金句 3：torch.compile 是双刃剑，看业务形态决定开关

torch.compile 能在稳态推理上提速，但编译本身发生在冷启动阶段（Model loading 之后、Worker spawning 之前），是纯启动开销。

业务适配：

  • 短命实例 + 高 QPS（比如函数推理、Serverless）：关掉 torch.compile，每次重编会显著拉长冷启动
  • 长命实例 + 低 QPS（比如常驻在线推理）：打开 torch.compile，摊薄后是净赚

vLLM v0.10+ 已经把开关做成了配置项：

# vLLM config
LLM(
    model="meta-llama/Llama-3-70b",
    tensor_parallel_size=4,
    enforce_eager=False,  # True = 关闭 torch.compile
    # ...
)

为什么这件事对 2026 年的 LLM 工程至关重要

如果你做的是下面任一种业务，这篇论文几乎是必读：

  • Serverless LLM（Modal、Beam、AWS Inferentia）：冷启动是用户能直接看到的延迟
  • 流量有峰谷的 SaaS：早高峰扩容体验决定用户留存
  • K8s 上的弹性推理：HPA 调参依赖冷启动预测
  • 边缘 / 端侧推理：本地硬件弱，冷启动感更强
  • 多模型多规格的推理平台：选哪种配置「冷启动 + 推理」总成本最低

论文还开源了完整的工具链（vllm-startup-profiler），把整套方法论打包成 22 个模型 + 2 类硬件的 profile 数据 + 解析预测脚本。CI/CD 接入做冷启动预算校验，是这份工具最直接的用法。

三处落地风险别踩

风险 1：解析模型需要本地校准

论文用 H100 / L40S 训练，套到 AMD EPYC + A100 或国产卡（昇腾 910、寒武纪）上预测精度可能偏差 2–3 倍。

落地做法：用 vllm-startup-profiler 在目标硬件上先跑一轮本地 profile，至少覆盖 Model loading 和 Worker spawning，做一次最小二乘拟合校正系数。

风险 2：MoE 模型的参数量代入有误

MoE（Mixtral、DBRX）的「总参数量 N」和「实际加载量」差异巨大（Mixtral 8×7B 总参数 46.7B，但每 token 只激活 ~12.9B）。

直接拿总参数 N 代入公式会高估冷启动时间。建议用「实际反序列化的激活参数量」替代，或在公式里加 MoE sparsity ratio 系数。

风险 3：容器内 page cache 状态不可控

论文环境的 Model loading 速度，依赖权重文件已被 OS page cache 命中。但 K8s 容器首次调度时 page cache 是冷的，Model loading 可能比论文环境慢 2–5 倍。

落地做法：部署脚本里强制 fadvise(DONTNEED) 让每次都测「真冷」，避免依赖「幸运的 page cache 命中」导致 SLO 失准。

写在最后

冷启动是 LLM 部署里最容易被假装不存在的性能问题——因为它的可见性差（藏在 SLO 平均值尾巴里）、复现性低（依赖 page cache、CUDA init 抖动）、跨团队难共担（运维嫌慢，应用感受不到）。

但它直接影响用户感知的首请求延迟、自动扩缩灵敏度、以及单位算力的吞吐密度。

这篇 MLSys 2026 论文最大的贡献，是把一个长期玄学问题变成 6 个可量化的工程步骤 + 1 个解析公式。当你下次再被「这个模型启动怎么这么慢」拷问时，可以直接说：

「现在慢在 step 3，KV cache block 池预分配吃掉了 12 秒，建议把支持的最大并发上下文长度从 200k 降到 32k，能省掉 9 秒。」

——这是工程语言，而不是「玄学调参」。

延伸阅读 - 论文：arXiv 2606.07362（MLSys 2026，vLLM v0.10.1.1） - 开源工具：https://github.com/upb-cn/vllm-startup-profiler - 互补工作：LLM-Perf / Photon（聚焦稳态吞吐与 TTFT 推理段，本文补齐冷启动段） - 同方向：AWS Inferentia / Modal / Beam 等 Serverless LLM 平台的冷启动研究