Serverless AI Agent 的冷启动税

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

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

为什么 AI 智能体不同于普通函数

冷启动对于常规的 Serverless 函数来说是可控的。基准数据已经非常成熟：Lambda 上的 Python 3.12 在第 50 百分位数的启动时间为 200-300 毫秒。一个 14 MB 的部署包会将时间推迟到约 1.7 秒。虽然令人不悦，但对于许多用例来说是可以接受的。

AI 智能体打破了这些数字背后的所有假设。Serverless AI 函数的冷启动涉及典型 Web API 处理程序从未遇到的阶段：

1. 容器镜像拉取 —— LLM 推理容器的重量通常在 8-15 GB 之间。即使在快速的内部网络上，拉取一个全新的镜像也需要 10-30 秒。
2. SDK 和依赖项初始化 —— Anthropic Python SDK、OpenAI 客户端、boto3 以及类似的库会导入庞大的依赖树并建立连接池。一个除了导入这些库之外什么都不做的函数，也会给冷启动增加 3-8 秒。
3. 模型权重加载 —— 对于本地推理，FP16 格式的 7B 参数模型大约有 14 GB，必须从存储移动到 GPU 显存中。70B 模型则超过 130 GB。LLaMA-2-70B 从下载到产出第一个 Token 的冷启动时间经测量超过 110 秒。
4. GPU 上下文初始化 —— CUDA 上下文创建、内存池分配和内核编译在权重加载的基础上又增加了 5-15 秒。
5. KV 缓存预热 —— 一些推理服务器在启动时会预分配 KV 缓存块，在系统接受请求之前增加了额外的时间。

生产环境的测量数据直观地说明了这种差距：在一个基准测试中，冷启动的 GPU 实例在 40 多秒后才产生第一个 Token，而热实例产生后续 Token 仅需约 30 毫秒。这是冷热状态之间 1,000 倍的延迟比。对于不运行本地推理的 API 调用型智能体，数字虽然较小，但比例依然成立——热调用在 300 毫秒内完成，而冷调用仅由于 SDK 初始化和 TLS 握手开销就需要 5-10 秒。

三层部署决策

Serverless 并不是单一的选择。在 Lambda、容器和专用实例之间的选择，实际上是一条具有清晰交叉结构的成本与延迟权衡曲线。

Lambda（标准版） 在每日请求量低于约 35,000 次时胜出。在低流量下，按调用付费比保持容器热启动更划算。Lambda 会自动缩减至零，对于 API 调用型智能体（无本地模型），启用 SnapStart 后，优化良好的 Python 函数冷启动时间不到 2 秒。Lambda 不支持 GPU —— Firecracker 微虚拟机架构不支持 PCIe 透传 —— 因此如果本地推理是必需的，无论成本如何，Lambda 都不在考虑范围内。

容器部署（ECS Fargate、Cloud Run、EKS）根据 ML 工作负载基准，在每日请求量超过约 35,000 次时变得更便宜，并且它们提供了显著更好的尾部延迟。在直接对比中，对于相同的 ML 推理工作负载，EKS 的平均延迟比 Lambda 低 48%，且 P99 延迟表现好 3.7 倍。容器支持 GPU 实例，没有超时限制，并能对扩缩容行为提供更多控制。权衡点在于运维复杂性和最小闲置成本。

专用 GPU 实例 对于 70B 级别的模型，在每月 Token 数超过约 5,000 万至 1 亿时具有成本效益。低于这个阈值，一旦考虑到工程开销和利用率不足，托管 API（Anthropic、OpenAI）或专业的 Serverless GPU 平台通常在总成本上胜出。

专业 Serverless GPU 平台（Modal、RunPod、Replicate）填补了 Lambda 无法覆盖的空白。Modal 的 GPU 冷启动在有热容器池的情况下为 2-4 秒，GPU 快照将 vLLM 启动时间从 45 秒缩短至 5 秒。Replicate 对流行的公共模型进行预热，实现了近乎零的冷启动。这些平台按秒计费，并提供自动缩减至零，费率与专用 GPU 计算相当 —— 这与 Lambda 和自管容器相比，是一个真正不同的价值主张。

