MacPaw把AI搬进应用商店

MacPaw开始给开发者提供端侧AI能力

MacPaw 于 2026 年 8 月 5 日披露与 Liquid AI 的合作，计划向旗下应用商店生态的开发者提供端侧模型推理能力，同时使用 Liquid AI 的模型开发本地版本 AI 助手 Eney。按照目前公布的信息，这项合作的重点不是再给应用接入一个云端聊天机器人，而是把模型直接部署到 Mac、iPhone 等用户设备上运行。

端侧模型推理是指模型在用户的手机、电脑或其他终端设备上直接完成计算，不必把每次请求发送到远程服务器。 它带来的直接变化包括离线可用、数据不离开设备、没有逐次请求产生的网络往返，以及更可预测的推理成本。

这次合作对 MacPaw 的意义，首先在于为其应用生态补上一层统一的 AI 基础设施。MacPaw 最为人熟知的产品包括 CleanMyMac、Setapp 和 ClearVPN，其中 Setapp 采用订阅制应用分发模式，MacPaw 也在欧洲运营 Setapp Mobile。开发者如果能够直接获得适配这一生态的本地模型能力，就不必从模型挑选、量化、运行时适配和硬件调度开始重新搭建整套端侧 AI 技术栈。

这次合作对 Liquid AI 的意义，则是拿到了一个比单独发布模型权重更接近真实用户的分发入口。端侧模型公司最大的难题通常不是做出一个可以在笔记本上运行的 Demo，而是进入稳定的软件分发体系，并让第三方开发者愿意把模型写进自己的产品。MacPaw 恰好拥有应用、开发者和付费用户三端资源，这比单纯增加一次模型下载量更有商业价值。

Eney将成为第一块试验田

Eney 是 MacPaw 推出的一款 AI 助手，目标是让用户通过自然语言在 Mac 上查找信息、处理文件并调用不同应用完成任务。 MacPaw 目前正在使用 Liquid AI 的模型构建本地版本 Eney，这意味着它至少会把部分理解、规划或工具调用环节从云端转移到用户设备。

本地版 Eney 最值得关注的不是“能不能聊天”，而是它能否处理真正敏感的桌面上下文。桌面助手要发挥作用，往往需要读取文件名、剪贴板、日历、邮件摘要、应用状态甚至系统设置；如果这些信息每一步都要上传云端，隐私授权会成为产品落地的主要阻力。端侧模型可以先在本地判断用户意图，再决定是否调用应用工具或外部服务，从架构上减少原始数据外流。

本地推理也更适合高频、短链路的桌面操作。比如“找出下载目录中最大的 5 个安装包”“比较这两份合同的修改位置”“把今天会议记录整理成待办”等任务，真正影响体验的常常不是模型首字输出有多快，而是一次任务要连续执行多少次分类、检索、判断和工具调用。云端方案每一步都叠加网络往返，本地模型则可以在没有网络延迟的情况下完成中间决策。

不过，MacPaw 尚未公开本地版 Eney 使用的具体模型版本、参数规模、量化精度和最低硬件要求。Liquid AI 已经拥有从小型模型到混合激活大模型的多条产品线，但这不等于 Eney 会直接采用其中某个公开版本；消费级产品通常还要经过任务微调、量化、蒸馏和安全限制，最终交付模型可能与公开权重明显不同。

Liquid AI卖的不是“小模型”，而是设备原生架构

LFM 是 Liquid Foundation Model 的缩写，指 Liquid AI 面向低延迟、低内存和端侧部署设计的基础模型系列。 Liquid AI 的核心卖点并非简单缩小 Transformer，而是通过结构化、自适应计算单元以及混合架构，减少推理过程中的计算量和内存访问压力。

LFM2 是 Liquid AI 于 2025 年发布的第二代基础模型架构，主要面向手机、笔记本、汽车和其他资源受限设备。 Liquid AI 当时将部分 LFM2 权重开放，并强调其在 CPU 推理、长上下文效率和边缘设备吞吐方面的表现。开发者目前可以在 Liquid AI 的 Hugging Face 官方主页 查看公开模型、模型卡和许可证信息。

