Wire 迁离 Cloudflare Durable Objects，性能变快只是故事的一半
作者：林岚｜OC 技术编辑
林岚
据 Wire 工程博客，这家为 AI 代理提供“上下文容器”的公司，正在把核心数据平面从 Cloudflare Durable Objects 迁到基于 Fly Machines、Bun、SQLite 和 sqlite-vec 的自建运行时。迁移后，热调用从约 0.4 秒且偶有 2 秒以上尖峰，变为约 0.3 秒；空闲容器恢复时间从 3.7 秒降至 1.4 秒。
一句话结论：Wire 不是因为 Durable Objects 不可靠才离开，而是它需要向量索引与数据同进程、计算靠近数据、租户级隔离和私有部署；代价是原来平台免费提供的一致性与持久化，现在都要自己重新实现。
Wire 的一个容器保存处理后的知识、embedding、来源关系图，并通过 MCP 提供查询。过去每个容器就是一个 Durable Object。这个模型很适合大量小型、长时间空闲的有状态单元：创建快、单写者一致性清楚、存储自动复制，开发团队不必自己管理机器。
问题出在向量检索。embedding 放在独立的 Cloudflare Vectorize 服务里，查询最热路径多一次网络跳转，也多一份可能发生偏差的状态。Durable Objects 内置 SQLite 又不能加载扩展，sqlite-vec 无法直接放进去。检索、融合、扩展和 rerank 只好散在多个服务之间，代理每次工具调用都要承担延迟波动。
新架构给每个组织分配一个 Bun 主进程，容器变成带内嵌向量索引的 SQLite 文件，候选检索在进程内完成；模型调用、query embedding 和 rerank 仍然使用外部推理服务。快照进入对象存储，区域路由器把容器放到调用者附近，付费租户还可以获得独立进程和机器。
这些收益并非没有水分。Wire 很坦率地说，recall@5 从 78.1% 提高到 89.1%，不全是新架构的功劳，因为迁移时也更换了 embedding 模型。3.7 秒的旧恢复时间也不是 Durable Objects 自身冷启动，Cloudflare isolate 通常毫秒级唤醒，慢的是 Wire 自己的软件栈重建。
更关键的代价发生在持久化。Durable Objects 会在确认写入前复制存储；Wire 第一版自建运行时只保证“下次 checkpoint 后持久”，压力测试杀掉机器时，已经向客户端确认的少量写入会丢失。团队最后增加持续 WAL 传输：只有日志帧进入对象存储后才确认，group commit 把额外延迟控制在约 100 毫秒。
所以这不是一篇“逃离 Cloudflare”的胜利宣言。Wire 的 API、前端、控制平面和处理流程仍留在 Workers。它甚至明确建议：如果你不需要索引同置、位置迁移、独立租户和自托管，就继续使用 Durable Objects。平台抽象并没有失败，只是产品需求越过了抽象边界。
关键事实
- Wire 只迁移核心容器数据平面，其他大量服务仍运行在 Cloudflare。
- 新架构使用 Fly Machines、Bun、SQLite 与内嵌
sqlite-vec。 - 热调用约 0.3 秒，空闲恢复约 1.4 秒；旧值分别约 0.4 秒和 3.7 秒。
- 检索提升同时受到 embedding 模型更换影响，不能全部归因于架构。
- 自建后必须通过持续 WAL 传输重新获得已确认写入的持久性。
OC 判断
这是一次成熟的“什么时候该离开托管平台”案例：不是账单一贵就重写，也不是看到 benchmark 变快就宣布胜利，而是确认产品需要的平台能力确实无法获得，并承认迁移后买回了哪些复杂性。
为什么重要
- 开发者：架构 benchmark 必须控制模型、数据和算法变量，否则性能结论会混入其他改动。
- 企业：自托管和租户隔离可能迫使产品拥有数据平面，但一致性、备份和故障恢复成本也随之转移。
- 用户：服务迁移后接口可以完全不变，真正变化的是数据落在哪里、故障时能否恢复。
评论
围绕这篇文章补充信息、提出问题或分享观察。