Mac 里自带一个免费本地模型：fm 命令行能干什么，以及它干不了什么

有个做法律咨询的朋友，日常工作里有一大块是「把客户给的几十页材料压成一页要点」。这件事不难，但材料不能外传，所以她一直手工做，一份要花四十分钟。她不知道的是，她的 Mac 里从系统更新那天起就躺着一个能干这活的工具——不联网、不上传、不要钱，只是没人告诉她它在哪。

这个工具是一个预装在系统中的命令行程序，名字很短，就叫 fm。它是苹果端侧基础模型的命令行入口，直接调用本机跑的三十亿参数模型。你在终端里敲一行，答案就在终端里出来，整个过程数据不出机器。

它到底是什么，以及为什么值得看一眼

先说定位：它不是用来跟前沿大模型比能力的。三十亿参数的端侧模型，跟动辄几千亿参数的云端模型不在一个量级，官方自己也不建议用它做代码、数学和逻辑推理。

它真正的价值在另外三个地方。

• 零成本。 不按 token 计费，没有月度额度，跑一万次和跑一次花的钱一样。
• 零上传。 数据不出本机，这对处理合同、病历、财务材料、未公开稿件这类内容的人来说，是云端模型给不了的。
• 零配置。 不用申请密钥、不用装运行时、不用拉镜像，系统更新完就在那儿。

这三条叠在一起，构成了一个很具体的适用场景：高频、轻量、敏感的批量文本处理。这类任务正好是云端模型最不划算的——量大所以贵，敏感所以不敢传，简单所以不需要强模型。

上手三步：许可、调用、脚本化

使用路径比想象中短，但有一步很容易卡住。

第一步，接受许可。 这是最常被忽略的门槛。在首次使用前，需要用管理员权限执行一次许可接受命令。没做这一步之前，命令会以特定状态码退出，并把提示写到错误输出里——如果你在脚本里只捕获标准输出，会拿到一个空字符串，然后以为模型坏了。先跑许可，再看其他。

第二步，两种调用方式。 一种是交互式会话，适合边聊边调，会话记录会存在用户目录下，可以后续接着上次的上下文继续。另一种是一次性问答，直接把提示词作为参数传入，输出打印到标准输出，适合写进脚本。

第三步，接进流水线。 一次性问答模式天然适配 Unix 管道，可以和常见的文本处理命令组合。比如把一批文件名喂给它做分类，再接一个 JSON 解析工具把结果拆出来，最后交给移动或重命名命令执行——整条链路上不需要写一行 Python。

这里有个细节值得注意：模型权重需要占用大约 7GB 存储空间，且由系统自行安排下载时机，没有进度条。所以第一次用之前，最好给它留出足够的磁盘和一段安静的时间。

fm serve 才是真正有意思的那个

三条子命令里，交互式和一次性问答都直观，但真正改变用法的是本地服务模式。

它做了一件很聪明的事：在本机起一个 HTTP 服务，接口格式与 OpenAI 的对话补全接口兼容。这意味着任何已经接入 OpenAI 接口的工具——各类客户端、开发框架、脚本库——只要把服务地址改成本机地址，就能直接调用这个本地模型，其他代码一行都不用动。

对开发者的实际意义是：你已经有的一大堆代码可以立刻切换到本地推理。原本指向云端的调用改一个基础地址参数即可，认证字段随便填一个占位值就行，因为本地服务不需要认证。这让「本地优先、云端兜底」的架构从需要专门适配，变成了一个配置开关。

对非开发者也有意义：不少图形化的 AI 工具允许自定义接口地址。把它填成本机服务地址，这些工具就变成了免费、离线的本地版本。

结构化输出：把它塞进自动化流水线

第二个关键能力是结构化输出。你可以在调用时传入一个 JSON Schema，模型保证返回符合该结构的 JSON。

这一点的重要性怎么强调都不过分。语言模型进入自动化流程最大的障碍不是能力不够，而是输出不稳定——你没法可靠地解析一段自由文本。有了结构化约束，模型的输出就直接变成了程序能消费的数据。

