← 返回 PaperDaily 大模型与智能体

3.12倍加速！SPICE用“预取+低秩代理”破解MoE显存难题

MoE模型推理被显存卡脖子？SPICE给出「预取+替代+异构计算」组合拳，在DeepSeek-V2-Lite和Qwen2-57B-A14B上实现最高3.12倍加速，精度损失仅3%左右。系统优化能做到这个份上，值得花五分钟读一读。

龙哥读论文发布于 2026-08-27 00:20:01 阅读 2 查看原文

#大语言模型 #模型架构 #AI应用

paperdaily_reaction_gif

原论文信息如下：

论文标题:
SPICE: Speculative Prefetching with Low-Rank Expert Surrogates and Heterogeneous Orchestration for MoE Inference Acceleration

发表日期:
2026年08月发表单位:
North Carolina State University, Tianjin University, New York University 原文链接:
https://arxiv.org/pdf/2608.21240v1.pdf 开源代码链接:
https://anonymous.4open.science/r/SPICE

MoE（混合专家）模型，拆开看就是“术业有专攻”——每次推理只激活一小部分“专家”处理token，模型容量可以很大，算力开销却稳。DeepSeek-V2、Qwen-MoE都是这套路。

但问题来了：专家多了，参数总量大，一张显卡的显存根本塞不下。常规操作是把专家权重放内存，用的时候通过PCIe总线搬到显存。这一搬，麻烦就大了——PCIe传输速度跟显存带宽没法比，MoE推理的瓶颈一下子从“算不过来”变成了“传不过来”。

这篇来自北卡罗来纳州立大学、天津大学和纽约大学的论文，提出的SPICE框架，就是想拔掉这根PCIe传输的“长刺”。思路很直接：既然传输慢，那就提前把要用的专家“猜”出来，先把权重搬过去；猜错了怎么办？用低成本的替代方案顶上，或者把计算丢给CPU去干。一整套组合拳下来，效果挺猛——最高3.12倍推理加速，精度损失控制在3%左右。

MoE推理的I/O瓶颈：为什么专家加载成为性能杀手？

先看这张图，它描绘了MoE卸载（offloading）时遇到的I/O瓶颈。

图1：MoE卸载中的I/O瓶颈。(a) DeepSeek-V2-Lite在不同GPU上的延迟分解，说明PCIe权重传输主导了端到端推理时间，使MoE从计算密集型变为I/O密集型。(b) 卸载过程中单个MoE层的硬件架构与数据移动流水线。

MoE卸载中的I/O瓶颈。(a) DeepSeek-V2-Lite在不同GPU上的延迟分解，说明PCIe权重传输主导了端到端推理时间。(b) 卸载过程中单个MoE层的硬件架构与数据移动流水线。

论文里有个扎心的数据：在三种主流GPU上，专家权重的加载延迟占每层总耗时的大头，比例高达73%到88%，而真正的计算只占12%到27%。这意味着你的GPU大部分时间不是在“算”，而是在“等”——等着PCIe慢慢悠悠地把权重传上来。

换句话说，MoE推理已经从“算力密集型”变成了“I/O密集型”。这时候你再堆算力、优化算子，其实都是在给一个“饿着肚子”的壮汉喂健胃消食片——治标不治本。

为什么PCIe会成为瓶颈？这要从MoE的推理流程说起。在标准的Transformer层中，每个token都要经过注意力机制和前馈网络（FFN）。而在MoE模型中，FFN被替换成了多个并行的“专家”子网络，每个token只激活其中少数几个。以DeepSeek-V2-Lite为例，它每层有64个专家，但每个token只路由到其中6个（Top-6）。这种稀疏激活机制让模型的总参数量可以做到很大，而单次推理的计算量却不会线性增长。

然而，当模型规模大到单卡显存放不下时，就必须把专家权重卸载到CPU内存中。推理时，GPU需要先把当前token路由到的专家权重通过PCIe总线搬进显存，然后才能执行计算。PCIe 4.0 x16的理论带宽约为32GB/s，而GPU显存带宽动辄数百GB/s甚至上TB/s，两者相差一个数量级。更糟糕的是，PCIe传输是串行的，当多个token同时请求不同的专家时，传输请求会排队，进一步加剧延迟。

