生产级智能体的 90 秒冷启动：当 LLM 不再是瓶颈时

用户点击按钮。90 秒后，他们才收到第一个 token。团队的反应几乎是条件反射式的，即要求模型厂商提供更快的 TTFT —— 而厂商的 TTFT 其实只有 800 毫秒。模型从来都不是慢的那一部分。请求花了 30 秒等待工具注册表（tool registry）加载，20 秒等待向量数据库客户端协商首次连接，15 秒用于新鲜容器上的 Prompt 缓存预热，还有 10 秒让智能体框架针对一个初次使用的 JSON Schema 校验器验证注册表中的每个工具模式（tool schema）。

这就是智能体冷启动，它几乎与模型无关。仅对 LLM 调用进行性能分析的团队是在优化请求中本就不慢的部分。更糟糕的是，冷启动在稳态下是不可见的 —— 针对热池（warm pool）的负载测试结果看起来很棒，中位数指标图表看起来也很棒，只有那些在部署、自动扩缩容事件或因低流量导致资源回收后触发首个请求的用户才会察觉到问题。

这种模式的一致性足以使其成为一门独立的学科。“智能体延迟”分解后的组件远比模型调用多，而且每个组件都有冷启动成本，并与其他组件叠加。修复方法不是单一的优化，而是在第一次冷启动发生前做出的一系列架构选择，因为发现这些问题的时机不该是在凌晨 3 点的生产环境中。

智能体冷启动剖析

在新节点上的容器化智能体会执行一段启动序列，而这段序列并非由任何单个工程师进行过端到端的系统设计。每个组件在孤立状态下都是合理的；但它们的组合却造成了巨大的性能损失。

容器镜像拉取。对于一个典型的包含嵌入模型权重、嵌入库和框架依赖项的智能体镜像，其大小可能达到 8–15 GB。标准容器注册表并非为这种吞吐量设计的；受限于镜像拉取的冷启动往往占据了时间预算的大部分，仅拉取阶段就可能在运行时启动前耗费 30–60 秒。

运行时初始化。模型客户端连接到提供商，协商身份验证，获取可用模型，并预热其 HTTP 连接池。如果智能体使用本地嵌入模型，该模型会加载到内存或 VRAM 中 —— 小型嵌入模型需要 2–5 秒；大型重排序器（reranker）则需要 15–30 秒。在从第一个用户请求开始计时的链路追踪工具中，这些都不会显示出来。

工具注册表实例化。现代智能体在启动时发现工具：MCP 服务器连接、函数调用注册、Spring Bean 注册过程。每个工具都带有一个 JSON Schema，需要进行解析和验证。最近对生产环境中 MCP 服务器的基准测试发现，模式验证问题占所有可靠性故障的 38%，而且验证工作本身也不容小觑 —— 工具调用的中位数延迟为 320 毫秒，但 P95 飙升至 1,840 毫秒，P99 更是达到 6,200 毫秒。一个拥有 50 个工具且在首次请求时进行串行验证的注册表，在智能体考虑调用什么之前，就可能耗费 10–15 秒。

向量数据库句柄建立。一旦预热，针对具有 HNSW 索引的 pgvector 的第一次查询仅需 5–8 毫秒 —— 但第一次连接需要协商 TLS、进行身份验证，在托管服务上还可能触发自身的无服务器预热，从而增加 200–800 毫秒。Pinecone 在稳态下每条查询会增加 10–20 毫秒的网络延迟，但冷连接则会耗费 1–3 秒。在低流量下因空闲而超时的连接池会在下一个请求中重新支付这一成本。

Prompt 缓存预热。Anthropic 的 Prompt 缓存默认 TTL 为 5 分钟，扩展 TTL 为 60 分钟。大型系统提示词的缓存创建需要 2–4 秒，成本是普通写入的 1.25 倍。一个在新鲜容器上发起 10 个并行请求的朴素实现会产生 10 次缓存写入、0 次缓存读取，产生的账单是预测值的 5–10 倍。对于那些在预热前就进行并行的团队，测得的命中率低至 4%。

综上所述。一个在新鲜容器上调优不佳的智能体可能需要 60–120 秒才能响应第一个用户请求，在此期间，链路追踪没有显示任何内容，因为追踪是在初始化完成后才开始的。

为什么分析 LLM 会忽略大部分问题

流行智能体框架中内置的默认检测工具测量的是模型延迟、工具调用延迟和端到端请求延迟。它们默认不测量从容器启动到第一个请求就绪之间的时间。它们不测量模式验证时间、嵌入模型加载时间或下游服务的首次连接延迟。它们在请求到达时才开始计时。

这是一种具有运维后果的测量偏差。工程团队在每日站会中审阅的仪表盘显示的是稳态延迟 —— 这没问题，因为大多数用户看到的就是稳态延迟。但“大多数用户”并不等同于“在推特上发布截图的用户”。冷启动尾部存在于不同的分布中：它不是请求延迟直方图的长尾，而是一个仅在特定条件下（部署、扩容事件、超过缓存 TTL 的流量间隙）触发的独立模式。

修复方法不是更激进的数据聚合，而是一个独立的指标。将冷启动延迟（定义为从容器启动到第一个请求就绪的实际时间）视为一等公民 SLO。为其配置告警。在仪表盘中将其与 TTFT 并列显示。在 CI 中针对新鲜容器运行该指标，而不是针对已经运行了数小时的热分段（staging）环境。

针对该指标的一个有用分解：镜像拉取时间、运行时初始化时间、框架初始化时间、下游预热时间（嵌入模型、向量数据库、Prompt 缓存）以及首个请求就绪时间（time-to-first-ready）。其中每一个都有不同的修复方法，将它们混为一谈只会确保错误的修复被优先处理。

