Meta 30B 模型实测：YaRN 拉到 1M，832K 检索全通过

Reddit 用户 StartupTim 对 Meta 新发布的 Muse-Glimmer-30B 模型进行了极端上下文压力测试，借助 YaRN 将原生 131K 上下文拉伸到 1M，并在 832K token 长度下实现 3/3 大海捞针（needle-in-a-haystack）检索全部通过；同时验证了 DFlash 投机解码在该模型上可获得约 3 倍的解码速度提升。

测试环境与配置

测试硬件为 2 张 NVIDIA DGX Spark（GB10 芯片、单卡 128 GB 统一内存、理论带宽约 273 GB/s），通过 ConnectX-7 直连。推理引擎采用从源码编译的 llama.cpp master 分支，开启 CUDA sm_121 与 GGML_RPC。

模型侧使用官方 Muse-Glimmer-30B 的 GGUF K-Quant-Dynamic 量化（体积约 18.3 GiB），叠加官方 mmproj 视觉塔与 DFlash 草稿模型。上下文扩展通过 --rope-scaling yarn 配合不同的 --rope-scale（2 / 4 / 8）实现，并通过 --override-kv 把 metadata 中的 context_length 直接覆写为目标值——绕过 llama.cpp 默认不超出训练长度的限制。投机解码使用 --spec-type draft-dflash --spec-draft-n-max 15，每轮最多生成 15 个草稿 token。

检索与速度表现

大海捞针测试在 10%、50%、90% 三个深度各埋 3 根关键事实，每一档 token 数都做完整 3 根针的检索：

• 97K token（原生 131K 以内）：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 在 RTX 5090 上宣称的 3.1× 加速基本吻合；短上下文 prefill 约 700 tok/s，进入 832K 长 prompt 后降至约 390 tok/s；4 路并发时每节点聚合约 57 tok/s。

将单实例拆分到两张 Spark 上跑 llama.cpp RPC 时，解码降至 25–28 tok/s，比单卡反而慢约 30%。作者认为 20 GB 量级的模型本就不需要跨节点，layer-split 每个 token 都要走一次网络，集群化更多是出于兴趣而非性能。

其他验证项：

• 编程小套件（含 LRU cache、RFC4180 CSV 解析器、旋转二分查找等 7 道执行检查题）双卡都拿到 7/7。
• 官方 mmproj 视觉可识别形状、颜色、文本。
• 权重 + 草稿模型 + 视觉塔 + 完整 1M KV 缓存合计约占用单卡 60 GB。

为什么 YaRN 在此架构上几乎无损

Muse 的注意力布局较为特殊：39 个滑动窗口层（窗口 2048 token）保留 RoPE，13 个全局全注意力层完全没有位置编码（NoPE）。当 YaRN 将上下文拉伸 8 倍时：

• 局部层在 2K 窗口内的相对位置在任何文档长度下都一致，几乎不会受到拉伸影响。
• 真正负责在 800K token 之间搭桥的长程层本来就没有旋转位置编码可「破坏」。

此外极小的 KV 头数（仅 2 个 KV 头，且大部分分布在滑动层）也是 1M 上下文在该级别硬件上跑得起来的关键。两者叠加解释了为什么在传统全 RoPE 架构上经常掉点的 YaRN 拉伸，在这个模型上每个测试档位都能拿满。

结论与后续

作者给出的结论是：Muse-Glimmer-30B 是一个真正可用的本地 agentic 模型，可用上下文远超规格表标注；DFlash 投机解码是带宽受限硬件上「从勉强可用变得顺滑」的关键，单卡运行优于跨卡 RPC。该用户日常的对照基线是 DeepSeek-V4-Flash-0731 跑官方 vLLM、TP=2 over RDMA 全 1M 上下文，作者明确表示正在等待 vLLM 适配 muse_glimmer，以便用同样的张量并行方式做正式 A/B 对比并后续复测报告。