2. 从云计算到边缘计算

传统云计算会把用户请求发送到某个固定的数据中心，等待服务器处理完成后，再通过公网返回结果。无论应用代码如何优化，只要用户与数据中心相距很远，物理距离产生的延迟就无法完全消除。

以北京用户访问美国数据中心为例，光纤传输速度约为 20 万公里/秒，北京到美国的直线距离约为 1 万公里。只计算传播时间，单程物理延迟已经达到：

这还没有包含路由跳转和协议握手。进入真实网络后，一次请求的往返延迟通常会达到 200-500ms。

边缘计算的思路并不复杂：既然距离是延迟的重要来源，就把可执行的代码部署到用户附近。以 CloudFlare 为例，它在全球 120 多个国家部署了超过 310 个边缘节点。用户发起请求后，DNS 会自动把请求路由到附近的节点。北京用户不再跨越太平洋访问美国数据中心，而是在邻近节点完成处理，往返延迟可以缩短到 30-50ms。

边缘计算的特点

边缘平台首先解决的是全球分布问题。同一份代码会被部署到各个边缘节点，不需要为不同区域分别维护一套应用。开发者只需完成一次发布，平台便会把代码分发到全球节点。

它通常也采用 Serverless 运行方式。服务器配置、扩缩容和节点分发都由平台负责，应用按照实际请求量计费，没有请求时不会产生计算成本。

传统 Serverless 平台的冷启动可能需要几百毫秒，极端情况下甚至要等待数秒。边缘函数一般运行在 V8 Isolates 之类的轻量级环境中，冷启动通常可以控制在 5ms 以内。

除此之外，边缘平台还支持数据本地化。开发者可以根据业务和合规要求，指定数据存储的地理区域，以处理 GDPR、数据出境等问题。

3. 集群部署与边缘部署

理解边缘计算的基本原理之后，我们再从整体架构上比较集群部署和边缘部署。

3.1 集群部署

集群部署是常见的后端架构。所有请求先到达负载均衡器，再被分发给多台应用服务器；这些服务器共享集中式数据库，并通过 API 调用 LLM。负载均衡器、应用服务、数据库和相关依赖通常集中在同一个区域。

这种架构已经非常成熟，团队容易理解，开发和调试也比较方便。如果需要自建模型，集中管理 GPU 集群同样更简单。

它的问题也来自集中部署：无论用户在哪里，请求最终都要前往同一个区域。如果服务器位于美国，中国用户每发送一条消息，都要经历一次跨洋网络往返。

3.2 边缘部署

边缘部署会先把用户请求路由到最近的节点。安全检查、记忆检索和 Prompt 组装可以直接在该节点完成。对于计算量较小的模型，推理也可以留在边缘；如果使用大模型，则由边缘节点把请求发送到最近的推理集群。与此同时，分布式存储负责让需要的数据能够就近读取。

3.3 指标对比

3.4 LLM 推理放在哪里

选择部署方式之前，还要确认 LLM 推理究竟在哪一层完成。不同的推理策略，对基础设施的要求并不相同。

方案 A：调用第三方 LLM API。 使用 DeepSeek、GPT 或 Claude 时，模型并不运行在自己的服务器上。应用服务只负责检索记忆、组装 Prompt 和转发请求等调度工作。这些任务计算量较小，很适合放在边缘函数中，节省下来的网络时间也能直接改善响应速度。

方案 B：自建 GPU 集群。 如果使用自己的服务器运行开源模型，GPU 资源会成为架构的核心，集中式集群更适合承载推理任务。不过，安全检查、记忆检索和请求调度仍然可以放在边缘，最终再回源到 GPU 集群。

方案 C：使用边缘 AI 推理。 Workers AI 一类服务可以直接在边缘节点运行模型，延迟最低。不过，它当前主要提供 Llama、Mistral 等中小模型，模型选择比较有限，生成质量也可能不如顶级闭源模型。

对于大多数 AI 伴侣项目，比较务实的起步方案是第三方 LLM API 加边缘调度，原因主要有四点：

1. 安全检查、记忆检索和 Prompt 组装都是轻量 CPU 任务，适合边缘运行。
2. 网络延迟可以减少 200-400ms，对实时对话的体验有直接影响。
3. LLM API 请求从边缘节点发出时，通常比用户端直接访问更快，因为边缘节点与 API 提供商之间往往有专线连接。
4. 服务器、扩缩容和基础运维都交给平台处理，可以显著降低维护成本。

4. AI 伴侣为什么需要边缘部署

并不是所有应用都必须运行在边缘。后台管理系统、CMS，甚至普通 ChatBot 使用集群部署通常已经足够。AI 伴侣更依赖边缘部署，是因为它的交互方式对延迟、访问频率和用户分布都有不同的要求。

4.1 对话延迟会影响情感连接

代码助手、翻译工具等任务型应用通常允许用户等待 2-3 秒，因为用户知道系统正在处理一项明确任务。AI 伴侣模拟的却是即时对话。发送消息后，如果对方迟迟没有开始回复，用户很容易把等待理解为对话中断。

因此，延迟影响的不只是处理效率，还会削弱情感沉浸。等待时间越长，用户越容易意识到对面是一个 AI 系统。

4.2 高频短消息会放大等待感

AI 伴侣的消息通常很短，平均每条 20-50 个字，但一天可能产生 50-200 条消息，而且每一条消息都要经过完整的处理链路。

代码助手的交互方式有所不同。用户通常会提交几百到几千 Token 的代码，并等待一个相对完整的答案。单次等待可以更长，但调用频率更低。