隐藏延迟的模式

一旦指标确立，工程工作就变得清晰可见。这其中并没有什么新鲜事 —— 这些模式源于十年来的 serverless 和 FaaS 工作 —— 但 LLM 生态系统在应用这些模式方面一直进展缓慢。

与流量挂钩的热池（Warm-pool）规模。 解决冷启动最廉价的方法就是避免它的发生。维持一个预热好的副本池，其规模应根据 95 百分位（P95）的突发流量而非中位数来确定。成本模型非常直观：边际闲置计算成本 vs. 用户在负载下感知到的冷启动延迟。对于聊天产品，计算结果几乎总是倾向于维持热池。而对于每六小时运行一次的批处理智能体（agent），缩减至零（scale-to-zero）则完全没问题。

首次使用时实例化的延迟工具注册。 如果一个工具注册表在启动时串行验证 50 个 schema，那么它是在为该请求中可能永远不会用到的能力买单。延迟注册会根据需求解析工具定义，第一次调用承担验证成本，后续调用则命中缓存。权衡之处在于每个工具的首次调用会变慢；而收益在于冷启动在几秒钟内即可完成，而不是几分钟。

容器镜像的快照与恢复。 这是影响最大但采用最少的技术。CRIU（Checkpoint/Restore In Userspace）允许你对已经加载了模型、建立了连接并填充了缓存的容器进行快照 —— 然后在下次冷启动时从快照恢复。ServerlessLLM 的测量结果显示，对于 OPT-2.7B，这种方法比 PyTorch 快 6 倍，比 safetensors 快 3.6 倍；对于 LLaMA-2-70B 则快 8.2 倍。对于那些启动成本主要由 Python 导入和 JSON schema 解析构成的重框架型智能体，同样的技术可以在无需 GPU 特性的情况下提供类似的收益。

粘性路由以保持热副本持续提供服务。 一旦副本变热，处理下一个请求最廉价的方式就是将其路由回该副本。前缀缓存感知路由（Prefix-cache aware routing）—— 如 llm-d v0.5 等项目中所实现的 —— 将请求保留在 KV 缓存中已有所需提示词前缀的副本上，从而实现比轮询（round-robin）高出数量级的 TTFT 降低。同样的逻辑也适用于更高层级：将用户的后续请求路由回已经拥有其会话上下文（session context）的热副本，即使该副本的负载比冷副本稍高一些。

在并行任务之前进行专门的缓存预热。 特别是对于提示词缓存（prompt caching），规则是“先预热，再并行分发”。通过设置 max_tokens=0 和静态前缀调用 prewarm_cache() 来建立缓存条目；后续请求则读取该条目。如果没有预热调用，并行请求会竞相写入同一个缓存条目，每个请求都在为创建缓存付费，导致部署后的第一分钟内命中率几乎跌至零。

捕获延迟的评估规范

评估（Evals）已经吸取了教训，即质量回退需要预部署门禁。冷启动回退也需要同样的对待，但几乎没有团队将冷启动测试作为 CI 的一部分。

一个有用的 CI 门禁（CI gate）是这样的：在测试环境中启动一个全新的容器，发送一个具有代表性的单次请求，测量从容器启动到响应完成的实际时间（wall clock），如果超过阈值则使构建失败。不是负载测试中的 P95 —— 而是单次的冷启动测量。方差会有波动，因此请使用多次运行的中位数，并设置一个足够宽的阈值来吸收波动，但也要足够严格以捕获 30 秒级的回退。

这种评估捕获的模式正是生产追踪容易忽略的：一个新的依赖项增加了 8 秒的导入时间，一个工具注册表从 30 个条目增长到 80 个且现在序列化时间变长，一个向量数据库客户端切换到了需要 600ms 协商的 TLS 配置，或者一个嵌入模型升级到了更大的变体。在稳态下，这些都是不可见的，但在全新的容器上却显而易见。

同样的评估应该在每次依赖升级后运行，而不不仅仅是在代码更改时。依赖升级是大多数冷启动回退的源头，因为大多数依赖并不会标榜它们的启动成本 —— 而升级 Python 框架的团队很少会去测量该框架的导入时间在新的次要版本中是否增加了 5 秒。

将冷启动视为头等大事后会发生什么

随之而来的架构认知是：智能体运行时是一个操作系统，而不是一个函数。它有启动序列、稳态和关机过程。启动序列是用户在任何中断后的首次请求中所能感受到的部分 —— 对于具有正常流量模式的服务来说，这种情况每天会发生很多次。

内化了这一点的团队不再将智能体延迟视为单一的数字。他们拥有稳态 TTFT（模型供应商的数值，加上几百毫秒的路由时间）。他们拥有冷启动延迟（全新容器提供首次服务所需的实际时间）。他们拥有恢复延迟（在下游波动后恢复服务所需的时间）。每一项都有自己的 SLO、自己的仪表板和自己的工程负责人。

构建智能体基础设施的供应商正开始交付正确的原语 —— 框架层级的快照/恢复、路由层级的前缀缓存感知路由、编排层级的带有热池回退的缩减至零。但是，衡量冷启动、将其视为问题并将其纳入 CI 门禁的规范，是每个团队必须为自己建立的。如果不具备这种规范就发布功能，那么团队发布的并不是一个慢速智能体 —— 而是发布了一个其“最糟糕时刻”在被用户发现之前一直处于不可见状态的智能体。

模型很少是缓慢的部分。只对 LLM 进行性能分析的团队是在优化错误的系统。