设备端 AI 该成标配了：别再啥都往云端 API 送了

王木风
6 阅读5分钟

刷到一篇叫《Local AI Needs to be the Norm》的帖子，说实话，标题就挺戳我的。现在搞开发，一提到加 AI 功能，第一反应是不是就是 import openai？作者的观点很直白：这种“随手接个 API”的习惯，正在制造一堆又脆又贵还侵犯隐私的软件。

说白了，你把用户输入的内容 stream 到弗吉尼亚的服务器，等个 JSON 回来，这中间有多少坑，可能根本没细想过。

云端 API 的“隐形账单”

先不说钱。最直接的问题是脆弱性。

你的功能完全依赖于另一个公司的网络、算力和账单。网络波动、对方 API 升级、甚至你信用卡额度满了，功能说挂就挂。这哪是加了个功能，这是给自己绑了个不定时炸弹。

再说隐私，这代价被严重低估了。一旦内容离开用户设备，你就引入了数据留存、用户同意、政府数据索取、甚至被拿去训练下一代模型等一系列风险。你的隐私政策得多厚，才能把这些潜在风险都 cover 住？

作者有个比喻挺绝的：我们手机里明明有专用的 Neural Engine（神经引擎），结果却让它闲着，绕道几千公里外的服务器等响应，这荒谬不？

Brutalist Report iOS 客户端的设备端 AI 摘要界面截图 Brutalist Report 这个 App 就在这么干，文章摘要全在设备上跑。

本地模型能干点啥？（以及不能干啥）

个人觉得，很多人不用本地模型，是没搞清楚它的能力边界。它不是什么“平替版 GPT-4”。

它擅长的是对用户已有的数据进行变换：

  • 摘要：长文章变短摘要。
  • 分类/打标签：给内容分个类。
  • 信息提取：从文本里抽人名、日期、关键数据。
  • 改写/润色：换个说法，或者统一风格。
  • 数据归一化：把非结构化日志变成固定格式。

它不擅长（或者说完全不行）的是：

  • 需要世界知识的问答（比如“梅西哪年得的金球奖？”）。
  • 实时信息检索（当搜索引擎用）。
  • 需要复杂推理和规划的任务。

所以，如果你的场景是“用户上传了一份合同，帮我提取关键条款”，这太适合本地模型了。但如果是“帮我写一份关于量子计算的行业报告”，那还是得找云端大模型。

看看 Apple 给的“标准答案”

帖子作者用 Apple 的 FoundationModels 框架做了演示。这东西有点意思，它展示了本地 AI 开发可以多“正经”，而不是那种玩具级的调用。

最让我觉得“有点东西”的，是它的结构化输出。用过 Chat Completions API 的都知道，让模型返回一个规整的 JSON 有多痛苦，得在 prompt 里反复叮嘱格式，还得祈祷它别出错。

FoundationModels 用 @Generable 和 @Guide 这两个装饰器，直接把这事解决了。看代码：

import FoundationModels

@Generable
struct ArticleIntel {
  @Guide(description: "One sentence. No hype.") var tldr: String
  @Guide(description: "3-7 bullets. Facts only.") var bullets: [String]
  @Guide(description: "Comma-separated keywords.") var keywords: [String]
}

let session = LanguageModelSession()
let response = try await session.respond(
  to: "Extract structured notes from the article.",
  generating: ArticleIntel.self
) { articleText }
let intel = response.content // 直接拿到强类型的 ArticleIntel 实例

看到了吗？直接定义一个 Swift struct，模型返回的内容会自动填充进去，类型安全。这开发体验，比对着字符串解析 JSON 高到不知道哪里去了。

基础的文章摘要功能也很简洁：

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

let session = LanguageModelSession {
  """
  Provide a brutalist, information-dense summary in Markdown format.
  - Use **bold** for key concepts.
  - Use bullet points for facts.
  - No fluff. Just facts.
  """
}
let response = try await session.respond(
  options: .init(maximumResponseTokens: 1_000)
) { articleText }
let markdown = response.content

无服务器绕路，无提示词被记录，无需额外账号。这才是真正的“本地功能”。

云端 vs 本地：一个架构选择问题

我们理一下思路。这其实不是一个技术能力问题，而是一个架构决策问题。

下面这个对比表，基本说清了两种路线的核心差异：

维度云端 AI API设备端 AI
隐私数据离岸，存在合规与泄露风险数据不出设备，隐私风险近乎为零
可靠性依赖网络和供应商服务 SLA仅依赖设备自身状态
延迟网络往返延迟（通常 >100ms）本地计算延迟（通常 <50ms）
成本按 token 持续付费，随用量增长一次性的设备算力（边际成本低）
适用场景需要世界知识、复杂生成、实时检索对已有数据的变换、摘要、提取、分类
开发复杂度低（调用 API），但需处理网络错误、计费中（集成框架），但无需处理网络层

把这张表往需求上一套，该选哪边，其实挺清楚的。作者说的核心结语我特别同意：“靠根本不需要隐私政策来赢得用户信任”。

对于很多功能，用云端 AI 相当于“把一个本可以在本地完成的功能，硬生生做成了一个烧钱的分布式系统”。这架构，怎么看都不优雅。

所以，该怎么做？

我的看法是，以后设计带 AI 功能的应用，可以把这个流程图作为决策参考：

graph TD
    A[新功能需求] --> B{是否需要世界知识<br/>或实时数据?};
    B -- 是 --> C[使用 云端大模型 API];
    B -- 否 --> D{是否处理用户私有数据?};
    D -- 是 --> E[优先使用 设备端模型];
    D -- 否 --> F[可根据成本/延迟选择];
    E --> G[实现: 如 Apple FoundationModels];
    C --> H[实现: 注意隐私合规与降级方案];
    G & H --> I[功能上线];

先说结论：处理用户私有数据（文档、笔记、聊天记录、图片）的变换类任务，无脑优先考虑设备端方案。现在手机和电脑的 NPU 真的不是摆设。

再说坑：生态确实还在早期。不同平台（iOS/Android/Windows/macOS）的本地模型框架不一，模型效果和尺寸也需要权衡。但像 Apple 这样把 FoundationModels 做成系统级框架，绝对是个强烈的信号。

对了，提一嘴性能。帖子没给具体数据，这点我存疑。本地小模型的推理速度和质量，需要实际测试，不能无脑吹。但至少，零网络延迟这个优势是实打实的。

总之，东西是个好方向，但别指望它能解决所有问题。把它当成你工具箱里的一把新扳手，用在拧对的那颗螺丝上，别拿着锤子看啥都是钉子。

下次当你下意识地想去 OpenAI 官网复制 API Key 的时候，或许可以先停下来问问自己：这个功能，真的必须离开用户的手机才能完成吗？

参考

avatar
文章
阅读
粉丝