停止交付分布式系统：支持本地 AI 的理由
在当前软件开发的格局中，一种普遍的趋势已经出现：AI 的“API 优先”方法。对于许多开发者来说，现在添加 AI 功能仅仅意味着在代码库中加入一个对 OpenAI 或 Anthropic 的 API 调用。虽然这允许快速原型设计，但它引入了一个根本性的架构缺陷。通过依赖云端托管模型来实现基础功能，开发者在无意中将简单的 UX 增强功能转变为复杂且脆弱的分布式系统。
这种依赖性使得软件本质上变得脆弱。应用程序的核心功能现在取决于外部服务器的在线时间、网络稳定性、信用卡有效性以及第三方速率限制。更重要的是，它从根本上改变了与用户的隐私契约。一旦用户内容被流式传输到第三方提供商，产品就会继承大量的法律和伦理负担——数据保留政策、同意审计以及持续的数据泄露风险。
本地优先 AI 的哲学
现代软件的目标不应该是“AI 无处不在”，而应该是“实用的软件”。对于许多常见的用例，前沿云端模型提供的智能程度是过剩的。当模型的主要任务是转换用户拥有的数据而非充当通用搜索引擎时，本地 AI 的优势就会显现出来。
考虑一下总结文档、从笔记中提取行动项或对文件进行分类等常见任务。在这些情况下，数据已经在设备上。将这些数据发送到弗吉尼亚州的服务器进行处理并传回，不仅效率低下，而且没有必要。通过将计算保留在本地，开发者可以利用架构而非通过一份 2,000 字的隐私政策来建立信任。
实际落地：设备端智能
以 Apple 生态系统为例，通过内置的模型 API，向本地 AI 的转变在技术上正变得可行。现代工具不再是请求非结构化 JSON 并寄希望于模型遵循某种模式，而是允许开发者定义类型化的数据结构（例如 Swift structs）供模型直接填充。
这种方法将 AI 从“新奇的聊天框”转变为“可靠的子系统”。当输出是类型化且可预测的，UI 就可以一致地渲染它，而无需复杂的抓取或正则表达式模式来清理 Markdown 块。例如，对于一个新闻聚合器，本地模型可以生成一个“粗犷主义”摘要——仅包含事实，没有废话——而无需任何服务器中转或用户日志。
“智能差距”之辩
对本地 AI 最常见的反驳之一是，本地模型显然没有云端模型那样“聪明”。这在技术上是正确的，但通常与手头特定的任务无关。
大多数应用程序功能并不需要一个能通过律师资格考试或编写莎士比亚作品的模型；它们需要一个能可靠地分类、总结或规范化数据的模型。当任务被限制在页面或文档中已有的信息时，一个 70B 参数的云端模型与一个高度优化的本地模型之间的差距会显著缩小。
反方观点与技术障碍
尽管本地 AI 前景广阔，但开发者和高级用户社区强调了几个重大挑战：
1. 硬件约束与内存
许多人认为，对于真正实用的本地 AI 来说，硬件要求对于普通消费者来说仍然太高。正如社区讨论中所述：
"We need computers with 128gb or maybe even 192gb of memory before local use make sense... On my 36gb M3 the 24b Gemma model is nice. But the entire system gets allocated for that thing."
在 DRAM 成本下降或统一内存架构在主流设备中变得更加普遍之前，高性能本地 AI 可能仍然是高级用户的利基市场。
2. “SOTA”陷阱
人们倾向于追求 SOTA 模型，因为它们可以减少提示工程（prompt engineering）的“工作量”。开发者经常选择云端 API，并非出于懒惰，而是因为前沿模型的卓越推理能力使得功能“即插即用”，无需太多微调。这导致了一个循环：开发者依赖于最强大的模型来处理每一个任务，无论该任务是否真的需要那种级别的智能。
3. 能量与效率
一些批评者指出，本地推理的单位智能能效比数据中心推理要低，因为后者受益于大规模的经济规模和批处理。本地模型通常处理的是大小为 1 的批次，这比云端集群使用的批处理效率要低得多。
前行之路：混合未来
最务实的做法很可能是采用混合方法。行业正在向以下模式转变：
- 本地 AI 处理私密、日常的任务：摘要生成、PII 掩码处理以及基础数据转换。
- 云端 AI 预留给“前沿”任务：复杂的推理、海量的上下文窗口以及高风险的规划任务。
为了实现这一转变，行业需要在操作系统层面提供标准化的 API——类似于 Chrome 中新兴的 Prompt API——以允许操作系统优化不同应用程序之间的资源分配和批处理。通过将 AI 视为首先是本地子系统、其次是云端服务，我们可以回归到构建快速、私密且具有根本韧性的软件的传统。