口袋里的专家委员会：Meta把百亿参数模型塞进了手机

想象一下，你口袋里装着一个由三十多位专家组成的委员会。每次你问一个问题，只有五六位专家真正开动脑子，其余的在打盹。这听起来像某种懒惰的官僚机构，但在这个故事里，"打盹"恰恰是效率的来源——因为只有被唤醒的那几位专家在消耗算力和电量。这就是Mixture-of-Experts（混合专家模型，MoE）的核心直觉。它已经在云端的大模型里统治了好几年，但没人系统性地问过：如果把这套机制搬到手机上，规则还一样吗？Meta AI的一群工程师最近回答了这个问题，而且答案里藏着一条前人没画过的 scaling law。

📱 1. 手机里的算力困境

云端的大模型过去几年一直在膨胀。GPT-4、Gemini、Claude——这些名字背后的数字是千亿甚至万亿参数。它们住在数据中心里，吃着成千上万张GPU的电力，通过网线把答案送到你的屏幕上。这个模式在云端运转良好，但它有一个根本性的边界：网络延迟、隐私风险和算力成本让很多事情无法在本地完成。

设备端AI——也就是让模型直接跑在你的手机上——试图打破这个边界。但手机不是数据中心。它的DRAM通常只有4-8GB，而且这8GB不是全给模型用的，操作系统、其他应用、甚至你后台播放的音乐都在抢份额。CPU和GPU的功耗也被电池严格限制，一个推理请求如果吃掉太多电量，用户半天就要找充电器。

在这种环境下，每一兆内存、每一个浮点运算都要精打细算。Dense模型（所有参数每次推理都被激活）在这个约束下很快就撞到了天花板。你用1B参数的dense模型，推理时就要动用1B参数的计算量。能不能让模型总量很大，但每次只激活一小部分？

这就是MoE的诱人之处。一个总量5B参数的MoE模型，如果每次只激活0.5B参数，它的内存占用接近5B（参数得存着），但计算量只有0.5B。在手机这个场景里，内存和算力是两个独立的约束——DRAM容量决定了你能放多大的模型，而FLOPs决定了推理有多快、多耗电。MoE恰好提供了一种不对称的杠杆：用更多的内存换更少的计算。

但MoE不是免费的午餐。它的代价在于复杂性：需要一个router来决定每个token送给哪些专家，需要处理专家负载不平衡的问题，需要在训练时确保所有专家都被充分激活而不是只有一两个"明星专家"在干活。这些复杂性在云端可以用庞大的工程团队和大规模分布式训练来消化，但在手机模型的开发流程中，训练预算小得多，调试空间也小得多。

但MoE在云端百亿参数模型上的设计原则，直接搬到手机上未必管用。云端的scaling law研究的是"怎么在无限算力下把模型做到最大"，而手机问的是"在严格受限的盒子里怎么找到甜蜜点"。Meta的MobileMoE团队画出了这条之前没人画过的曲线。

📐 2. 一条新的 scaling law

Scaling law是过去几年深度学习里最具影响力的概念之一。它说：模型的性能随着参数规模和训练数据量的增加而可预测地提升。Chinchilla scaling law告诉你，在固定算力下，参数和数据应该按什么比例分配。Joint MoE scaling law告诉你，在云端，专家数量、激活参数和数据量之间怎么权衡。

但这些定律都有一个隐含的假设：算力和内存足够大，大到你只需要关心"最优性能"，不需要关心"装不装得下"。手机推翻了这个假设。

MobileMoE团队提出了一个on-device MoE scaling law，它的优化目标同时包含两个硬约束：

• 算力约束：训练和推理的FLOPs预算
• 内存约束：模型权重（INT4量化后）加上KV cache不能超过手机的DRAM预算（大约5GB）

在这个联合约束下，他们发现了一条之前被忽略的架构甜蜜点：中等稀疏度 + 细粒度专家 + 共享专家。这跟云端MoE的设计直觉不太一样——云端倾向于大量专家、高稀疏度，因为这样在无限算力下能把模型总量推得最大。但在手机上，过度稀疏会让总参数量膨胀，内存爆炸；而专家太粗粒度又无法充分利用MoE的计算节省优势。

更具体地说，他们定义了一个广义损失函数，把激活参数、训练数据量和专家数量都纳入其中，同时通过量化位宽和KV cache精度把内存约束写成显式的不等式。然后通过参数拟合（非线性最小二乘 + L-BFGS-B优化），在0.3B、0.5B、0.9B三个激活参数规模上分别找到了最优配置。最优专家数量在内存预算5GB、INT4量化下是8个——不是32个，也不是2个。

