苹果把端侧大模型交给Mac应用

苹果正在把 macOS 变成一个自带大模型运行时的应用平台。

截至 2026 年 11 月 12 日，Mac 开发者已经可以通过 Foundation Models Framework，直接在应用内调用驱动 Apple Intelligence 的设备端基础模型，并使用结构化生成、流式输出、工具调用、多轮会话和图像理解等能力。模型由系统提供，用户数据可以留在本机，断网时仍能运行，开发者也不需要把数 GB 的模型权重塞进安装包。(developer.apple.com)

但需要先澄清一个时间点：Foundation Models 并不是今天才首次出现在 macOS 上。它最早随 2025 年 9 月发布的 macOS 26 向开发者开放；到了 2026 年的 macOS 27，苹果又补上了图像输入、Private Cloud Compute、第三方模型协议、Dynamic Profile、评估框架、fm 命令行工具和 Python SDK。换句话说，这次更值得关注的不是“框架登陆 Mac”，而是它已经从一个端侧文本模型接口，扩展成苹果平台的统一大模型抽象层。(developer.apple.com)

Foundation Models 到底是什么

Foundation Models Framework 是苹果提供的一套原生 Swift 大模型接口，用于在应用中调用设备端 Apple Foundation Model、Private Cloud Compute 模型以及符合协议的第三方模型。

这一定义里的重点不是“模型”，而是“接口”。Foundation Models 并不要求开发者理解量化、显存分配、KV Cache 或 Metal Kernel，也不要求自己管理模型下载、加载和卸载。开发者面对的是 LanguageModelSession、提示词、结构化输出和工具，而模型调度、硬件加速、资源管理及系统版本更新由 macOS 负责。

这种设计更接近 Core Location 或 Vision，而不是传统的云端模型 SDK。开发者请求一个能力，系统决定当前设备是否可用，并在能力不可用、模型尚未下载或设备不符合条件时返回明确状态。苹果甚至会通过系统更新替换底层模型，因此 macOS 26.0、26.4 和 macOS 27 对应的系统模型并不是完全相同的版本。(developer.apple.com)

苹果最初披露的设备端模型规模约为 30 亿参数，重点优化内容生成、摘要、分类、信息提取和用户输入分析。进入 macOS 27 后，苹果强调的是指令遵循、工具调用和复杂场景表现的提升，而没有继续用参数量定义新版模型，因此不能简单把当前版本理解为一颗固定不变的“3B 模型”。模型会随着操作系统一起更新，这也意味着开发者必须针对不同系统版本重新跑评估，而不是写完提示词就永久不动。(developer.apple.com)

为什么这件事对 Mac 应用重要

Foundation Models 第一次让普通 Mac 应用获得了接近系统服务级别的大模型能力。

过去要给一款笔记、邮件或文件管理应用增加 AI 功能，开发者通常只有两条路：调用云端模型，或者把开源模型打包到本地。前者需要处理网络、延迟、成本、隐私和账号体系；后者则要处理模型体积、内存占用、硬件兼容和推理框架。

Foundation Models 提供了第三条路：直接调用操作系统已经安装好的模型。

这会显著改变一些“小而高频”的 AI 功能。例如，邮件应用可以离线提取待办事项，文件管理器可以根据文档内容生成标签，日记应用可以总结一周记录，游戏可以生成短对话，照片工具可以根据图像内容建议文件名。它们并不需要调用拥有数千亿参数的服务器模型，却非常在意启动速度、隐私和边际成本。

苹果在 macOS 27 中进一步加入图像理解，应用可以把文本和图片放入同一个提示中，并结合 Vision 框架提供的 OCR、条形码识别等专用工具。这不是要让 Mac 上的系统模型取代大型多模态模型，而是让“识别截图中的文字并归档”“根据产品照片生成描述”“理解白板照片并提取行动项”这类本地工作流变得足够便宜。(developer.apple.com)

它和 MLX、Core AI 不是一回事

Foundation Models 是高层应用接口，Core AI 和 MLX 则更接近模型运行与研究基础设施。

三者都能在 Apple Silicon 上运行模型，但适合的开发者和任务完全不同。

