MawForge：面向本地混合专家推理的内存受限专家物化

# MawForge：面向本地混合专家推理的内存受限专家物化

来源：https://arxiv.org/html/2607.09686

###### 摘要

稀疏混合专家（MoE）语言模型将总参数量与每个token的活跃计算分离，但本地推理系统通常仍需要完整模型、键值缓存、运行时缓冲区和操作系统预留空间，才能容纳在快速内存中。MawForge测试了一个不同的系统假设：通过将完整模型存储在磁盘上、保持公共张量常驻、并按需将路由专家张人物化到有限执行缓存中，可以在受限的统一内存机器上使本地MoE服务变得实用。

本文介绍了MawForge的分包架构、预算模型、原生GGUF服务路径，以及在搭载24 GB统一内存、目标服务内存为18 GiB的MacBook Pro M5 Pro上完成的本地验证。验证矩阵包含600个非推测性MawForge行，涵盖三个模型配置文件、五种缓存设置、两种上下文长度、四类提示词，每个单元格五次重复。静态规划接受了30个唯一模型/上下文/缓存单元格中的27个，执行前拒绝了3个单元格；所有540个静态可行的生成行均返回有效的96 token完成结果，且未触发内存保护。结果表明，MawForge能够在受限的本地内存范围内服务大型GGUF MoE模型，包括34 GB的Qwen3.6 35B A3B Q8_0配置文件和25 GB的Gemma 4 26B A4B Q8_0配置文件。结果还表明，专家缓存大小是非单调的：更大的缓存能持续提高命中率并减少物化字节，但可能因增加主机内存压力而降低吞吐量。Qwen Q8在4K和32K上下文中均倾向于最小的测试缓存（15%）；Gemma Q8在可行点中倾向于35%；Qwen Q4的倾向随上下文和提示词类别而变化。一个针对性的推测解码附录发现，Gemma MTP推测虽然接受了更多草稿token，但降低了吞吐量并增加了专家物化，表明密集模型的推测假设不能直接迁移到分包MoE服务中。

核心发现是，MawForge作为一种受限执行机制和本地MoE推理的测量基板是有效的，但作为缓存最大化策略则不然。性能取决于平衡专家重用与常驻占用、KV缓存大小、量化、路由局部性以及macOS内存压力。

## I. 引言

大型语言模型的部署通常受限于一个硬性驻留约束：模型权重必须能容纳在快速内存中，并留有额外空间用于键值缓存、运行时分配、加速器缓冲区和操作系统压力。在具有统一内存的消费级和工作站系统上，这一约束尤为尖锐，因为CPU、GPU、内核、显示栈、文件系统缓存和推理运行时都从同一个物理池中分配内存。

稀疏MoE模型放宽了计算端的约束。一个token不会激活所有专家，只会激活一个路由子集。然而，大多数本地推理路径仍将模型驻留视为一个完整文件加载问题。整个GGUF被映射或加载，当模型、KV缓存和运行时内存的总和超出机器承受能力时，就会失败。稀疏激活并不会自动变成稀疏驻留。

MawForge将问题重新定义为内存层次结构。完整模型仍然是持久的磁盘对象。公共张量保持常驻。路由专家张量被拆分为每层、每专家的有效载荷，仅在路由器需要时才复制到有限的内存槽中。由此产生的问题不仅仅是“完整模型是否适合”，而是“多少专家缓存足以捕获路由局部性，而又不越过主机内存压力边界？”

这一区别至关重要。在测试机器上，直接非MawForge加载Gemma 4 26B A4B Q8_0（32K上下文）时，超过了98%的系统使用安全保护，在产生路由输出前被终止。而MawForge分包路径在18 GiB服务目标下，完成了所有静态可行的Gemma Q8 32K验证行。这一发现并不证明没有其他直接配置可以运行；它表明，在相同机器上，测试的完整GGUF Metal路径不安全或不切实际，而MawForge的受限路径保持可控。

本文做出四项贡献：

1. 1. 描述了MawForge用于本地GGUF MoE服务的分包和运行时物化架构。
2. 2. 将本地稀疏专家推理形式化为一个具有显式预算和吞吐量权衡的受限缓存放置问题。
3. 3. 报告了在受限Apple Silicon硬件上完成的600行验证矩阵，包括静态预算拒绝和受保护的生成完成。
4. 4. 分析了仅从缓存命中率无法看到的失效模式，包括高缓存延迟崩溃和推测解码退化。

