Apple Foundation Models

原文 ↗ Hacker News 讨论 ↗

Apple 的 Foundation Models Framework 是什么

  • 面向语言模型的标准 Swift API（将在 iOS/macOS/watchOS/iPadOS/visionOS 27 中随系统发布）。
  • 支持两种模型：
    • Apple 的设备端小模型（SystemLanguageModel）。
    • 通过通用 LanguageModelSession / LanguageModel 协议接入的云端模型（例如 Claude、Gemini）。
  • 同一套 API 处理流式输出、工具调用、结构化输出；应用只需更改一个构造函数就能切换模型。

Claude 集成细节

  • Claude 作为一个 Swift package 暴露，实现在 Apple 的 LanguageModel 协议之上。
  • 设备发出的请求会直接发送到 api.anthropic.com；Apple 不在网络路径中，也看不到提示词或响应。
  • 通过这个框架使用 Claude 仅支持云端；离线时，只有 Apple 设备端约 3B 参数的模型还能继续工作。
  • 使用费用按标准 API 定价计入普通 Anthropic 账户。

设备端 vs 云端以及存储顾虑

  • Apple 当前设备端模型规模有限（大约 3B 参数）；Claude 要大得多，并且仍然运行在服务器端。
  • 有人希望第三方本地模型能由系统级共享缓存，以避免每个应用都下载自己的副本；也有人指出 Apple 目前只对系统模型做去重。
  • 讨论集中在：相比许多应用各自使用专用模型，单一、优化过的默认设备端模型是否更适合用户体验和资源利用。

商业模式、锁定与 UX 控制

  • 许多人认为，这相当于 Apple 将 LLM 提供商商品化，同时保留对整体 UX 和品牌展示的控制权（“Apple Intelligence” 作为可见层）。
  • 有人猜测未来可能会出现类似“Intelligence Store”的分成模式，或对 AI 驱动的应用订阅抽取 30% 分成，即使 API 计费本身不经过 Apple。
  • 也有人担心 Apple 之后可能会偏向或替换提供商，而用户并不会察觉，从而进一步强化平台锁定。

开发者体验与 API 密钥

  • 在开发阶段，SDK 可以直接使用 API key；在生产环境中，文档强烈建议通过开发者的后端代理转发，并由后端注入凭据。
  • 这避免了在应用中直接打包密钥，但也引发了关于代理端能否访问用户提示词和数据的担忧。
  • 一些评论者不喜欢面向终端用户的、基于 token 且成本可变的 UX；他们认为订阅制或本地模型对用户更友好。

模型商品化与竞争

  • 线程讨论了前沿模型是否正变成可互换的“商品”，还是仍然存在显著的质量差异。
  • 对哪些实验室领先看法不一，但普遍同意：
    • 大多数应用场景并不需要绝对的前沿性能。
    • 统一的 OS 级 API 会把很多应用推向“够用就好”的默认模型，而把云端前沿模型留给更重的任务。