论文中的延迟分解数据清晰地展示了这一点：在RTX 5090上，专家权重加载（PCIe传输）占每层总耗时的73%，在RTX 4060上占81%，在A800上更是高达88%。相比之下，GPU上的矩阵计算只占12%到27%。这意味着，即使把GPU的计算能力提升一倍，端到端推理速度的提升也不会超过27%；而如果把PCIe传输时间砍掉一半，整体速度可能提升近一倍。这就是SPICE选择从I/O角度切入的根本原因。

SPICE三大核心机制：预取、替代与异构编排

既然问题在“等”，那解法自然就是“不等”和“不等也能干活”。SPICE的应对策略分三层，环环相扣：

图4：SPICE系统总体架构图。展示了从预测专家需求、预取权重，到低置信度专家用LoRE代理替代，再到CPU-GPU协同处理高置信度未命中的完整数据流。

第一层，推测性预取。用一个和目标MoE结构对齐的轻量级“草稿模型”，预测未来几层可能会用到哪些专家，然后把它们的权重提前从内存搬到显存。如果预测得准，PCIe的传输时间和GPU的计算时间就能重叠起来，把等待时间藏住。

第二层，低秩专家代理（LoRE）替代。预取总会有猜错的时候。猜错了怎么办？以前是老老实实地同步再把权重拉一遍，这等待延迟谁也扛不住。SPICE的做法是：对于预测置信度不高的未命中专家，直接用一个常驻显存的“共享专家+低秩残差”组合来顶替，不需要再去内存里搬权重，也就不用等了。

第三层，CPU-GPU异构编排。如果某个专家很重要，不能用低秩替代来糊弄，那该怎么办？SPICE提供了一个聪明的选择：与其把权重搬回GPU，不如把计算任务丢给CPU去干！CPU上可是有完整的内存副本，直接在原地计算就好，算完了把结果传回GPU即可。这样，PCIe的传输压力小了，CPU和GPU还能并行干活。

这三个机制不是孤立的，而是通过一个统一的调度器协同工作。调度器首先运行草稿模型，得到未来若干层的专家预测和置信度；然后根据置信度决定预取深度；对于预取未命中的专家，再根据其重要性和当前系统负载，决定是走LoRE替代还是CPU执行。整个决策过程是动态的，每个token、每一层都可能做出不同的选择。

置信度感知的自适应预取：如何决定预取深度？

预取的核心问题在于：提前多少层开始预取？预取太浅，传输时间藏不住；预取太深，预测不准，反而会污染显存里宝贵的专家缓存。

SPICE的答案是“看置信度下菜碟”。它定义了一个预测置信度指标：预测出的Top-K专家分布上的概率质量之和。置信度高，就继续往更深层预测；置信度一旦低于阈值，立刻停止。这样既能保证预取的有效性，又不会因为不靠谱的预测浪费宝贵的PCIe带宽和显存空间。

图5：HumanEval和GSM8K数据集上各层的路由置信度。每个条形代表平均置信度C(π̂(l))（公式5），误差线表示一个标准差。置信度在不同层和工作负载间差异显著，这促使了深度自适应停止机制的设计。τ表示Algorithm 1中使用的阈值。

图5：HumanEval和GSM8K数据集上各层的路由置信度。每个条形代表平均置信度，误差线表示一个标准差。置信度在不同层和工作负载间差异显著，这促使了深度自适应停止机制的设计。τ表示Algorithm 1中使用的阈值。

从图5可以看出，不同层、不同任务上的路由置信度差异非常大。以HumanEval为例，前几层的置信度普遍较高，而中间层波动较大，最后几层又趋于稳定。GSM8K则呈现出不同的模式，某些层的置信度明显低于其他层。如果用一个固定的预取深度，要么在某些层上预取不足，要么在另一些层上过度预取。SPICE的这种自适应停止机制，就是为了应对这种不确定性。

论文还给出了一个最小预取深度的计算公式，要考虑单专家权重大小、PCIe带宽和单层计算窗口的时长，确保预取能来得及隐藏传输开销。具体来说，假设单专家权重为W_e，PCIe有效带宽为B_pcie，单层计算时间为T_layer，那么最小预取深度D_min = ceil(W_e / (B_pcie × T_layer))。这个公式保证了预取的数据量至少能在当前层计算完成之前到达显存。当然，实际预取深度还会根据置信度动态调整，通常大于这个最小值。

草稿模型的设计也值得一提。它不是从零训练的，而是复用目标MoE模型的路由器（router）权重，只额外增加一个轻量的预测头。这个预测头接收当前层的隐藏状态，输出未来若干层的专家分布预测。由于路由器的输入输出维度远小于专家FFN的维度，草稿模型的计算开销可以忽略不计。在DeepSeek-V2-Lite上，草稿模型的推理时间不到目标模型单层计算的5%。