这项工作在实证声明上有意保持狭窄范围。它评估了一台当前机器、三个模型配置文件、两种上下文长度、四类提示词和短的固定完成。在此边界内，矩阵对于所陈述的非推测性MawForge协议是完整的。

## II. 研究问题

评估旨在回答五个研究问题。

RQ1：可行性。MawForge能否在24 GB统一内存笔记本电脑上，在18 GiB显式服务预算内，服务大型GGUF MoE模型？

RQ2：缓存行为。专家缓存百分比如何影响解码吞吐量、TTFT、缓存命中率、物化专家字节数和内存压力？

RQ3：量化与上下文。改变量化或上下文长度是否会改变可行的缓存区域和最佳运行点？

RQ4：推测。MTP推测解码能否提升MawForge分包服务的吞吐量？

RQ5：测量纪律。已完成的验证证据支持哪些声明边界，哪些声明需要进一步测量？

## III. 背景与相关工作

MoE模型使用条件计算来增加总参数量，同时仅为每个token激活一部分参数。GShard展示了大规模条件计算和稀疏门控模型的自动分片\[1\]。Switch Transformer简化了路由，并表明稀疏激活可以在保持较小活跃计算路径的同时扩展模型容量\[2\]。

服务研究也强调内存管理是一流的系统问题。vLLM的PagedAttention将KV缓存分配视为分页问题，并表明内存布局和分配策略可能主导服务吞吐量\[3\]。MawForge将相关的系统视角应用于不同的对象：路由专家权重而非注意力KV页。

推测解码提出使用更小或更便宜的模型生成草稿token，并用目标模型验证，以减少串行解码延迟\[4\]。对于密集模型，主要问题是接受的草稿token是否能够抵消草稿和验证开销。对于分包MoE服务，还有一个额外问题：推测是否扩展了每一步触及的路由专家并集，从而增加物化成本和缓存抖动。

GGUF是llama.cpp使用的模型格式，用于许多量化本地模型\[5\]。MawForge当前最完整的服务路径通过一个原生llama.cpp派生worker来定位GGUF MoE模型，该worker使用MawForge分包，而非要求所有专家张量常驻。

## IV. MawForge设计

### IV-A 系统论点

MawForge围绕以下论点构建：

> 稀疏专家推理应该从一个受限的专家物化缓存中服务，而不是要求所有路由专家张量都常驻。

该论点并不意味着磁盘访问是免费的，或者稀疏模型自动变快。它意味着本地推理系统应该直接暴露专家驻留的权衡，并应在运行时加载之前使预算可行性可测量。

### IV-B 分包表示

打包器读取一个GGUF模型，并将张量分为公共张量和路由专家张量。公共张量以常驻形式发出。专家张量被拆分为确定的每层、每专家块。每个块记录张量种类、层、专家ID、源偏移、字节计数、拓扑元数据和摘要。块有效载荷写入`experts.pack`，索引写入`experts.index`。

分包设计有两个实际后果。首先，运行时可以在不扫描或复制无关模型权重的情况下寻址一个专家块。其次，包索引成为一个可复现性工件：验证行可以将模型配置文件绑定到包路径和包摘要，而不仅仅依赖于人类可读的模型名称。

### IV-C 原生服务路径

服务worker加载公共张量，并为路由专家分配紧凑的每层槽张量。槽数量根据请求的缓存字节数、路由层数、每槽专家块大小、每个token的活跃专家数以及每层专家数计算得出。具有融合前馈张量的架构使用融合槽张量；具有独立门、上、下张量的架构分配相应的槽张量。缓存未命中时，运行时将请求的专家块物化到一个可用槽中，并更新路由到槽的元数据。

worker通过`mawforgeserve`暴露一个兼容OpenAI的本地端点。CLI报告TTFT、解码率、专家缓存字节数、KV缓存字节数、常驻公共字节数、命中率、物化专家字节数、推测计数器和预算来源。

### IV-D 静态预算检查

MawForge在服务之前执行静态规划检查。设C为常驻公共张量字节数，E(p)为缓存百分比p下的专家缓存预算，K(n)为上下文长度n下的KV缓存字节数，O为运行时开销。静态下界为：

L(p, n) = C + E(p) + K(n)

运行时占用为：

F(p, n) = C + E(p) + K(n) + O

静态规划拒绝下界已经超过请求服务目标的行。然后运行时加载在相同预算下验证分配器行为。这种方法有意将拒绝视为证据：如果拒绝证明请求的缓存/上下文点超出了配置预算，那么被拒绝的行就不是失败的基准测试。