举几个立刻能落地的用法。

• 批量分类：把一批文件的名字或首段喂进去，要求返回「草稿」和「终稿」两组数组，管道接解析工具，直接驱动归档动作。
• 信息抽取：把一段文本喂进去，要求返回人名、地名、金额、日期四个字段的 JSON，直接写进表格。
• 内容打标：给每篇文章生成两到三个标签，输出固定结构，直接入库。
• 合规初筛：对一批文本判断是否包含特定类型的内容，返回布尔值和理由，人工只看被标记出来的那些。

这四类任务的共同点是：量大、规则清晰、容错空间存在，正好落在小模型的能力圈里。

明确的能力边界：别让它写代码和算账

说完了能做什么，必须把不能做什么讲清楚，否则期望落差会毁掉整个体验。

官方给的能力定位是摘要、抽取、分类这三类「文本进、变形文本出」的任务，配套的建议用例是：总结一段文字、抽取提到的人与物、就你提供的段落回答问题、改写或编辑文本、判断文本是否属于某个主题、生成短创意文本、给一段文字打标签。

同时官方明确列出了不适合的领域：写代码、做数学、逻辑推理，以及依赖世界知识的问答。

第三方实测印证了这个边界，而且比官方说法更直白。有开发者用五个真实的终端新手问题测试，两种方式各问一遍，两轮下来没有一个完全答对：它会煞有介事地解释一个根本不存在的命令；被问当前系统版本时，两次给出了两个不同的错误答案；遇到一段常见报错信息，直接回复无法处理。更麻烦的是，提问方式越正式，它给出的步骤越具体、越像真的——幻觉被包装成了可执行的操作指南。

而在它宣称擅长的任务上，表现是合格的：给一篇真实文章要求三句话摘要，输出准确且没有编造；要求给两个文件标签，给的是对的。

这个对比就是使用它的正确姿势：把它当文本处理器，不要当顾问。

和本地推理框架不是替代关系

很多人第一反应是「这是不是要取代 Ollama 这类本地推理工具」，答案是否定的，两者解决的问题不同。

本地推理框架的核心价值是模型可选：你能跑几百上千种开源模型，从几亿参数到几百亿参数，可以按任务挑最合适的，也能跑量化过的大模型。代价是要自己管理模型下载、显存占用、推理后端。

系统内置这个工具的核心价值是零管理：没有选择，只有一个模型，但你什么都不用配。代价是能力固定，且明确不适合推理类任务。

所以合理的关系是分工：高频轻活走系统内置的，重活走本地推理框架，最重的走云端。三者不是竞争，是一条成本曲线上的三个点。

四类真正划算的用法

结合能力和边界，下面四类场景是投入产出比最高的。

• 敏感材料的预处理。 合同、病历、内部纪要、未发布稿件，先在本地做摘要和脱敏，再决定要不要送云端做深度处理。
• 高频批量文本任务。 每天几十上百次的摘要、分类、打标，走云端是一笔持续的开销，走本地是零边际成本。
• 离线场景。 飞机上、内网环境、网络受限的办公场所，本地模型是唯一可用的选项。
• 自动化流水线里的「胶水步骤」。 在脚本中间插一步需要理解语义的操作，以前要么写复杂规则要么调云端接口，现在可以本地完成且免费。

现在就该试的几件事

先跑一次许可接受命令，再用一次性问答模式让它总结一段你正在处理的文本，感受一下输出质量。如果感觉可用，接着试本地服务模式，把它接进你已经在用的某个支持自定义接口的工具里。最后挑一个你每周重复做的高频任务，用结构化输出把它脚本化。

三步走完，你会对「本地小模型能替我做什么」有一个不再靠想象的答案。而在这个模型能力不断被收进付费档的年份里，一个免费、离线、不需要账号的本机选项，值得你花一小时去摸清它的边界。