无服务器推理中的冷启动延迟：那些几秒钟到底发生了什么

冷启动是五次等待，它们之间没有共同的原因。

• 第一阶段：调度和容量分配。 在其他任何步骤之前，平台会寻找或启动一个具有足够空闲内存以容纳您模型的 GPU。这段时间的长短取决于集群的使用程度以及调度器放置您工作负载的速度，与您的模型本身无关。这是用户永远不会直接看到的阶段，也是运行间变化最大的阶段，而自托管的复现 无法观察到 这一阶段。在您自己的 GPU Droplet 上，没有多租户调度器来决定 GPU 是否空闲。任何白盒实验默认都对这一阶段视而不见。下面的 Track B 是我们两项测量中唯一能够看到这一阶段的，而且即使如此也只是间接可见。

• 第二阶段：容器和运行时启动。 平台会拉取容器镜像（如果该节点尚未包含该镜像），启动容器并初始化依赖项。这是通用无服务器讨论所关注的阶段，而在平台具备良好镜像缓存后，它通常是贡献最小的部分。我们的测量结果印证了这一点，尽管其中有一个让我们感到惊讶的注意点，我们将在下文中讨论。

• 第三阶段：权重传入 VRAM。 模型的权重会从对象存储或本地 NVMe 移动到 GPU 显存。持续时间大约等于权重字节数除以有效带宽，因此它会随着模型大小线性增长，并且很大程度上取决于权重的存放位置。这是量化直接影响的阶段，也是大多数人认为占主导的阶段。我们的数据表明，只有在缓存为冷状态时，它才会占主导。

• 阶段 4：服务运行时初始化。 CUDA 上下文创建、引擎启动、KV 缓存分配，以及显著的 CUDA 图捕获——在引擎首次遇到特定批次形状时进行。DigitalOcean 自己的 Ornith-9B 基准测试 已经表明这一阶段是真实存在且可分离的：在新的并发级别下的首个请求的首 token 延迟（TTFT）达到 0.691 秒，而在已经预热的硬件上，后续每个请求大约只有 0.035 秒。这仅来自 CUDA 图捕获就产生了约 20 倍的差距。我们的分解表明，这一阶段是热缓存冷启动的主要开销。

• 阶段 5：首次请求的预填充。 实际的首次推理，在生成开始之前将您的提示词的 token 转换为模型的内部表示。这看起来就像普通的 TTFT，但在冷启动时，它会叠加在前述所有开销之上。服务提供商有时会引用一个所谓的“冷启动”数字，实际上它是包含预填充的 TTFT；有时则完全排除预填充。了解您查看的是哪一种，就是有用数字与营销数字之间的区别。

我们进行了两项实验，并且将它们分开进行很重要。

• 轨道 A 是白盒分解。 我们在单个 H100 80GB GPU Droplet 上从零部署了 vllm/vllm-openai:v0.26.0，并直接通过挂钩 vLLM 自身的启动日志行对每个阶段进行时间戳，从容器启动到首次预填充。我们在四种 Qwen3 模型规模（0.6B、1.7B、4B、8B）和五种缓存条件（从完全冷到完全热）上进行了此实验，总共 200 次试验，每个条目十次。轨道 A 能够将黑盒测试仅能看到的聚合结果进行分解。其唯一的硬性限制（事先已说明）：它近似估算阶段 2 到 5，但无法观察阶段 1，因为在您拥有的 Droplet 上没有多租户调度器。

• 轨道 B 是黑盒观测。 这里的计划在与实际接触后发生了变化，这就是为什么它在下面有自己的小节。我们测量了用户在 DigitalOcean 无服务器推理平台上实际体验到的情况，每五分钟探测一次，持续七天。

值得提前指出的三个范围限制如下。我们在 Track A 上测量了 0.6B 到 8B 的范围，而不是完整的 70B 阶段细分：70B 仅在 Track B 中作为黑箱控制出现。我们未做量化/精度扫 sweep，因而 Phase 3 由 4 位权重带来的差值是根据字节数推断的，这里没有实际测量。并且，每次试验的 harness 和数据已单独发布（见上述注释中的仓库链接），而未直接嵌入。下面的缩放趋势在四种规模上足够明显，可外推到 70B 的形状，但 70B 本身的阶段划分仍是预测而非测量得到的。

