DAC2026 | ExpertFlow：高效 MoE 推理系统，单卡部署省内存提速度
最近我们针对稀疏MoE大模型推理优化的工作 ExpertFlow 被顶会DAC 2026接收了，今天想和大家聊聊我们做这个工作的初衷、踩过的坑，以及它到底解决了MoE落地里的什么真问题。
先交代下背景：现在MoE模型火是真的火，Mixtral、DeepSeek-MoE、Qwen-MoE这些开源模型，用远低于稠密大模型的单token计算量，就能跑出差不多的效果，堪称大模型规模化的“性价比之王”。但我们自己跑模型的时候，却结结实实踩了个大坑：
就拿最经典的Mixtral-8×7B来说，全量加载模型权重就要96GB显存，单张A100 80G直接OOM。但离谱的是，这个模型46.7B参数里，有45.1B都是专家模块，单轮输入里，每个token只会激活其中2个专家——90%以上的参数全程闲着，却把显存占得满满当当。
这也是整个行业做MoE推理的核心矛盾：MoE的优势是“稀疏激活”，但落地时却被“全量加载”的内存瓶颈卡死了。
先说说现有方案解决不了的三个痛点
行业里其实早有思路：把不用的专家放到CPU内存里，只把当前要用的加载到GPU，也就是“专家卸载”。但我们把现有方案都跑了一遍，发现三个绕不开的硬伤，也是我们最终要解决的核心问题：
第一个是预测像“开盲盒”。要提前加载专家，就得先预测token会激活哪些专家。之前的方案要么是启发式的，靠统计规律瞎蒙，准度低到离谱；要么是逐层预测的，走一步看一步，上一层算完才知道下一层要找哪个专家，根本没法提前做全局调度，预取的优势完全发挥不出来。
第二个是专家“空跑”太严重。解码阶段最头疼的，就是token路由太碎了。经常出现一个批次里，每个token都要找不同的专家，最后一个批次激活了所有专家，但每个专家只处理1个token。GPU的专家算子，处理1个token和处理4个token的开销几乎没差，就像大货车每次只拉一个快递，油费都赚不回来，算力利用率低到离谱。
第三个是缓存“该留的不留，该踢的不踢”。主流的LRU缓存策略，只看专家最近用没用，完全不管MoE的路由规律。经常出现下一层马上就要用的专家被提前踢出去了，不用的专家反而占着显存，缓存命中率忽上忽下，CPU-GPU来回传数据，延迟直接拉满。
我们当时就想：能不能做一套统一的系统，把“预测-调度-缓存”这三件事打通，而不是各做各的？这就是ExpertFlow的由来。
ExpertFlow的核心思路：用“全局预测”，把被动推理变成主动调度
ExpertFlow不是单点的优化，而是一套端到端的协同优化系统，核心就是用一个超轻量的路由预测器，提前拿到所有token、所有层的全局路由信息，然后用这个信息去指导token调度和专家缓存，从根上解决上面三个问题。
整个系统就三个核心模块，我们可以叫它“三板斧”，今天给大家掰开揉碎了讲：
第一板斧：RPP路由路径预测器，一次性算完所有层的路由，告别“走一步看一步”
之前的预测方案，最大的问题就是串行依赖，必须逐层算。我们直接换了个思路：用一个T5风格的编解码架构，单次前向传播，直接输出所有token、所有MoE层的专家激活概率。
简单说，之前的方案是“爬楼梯，上一层才知道下一层往哪走”，我们的RPP是“直接坐电梯到顶楼，把整栋楼的路线全看清了”。这样一来，在第一个MoE层开始算之前，我们就拿到了完整的全局路由规划，提前预取、全局调度都有了基础。
最关键的是，我们把这个预测器做的极致轻量化：最终的模型大小只有7.21MB，带来的计算开销几乎可以忽略不计。准度还特别能打：域内场景预测准确率最高能到95%，就算跨任务跨数据集，也只掉5-10个百分点，远甩之前的启发式方案。
当时我们测跨域效果的时候还挺意外的：用对话数据集训的预测器，放到翻译、摘要任务里照样能用，说明它学到的不是数据集的表面规律，而是MoE模型本身的路由行为模式，这也是它能落地的核心前提。
第二板斧：TS Token调度器，给token“拼车”，让专家别再“空跑”
有了全局路由信息，我们就能解决专家利用率低的问题了。
之前的token批次是按输入顺序排的，就像乘客随机上出租车，每辆车都要跑不同的地方，最后所有路都要跑一遍，每辆车只拉一个人。我们的TS做的事，就是把要去同一个“地方”（路由路径相似）的token，重新拼成一个新批次。
比如两个批次各4个token，原本每个批次都要激活4个专家，每个专家只处理1个token；重排之后，每个批次只需要激活2个专家，每个专家处理2个token。专家的调用次数直接砍半，单专家处理的token数翻倍，GPU算力利用率一下就上来了。
当然，工程上也踩了不少坑：token重排会打乱KV缓存的顺序，我们专门做了Merge和Reindex两个轻量操作，保证注意力计算的语义完全不变；还设计了双批次流水线，让当前批次的模型计算，和下一个批次的预测、调度并行跑，把额外开销完全隐藏掉，最终调度的CPU开销不到10ms。
从实测来看，专家数量越多，TS的收益越明显：Switch-128模型上，吞吐量直接提了17%，就算是专家数最少的Switch-32，也有3%的稳定提升。
第三板斧：ECE专家缓存引擎，提前给专家留好“车位”，缓存命中率直接拉满
有了预测的路由信息，缓存策略就不用再“事后补救”了，而是可以“提前规划”。
传统的LRU缓存，是给每层固定分几个缓存槽位，用完了再淘汰，完全不考虑接下来要用什么。我们的ECE不一样：根据预测的路由信息，跨层自适应分配缓存槽位，提前预取接下来要用的专家。
举个最简单的例子：GPU缓存只能放4个专家，预测到第一层要用3个，第二层要用2个。我们会先给第一层分3个槽位，第二层分1个，提前把最可能用到的4个专家加载进来；等第一层的专家算完释放了槽位，再立刻加载第二层剩下的专家，全程没有多余的加载和卸载。
当然，预测不可能100%准确，我们还做了实时纠错机制：算的过程中发现预测错了，就用高低优先级队列，在当前专家计算的同时，异步完成专家的换入换出，把I/O和计算完全重叠，就算有预测误差，也不会影响吞吐量。
最终的效果是：缓存命中率最高能到**91.96%**，比LRU策略最高提升了61.15%。尤其是大批次高吞吐的场景，LRU的命中率会暴跌，而我们的策略依然能保持稳定。
实测效果：到底能带来多大的提升？
我们在单张NVIDIA A40 48G显卡上做了全量实验，覆盖了Switch Transformer、Mixtral-8×7B、Qwen1.5-MoE、Deepseek-MoE这6个主流MoE模型，还有对话、翻译、摘要、数学解题4类典型任务，对比了Cache-MoE、SE-MoE这些业界主流的基线方案。
这里挑几个最实在的结果和大家说：
- 显存占用砍到极致：相比全量加载到GPU，我们最高能降低**93.72%**的峰值显存。Switch-128模型从15.26GB降到了1.03GB；之前全量加载直接OOM的Mixtral-8×7B，我们用15.99GB显存就能流畅跑起来。
- 吞吐量提升拉满：在显存卡得最死的场景下，Switch-128模型的吞吐量是SE-MoE基线的10倍；在Mixtral、Qwen、Deepseek这些主流开源模型上，也能稳定做到比Cache-MoE基线高2倍左右的吞吐量。就算用跨域的预测器，这个收益也完全不掉。
当然，我们也得客观说：10倍的提升是极端受限场景下的结果，更能体现方案的上限；在常规的推理场景里，我们能稳定做到1.5-2倍的吞吐量提升，同时显存占用砍到原来的1/5-1/10，这个收益对于实际落地来说，已经非常实在了。
聊聊后续：这个工作到底能用来做什么？
很多朋友问我们，这个工作除了发论文，实际落地的价值在哪？这里也和大家说说我们的思考，也算是对未来工作的展望：
首先最直接的，大幅降低MoE模型的部署门槛。现在大家想跑个大一点的MoE模型，至少要高端显卡甚至多卡，而用我们的方案，消费级显卡也能跑起来Mixtral-8×7B级别的模型，中小团队、个人开发者不用再被硬件卡脖子，就能基于MoE模型做自己的应用。
其次，给云端大模型推理服务降本。现在大模型推理服务，显存成本是大头。用ExpertFlow，同等显存资源下能承载更高的并发，同时降低推理延迟，尤其是现在很多企业都在用MoE模型做私有化部署，这个方案能直接帮他们省下大量的硬件成本。
再往远了说，这个工作的核心——精准的全局路由预测，能做的事远不止单卡卸载。比如分布式MoE推理里，我们可以用路由信息指导专家的分布式放置，减少跨节点通信；还能结合路由规律做模型剪枝、量化、蒸馏，进一步压缩MoE模型；甚至端侧MoE的部署，也能靠这套思路做CPU-NPU的异构调度，让MoE模型真正跑到端侧设备上。
我们也在计划把这套系统开源，让更多开发者能用上，也欢迎业界的同行们一起交流优化。
最后说点心里话
其实做这个工作的过程中，我们也踩了无数的坑：一开始预测器做的又大又慢，token重排把KV缓存搞乱了，缓存预取和计算的重叠总是调不好……但好在最终我们拿出了一套能真正解决问题的方案，也得到了DAC审稿人的认可。
当然，这个工作也不是完美的：比如超长序列场景下的预测精度还有提升空间，和动态批处理、vLLM这些主流推理框架的适配也还有很多工作要做。MoE模型的系统优化，还有太多值得深挖的地方，我们也会在这个方向继续深耕下去。
如果大家对这个工作有什么疑问或者建议，欢迎在评论区交流，我们也会尽可能回复大家。