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

# Muse Glimmer 如何适配到您的设备上的智能体 来源：https://abstractextraordinary.com/blog/how-muse-glimmer-fits-an-agent-on-your-device Meta 将 Muse Glimmer 宣传为一个在您设备上运行的智能体：自主、多模态、无需云服务。这既是工程挑战，也是产品主张：需要将一个性能强大的30B级模型、漫长的工作历史和感知系统，全部塞进消费级硬件中。最终的解决方案，其核心是一个伪装成30B Transformer的内存层次结构。 其模型卡直指目标：Muse Glimmer 是“专为消费硬件上的自主智能体任务构建”，并“无需云基础设施或网络访问”即可运行。这一承诺要求严苛，因为智能体的工作负载是持久性的。数小时的历史记录和工具转录内容需常驻内存，截图和文档需要在任务中途被重新读取，所有这些都必须装进 Meta 为量化版本设定的24GB或32GB内存空间内。 高层 Muse Glimmer 架构 Muse Glimmer 是一个大约300亿参数的、纯解码器多模态模型：包含一个视觉编码器、一个投影器和一个稠密语言模型。以BF16精度，检查点权重约55 GiB，这会在处理任何上下文token之前就溢出上述任一内存空间，因此答案的一部分很容易点明：Meta 发布了大约四位量化的版本，将语言模型压缩至20 GB以下。但这个压缩后的模型仍需与131,072 token的上下文窗口、一个常驻的视觉塔以及一个推测解码草稿模型共享显卡，而且当语言模型缩小时，这些组件的大小并不会随之减小。答案的另一部分在于架构设计：模型如何分配内存，以及每一层承载何种类型的信息。 Muse Glimmer 基于精心设计的分工原则构建。在大多数层中，注意力机制是局部的：通过RoPE定位，并限制在2,048 token的窗口内。在每第四层，注意力机制会扩展到整个上下文，但移除了RoPE，主要通过内容进行检索。只有注意力机制在交替变化；每个块中的其余部分都是相同的。三十二个查询头提供了丰富的检索行为，而KV缓存中仅存储两个键/值头。在视觉方面，一个大型视觉Transformer（ViT）执行一次高成本的感知，将相邻的图像块压缩四分之一，然后将结果作为普通token传递给语言解码器。 综合来看，这些部分构成了一个层次化的记忆系统： - 局部层构建有序、上下文丰富的表征； - 全局层在整个序列上搜索这些表征； - KV缓存为每个活跃序列存储非常狭窄的记忆痕迹。 每个序列的状态设计得非常小，因此运行实例所需的几乎所有内存都来自模型参数。这就是为什么权重量化在这里的效果如此显著。一旦这些固定权重被压缩，释放出的内存就可以用于扩展上下文长度、增大批次大小、容纳一个常驻感知塔，或一个推测解码草稿模型。 ## 55 GiB 权重分布何处 以下是根据发布张量形状求和得出的分解： | 组件 | 近似参数量 | BF16 存储大小 | | :--- | :--- | :--- | | 52个文本Transformer块 | 25.165B | 46.87 GiB | | 输入token嵌入 | 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 是稠密模型，每个生成的token都必须经过全部52个文本块。没有路由专家闲置在内存中等待使用。这提供了可预测的执行性能，但在小批量大小下，解码过程严重依赖于反复读取一大组权重。 ## 每第四层“看到”一切 52个文本层遵循严格的循环调度： Muse Glimmer 重复的局部/全局注意力调度 因此，模型包含39个滑动注意力层和13个全注意力层。局部窗口为2,048个token。 在位置的局部层只能直接读取截止到位置的最近区间。但局部感受野会随深度复合。忽略边界效应，三个堆叠的因果窗口使一个token间接“看到”大约 1 + 3 × (2048 − 1) = 6,142 个位置：6,141个前驱token加上该token自身。随后的全局层接收到的并非原始孤立的token，而是已经总结了数千个有序局部结构token的表征。 解读这个四层循环周期的一种方式是：第一个局部层建立直接的词汇和语法关系，接下来的两个将它们组合成逐步增大的局部结构，最后的全注意力层则从上下文的任何位置检索相关的摘要信息。 这种划分当然是柔性的。局部层在其残差流中携带全局信息前传，全局层也可以进行局部注意力。尽管如此，掩码施加了一个强先验：大多数计算用于精炼邻近结构，而偶尔的层负责处理远距离通信。 这比让所有52层都全局注意力要便宜得多，尤其是在KV缓存方面。长上下文计算则是另一回事：在预填充期间，那13个全注意力层仍然对序列长度执行二次方的注意力计算。类FlashAttention的内核避免了物化完整的注意力矩阵，但它们并不能消除点积运算。Muse Glimmer使131K上下文在内存上可行；但它并没有让131K的预填充等同于4K的预填充。 ## 无RoPE的全局注意力 首先，提醒一下全注意力层放弃了什么：RoPE根据token索引旋转每个查询和键，角度随索引增长，并且由于两个旋转在向量相互评分时会组合，因此注意力logit最终仅取决于相对位移。这种组合性是Transformer通常感知距离的方式。 Muse Glimmer在每个局部层中使用RoPE。然而，在每个全注意力层中，该层的RoPE theta参数为零，实现时不会将任何位置嵌入传递给注意力——这种配置称为NoPE。因此，全注意力层在计算Q–K兼容性时没有直接的旋转位置项。 尽管如此，顺序信息仍通过两个途径到达这些层。首先，因果掩码告诉位置，它只能读取位置或之前的位置。其次，每个全局键和值都已经通过了三个配备RoPE的局部层。一个表示“河岸”（bank near river）的向量与一个表示“银行”（bank near loan）的向量是不同的，并且两个向量都编码了产生它们的局部顺序。后来的全局层也会接收到被早期全局层修改过的残差状态。 所以准确的陈述是：全局层在它们的Q-K评分中没有直接的位置项，但它们操作的是位置感知的、局部上下文化的表征。 为什么这在131K token时有帮助？传统的全局RoPE层必须解释从一个token到超过十万个token距离上的相对旋转。长距离检索可能会与远超普通语言主导距离的相位行为纠缠在一起。而NoPE全局层则更像内容可寻址存储：一个相关项目仅因为距离80,000个token远，并不会本质上变得更难匹配。 该架构将精确的排序放置在最有价值的地方——在有界的局部窗口内，并向全局层提出一个不同的问题：不是邻近部分如何排列，而是记忆中任何位置的哪个上下文化部分能响应当前的需求。 这里存在一个权衡。当全局评分没有显式位置项时，两个真正相似的遥远事件更难通过绝对位置来区分。Muse Glimmer通过让每个事件携带其周围的局部上下文来缓解这一问题，但歧义不可能完全消失；该设计倾向于鲁棒的语义检索，而非精确的全局坐标匹配。 ## 三十二个查询头，两个记忆体 Muse Glimmer使用分组查询注意力，具有32个查询头但只有两个键/值头，因此每个K/V组共享十六个查询头。这种不对称性符合生成任务的实际开销结构。查询仅存在于当前正在生成的token，并且会立即丢弃，因此保留32种不同的查询方式只消耗计算资源，不占用持久内存。键和值则不同：层内注意力跨度内的每个token都必须常驻内存，全局层中是完整历史，局部层中是最近的2,048个token。将KV头减少到两个，直接攻击了唯一持久的per-token状态，这就是为什么这个选择能产生如此大的内存效益。 内存计算直接明了。在BF16或FP16中，每层的每个token为每个KV头存储一个键向量和一个值向量，每个数字占两字节： 因此，Muse Glimmer每个token每层使用1 KiB的KV缓存（K和V合计）。 对于长度为的序列，13个全局层持有全部个token的KV，而39个局部层则受限于其2,048 token的窗口，因此理论上的活跃KV缓存约为： 在设定的131,072 token上下文长度下： - 13个全局层消耗约1.625 GiB； - 39个局部层在窗口填满后消耗约78 MiB； - 每个序列的总活跃BF16 KV缓存约为1.70 GiB。 KV缓存对比 此计算假设服务引擎实际为滑动层驱逐或循环重用缓存条目。为每一层都分配全长存储的静态实现无法获得全部收益。缓存量化、页面大小、内存碎片和运行时工作空间也会改变实际测量值。 架构上的观点经受住了所有这些注意事项：每个序列的内存被刻意设计得很窄，从而将瓶颈转移到固定的模型权重上。 ## 解码器块内部 到目前为止，讨论的是各层如何看待上下文以及每个序列的开销。再深入一层，每个块读取和写入宽度为6,656的残差流，每个token添加两个更新：一个来自门控分组查询注意力，另一个来自SwiGLU前馈网络。 一个Muse Glimmer文本块 注意力使用五个投影：常规的查询、键和值映射，一个将注意力结果返回残差流的输出映射，以及第五个矩阵，它计算该结果上的一个门控（下文描述）。它们的宽度分别为： 4,096维的查询和注意力输出空间对应32个128维的头。键和值的维度要窄得多，因为只有两个KV头：2 × 128 = 256维。 前馈网络是标准的SwiGLU，与Llama系列使用的设计相同：一个门控矩阵和一个上投影矩阵都将状态扩展到19,968维（正好是隐藏宽度的三倍），一个下投影矩阵将SiLU门控后的乘积映射回模型宽度。这些都不是Muse Glimmer特有的，其参数量也是如此：每层大约398.7M参数，FFN主导了每个块的参数计数，这与大多数稠密模型一样。需要记住的一个细节是，这个门控并非该块中唯一的。Muse Glimmer在注意力内部添加了第二个完全独立的门控，这种添加要少见得多。 ## 注意力内部的第五个投影 标准的类Llama注意力有四个大投影：Q、K、V和O。Muse Glimmer添加了第五个。从与产生查询相同的归一化块输入，计算一个4,096维的向量（每个注意力通道一个值），然后通过sigmoid函数将其转换为一个门控。该门控在输出投影之前，对拼接后的注意力结果进行逐元素相乘： sigmoid为每个注意力通道提供了独立的门控。 这使得当前token不仅决定注意哪里，还决定哪些检索到的通道被允许写入残差流。一个头可能同时检索到有用和噪声特征；输出门控可以在输出投影将它们混合回6,656维模型空间之前，抑制各个维度。 该门控也占据实际权重：一个6,656 × 4,096的矩阵每层包含27,262,976个参数，整个模型约1.418B参数，在BF16下约2.64 GiB。 ## QK归一化分离语义与温度 常规注意力已经将每个查询-键点积除以，以保持其在头维度上方差平坦。这种缩放无法控制的是向量本身的范数：如果模型将和的幅度都加倍，每个logit会变为四倍，softmax会变得更尖锐，但向量指向的方向没有任何改变。范数膨胀会悄然改变注意力温度。 Muse Glimmer移除了这种自由度。它对Q和K独立应用了无缩放的RMSNorm，然后将Q乘以一个固定因子3.87，使得位置和之间的注意力logit为： QK归一化并未取代常规的因子；实现保留了两者，因为它们扮演不同的角色。RMS归一化移除不可控的幅度漂移，因子补偿了在128个维度上求和的影响，而常数3.87则明确选择了所需的注意力锐度。与稍后出现在模型头部分的输出乘数不同，我无法从任何模型维度推导出3.87；它看起来像是一个调优后的选择。 这里还有一个隐藏的上限。归一化到单位RMS的向量具有范数，因此，根据柯西-施瓦茨不等式： 无论底层激活变得多么极端，没有一对token能产生更大的logit。这很可能就是为什么Muse Glimmer中唯一的tanh软上限被置于最终输出logit上：当几何结构已经强制执行了一个上限时，注意力内部的第二个上限将是多余的。 ## 三明治归一化控制每个分支的输出 Muse Glimmer每个块使用四个居中的RMSNorm，用一对范数包裹每个子层：一个范数在进入子层时应用，另一个在其输出残差加法之前应用： 前置范数为每个子层提供可预测的输入尺度。后置范数为残差流提供可预测的更新尺度。恒等路径本身保持不变。 “居中”名称指的是增益参数化，而非均值减法：该操作仍然是RMS归一化，学习到的增益存储为与1的偏移量（，初始化为0）。 前置子层范数使用；后置子层范数使用更紧的。后者使得epsilon底线在归一化小分支输出时干扰更小。 后置注意力范数也约束了门控能做什么。对整个注意力向量进行均匀的标量缩减大部分会被RMS归一化抵消。存活下来的是门控对向量的选择性重塑：改变相对通道、抑制维度、旋转更新方向。门控最终的作用更多地体现在学习到的特征过滤上，而非整体幅度。 ## 视觉塔更偏向传统设计 文本解码器看起来现代且高度定制。视觉塔则更接近经典的大型ViT： - 50层； - 隐藏大小1,536； - 16个头，因此每个头96维； - GELU MLP，宽度8,960； - 普通的LayerNorm，带学习权重和偏置； - 带偏置的注意力和MLP投影； - 没有注意力输出门控。 尽管如此，它依然镜像了文本端的局部/全局节奏。发布的50层调度包含37个窗口注意力层和13个全注意力层：大多是三个窗口层后跟一个全注意力层，最后以一个额外的窗口/全注意力对结束。 Muse Glimmer 视觉路径 ### 时空patch在第一投影层就使视频成为原生输入 每个patch包含两帧、三个颜色通道和一个14×14的空间区域，因此它包含 2 × 3 × 14² = 1,176 个输入值。一个线性投影将这个1,176维的管状输入映射到1,536维的视觉空间。 对于视频，第一个学习的操作...