Track A 中的五种缓存条件，每种相比前一种多保留一个温暖的对象，正是它们让我们能够把时间归因于具体阶段：

我们采用了 DigitalOcean 自身的 TTFT 定义，并遵循了 metrics-that-matter 协议：多次试验，丢弃预热，按一天中的时间窗口抽样，因此这些数字与本系列其他工作的结果可比。

Track B 的原始计划是标准做法：让无服务器部署在超过其 scale-to-zero 窗口后保持空闲，发送请求，然后测量其比温暖情况下慢多少。这是每篇冷启动文章常用的方法。但在共享无服务器推理中这行不通，弄清楚原因将重新定义整个问题。

DigitalOcean 无服务器推理 在所有客户之间共享 GPU 容量。没有任何闲置的按客户实例，也没有部署 ID，也没有属于你的 scale-to-zero 窗口。你的沉默不会让模型变冷；其他租户的流量让它保持温暖。你需要编写的函数，“等待我的部署缩放至零”，不仅难以实现，而且毫无意义，因为根本不存在 我的部署 可以进行缩放。

我们通过直接方式得出了这一结论。采用强制设计的第一次测试产生了 41 个样本，其中位数 TTFT 为 1.05 秒，且空闲时长与延迟之间完全没有关系。在 41 次试验中，有 10 次冷请求的速度快于热请求。这并不是一次失败的测量。这是对一个在我们每次探测时始终保持温暖的资源池的正确测量。

于是我们从 强制 冷启动转为 观察 冷启动。在共享平台上，冷启动仍然会发生，因为容量会随着总体需求进行扩展，且模型会被驱逐，但你无法 引起 它。你只能持续采样，并在发生时捕获它。对方法论的影响：

• 频繁探测，持续较长时间。 我们每五分钟采样一次，持续七天（共获得 1,827 个可用探测），而不是只做几十次强制试验。
• 尾部才是故事，而非中位数。 在温暖的资源池中，中位数仅仅表示“资源池是温暖的”，这几乎总是成立。问题在于用户遇到慢请求的频率以及慢到何种程度。
• 模型受欢迎程度取代空闲时长成为自变量。 旗舰模型会因其他人的流量而保持温暖；冷门目录模型则是最有可能观察到扩容的地方。我们在同一样本中对低流量目标（alibaba-qwen3-32b）进行探测，并以热门对照组（llama3.3-70b-instruct）作为对照，这样，若仅在一方出现尖峰而另一方没有，就能判断原因是模型特定的还是平台范围的。

控制探测是使 Track B 数据可信而非仅凭轶事的关键。从池外观察到的延迟尖峰可能是模型加载、网络波动、拥塞或客户端连接设置造成的。将已知温暖的控制与目标一起探测、单独计时网络路径、检查间隔 token 延迟是否保持正常以及立即重新发送每个请求，这四种独立的方法可以帮助我们区分这些因素。

该设计基于一个值得说明的假设：在共享平台的轨道模型上，冷启动的发生取决于模型的受欢迎程度，因为热门模型能够证明预热副本的合理性，而小众模型则不然。这一结论并非我们独自提出。DigitalOcean 的一致性基准测试（consistency benchmarking）也得出了我们在独立测试中构建 Track B 所依据的三个结论：应测量变异系数而非中位数，因为冷启动会产生中位数掩盖的双峰分布；应在非高峰时段取样，因为当模型流量最低时冷启动表现最差；还应预期低流量模型比热门旗舰模型更频繁地发生冷启动。我们所采用的冷门目标对照热门控制的设计，正是将这一推理应用于单一平台随时间的变化。

以下是 8B 模型的 Track A 分解，从完全冷启动 (C0) 到完全预热 (C4)，以容器启动到首个 token 的中位数秒数衡量：

首先，原始冷启动耗时 157 秒，其中约 63 秒（即 8B C0 镜像拉取中位数，为上表未显示的 Phase 2 子测量）用于容器镜像拉取，民间认为这部分可忽略不计。只有当节点已存有你的镜像时才能忽略；在真正冷启动的节点上，这项是最大的单一开销。其次，注意 C1 的速度实际上 快于 C2。当权重被删除（C1）时，vLLM 在试运行期间下载权重，并将其缓存到页面缓存中变为“温热”；当权重存在磁盘但页面缓存被清除（C2）时，引擎会发生一次真正的冷读取。从磁盘下载权重以及从冷磁盘读取权重的成本大致相当。这种倒置首先暗示 页面缓存，而非权重来源，才是关键因素。

