把35B大模型塞进24GB内存：一场关于“预测”的豪赌

你有没有想过，一台24GB内存的普通电脑，怎么可能跑得动一个体积高达19.5GB的AI大模型？

这听起来就像想在一个只能装下19.5升水的水桶里，硬塞进去19.5升水，然后还要求你同时用这个水桶洗菜做饭。理论上空间是够的，但实际上根本没有余地干别的事。你的操作系统要占地方，你打开的其他软件要占地方，AI生成文字过程中产生的临时数据也要占地方。

这就是2026年AutoArk团队在论文里讲的那个故事的开头。他们要解决的，正是这样一个看似无解的难题：如何在一台连模型本体都装不下的机器上，流畅地跑一个350亿参数规模的混合专家模型。

**内存墙的另一半，没人愿意碰的那一半**

1995年，两位计算机科学家Wulf和McKee提出了一个后来影响整个行业几十年的概念，叫"内存墙"。

内存墙：指处理器运算速度提升得越来越快，但内存读写速度跟不上，导致机器大量时间花在"等数据"上，而不是"算数据"上。

这堵墙原本说的是CPU和内存之间的速度差距，三十年后，它换了个战场，出现在了AI大模型的推理过程里。AI生成文字这件事，本质上是不断地读取模型的参数，然后做一堆乘法加法运算。问题是，现代硬件做运算的速度极快，但从内存或硬盘里把参数读出来的速度，慢得多。这意味着瓶颈根本不在"算得快不快"，而在"读得快不快"。

内存里存的东西可以分成两种。一种是动态数据，也就是模型在生成文字过程中临时记下的"上下文记忆"，行话叫KV缓存，这部分数据会随着生成的字越来越多而越变越大。另一种是静态数据，就是模型的参数本身，这部分数据从训练完成的那一刻起就固定不变了。

过去几年，整个行业在拼命优化第一种数据。多头潜在注意力机制把KV缓存压缩了一个数量级，稀疏注意力把它限制在一个固定窗口内，线性状态模型干脆把这种缓存机制取消了。但第二种数据，也就是参数本身占的空间，几乎没人碰。行业默认的解法是：把这几十GB的参数丢进数据中心的显卡集群里，用专家并行和分布式服务来扛住它。

这个解法对企业没问题，对普通人的电脑就是灾难。你桌上那台24GB的电脑，根本没有数据中心那种"分布式扛压力"的能力。

**量化到头了，稀疏也帮不上忙**

面对这个问题，业界通常有两条现成的路，但这篇论文的作者发现，这两条路走到35B这个规模都会失效。

第一条路是量化，简单说就是把模型参数用更少的比特数来表示，从而缩小体积。

量化：把模型参数从16位浮点数压缩成更少位数（比如4位整数）来表示，从而减少存储空间和读取带宽。

问题是量化这件事有个天花板。业界公认4比特是目前能稳定使用的下限，低于这个数字，模型输出质量会断崖式下跌，而且目前没有任何后处理技术能把这种损失补回来。

第二条路是混合专家架构本身自带的稀疏性。

混合专家模型（MoE）：一种大模型架构，每次处理一个字词时，并不会用上全部的参数，而是从一堆"专家"模块里挑出少数几个来干活，这样计算量就变小了。

问题是，MoE的稀疏性省的是"算力"，不是"存储"。35B规模的MoE模型，每个字词处理时只激活大约30亿参数，计算量确实小了，但你依然得把195亿参数（4比特量化后是19.5GB）全部存在某个地方，因为你不知道下一个字词会用到哪几个专家，所有专家的参数都得随时待命。19.5GB这个数字，一分不能少。

这就是为什么标题里说这是"内存墙的另一半"：大家一直在优化会变化的那部分数据，却没人正视这部分固定不变、却依然巨大的参数存储问题。

**把参数搬到硬盘上，然后呢？**

于是研究团队想到了一个直接的办法：既然内存装不下19.5GB的参数，那就别硬塞进内存，让参数待在硬盘（SSD）上，需要哪个专家的时候，现读现用。

这个思路听起来很合理，但作者很快指出，光这么做是不够快的。

问题出在MoE的路由机制上。模型在处理每一层的时候，需要先算出这一层该激活哪些专家，这个决策叫"路由"。而这个决策必须依赖上一层算完的结果才能做出来。换句话说，第N+1层要用哪些专家，得等第N层算完才知道。