AI 智能体 Lambda 冷启动剖析

即使是对于不运行本地模型的智能体（这是更常见的情况），冷启动也往往不被充分理解。主要的调节杠杆包括：

包大小和运行时。 1 KB 的 Python Lambda 在 AWS 上启动需要 0.3 秒。35 MB 的包需要 3.9 秒。加上 PyTorch、transformers 或重量级 LLM 客户端库，在你的处理程序运行第一行代码之前，你将面临 8-12 秒的等待。

模块作用域内的 SDK 初始化。 最常见的错误是在处理程序函数内部初始化 SDK 客户端。这样每次冷启动都会重新初始化 Anthropic SDK、建立 HTTP 连接池、验证凭据并建立 TLS。将所有初始化移动到模块作用域（处理程序之外），这样它在每个容器生命周期内只运行一次。对于热调用，这是免费的。对于冷启动，它只发生一次，后续所有请求都会重用已初始化的状态。

Lambda SnapStart（Python 3.12+ 和 .NET 8）在初始化完成后对执行环境进行快照并存储，在冷启动时从快照恢复，而不是重新初始化。在实测基准中，SnapStart 将 Python 冷启动时间缩短了 93-95% —— 以前需要 6.5 秒冷启动的函数降至 415 毫秒。实际限制是：你必须注册钩子，在快照前关闭数据库连接，并在恢复后重新打开，这为具有持久连接的智能体增加了一点复杂性。

VPC 冷启动 过去由于 ENI 分配会增加 10 秒以上的时间。AWS 的 Hyperplane ENI 改进解决了这个问题 —— 现在 VPC Lambda 冷启动运行时间在 1 秒以内。如果你是因为 2024 年之前的冷启动担忧而避开 VPC，那么这种权衡已经发生了变化。

真正有效的缓解模式

通过合成调用进行预热 (Pre-warming via synthetic invocations) 是最老套但有效的招数。通过设置 CloudWatch Events 规则每 5 分钟触发一次，以保持执行环境处于活跃状态（Lambda 通常会在闲置约 5–7 分钟后回收环境）。对于需要多个并发热实例的情况，你需要同时发起 N 个请求，因为 AWS 可能会将所有合成 ping 路由到同一个容器。其局限性在于：这仅在流量水平可预测时奏效。此外，它会增加成本（闲置调用加上预置的计算资源），且对于超出预热池的突发流量无济于事。

预置并发 (Provisioned Concurrency) 是预热的官方托管版本。AWS 会保持 N 个执行环境已初始化并就绪。算一笔账：一个拥有 10 个预置实例的 512MB 函数，每月仅闲置成本约为 15 美元，算上调用费用则会攀升至 30 美元。2025 年 8 月新增的一个重要背景是：Lambda 现在开始对冷启动期间的 INIT 阶段计费。在这一变化之前，一个 512MB 且初始化耗时 2 秒的函数，冷启动成本约为每百万次调用 0.80 美元。调整后，成本飙升至每百万次 17.80 美元。对于那些包含沉重 AI SDK 初始化逻辑的函数，这可能会使 Lambda 成本增加 10–50%，从而使预置并发在处理高流量交互式工作负载时显得更具性价比。

Lambda 托管实例 (Lambda Managed Instances)（在 AWS re:Invent 2025 发布）在你账户中的 EC2 实例上运行 Lambda 函数，包括支持 GPU 的实例。由于执行环境在底层的 EC2 上保持初始化状态，冷启动彻底消失。弊端在于：其扩容速度慢于标准 Lambda（增加容量需要数十秒，而标准版是亚秒级的爆发式扩容），并且你需要在 EC2 实例成本之外额外支付 15% 的计算管理费。这对于持续高吞吐量的工作负载是正确选择，但不适用于突发或不可预测的流量。

Cloud Run GPU 实例 采取了不同的方法。Google 从请求到达的那一刻起按秒计费，在最后一个请求结束后将启用 GPU 的实例保持预热状态长达 10 分钟，并在流量消失时缩容至零。从零到 GPU 驱动就绪的冷启动时间不到 5 秒；对于 gemma3:4b 模型，从真正的冷启动到输出首个 token 的时间 (Time-to-first-token) 约为 19 秒——相比于自托管容器（同等情况下需要 40 秒以上）有了显著提升。