图 1. Qwen3-8B 在不同缓存条件下的阶段分解。C0 总时长主要由 63 秒的镜像拉取决定；C4 底线为 53 秒。

现在看基线。当所有缓存均已预热（C4），8B 模型的冷启动底线降至 52.9 秒。以下是 vLLM 自身日志可直接计时的主要组成部分：

这些是日志标记的阶段，不是完整的划分：它们的总和约为 43.8 秒，剩余约 9 秒是容器启动以及各阶段之间未标记的间隙。形状才是关键。只有花费 8 秒加载权重的部分会随模型大小变化。其余的是固定的进程、CUDA 和图捕获开销，无论是加载 0.6B 模型还是 8B 模型，这一部分都是相同的。证明在于：在参数规模变化 13 倍的范围内，底线变化甚微——0.6B 时为 48.6 秒，而 8B 时为 52.9 秒。参数增加十三倍的模型，使得热缓存底线仅增加约四秒。

图 2. 四种规模下的相同分解。在参数范围扩大 13 倍时，C4 底线从 49 秒升至 53 秒。

编译缓存是与页面缓存独立的杠杆，它作用于不同的阶段。

图 3. 按条件划分的 torch.compile 时间。编译缓存将其降低约 4 倍（C2→C3）；升温页面缓存（C3→C4）对此影响甚微。

这里的数据与直觉的解剖学相矛盾。第三阶段（权重传输）是大家普遍认为占主导的阶段，在你预热 OS 页面缓存时它会收缩得最多（编译缓存单独削减第四阶段），而在底部它的大小甚至小于 CUDA 初始化或图形捕获。瓶颈在于第四阶段：CUDA 上下文创建和图形捕获，无论多少权重预暂存都无法触及。缓存是必要的但不充分的。你可以去除镜像拉取、预暂存所有权重、预热页面缓存，但仍会等待约 50 秒，因为这段时间是引擎启动的时间，而不是模型加载的时间。

如果在底部第三阶段（权重加载）很小，那么在冷启动时它会变得巨大；导致这种变化的因素是 OS 页面缓存，而不是权重被预暂存的位置。

我们在各种条件下测量了不同模型大小的权重加载时间。在 冷 页面缓存情况下，权重加载大约每 GiB 需要 1.42 秒。在 温暖 页面缓存情况下，边际 加速降至大约每 GiB 0.15 秒，在此基础上还有固定的约 5–6 秒加载开销，这意味着与大小相关的部分减少了大约 90%。各模型的差异如下：

图 4. 右侧为权重加载时间与模型大小的关系。冷页面缓存大约每 GiB 1.5 秒；温页面缓存降至大约每 GiB 0.15 秒。

对于 8B 模型，权重是否恰好位于 OS 页面缓存中这一点的影响达到了 18 秒，这比编译缓存的差异（约 13 秒，即 8B 模型特定阶段的 torch.compile 中位数差异）更大，也大于我们测量的任何其他单一可避免的开销。与固定底线不同，这一开销会随模型大小而增长，因此对于大多数人实际担心的 70B 级模型来说，情况只会变得更糟。

这重新诠释了‘在本地 NVMe 上预存权重’的建议。在快速本地磁盘上预存权重确实有帮助，但真正起作用的机制是 页面缓存：文件的第二次读取之所以快，是因为它来自内存而不是磁盘。在无服务器平台上，这表现为请求落在最近刚刚服务过你的模型的节点上与未服务过的节点之间的差异——正是池化调度器试图利用的局部性。

现在来看黑箱视图。以五分钟间隔进行七天的测试产生了 1,829 次合法探测。在这些合法探测中，有 1,827 次得到了可用的目标模型 TTFT；其余两次分别是一次 500 错误和一次 200 响应但未返回任何 token，均被记录为失败而非快速响应。因此可用率为 99.9%，下面的百分比均基于合法的目标模型探测。需要注意的是，在这整个部分中，这些数据来源于一周内、来自单个客户区域、针对单个目标和控制配对的测试。这些数字仅适用于该特定设置，而非对平台的普遍特征描述。