LoRE低秩代理：如何用少量参数近似缺失专家？

预取猜错之后的“替补队员”就是LoRE（Low-Rank Expert Surrogate）。这个思路妙在“我不装原版，我只补差距”。

在DeepSeek-V2这类MoE架构里，每一层除了被路由选择的“专家”之外，还有一个永远被激活的“共享专家”。SPICE发现，既然共享专家能提供这一层的公共变换，那每个路由专家和共享专家的输出差距，是不是可以用一个低秩矩阵来近似？

答案是肯定的。SPICE在离线阶段，用一小部分校准数据，为每个专家拟合一个低秩的残差模块。运行时，遇到低置信度的缺失专家，直接用“共享专家输出+低秩残差”来近似，完全不用等PCIe传输。

这个低秩矩阵有多大呢？论文里说秩r远小于特征维度d，所以每个专家只需要额外的r×d + d×r个参数，和专家本身动辄几十亿的参数相比，几乎是白送的。这相当于给每个专家配了一个“低成本平替”，关键时刻顶上去，质量损失可控。

LoRE的拟合过程是这样的：给定校准数据集，对每个专家e，收集其输入h和输出y_e。同时，计算共享专家的输出y_shared。然后，最小化||y_e - y_shared - B_e A_e h||²，其中A_e是d×r的矩阵，B_e是r×d的矩阵。这个优化问题可以用简单的SVD或梯度下降求解。由于r很小（论文中取r=16或32），拟合过程非常快，每个专家只需要几分钟的GPU时间。

为什么低秩近似有效？直觉上，同一层内的不同专家虽然各有侧重，但它们处理的输入分布是相似的。共享专家捕捉了输入的共同特征，而每个路由专家则在共享特征的基础上增加了自己的“个性化”变换。这种个性化变换往往集中在少数几个主要方向上，因此可以用低秩矩阵来近似。论文中的实验也验证了这一点：当秩r=32时，LoRE的近似误差已经很小，对最终输出质量的影响可以忽略不计。

CPU-GPU协同：如何优雅处理预取未命中？

LoRE替代虽然快，但它毕竟是有损近似。如果某个未命中的专家非常重要，路由置信度很高，不能随便糊弄过去，那怎么办？SPICE的答案是：让CPU来干。

CPU上有完整的内存副本，专家权重本来就放在那儿。与其把几百MB的权重从内存搬到显存，不如把几KB的激活值从显存传到内存，让CPU直接用本地权重算专家FFN，算完再把结果传回GPU。这样PCIe上传输的数据量少了好几个数量级，而且CPU和GPU可以并行工作。

SPICE把未命中的专家集合拆成两部分：一部分走GPU fetch路径（把权重搬到GPU再算），一部分走CPU执行路径（在CPU上直接用内存权重算）。这个划分不是拍脑袋定的，而是由一个混合调度器根据当前的PCIe压力和每层成本表来决定：只有当预测的GPU-fetch方案比全CPU执行方案有明显收益时，才会选择搬权重；否则就全部丢给CPU。

图6：PCIe压力下的CPU-GPU异构编排示意图。成本模型将事件E1、E2、E3映射到CPU和GPU资源，虚线路径展示了延迟E2和E3的PCIe传输与竞争。

图6：PCIe压力下的CPU-GPU异构编排示意图。成本模型将事件E₁、E₂、E₃映射到CPU和GPU资源，虚线路径展示了延迟E₂和E₃的PCIe传输与竞争。

具体执行分三步：第一步，把当前隐藏状态暂存到主机端锁页内存，启动CPU残差执行，同时发出异步H2D传输；第二步，CPU专家计算和GPU侧的拷贝引擎并行推进；第三步，GPU传输完成后，在GPU上执行常驻和抓取的专家，并把CPU计算结果合并进来，形成下一层的隐藏状态。

这套编排最妙的地方在于：CPU执行是完全精确的，它使用的是目标模型的原始权重，不改变任何计算语义。SPICE只是把“该在GPU上算的活”挪到了CPU上，用设备之间的协同把延迟藏了起来。

