Meta 这个 30B 把我三条理由全接住了，我卡在另一条上

Hello，我是飞飞。

Meta 昨天开源了一个叫 Muse Glimmer 的模型，300 亿参数，Apache 2.0，说是专门给「常驻在你机器上的 agent」做的。

我得先交代一件事：本地模型这个话题，两周内我已经写过两回了。

七月二十八号写 Deltafin 把 K3 塞进 64G 的 Mac，结论是装得进但太慢。八月四号写 iPhone 上真跑起了 35B，同一把尺子量下来还是同一个答案。按理说该换换口味了。

我今天还写，是因为这次多了三样以前没同时出现过的东西：为常驻 agent 调的、四比特量化后二十来 G 就够、Apache 2.0 可以商用。

前两次我那把尺子卡在容量和速度上。这次这三样凑齐了，我得重新量一遍。

凭什么还写这一篇

先把新东西摆清楚，下面这些数我一个都没测过。

它是 30B 的 dense 模型，27.9B 的文本解码器加 1.9B 的视觉编码器，从 Meta 更大的 Muse Spark 蒸出来的。

注意 dense 这个词，等会儿要用。

内存这条得掰清楚，因为传得最广的说法有点糊。

全精度要五十五 G 以上，Meta 自己都说消费级硬件够不着。压到四比特之后，模型本体不到二十 G。

官方原话是，剩下的空间刚好够用。二十四 G 或三十二 G 的盘子里，还塞得下 KV 缓存、视觉编码器，和推测解码用的那个小模型。

所以「24G 能跑」是真的，但它是量化之后的事，不是原生。

速度这块，单张 AMD Radeon AI PRO R9700 上最高 53 tok/s，AMD 那颗 Ryzen AI Max+ 395 上最高 24 tok/s，RTX 5090 上单用户解码 236 tok/s。

我跑 Mac，所以最想看的是 Apple 芯片上的数。LMSYS 那篇说测了 M5 Pro，可我没扒到具体数字，Ollama 页面也不给。这条我没核到，如实说。

我留本地的那三条

七月我写过一篇讲本地和云那条线，里面把我为什么非留着本地不可，掰成了三条。

数据不出这台机器。断网了照样能跑。模型下下来之后，推理不再计费。

这三条是我的判据，现在拿它们逐条对一遍。

数据不出机器，满足。而且 Meta 专门往这个方向训过，官方说训练目标里包含少外泄、抗住来自不可信内容的提示注入、守住信息边界。

断网能跑，满足。这条比看上去值钱。Deltafin 那个流式模式虽然只占两百多 G 磁盘，可它是边跑边从 HuggingFace 拉专家权重，断网就废。Muse Glimmer 是权重整个躺在你盘上。

推理不计费，满足，而且这次多了一层。Apache 2.0 意味着能商用、能改、能再分发。以前不少开源模型的许可，正经拿去做产品之前得先请法务看一眼。

三条全中。

速度这关它过了

现在轮到那把尺子。

我量本地模型只问一句：这次是不是人在盯着屏幕等。人坐那儿等它吐字，慢一秒都难受。活能挂后台异步跑，慢点无所谓。

七月底 K3 那次，这把尺子直接被量废了。14.6 秒才蹦一个字，挂后台跑一篇稿要十二个小时，连异步这条退路都堵死。

我当时还留了个估法：别看参数量，看激活参数量和你机器的内存带宽。

这就是 dense 这个词该拿出来用的地方。

K3 是 2.8T 总参数但每次只激活 104B 的混合专家模型。Muse Glimmer 是 30B dense，每次全都要过一遍。听起来后者更亏，可你把数放一块看：104B 对 30B，还是量化到四比特之后的 30B。

打个比方，K3 那种是仓库特别大但每次只从几个货架取货，问题是那几个货架本身就重得搬不动。Muse Glimmer 是整个仓库小到你可以一趟全搬完。