图 5. 目标模型 TTFT 尾部（对数尺度）。99% 的探测在 3.9s 以下完成；最慢的为 9.3秒。

每种缓解措施都针对一个特定阶段。正是这种映射，使得供应商的‘快速冷启动’声明可验证，而不仅仅是一句口号。

• 第一阶段（调度）：温池和最小实例底线。 提前预留容量，使请求永不需要等待调度。在共享平台上，这是提供商为你不可见地完成的工作，我们的 Track B 数据表明它在 99% 的合法目标模型探测中有效。剩余风险是事故尾部。保活流量无法修复这一点，因为你不控制该池；不过重试、模型或提供商回退以及降级模式路由可以降低你对此的暴露。
• 第二阶段（容器启动）：节点本地镜像缓存。 我们的数据对这一点进行了重新框架。镜像拉取在节点已有镜像时可以忽略不计 仅在节点已有镜像时；否则需要 63 秒，这是完全冷启动中最大的单一开销。在具备良好节点本地缓存的平台上，这问题基本得到解决；在冷节点上，它则占主导。更轻量的镜像直接有助于改善冷节点情况。
• 第三阶段（权重传输）：先暖页缓存，再考虑来源。 量化仍然有所帮助（移动的字节更少），但我们的数据表明更大的杠杆是页缓存局部性：冷态 1.42 s/GiB 与暖态 0.15 s/GiB。将权重预存到本地 NVMe 之所以重要，主要是因为它使得第二次暖读成为可能。对于 70B 级模型，这将带来数十秒的波动。
• 第 4 阶段（引擎初始化）：预先捕获 CUDA 图并保持上下文存活。 底层测量把这一阶段从脚注提升到标题位置。大约 53 秒的 warm-floor 时间里，约有 25 秒用于 CUDA 初始化和图捕获，这是固定开销，对小模型来说比例上更不利。只需预捕获预期批次形状的图并在请求间保持持久的 CUDA 上下文，才能影响此阶段。如果供应商把“快速冷启动”仅归因于权重，那么他们就没解决实际上主导热缓存启动的阶段。
• 应用层面（与阶段无关）： 在客户可控制部署且具备 scale-to-zero 窗口的无服务器系统中，保活 ping 能防止 scale‑to‑zero，但它是按请求付费取暖，而非按小时付费——这与预留容量决策的权衡相同，只是表述方式不同。足够的保活流量和预热计划加起来，等同于系统在为专用容量付费却不愿明说。应该直言不讳地命名它，而不是把无服务器加上变通手段当作免费。

值得直白地说明，既然这是常见的混淆：提示缓存不会降低冷启动。 提示缓存作用于已经在运行的部署中的重复输入内容；冷启动是指部署在缩放到零后重新加载自身。它们是不同的机制，解决不同的问题。如果工作负载同时需要两者，则需要同时使用两种方案。

无服务器在您的流量下是否比专用容量更便宜，这是一个问题；而您的工作负载是否能容忍无服务器带来的冷启动，则是另一个问题。两者都必须满足。我们的数据让您能够使用尾部（而非中位数）具体地推断第二个问题。

• 可以容忍冷启动且无需任何缓解措施，当 工作负载是异步或批处理（如嵌入、离线评分或任何无人等待的场景），此时它是一个内部工具，偶尔的延迟不是产品问题；或者（依据 Track B）您处于一个池化平台，其测得的 TTFT 分布符合您的 SLA，常规尾部较低（我们的目标模型 p99 小于 4 秒），并且您能够承受类似对照模型那样罕见的多分钟事件。

• 无服务器加缓解，当 工作负载面向用户且突发到足以让最小实例下限覆盖流量周期，而无需全天候付费容量。计算是直接比较：一个温暖的底线实例与完整的专用容量相比，权衡的是自己管理温暖池的运营成本。

• 专用容量，当 包含冷启动的 p99 直接违反您的 SLA，或者（Track B 添加的情况）即使中位数表现优秀，您也无法容忍罕见的失控尾部事件。自托管的约 157 秒完全冷启动中位数（在此 8B 设置下测得）虽然不好，但它属于您：可重复、可预测，并且您可以通过控制的温暖池来消除它。共享平台的 287 秒事件很少见，且由他人负责修复，这取决于等待响应的内容，可能是可以接受的，也可能是不可接受的。

