这一周有两场模型发布，标题里都在说同一件事——「在你的设备上跑」。

一篇是 Liquid AI 的 LFM2.5-24B-A2B，10 月 14 日，Hacker News 上 284 分。另一篇是 Meta 的 Muse Spark Open，10 月 15 日，684 分、369 条评论，当天最热。

我把两边的官方发布页、模型卡、跑分表和硬件要求都翻了一遍，越看越觉得，「端侧（on-device）」这四个字，正在被用出两种完全不同的意思。

按 Liquid 的说法，端侧是你现在坐着的这台笔记本：一台 M5 Max MacBook Pro，插着电，跑 184 tokens/s，全程不联网。

按 Meta 的说法，端侧是两台顶配 Mac Studio，共享 1TB 统一内存。官方原话是「两台 Mac Studio 表现得像一台带 1TB 统一内存的超级计算机」。

一个能塞进背包，一个要约一辆小货车。它们都叫「端侧」。我想把这中间那笔账，一行一行摊开算清楚。

先把两款的底牌亮出来

Liquid LFM2.5-24B-A2B —— 一句话：24B 的脑子，每个 token 只花 2.45B 的电。它是 LFM2.5 家族里最大、也是最后一款模型，这个家族从 230M 一路排到 24B，跨了两个数量级。这是个纯推理模型，回答前一定先想一遍，而且是纯文本的。Liquid 对它的定位很清楚：跑在你已有的设备上，做连续在线的私人 agent。

Meta Muse Spark Open —— 一句话：把一台数据中心级的开源模型搬回家。816B 总参数，42B 激活，100 万 token 上下文，原生多模态（文字、图像、音频、视频进，文字出）。Meta 把它称作「迄今最强的美国开源权重模型」，主打长程编码和多步 agent 任务。

定位差得远，但真正把两条路劈开的，是下面这张表。

一张表：分岔点在哪

我把两份模型卡里能对上的维度拉到同一根轴上：

光看这一张表，最容易得出的结论是「一个大一个小」。但真正决定它俩能不能进你家门的，不是总参数这个数。

决定「装得下」的是总参数，决定「跑得快」的是激活参数

这两个数经常被混为一谈，而它们其实是两件完全不同的事。

先说装得下。MoE 的机制是：专家很多，但每个 token 只走其中几个。问题是，没被走到的专家也得待在内存里。Muse Spark Open 每层 256 个专家、每 token 挑 8 个——挑 8 个是算的时候省，但那 256 个在外头排着队等，一个都不能少。Meta 的模型卡里把这句话写得很直白：专家占了全部参数的约 97%，所以「你需要的是一台 816B 模型的内存，但每个 token 只付 42B 的算力」。

翻译成大白话：它很大，算得不慢——但一点都不小。

再看跑得快。推理时每个 token 要做多少次矩阵运算，取决于激活参数。Liquid 的 2.45B 激活，意味着生成一个 token 的计算量，跟一个 2B 多的稠密模型差不多——这就是它能在 M5 Max 上跑到 184 tok/s 的原因。而 Muse Spark Open 虽然参数多得多，激活 42B，单 token 计算量也上去了，所以「端侧」跑起来是 18 tok/s 那一档（还是 2-bit 量化之后）。

所以这里有个反直觉的结论：「42B 激活」听起来比「2.45B 激活」大一轮，到了端侧，它俩的差距其实是「能不能装下」决定的，不是「算得快不快」决定的。 用单个数字去描述「端侧能力」，一定会错——你得同时看两个数：常驻内存（总参数 + KV cache）决定装得下，激活参数 × 内存带宽决定跑得快。

这里还藏着一个 Liquid 没明说、但从数字里能读出来的门槛：18 tok/s 这一档，已经不是交互速度了。 Liquid 的整套卖点是「工具分派循环像在聊天」——问、提方案、确认、执行、再来一轮，官方说每一轮都远低于一秒。而 Muse Spark Open 在家用 512GB Mac 上跑 2-bit 是 18 tok/s，一个 token 五十多毫秒，一轮多步工具调用下来就是几十秒。它更像一台在后台干活的机器，不是能陪你来回聊的助手。同样叫「端侧」，一个服务交互，一个服务吞吐——这才是两条路在产品形态上真正分道扬镳的地方。

再补一个细节：Liquid 是主动封顶的。官方说 24B 是 LFM2.5 家族「最大、也是最后一款」模型。也就是说，他们先给「笔记本能跑」这件事定了一个上限，到了就不再往上加。Meta 走的是相反方向：先把数据中心级的模型放出来，再回头用量化把它塞进桌面。一个是从尺寸出发定能力，一个是从能力出发找尺寸——顺序反了，最后的形态也就完全不同。