这就好比你去一家没有提前点单系统的餐厅吃自助火锅，服务员必须等你吃完当前这盘菜、看你反应之后，才能决定去后厨拿下一盘什么菜。如果后厨在很远的仓库（相当于硬盘），每次都要等你吃完这盘才开始去仓库取下一盘，那么无论仓库距离餐桌有多远，你每吃完一盘都要干等着，因为取货这个动作根本没法提前开始。如果不解决这个"必须等结果出来才能行动"的先后顺序问题，硬盘再快也没用，因为读取硬盘的时间没办法藏在计算时间背后，只能老老实实地排队等着。

这正是论文标题里提到的核心矛盾：单纯把参数挪到硬盘上，解决不了速度问题，因为"选专家"和"读专家"这两件事有严格的先后依赖关系，没法并行。

**预路由器：让预测提前一步替你做决定**

这篇论文最核心的创新，就是打破了这个"必须等结果才能行动"的死循环，方法是训练一个专门的小模块，提前一步预测路由结果。

作者管这个模块叫prerouter（预路由器）。

预路由器：一个附加在每一层上的小型神经网络模块，它不是等当前层算完后再决定下一层用哪些专家，而是提前一个字词的时间，就把下一层的专家选择预测出来。

具体来说，第N层的预路由器，会在处理第t个字词的时候，就去预测第N+1层在处理第t+1个字词时会用到哪些专家。这一步预测提前完成之后，硬盘就可以立刻开始把这些专家的参数往内存里搬，等真正轮到第N+1层处理第t+1个字词的时候，需要的参数已经躺在内存里等着了，读取硬盘的时间就被"藏"在了计算的过程背后，两件事同时发生，谁也不耽误谁。

这里最关键的一点是，这个预测不是"辅助参考"，而是直接被当成了真正的路由结果来使用。

这意味着模型实际生成文字时，走的路由路径就是预路由器猜的那条路径，不存在预测错了之后需要临时补救、丢弃数据、重新加载的情况。为什么要这么设计？因为如果预测只是个参考，模型实际执行的时候发现预测跟真实路由对不上，就得现场补救，之前那些为了预测提前搬来的参数全都白费了，速度优势瞬间清零。作者的做法很干脆：既然要用预测代替真实路由，那就让训练阶段一次性把这个"预测不准"的代价吸收掉，把模型训练成一个"就算路由是猜的，也照样能说人话"的模型。这个思路跟此前学术界一个叫"Pre-gated MoE"的方案不一样，那个方案是在同一个字词内部、当前层算完注意力之后立刻决定下一层的专家，作者实测发现这样做需要频繁地同步和暂停GPU流水线，每一步要花30到100毫秒，比它能省下的硬盘读取时间还长，属于赔本买卖。而提前一整个字词做预测，就能把这个决策计算挪到不影响主流程的地方，一次性给所有需要预取的层做完预测。

预路由器的具体结构也值得说一说。每一层的预测头由两层小型神经网络组成，中间用erf-gelu激活函数连接，此外还有一条从下一层原本路由器的权重直接抄过来的"直连"路径，相当于给训练打了个底：一开始就模仿"直接套用下一层原来的路由器"这种最朴素的做法，然后再在这个基础上学习修正。输入特征除了当前层的隐藏状态，还包含了这一层和上一层实际路由到的专家信息，这样预测头就有了"最近发生了什么"的上下文信息可用。

在35B这个规模的模型上，一共有40层，其中33层挂载了预测头，32层的推理路由是靠预测完成的，只有前几层还是靠自己的原生路由器，因为最开始的几层还没有足够的历史信息可以预测。

实测效果相当直观：在一台16GB内存、模型根本装不下的MacBook M2上，光靠"读到再算"的传统流式加载，解码速度是每秒1.8到4.8个字词（具体数值取决于每层激活几个专家），而用上预路由器提前预取之后，速度提升到每秒3.3到8.6个字词，提升幅度是80%到84%。

这个提升的本质，作者讲得很实在：不是预测让读取的数据变少了，而是把原本堵在关键路径上的等待时间挪走了。数据表明，两种方案实际读取的字节数几乎一样，差别只在于什么时候读、以及读的时候会不会卡住整个计算流程。

