首页 / 资讯详情
深度拆解 Muse Glimmer，24GB 显存跑 30B Agent，Meta 到底做了什么？
摘要
128K 长上下文与 3.1 倍推理加速背后，Meta 正在重构本地 Agent 的底层逻辑。 作者丨郑佳美 编辑丨岑 峰 昨天，Meta 发布了 Muse Glimmer。这是一款约 30B 参数的多模态 Agent 模型，支持 128K 级上下文，可以调用工具、执行代码，也能处理图片和屏幕信息。这个模型采用 Apache 2.0 许可证开放，同时还有两套 4 bit 量化版本、独立视觉编码器和 DFlash 推理加速组件，并提供 llama.cpp、MLX、ExecuTorch 等本地部署方式。虽然 30B 的参数规模和 128K 的上下文在今天看来并不稀奇，但问题在于，Meta 想让它干的不是普通聊天，而在于建立一套完整的本地 Agent 运行范式。Muse Glimmer 面向的长期运行的本地 Agent，会面临着苛刻的工程约束：它必须在有限的 24GB 显存里，一边处理不断产生的屏幕截图，一边维持长达几十步的任务逻辑。一次任务跑上几十步以后，前面的工具结果、代码日志、页面状态和推理过程会不断留在上下文里。这时候，很多在聊天场景里不明显的问题会迅速放大。128K 上下文怎么塞进有限显存，截图越来越多以后怎么管理历史状态，工具调用失败后模型怎么接着往下走，大量 Reasoning Token 又会把 Decode 拖慢到什么程度。Muse Glimmer 的技术设计，基本就是围着这些问题展开的。它没有靠某一个特别显眼的新架构解决所有事情，而是在 Attention、KV Cache、训练方式、量化和 Decode 上进行了激进的取舍。如果说以前的本地模型是“能跑起来”，Muse Glimmer 的目标是“能像云端一样好用且连续工作”。把这些部分连起来看，比单看 30B 或 128K 更容易理解 Meta 为什么会把它做成现在这个样子。01128K 上下文怎么压进 24GB 显存Muse Glimmer 使用 52 层 Dense Transformer，Hidden Size 为 6656，有 32 个 Query Head，但只有 2 个 KV Head。Attention 也不是每层都处理完整上下文，而是采用三个 Local Attention 接一个 Global Attention 的循环方式。Local Attention 只处理附近 2048 个 Token，Global Attention 才负责更远距离的信息交换。这两个设计其实在同时压长上下文的成本。模型生成新 Token 时，会缓存前面 Token 的 Key 和 Value，也就是 KV Cache。Context 越长，这部分占用越大。Muse Glimmer 每层只有 2 个 KV Head，每个 Head Dimension 为 128。按照 BF16 粗略计算，一个 Token 在一层里的 KV 大约占 1024 Byte。雷峰网如果 52 层全部保存完整 128K Context，KV Cache 大约需要 6.5 GiB。但 Muse Glimmer 实际有 39 个 Local 层和 13 个 Global 层。Local 层只需要维护约 2048 Token 的滑动窗口，只有 Global 层需要保存完整的长上下文。按同样方式估算，KV