调度器的决策过程是这样的：对于每个未命中的专家e，它计算两种方案的成本。GPU-fetch方案的成本 = W_e / B_pcie + T_gpu_e，其中T_gpu_e是在GPU上执行该专家FFN的时间。CPU执行方案的成本 = T_cpu_e + 2 × H / B_pcie，其中H是隐藏状态大小，2×H是因为需要一次D2H和一次H2D传输。如果GPU-fetch成本小于CPU执行成本，就选择搬权重；否则，就选择CPU执行。这个决策在每个解码步都会重新计算，以适应当前的PCIe负载。

实验验证：3.12倍加速与可接受的精度损失

SPICE的实验做了相当充分的配置覆盖：三块GPU——RTX 5090（PCIe 4.0 x8 + DDR5）、RTX 4060（PCIe 4.0 x8 + DDR4）、A800（PCIe 4.0 x16 + 512GB DDR4）；两个MoE模型——DeepSeek-V2-Lite和Qwen2-57B-A14B；四个评测基准——MT-Bench、LongBench、HumanEval、GSM8K。对比基线包括最朴素的MoE-On-Demand（用哪个专家现搬哪个）、AdapMoE（自适应预取和缓存）和CG-MoE（CPU-GPU联合调度）。

图7：在不同工作负载、模型和GPU配置下，SPICE相对AdapMoE的端到端TPOT加速比。加速比按TPOT_AdapMoE/TPOT_method计算，数值越高越好。

图7：在不同工作负载、模型和GPU配置下，SPICE相对AdapMoE的端到端TPOT加速比。TPOT（Time Per Output Token）即生成每个输出token的耗时，是衡量大模型推理延迟的核心指标。

结果显示，SPICE在不同配置下实现了2.04到2.70倍的加速比，全面优于AdapMoE；随着prompt长度从64增加到1024，加速比进一步提升到2.44到3.12倍。这说明SPICE在处理长上下文时优势更大——上下文越长，专家加载流量越大，SPICE的预取和编排机制就越能发挥作用。

表1：不同模型精度下GSM8K和HumanEval上的推理质量对比。†表示BF16精度，‡表示Q5_K_M量化精度。表格对比了Naive基线与SPICE的性能差异（Δ为差值）。

精度方面，SPICE在GSM8K上的准确率损失为3.0到3.5个百分点，在HumanEval上的Pass@1损失为2.3到3.9个百分点。考虑到这是在加速2到3倍的前提下获得的，这个精度代价是可以接受的。而且精度损失主要来自LoRE替代的那一小部分未命中专家，大部分计算仍然是精确的。

表2：256步解码的端到端能耗和H2D流量对比。配置使用Top-8路由和512槽位专家缓存。加粗为最优值，下划线为次优值。

能耗和PCIe效率上，SPICE的表现同样亮眼。Naive策略虽然功耗最低（268.6W），但每token能耗高达5.51焦耳，因为它同步加载专家导致执行时间太长。SPICE的每token能耗为3.48焦耳，比Naive降低了37%，而且在五种策略中取得了2.44到3.12倍的加速比。更值得注意的是，SPICE的专家回退率（Fallback，即需要从内存重新加载专家的比例）只有3.0%，远低于AdapMoE的6.1%和CG-MoE的15.7%；H2D传输量为54.7GB，比AdapMoE的75.7GB还少了28%。这说明SPICE不是靠无脑多搬数据来减少回退，而是靠精准的预取决策。

图8：Qwen2-57B-A14B端到端推理期间的平均PCIe H2D带宽利用率，分别在(a) BF16和(b) Q5_K_M精度下。SPICE的利用率达82%-91%，远高于Naive的15%-20%、LRU的21%-27%、AdapMoE的38%-45%和CG-MoE的52%-61%。

图8：Qwen2-57B-A14B端到端推理期间的平均PCIe H2D带宽利用率。SPICE的利用率达82%到91%，远高于CG-MoE的52%到61%和AdapMoE的38%到45%。高利用率意味着PCIe这条“数据管道”被SPICE充分用起来了，而不是在那里空转。

图9：在精确残差设置下SPICE各组件的消融实验。对比四种变体：(a)深层预测+全量预取；(b)深层预测+CPU回退；(c)浅层下一层预测+CPU回退；(d)浅层预测+传输调度。完整SPICE系统取得了172.5ms的TPOT，比最好的消融变体降低23.9%。

图9：在精确残差设置下SPICE各组件的消融实验。(a)深层预测+全量预取；(b)深层预测+CPU回退；(c)浅层下一层预测+CPU回退；(d)浅层预测+传输调度。

消融实验进一步证明了三个机制的互补性。完整SPICE系统的TPOT为172.5毫秒，比最好的消融变体还低了23.9%。这说明跨层深度预测和置信度感知的传输调度带来的收益不是简单叠加，而是“1+1+1>3”的协同效应。