**量化和路由预测都会伤模型，那就用一个"外挂"补回来**

预路由器解决了速度问题，但天下没有免费的午餐。用预测代替真实路由，加上前面提到的4比特量化，这两件事都会让模型输出质量打折扣。

作者的解法是训练一个叫"恢复LoRA"的轻量级修补模块。

LoRA：全称低秩适应，是一种给大模型打补丁的技术，不需要重新训练整个模型，只需要额外训练一小组参数，就能让模型行为发生特定方向的调整。

这个恢复LoRA是拿4比特量化之后的模型、用预测路由跑出来的实际路径当作训练环境，去对照没有量化、用真实路由的原始模型（也就是"老师模型"）学出来的答案，一点点纠偏。

这里有个特别值得展开讲的细节：这个LoRA补丁在实际部署的时候，是不能和主模型"合并"的，必须以独立的、并联的方式挂在旁边同时计算。

为什么不能合并？因为LoRA学到的调整幅度非常微小，用数值来说大概是千分之一的量级，而4比特量化本身的"刻度间隔"比这个调整幅度还要粗糙。如果把这个微小的修正值硬塞进已经量化过的权重里，再重新量化一遍，这个精细的修正信息在粗糙的量化刻度面前根本站不住脚，绝大部分修正效果会在重新量化的过程中被抹掉。

这就好比你用一支极细的铅笔在一张纸上写了一行很小的批注，字迹只有零点几毫米粗细，然后有人非要把这张纸重新复印一遍，而复印机的最小分辨精度比你的字迹粗得多。复印出来的结果，你那行批注基本就是一团模糊的灰色阴影，内容全没了。如果不坚持"不合并、单独跑"这个设计，那这个精心训练出来的LoRA补丁，实测显示在某些参数上重新量化后只剩下2%到34%的效果能留存，等于白训练了。

论文里给出了具体数字：把LoRA合并进权重再重新量化，在注意力层的某个投影上只有34%的修正效果能存活，在另一个稠密层的投影上更惨，只剩2%，从模型最终输出的文字概率分布来看，整体上只有18%的效果被保留。而选择让这个补丁独立并联运行，只需要多付出42MB的存储空间，几乎不影响解码速度，效果却是完整保留的。

这个设计思路，其实和2023年就已经提出的QLoRA有些相似的血缘关系，QLoRA证明了在4比特基座模型上训练LoRA可以逼近16比特全精度微调的效果，而这篇论文进一步追问的是：这个补丁在真正上线服务的那一刻，到底能不能保住它训练时学到的东西。答案是，只要不把它强行揉进量化权重里，就能保住。

**三个阶段的训练，一步都不能乱序**

要让整个系统真正跑起来，光设计出预路由器和LoRA还不够，训练的顺序本身也是一门学问。作者的训练分成三个阶段。

第一阶段只训练预路由器这些小预测头，目标很单纯，就是让它们尽量模仿真实路由器下一层会做出的选择。

第二阶段是在"学生路径"上做监督微调，也就是让整个模型带着预路由器的预测路由去跑，同时训练那个恢复LoRA，用大约200万条老师模型生成的文本数据来纠正质量损失。这一步是决定整个系统能不能用的关键，作者在论文里坦诚地写道，如果只做第一阶段的预测头蒸馏，模型生成的文字会陷入重复、坍缩的状态，根本没法用，必须叠加第二阶段的微调才能产出连贯的文本。

第三阶段叫"在线策略蒸馏"，这一步比较微妙：前一阶段训练用的是老师模型自己写的文本，而这一阶段改用学生模型自己生成的文本，再让原始的高精度老师模型去给这些文本打分当作监督信号。这样做的目的是让学生模型习惯"评判自己实际会说出的话"，而不是死记硬背老师的答案。这个阶段用的训练数据量只有第二阶段的十分之一左右，大约20万条，说明它更像是精细调优，而不是从头再学一遍。

三个阶段的顺序不能打乱，作者特别强调了这一点。必须先训练预测头，否则如果一开始就直接上大规模微调，微调产生的梯度信号会把预测头那点微弱的学习信号直接淹没掉，预测头根本学不到东西。

**实测数据：真的能跑起来吗**

说了这么多设计，最终还是要看实际效果。论文给出了两个开源模型版本的实测结果。