24 到 53 tok/s 是什么概念。我在 M1 上跑 gemma4:e4b 大概是一秒二十到四十个字，就是那个体感。这个速度我用得下去。

所以速度这关，它大概率过了。

我卡住的是另一条

三条理由全中，速度也过了。那我今天就该去下权重了，对吧。

说真的，我没有。

七月十三号我写过一篇，OpenAI 的员工在推上手把手教人五分钟把 Claude Code 的后端换成 GPT-5.6 Sol，四行 alias 的事。我盯着那四行看了半天，没敢按。

当时我写下的理由是这么一句：门槛低成这样，恰恰是我最不敢按的地方。它跑得越顺，越照不出哪里已经悄悄错了。

我怕的是一个具体的场景。

有人踩过这么个坑。模型给工具参数全填了默认值，一大批文件读进来是空的。可这些调用一个错都没报，跑通率照样满格，界面上不飘一点红。这道空读悄悄跑了三天，才有人回头发现。

我那条发号的流水线是一模一样的结构。Claude Code 认得 frontmatter，才拼得对图文。真换了个模型，它把某个字段悄悄填成默认值，渲染照样成功，草稿照样进箱，等我点开才看出封面早填岔了。

这就像体检报告上每一项都是绿的，你以为自己没事，可病恰好在那份报告没测的那一项上。指标全绿不等于身体没病，它只等于你测的那几项没病。

你知道吗，Muse Glimmer 的官方卖点里正好有一条是冲着这个来的，叫失败恢复。

说明写得很清楚：工具调用失败、或者返回了意外结果，模型会自己诊断错误再重试，而不是停在那儿干等。

我读到这条的时候愣了一下。它擦着我那个恐惧过去了，可没打中。

它解的是「摔了能自己爬起来」。我怕的是「压根没摔，可它填错了，而且不报错」。前者是有个错误信号摆在那儿等着被处理，后者是从头到尾没有信号。这两件事隔着一整层。

说白了，失败恢复给体检报告加了一项「指标异常自动复查」，可它复查的还是原来那几项。

我下周先接哪一段

所以这次的结论跟前两次不一样了。

前两次我说的是「跑不动」，模型那头就把路堵死了。这次它跑得动，路通了，可拦住我的东西挪到了我这头：我没有一套能看出它悄悄填错的办法。

顺带说一句，Meta 自己在模型卡里写着，在能触发真实动作的 agent 场景里，建议给不可逆的操作加人工确认。厂商比营销号清醒。

有一条路我看了挺动心。Ollama 已经支持它了，虽然眼下只在 Apple 芯片的 MLX 引擎上，命令长这样：ollama launch claude --model muse-glimmer:30b-mlx。

你注意这个 claude。它换的是发动机，车还是原来那台。我那十几个 skill 是照着 Claude Code 的脾气一点点抠出来的，谁认 frontmatter、谁按什么顺序加载、hook 在哪个时机触发，全焊在这套壳上。能保住壳只换模型，迁移成本就完全是另一个量级。

不过还有件事得说明白。有人指出，跨会话接着干活这个能力是那层壳给的，不是模型给的。所以换了模型之后，壳还在，可壳和新模型之间那些没写进文档的默契，得重新验一遍。

我下周打算这么干。不整条流水线切，先挑最不怕出错的那一段：调研阶段抓网页、提摘要。这段出错了我一眼能看出来，重跑一次也不心疼。切过去跑一周，专门盯一件事，就是工具调用的参数有没有被悄悄填成默认值。

给你一个今天就能做的判断。别先看参数量，去查你那台机器的内存带宽，再拿激活参数量除一除，这比翻一晚上教程管用。然后问自己那三条：数据要不要留在本地、断网要不要还能干活、推理费用疼不疼。三条占不到两条，本地这条线对你就是个玩具。

你把 agent 搬到本地了吗？如果没搬，是嫌它跑不动，还是跟我一样，卡在「我不知道怎么验它有没有跑对」这件事上？评论区聊聊。