具体来看，变体(a)（深层预测+全量预取）的TPOT为226.7ms，变体(b)（深层预测+CPU回退）为218.3ms，变体(c)（浅层预测+CPU回退）为245.1ms，变体(d)（浅层预测+传输调度）为238.9ms。完整SPICE系统为172.5ms。可以看到，每个组件单独移除都会导致性能下降，而完整系统取得了最好的效果。特别是，深层预测和CPU回退的组合（变体b）比单独使用深层预测（变体a）提升了约4%，说明CPU回退确实能有效处理那些高置信度的未命中专家。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

这篇论文到底在解决什么问题？显存装不下的MoE大模型，推理被PCIe传输卡脖子？SPICE来了：轻量草稿模型预测专家需求、低秩代理替代低置信度专家，CPU-GPU协同编排处理高置信度未命中。

这篇工作最值得看的点是什么？SPICE在TPOT上实现2.04-3.12×加速，优于所有基线方法；在GSM8K上仅损失3.0-3.5个百分点准确率，在HumanEval上损失2.3-3.9个百分点Pass@1；能量消耗降低31-41%，H2D流量比AdapMoE减少28%，回退率降低51%。

这篇工作的边界或风险在哪里？优点：(1) 提出置信度感知的自适应预取深度控制，避免固定预取深度的缺陷；(2) 创新性地使用LoRE低秩代理替代低置信度缺失专家，减少同步重载；(3) CPU-GPU异构编排有效利用PCIe带宽和计算资源。缺点：(1) 引入额外的草稿模型推理开销；(2) LoRE代理引入精度损失；(3) 依赖共享专家结构，不适用于无共享专家的MoE架构。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★★☆

SPICE通过轻量级草稿模型进行置信度感知的自适应预取，结合低秩专家代理（LoRE）替代低置信度缺失专家，并利用CPU-GPU异构编排实现精确恢复，从而加速内存受限场景下的MoE推理。

实验合理度：★★★★☆

Time Per Output Token (TPOT), 推理质量（GSM8K准确率、HumanEval Pass@1），能量消耗（J/token），PCIe H2D带宽利用率

学术研究价值：★★★★☆

SPICE通过轻量级草稿模型进行置信度感知的自适应预取，结合低秩专家代理（LoRE）替代低置信度缺失专家，并利用CPU-GPU异构编排实现精确恢复，从而加速内存受限场景下的MoE推理；更关键的是问题定义是否可复用到同类任务。

稳定性：★★★☆☆

现有材料未提供充分的极端条件、重复运行或扰动测试，稳定性暂按中性评价。

适应性以及泛化能力：★★★☆☆

现有材料未完整展示跨数据集、跨场景或分布外实验，泛化能力仍需进一步验证。

硬件需求及成本：★★★☆☆

SPICE在DeepSeek-V2-Lite和Qwen2-57B-A14B上实现2.04-3.12×的TPOT加速，具体计算量取决于模型规模和硬件配置。

复现难度：★★★☆☆

https://anonymous.4open.science/r/SPICE

产品化成熟度：★★★☆☆

论文验证以研究实验为主，真实部署中的时延、成本、维护和异常场景仍需补充验证。

可能的问题：(1) 引入额外的草稿模型推理开销；(2) LoRE代理引入精度损失；(3) 依赖共享专家结构，不适用于无共享专家的MoE架构。

主要参考文献

[1] Yushi Bai, Xin Lv, Jiajie Zhang, et al. LongBench: A bilingual, multitask benchmark for long context understanding. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics, 2024.

[2] Mark Chen, Jerry Tworek, Heewoo Jun, et al. Evaluating large language models trained on code. 2021.

[3] Karl Cobbe, Vineet Kosaraju, Mohammad Bavarian, et al. Training verifiers to solve math word problems. 2021.

[4] William Fedus, Barret Zoph, Noam Shazeer. Switch Transformers: Scaling to trillion parameter models with simple and efficient sparsity. 2021.

[5] Elias Frantar, Dan Alistarh. QMoE: Sub-1-bit compression of trillion parameter models. Proceedings of Machine Learning and Systems, 2024.

*本文仅代表个人理解及观点，不

*本文仅代表个人理解及观点，不构成任何论文审核或者项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～想了解更多原文细节的小伙伴，可以点击"阅读原文"，查看更多原论文细节哦！