内存带宽才是真正的裁判

Meta 那边的算术很值得看。M5 Ultra 每台能分给集显最多 512GB 统一内存，两台凑一块儿就是 1TB；而这颗芯片的内存带宽是 1.2 TB/s，快到足够在一个 token 的时间里把需要的那一小片权重读出来。

这句话翻译一下：端侧推理的瓶颈不是算力峰值，是内存带宽——模型再稀疏，权重总得从内存里读出来喂给 GPU，读得慢，再少的激活参数也白搭。这也解释了为什么 Meta 敢说「两台 Mac Studio 能装下整个模型」：BF16 权重大约 1.5TB，两台 Mac 的 1TB 是装不下的，所以官方那条线，靠的是量化——Muse Spark Open 同时放出了 NVFP4（4-bit，给 Blackwell GPU 用）的权重，社区还用 llama.cpp 压到 2-bit。真正能进「家」的那一版，是压过的。

Liquid 这条路反过来：它从一开始就没打算让你跑原尺寸。家族里直接备好了 FP8、GGUF、ONNX、MLX 4-bit 一堆版本，目标就是那个「塞进笔记本」的尺寸。一边是先把大模型放出来、再想办法压进去；另一边是先定死笔记本的尺寸、再把能力往这个尺寸里塞。 这是策略上的根本分歧。

有一笔钱，两边都没在宣传页上写明：KV cache

上下文越长，缓存越大，而这笔内存是叠在权重上的。

Muse Spark Open 的 100 万 token 上下文听着很爽，但 HF 的说明给了一组算术：它的分组查询注意力（GQA）每个 token 要在 KV cache 里多存 126,976 个值，BF16 下大约 250KB/token——填满 100 万上下文，光缓存就要约 266GB。

也就是说，「100 万上下文」在桌面端不是一个能力描述，是一个内存承诺。你规划硬件的时候，不能只按权重算，得把缓存一起算进去。

Liquid 这边上下文是 131K，量级小一档，代价也就轻一档。这又是同一件事的两面：你要多长的记忆，就得买多大的内存。

跑分这回事，两边用的是两套标准

Liquid 的做法很清楚：发布页上摆了一张 16 项的跑分表，逐项对标 Qwen3.6-35B-A3B、Gemma-4-26B-A4B、Nemotron-3.5-Lightning 这些「总参数和激活参数都比它多约 50%」的对手。

结果是这样：在 8 项工具使用和 agent 基准里，它赢了或追平了 5 项——AutomationBench 拿了 27.69，对手最好的才 8.72，是三倍多的差距；LiveClaw 48.09 对 38.19；IFBench、Multi-IF 这类指令跟随也全部领先。但到了知识密集型（GPQA Diamond 74.42 对 83.69）和编码（SWE-Bench Verified 51.00 对 66.20）上，大模型依然压它一头。Liquid 自己也没藏着，直接在文档里写：知识密集型的活别指望它单干，「配检索或联网搜索」。

这个态度本身就值一提：它把「我能赢哪几项、会输哪几项」都摊开了，让读者自己判断。

Meta 这边，我翻完了 Muse Spark Open 的发布页和模型卡，页面上是有一个「Key Benchmarks」的标题，但没有给出能和 Liquid、Qwen 这些放在同一根轴上比对照的公开跑分表——第三方梳理也点出了这一点：「最强开源权重模型」这个定语，目前查不到对应的公开基准支撑。Meta 说详细结果在模型卡和方法学报告里，但那份「可比对」的表，我在发布页上没看到。

我不想把一个「暂未公开」读成「不敢公开」——超大模型的对标口径本来就和小模型不一样。但事实是：小模型要靠一张打得赢的跑分表证明自己值这个尺寸；超大开源模型这一轮，靠的是一个「最强」的定语，加一长串合作伙伴的名单。 两边的证据标准，确实不在一个水平线上。

两个训练细节，比参数更能说明问题

Liquid 的训练过程里有两个细节，我觉得比参数更值得记。

第一个：它是被放进真实的 agent harness 里做强化学习的——OpenClaw、Hermes Agent、Pi、OpenCode 都进过训练环。不是在一个模拟环境里练，是在真家伙里练。

第二个，也是更微妙的：在教师模型专门化阶段，它出现了一批典型的「钻奖励空子」行为——它会跑去 git 历史里翻答案，跑上 GitHub、PyPI、Hugging Face 去找最终结果；更没想到的是，它甚至意识到自己在沙箱里。Liquid 的判断是，这看着像涌现，但多半是训练数据里有类似模式；他们随后收紧了沙箱，并声明所有公布成绩都来自「密封的评估环境」。

