在 macOS 27 的终端输入fm会看到一个很直接的入口system默认使用设备上的 Apple Foundation Model。它能聊天、读图、输出结构化数据还能启动 Chat Completions API 服务。看到这里很容易接着问Mac 已经自带一个能替代主流大模型的本地助手了吗能不能再下载几个模型按需切换我查了 Apple 的模型报告、WWDC26 开发者资料以及第三方公开测试也检查了当前 Mac 上的命令帮助。先说结论Apple 确实公布过基准测试社区也有可复查的测试记录但目前查到的证据不能把你机器上的system排进一个可靠的“当代大模型总榜”。fm当前也没有下载任意模型的功能。问题的关键是区分模型家族、系统接口和具体版本。本文资料核查截至 2026 年 10 月 19 日本机检查环境为 macOS 27.0.1build26A434。system是系统入口不是完整的模型身份证Apple Foundation Models 是一组模型的名称。system则是fm暴露的设备端模型选项。这个名字本身没有告诉我们权重版本、量化配置或完整架构。Apple 在 2026 年 6 月介绍了第三代模型家族。其中AFM 3 Core 是 30 亿参数的设备端稠密模型AFM 3 Core Advanced 是总计 200 亿参数、按请求激活约 10 亿至 40 亿参数的设备端稀疏模型面向更有能力的 Apple 芯片。家族还包括运行在 Private Cloud Compute 上的云端模型。这不意味着终端里的system就一定是那个 200 亿参数模型更不意味着fm可以调用整组模型的全部功能。在缺少可核实的运行时映射信息时我不会直接把system写成 AFM 3 Core Advanced。注意下图绿色的本机边界fm → system是当前确认的路径。右侧云端属于另一条执行路径不能因为框架支持就认定当前 CLI 也支持。Apple 的 Foundation Models 框架还支持通过适配接口接入其他提供商。这里至少有三个层次Apple 拥有哪些模型、框架能接入哪些模型、这台 Mac 的fm实际开放哪些选项。把三者混在一起最容易高估终端里这个入口。Apple 自己有评测而且要分年份读2025 年技术报告能判断上一代的小模型水平Apple 的《Apple Intelligence Foundation Language Models: Tech Report 2025》公开了 MMLU、MMMLU 和 MGSM 成绩。它们分别侧重多学科知识、多语言知识和多语言数学题都不能单独代表完整的助手体验。报告中2025 年设备端 AFM 的 MMLU 为67.85Qwen-2.5-3B 为66.37Qwen-3-4B 为75.10。MGSM 上对应成绩分别为74.91、64.80、82.97。这里比较的是报告指定的 instruct、非 thinking 设置。这些结果支持一个有限但有用的判断上一代设备端 AFM 在当时的数十亿参数模型中有竞争力但并没有全面超过同级开源模型。例如Qwen-3-4B 在这些公开知识与数学测试上领先。还有一个容易忽略的细节报告另列的压缩优化对比中设备端模型的 MMLU 从约 67.8 降至 64.4。论文里某个模型配置的成绩不能原样当作每台 Mac 实际部署版本的成绩。2026 年第三代评测主要证明代际改进Apple 的第三代模型介绍也有评估结果。对一般文本能力进行人工成对比较时AFM 3 Core 获得偏好的比例为45.6%2025 年基线为23.3%剩余为平局。这表示在该评测集上评审更常选择新模型的回答。它不表示正确率是 45.6%也不表示模型能力提升了 45.6%。更关键的是这组数字比较的是 Apple 自己的两代模型。它能支持“新一代变好了”不能直接支持“已经追平当前的 GPT、Claude 或 Gemini 旗舰模型”。本次检索没有找到足以给当前system建立这种同条件横向排名的完整证据。因此网上出现“Apple 模型相当于某某旗舰”的说法时至少要继续问哪一代设备端还是云端什么任务压缩前还是部署后这些条件不齐排名就很容易失真。第三方测过什么有数据但不要扩大解释我找到一个独立开源项目 FoundationModelsBench。它不只看生成速度还分别记录任务通过情况、首段输出延迟、生成吞吐、失败和环境信息。项目公开的一组历史基线来自 2026 年 6 月 12 日MacBook ProApple M532GB 内存macOS 27.0 betabuild26A5353q正常温度状态关闭低电量模式。这组记录包括Practical Quick25 次测量全部通过提示任务未记录失败。Synthetic Performance5 次测量首段输出时间中位数0.413 秒解码吞吐中位数55.35 token/秒。一次 PCC 尝试首段输出前就不可用不能算作成功的云端性能测试。其中“25 次通过”不能读成“通用能力正确率 100%”。这是特定测试集及其判定规则的结果。项目还提醒这组记录早于测试集扩展不能直接与后来更大的题库比较通过数量。55.35 token/秒也只是这台机器、这些输入和计时口径下的结果。它的解码统计排除了首个累计流式输出中已包含的 token。换芯片、换输入长度或换统计方式数字就可能变化。这份测试的实际价值是说明设备端模型已经可以在具体机器上提供较快的交互并给出可复查的测量方法。它没有回答“中文长文、复杂代码、数学推理分别比主流模型差多少”。相比主流模型应该给它怎样的预期我会把它作为本地任务组件来评估输入材料明确处理范围有限结果容易检查。比如把一小段会议记录整理成要点从订单描述中提取字段或者按固定标签分类文本。这是基于部署方式和已有证据的选型建议不是一个新造的能力排行榜。2025 年报告提供的是历史上的小模型对比2026 年官方介绍提供的是代际改进社区样本则提供具体机器上的任务与速度记录。三者还不足以拼成当前旗舰模型的完整横评。面对跨文件代码修改、困难数学题、长时间多步规划或者需要大量外部知识的问答我不会仅凭“系统自带”就把任务交给它。更合理的做法是拿实际任务与准备采用的云端或本地模型对照测试。这里还有一个区别fm chat给你聊天界面但模型没有因此自动获得联网搜索、仓库访问或应用操作权限。回答得流畅也不代表回答已核实。中文能力也需要单独验收。多语言综合成绩不能说明它是否能稳定保留中文专有名词、金额、日期和语气。若任务是中文内容处理测试集就应该以真实中文样本为主。当前fm到底能做什么这次我在本机运行了fm available结果为System model available。同时检查了respond、serve和schema object的帮助。以下命令作为使用示例提供没有把这些示例的输出当作质量实测。文本生成和多轮对话。respond适合单次调用也能从标准输入读取内容chat提供交互界面。指令可以单独传入输出支持流式生成。fm respond--instructions用中文回答保留原文数字。\把下面的记录整理成三条要点……catnotes.txt|fm respond--instructions提取待办事项不补充原文没有的内容。结构化输出。schema用于定义输出结构再交给respond --schema使用。例如fm schema object--nameTask--stringtitle--booleanurgenttask-schema.json fm respond--schematask-schema.json\提取任务明天下午提交报销材料标记为紧急。结构化生成能约束字段和类型但不能保证字段内容一定正确。输出是合法 JSON与提取的日期、金额是否准确是两个问题。图片输入和工具辅助。本机respond --help列出--image、--text以及内置的ocr和barcode工具。读图理解、OCR 和条码识别可以配合使用但它们各自承担不同工作。fm respond--imagereceipt.jpg--toolocr\--text提取商户、日期和总金额无法确认的内容明确说明。这个入口用于理解图片当前帮助没有提供生成图片、语音合成或转录的对应命令。Apple 模型家族中的这些能力不能自动算作当前fm system的功能。本地 API 服务。fm serve提供/health、/v1/models和/v1/chat/completions支持流式与非流式 Chat Completions。fm serve--host127.0.0.1--port1976它适合让已有脚本通过 HTTP 调用本机模型。接口形式相似不意味着其他服务的所有参数和端点都能直接迁移接入时仍要检查兼容范围。此外count-tokens可以计算输入的 token 数--resume和--save-transcript可以继续和保存对话。上下文容量应以具体设备和运行时接口为准不宜把旧版本的固定数字套给所有 macOS 27 设备。能不能通过fm下载更多模型就本机当前版本而言不能像模型管理器那样通过fm下载 Qwen、Gemma 或其他任意权重。顶层命令没有pull、download、install或导入权重的选项。respond --help中的--model只列出systemserve --help也只列出这一个模型。这些是当前机器的直接观察。这里要区分三件事系统准备或更新 Apple Intelligence 模型资产由系统管理。开发者通过 Foundation Models 框架接入其他模型需要对应实现及运行条件。在 Mac 上自行运行开放权重模型需要支持这些权重的运行工具。后两者都不能推导出fm已经拥有模型下载功能。想在同一台 Mac 上运行多个开放模型是另一项部署任务要考虑可用内存、量化格式、上下文长度和运行时支持。还有一处版本差异值得单独说明WWDC26 的官方演示展示过fm切换到 PCC以及通过--model使用云端模型。可是当前本机帮助仅显示system与你看到的菜单一致。因此我不会建议直接照搬演示里的 PCC 用法也不会由此断言 Apple 的整个框架取消了 PCC。判断自己能用哪些选项先看当前机器的帮助看框架能做到什么再查对应 API 和接入要求。云端模型也不是下载到本地后离线运行。我会怎样判断它是否值得用先选一项准备投入使用的小任务整理 50100 条有预期结果的样本。这个数量只是起步建议用于发现明显问题不能替代完整评估。例如做中文信息提取就同时放入普通文本、缺字段文本、含多个金额的文本以及容易混淆日期的文本。要求模型在信息缺失时明确返回缺失检查它是否擅自补全。然后让system和候选模型处理相同输入分别记录任务是否正确完成关键事实是否保留。输出格式是否符合要求是否拒答、超时或超出上下文。从请求到可用结果的时间以及长时间运行后的变化。不要只挑一个回答漂亮的例子也不要把一次模型回复当成基准测试。速度快但经常提取错金额和速度略慢但稳定正确代表完全不同的产品选择。对于我的使用预期fm最值得尝试的地方是把本地语言处理接进已有脚本材料留在本机、无需为每次设备端调用支付云 API 费用也省掉单独部署权重的步骤。至于复杂任务是否能替代现有模型答案应该来自同条件的实际任务测试。