35B版本基于Qwen3.6-35B-A3B模型改造，40层、每层256个专家，每次处理只激活大约30亿参数。在一台24GB内存的Mac mini M4 Pro上，这个35B模型的解码速度达到每秒20.4个字词，峰值内存占用只有2.9GB。作为对比，把同样的模型完整塞进内存跑（不做任何流式加载），解码速度只有每秒3.9个字词，内存占用高达18.2GB。同样一台机器，同样的模型，快了超过5倍，内存只用了原来的六分之一。

8B版本基于Ling 3.0 tiny模型，24层、每层128个专家，解码速度达到每秒28个字词，峰值内存只要1.5GB。

质量方面，论文用OpenCompass在五个公开基准测试上对比了量化加改造之后的模型和原始16比特模型。35B版本平均每个基准的分数差距是3.9分（满分100分），8B版本是2.8分。具体到各项测试，35B版本在数学竞赛AIME上从92.7分掉到86.6分，掉了6.1分，是所有测试里损失最大的一项，而在代码能力测试HumanEval上只掉了4.2分，在指令遵循测试IFBench上从61.7掉到57.9。

这里有个挺有意思的细节，8B版本在MMLU-Pro这个知识测试上，改造后的分数反而比原始16比特模型高出4.3分（70.1对65.8），这说明质量损失并不是均匀分布在所有能力维度上的，长链条推理这类需要精确计算的任务受影响最大，而知识类问答受影响很小，甚至可能因为额外的微调训练而有所提升。

**硬盘读取的账本：省下来的时间到底从哪来**

作者在论文里做了一件挺严谨的事，他们没有满足于"快了多少"这种笼统结论，还去拆解了这个速度提升具体是怎么来的。

在那台16GB、模型根本装不下的MacBook上，实测显示，主线程等待专家参数加载的时间，从每步244毫秒降到了101.9毫秒（这是每层激活4个专家的配置下测出来的），在每层激活8个专家的配置下，从575毫秒降到211.6毫秒。这段被省下来的时间，就是原本浪费在"干等硬盘"上的空转时间。

但作者也诚实地指出了这个机制的代价：预取是要花内存的。因为要提前把预测出来的专家参数放进内存待命，这部分内存是没法被操作系统回收利用的，会挤占原本可以用来做磁盘缓存的空间。在每层激活8个专家的配置下，预路由器方案要多占用1.43GB的常驻内存，而磁盘缓存因此损失了1.15GB，相当于挤占效应吃掉了将近八成的额外内存开销。

还有个现象叫"读取粒度"问题：因为提前预取，读进来的数据往往是"冷数据"，也就是从来没被访问过、刚从硬盘上取来的新鲜数据，这种冷数据每次加载的成本比"热数据"（之前访问过、还在缓存里的数据）要高。论文测出的经验公式是，每次加载的耗时大约是1.17毫秒加上1.33毫秒乘以这次加载里冷数据所占的比例，这个公式在多组实测数据上误差都在0.13毫秒以内，拟合得相当精确。

论文还提到一个有意思的现实制约：相邻的两个字词，路由到的专家集合只有大约四分之一是重叠的。这意味着大部分被提前预取的专家参数，读进来一次之后就再也用不上了，等于白读了。这也解释了为什么这套机制的收益并不是无限放大的，它天生受限于"预测出来的东西到底有多少会被真正用上"这个现实约束。

论文里还提到两个"暂未拉动的杠杆"：一个是当前的实现里，同一份专家权重在内存里同时存了两份不同格式的拷贝，去掉重复能省下大约0.45GB；另一个是把参数组装这个步骤从主线程挪到别的线程去做，能省下每步62.5毫秒的等待。这两处优化目前还没做，留给了未来的版本。

**这套系统的边界在哪**

作者对这套系统的局限性写得也很坦率。

首先，Edge0目前只能一次处理一个请求，不支持并发，因为多个请求同时跑会让专家的实际使用模式变得不可预测，论文里这套针对单请求场景做的性能画像就用不上了。

其次，作者发现哪怕硬盘读取的等待时间已经被完全藏起来了，模型解码这个过程本身在CPU这一侧还有个躲不开的开销，就是每一步都要重新搭建计算图，这部分开销在40层的模型里测出来是每步44毫秒，这是个硬底线，没法靠优化存储系统绕过去，得从更底层的计算图复用机制或者换用更小的模型来解决。

