MoE(混合专家)模型的卖点一直是"参数很大、每个 token 只算一小部分":路由器为每个 token 挑选少量专家参与计算,总容量上去了,单 token 计算量却没有同比例膨胀。但部署侧有个不太被大众讨论的尴尬——计算稀疏不等于显存友好。当专家总数超过单卡显存能装下的量,没被选中的专家只能躺在 CPU 内存或更慢的存储层,解码时被路由器点到的专家要临时搬回 GPU,权重搬运本身成了新瓶颈。
华为联合北京航空航天大学等机构的研究团队,9 月 4 日提交到 arXiv 的论文(https://arxiv.org/abs/2609.04895)选了一个不常见的攻击位置:与其在 serving 系统层用启发式规则猜"哪些专家接下来会被用到",不如把缓存管理本身做成模型侧的后训练目标。
两个辅助路由器,不碰原生 Top-K
方法分两层。Temporal Router(时间路由器)在每层专家计算完成后,预测同层专家在后续 token 上的复用概率,决定哪些专家留在 GPU 缓存里——它只管"留谁",不做主动预取,因此不产生任何前瞻传输。Spatio Router(空间路由器)则利用因果 Transformer 的执行顺序:目标层被访问之前,其"因果前驱层"的隐状态已经算好,可以用这个信号提前修正缓存内容。
关键约束是:原生 MoE 路由器的 Top-K 专家选择规则在推理时完全保留,辅助路由器只管理"谁驻留显存",不改变"谁执行计算"。训练时用软化的 Top-B 隶属度代理构造缓存覆盖损失,与语言建模损失联合优化,让骨干网络和辅助路由器一起适配出缓存更友好的路由分布。
实测:命中率与流量
团队在 Qwen3 和 GPT-OSS 两个 MoE 骨干上,用 GSM8K、MATH、CommonsenseQA 三个推理基准评测(结果为五个种子的均值)。只做驻留更新的 Temporal Router 对比最强的经典替换策略(LRU/LFU/LRFU 一类),命中率在三个任务上分别提升 10.46、10.70、33.34 个百分点,每 token 解码流量从 1353/1294/1512 MB 降到 974/906/304 MB。加上空间路由的完整版,对比预取类基线中最强的 ProMoE,负载调整后命中率提升 1.15–18.03 个百分点,流量降低 4.6–53.3%。
代价相当克制:完整版在 Qwen3 上新增 25.2M 推理参数,只占模型规模的 0.083%(GPT-OSS 上为 4.4M、0.021%),而 ProMoE 需要新增 96.0M。GPT-OSS 上的结果被论文如实描述为"有竞争力但依赖任务"。
不是免费的午餐
消融部分披露了几个真实代价。缓存损失权重 sw 调大,流量进一步下降,但精度开始掉:sw=0.1 时 Temporal Router 保持基线精度(GSM8K 85.44 不变),sw=2.0 时精度下降 10.84 个点。专家使用也向头部集中——熵从 3.96 降到 3.51,等效专家数从 53.41 缩到 34.54,专家并行的负载均衡可能受影响。作者还明确说明:Load 指标度量的是模拟的解码阶段流量,不等于端到端延迟;方法需要对全模型做后训练,不是即插即用的 serving 补丁。
所以呢
这篇论文的核心动作,是把 MoE 专家缓存从"系统层启发式"(MoE-Infinity、ProMoE、FineMoE 均属此类)拉进"模型侧后训练"的范畴。对显存受限的部署场景——比如 llama.cpp 这类想把大 MoE 塞进消费级设备的生态——这是值得跟踪的方向:缓存策略第一次成为可训练的优化目标,而不是靠 LRU 通用规则硬猜。代价也很清楚:全模型后训练加专家集中化副作用,离"拿来就用"还有距离。你愿意为省下一半权重流量,给模型做一次缓存感知的再训练吗?