• 主页
  • 架构
  • 编程语言
  • 数据存储
  • 网络
  • VMware
  • 服务器
  • 组网
  • AI
  • 算法系列
  • 设计模式
  • 读书笔记
  • 思考
  • 工具
  • 其它技术

  • 主页
  • 架构
  • 编程语言
  • 数据存储
  • 网络
  • VMware
  • 服务器
  • 组网
  • AI
  • 算法系列
  • 设计模式
  • 读书笔记
  • 思考
  • 工具
  • 其它技术

Local-First 与 Cloud-First:场景决定选择

2026-07-09

前些日子和一个朋友聊架构方向,聊到了 Local-First 和 Cloud-First 两种模式。所谓 Local-First 和 Cloud-First,核心区别在于 Agent 执行层、数据层、RAG、Gateway 这些模块是放在客户端还是服务端。

当时我强烈站队 Cloud-First。现在想想,还是眼界窄了——模式好不好,和场景强相关。

image-20260704204852495

为什么我站 Cloud-First

我是服务端研发,天然的设计理念是服务端重、客户端轻。不是因为觉得服务端了不起(我身边好多大前端同事都非常厉害),主要是因为逻辑落在服务端,迭代速度和问题修复都能快速进行。

只要架构设计合理,产品优化、线上问题只需要服务端改完就能生效。否则就要等客户端发版,发版又涉及用户更新。如果客户端逻辑过重,一旦全量发版后发现有问题,修起来非常麻烦。

但 Cloud-First 也有一个很大的缺点:它把逻辑从分散变成了集中。一旦服务端出现问题,整个产品全部受影响。

跳出这个比较狭窄的视角,更全面地看 Local-First 和 Cloud-First,它们各有什么优缺点呢?

Local-First 的七大原则

2019 年,Martin Kleppmann 与 Ink & Switch 团队发表了里程碑式的论文《Local-First Software: You Own Your Data, in spite of the Cloud》,第一次系统性地定义了 Local-First 软件的七大原则。

image-20260704142423866

原则一:No Spinners(即时响应)——数据存储在用户设备上时,读取操作是毫秒级的磁盘访问,而不是跨越大洋的网络请求。

原则二:Network Optional(离线可用)——真正的 Local-First 应用在完全离线状态下也能正常工作。

原则三:Not Hostage(数据不被绑架)——数据必须以开放、可迁移的格式存储。用户应当能轻松导出全部数据,并在其他应用中使用。

原则四:Privacy(隐私安全)——数据存储在本地时,隐私保护从”信任问题”变成了”技术问题”。

原则五:Collaboration(无缝协作)——Local-First 不意味着成为孤岛。当用户有多台设备、或需要与他人协作时,数据应该能无缝同步。关键在于同步是在设备之间直接进行,而非通过中心服务器中转。

原则六:Longevity(长期保存)——你今天创建的数据,五十年后依然可以访问。Local-First 把数据存在用户设备上,使用开放格式(SQLite、Markdown、JSON),即使原始应用不复存在,数据依然可以读取。

原则七:User Control(用户控制)——最终也是最重要的:用户对自己的数据拥有完全的控制权:访问、修改、导出、共享、遗忘。

对比

先明确一个前提:无论是 Local-First 还是 Cloud-First,只要有官方提供的模型、或者要做商业化,请求通常都要经过服务端。只有纯本地模型(比如 Ollama 跑的小模型)才能做到完全离网运行。

对比维度 Cloud-First Local-First
延迟性能 服务间调用有开销。但云端和模型厂商通常在同一个 Region,走专线或 VIP 模型,推理延迟很低 数据读取快(本地磁盘),但调模型有网络开销。自己带 Key 的情况下,网络延迟取决于客户端到厂商的距离。如果是本地模型(Ollama 等),推理和服务端一样在本地完成,但模型能力受限
隐私安全 有监管和泄露风险。要做合规得建立符合 GDPR 的系统,支持一键删除用户数据。代码开源、做第三方认证来证明没有滥用数据,但维护成本极高 数据在本地。但如果用了第三方模型服务,数据仍然要传给模型厂商;如果完全用本地模型,则可以做到数据不出本机。在商业化场景下,请求必须经过服务端,两者的隐私差异其实没那么大
可用性 服务端挂了就全挂了 自带 Key 的场景下,模型厂商也会挂,而且说实话模型厂商的稳定性没那么好。官方模型的场景和 Cloud-First 一样依赖服务端。纯本地模型则不受任何方影响
运营成本 存储、计算用服务端资源,成本高 计算压力转移到了客户端。但用户的机器性能参差不齐,差的机器很影响体验和效果
敏捷开发 服务端快速升级,新能力上线、问题修复都很快 依赖发版和用户升级。即使有 hotfix,也不是所有终端都支持

说了这么多,到底怎么选?

核心差异其实就两个:敏捷开发 和 隐私安全。

如果你追求快速迭代、灰度控制、统一排查问题——Cloud-First 是自然的选择。

如果你的用户对隐私极为敏感,或者场景需要离线使用——Local-First 更合适。但注意,一旦涉及商业化、合规,请求必须过服务端,Local-First 的隐私优势就会大打折扣。

没有银弹。模式本身没有好坏,场景决定选择。

扫一扫,分享到微信

微信分享二维码
看穿还得接住:一场三国最经典的阳谋
2025总结
© 2026 John Doe
Hexo Theme Yilia by Litten