延迟决策背后有一个经济门槛。DigitalOcean’s 代币经济分析 为 70B 模型计算出交叉点：专用 H200 GPU Droplet 仅在持续 GPU 利用率大约超过 72% 时，才在每 token 基础上击败无服务器；低于此利用率时，您全天候付费的闲置容量会使无服务器更具成本优势。冷启动容忍度和该利用率阈值必须指向同一方向。突发且面向用户的工作负载往往低于利用率线 且 最难以吸收冷启动，这种组合会促使您选择无服务器加温暖底线，而不是两极选择。推理三难框架 中的 TTFT 和 inter-token 延迟 (ITL) 在 p50/p95/p99 水平是您在决策时用来把握 SLA 的词汇。

任何供应商的“快速冷启动”声明的五项检查清单，每阶段一项：Phase 1：预分配的容量与即时调度的容量各占多少？Phase 2：镜像是否在服务节点上本地缓存？Phase 3：权重是否预先暂存到 GPU 附近 并且页面缓存是否已预热？Phase 4：服务引擎的图和上下文是否已为您的批次形状预热，还是在首次使用时现场编译？Phase 5：所谓的“冷启动”数值是否包含首次请求的预填充，还是单独测量？能够用具体数据回答全部五个问题的供应商在告诉您真实情况。只给出单一汇总数字的供应商在重复每个竞争对手营销页上的说法。

当供应商不予回应时，可参照 Track B 的做法进行测量。DigitalOcean 的 一致性指南 提供了一条值得借鉴的经验法则：对模型发送至少 75 次间隔请求，随后计算 TTFT 的变异系数（标准差除以均值），而非使用中位数。其区间可作为可用的门槛：低于 40% 表示模型已预热并经过优化；超过 100% 表示你正遇到冷启动；超过 300% 则应视为在没有专用端点的情况下，不适合用于对延迟敏感的生产工作负载。建议在非高峰时段运行此测试，因为此时尾部延迟最严重。

1. 冷启动到底会发生什么？

冷启动可分为五个不同的步骤，每个步骤都会带来各自的延迟和复杂性：

1. GPU 调度： 平台会寻找并调度一个可用的 GPU 来处理你的作业。
2. 容器启动和镜像拉取： 它会启动一个容器，并在需要时将镜像拉取到节点。如果已经在本地缓存，这一步可以忽略不计；否则可能会相当耗时。
3. 模型权重传输： 模型权重被加载到 GPU 显存（VRAM）。此步骤的时长取决于模型的大小以及权重是否已在操作系统页面缓存中，或必须从存储读取。
4. 推理引擎初始化： 推理引擎（常见为 vLLM 或类似）进行初始化。这可能包括创建 CUDA 上下文、分配 KV 缓存以及执行 CUDA 图捕获。这些基本属于固定开销，当所有缓存均已预热时，它们会成为瓶颈。
5. 首次 prefill： 系统在生成开始前处理提示词，这就是用户实际感受到的包含冷启动的 TTFT。

每个阶段都有不同的调节杠杆，且可能受到硬件、架构和软件栈选择的影响。“冷启动”指的是这些步骤的组合，而非任何单一环节——因此端到端的耗时会掩盖底层的细分。

2. 加载模型权重是否导致大部分延迟？

只有在从冷存储读取时才会如此。如果操作系统页面缓存已经预热，加载权重会很快，仅占总体延迟的一小部分：在8B模型的温缓存基线下大约是53秒中的8秒。此时主导因素是引擎初始化：初始化CUDA上下文并捕获计算图，这些步骤不受权重所在位置或传输速度的影响。提供商和用户经常优化模型加载，因为这部分是可见的，但一旦缓存预热，权重加载的改进对总体延迟的影响空间有限。

3. 使用更小的模型是否能显著降低冷启动时间？

在温缓存基线下，答案是否定的，没有显著差异。该基线对模型大小的敏感度有限：0.6B参数大约需要48.6秒，而8B大约需要52.9秒，尽管模型大小增加了十倍以上，但两者仅相差约四秒。原因在于大部分初始化成本是固定的：容器启动、CUDA设置、引擎启动和图捕获。只有模型权重传输这一步骤在更小的模型中会显著减少，而这一步骤在缓存预热后并不是主要瓶颈。

