Meta 时隔 16 个月重回开源，这次放出来的是 Muse Glimmer，一个 30B 参数的本地 Agent 模型，从自家旗舰 Muse Spark 蒸馏而来，单张 24GB 显卡就能跑，Apache 2.0 协议。我把 17GB 量化版装进单张 RTX 4090，重点测了它主推的 DFlash 推测解码。官方默认参数在消费卡上是个坑，不改白丢一截速度。
省流版 模型定位是本地 Agent 特化 ：从旗舰 Muse Spark 蒸馏出 Agent 能力，多步推理、工具调用、多模态、失败恢复塞进一个 30B 模型，单卡 24GB 跑得动 同级 Agent 能力断层领先 ：MCP Atlas 75.5，把 Gemma4-31B（54.2）和 Qwen3.6-27B（62.5）都压在下面，SWE-Bench Verified 76（官方数据，尚无第三方验证） DFlash 调成 n-max=3，速度提 24% ：官方默认的 n-max=15 在 4090 上草稿接受率只有 16%，改成 n-max=3 + p-min=0.2 后涨到 62%，生成速度从 75.8 提到 93.8 tok/s 单卡够用，不必双卡 ：单张 4090 跑 17GB 版，速度和双 4090 跑更大的 dynamic 版差不多，省一张卡干别的它是同级里 Agent 能力最完整的本地模型，但 DFlash 的官方默认参数你得自己改，否则白白慢一截。
Muse Glimmer 是什么 它是 Meta 超智能实验室的产品，29.6B 参数，其中约 1.8B 是一个 ViT-G/14 视觉编码器，专门处理图像输入。模型本身是个稠密因果 Transformer，128K 上下文，能看屏幕截图、能调工具、工具调用失败会自己诊断重试，而不是停在原地。
它不是从零炼的，是从 Meta 更大的旗舰 Muse Spark 蒸馏来的。就像 Muse Spark 是个全能的大师傅，Muse Glimmer 把它手里"干 Agent 活"的那套手艺单独提出来，浓缩成一个能在你电脑上跑的小版本。参数量比 Spark 小一截，但 Agent 任务上的能力刻意保住了。
官方基准，和两个同体量对手摆一起：
基准 Muse Glimmer 30B Gemma4-31B Qwen3.6-27B MCP Atlas 75.5 54.2 62.5 DeepSearch QA 74.6 61.7 71.1 SWE-Bench Verified 76.0 66.6 77.2 SWE-Bench Pro 51.2 36.9 50.2 这是官方数据，模型发布太新还没有第三方独立评测，先按官方口径看。但即便是官方自己量的，MCP Atlas 这种测"模型接进脚手架后事情能不能办成"的基准上，30B 的 Glimmer 比 31B 的 Gemma4 高出 20 多分，同级里断层领先。SWE-Bench Verified 上略输 Qwen3.6-27B 一点（76 vs 77.2），但 SWE-Bench Pro 这种更难的现实工程任务上又反超回来。
在 30B 这个消费级能跑的量级里，Muse Glimmer 的 Agent 能力是目前最完整的。这也是为什么值得花力气把它在本地调通。
量化与显存门槛 本地能跑的前提是量化。Muse Glimmer 官方给了两个量化版本，区别在体积和精度：
版本 体积 目标显存 性能下降 kquant-17gb 16.8GB 24GB 约 1.0% kquant-dynamic 19.7GB 32GB 约 0.2% 性能下降是官方在 15 个基准上平均算的。dynamic 版精度更好（只掉 0.2%），门槛是 32GB 显存；17GB 版掉 1%，单张 24GB 卡就能塞下。
我的情况是单张 RTX 4090，24GB 显存，所以选 17GB 版。主模型 16.8GB，加 1.4GB 的视觉编码器 mmproj，加 1.6GB 的 DFlash 草稿模型，再留点给 KV cache 和上下文，24GB 刚好卡住。如果你是 32GB 的卡或者有两张卡，可以上 dynamic 榨精度；单张 24GB 卡没得选，就是 17GB。
量化几乎不掉智（官方验证 1% 以内），才是这类 30B 模型能在消费级显卡上谈"跑得动"的前提。
DFlash 推测解码 Muse Glimmer 主推的加速技术叫 DFlash，属于推测解码这一类。
普通大模型生成文本是一个字一个字往外蹦，每蹦一个字都要回头把前面所有字重新过一遍。这个逐字生成的过程叫 decode，是推理里最吃资源的环节。推测解码的思路是：派一个又小又快的草稿模型先猜接下来好几个字，再让主模型一次性并行验证，猜对的全采纳，猜错的从错处重写。验证是并行的，一次能验好几个，整体就比逐字快，而且输出质量和主模型完全一致，无损。
DFlash 和 MTP、Eagle3 的区别在草稿怎么猜。MTP 是主模型自带几个预测头顺带猜，Eagle3 是草稿模型逐字串行猜；DFlash 用的是一个块扩散模型，一次性并行吐出一整块 16 个 token，不是一个个串行写出来。
逐字串行像一个字一个字写，每写一个回头看一眼前面；DFlash 是一挥手同时写一整行，写得快，但这一行后面的字在写的时候还看不到前面的字最终被定成什么样。
官方 llama.cpp 示例给 DFlash 的默认配置是 --spec-draft-n-max 15 ，意思是让草稿一次最多猜 15 个 token。我在 4090 上按这个默认值跑，草稿接受率只有 16%，生成速度 75.8 tok/s。意思是 DFlash 猜出来的候选 token，主模型只接受了 16%，剩下 84% 全是白算。日志里 4690 个被接受，29265 个被生成，大量推测算力在做无用功。
调到 n-max=3 的甜点位 我把 --spec-draft-n-max 从 15 改成 3，加上 --spec-draft-p-min 0.2 ，其他参数全部不动，再重测：
配置 草稿接受率 mean len 生成速度 n-max=15（默认） 16.0% 3.40 75.8 tok/s n-max=3 + p-min=0.2 62.1% 2.82 93.8 tok/s 接受率从 16% 直接涨到 62%，生成速度从 75.8 提到 93.8 tok/s，提升约 24%。看实时日志，在 DFlash 连续命中的片段里，4090 能短时间冲到 120 到 126 tok/s。
93.8 tok/s 是短 prompt 测出来的；同样这套 n-max=3 参数，换长 prompt（约 5900 token 输入）测，速度落在 84 tok/s 左右、接受率 53% 左右。生成速度会随 prompt 长度浮动，但接受率从 16% 跳到 50% 到 60% 这个量级，是稳的，不随 prompt 变。这次调参真正坐实的，是接受率数量级的跃升，速度提升是它的结果。
不是接受率越高就一定越快，最终以 tok/s 为准；但对这张 4090，n-max=3 就是甜点位。
为什么少猜反而快 DFlash 一次并行吐一整块 16 个 token，草稿算得快，一次前向传播就够；代价是块里后面的 token 在生成时看不到前面 token 的最终采样结果，越往块尾走猜测越不靠谱。
n-max=15 等于把这块里最不靠谱的那十几个位置也一起算上，主模型验证完大半扔掉，白费。n-max=3 是只取最靠谱的前几个，接受率自然高，主模型也不用反复验一堆废候选。少猜，反而准，反而快。
这也能解释官方那个 233.4 tok/s 的数字。官方测的是 RTX 5090，17GB 模型 + DFlash + 贪心解码 + batch size 1，路径和我这次一样，区别只在卡。5090 算力大，单次验证更快，绝对速度冲得上。4090 复现不了 233，但调对参数能稳在 90 tok/s 以上、峰值 120 多 tok/s。
少猜比多猜快，是 DFlash 块扩散结构的必然结果。
单卡还是双卡 我之前用两张 4090 跑过更大的 dynamic 版（19.7GB，需要双卡分摊），长期生成速度在 60 到 99 tok/s 之间晃，草稿接受率 9% 到 27%。这次单张 4090 跑 17GB 版，调对参数后是 84 到 94 tok/s。
方案 生成速度 草稿接受率 占用 双 4090 + dynamic（19.7GB） 60 到 99 tok/s 9% 到 27% 两张卡 单 4090 + 17GB + n-max=3 84 到 94 tok/s 53% 到 62% 一张卡 为了单请求的生成速度，没必要上双卡。单张 4090 跑 17GB 已经能到差不多甚至更好的区间，还省出一张卡。双卡唯一值得的理由，是你要跑 dynamic 榨那 0.8% 的精度，或者要同时开多个并发请求。单请求测速、日常对话、本地 Agent 交互，单卡够用。
部署踩坑 一是 llama.cpp 版本。Muse Glimmer 的架构支持是 2026 年 8 月 10 日才合并进 llama.cpp 的（PR #26841 ），要构建版本 b10353 或更新才行，老版本根本不认识这个架构，会拒绝加载。先 ./llama-server --version 确认。
二是 --jinja 不能省。这批 GGUF 里嵌了聊天模板，必须加 --jinja 让它用内置模板，否则多模态的 llama-mtmd-cli 直接报错退出。
三是上下文会被切分。llama-server 会把 -c 按 -np （并发槽数）平分，单个请求实际拿到的是 -c / -np 。看启动日志里的 n_ctx_slot 才是单请求真实上下文。跑评测尤其要注意，上下文不够不会报错，只会静默不出答案，分数掉下来日志里还没任何解释。
四是推理关不掉，只能调强度。模板里推理通道是无条件开的， --reasoning off 没用，能调的是强度 low/medium/high/xhigh，默认 high。复杂任务用 high 或 xhigh，想快用 low。
还有一个已知问题：第一次真正喂图片之后，prefill 速度会掉一截（比如从 3000 多 tok/s 掉到 1800 多），而且即使清空上下文也不会恢复。这是 llama.cpp 上还开着的 issue，影响的是 prefill 不是生成，但要知道有这回事。
写在最后 Muse Glimmer 是我最近测下来，30B 这个消费级能跑的量级里 Agent 能力最完整的本地模型，多步推理、工具调用、多模态、失败恢复一把抓。但 DFlash 加速的官方默认参数是按旗舰卡设的，单张 4090 上不改就是白丢速度，n-max=3 才是甜点位。
官方基准先看着，等第三方独立评测出来再复核一遍能力含金量。
我是寂寞的熊猫，感谢你读到这里。
