企业官网建设流程全解析

1. 为什么 MoE 推理总在显存上翻车

1.1 从一次 OOM 说起：MoE 的显存账本到底怎么算

我第一次在单张 24GB 卡上跑一个 8x7B 的 MoE 模型时，脑子里想的很简单：8 个专家，每个 7B，激活两个，那显存占用应该跟一个 13B 稠密模型差不多吧？结果加载到一半直接 OOM，连权重都没放完。后来把账本摊开算了一遍才明白，MoE 的显存占用和稠密模型完全是两套逻辑。

稠密模型的显存占用大致是：参数量 × 精度字节数 + 激活值 + KV Cache。一个 13B 的模型用 FP16 加载，权重就是 26GB 左右，量化到 INT8 是 13GB，INT4 是 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 约 7B，B 为 1 字节。如果 N_resident 取 3，N_cache 取 2，KV 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，显存还是不够的情况我也遇到过。排查按这个清单来：

这个清单我基本每次部署都会过一遍，大部分显存问题都能定位到。

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 的很多参数可以在不实际加载模型的情况下模拟出来，比如预测准确率、命中率、加载次数。用一个轻量的模拟器先把参数空间扫一遍，找到几个候选配置，再上真实模型验证。这样能省下大量试错时间，尤其是显存紧张、每次加载模型都要好几分钟的场景下，模拟器的价值非常明显。