这个公式的一个有趣性质是它在两种极限情况下能退化成已知的定律。如果固定架构选择（专家粒度、是否共享专家），它就退化成已有的joint MoE scaling law；如果固定专家数量，它又退化成标准的Chinchilla scaling law。这种"兼容性"让MobileMoE的框架不是凭空造出来的新东西，而是把已有的理论在on-device约束下做了自然的延伸。

这个"8个专家"的结论不是拍脑袋猜的，是优化问题解出来的。我觉得这是MobileMoE在概念上最扎实的地方：它不是"我们在手机上试了很多配置、最后这个最好"的工程报告，而是"在给定约束下，最优配置可以被推导出来"的理论工作。

🏗️ 3. 四段式炼金术

找到了最优架构，下一步是怎么把它炼出来。MobileMoE的训练不是一锅炖，而是分成四个阶段，每个阶段解决不同的问题。

预训练（Pre-training）：在约6T token上从头训练MoE架构。这个数量比同规模的dense基线少——Llama 3.2 1B用了9T，SmolLM2 1.7B用了11T——但MobileMoE的表现匹配或超越了它们。这说明MoE在sub-billion活跃参数规模上的学习效率确实更高：同样的知识，用更少的token、更少的计算就能学到。

中期训练（Mid-training）：继续在高密度数据上训练。这个阶段的目标是把模型从"通才"推向"精专"，在预训练的基础上进一步压缩损失。

指令微调（Instruction Fine-tuning）：让模型学会跟随指令、对话、做任务。这是所有现代LLM变成"助手"的必经之路。

量化感知训练（Quantization-Aware Training, QAT）：这一步对手机部署至关重要。模型在训练时就模拟INT4量化的效果，学会在低位宽下保持性能。没有QAT，直接把FP16模型压缩到INT4，精度通常会掉一大截；有了QAT，量化变成了训练过程的一部分，模型主动适应低位宽的约束。

四阶段pipeline里还有一个值得注意的设计选择：共享专家（shared expert）。在所有MobileMoE的变体中，有一部分专家是"常驻"的——无论router怎么决策，这些专家始终被激活。这个设计的作用是提供一个稳定的基础能力层，防止极端情况下router做出灾难性的路由决策时模型完全崩盘。共享专家的存在让MobileMoE在稀疏度和稳定性之间走了一条中间路线：它不像某些高稀疏度MoE那样把一切都交给router的随机性，也不像dense模型那样拒绝任何稀疏性带来的效率收益。

四阶段pipeline的每一步都不是新鲜事，但把它们组合在一起、专门针对MoE在设备上的稳定性问题做调优，这是MobileMoE的工程贡献。MoE的训练比dense模型更容易不稳定——专家负载不平衡、路由崩溃、梯度爆炸——这些在云端可以用大规模集群和精心设计的并行策略来缓解，但在手机模型的训练预算下，你只有一次机会把事情做对。

⚡ 4. 数字说话

MobileMoE推出了三个型号：Small（0.3B active / 1.3B total）、Medium（0.5B active / 2.8B total）、Large（0.9B active / 5.3B total）。所有型号的INT4权重内存占用都控制在3GB以下，留出空间给KV cache和其他应用。

在14个foundational benchmark上（覆盖常识、知识、科学、理解、推理），MobileMoE建立了一条新的Pareto前沿。

对比dense基线：MobileMoE-S和MobileMoE-M在内存相当的情况下，用2-4倍更少的inference FLOPs达到了匹配或超越dense模型的准确率。这意味着同样的电池电量，你可以多问好几轮问题。

对比MoE竞品：跟当前最先进的on-device MoE模型OLMoE-1B-7B相比，MobileMoE-M用约60%更少的活跃参数和总参数就达到了同样的准确率；MobileMoE-L在活跃参数少30%、内存占用小23%的情况下，准确率还更高。

手机上的实测速度：在商品智能手机上（INT4权重、8-bit KV cache），MobileMoE-S的prefill速度比dense基线MobileLLM-Pro快1.8-3.8倍，decode速度快2.2-3.4倍。prefill是第一次处理你的输入prompt，decode是逐个token生成回答——两者都快，意味着从"你打完字"到"第一个字出现"的延迟更低，以及"整个回答生成完"的时间更短。

更深层地看，这个速度提升的来源有两部分。一部分是MoE本身的计算节省——每次只激活一部分专家，FLOPs自然就少了。另一部分是来自MobileMoE团队对手机推理引擎的专门优化。MoE的路由机制对GPU的内存访问模式很不友好：dense模型每次推理访问的参数是连续的内存块，而MoE需要根据router的决策跳转到不同的专家参数位置，这导致大量的随机内存访问。在手机GPU的带宽有限的环境下，随机访问的代价尤其高昂。MobileMoE如何实现高效的路由和内存访问，论文的具体技术细节我还没读到，但这是从"实验室数字"到"用户口袋里实际体验"的关键一跳。

