端侧跑 MoE 推理最近一年聊得特别多。各家模型都在往混合专家架构上靠同一份权重里塞几十上百个专家子网络推理时只激活其中几个用稀疏激活换能力上限。听起来很聪明可真正把模型放进开发板或者旗舰手机上搞部署第一个撞上的就是存储墙模型权重动辄几十个GB显存根本放不下即便硬塞进去单个 token 的推理也要反复把专家权重搬进搬出IO 带宽直接卡死算力。我自己在模拟项目 X 里完整折腾过一轮从显存规划、权重预取、量化回补到异构流水线踩了不少坑也积累了一些实测有效的方法。这篇文章把整套思路和实操细节整理出来给正在做端侧推理或者准备做端侧 MoE 落地的朋友一个参考。先说清楚这套方案解决的核心问题模型在端侧从“能跑”变成“跑得快”。解决手段一句话总结——先用精算账本把显存需求压缩到硬件红线以内再用预取重叠把 IO 等待藏进计算时间用量化补偿把压缩损失找回来最后用异构流水线把所有器件按各自擅长的方式组织起来。适合的人群是有一定模型部署经验、手头有 NPU/GPU 开发板或旗舰手机、正在被显存容量和带宽折磨的工程师。1. 端侧 MoE 推理的存储墙问题到底是什么1.1 MoE 模型的结构特点与推理特性混合专家结构跟传统密集模型最大的区别在于模型总参数非常多但每次推理只点亮一小部分。具体来说一个典型 MoE 层包含一个共享的注意力/FFN 基础模块以及一组并行的专家子网络通常 8 到 64 个不等。输入 token 先经过路由 Gate 打分选出得分最高的 top-2 或 top-3 个专家参与计算其余专家本 batch 内完全不产生计算。从项目简介的角度看稀疏激活带来了三项收益同等参数量下能力更强、单 token 计算量可控、可以堆叠更大规模的先验知识。但从工程部署的角度看“总权重驻留”这个事实无法回避。总有开发者以为 MoE 推理时只加载被激活的专家就行实际并非如此——路由是动态的下一 token 激活哪几个专家完全不确定所以全部专家权重都必须在线。这就产生了端侧最尖锐的矛盾模型磁盘占用可能超过 20GB而端侧可用显存往往只有 4 到 8GB。1.2 为什么端侧“存储墙”比数据中心更难受数据中心的 GPU 服务器有几百 GB 显存权重驻留通常不是问题卡在计算和跨卡通信上。端侧则完全反过来算力其实相对够用尤其是新一代移动 NPU 的 INT8 算力已经达到数十 TOPS卡死你的从来不是 FLOPS而是权重搬运。我这里有一个很直观的实测数据。某开发板上的 NPU 理论算力大约 45 TOPS跑一个 7B 密集模型每 token 的稠密计算量约 20 GFLOPs理论上单 token 延迟应该在 0.5ms 以内。但实际测出来是 30ms 以上。差在哪权重从 DRAM 到片上 SRAM 的搬运时间占了 90%。再看 MoE 版本7B 总参数、1B 激活参数计算量是降低了但每次 token 需要读取全部专家权重即便只计算 top-2也得为这些专家准备好参数驻留如果路由分布均匀整份专家权重都会被频繁读取访存量不降反升。这就是存储墙的两个维度容量墙——权重驻留超限就装不下带宽墙——权重每次推理都要过一遍总线带宽成了真瓶颈。要破局必须把这两个维度分别拆开处理后续所有方案都围绕这两件事展开。2. 显存账本精算先算清楚账再动手2.1 静态显存权重参数怎么精确记账所谓显存账本就是把模型的每一块占用精确估算出来而不是拍脑袋估一个“大概 8GB”。第一步是盘点静态权重。以某 14B 参数的 MoE 模型为例FP16 存储需要 28GB显然端侧装不下。做 4bit 量化后权重降到 7GB再做 2bit 量化能到 3.5GB但精度损失需要后面补偿。这里有一个容易遗漏的点MoE 模型里不是所有部分都适合低比特。路由 gate 和最终输出层对精度极敏感我通常保留 FP16专家内部 FFN 矩阵则可以用 4bit。混合精度的账本计算公式为总权重占用 共享层参数 × 1 × 2字节 路由层参数 × 1 × 2字节 专家总参数 × 量化权重平均字节数比如共享层 1.5B、路由 0.1B、专家 12.4B4bit 量化后为 12.4 × 0.5 6.2GB加上共享层和路由的 3.2GB合计约 9.4GB。如果硬件可用显存只有 6GB就还需要继续压缩或者走后面的预取卸载方案。这一步的教训是不要把所有层一刀切量化混合精度的静态占用差异能到 2 到 3 倍先把账算到字节粒度再谈优化。2.2 动态显存激活值和 KV Cache 的计算静态权重之外推理过程中还有两部分动态占用。一部分是激活值也就是每层的中间张量另一部分是 KV Cache即注意力阶段缓存下来的 Key 和 Value 张量。KV Cache 的计算公式比较固定2K 和 V 两份× 层数 × 序列长度 × 每层 KV 头数 × 头维度 × 字节数。以 40 层、64 个 KV 头、head_dim 为 128、序列 2048、FP16 为例单条序列的 KV Cache 约为 2 × 40 × 2048 × 64 × 128 × 2 字节算下来约 2.68GB。如果同时处理 4 条并发序列就超过 10GB直接爆掉。所以端侧部署通常必须限制并发数很多实际工程把并发压到 1 到 2。激活值方面batch1 时 token 级激活不大但前向计算时如果算子实现不佳中间结果可能把内存峰值抬高。我在项目里常见的一个坑是某个融合算子没做内存复用峰值激活能到 2GB而做了算子间内存复用后降到 400MB。所以激活值记账时不要只看原理上的最小值要实际跑一遍 profiling看内存分配器的峰值。2.3 一张完整的显存账本示例我把一个模拟项目的显存账本列出来方便你对照自己的模型做预算项目计算方式容量专家权重4bit 量化12.4B × 0.5 字节6.2GB共享层路由FP161.6B × 2 字节3.2GBKV Cache序列 1024单并发40×1024×64×128×2×21.34GB激活值复用优化后profiling 实测0.4GB推理框架运行时开销实测预留0.3GB合计—11.44GB如果目标硬件是 8GB 可用显存账本差 3.44GB。这时候只有两个方向要么把专家权重改成 2bit再从 KV Cache 下手量化到 8bit要么就设计权重预取让一部分专家不常驻显存用到时才搬进来。预取这条路更现实因为 2bit 的精度补偿成本很高。这也是为什么我把“预取 I/O 重叠”放在显存账本之后讲——账算完了才知道该从哪里省。3. 预取 I/O 重叠让数据在计算时悄悄“在路上”3.1 顺序预取的问题专家访问模式是不确定的传统的模型推理预取很简单按层顺序把下一层权重提前搬到片上。MoE 则不一样下一层要访问哪个专家由当前 token 的路由结果决定而路由结果本身要等当前层计算完才出来。如果等路由结果出来再加载专家权重IO 等待时间就完全暴露在关键路径上这基本是最差的情况。我曾经试过最朴素的做法计算第 i 层时顺带把第 i1 层所有专家的权重全部预取到 SRAM。这种做法解决了“等路由”的问题但代价惊人。假设每层 16 个专家、每个专家 20MB预取全部专家需要 320MB 带宽而实际上只用到 2 个40MB。SRAM 总容量可能只有几 MB这种粗放预取根本放不下反而把有限的缓存污染了。正确的思路是只预取大概率会用到的专家而不是全量预取。既然路由结果没出那就做一个预测。端侧场景 token 之间的路由往往有一定连续性用前几个 token 的路由统计做预测可以覆盖相当一部分访问再结合后续的 prefetch 队列把命中率做到 70% 以上并不难。3.2 双缓冲预取队列的实现要点我把预取实现拆成两个部分预测器 异步搬运队列。预测器维护一个专家访问频率表比如最近 N 个 token 里每个专家被路由的次数下一次预取时选频率最高的 K 个专家装入预取队列。异步搬运队列用双缓冲结构buffer A 在 NPU 计算当前专家时buffer B 同时从 DRAM 搬运下一批专家权重。这样 IO 和计算重叠关键路径上不出现等待。实际编码上C 风格伪代码如下// 双缓冲预取循环示意 while (token ! END) { // 预测下一 token 最可能用到的专家集合 top_experts predict_next_experts(token_context); // 检查 cache未命中的专家发起异步预取 for (e in top_experts) { if (!cache.contains(e)) { issue_async_load(e, buffer[1 - current_idx]); } } // 计算当前 token 的专家前向 compute_experts(token, buffer[current_idx]); // 等待预取完成因为计算时间通常长于搬运时间这里几乎不会真正阻塞 wait_for_prefetch_done(); swap_buffers(); token next_token(); }这个设计的成败取决于一个假设计算时间 搬运时间。搬运时间约等于专家权重大小除以可用带宽计算时间则是专家 FFN 的算力需求除以实际算力。端侧 NPU 的带宽算力比往往不够理想比如某开发板 25GB/s 带宽、45 TOPS 算力一个 20MB 专家权重 INT8 算力需求约 0.4 GFLOPs搬运 0.8ms、计算 0.09ms搬运远慢于计算预取重叠效果会很差。这时候必须靠两个手段补一是把专家权重压缩到 4bit 或 2bit搬运量直接减半到四分之一二是调整 Batch 粒度让一个批量内的 token 共享同一批专家权重摊薄平均搬运成本。3.3 预取命中率与缓存策略预取不是万能的命中率直接决定收益。如果预测命中率只有 50%那剩下 50% 的 token 仍然要走“路由结果出来后同步加载”的老路。这里有几个实测有效的技巧利用路由的时序局部性。很多语言模型的路由模式存在连续性同一句话相邻 token 往往倾向于选择相似的专家。用滑动窗口维护最近 10 个 token 的专家分布能显著提高预测精度。分组预取。把专家按“语义功能”聚类比如某些专家偏向处理代码、另一些偏向处理自然语言。预取时一次搬一组组内命中率远高于单专家预测。分组依据可以从训练数据或者门的权重相关性里挖出来。缓存替换策略用 LFU 而不是 LRU。MoE 的访问频率呈长尾分布热门专家被高频访问冷门专家偶尔闪现。LRU 会把热门专家误淘汰LFU 更符合这种访问模式。实测效果上我在模拟项目 X 里用滑动窗口预测 LFU 缓存专家命中率从 63% 提升到 81%端侧 token 生成速度提升约 1.7 倍。剩下的 19% 未命中代价需要靠后续流水线隐藏不能完全消除但已经可以接受了。4. 量化补偿精度降下来之后怎么把损失补回去4.1 量化误差的两个主要来源量化是端侧 MoE 绕不开的手段没有量化权重根本驻留不进显存。但量化不是简单把 FP16 截断成 INT4关键是搞清楚误差从哪里来。我拆成两类分布截断误差和离群值放大误差。分布截断误差指的是模型权重的分布通常是近似高斯或拉普拉斯分布但存在少量绝对值特别大的离群值。如果直接按最大值做均匀量化离群值占据了大半动态范围其他普通权重只能使用很窄的码位精度损失被剧烈放大。这就像一间教室里有一个两米二的巨人你把门框按巨人的身高设计其他人都够不着开关。离群值放大误差则更隐蔽量化误差经过 MoE 的路由和后续专家计算后被放大。路由 Gate 本身用的是高精度浮点它选中的专家如果权重被量化破坏输出偏差会被进一步传递。我在项目里观察到同一个模型 4bit 量化后均方误差看似不大但生成文本的流畅度和事实性明显下降这就是误差在深层传播的典型表现。4.2 离群值感知和混合精度补偿的核心手段针对离群值业界通行做法是离群值通道拆分。把权重矩阵中那些数值明显偏大的通道单独提取出来保持 FP16其余通道做低比特量化。这样做增加的静态显存有限通常只有 1% 到 3% 的通道需要保留高精度却能保留绝大多数动态范围。实际操作时按通道统计权重的 abs max设定一个阈值比如超过该层均值 5 倍以上的通道标记为离群通道。混合精度的选层策略也需要注意。我用过一个经验法则靠近输入和输出的层用 8bit中间层用 4bit。原因是首尾层直接接触原始 token 语义和最终输出分布对精度最敏感中间层经过多层抽象鲁棒性更强。总占用接近全 4bit 方案但端侧生成质量能提升一个档次。另外量化补偿并不只在推理阶段做。如果在微调阶段就加入量化感知训练QAT让模型在低比特约束下重新适应效果远好于后训练量化PTQ再补偿。端侧团队往往没有训练资源那就退而求其次用一小段校准集做逐层误差补偿即量化每一层后对比该层输入输出用最小二乘拟合一个补偿矩阵把均方误差压下去。这个方法不需要反传梯度只需要前向跑几十条样本工程上很好落地。4.3 校准集选择和 per-channel 粒度的实战细节校准集的选择直接影响量化质量。很多人随手拿训练集几百条样本就开干结果量化误差大得离谱。原因在于校准集分布和实际部署场景差异太大。我的建议是收集三类数据通用文本、代码、结构化指令各拿几百条混合后用这组数据做校准。这样校准出的量化参数覆盖的场景更广遇到边缘案例时不容易崩。per-channel 和 per-tensor 的选择同样关键。MoE 专家权重矩阵通常维度很高不同 channel 的 scale 差异很大必须用 per-channel 量化。这是一条硬经验在 MoE 上做 per-tensor 量化基本等于直接宣判效果死刑。per-channel 后每个 channel 有自己的 scale 和 zero point计算时先反量化再乘加会多一点点开销但对精度收益来说完全值得。我在模拟项目 X 里做过一组对照实验全 FP16 基线、per-tensor INT4、per-channel INT4、per-channel INT4 离群通道 FP16。第四个方案相对第二个在困惑度上只差 0.8%相对第一个基线的差距也控制在 2% 以内但显存占用降到原来的八分之一。这才是量化补偿真正要达到的目标——不是数学上的无损而是端侧体验上的近似无损。5. 异构流水线落地让每个计算单元干它最擅长的事5.1 异构调度的整体结构显存账本解决容量问题预取重叠解决带宽问题量化补偿解决精度问题最后一步是把这些技术放在一个统一的执行框架里。异构流水线的核心思想一句话不要把端侧设备当成单一 NPU而是当成一个多核异构系统来调度。常见的端侧硬件实际上有 CPU、NPU或 GPU、DSP。NPU 擅长矩阵乘加的大规模并行CPU 擅长控制流和逻辑判断DSP 擅长数据搬运和简单运算。我在设计某个端侧推理引擎时做了以下分工NPU 负责全部线性层计算包括共享注意力、专家 FFN 前向、路由 Gate 打分。CPU 负责预取决策和任务调度处理路由结果、预测下一组专家、维护预取队列、控制各 buffer 的切换。DSP 负责权重解压和格式转换量化权重的反量化、格式重排、内存拷贝这些操作大量消耗带宽但不需要复杂计算正好是 DSP 的强项。内存池统一管理显存账本作为硬约束所有算子启动前先向内存池申请空间内存池根据账本预分配不允许超额。这样做的收益是CPU 的调度延迟不再占用 NPU 计算时间DSP 解压数据和 NPU 计算可以真正并行所有器件跑起来时整个系统像一个三级的装配流水线而不是一个串行接力赛。5.2 流水线气泡和负载均衡的实际处理异构流水线最怕的东西是气泡某一环在等上一环整条流水线停转。我在初期版本里踩过一个典型问题NPU 计算速度太快DSP 解压来不及CPU 的预取指令经常因为 buffer 还没准备好而阻塞。整个系统陷入频繁的空转等待实际吞吐比单器件串行还低。解决办法有两个。第一个是增大 buffer 深度从双缓冲改三缓冲甚至四缓冲。双缓冲只允许一读一算三缓冲允许解压、搬运、计算同时进行气泡概率显著下降。代价是每多一层 buffer 就多一份权重驻留显存这需要回到显存账本里重新精算。第二个办法是动态 Batch 聚合如果 CPU 发现预取队列长期空转就暂时把当前 token 挂起等下一两个 token 一起组成一个小 Batch 再送进 NPU。Batch 变大后专家权重复用率升高搬运次数减少流水线自然跑满。负载均衡方面我吃过亏的是初始划分静态死板。比如 DSP 解压占用 60% 带宽CPU 调度占用 20%NPU 计算占用 20%但实际推理中比例会因为上下文长度变化而波动。后来我把分工做成动态可调上下文短时KV Cache 小DSP 负载低可以多分一些搬运任务给 DSP上下文长时KV Cache 变大DSP 压力高则把部分解压转回 NPU 的处理闲时。调度器每隔几十个 token 采集一次各器件负载做一次微调整体吞吐比静态划分提升了约 15%。5.3 实测效果与参数配置参考下面是我在模拟项目 X 的开发板上跑的一组代表性数据模型为人工模拟的 14B MoEINT4 专家权重序列长度 2048单并发配置显存占用首 token 延迟稳态生成速度备注全 FP16 无预取超出硬件无法运行——直接不可用INT4 无预取无流水线6.8GB1.8s4.2 token/s勉强能跑带宽瓶颈明显INT4 双缓冲预取6.8GB1.2s7.1 token/s预取带来明显增益INT4 三缓冲 异构流水线7.1GB0.9s11.6 token/s流水线各环节跑满INT4 三缓冲 动态 Batch 聚合7.3GB1.0s13.8 token/s吞吐最优首 token 略降可以看到最关键的增益来自预取和流水线重叠这一项把稳态生成速度翻了近三倍。显存只多付出了 0.5GB这是可以接受的代价。首 token 延迟反而略有上升是因为开启动态 Batch 聚合后最初几个 token 可能被暂时蓄积这个取舍要按业务需求判断。如果产品首 token 体验优先就关掉动态聚合保留三缓冲。参数配置上我最终使用的几个关键值专家缓存容量 1.5GB、预取队列深度 4 个专家组、离群通道阈值 5 倍均值、DSP 解压优先级高于 CPU 调度。这些值不是拍脑袋定的前两个来自显存账本的剩余空间推算后两个来自调试过程中的 profiling 数据。每个人的硬件和模型不一样配置一定不会相同但这套“算账 → 重叠 → 补偿 → 流水线”的框架是通用的。6. 常见问题与排查技巧实录6.1 预取命中率上不去的排查有次我在新模型上复现方案预取命中率只有 40%远低于之前的 81%。排查下来发现新模型的专家数量从 16 个增加到了 64 个滑动窗口预测的准确率天然下降。改进方式是引入“当前 token 语义类别”作为额外特征先对输入 token 做一个轻量分类比如属于代码、数学、对话中的哪一类然后在该类别内统计专家分布。分类本身只需一个几百维的 embedding 做最近邻查询成本很低但命中率回升到 75% 左右。如果你的命中率长期上不去先不要怀疑缓存策略而是看看预测器用的特征是不是太粗糙。6.2 预取导致显存越界的处理三缓冲比双缓冲多占一份权重空间稍不注意就会触碰显存上限。我在项目中期遇到过 NPU 报内存分配失败回看显存账本发现动态 Batch 聚合导致 KV Cache 瞬时变大正好跟额外 buffer 撞在一起。解决方法是把 buffer 空间和 KV Cache 空间放进同一个受控内存池池子满了优先回收预取 buffer而不是直接报错。这个优先级策略来自“预取是优化项、KV Cache是必需项”的判断哪怕预取全部失效也不能让模型因为缓存抢占而崩掉。6.3 低比特量化后输出质量差先查门和首层如果量化后生成质量出现明显下降不要盲目继续压低比特数先检查两处路由 Gate 是不是被量化了。Gate 输出直接决定选哪个专家选错专家的损失是连锁性的。我一般要求 Gate 必须保持 FP16哪怕专家全 4bit。这一点在量化时最容易因为“占空间小”而被忽略。首层 embedding 权重的离群值。首层直接接收 token embedding误差被逐层放大。如果首层的离群通道拆分没做干净后面多少补偿都救不回来。补完这两处之后绝大多数“量化后答非所问”的问题都能缓解。如果还不够再考虑把 QAT 纳入训练流程但这是另一个大工程端侧团队通常用后训练量化加逐层补偿就足够了。6.4 异构调度死锁在异构流水线联调时最容易出现的死锁场景是CPU 等待 DSP 解压完成DSP 等待 NPU 释放 bufferNPU 等待 CPU 下发指令三环互等。我当时花了一整天追这个 bug最后发现根因是 buffer 回收和释放共用一把锁一个器件持有锁后被挂起直接卡死整条链。解决方式是拆锁每个 buffer 配独立的读写状态位CPU 调度时不再全局加锁而是采用无锁队列 原子操作。改造后整个调度循环的核心延迟大幅降低也顺手消掉了大部分帧率波动。如果你也遇到“偶尔卡住几十毫秒”的诡异问题优先看共享锁。7. 一点个人经验收尾这套方案从显存账本到异构流水线每一环单独拿出来都有不少文章写过但真正难的是把它们按正确的顺序组织起来。我自己最大的体会是不要先上优化先把账算清楚。很多团队一上来就做量化、做预取最后发现瓶颈根本不在那里白白折腾几周。按“容量够不够 → 带宽能不能藏 → 精度掉多少 → 算力怎么排”的顺序推进每次只解决一个约束问题会清晰很多。另外一个很实际的建议做端侧 MoE 推理一定要在目标硬件上做 profiling而不是在服务器模拟器上自我感动。模拟器测出来的带宽、缓存行为、调度开销跟真实硅片差得不是一星半点。就拿预取来说服务器上命中率再高到了端侧缓存容量不足照样失效。我在模拟项目 X 里最终能跑到 13 token/s 以上靠的不是某一项黑科技而是把每个环节的损耗一点点抠下来最后攒出来的整体收益。如果你正在做类似的部署希望这篇经验能帮你少走几趟弯路。后续还可以继续扩展的方向是序列级别的预取策略优化以及把量化补偿跟运行时 profiling 数据打通实现自适应比特位宽这些都是值得再深挖的领域。