第三，预路由器带来的收益是有前提条件的：如果换成内存足够大、硬盘足够快的机器，这套机制能省下的等待时间本身就很少，收益会自然缩水。这套系统天生就是为"内存紧张、存储慢"这个场景量身定做的，脱离了这个场景，它的优势也就随之消失。

**三个后续能延展的方向**

论文里提到的一些相关工作，其实能帮我们理解这篇论文站在什么位置上。

比如PowerInfer这类工作，思路是把神经元分成"热"和"冷"两类，分别放在GPU和CPU里，本质上是一种基于访问频率的缓存策略。Mixtral-offloading和MoE-Infinity也是类似的"按热度或复用距离缓存专家"的思路。这些方案共同的特点是，它们移动的是负担的位置，而不是负担的大小，模型参数依然要占用几十GB的空间，只是换了个地方存，而且读到硬盘这一层的时候，系统并不知道下一步到底需要哪些专家，只能凭经验猜。这篇论文的不同之处在于，它不是靠猜经验，而是靠一个专门训练出来的模块去做有依据的预测，而且预测直接等于路由决策本身，不存在"猜错了怎么办"这个后续补救的环节。

再往前追溯，Pre-gated MoE这篇论文提出了"提前选专家"的思路，但它是在同一个字词内部完成的，作者在这篇论文里明确指出这个方案撑不住流式加载引擎的节奏，因为同步开销比它能省下的时间还大。这篇论文把这个提前量从"同一层内"拉长到"整整一个字词"，是对同一个问题在时间尺度上的重新设计。

还有一篇关于"MoE可以跳过一半专家"的自蒸馏工作，验证的是"只要经过针对性训练，模型可以容忍更激进的专家数量削减"这个观察，这篇论文里的路由替换训练本质上是同一个观察的另一种应用方式：只要训练到位，模型也能容忍"路由决策是猜的"这件事。

写在后面

读完这篇论文，最让我意外的一个细节是，作者敢于把"预测出错了怎么办"这个问题彻底绕开，而不是在工程上做各种补救机制。大部分做缓存和预取的系统设计，思路通常是"预测一个大概率对的结果，同时留一个兜底方案应对预测出错的情况"，这篇论文反其道而行之：既然要靠预测，那就干脆把预测直接当成唯一真相，把所有的容错工作一次性放到训练阶段解决掉。这种"在哪个阶段付出代价"的选择，其实是个挺深的工程哲学问题，放在训练阶段一次性付费，还是放在推理阶段反复打补丁，两条路都能走通，但成本结构完全不同。

另一个让我反复琢磨的地方是那组"合并LoRA会让效果损失98%"的数据。这提醒我一件容易被忽略的事：很多看起来只是工程实现细节的选择（合并还是不合并），背后其实是数值精度和量化刻度之间的物理约束在起作用，不是随便怎么实现都无所谓的。

这篇论文没有回答的一个问题是，当模型规模继续往上走，比如到100B甚至更大的时候，预路由器这套机制还能不能保持同样的预测准确率。文中提到相邻字词路由到的专家只有四分之一是重叠的，如果这个重叠率随着模型变大而进一步降低，预取的收益会不会跟着塌缩？这大概是留给下一篇论文的问题。

Q&A

Q1：Edge0是什么？

A：Edge0是AutoArk团队开发的流式MoE推理引擎，能让350亿参数规模的混合专家大模型在24GB内存的普通电脑上运行，核心是把专家参数放在硬盘上，用训练出的预测模块提前一步猜测路由结果，从而让硬盘读取和计算同时进行。

Q2：Edge0为什么比直接把模型塞进内存跑得还快？

A：直接把19.5GB模型塞进24GB内存会占用几乎全部内存，导致操作系统和缓存空间被挤压，系统被迫频繁换页，实测只有每秒3.9个字词。Edge0把参数放硬盘按需读取，内存只占2.9GB，速度反而达到每秒20.4个字词。

Q3：Edge0对模型输出质量的影响大不大？

A：影响不大，35B版本和8B版本在五项公开基准测试上平均分别只比原始16比特模型低3.9分和2.8分，损失主要集中在数学竞赛这类长链条推理任务上，日常问答和代码能力几乎不受影响。