| 方案 | 模型来源 | 是否需要管理权重 | 离线能力 | 开发复杂度 | 更适合什么任务 | |---|---|---:|---:|---:|---| | Foundation Models | macOS 系统模型、PCC、第三方模型 | 设备端模型不需要 | 支持 | 低 | 摘要、分类、提取、轻量智能体、原生应用功能 | | Core AI | 开发者自带或转换的模型 | 需要 | 支持 | 中高 | 自定义模型、图像分割、专用神经网络、可控部署 | | MLX / MLX Swift | Hugging Face 或自训练模型 | 需要 | 支持 | 高 | 模型实验、本地推理、研究和高度定制 | | 传统云端模型 | 模型供应商托管 | 不需要 | 不支持 | 中 | 长上下文、复杂推理、广泛知识和高能力生成 |

Foundation Models 的优势是接入快，而且系统模型不会增加 App 安装包大小；它的劣势则是开发者无法自由选择设备端模型的参数规模、量化方式和训练数据。MLX 恰好相反：自由度更高，但开发者要承担模型分发、内存预算和性能优化。

macOS 27 让这几条路线开始汇合。苹果新增了 LanguageModel 协议，Core AI 和 MLX 模型能够桥接到 Foundation Models 的会话接口，第三方厂商也可以通过 Swift Package 提供自己的模型实现。Apple 的 mlx-swift-lm 已经提供 MLXFoundationModels 桥接层，可以把 MLX 模型交给标准的 LanguageModelSession。(developer.apple.com)

这意味着应用上层不必为每个模型重写一套业务逻辑。开发者可以让端侧模型处理分类和摘要，把需要更强推理的任务切换到 Private Cloud Compute，再把特定领域任务交给自己的 Core AI 模型，而结构化输出、工具调用和会话管理仍然使用同一套 API。

结构化生成比聊天框更有价值

引导式生成是 Foundation Models 最实用的能力，因为应用真正需要的是可靠数据，而不是一段看起来合理的文字。

传统大模型集成经常要求模型返回 JSON，然后开发者再祈祷字段没有拼错、类型没有改变。Foundation Models 的 Guided Generation 可以根据 Swift 类型约束输出结构，让模型直接生成应用可以消费的数据对象。

一个旅行应用要的不是一篇散文，而是包含地点、时间、交通方式和注意事项的行程对象；一个邮件应用要的也不是复述邮件，而是明确的负责人、截止日期和任务列表。结构化生成把模型从“聊天对象”变成了应用逻辑中的一个组件。

工具调用则解决了模型知识与应用数据之间的断层。模型可以按需调用开发者定义的函数，查询本地数据库、读取日历、搜索文件或执行应用内部动作。所有工具都由应用明确暴露，模型并不能任意访问整个系统，这比让一个自动化智能体获得完整桌面权限更容易控制。

macOS 27 新增了真正的模型路由

Dynamic Profile 是 macOS 27 中最值得开发者关注的升级，它让同一个会话可以动态切换模型、指令和工具。

传统智能体通常会为摘要、搜索、规划和执行分别创建会话，再手动搬运上下文。会话越多，状态同步和提示词管理就越复杂。Dynamic Profile 允许开发者声明当前模式所需要的模型、系统指令和工具，并由框架处理配置切换。

例如，一款手工记录应用可以先用设备端模型分析折纸照片，再切换到 Private Cloud Compute 进行创意规划。用户看到的是连续对话，底层却已经从低成本的本地视觉分析，切换到能力更强的云端推理模型。苹果强调，在任意时刻只有一个 Profile 处于活动状态，这能减少上下文污染，也让隐私边界更清楚。(developer.apple.com)

这套设计的价值不在“自动切模型”本身，而在于它把模型路由变成应用架构的一部分。过去开发者通常在业务代码中写大量判断：短任务走本地、长任务走云端、敏感数据禁止上传。现在这些策略可以集中描述，并在一个会话生命周期内执行。

免费推理不等于没有成本

设备端模型不按 Token 向开发者收费，但它仍然受硬件、上下文和系统状态限制。

系统模型目前只在支持 Apple Intelligence 的设备和地区可用，Mac 端主要要求 Apple Silicon；用户还需要开启 Apple Intelligence，并等待模型资源下载完成。即使设备型号符合要求，应用也必须处理模型未准备好、语言不支持或功能被关闭的情况。(support.apple.com)

端侧 SystemLanguageModel 的上下文窗口为 4096 Tokens，提示词、工具定义、结构化输出 Schema、历史消息和最终回复都会共同占用这部分空间。4096 Tokens 足够处理邮件、短文档和少量工具，但不适合直接吞下一整份财报或大型代码仓库。开发者需要切分任务、压缩历史或创建新会话，而不是把它当作长上下文云模型使用。(developer.apple.com)