状态管理：Serverless 的另一个难题

冷启动是显性的失效模式，而状态管理则是隐性的。

Lambda 执行环境是无状态的。每次调用都可能落在一个全新的容器上，没有任何关于前几轮对话的记忆。对于执行工具调用循环 (Tool-use loop) 的多步 Agent 来说，这意味着除非显式地将状态外部化，否则每一个后续请求都可能被迫从头开始对话。

实用的架构方案是：将活跃会话状态存储在 Redis 中（实现热状态的亚毫秒级读取），在每次产生副作用的工具调用后将持久化的 Agent 状态写入 DynamoDB 或 Postgres 检查点，并在检查点超过 DynamoDB 的项目大小限制时使用 S3 处理溢出的载荷。核心设计原则是在每一个不可逆的操作（如外部 API 调用或数据库写入）之后进行状态检查点化 (Checkpointing)。这样，如果容器在任务中途被回收，Agent 可以从上一个成功的步骤恢复执行。

Lambda 的 15 分钟执行超时是另一个难点。拥有长工具链的多步推理 Agent 很容易触及这个限制。2025 年 12 月推出的 Lambda Durable Functions 功能直接解决了这个问题：context.step() 为业务逻辑添加了自动检查点和重试机制，而 context.wait() 可以暂停执行长达一年，且在暂停期间不收取计算费用。现在，需要等待人工审批、外部 API 回调或计划重试的 Agent 可以直接实现，而无需编排复杂的 Step Functions 状态机。

Amazon Bedrock 的 AgentCore 运行时 增加了另一个维度：它仅对活跃的 CPU 时间计费，而不会对 Agent 等待 LLM API 响应的秒数计费。如果一个请求中 Agent 花费 1.5 秒进行计算，8 秒等待模型输出，AgentCore 仅收取 1.5 秒的 CPU 费用，而 Lambda 会收取全部 9.5 秒的费用。对于 I/O 密集型的 Agent 循环，这可以将计算成本降低 80% 以上。这里的会话亲和性模型 (Session affinity model) 至关重要：你必须在所有后续请求中包含首次响应的 Session ID，否则每个请求都会路由到新的 MicroVM 并触发全新的冷启动。

将部署模型与工作负载相匹配

决策矩阵可以简化为几个关键维度：

流量模式。 突发或不可预测的流量更适合 Lambda 或容器自动扩缩容。持续的高吞吐量更适合 Lambda 托管实例或专用容器。近乎零流量但偶尔有爆发的需求，正是 Serverless GPU 平台发挥溢价价值的地方。

延迟要求。 如果用户在实时等待响应，任何超过几秒的冷启动都是用户可见的。此时，预置并发、SnapStart 或最小实例保持预热将成为必选项。如果 Agent 是在后台批处理作业中运行，冷启动只是一个分摊成本的考量，而不是用户体验问题。

模型推理位置。 如果你的 Agent 调用云端 LLM API，那么你处于 Lambda 的适用范围内，主要关注的是 SDK 初始化开销。如果你运行本地推理，Lambda 则无法使用，你需要在专门的 Serverless GPU 平台（适用于中低流量）和自托管 GPU 容器（适用于高流量或严苛的延迟要求）之间做出选择。

会话状态性。 无状态 Agent（即每个请求都包含所有必要上下文）能完美契合 Serverless 模型。有状态的多轮对话 Agent 需要显式的会话存储基础设施；状态模式 (Schema) 越简单，运维复杂度就越低。

做得出色的工程师不会试图将 AI Agent 强行套入传统的 Lambda 思维模型。他们会审计实际的冷启动成本，衡量现实流量下的冷热比，并选择能让冷启动变得稀缺（通过最小实例）、快速（通过 SnapStart）或无关紧要（通过批处理工作负载）的基础设施。而那些失败的人，往往是在生产环境中通过用户对“每天第一个请求太慢”的投诉，才发现冷启动带来的“隐形成本”。