Meta 把开源模型的甜点,卡在了 24GB 显存上

Meta 今天又扔了一颗炸弹:Muse Glimmer,30B 参数,Apache 2.0,专门给本地 Agent 场景。4bit 量化压到 17GB,24GB 显存就能跑,transformers、llama.cpp、vLLM、MLX 全都有 Day-0 支持。

初看很香。但看多了这类发布,我开始觉得 30B 不是一个偶然的数字,而是开源模型的新天花板。

30B 是甜点,也是天花板

模型卡上写得明白:全精度 BF16 要 64GB,K-Quant-Dynamic 32GB,K-Quant-17GB 压到 24GB。Meta 花了不少力气证明 4bit 量化对 Agent 任务几乎没有衰减。

这说明他们不是想做最大的开源模型,而是想做刚好能塞进你现有显卡的最大开源模型。24GB 这个档位的消费卡,养一个 30B 多模态 Agent 刚好,再往上就得换设备了。

这尺寸不是技术极限。Kimi K3 开源了 2.8T,Qwen 3.8 pledged 2.4T。万亿参数的模型仍然在开,但它们显然不是为了让你本地跑。

Muse Glimmer 量化档位与显存门槛

本地主义的胜利?更像是商业分层

Meta 不是第一次玩这套。Muse Spark 1.2 有云端付费版,Glimmer 是本地免费版。两者差的不是全部能力,而是商业模式:一个按 token 卖,一个让你自己掏电费和硬件。

有人算过,27B-30B 这一档的开源模型,发布方大都同时卖着云端高级版。把这一档开源,通常不会冲击付费墙,反而能培养一批愿意为上游买单的用户。

所以别把这件事浪漫化成”开放权重战胜闭源”。Apache 2.0 是真的,权重可以改,代码可以 fork,这对开发者是好处。但 Meta 没有开放最大的那块蛋糕,只是把入口层的蛋糕免费了。

Benchmark 也没有一边倒

Muse Glimmer 与同尺寸模型基准对比

从官方数据看,Muse Glimmer 在 MCP Atlas 和 DeepSearch QA 上领先同尺寸对手,但 SWE-Bench Verified 和 OSWorld-Verified 还是 Qwen3.6-27B 更高,Gemma4-31B 在 GPQA Diamond 上略胜。

它不是全面领先,只是在”本地能跑”这个约束下把能做的都做了。把它塞进家里一台机器当 Agent 基线,靠的不是碾压,而是够用。

我会怎么用它

作为一个长期本地跑模型的人,我欢迎 Day-0 生态支持。这意味着 Agent 脚手架、工具调用、多模态输入会多一个稳定的本地基线,不用再靠 7B 小模型硬撑复杂任务。

但 30B 不会替换我手里的 35B 级本地模型,也不会替换偶尔调用的云端 API。它更像一个新的中间层:比 13B 能做事,比闭源旗舰便宜且私密。

真正的分界不是参数量,而是你愿不愿意让模型离开你的机器。只要答案是不愿意,30B 这个天花板就会一直卡在那里。

发表评论