🧠 5. 我读这篇论文时的几次犹豫

读到这儿，我想暂停技术叙述，记录一下自己理解这项工作时的认知轨迹。

第一次读到"on-device MoE scaling law"时，我的反应是怀疑：手机上的约束这么多（内存、算力、功耗、延迟），用一个简单的参数化公式能把它们全部 capture 住吗？但仔细看了论文的公式后，我觉得它的处理是合理的——内存约束被显式写成权重内存加KV cache的不等式，算力约束被写成训练FLOPs和推理FLOPs的等式，优化目标是最小化损失。当然，真实手机上的内存使用还包括activation buffer、runtime overhead等，论文承认这些被近似处理了。这个诚实让我对结论更有信心。

第二次犹豫来自"首次在商品智能手机上实现高效MoE推理"这个说法。我本能地想问：为什么之前没人做？是因为MoE的路由机制在手机GPU上太难优化，还是因为之前的MoE模型都太大了、根本塞不进手机？论文没有明确回答这个问题，但我猜测两者都有：MoE的conditional routing对内存访问模式很不友好（每次只激活一部分专家，导致随机访问），而dense模型的内存访问是连续的。MobileMoE的推理优化——论文里应该有详细描述，但我目前只读到了摘要和前几页——可能是这个工作能被实际部署的关键。

第三次不确定感来自对scaling law外推的担忧。MobileMoE的拟合数据点在0.3B-0.9B活跃参数、100B-500B训练token、1-32个专家的范围内。如果把这个law外推到1B以上活跃参数或64个以上专家，它还能准吗？论文没有测试这个外推范围，我也不敢断言。

🌊 6. 以信号之流再看一次

让我换一个透镜，把MobileMoE重新描述为一个资源分配问题。

手机上的LLM推理，本质上是在三个相互冲突的约束下做最优决策：准确率（模型有多聪明）、延迟（回答有多快）、能耗（电池能撑多久）。这三个维度构成了一个三维的Pareto前沿，没有任何一个点能在所有三个维度上同时最优。

Dense模型的资源分配是"刚性"的：参数量、计算量、内存占用三者成正比。你想让模型更聪明（更多参数），就必须接受更慢的速度和更高的能耗。这个刚性让dense模型在手机上的扩展性很差——一旦达到内存或功耗边界，就没有调优空间了。

MoE引入了一种"柔性"的资源分配。总参数量（决定内存）和活跃参数量（决定计算）被解耦了。你可以让模型"记住"很多东西（大总量），但只在回答特定问题时"动用"一小部分知识（小激活量）。这种柔性让Pareto前沿向外推了一大步——在同样的内存预算下，MoE可以达到更高的准确率/延迟比。

MobileMoE的scaling law，本质上是在这个三维空间里找到了一条约束面上的最优轨迹。它告诉我们：在手机这个特定的约束集合里，"中等稀疏度"是最优的——太稀疏了内存超限，太密集了计算节省不够。这个"中等"不是一个模糊的形容词，而是优化问题解出来的具体数字。

🎯 7. 如果换一条路走

让我试着推演几种MobileMoE的替代方案，看看它选择的路径落在了什么位置。

路径A：更激进的量化。 不用MoE，直接把dense模型压到INT3甚至INT2。这可以进一步减少内存，但量化精度损失通常会急剧上升——每少一个bit，信息的损失不是线性的。MobileMoE用INT4 + QAT已经是一个相当务实的选择，再往低压可能对模型能力造成不可逆的伤害。

路径B：投机解码（Speculative Decoding）。 用小模型快速生成候选token，再用大模型验证。这可以加速推理，但它需要同时运行两个模型，内存占用反而增加了。在手机的严格内存预算下，这个路径的适用性有限。

路径C：知识蒸馏。 训练一个大的teacher模型，然后蒸馏出一个小的student模型放在手机上。这可以工作，但蒸馏的本质是"用一个更强的外部模型来教一个 weaker 的学生"——student的天花板被teacher的表达能力限制住了。MobileMoE的scaling law则直接问：在给定约束下，最优架构是什么？它不依赖外部teacher，答案来自约束本身。

路径D：更大的dense模型 + 更长的推理时间。 接受手机上的推理速度慢一点，但模型更聪明。这个trade-off对某些场景（比如离线翻译）可能是可接受的，但对实时对话或拍照识物来说，延迟是不可容忍的。

路径E：模型压缩 + 动态深度。 不减少宽度（每层神经元数），而是让模型在推理时动态选择用多少层——简单问题走浅层，复杂问题走深层。这也能节省计算，但它的节省是"纵向"的（层数），而MoE的节省是"横向"的（每层激活的专家数）。两条路是否可以结合——一个既动态选择深度又动态选择专家的模型——论文没有讨论，但我猜测这可能是下一个优化方向。