LFM2 的技术路线值得注意，因为端侧推理的瓶颈不只在算力。云端 GPU 可以依靠高带宽显存和批处理提高利用率，消费级设备却要同时考虑统一内存占用、功耗、散热和前台应用响应；一个模型即使跑得动，只要持续占满 CPU、让风扇高速转动或明显消耗电池，就很难成为可长期启用的产品功能。

Liquid AI 随后继续扩展 LFM2 产品线，包括强调设备端推理能力的 LFM2.5-1.2B-Thinking，以及采用激活参数设计的 LFM2-24B-A2B。后者名称中的“24B-A2B”意味着模型总参数规模约为 240 亿，但单次推理只激活约 20 亿参数，思路类似稀疏专家模型：模型保留更大的知识容量，同时避免每生成一个 token 都计算全部参数。

模型规模仍然不能直接等同于产品效果。一个 10 亿至 30 亿参数的端侧模型，可以很好地完成意图分类、摘要、结构化提取和有限工具选择，却很难稳定替代前沿云端大模型处理复杂研究、长链推理和开放式编程。MacPaw 如果希望 Eney 成为真正可用的桌面智能体，更合理的方案可能是“本地优先、云端兜底”，而不是强行把所有任务塞进一台设备。

MacPaw真正需要解决的是开发者体验

端侧 AI 平台是把模型、运行时、硬件加速、权限控制和应用分发整合在一起的开发基础设施。 对应用开发者来说，模型权重只是其中一部分；更麻烦的工作包括判断设备是否支持、选择量化版本、下载和更新模型、限制内存峰值、处理中断恢复，以及在不同芯片上保持一致表现。

MacPaw 与 Liquid AI 的合作能否成立，取决于它们是否愿意把这些脏活封装掉。理想情况下，Setapp 生态中的开发者只需要声明任务类型和资源预算，平台就能提供经过签名、版本管理和硬件适配的模型组件；如果开发者仍需自行下载数 GB 权重、编译运行时并为每代 Apple Silicon 单独调优，这项合作就更像联合营销，而不是平台能力。

目前双方尚未公布 SDK 形态、模型分发方式、商业授权条款、开发者价格和正式开放时间表。对于准备评估这项能力的团队，这些缺失信息比一次跑分更重要：端侧模型没有按 token 产生的云端账单，但模型授权、应用体积、测试成本、设备兼容和持续更新同样会形成实际开支。

开发者还需要关注模型是否随应用安装包分发。苹果应用生态对安装包体积、后台下载、动态代码和隐私权限均有明确限制，数百 MB 乃至数 GB 的模型如果直接打进应用，会降低下载转化率；如果在首次启动后下载，又需要处理网络失败、存储空间和模型版本回滚。MacPaw 若能把模型作为平台级共享资源分发，多个应用就可能复用同一份权重，从而避免重复占用磁盘。

它与苹果自己的端侧模型并不完全重合

苹果已经通过 Core ML、MLX 和 Foundation Models framework 提供多层本地 AI 能力，因此 MacPaw 与 Liquid AI 并不是进入一片空白市场。苹果的优势是操作系统级硬件调度、统一内存优化和隐私架构，Liquid AI 的优势则是模型可定制性、跨设备部署空间，以及不完全受限于苹果系统模型的能力边界。

| 方案 | 推理位置 | 开发者成本结构 | 模型可定制性 | 离线能力 | 更适合的场景 | |---|---|---|---|---|---| | MacPaw + Liquid AI | Mac、iPhone 等终端设备 | 价格与授权方式尚未公布 | 预计高于系统内置模型，但取决于平台开放程度 | 支持 | Setapp 应用、桌面智能体、私密文件处理 | | Apple Foundation Models framework | 苹果设备本地 | 通常不按 token 收费，受系统与设备支持范围限制 | 相对有限 | 支持 | 摘要、生成、系统级智能功能 | | Core ML / MLX 自行部署 | 苹果设备本地 | 无逐次云端推理费，但工程和维护成本高 | 高 | 支持 | 有模型团队、需要深度优化的应用 | | 云端前沿模型 | 远程数据中心 | 通常按输入、输出或调用量计费 | 取决于服务商 | 不支持完整离线 | 复杂推理、编码、长上下文与高质量生成 |

