2 篇博文 含有标签「serverless」

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

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

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

一个带有精简 Python 处理程序的标准 Lambda 函数冷启动大约需要 250 毫秒。而你的 AI 智能体，在调用相同的运行时并添加了一些 SDK 导入后，冷启动需要 8-12 秒。如果再加上本地模型推理，时间将达到 40-120 秒。第一个触发已缩容部署的用户，在智能体响应之前需要等待一条电视广告的时间。这种差距——不是单次推理 Token 的延迟，也不是吞吐量，而是初始启动成本——正是大多数 Serverless AI 部署在用户体验上悄然失败的原因。

这个问题并非 Serverless 所特有，但 Serverless 让它变得显而易见。当你在常驻（always-on）基础设施上运行智能体时，你是在为闲置容量付费，且冷启动永远不会发生。当你为了降低成本而采用缩减至零（scale-to-zero）的策略时，每一个低流量时期都成为了等待下一个请求的陷阱。