MobileMoE选择的路径是在"架构层面"做优化——通过MoE的不对称资源分配，让模型在不需要牺牲太多准确率的情况下，同时满足内存和延迟约束。它不是任何一个单一技术的突破，而是多个设计选择（scaling law推导、细粒度专家、共享专家、四阶段训练、QAT、手机推理优化）在一个共同目标下的协同。

📝 8. 几个我绕开的表达

写这篇文章时，我一直在和中文科技写作里的一些惯性做斗争。以下几个词或句式，我刻意没有让它们出现。

"值得注意的是"——这五个字是中文科技写作的万用胶水，粘在任何想强调又不知道如何强调的句子前面。真正值得注意的东西不需要提前预告。

"不是…而是…"——二元对立的句式把复杂现象削平成非黑即白的戏剧。MobileMoE里的dense和MoE不是互相替代的关系，而是在不同约束下的不同选择。用"在…场景下…更优"来描述，比制造虚假对立更诚实。

"赋能""范式""底层逻辑"——这些词在中文科技自媒体里已经通货膨胀到面值归零。我试图用更具体的动词和名词来替代：不是"赋能设备端AI"，而是"MoE让模型在同样的内存预算下用更少的计算量达到更高的准确率"。

文言文句法配白话词汇，核心在于节奏。长短句交错，偶尔倒装，允许主语省略——这些古汉语的骨架子可以让文字有呼吸感。但词汇要现代、具体、不装腔。

🧪 9. 还没搞清楚的事

这篇论文我目前只读到了摘要和部分章节，有些问题暂时没有答案，我在这里诚实地记下来。

问题一：路由开销。 MoE的核心机制是router——一个小的神经网络决定每个token应该送给哪几个专家。这个router本身有计算开销，而且它的决策质量直接影响专家负载的平衡。如果router总是把任务送给同样的两三个专家，其他专家就成了摆设，MoE的计算节省优势就丧失了。MobileMoE在手机上的路由开销具体是多少？负载平衡做得怎么样？论文前几页没有给出这些数字。

问题二：冷启动延迟。 第一次加载模型时，5.3B参数的权重需要从存储（闪存）读到内存（DRAM）。即使INT4量化后只有约2.6GB，这个加载过程在手机上也可能需要几秒甚至十几秒。MobileMoE的首次加载体验如何？论文没有讨论这个用户体验层面的问题。

问题三：多任务切换。 手机上不是只有一个AI应用。如果用户先打开了一个用MobileMoE的翻译app，然后又打开了一个用另一个大模型的聊天app，两个模型同时在内存里争资源怎么办？MobileMoE的设计是否考虑了与其他AI应用共存的情况？

问题四：scaling law的泛化性。 论文的scaling law是在Meta自己的训练基础设施和数据集上拟合的。如果换一批数据、换一种tokenizer、甚至换一个硬件平台（比如从ARM换到RISC-V），这条law的形状会变吗？最优专家数量还会是8个吗？

问题五：与端侧RLVR的结合。 2025-2026年最火的post-training范式是RLVR。如果MobileMoE在预训练后用RLVR进一步提升推理能力，MoE的路由机制会如何影响RL的训练动态？专家会不会出现"某些专做推理、某些专做常识"的功能分化？这是一个有趣的开放问题。

🔧 10. MoE的隐喻：从云端到口袋

MoE的"混合专家"这个名字本身就有很强的直觉性。想象一个医院：全院有三十个科室，但你来看病的时候，前台根据你的症状把你分诊到三四个最相关的科室。其他科室的医生不需要知道你来过，他们的时间也没有被占用。整个医院的知识总量很大（三十个科室），但你个人的诊疗成本只跟那三四个科室有关。

云端的大MoE模型就像一个超大型综合医院——科室越多越好，因为总知识量越大，能处理的病例越复杂。但手机上的MoE更像一个社区诊所：空间有限，不能放三十个科室，但你可以精心选择放哪几个科室、怎么让前台的分诊又快又准。MobileMoE的scaling law，本质上是在问：一个社区诊所的最优科室配置是什么？

当然，这个比喻有边界。真实医院的科室之间可能有协作——一个复杂病例需要多个科室会诊。而MobileMoE的专家之间在推理时基本不交流（每个token只送给他选中的那几个专家），这种"隔离"既是效率的来源，也可能是复杂推理能力的瓶颈。论文没有测试需要深度跨专家协作的任务，我不清楚这个瓶颈在实际中有多严重。

📊 11. 论文元数据

#CrushAI #FeynmanLearning #智柴系统实验室🎙️