4. 减少加载时间的最有效方法是什么？

预热存储模型权重的操作系统页面缓存。如果必须从冷磁盘读取权重，加载时间大约每 GiB 增加1.42秒。如果权重已经通过页面缓存位于内存中，则增量开销降至大约每 GiB 0.15秒，此外还有固定约5-6秒的加载开销。对于8B模型，相比冷页面缓存读取，利用页面缓存可节省大约18秒。将权重存储在快速本地NVMe上主要有助于提高反复命中缓存的概率。在本文测量的可避免成本中，这是最大的与模型大小相关的杠杆。

5. 无服务器推理实际上能避免冷启动吗？

在此七天样本中，目标模型的池化无服务器推理很好地隐藏了常规冷启动。平台在 3.9 秒内处理了 99% 的合法目标模型探测，显著优于自托管的冷启动基准。冷启动候选非常罕见：在 1,827 个可用样本中只有 11 个，约占 0.60%，而最慢的目标模型候选为 9.3 秒。需要注意的是，由于您参与了资源池，无法按需让系统为您的测试进入冷启动状态；冷启动只能通过在大量样本中观察罕见的慢尾延迟事件来检测。

6. 无服务器在延迟保证方面总是更安全吗？

不。无服务器将您的风险从可预测且可控的事情转变为罕见且不可控的事情。如果您自行托管，完全冷启动会持续缓慢（在这些测试中，8B 配置的中位数约为 157 秒），但您可以通过使用自己控制的温暖池来消除它们。在本样本中，池化无服务器几乎消除了目标模型的所有常规延迟，提供了优秀的中位数和 p99 延迟。然而，您将继承平台的事件尾部：在罕见的模型特定抖动期间，响应可能会不可预测地激增。在此次运行中，流行的控制模型在一天内达到 286.7 秒，而目标模型保持快速。如果您的应用能够容忍偶尔的多分钟异常值，池化无服务器可以工作良好。否则，专用容量或回退策略可能是更安全的选择。

那些几秒钟从来不是一个数字。它有五个阶段，它们随模型大小以不同方式缩放，并且通过不同的工程工作得到修复。测量使形状具体化：自托管的 8B 冷启动在完全冷态时的中位数为 157 秒，在不可降低的底线时为 53 秒。该底线的大部分是固定的引擎初始化成本，没有任何权重加载技巧能够触及，因为大家优化的阶段并不是缓存变暖后占主导的阶段。池化的无服务器平台几乎隐藏了所有这些开销，能够在 4 秒 内处理 99% 的合法目标模型探测，同时悄悄地给你一个你无法控制的罕见尾部：在这七天的样本中，有一天，一个流行模型的回答时间长达 287 秒。

实际决策取决于你更愿意承担哪种尾部风险。自托管为这个 8B 配置提供了可重复的约 157 秒中位数冷启动，这个数字可以通过你管理的温池降低。池化的无服务器在我们探测的模型上提供了低于 4 秒的 p99，此外还伴有你无法预测或修复的偶尔多分钟事件。选择你的工作负载能够承受的一方，并使用五问题清单来让任何提供商的冷启动声明针对特定阶段进行验证。

• The Hidden Cost of Cold Starts in Serverless AI Workloads, DigitalOcean Community. 这篇文章将三步概念性解剖扩展为五个阶段。
• DigitalOcean Serverless Inference: A Deep Dive, DigitalOcean engineering blog. 这是关于冷启动“由权重预暂存、内存可用性和调度速度主导”这一说法的来源，直接针对我们的 Track A 分解进行了测试。
• Fine-tuning the LLM Ornith 9b on a single H200 GPU Droplet, DigitalOcean Community. 这是独立测量的 CUDA 图捕获差距（0.691 秒 对比 ~0.035 秒 TTFT）的来源，证实了我们的 Phase 4 发现。
• How Does Prompt Caching Work and When Does It Actually Cut LLM Costs?, DigitalOcean Community. 这是适用于 Track B 的 TTFT 流式 harness 模式的来源，以及 prompt-caching 与 cold-start 的区分。
• LLM Inference Benchmarking: Measure What Matters, DigitalOcean engineering blog. 采用了 TTFT 定义以保证测量的一致性。