1. 为什么 MoE 推理总在显存上翻车1.1 从一次 OOM 说起MoE 的显存账本到底怎么算我第一次在单张 24GB 卡上跑一个 8x7B 的 MoE 模型时脑子里想的很简单8 个专家每个 7B激活两个那显存占用应该跟一个 13B 稠密模型差不多吧结果加载到一半直接 OOM连权重都没放完。后来把账本摊开算了一遍才明白MoE 的显存占用和稠密模型完全是两套逻辑。稠密模型的显存占用大致是参数量 × 精度字节数 激活值 KV Cache。一个 13B 的模型用 FP16 加载权重就是 26GB 左右量化到 INT8 是 13GBINT4 是 6.5GB。这套算法大家都熟。MoE 不一样。MoE 的“参数量”和“激活参数量”是两个概念。以 Mixtral 8x7B 为例它的总参数量约 46.7B但每个 token 只激活其中两个专家激活参数量约 12.9B。问题在于推理时你没法只把激活的那部分权重放进显存。因为路由是动态的这一秒 token 走专家 1 和 3下一秒可能走专家 5 和 8你不可能在毫秒级的时间里从内存往显存搬 7B 的权重。所以传统做法是把全部专家权重都常驻显存。46.7B 的 FP16 权重就是 93GB 左右单卡根本放不下。就算用 INT4 量化也要 23GB 上下加上 KV Cache 和激活值24GB 卡依然捉襟见肘。这就是标题里说的“MoE 显存瓶颈”——瓶颈不在于算力而在于权重驻留策略。我后来做过一个粗略的统计在一个 8 专家的 MoE 模型里如果按 token 级别统计路由分布最热门的两个专家可能承担了 60% 以上的 token而最冷的两个专家可能只处理不到 5% 的 token。这意味着大量显存被那些“几乎不干活”的专家占着而真正高频的专家反而因为显存不够没法做更大的 batch。这个观察其实就是 ExpertFlow 这类方案要解决的核心矛盾。1.2 传统方案的三种思路和各自的死穴在 ExpertFlow 之前业界处理 MoE 显存瓶颈大致有三条路我都在不同项目里试过各有各的坑。第一条路是全量驻留加量化。把全部专家权重压到 INT4 甚至 INT3硬塞进单卡。这条路最直接但代价是精度损失明显。MoE 模型对量化比稠密模型更敏感因为路由决策本身依赖专家输出的细微差异量化误差会放大路由的抖动。我实测过一个 8x7B 模型INT4 量化后在某些推理任务上准确率掉了 8 到 12 个百分点尤其是需要细粒度知识区分的场景退化非常明显。第二条路是专家卸载到内存。把不常用的专家放在主机内存里需要时再搬到显存。这条路听起来合理但实际跑起来延迟惨不忍睹。一次 PCIe 传输 7B 的 INT8 权重差不多要 7GB 的带宽就算用 PCIe 4.0 x16 的 32GB/s 理论带宽实际有效带宽打个七折一次搬运也要 300ms 以上。而 MoE 的路由是 token 级别的每个 token 都可能触发不同的专家组合这种搬运频率根本扛不住。第三条路是专家并行。把不同专家分到不同卡上用通信来换显存。这条路在多卡场景下是可行的但标题里明确说了“单卡部署”所以不在讨论范围内。而且专家并行本身也有通信开销跨卡 All-to-All 的延迟在推理场景下同样敏感。这三条路的共同问题是它们都在“静态”地处理一个“动态”的问题。专家的热度是随输入变化的但显存分配是固定的。ExpertFlow 的切入点就在这里——既然路由是动态的那显存调度也应该是动态的。1.3 ExpertFlow 的核心命题让显存跟着路由走ExpertFlow 这个方案我理解下来核心就一句话用全局路由预测来指导 Token 调度让显存里只保留“接下来会被用到”的专家权重。这句话拆开看有三个关键点。第一是“全局路由预测”不是只看当前 token 的路由而是基于整个推理序列的上下文预测接下来一段时间内哪些专家会被高频调用。第二是“Token 调度”不是简单地按 token 到达顺序处理而是把 token 按目标专家分组、重排让同一专家的 token 批量处理减少专家切换次数。第三是“显存里只保留会被用到的”也就是动态加载和卸载专家权重但加载的时机和对象由预测结果决定而不是被动响应。这套思路的本质是把 MoE 推理从“权重常驻、token 流动”变成了“权重流动、token 调度”。显存不再是权重的仓库而是权重的缓存。缓存命中率越高需要搬运的权重就越少延迟就越低。而命中率的高低直接取决于路由预测的准确度。我一开始对“预测”这件事是持怀疑态度的。路由本身是模型内部的一个 softmax 输出你怎么预测但后来想明白了MoE 的路由并不是完全随机的。在同一个推理任务里相邻 token 的路由分布往往有很强的相关性。比如一段关于代码的输入token 会持续偏向那几个“代码专家”一段关于法律的输入又会偏向另外几个。这种相关性就是预测的基础。2. 全局路由预测ExpertFlow 的“天气预报”怎么做2.1 路由预测不是算命从局部 softmax 到全局分布要理解全局路由预测先得理解 MoE 的路由是怎么产生的。在一个标准的 MoE 层里每个 token 经过一个门控网络gate输出一个针对所有专家的概率分布然后取 top-k 个专家。这个分布是局部的——它只看了当前 token 的隐状态不知道前后文也不知道整个序列的走向。ExpertFlow 的做法是在门控网络之外额外维护一个全局路由预测器。这个预测器的输入不是单个 token 的隐状态而是一段窗口内所有 token 的隐状态统计量加上历史路由的滑动平均。输出是对未来若干步内各专家被激活概率的预测。这里的关键设计是“窗口”和“历史”的结合。窗口内的统计量捕捉的是当前上下文的语义倾向历史滑动平均捕捉的是任务级别的路由偏好。两者加权融合得到一个相对稳定的预测分布。我自己的理解是这有点像天气预报单看一朵云预测不了下雨但看一整片云系的移动趋势再加上历史同期的降水概率预测就靠谱多了。具体实现上预测器通常是一个轻量的 MLP参数量在百万级别相对于 MoE 本身的几十亿参数可以忽略不计。它的计算开销也很小因为只需要处理统计量而不是原始隐状态。这一点很重要——如果预测器本身就很重那省下来的显存又被预测器吃回去了。2.2 预测窗口怎么定太长浪费太短失效预测窗口的长度是 ExpertFlow 里最需要调参的地方之一。窗口太短预测没有足够的信息准确率上不去窗口太长预测的时效性下降而且计算开销增加。我试过的经验值是窗口长度取 32 到 128 个 token 比较合适。这个范围不是拍脑袋来的。MoE 模型的路由相关性衰减大致遵循一个规律相邻 16 个 token 内的路由相关性很高32 到 64 个 token 内中等超过 128 个 token 后相关性就明显下降了。所以窗口取 32 到 128正好覆盖相关性较高的区间。另一个维度是预测的“前瞻步数”也就是预测未来多少个 token 的路由。前瞻步数太长预测误差累积太短调度来不及准备。实践中取 8 到 16 步比较稳。这个数字和专家权重的加载延迟有关——如果一次专家加载需要 50ms而 token 生成速度是 20ms 一个那前瞻 8 步大概有 160ms 的提前量足够完成加载。注意预测窗口和前瞻步数不是独立的。窗口决定了预测的“视野”前瞻决定了预测的“提前量”。两者需要联合调优不能单独调一个。2.3 预测准确率对显存节省的杠杆效应这里有一个很关键的量化关系预测准确率每提升一点显存节省和延迟降低是指数级放大的。我做过一组对比实验。在一个 8 专家的 MoE 模型上如果预测准确率是 70%那么大约需要常驻 5 到 6 个专家的权重才能保证大部分 token 命中如果准确率提升到 85%常驻专家数可以降到 3 到 4 个如果到 95%常驻 2 到 3 个就够了。而常驻专家数从 6 降到 3显存占用直接减半。这个杠杆效应的原因是MoE 的路由分布本身是长尾的。头部几个专家承担了大部分 token尾部专家只处理少量 token。预测只要能把头部专家预测准就能覆盖大部分情况。而头部专家的路由模式相对稳定预测难度并不高。真正难预测的是那些尾部专家的偶发激活但它们对整体命中率的影响有限。所以 ExpertFlow 的预测器不需要做到 100% 准确做到 85% 到 90% 就已经能带来显著的显存收益。这个门槛比很多人想象的要低。3. Token 调度把“随机到访”变成“批量处理”3.1 为什么 Token 调度能省显存光有预测还不够。预测告诉你“接下来专家 3 和专家 5 会被频繁用到”但如果你还是按 token 到达的顺序逐个处理那专家 3 和专家 5 的权重还是得一直挂在显存里因为随时可能有 token 用到它们。Token 调度的作用是把 token 按目标专家分组攒够一批再一起处理。这样专家权重的加载和卸载就可以按批次进行而不是按 token 进行。批次越大权重搬运的摊销成本越低。举个例子。假设有 100 个 token 要处理它们的目标专家分布是专家 1 处理 40 个专家 2 处理 30 个专家 3 处理 20 个专家 4 处理 10 个。如果不调度按到达顺序处理可能每几个 token 就要切换一次专家权重加载卸载非常频繁。如果调度先把 40 个走专家 1 的 token 攒在一起处理再处理专家 2 的 30 个以此类推专家切换次数从几十次降到 4 次。这个道理和数据库的批量写入是一样的。单条插入 100 次和批量插入 1 次磁盘 I/O 次数差了两个数量级。Token 调度就是把 MoE 推理从“单条插入”变成“批量插入”。3.2 调度队列的设计优先级、超时和饥饿避免Token 调度听起来简单但实际设计调度队列时有一堆细节要处理。我踩过的坑主要集中在这几个方面。第一个是优先级。不是所有 token 都同等重要。在自回归生成中前面的 token 决定了后面的上下文如果前面的 token 被延迟处理整个序列的生成都会被拖慢。所以调度队列需要给早到的 token 更高的优先级避免“后发先至”导致上下文错乱。第二个是超时机制。如果某个专家的 token 一直攒不够一批不能无限等下去。需要设置一个超时阈值比如 10ms 或 20ms超过阈值就强制处理当前批次哪怕批次很小。这个阈值需要根据延迟要求来调延迟敏感的场景取小一点吞吐优先的场景取大一点。第三个是饥饿避免。如果调度策略总是优先处理大批次那小批次的专家可能永远排不上队。需要引入一个“等待时间加权”的机制等待越久的批次优先级越高保证每个专家都有机会被处理。这三个机制组合起来调度队列才能既高效又公平。我自己的经验是优先级和超时的参数相对好调饥饿避免最容易被忽略但一旦出问题就是长尾延迟飙升很难排查。3.3 调度粒度token 级、序列级还是批次级Token 调度的粒度选择直接影响到显存节省的效果和实现的复杂度。Token 级调度是最细的每个 token 独立决定何时处理。灵活度最高但调度开销也最大因为每个 token 都要进队列、排序、出队列。在小 batch 场景下调度开销可能比计算本身还大。序列级调度是以整个序列为单位一个序列的所有 token 一起调度。开销小但灵活度差因为一个序列内的 token 可能走不同的专家序列级调度没法利用这种差异。批次级调度是折中方案把多个序列的 token 混在一起按专家分组后批量处理。这是 ExpertFlow 实际采用的方式。它既保留了 token 级的灵活性又通过批处理摊薄了调度开销。我实测下来批次级调度在 batch size 大于 4 的时候调度开销可以控制在总延迟的 5% 以内。batch size 小于 2 的时候调度开销占比会上升到 15% 左右这时候就需要考虑简化调度策略或者干脆退回全量驻留。4. 单卡部署的实操配置与参数计算4.1 显存预算怎么算一个可复用的公式在单卡上部署 ExpertFlow第一步是算清楚显存预算。我总结了一个可复用的公式总显存 常驻专家权重 缓存专家权重 KV Cache 激活值 预测器开销 框架开销逐项拆解。常驻专家权重是那些预测为高频的专家数量记为 N_resident每个专家的参数量记为 P_expert精度字节数记为 B则常驻权重占用为 N_resident × P_expert × B。缓存专家权重是那些按需加载的专家数量记为 N_cache它们占用的显存是动态的峰值不超过 N_cache × P_expert × B但实际占用取决于同时加载的数量。KV Cache 的计算和稠密模型一样2 × 层数 × 序列长度 × 隐藏维度 × batch size × 精度字节数。激活值取决于 batch size 和模型结构一般可以用经验值估算大约是权重的 5% 到 10%。预测器开销很小百万参数级别可以忽略。框架开销包括 CUDA 上下文、通信缓冲区等一般预留 1 到 2GB。以一个 8x7B 的 MoE 模型为例INT8 精度P_expert 约 7BB 为 1 字节。如果 N_resident 取 3N_cache 取 2KV Cache 按 4096 序列长度、batch size 4 算大约 4GB。常驻权重 3 × 7GB 21GB缓存权重峰值 2 × 7GB 14GB但实际同时加载通常只有 1 个所以按 7GB 算。加上 KV Cache 4GB、激活值 2GB、框架开销 1.5GB总计约 35.5GB。这个数字超过了 24GB 单卡所以需要进一步压缩要么降低 N_resident 到 2要么用 INT4 精度要么缩短序列长度。提示这个公式里的每一项都要留 10% 到 15% 的余量因为实际运行时的显存占用会有波动尤其是 KV Cache 和激活值。4.2 专家驻留策略哪些专家常驻哪些按需加载专家驻留策略的核心是决定 N_resident 取多少以及哪些专家进入常驻集合。N_resident 的取值是一个权衡。取值越大缓存命中率越高但显存占用越大。取值越小显存越省但缓存未命中的概率越高延迟波动越大。我的经验是N_resident 取专家总数的 30% 到 50% 比较合适。8 专家取 3 到 4 个16 专家取 5 到 8 个。哪些专家进入常驻集合不能只看全局热度还要看路由的稳定性。有些专家虽然总体热度不高但一旦被激活就是连续激活这种专家适合常驻。有些专家热度中等但激活很分散这种专家适合按需加载。判断稳定性可以用路由的方差或者自相关系数方差小、自相关高的专家优先常驻。这个策略不是静态的。在推理过程中常驻集合应该根据实际路由分布动态调整。比如每处理 1000 个 token 重新评估一次把热度下降的专家移出常驻把热度上升的专家加入常驻。调整频率不能太高否则搬运开销会吃掉收益也不能太低否则跟不上路由分布的变化。4.3 加载延迟的隐藏预取和重叠计算ExpertFlow 能不能跑出低延迟关键看加载延迟能不能被隐藏。如果每次专家加载都要等 50ms那推理速度肯定上不去。隐藏延迟有两个手段预取和计算重叠。预取就是根据预测结果在专家真正被需要之前就开始加载。比如预测未来 8 步会用到专家 5那在当前步处理完后立刻发起专家 5 的加载等 8 步之后专家 5 真正被用到时权重已经在显存里了。预取的提前量要大于加载延迟否则预取没意义。计算重叠是利用 GPU 的计算和传输可以并行的特性。在 GPU 计算当前批次的同时用另一个流stream去加载下一批需要的专家权重。这样加载时间和计算时间重叠总延迟取决于两者中较大的那个而不是两者之和。这两个手段配合使用可以把加载延迟隐藏掉 80% 以上。我实测过一个场景不隐藏延迟时每 token 延迟 120ms隐藏后降到 35ms效果非常明显。当然隐藏延迟的前提是预测准确如果预测错了预取的权重用不上反而浪费了带宽。5. 常见问题与排查技巧实录5.1 预测准确率上不去怎么办预测准确率低是 ExpertFlow 部署中最常见的问题。排查思路按优先级排先看窗口长度是否合适。窗口太短统计量不够预测器没有足够信息。可以试着把窗口从 32 加到 64 或 128看准确率有没有提升。如果提升明显说明之前窗口太小。再看预测器是否训练充分。ExpertFlow 的预测器需要在一个校准集上训练如果校准集和实际推理任务的分布差异大预测准确率会下降。解决办法是用实际任务的样本做少量微调或者扩大校准集的覆盖面。还要看路由本身是否稳定。有些 MoE 模型的路由抖动很大相邻 token 的路由分布差异明显这种情况下预测本身就很难。可以检查路由的熵如果熵很高说明路由很分散预测难度大这时候可能需要调整模型本身的路由温度参数。5.2 显存还是不够逐项排查清单即使上了 ExpertFlow显存还是不够的情况我也遇到过。排查按这个清单来排查项可能原因解决办法常驻专家数过多N_resident 设置太大降低 N_resident观察命中率变化缓存专家同时加载过多预取策略太激进限制同时加载的专家数串行化加载KV Cache 过大序列长度或 batch size 太大缩短序列长度或启用 KV Cache 量化激活值峰值过高batch size 太大降低 batch size或启用梯度检查点框架开销超预期CUDA 上下文或缓冲区过大检查框架配置关闭不必要的功能显存碎片频繁加载卸载导致碎片启用显存池或固定专家权重的显存地址这个清单我基本每次部署都会过一遍大部分显存问题都能定位到。5.3 延迟波动大调度队列的调参经验延迟波动大通常和调度队列有关。我遇到过的典型情况是大部分 token 延迟很低但偶尔有几个 token 延迟飙升到几百毫秒。这种长尾延迟的根源往往是调度队列的饥饿或者超时设置不合理。排查时先看超时阈值。如果超时设得太长小批次的 token 会等很久才被处理导致延迟飙升。可以试着把超时从 20ms 降到 10ms看长尾延迟有没有改善。再看优先级机制。如果早到的 token 没有足够高的优先级可能会被后来的大批次 token 插队导致上下文错乱和延迟累积。检查优先级计算是否合理早到 token 的权重是否足够。最后看饥饿避免。如果某个专家的 token 总是排不上队说明饥饿避免机制没生效。检查等待时间加权的系数是否太小或者批次大小阈值是否太高。5.4 精度下降量化与调度的联合影响ExpertFlow 本身不引入量化但它和量化叠加使用时精度下降可能会比预期更明显。原因是调度会改变 token 的处理顺序而量化误差在不同处理顺序下可能有不同的累积效果。我实测过一个案例单独用 INT8 量化精度下降 2%单独用 ExpertFlow精度几乎无损两者叠加精度下降 5%。这个额外的 3% 下降来自调度引入的批次内 token 顺序变化导致量化误差的累积模式改变。解决办法有两个。一是对调度后的批次做误差补偿在专家输出上加一个小的校正项。二是降低调度粒度减少 token 顺序的变化幅度。前者效果更好但实现复杂后者简单但会牺牲一些显存收益。6. 我踩过的坑和几条实用建议6.1 不要一上来就调预测器我刚开始用 ExpertFlow 的时候花了很多时间调预测器的结构和参数结果发现收益不明显。后来才意识到预测器的上限是由路由本身的可预测性决定的。如果路由本身抖动很大再好的预测器也没用。正确的顺序是先分析路由分布看头部专家的稳定性和尾部专家的激活模式。如果头部专家很稳定那预测器随便调调就能到 85% 以上。如果头部专家都不稳定那应该先考虑调整模型的路由温度或者换一个路由更稳定的 MoE 模型。6.2 常驻集合要留缓冲常驻集合的大小不要卡得太死。比如算下来显存刚好能放 3 个专家那就常驻 2 个留 1 个的缓冲。因为实际运行时显存占用会有波动KV Cache 和激活值的峰值可能比估算的高。留缓冲可以避免偶发的 OOM。这个缓冲的比例我一般取 20% 到 30%。也就是说如果显存能放 5 个专家常驻集合取 3 到 4 个。这样既保证了命中率又留了安全边际。6.3 监控比调参更重要ExpertFlow 的调参空间很大但盲目调参效率很低。更好的做法是先把监控做起来看清楚瓶颈在哪里。需要监控的指标包括预测准确率、缓存命中率、专家加载次数、加载延迟、调度队列长度、长尾延迟。这些指标能告诉你系统卡在哪一环。如果预测准确率低就调预测器如果命中率低但预测准确率高就调常驻集合如果加载延迟高就调预取策略如果长尾延迟高就调调度队列。我自己的习惯是每部署一个新模型先跑一轮监控把基线数据记下来然后再针对性调参。这样每次调参都有对比不会越调越乱。6.4 小 batch 场景要谨慎ExpertFlow 在 batch size 较大的时候收益最明显因为批处理能摊薄调度和加载开销。但在 batch size 很小比如 1 或 2的场景下调度开销占比会上升收益可能不如预期。如果实际场景就是小 batch有两个选择。一是放宽调度粒度减少调度频率接受一些显存浪费。二是混合策略高频专家常驻低频专家按需加载但不做复杂的 token 调度直接按到达顺序处理。后者实现简单在小 batch 下反而更稳。6.5 别忘了框架层面的优化ExpertFlow 是算法层面的优化但框架层面的优化同样重要。比如用 CUDA Graph 减少 kernel 启动开销用 PagedAttention 管理 KV Cache用连续批处理continuous batching提高 GPU 利用率。这些优化和 ExpertFlow 是互补的叠加使用效果更好。我见过一些部署案例ExpertFlow 本身跑得不错但因为框架配置没调好整体性能还是上不去。所以部署时要把算法和框架一起考虑不要只盯着 ExpertFlow 本身。7. 这套方案适合谁不适合谁ExpertFlow 不是万能的。它适合的场景是单卡部署、MoE 模型、显存受限、对延迟有一定容忍度不是硬实时、路由分布有一定稳定性。在这些场景下它能带来 30% 到 50% 的显存节省延迟增加控制在可接受范围内。它不太适合的场景是硬实时推理延迟波动不能接受、路由极度不稳定预测准确率上不去、batch size 极小调度开销占比过高、或者显存其实够用没必要引入额外复杂度。我自己的判断标准是如果全量驻留的显存占用超过单卡容量的 1.5 倍那 ExpertFlow 值得一试如果只超过 1.2 倍那可能量化或者缩短序列长度就能解决不一定需要上 ExpertFlow。这个阈值不是绝对的但可以作为一个快速判断的参考。最后分享一个我在实际部署中总结的小技巧先用模拟器跑一遍。ExpertFlow 的很多参数可以在不实际加载模型的情况下模拟出来比如预测准确率、命中率、加载次数。用一个轻量的模拟器先把参数空间扫一遍找到几个候选配置再上真实模型验证。这样能省下大量试错时间尤其是显存紧张、每次加载模型都要好几分钟的场景下模拟器的价值非常明显。