在高频对话中，网络延迟会被反复感知。假设每条消息多等待 300ms，一天发送 200 条消息，就会累计增加 60 秒等待时间。即使用户不会计算这个数字，也会明显感觉系统反应迟缓。

4.3 全球用户不能只靠选择区域

如果用户集中在一个城市，把服务器部署在附近即可。AI 伴侣产品往往面向不同语言和时区的用户，只选择一个区域，很难同时兼顾所有人的访问速度。

集群架构也可以采用多区域部署，但每个区域都要维护独立服务，数据库需要跨区域同步，部署和运维流程也会随之变复杂。边缘部署则把这部分工作交给平台：代码发布一次，全球 310+ 节点同时生效，用户会被自动路由到附近的节点。

4.4 流量具有明显的时间规律

AI 伴侣的使用量通常会在晚上 9 点到凌晨 1 点达到高峰，白天工作时间则进入低谷。传统集群需要按照峰值提前配置资源，低谷期仍然会保留一部分闲置容量。

边缘平台按照实际请求计费，没有请求时不会产生计算成本，因此更适合这种波峰和波谷差异明显的业务。

5. CloudFlare Workers 实践

在第一篇文章中，我们已经确定服务接口层使用 Hono.js，并部署到 CloudFlare Workers。下面继续看推理和记忆检索如何落到边缘环境中。

5.1 边缘推理

CloudFlare Workers AI 提供了可直接调用的 LLM 推理能力，支持 Llama、Mistral、Gemma 等开源模型：

01
export default {
02
  async fetch(request, env) {
03
    const { message, systemPrompt } = await request.json()
04

05
    // 边缘节点上直接运行 LLM 推理
06
    const response = await env.AI.run(
07
      '@cf/meta/llama-3.1-8b-instruct',
08
      {
09
        messages: [
10
          { role: 'system', content: systemPrompt },
11
          { role: 'user', content: message }
12
        ],
13
        stream: true  // 流式输出，进一步降低首字节时间
14
      }
15
    )
16

17
    return new Response(response, {
18
      headers: { 'content-type': 'text/event-stream' }
19
    })
20
  }
21
}

Workers AI 比较适合安全分类、情绪识别和意图判断等轻量级推理任务。如果核心对话对生成质量要求较高，仍然可以调用 DeepSeek 或 Claude 的 API。

5.2 边缘存储

CloudFlare 提供了三种可以互相配合的边缘存储服务，分别覆盖会话状态、结构化数据和向量记忆。

KV（键值存储）适合保存当前会话上下文、情绪状态和用户在线状态等热数据。这些数据需要毫秒级读取，KV 会在全球自动复制，因此读取延迟很低。

D1（SQL 数据库）是兼容 SQLite 的关系型数据库，可以存储用户档案、对话记录和攻略进度等需要复杂查询的结构化数据。

Vectorize（向量数据库）用于保存记忆的向量表示，并提供相似度搜索能力，适合完成语义检索。

5.3 边缘记忆检索

把 Workers AI、Vectorize、D1 和 KV 组合起来，就可以在边缘节点完成一套完整的记忆检索流程：

01
export default {
02
  async fetch(request, env) {
03
    const { userId, query } = await request.json()
04

05
    // 1. 将用户消息向量化（边缘完成）
06
    const embedding = await env.AI.run(
07
      '@cf/baai/bge-base-en-v1.5',
08
      { text: query }
09
    )
10

11
    // 2. 向量检索：找到语义最相关的历史记忆
12
    const vectorResults = await env.VECTORIZE.query(
13
      embedding.data[0],
14
      { topK: 5, filter: { userId } }
15
    )
16

17
    // 3. 从 D1 拉取记忆的完整内容
18
    const memoryIds = vectorResults.matches.map(m => m.id)
19
    const memories = await env.DB.prepare(
20
      `SELECT content, created_at, importance
21
       FROM memories WHERE id IN (${memoryIds.map(() => '?').join(',')})
22
       ORDER BY importance DESC`
23
    ).bind(...memoryIds).all()
24

25
    // 4. 从 KV 读取当前情绪状态
26
    const emotionState = await env.KV.get(
27
      `emotion:${userId}`, 'json'
28
    )
29

30
    return Response.json({
31
      memories: memories.results,
32
      emotion: emotionState
33
    })
34
  }
35
}

从消息向量化、语义检索、数据库查询到状态读取，整个过程都在边缘节点完成，不需要回源到中心数据中心，总耗时可以控制在 50-100ms 以内。

6. 总结

边缘部署并不适合所有业务，但它可以解决 AI 伴侣最敏感的网络延迟问题。在 LLM 推理时间很难继续压缩的情况下，边缘节点能够为安全检查、记忆检索和 Prompt 组装争取更多预算。对于追求实时对话体验的产品，200-400ms 的差距足以让用户感受到响应是否流畅。

具体选择哪种部署方式，可以根据当前业务条件判断：

本专栏的实战项目会使用 CloudFlare Workers 全家桶作为基础设施。Workers 每天提供 10 万次免费请求，D1 有 5GB 免费存储，KV 提供 10 万次免费读取，足够支持 MVP 阶段的验证。

它不需要自行管理服务器、配置自动伸缩或处理证书，代码发布一次即可在全球 310+ 节点生效。计算层有 Workers，存储层有 KV、D1 和 Vectorize，推理层还有 Workers AI，整个技术栈可以在同一套平台内完成。

当产品需要更强的推理能力或更大的处理规模时，再逐步加入集中式集群，形成边缘调度与区域推理结合的混合架构。这样可以保留早期架构，也能以较低风险逐步扩展。