Muse Glimmer 是一个伪装成 30B Transformer 的内存层次结构

Meta 将 Muse Glimmer 作为在您的设备上运行的代理：自主、多模式、无需云。这既是一个工程问题，也是一个产品声明：将功能强大的 30B 级模型、悠久的工作历史和感知堆栈融入到消费类硬件中。答案是伪装成 30B Transformer 的内存层次结构。它的模型卡直接说明了目标：Muse Glimmer 是“专门为消费者硬件上的自主代理任务而构建的”，并且它的运行“不需要云基础设施或网络访问”。这个承诺要求很高，因为代理的工作量是长期的。数小时的历史记录和工具记录会保留下来，屏幕截图和文档会在任务中重新读取，所有这些都必须适合其量化版本的 24 或 32 GB 信封元名称。 Muse Glimmer 是一个大约有 300 亿个参数、仅解码器的多模态模型：视觉编码器、投影仪和密集语言模型。在 BF16 中，检查点的大小约为 55 GiB，这会在单个上下文标记之前溢出这两个信封，因此部分答案很容易命名：Meta 提供了大约四位的量化变体，使语言模型的大小低于 20 GB。压缩模型仍然必须与 131,072 个令牌上下文、常驻视觉塔和推测解码起草者共享卡片，并且当语言模型变小时，它们都不会变小。答案的其余部分是架构性的：模型在哪里使用内存，以及每层携带什么类型的信息。 Muse Glimmer 是围绕刻意的劳动分工而建立的。在大多数层中，注意力是局部的：由 RoPE 定位并限制在 2,048 个令牌的窗口内。在每第四层中，注意力会向整个上下文开放，但会放弃 RoPE，主要通过内容进行检索。只是注意力交替；每个块的其余部分都是相同的。 32 个查询头提供了丰富的检索行为，而 KV 缓存中仅存储两个键/值头。在视觉方面，大型 ViT 执行一次昂贵的感知，将相邻补丁压缩为四比一，并将结果作为普通令牌传递给语言解码器。总而言之，这些部分形成了一个分层存储系统：局部层构造有序、上下文丰富的表示；全局层在整个序列上搜索这些表示； KV 缓存为每个活动序列存储非常窄的内存跟踪。每个序列的状态在设计上都很小，因此运行实例所需的几乎所有内存都是模型的参数。这就是为什么权重量化在这里获得如此异常良好的回报。一旦这些固定权重被压缩，释放的内存就可以转化为更长的上下文、更大的批次、常驻感知塔或推测解码起草器。 55 GiB 位于何处 以下是根据发布的张量形状汇总的细分： 组件 近似参数 BF16 存储 52 个文本 Transformer 块 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 个全注意力层。本地窗口是 2,048 个令牌。位于 i 位置的本地层只能直接读取以 i 结尾的最近间隔。但局部感受野与深度相结合。忽略边界效应，三个堆叠的因果窗口将令牌间接暴露于大约 1 + 3 × (2048 − 1) = 6,142 个位置：6,141 个前驱加上令牌本身。随后的全局层不接收原始的隔离令牌；它接收的表示已经总结了数千个有序局部结构的标记。阅读四层循环的一种方法是：第一个局部层构建直接的词汇和句法关系，接下来的两个将它们组合成逐渐更大的局部结构，最后的完整层从上下文中的任何位置检索相关摘要。当然，这种划分是软性的。本地层在其剩余流中携带全局信息，全局层可以在本地参与。尽管如此，掩码仍然具有很强的先验性：大多数计算都会细化附近的结构，而偶尔的层会处理远程通信。这比将所有 52 层设为全局要便宜得多，尤其是对于 KV 缓存。长上下文计算是另一回事：在预填充期间，13 个全注意力层仍然在序列长度上进行二次注意力工作。类似 FlashAttention 的内核避免具体化完整的注意力矩阵，但它们不会擦除点积。缪斯微光打造