Meta 将 Muse Glimmer 描绘为运行在您的设备上的代理：自主、多模态、不需要云。 这是一个工程问题，就像产品声明一样：将一个能够的 30B 级模型、长期的工作历史和感知堆栈配置到消费硬件中。 答案最终是一个伪装成 30B 变压器的内存层次结构。 其模型卡直接表明了目标：Muse Glimmer 是“专为消费硬件上的自主代理任务而构建的”，并且它在“无需云基础设施或网络访问的情况下运行”。 这一承诺是非常艰巨的，因为代理的工作负载是长期的。 几小时的历史和工具记录保持在内存中，屏幕截图和文档在任务中途被重新阅读，而所有这些数据必须适应 Meta 为其量化版本命名的 24 或 32 GB 信封。 Muse Glimmer 是一个大约 30 亿参数、仅解码的多模态模型：一个视觉编码器、一个投影器和一个密集语言模型。在 BF16 中，检查点的大小约为 55 GiB，这会在产生一个上下文令牌之前溢出这两个信封，因此部分答案比较容易命名：Meta 发货约四位量化变体，使语言模型低于 20 GB。 压缩模型仍然需要与一个 131,072 令牌上下文、一个驻留的视觉塔和一个假设解码器共享卡，而当语言模型变小时，它们的大小都不会减小。 答案的其余部分是架构方面的：模型消耗内存的位置，以及每一层携带的信息类型。 Muse Glimmer 是围绕有意的劳动分工构建的。在大多数层中，注意力是局部的：由 RoPE 定位并限制在 2048 令牌窗口中。在每第四层中，注意力开放到整个上下文，但放弃了 RoPE，主要通过内容进行检索。 只有注意力是交替的；每个块的其余部分是相同的。 三十二个查询头提供了一组丰富的检索行为，而 KV 缓存中只有两个关键/值头被存储。 在视觉方面，一个大型 ViT 一次性执行昂贵的感知，将相邻补丁压缩为四比一，并将结果作为普通令牌传递给语言解码器。 总体而言，这些组件形成一个层次内存系统：局部层构建有序、上下文丰富的表示；全局层在整个序列上搜索这些表示；KV 缓存为每个活动序列存储一个非常窄的内存痕迹。 每个序列的状态小之又小，因此运行实例所需的几乎所有内存都是模型的参数。 这就是为什么权重量化在这里表现出如此优异的回报。 一旦这些固定权重被压缩，释放的内存可以转化为更长的上下文、更大的批次、驻留的感知塔或假设解码器。 55 GiB 的位置 下面是根据发布的张量形状的汇总：组件 近似参数 BF16 存储 52 文本变压器块 25.165B 46.87 GiB 输入令牌嵌入 1.345B 2.50 GiB 未绑定语言模型头 1.345B 2.50 GiB 视觉塔 1.853B 3.45 GiB 视觉到文本桥 69.2M 0.13 GiB 总计 29.777B 55.46 GiB 由于 Muse Glimmer 是密集的，每个生成的令牌都通过所有 52 个文本块。 没有路由的专家在内存中等待未使用。 这带来可预测的执行，但在低批次大小下，它还使得解码严重依赖一次又一次地读取非常大量的权重。 每第四层看到一切 52 个文本层遵循严格的循环调度：因此总共有 39 个滑动注意层和 13 个全注意层。 局部窗口为 2048 个令牌。 在位置处的本地层只能直接读取仅以为结束的最近区间。 但是，局部接收场与深度相结合。 忽略边界效应，三个堆叠的因果窗口间接将一个令牌暴露给大约 1 + 3 × (2048 − 1) = 6,142 个位置：6,141 个前身加上令牌本身。 之后的全局层不会接收到原始孤立令牌；它接收到的表示已经总结了几千个有序局部结构的令牌。 解读四层循环的一种方式是：第一个局部层构建即时的词汇和句法关系，接下来的两个层将它们组合成逐渐更大的局部结构，而最后的全层从上下文中的任何地方检索相关摘要。 当然，这种分工是软的。 局部层在其残差流中向前传递全局信息，而全局层可以在局部范围内关注。 但是，掩码施加了强烈的先验：大多数计算细化了附近的结构，而偶尔的层处理长期通信。 这要比让所有 52 层都是全局的便宜得多，特别是对于 KV 缓存。 长上下文计算是另一个问题：在预填充期间，13 个全注意层仍然会在序列长度上执行平方级的注意工作。 类似于 FlashAttention 的内核避免了物化完整的注意矩阵，但它们并没有消除点积。 Muse Glimmer 生成 131K