把上千个 LoRA 在推理时合并成局部 MoE,开销约 20 个 token,比 TTT 快 125 倍

Local Mixtures of Experts: Essentially Free Test-Time Training via Model Merging

Ryo Bertolissi, Jonas Hübotter, Ido Hakimi, Andreas Krause

cs.LG, cs.AI

2025-05-20

新方法 TTMM 先把数据聚成局部邻域、每块训一个 LoRA,推理时按当前输入动态合并参数,一次前向拿到定制模型,开销仅约 20 个 token。

这篇在解决什么

混合专家(MoE)靠每次只激活少数专家来扩容而不增加推理算力,是当今大模型的主流架构。但它有两个老问题:专家数量受训练和推理成本限制,通常只有少数几个;而传统的测试时训练(test-time training,TTT)要为每个任务或每条提示单独微调一遍,慢且贵。

这篇想用一个近乎免费的法子拿到「成百上千个专家」的好处:把大量 LoRA 适配器在推理时按需合并,而不必让它们全部驻留显存轮流激活。

方法

方法叫 TTMM(test-time model merging,测试时模型合并)。

训练阶段:先用二分 k-means 把训练数据聚成一个个局部邻域,每个邻域训一个独立的 LoRA 适配器,再用聚类质心(平均 embedding)代表这个专家。K 个邻域就得到 K 个 LoRA 专家。

推理阶段:对每条新提示,先算它和每个质心的相似度,用带稀疏化的交叉注意力算出一组合并系数(sparse-softmax),只挑出少数最相关的专家,然后把它们的参数加权合并成一套参数,拼成一个专门为这条提示定制的单一模型。整个过程在参数空间里完成,只需要一次前向。

「近乎免费」的关键就在这里:它不像 TTT 或集成那样要多跑前向,合并发生在参数空间,额外开销大约只相当于多生成 20 个 token。

结果

以 Llama-3.2-1B 为底座、K=100 个专家:

指标底座TTMMTTT(对照)
Wikipedia 困惑度8.6747.5107.559
GitHub Python 困惑度2.6112.4922.441

困惑度越低越好。在 10 个活跃专家时,TTMM 的困惑度已经追平甚至略好于 TTT,而速度上 TTMM 的常数开销约 115 毫秒,比 TTT 快 125 倍以上。在 MMLU 上,微调基线 48.10%,TTMM(15 个专家)做到 48.96%。

还有一个细节:TTT 在 Python 上困惑度(2.441)略低于 TTMM(2.492),说明真正逐提示微调仍有边缘优势,但代价是 125 倍的延迟。

为什么重要

对做模型服务又想榨容量的人,这条路把「专家数」从显存约束里解放出来:可以训上千个 LoRA,却只在每条请求上合并少数几个,推理算力几乎不涨。它把测试时适配从「贵到用不起」拉到「便宜到可以默认开」。

要清醒的是,合并发生在参数空间,前提是这些 LoRA 大致在同一片参数地形里可加;不同任务训出的适配器如果互相干扰,合并质量会掉。

局限与存疑

作者自己点出两点:一是要把所有专家存在 CPU 内存里,K 一大内存吃紧;二是同时合并太多活跃专家会带来模型干扰。两者本质上是一个张力的两面,专家越多越能定制,也越容易互相打架。

读下来还有一个没充分回答的问题:聚类用二分 k-means 是个静态划分,而真实任务的分布未必干净可分,处于簇边界的提示该归哪个专家,合并系数能不能可靠地表达这种模糊,论文没有给压力测试。

术语

原文与代码

社区讨论

相关论文

全部论文解读