我在 1M 上下文下运行了 Muse Glimmer - 所有测试均通过。
摘要
用户在 2× DGX Spark 集群上测试了 Meta 的 Muse Glimmer 30B,使用 YaRN 将上下文从 131K 扩展到 1M tokens,并确认在 832K tokens 下通过检索。报告称 DFlash 投机解码带来了约 3 倍加速,并分享了完整配置。
嘿嘿,大家好!我刚刚用 Muse Glimmer 做了一些有趣的测试,想跟大家分享一下。事实上,下面的摘要就是 Muse 自己写的!我搭了一个 2× DGX Spark 集群,并在发布第二天就把 Meta 发布仅一天的 Muse Glimmer 30B 跑了起来——然后用 YaRN 把它的上下文从训练的 131K 一路推到了 1M,每一步都验证了检索能力。分享配置和结果,因为模型卡里“131,072+”的提示被证明是真实不虚的。
## 环境配置
**硬件:** 2× NVIDIA DGX Spark(GB10,每台 128 GB 统一内存,约 273 GB/s),通过 ConnectX-7 直连
**引擎:** llama.cpp master(发布首日即支持 muse_glimmer),从源码构建,启用 CUDA sm_121 + GGML_RPC
**模型:** 官方 Muse-Glimmer-30B-GGUF K-Quant-Dynamic(约 18.3 GiB)+ 官方 mmproj(视觉)+ 官方 DFlash drafter
**Spec 解码:** `--spec-type draft-dflash --spec-draft-n-max 15`(block-diffusion 草稿模型)
**上下文扩展:** `--rope-scaling yarn --rope-scale <2/4/8> --yarn-orig-ctx 131072`,外加 `--override-kv muse-glimmer.context_length=int:<N>`(否则 llama.cpp 会限制在训练长度)
是的,我们还用 llama.cpp RPC 把模型拆分到两台 Spark 上跑过——没有什么特别理由,就是喜欢把东西组集群玩。我们在这套硬件上的日常主力是官方 vLLM 上的 DeepSeek-V4-Flash-0731,通过 RDMA 跑 TP=2,完整支持 1M 上下文,这才是公平的比较基准。
## 结果
**大海捞针(3 根针,分别位于 10/50/90% 深度):**
- 97K token,原生 3/3
- 188K token,1.4× 3/3
- 415K token,2.9× 3/3
- 832K token,6.35×(最深的针约 749K)3/3
**速度:**
- 单台 Spark:基线解码约 10.5 tok/s → 使用 DFlash 后 36–38 tok/s(约 3 倍,与 Meta 在 5090 上声称的 3.1 倍一致);预填充在短上下文下约 700 tok/s,在 832K 提示的深处约 390 tok/s;×4 并发时每节点聚合约 57 tok/s
- RPC 拆分到两台 Spark:解码 25–28 tok/s——比单节点慢约 30%。一个 20 GB 的模型不需要两个节点,而按层拆分每个 token 都要付一次网络跳转的代价。好玩,但不算快。
**其他:**
- 编程:在我们的小型执行验证测试集上 7/7(LRU 缓存、RFC4180 CSV 解析器、旋转二分查找等),两个节点都通过
- 视觉通过官方 mmproj 正常工作(形状/颜色/文字读取)
- 权重 + 草稿模型 + 视觉 + 完整 1M KV ≈ 单台 Spark 约 60 GB
## 为什么 YaRN 扩展在这个模型上效果这么好(我们的理论)
Muse 的配置很不寻常:RoPE 只存在于 39 个滑动窗口层(2,048 token 窗口),而 13 个全局全注意力层完全没有位置编码(NoPE)。所以当你做 8× YaRN 拉伸时:局部层几乎无感——在 2K 窗口内,相对位置在任何文档长度下都相同;而真正桥接 800K token 的长距离层,本来就没有旋转嵌入需要去破坏。
结果:在我们测试的每一档上检索都保持完美,而传统的全 RoPE 架构通常到这里就开始拉胯了。极小的 KV(2 个 KV head,且大部分是滑动层)才是让 1M 在这类硬件上真正可用的关键。
## 结论
Muse Glimmer 30B 确实是一个强大的本地智能体模型,它的可用上下文远超规格表:只用 YaRN 参数和一个元数据覆盖,就在 832K token 上验证了 3/3 检索。在带宽受限的硬件上,DFlash spec decode 就是“密集 30B 速度没法用”和“体验舒适”之间的区别——白赚约 3 倍性能。通过 llama.cpp RPC 做集群拆分可行,但比单节点慢——不如每台机器各跑一个实例。热切期待 vLLM 支持 muse_glimmer,这样我们就能像 DeepSeek 环境一样通过 NCCL/RDMA 跑 TP=2——一旦支持落地,我们就会做 A/B 测试并汇报。
相似文章
Meta的Muse Glimmer 30B现在在Mac上通过mlx-dspark运行速度提升约3.3倍
一位开发者报告称,通过mlx-dspark中的推测解码,Meta的Muse Glimmer 30B在Apple Silicon上运行速度提升约3.3倍,输出与逐字节完全相同,且没有质量损失。
Muse Glimmer 居然真的能装进单张 RTX 3090
用户报告称,30B 参数的 Muse Glimmer 使用 Q4_K_XL 量化和 DFlash,在单张 RTX 3090 上即可运行,并支持完整的 256k 上下文,速度达到 64-124 tok/s,且长上下文检索完美,与同类模型不同。
在本地使用 OpenCode 测试 Muse Glimmer 的编码与智能体工作
一位用户分享了在 llama.cpp 上使用 OpenCode 对 Muse Glimmer(通过 Unsloth 的 Q4 量化)进行本地测试,指出其性能低于 Qwen3.6 27B,但工具调用可靠。
推出 Muse Glimmer
Meta 推出 Muse Glimmer,一款基于 Apache 2.0 协议的全新 30B 开放权重模型,针对智能体任务完成、可靠工具使用和多步推理进行了优化。Simon Willison 使用 LM Studio 和 llm-coding-agent 在本地对其进行了测试。
@ivanfioravanti: DGX Spark 上下文基准测试基于 Qwen3.6-35B-A3B-UD-Q8_K_XL,使用 Mia 发布的 llamacpp 脚本。速度很快!是时候测试质…
基于 Qwen3.6-35B-A3B-UD-Q8_K_XL 在 DGX Spark 上的基准测试结果,使用 Mia 发布的 llama.cpp 脚本,展示了在不同上下文长度下快速的 token 生成时间。