Liquid AI 的差异化不能只靠“隐私”和“离线”两个标签。苹果自己的模型框架同样主打本地运行，而且拥有系统级入口；MacPaw 必须进一步证明，Liquid 模型在特定任务上的质量、速度或内存占用足以让第三方开发者放弃最省事的系统方案。

MacPaw 的另一张牌是应用分发和商业化。苹果提供的是通用开发框架，MacPaw 则有机会把端侧模型与应用审核、订阅分成、功能推荐和用户触达结合起来。如果 AI 功能能够直接提高 Setapp 应用的使用频率，MacPaw 可以用平台数据判断哪些本地 Agent 真正产生留存，而不只是增加一个聊天入口。

端侧推理不等于天然安全

端侧模型可以减少数据上传，但不能自动消除安全风险。模型一旦能够调用文件管理、邮件、浏览器和系统工具，就可能受到提示注入、越权操作和恶意文档影响；攻击者不需要窃取模型，只要诱导 Agent 删除文件、发送错误内容或泄露本地信息，就能造成实际损失。

本地 Agent 的安全边界应建立在工具权限而非模型承诺上。读取、修改、删除和对外发送应该是不同等级的能力，高风险动作需要明确确认，并保留可审计日志；对于“清理磁盘”这类与 MacPaw 核心产品高度相关的任务，撤销机制甚至比模型准确率更重要，因为一次错误删除的成本远高于一次回答不够聪明。

模型更新也会成为新的供应链问题。端侧权重和运行时需要像普通软件一样签名、校验和回滚，开发者还要知道一次模型升级是否改变工具选择行为。对智能体来说，模型版本不是普通依赖：相同输入在升级后可能触发不同动作，因此 MacPaw 最终需要提供版本固定、灰度发布和自动化行为测试能力。

这是一笔有方向感、但仍待交付验证的合作

MacPaw 选择 Liquid AI 的方向是合理的，因为它没有试图用另一个通用聊天入口与 ChatGPT 正面竞争。MacPaw 更有机会做成的是与操作系统和应用生态紧密结合的任务型助手，而任务型助手恰好需要低延迟、高频调用和本地数据访问，这些都是端侧模型的优势区间。

Liquid AI 也需要 MacPaw 这样的合作伙伴来证明模型不只适合跑分。端侧 AI 市场已经不缺“可以在笔记本上运行”的小模型，真正稀缺的是被数十个应用稳定调用、在大量异构设备上持续运行，并且让用户愿意付费的基础设施。MacPaw 的应用生态为 Liquid AI 提供了这样的验证场。

这项合作目前仍缺少决定性数据。双方没有公布 Eney 本地版的首 token 延迟、每秒生成速度、内存占用、电池消耗、模型下载体积和任务成功率，也没有给出与苹果系统模型及同尺寸开源模型的同机对比。在这些数字出现之前，“更快、更私密”只能被视为技术方向，而不能算作已被产品验证的结论。

接下来最值得观察的有四件事：

1. 开放范围：能力是只供少数合作应用使用，还是向全部 Setapp 开发者开放。
2. 部署形态：模型由每个应用单独携带，还是由 MacPaw 平台统一下载和共享。
3. 混合路由：Eney 是否采用本地小模型处理意图和工具调用，再把复杂任务交给云端模型。
4. 量化指标：双方能否公布同一台设备上的延迟、吞吐、内存、功耗和真实任务成功率。

MacPaw 与 Liquid AI 的合作真正值得关注之处，是应用商店开始从“分发软件”转向“分发模型能力”。如果 MacPaw 最终提供的是一套可复用的本地推理层，Setapp 开发者得到的就不只是一个模型，而是一块共享的 AI 底座；如果后续只落地为 Eney 的单项功能，这笔合作的影响范围则会小得多。

参考来源

• Liquid AI 官方 Hugging Face 页面：提供 Liquid AI 公开模型、模型卡、权重与许可证信息。
• Liquid AI：端侧 AI 独角兽的美国往事：补充介绍 Liquid AI 的公司背景、端侧模型路线及典型应用场景。