Muse Glimmer 30B：512k上下文

我的周末趣味项目是尝试让新的Muse Glimmer 30B模型支持更长上下文，首先决定设定为512k。我原以为会需要常见的YaRN调整或LoRA适配。我大错特错了。仔细观察后发现，Glimmer在架构上非常独特。在其他模型中让长上下文适配变得困难的因素——带有令牌位置编码的全注意力层——在这里根本不存在。相反，只有2048令牌宽的SWA层使用了RoPE，而完整的GQA注意力层完全没有位置编码。似乎该模型被训练为从上下文和SWA层中推断长距离令牌关系来工作。这是一个相当大胆的架构赌注，但Meta似乎成功实现了。因此，该模型架构似乎特别适合通过简单的机械手段扩展上下文。要将模型上下文长度从默认的128k更改为512k，只需将配置设置中的“max_position_embeddings”从131072改为524288。在其他模型如Qwen3.5系列中令人困惑的问题，Glimmer却轻松应对。我在DGX Spark上花费了近70小时的计算资源，测试了默认模型在扩展上下文下的各种基准，并在全精度模型上发现以下结果：大海捞针，1针和4针：在高达512k令牌时达到100%；多跳检索：在高达512k令牌时达到100%；语义查找：在高达512k令牌时达到100%；整个上下文中的实例计数：从32k时的95%下降到385k时的约60%，然后在512k时降至22%；模拟代理会话中的内存使用：在高达385k时达到100%，然后略有下降；NoLiMa：结果有些嘈杂，但在高达512k的所有上下文中似乎稳定；LongBench v2：在高达512k令牌时性能相同；LongCodeQA：在高达512k令牌时性能相同；我还尝试了InfBench套件，但结果有些嘈杂，我仍在努力优化。完整的研究档案、脚本和报告公开在这里：https://github.com/lobanov/muse-glimmer-long-ctx