本地AI应该成为常态：为什么开发者不该把所有功能都接到云端API

Hacker News 上一篇引发大量讨论的文章提出了一个观点：本地 AI 应该成为软件开发的默认选择，而不是什么都调 OpenAI 或 Anthropic 的 API。这篇文章获得了 1147 点和 490 条评论，说明这个话题触动了很多开发者的痛点。

问题在哪

现在大量应用开发者在产品中接入 AI 功能时，默认做法是调用云端 API——OpenAI、Anthropic、Google 等。这带来了几个问题：

• 隐私风险：用户数据被流式传输到第三方 AI 服务商，涉及数据保留、同意、审计、泄露和训练等一连串问题
• 可靠性依赖：一个简单的摘要功能变成了分布式系统，需要处理网络超时、API 限流、服务商宕机
• 成本持续增长：每次 API 调用都花钱，用户量越大成本越高
• 延迟问题：网络往返加上 API 排队，响应时间不如本地推理

设备端算力其实够用

文章指出一个被忽略的事实：现在大多数手机和电脑都有强大的神经引擎（Neural Engine），但这些算力大部分时间处于闲置状态，等着云端返回 JSON 响应。

以苹果为例，Apple 的 FoundationModels 框架已经在设备端提供了相当不错的 AI 能力：

• 支持结构化输出（通过 Swift 的 @Generable 和 @Guide 注解）
• 可以在设备上完成摘要、分类、提取、改写等常见任务
• 不需要网络连接，没有延迟，不消耗 API 费用
• 用户数据完全留在设备上，隐私问题天然解决

一个实际案例

文章举了一个具体例子：iOS 应用 The Brutalist Report 使用苹果的设备端 FoundationModels API 来做文章摘要。整个过程不需要服务器中转，不需要记录 prompt，用户数据不出设备。

这类”转换型”任务（摘要、分类、提取、改写、格式化）正是本地模型最擅长的场景。大多数应用功能不需要博士级别的智能水平，本地模型完全能胜任。

什么时候该用云端 AI

作者并不是完全反对云端 AI。他的建议是：

• 先考虑本地：如果是对用户自有数据的转换类操作，优先用设备端模型
• 只在真正需要时才用云端：比如需要最新的世界知识、超大上下文窗口、或高级推理能力时
• 不要把功能变成分布式系统：一个本来可以在本地完成的摘要功能，不应该依赖第三方 API

对站长和开发者的实际建议

结合这篇文章的观点和当前技术现状，以下是给站长和开发者的建议：

1. 评估你的 AI 功能是否真的需要云端：文本摘要、分类、情感分析、简单问答等任务，设备端模型已经能做得不错
2. 关注 Apple FoundationModels 和 Google Gemini Nano：这两个平台在设备端 AI 上投入很大，API 设计也越来越成熟
3. 隐私是差异化优势：如果你的应用能做到”AI 功能但数据不出设备”，这在隐私敏感用户中是很大的卖点
4. 成本控制：本地推理没有 API 调用费用，对高使用量场景来说能省下大量成本
5. 混合策略：简单任务用本地模型，复杂任务才调云端 API，这是目前最务实的方案

本地 AI 不是要取代云端 AI，而是应该成为默认选项。只有当本地确实搞不定时，才升级到云端方案。这个思路转变，可能会让你的应用更快、更便宜、更隐私友好。