Local AI needs to be the norm

标题：本地 AI 应成为常态

来源 URL：https://unix.foo/posts/local-ai-needs-to-be-norm/

发布时间：Sun, 10 May 2026 20:50:24 GMT

Markdown 内容： 现代软件的一个当前趋势是开发人员在其应用程序中调用 OpenAI 或 Anthropic 的 API 来实现某些功能。合理的人可能会争论这些功能是否真正为用户带来了价值，但我想要讨论的是依赖于云托管 AI 模型的根本概念。

这种懒惰正在创造一代脆弱的、侵犯隐私的、本质上存在缺陷的软件。我们正在构建的应用程序在服务器崩溃或信用卡过期的那一刻就停止工作了。

我们需要回归一种习惯，即在本地设备上完成工作的软件构建方式。我们口袋里的硅芯片比十年前快得令人难以置信。当我们在等待弗吉尼亚州的一个服务器农场返回 JSON 响应时，有一个专门的神经引擎在那里闲置。这太荒谬了。

即使你的意图是纯粹的，一旦你将用户内容流式传输给第三方 AI 提供商，你就改变了产品的性质。你现在有了数据保留问题以及随之而来的所有负担（同意、审计、泄露、政府请求、训练等）。

除此之外，你还大大复杂化了你的技术栈，因为你的功能现在依赖于网络状况、外部供应商的正常运行时间、速率限制、账户账单以及你自己的后端健康状况。

恭喜！你把一个用户体验功能变成了一个需要花钱的分布式系统。

如果该功能可以在本地实现，选择加入这个混乱就是自找麻烦。

“无处不在的 AI”并不是目标。有用的软件才是目标。

具体示例：Brutalist 报告的设备端摘要

几年前，我启动了一个名为Brutalist 报告的有趣副项目，这是一个受 1990 年代风格网页启发的新闻聚合服务。

最近，我决定为其构建一个原生 iOS 客户端，设计目标是确保它仍然是一种高密度的新闻阅读体验。标题以简洁的列表形式展示，阅读模式可以剥离网页上的癌症，以及（可选地）一个“智能”视图，生成文章摘要。

然而，关键的一点是：摘要是在设备上使用 Apple 的本地模型 API 生成的。没有服务器绕行。没有提示或用户日志。没有供应商账户。不需要“我们将您的内容存储 30 天”的脚注。

人们已经习惯了任何 AI 使用都发生在服务器端。作为行业，我们还有很多工作要做来扭转这一局面。

我并不天真地认为有时你有的用例确实需要只有云托管模型才能提供的智能，但并非你试图解决的每个用例都是如此。我们需要在这里深思熟虑。

可用工具

由于我最初的重点是开发 Apple 生态系统的工具，因此我只能谈论 Apple 生态系统中的可用工具。在过去的一年里，Apple 在这方面投入了大量资源，允许开发者轻松使用内置的本地 AI 模型。

核心流程大致如下：

import FoundationModels

let model = SystemLanguageModel.default
guard model.availability == .available else { return }

let session = LanguageModelSession {
  """
  以 Markdown 格式提供一个粗犷的信息密集型摘要。
  - 使用 **粗体** 表示关键概念。
  - 使用项目符号表示事实。
  - 不要废话。只要事实。
  """
}

let response = try await session.respond(options: .init(maximumResponseTokens: 1_000)) {
  articleText
}

let markdown = response.content

对于较长的内容，我们可以将纯文本分成块（每块大约 10k 字符），为每一块生成简明的“仅事实”笔记，然后进行第二次处理，将其合并成最终摘要。

这是本地模型完美适合的工作。输入数据已经在设备上（因为用户正在阅读它）。输出轻量级。快速且私密。如果它不是超级人类博士水平的智能也没关系，因为它总结的是你刚刚加载的页面，而不是发明世界知识。

本地 AI 在模型的任务是转换用户拥有的数据，而不是充当宇宙搜索引擎时表现出色。

有很多 AI 功能是人们想要但又不信任的。例如，总结电子邮件、从笔记中提取行动项、分类文档等。

通常的云方法会将所有这些变成信任练习。“请将您的数据发送到我们的服务器。我们保证会小心处理。”

本地 AI 改变了这一点。你的设备已经有了数据。我们会在这里完成工作。

你不会通过写一篇 2000 字的隐私政策来赢得用户的信任。你通过根本不需要这样的政策来建立信任。

平台上的工具更进一步。

Apple 最近做得最好的举措之一是将“AI 输出”从无结构的文本块转向类型化的数据。

与其“请求模型返回 JSON 并祈祷”，更好的模式是定义一个代表你想要的东西的 Swift struct。用自然语言为每个字段提供模型指导。让模型生成该类型的实例。

就是这样。

概念上，它看起来像这样：

import FoundationModels

现在，你的用户界面不必从 Markdown 中抓取项目符号点或希望模型记住你的 JSON 架构。你可以获得一个带有真实字段的实际类型，并且可以一致地渲染它。它可以生成应用程序实际可以使用的结构化输出。而且这一切都在本地运行！

这不仅仅是更好的人体工程学。这是工程上的改进。

如果你正在构建一个以本地为中心的应用程序，这将是“人工智能作为新奇事物”与“人工智能作为可信赖子系统”的区别。

“但是本地模型不够智能”

正确。

但这又有什么关系呢？

大多数应用功能不需要一个能够写莎士比亚、解释量子力学并能通过律师资格考试的模型。它们需要的是一个能够可靠完成这些任务之一的模型：总结、分类、提取、改写或规范化。

对于这些任务，本地模型可以非常出色。

如果你试图用一个本地模型来替代整个互联网，你会感到失望。如果你将其用作位于应用程序内部的数据转换器，你会奇怪为什么以前会把这类东西发送到服务器上。

只有在真正必要时才使用云模型。保持用户的资料数据在其应有的位置。而当你确实使用人工智能时，不要只是将其粘贴为聊天框。而是将其用作具有类型化输出和可预测行为的真实子系统。

不要在打算发布功能时却发布了分布式系统。