设备端模型的能力上限也必须正视。它可以很好地完成格式明确、上下文充分的小任务，但在复杂推理、冷门知识、跨文档分析和长链条智能体任务上，仍然无法取代大型服务器模型。苹果在 macOS 27 引入 Private Cloud Compute 和第三方模型支持，本身就说明端侧模型不是万能答案。

| 模型路径 | 推理费用 | 数据位置 | 网络要求 | 能力上限 | 典型用途 | |---|---:|---|---|---|---| | Apple 设备端模型 | 开发者无按量费用 | 本机 | 无 | 中等 | 分类、摘要、信息提取、短文本生成 | | Private Cloud Compute | 不采用传统开发者 Token 计费模式，可能存在系统限额 | 苹果私有云计算 | 需要 | 较高 | 复杂规划、推理、多步骤任务 | | 第三方服务器模型 | 按供应商规则计费 | 第三方服务器 | 需要 | 取决于模型 | 长上下文、专业知识、复杂智能体 | | 自带 Core AI / MLX 模型 | 无云推理费，但有开发和资源成本 | 本机 | 无 | 取决于模型与硬件 | 垂直模型、可控部署、研究实验 |

对开发者来说，真正的门槛变了

Foundation Models 降低了接入门槛，却提高了产品设计和评估的重要性。

当每款 Mac 应用都能在几十行 Swift 逻辑内加入摘要、问答和生成能力时，“接入了 AI”很快就不再是卖点。差异会转移到三个地方：是否选择了适合端侧模型的任务、是否设计了可靠的工具和数据边界、是否能持续评估系统更新后的行为变化。

苹果为此推出 Evaluations Framework，用来批量运行测试样本、衡量准确率，并比较提示词、模型和 Dynamic Profile 调整前后的统计变化。大模型具有非确定性，普通单元测试只能验证代码有没有崩溃，却无法判断分类准确率是否从 92% 降到 81%。评估框架的出现，说明苹果希望开发者把 AI 功能当作需要持续测试的产品能力，而不是演示功能。(developer.apple.com)

系统模型会随 macOS 更新而改变，因此这套评估不是可选项。一个在 macOS 26.4 上表现正常的提示词，到了 macOS 27 可能因为指令遵循更强而产生不同输出；工具调用策略也可能发生变化。苹果甚至在 macOS 27 的发布说明中修复了特定提示导致工具被过度调用的问题，这类变化足以影响真实应用。(developer.apple.com)

苹果想做的是大模型时代的系统 API

Foundation Models 的长期目标，是成为 Swift 生态中与具体模型无关的统一接口。

2025 年的版本更像“开放 Apple Intelligence 的设备端模型”，2026 年的版本则开始容纳 PCC、第三方服务器模型、Core AI、MLX、Python 和命令行工作流。苹果还开放了 Foundation Models Utilities，提供 Skills、上下文管理和兼容聊天补全协议的模型适配层。(github.com)

这条路线与苹果过去的做法一致：先把复杂能力收进操作系统，再给开发者一个稳定、强类型、平台原生的接口。开发者不需要知道定位来自 GPS、Wi-Fi 还是基站，也不需要知道系统大模型究竟运行在 GPU、神经网络引擎还是私有云；应用只需要声明能力、检查可用性并处理结果。

Foundation Models 目前还远未成为通用 AI 平台。4096 Tokens 的端侧上下文偏小，Apple Intelligence 的设备和地区限制仍然存在，底层模型也不够透明。但它已经把本地大模型从少数 AI 应用的核心技术，变成任何 Mac 开发者都能调用的系统能力。

这才是它最重要的影响：未来 Mac 应用加入 AI 功能，可能不再需要首先讨论选哪个模型，而是先判断哪些任务应该留在设备上。

参考来源

• Apple Foundation Models Utilities：苹果开源的 Foundation Models 扩展工具包，包含 Skills、上下文管理和模型适配组件。
• Apple Core AI Models：苹果提供的 Core AI 模型导出方案和 Swift 运行时工具，可通过 LanguageModel 协议接入 Foundation Models。
• MLX Swift LM：Apple MLX 团队维护的 Swift 大模型运行库，包含 Foundation Models 桥接层。