1. 延迟预算
这篇文章我们要讨论部署方案的选择
用户发出一条消息后，系统通常需要完成下面这些工作：
| 环节 | 耗时范围 |
|---|---|
| 网络往返（用户 ↔ 服务器） | 50 - 500ms |
| 安全检查 | 10 - 30ms |
| 记忆检索（向量搜索 + 关键词匹配） | 30 - 100ms |
| 情绪状态读取 | 5 - 15ms |
| Prompt 组装 | 5 - 10ms |
| LLM 推理（首 Token） | 500 - 2000ms |
| 记忆写回 | 20 - 50ms |
在流式输出场景中，用户最直接感受到的是首字节时间（TTFB），也就是从发送消息到看到第一个字出现的间隔。比较理想的等待时间是 1-2 秒；超过 3 秒，等待感会变得明显；超过 5 秒，用户很可能直接离开页面。
LLM 生成首个 Token 通常需要 500-2000ms，这部分时间很难由应用层直接压缩，因此留给安全检查、记忆检索、状态读取和 Prompt 组装的预算并不宽裕。如果一次网络往返就占用 300ms，整条链路几乎没有调整空间。
所以，部署架构要解决的问题很明确：既然 LLM 推理时间不可控，就要尽可能缩短其余环节，尤其是网络传输时间。最直接的办法，就是把计算放到离用户更近的位置
2. 边缘计算
传统云计算会把用户请求发送到某个固定的数据中心，等待服务器处理完成后，再通过公网返回结果。无论应用代码如何优化，只要用户与数据中心相距很远，物理距离产生的延迟就无法完全消除。
以北京用户访问美国数据中心为例，光纤传输速度约为 20 万公里/秒，北京到美国的直线距离约为 1 万公里。只计算传播时间，单程物理延迟已经达到：
10000÷200000=50ms
这还没有包含路由跳转和协议握手。进入真实网络后，一次请求的往返延迟通常会达到 200-500ms。
边缘计算的思路并不复杂：既然距离是延迟的重要来源，就把可执行的代码部署到用户附近。以 CloudFlare 为例，它在全球 120 多个国家部署了超过 310 个边缘节点。用户发起请求后，DNS 会自动把请求路由到附近的节点。北京用户不再跨越太平洋访问美国数据中心，而是在邻近节点完成处理，往返延迟可以缩短到 30-50ms
边缘平台首先解决的是全球分布问题。同一份代码会被部署到各个边缘节点，不需要为不同区域分别维护一套应用。开发者只需完成一次发布，平台便会把代码分发到全球节点。
它通常也采用 Serverless 运行方式。服务器配置、扩缩容和节点分发都由平台负责，应用按照实际请求量计费，没有请求时不会产生计算成本。
传统 Serverless 平台的冷启动可能需要几百毫秒，极端情况下甚至要等待数秒。边缘函数一般运行在 V8 Isolates 之类的轻量级环境中，冷启动通常可以控制在 5ms 以内。
除此之外，边缘平台还支持数据本地化。开发者可以根据业务和合规要求，指定数据存储的地理区域，以处理 GDPR、数据出境等问题。
3. 集群部署与边缘部署
理解边缘计算的基本原理之后，我们再从整体架构上比较集群部署和边缘部署
集群部署是常见的后端架构。所有请求先到达负载均衡器，再被分发给多台应用服务器；这些服务器共享集中式数据库，并通过 API 调用 LLM。负载均衡器、应用服务、数据库和相关依赖通常集中在同一个区域。
这种架构已经非常成熟，团队容易理解，开发和调试也比较方便。如果需要自建模型，集中管理 GPU 集群同样更简单。
它的问题也来自集中部署：无论用户在哪里，请求最终都要前往同一个区域。如果服务器位于美国，中国用户每发送一条消息，都要经历一次跨洋网络往返。
边缘部署会先把用户请求路由到最近的节点。安全检查、记忆检索和 Prompt 组装可以直接在该节点完成。对于计算量较小的模型，推理也可以留在边缘；如果使用大模型，则由边缘节点把请求发送到最近的推理集群。与此同时，分布式存储负责让需要的数据能够就近读取。
| 指标 | 集群部署 | 边缘部署 |
|---|---|---|
| 网络延迟（TTFB） | 100-500ms | 30-50ms |
| 推理 |