### IV-E 吞吐量模型

缓存权衡是非单调的。简化的吞吐量关系为：

T(p) = 生成token数 / (计算时间 + 物化时间(p) + 压力惩罚(F))

增加p通常会通过改善路由局部性和命中率来减少物化时间(p)。同时也会增加F。当更大的缓存将主机推入压缩、分页或更低的有效内存带宽时，压力惩罚(F)可能占主导地位。在这种状态下，缓存命中率提高而解码吞吐量恶化。

推测解码增加了另一项：

T_spec = 生成token数 /

(目标时间 - 接受的节省的目标工作

+ 草稿开销 + 验证开销

+ 额外物化 + 状态开销)

对于MawForge，关键的特定项是额外物化。推测性前瞻可能在路由局部性能够摊销缓存之前触及更大的专家并集，尤其是当接受的草稿token绝对数量很少时。

## V. 实验方法

### V-A 硬件与预算

所有主要验证证据均在搭载24 GB统一内存的MacBook Pro M5 Pro上收集，时间为2026年6月8-9日HST。主要的MawForge服务目标是18 GiB。验证运行器使用内存保护，并终止超过配置安全阈值的直接或MawForge运行。主要的非推测性生成行使用最多96个完成token。

### V-B 模型配置文件

验证矩阵使用了三个模型配置文件。

矩阵评估了两种上下文长度：4K和32K，以及四类提示词：代码、摘要、长篇写作和推理。每个模型/上下文/缓存/提示词单元格在静态可行时使用五次重复。

### V-C 验证矩阵

主要验证矩阵为：

3 个模型配置文件 * 5 种缓存设置 * 2 种上下文 * 4 类提示词 * 5 次重复 = 600 行

静态规划阶段扩展了完整的600行清单，并执行了30个唯一的模型/上下文/缓存预算检查。在这30个静态检查中，27个可行，3个在18 GiB预算下被拒绝。每个被拒绝的静态单元格对应4类提示词和5次重复，产生60个有效的静态拒绝行。剩余的540行作为受保护的生成运行执行。

三个静态拒绝是：Gemma Q8 at 32K with 50% cache, Gemma Q8 at 32K with 65% cache, and Qwen Q4 at 32K with 90% cache。

### V-D 测量

主要的因变量是解码token每秒、TTFT、缓存命中率、物化专家字节数、专家缓存字节数、常驻公共字节数、KV缓存字节数、进程树RSS、采样的系统使用比例和防护状态。CLI遥测行连同原始请求和响应体、健康指标、解析的JSON遥测、内存样本、stdout和stderr以及运行摘要一起持久化。

当前的worker日志没有直接收集所有首选的macOS内存字段。特别是，`system_ram`、`tracked_metal`和`metal_budget`在最新的本地日志中没有被worker填充。基准测试包装器单独收集了主机和进程样本。因此，本文将进程RSS和包装器样本视为具有显式命名来源的内存信号，而不是将它们合并到单个统一内存字段中。

报告的统计信息是描述性的。每个可行的模型/上下文/缓存/提示词类别单元格包含五个有效重复，源工件报告这些单元格的均值和标准差。本文聚合选定的单元格来回答研究问题，并且不声称正式的假设检验显著性。这一选择是故意的：当前矩阵支持的最强声明是在受控本地条件下的运行包络特征描述，而不是跨硬件、提示词或模型分布的总体推断。

### V-E 有效性规则

一个生成行仅在服务器启动、通过兼容OpenAI的端点返回HTTP 200、产生非零完成token、发出最终遥测、保持在守护阈值以下、并在运行后关闭时才是有效的。一个静态拒绝行在`serveplan`在运行时加载之前拒绝模型/上下文/缓存点（因为估计的下界超过预算）时是有效的。

## VI. 结果

除非另有说明，本节中的数值结果取自基准测试账本\[6\]及其引用的运行工件。验证协议\[7\]定义了矩阵维度和接受规则，遥测模式\[8\]定义了字段含义和派生指标。

### VI-A RQ1：受限预算下的可行性

MawForge在18 GiB目标下完成了所有540个静态可行的生成行，在MawForge生成期间没有触发内存保护。这支持了测试的分包配置的可行性声明：当静态规划器接受该行时，MawForge可以在24 GB统一内存机器上服务评估的GGUF MoE配置文件。

当结合静态拒绝来解释时，这个结果最为有力。MawForge并没有强制每个模型/