温池与冷真相：Serverless LLM 推理中隐藏的延迟底线

将你的 GPU 推理自动缩放至零（Autoscaling to zero）看起来是显而易见的成本控制策略。GPU 是账单中最昂贵的项目，流量具有突发性，而空闲时间纯粹是浪费。所以你开启了缩放至零（scale-to-zero），看着云端账单下降，并以此自得。

然而，在一段沉寂之后，一位用户出现了，他们的第一次请求需要 60 秒才能返回一个 token。运行 Serverless LLM 推理的生产部署经常报告冷启动超过 40 秒才出现第一个 token —— 相比之下，模型预热后的每个 token 延迟大约仅为 30 毫秒。这是冷路径和热路径之间千倍的延迟差距，而这完全取决于你的流量空闲情况。

这是没有人会写在 PPT 上的权衡。缩放至零并没有消除成本；它将稳定的金钱成本转化为了突发性的延迟成本，然后将这种延迟成本隐藏在仪表盘很少关注的 p99 尾部。

这种情况比你已经了解的 Serverless 冷启动更糟糕的原因是结构性的。无状态函数的冷启动涉及容器拉取和运行环境启动 —— 耗时几百毫秒到几秒。LLM 冷启动不仅包含这些，还包括将模型权重移动到 VRAM、CUDA 上下文初始化、算子编译（kernel compilation）和 CUDA 图捕获（CUDA graph capture），以及 KV 缓存分配。模型权重不是冷状态的副作用。模型权重本身就是冷状态。你无法通过懒加载（lazy-load）来解决 16 GB 检查点带来的问题，因为这个检查点正是请求所需要的。

冷启动剖析

当 Serverless 平台从零开始扩展一个 GPU 工作节点时，用户的请求会被阻塞在由一系列顺序阶段组成的流水线之后：

• GPU 分配与调度。 平台寻找物理 GPU，挂载它，并将你的容器调度到上面。在繁忙的区域，仅这一步就需要排队。
• 容器拉取与启动。 你的镜像 —— 在内置了 CUDA、PyTorch 和推理服务后通常有几个 GB —— 被获取并启动。
• 权重获取。 模型检查点从对象存储或网络卷读取到主机内存中。对于半精度的 70B 级模型，这涉及超过 100 GB 的传输。
• 权重加载到 VRAM。 主机内存通过 PCIe 总线复制到 GPU。
• 预热。 CUDA 上下文创建、如果你使用了 torch.compile 则需要编译、算子自动调优、CUDA 图捕获以及 KV 缓存预分配。

这里的关键属性是，这些阶段大多是顺序进行的，并且由其中一项主导。对于大型模型，权重移动压倒了其他一切。这既是好消息也是坏消息。坏消息：你无法通过优化微小的阶段来获得显著的收益。好消息：只有一个值得攻克的瓶颈，而所有的缓解工具包都针对它。

没有人诚实建模的成本与延迟边界

在寻求缓解措施之前，先算算账，因为诚实的计算会让许多缩放至零的部署胎死腹中。

缩放至零是一场赌博，赌的是节省的空闲成本超过了产生的延迟成本。空闲成本显而易见：它是 GPU 小时单价乘以原本不被使用的小时数。延迟成本则更难衡量，因为它由用户而非财务团队支付，并且表现为用户流失和差评，而不是账单上的条目。

存在一个盈亏平衡的流量率，但大多数团队从未计算过。逻辑很简单：如果你的请求到达间隔足够长，以至于平台在两次请求之间缩减了规模，那么每一个请求都是冷启动。考虑一个实际推理需要 5 秒但冷启动需要 30 秒的工作负载：85% 的挂钟时间 —— 以及你支付的 85% 的 GPU 计费时长 —— 都花在了等待而不是处理上。你并没有在省钱。你是在为“慢”这一特权支付溢价。

2025–2026 年生产实践中总结出的普遍指导意见非常直接：如果你的平均 GPU 利用率超过大约 40–50%，那么专用的常驻容量不仅比 Serverless 更快，而且更便宜。Serverless 适用于真正的突发性或零散工作负载 —— 如内部工具、批处理任务、尚在寻找产品与市场匹配度（product-market fit）的新功能 —— 这些场景下空闲时间占主导，且偶尔的冷启动是可以容忍的。对于稳定的、对延迟敏感的流量，它表现极差，而这正是面向用户的聊天或语音产品所产生的流量。

加载中…