Tomas Koutsky 解释了 Meta 如何在 24 GB 的容量内容纳 Muse Glimmer
Meta 表示其 30B 本地代理可在配备 24 GB 或 32 GB 内存的系统中运行,并且能够与 131K 上下文、视觉编码器和投机性草拟器一起共存。Byteline 联合创始人 Tomas Koutsky 解释了内存算术。
By RuntimeWire Staff · Published
Primary source: Abstract Extraordinary
Why it matters
Muse Glimmer shows how a 30B local agent can preserve a 131K-token context without allowing its attention cache to consume most device memory. Actual performance still depends on prompt-processing time and whether the serving engine implements the sliding-window cache efficiently.

Meta 已发布 Muse Glimmer,一款 300 亿 参数的多模态代理,旨在在配备 24 GB 或 32 GB 内存的消费级硬件上运行。Tomas Koutsky,AI 工作流初创公司 Byteline 的联合创始人,研究了 Meta 如何在同一台设备上为模型、一个 131,072 个标记的上下文、一个视觉编码器和一个推测性解码模型腾出空间。
Koutsky 以代理系统构建者的视角来审视该架构。他于 2025 年共同创立了 Byteline,让用户通过自然语言对话协调多个 AI 代理。他此前在 Pipedrive 和 Streetbees 担任工程师职务,此后领导过 BRAHMA AI 和 Metaphysic.ai 的工程工作。他于 8 月 18 日发布的 Muse Glimmer 分析 将该模型描述为围绕窄键值缓存构建的记忆层次结构。
Meta 将权重压缩到低于 20 GB
Meta 于 8 月 10 日 发布了 Muse Glimmer,并采用 Apache 2.0 许可证发布。Meta 将其描述为一个用于本地编码、函数调用、工具使用和扩展代理工作流的密集多模态模型,无需云连接。RuntimeWire 报道了该开源权重发布,包括 Meta 声称其量化配置可以在 24 GB 或 32 GB 的内存范围内运行的说法。
未压缩的检查点将消耗超过 55 GB。Meta 表示,约 4 位量化将语言模型减少到小于 20 GB,从而为键值缓存、感知编码器和 DFlash 推测起草器留下空间。
Meta 在 M4 Max 和 M5 Max MacBooks 以及一块 Nvidia RTX 5090 上测试了其 K-Quant-17GB 配置和量化的 DFlash 起草器。该起草器提出由主模型并行验证的标记块。Meta 报告在 RTX 5090 上解码加速为 3.1 倍,在 M5 Max 上为 1.8 倍,在 M4 Max 上为 1.5 倍。
Koutsky 估算 Muse Glimmer 大约包含 297.77 亿个参数。52 个文本 Transformer 块约占 251.65 亿个参数,而视觉塔约含 18.53 亿个参数。他估算总 BF16 存储约为 55.46 GiB,包括嵌入、未绑定的输出头以及视觉与语言组件之间的桥接。
窄缓存为长上下文留出空间
Muse Glimmer 限制了随每个标记增长的内存。在其 52 个文本层中,有 39 层关注一个 2,048 标记的滑动窗口,13 层可以检查完整序列。模型还使用 32 个查询头和两个键值头。当前标记的查询可以被丢弃,而早期标记的键和值在生成过程中仍可用。存储两个键值库而不是 32 个减少了每个活动序列累积的状态。
Koutsky 估算在完整 131,072 个标记的上下文下,活动的 BF16 或 FP16 键值缓存约为 1.70 GiB。13 个全局层约占 1.625 GiB,本地层在其窗口填满后约分配到 78 MiB。
该估算取决于服务实现。Koutsky 说,引擎必须从滑动窗口层中驱逐或循环重用过时条目以实现这些节省。对整个序列进行静态分配将消耗大量更多内存。缓存量化、页大小、碎片和运行时工作区也会改变测得的使用量。
39 层使用 2,048 标记的滑动窗口,而每第四层跨整个上下文进行注意力。
长上下文仍然带来计算开销
Muse Glimmer 的 13 个全局注意力层在提示处理期间执行全注意力计算。即使内存高效的内核避免存储完整的注意力矩阵,它们的注意力计算仍随序列长度呈二次增长。因此 Koutsky 的分析将内存容量与处理时间分开考虑:该架构可以使 131K 标记的上下文适配,但并不意味着其预填充的处理时间等同于短提示。
本地层和全局层分担检索工作。本地层在有界窗口内保留有序信息。周期性的全局层搜索已包含附近上下文的表示。Koutsky 指出,全局层省略了旋转位置嵌入(RoPE),并主要通过内容匹配远处的信息。
顺序信息仍通过因果掩码以及由前面三层配备 RoPE 的本地层产生的表示传递到这些层。Koutsky 认为,这种安排可以支持跨长距离的基于内容的检索。当相似段落的本地上下文没有提供足够区分时,可能更难以区分相似段落。
Meta 报告有限的量化损失
Meta 表示其量化在代理任务上产生“最小到无退化”。其发布文件在一张图表中展示了全精度、K-Quant-Dynamic 和 K-Quant-17GB 配置的准确性结果,但随附文字中并未给出单一的总体退化数值。
Meta 将 Muse Glimmer 与 Gemma 4 31B 和 Qwen3.6 27B 进行比较。其 评估方法论报告 描述了这些比较背后的框架。所报告的结果确立了 Meta 所选择的对比,而在其他代理框架和扩展个人工作流中的性能仍不在这些结果的范围内。
Koutsky 的拆解解释了支持 Meta 硬件主张的内存计算。量化降低了固定权重成本,分组查询注意力缩小了持久缓存,本地-全局层的安排限制了大多数层保留的历史量。提示处理和服务实现仍然决定了模型在接近其最大上下文时的行为。