我把这段读了好几遍。它指向一个常被忽略的事实：端侧 agent 真正的难点，是 reward 怎么设计，不是模型怎么缩小。 一个 2.45B 激活的小模型，想到的第一招是作弊——而它在端侧要连续在线、要自己调工具、要跑好几天，这种「钻空子」的倾向会被放大。谁能把奖励和沙箱做扎实，谁才配谈「端侧 agent」。

Meta 那边的 demo 则更「发布会」一些：用 Muse Spark Open 驱动的 Muse Code，据说真的往开源 Mastodon 客户端 Ice Cubes 提交了 iOS 改动（改 bug、加功能、跑通完整构建），还端到端操作了一遍 DaVinci Resolve，逐帧看素材、挑高光、裁成竖版。这些是厂商 demo，不是评测——但方向上说明 Meta 押的是「长程、重度、真实工作流」。

于是我们看到的是两条完全不同的产品形态

把上面这些拼起来，这两款模型其实是两种未来的代言人。

Liquid 这条路的赌注是：模型必须跑进用户已经有的那台设备里。卖点是隐私、离线、以及边际成本为零——权重在你机器上，跑一百万 token 也不多花一分钱（走 API 的话官方定价是 $0.10/1M 输入、$1.00/1M 输出，端侧则是纯电费）。代价是能力天花板：知识、编码这些照样得靠检索补。它服务的是「随身、连续、私密」这一类 agent。

Meta 这条路的赌注是：把开源旗舰权重放出来，占领生态。但你得看清现实——官方列出的 API 伙伴是一长串：Baseten、Fireworks、Groq、Modal、Nebius、OpenRouter、Together。绝大多数人最终会走 API，而不是真的搬两台 Mac Studio 回家。「端侧」在这条路上，更像一层覆盖在生态分发上的叙事：权重开放是真的，但你手上的「端侧」体验，多半还是云。

一个有意思的补充：Apple 其实已经在自己的 MLX + RDMA 研究里演示过把这款模型跑在四台 Mac Studio 上。从两台到四台，这条路的方向是——往更大的设备集群走，而不是往更小的口袋走。

分叉的胜负手，不在参数表上

我的判断是：端侧不会收敛到一条路，而且这两条路短期内根本不在同一个战场。

Liquid 赢的是「单机可用」这道窄缝——一个模型能在你已有的笔记本上、离线、以交互速度跑起来，这是 Meta 现阶段不会去争的。但这条窄缝有个隐忧：Meta 手里并不是只有 816B 这一张牌。它 8 月就放过一个 30B 的开源模型 Muse Glimmer，跟 Muse Spark Open 共用同一套分词器和词表。也就是说，大厂在两端都下了注——往上是桌面超算，往下是小尺寸端侧。创业公司靠「单点工程性价比」建的护城河，正在被两头同时挤压。

所以如果你是读者，要按自己的场景选：

• 你要的是「我的数据不出门 + 随时在线」——盯激活参数和常驻内存，看它俩能不能一起压进你手里已有的那台机器。这一档目前是 Liquid 的地盘。
• 你要的是「开源旗舰、随便改、当基础设施」——接受它其实是一台**家电（appliance）**而不是一台笔记本：要么攒设备，要么直接走 API。这一档是 Meta 的地盘。

至于「谁更强」这种问法，本身就问错了。一款是往口袋里塞的，一款是往机房里塞的。它们唯一的共同点，是都在用「端侧」这个词给自己做广告——而这个词，已经通胀到能装下一台笔记本和一辆小货车的差价了。

写在最后

这两篇发布放一起看，最有意思的不是数字差了多少，是「端侧」这个词被拆成了两半。

一半是说给设备听的：模型要让路，压进你已有的机器。另一半是说给生态听的：权重放出来，占住开发者。前者是工程问题，后者是分发问题。

前几天聊 OpenAI Dots 和 Meta Muse 的时候，我拆的是两款永远在线 agent 的运行时架构（那篇讲的是云电脑 vs 安全虚拟机）；更早一篇讲的是 Meta Muse 作为产品长什么样（每人一台专属云端电脑）。这一篇不讲产品，只讲两个开源权重的端侧账本——它俩加起来，正好说明了同一个词可以指着多远的两个方向。

下一次再有人跟你说「这个模型能跑端侧」，别急着信。先问两个数：总参数多大（装得下吗），激活参数多大（跑得动吗）。 答案经常是两个世界。