本文由Nuoya Xiong、Yuhang

本文由Nuoya Xiong、Yuhang Zhou、Hanqing Zeng、Zhaorun Chen、Furong Huang、Shuchao Bi、Lizhu Zhang、Zhuokai Zhao等研究者合作完成。论文第一作者Nuoya Xiong为CMU计算机学院二年级博士生，研究方向为大语言模型的后训练与强化学习，本工作完成于其在Meta实习期间。该项目由Meta AI的Zhuokai Zhao和Lizhu Zhang共同领导，合作者还包括来自Meta TBD团队的Shuchao Bi以及University of Maryland的Furong Huang教授。

近年来，大语言模型能力的提升，已不再仅仅依赖于更大的模型规模或更多的训练数据。越来越多的研究开始探索另一条路径： 通过多个专家模型的协作来完成生成任务 。

这一思路背后的直觉并不复杂：现实中往往不存在一个在所有任务上都同样出色的模型，而是会涌现出大量各有所长的“专家模型”。例如，专门针对数学数据训练的模型更擅长复杂推理，代码模型在程序生成和语法结构上表现更稳定，而指令微调模型则更擅长对话理解与交互表达。与其追求一个“无所不能”的统一大模型，不如将多个领域专家进行组合，让它们在各自擅长的子问题上发挥作用。这种方式不仅能够更充分地利用已有模型的能力，也避免了单一模型在所有维度上都需要做到极致所带来的训练成本与优化难度。

针对这一方向，论文提出了 FusionRoute ，一种基于 token-level路由的多LLM协作范式 。不同于以往在整段生成中选择单一模型，FusionRoute训练一个路由模型， 在每一步生成时，使用该路由模型动态判断当前这个token更适合由哪个专家模型来生成。这种更细粒度的路由方式，使模型能够在同一段生成过程中灵活切换不同专家，在推理、代码生成和自然语言表达等不同子任务之间进行动态分工，从而更充分地发挥各个模型的优势。

在此基础上，FusionRoute进一步利用

在此基础上，FusionRoute进一步利用路由器本身的理解能力，引入了一种 补充生成（complementary generation）机制 。除了进行expert选择之外，路由器还会为当前token提供额外的生成信号，并与expert的输出共同作用，形成最终结果。由此，路由器不再只是一个“选择器”，而成为生成过程中的参与者，进一步提升了整体表达能力。

相比sequence-level的协作方式，FusionRoute具有更高的灵活性和更细粒度的控制能力。同时，不同于传统MoE，FusionRoute的专家可以是结构各异、已经训练完成的独立模型，从而在实际部署中更加灵活、也更具工程可行性。

论文标题： Token-Level LLM Collaboration via FusionRoute arXiv地址： https://arxiv.org/pdf/2601.05106 代码地址： https://github.com/xiongny/FusionRoute

以往的sequence-level collaboration 在整段生成完成后再进行模型融合，讨论或选择。多个模型需要生成完整回答，再通过reranking或辩论得到最终结果。这种方式虽然简单，但存在明显问题：一方面计算开销较大（需要多次完整生成），另一方面协作粒度较粗，因此往往比较低效。

相比之下， 以往的token-level c

相比之下， 以往的token-level collaboration 将协作粒度细化到每一步生成，通过在多个模型之间进行token级别的选择来决定下一个token。这种方法能够实现更灵活的专家切换，但其核心仍然是“从多个候选中进行选择”。因此，一旦选择结果不稳定或某一步选择出现偏差，误差会在后续生成中不断累积，导致整体生成过程不够稳定。文章也通过理论推导，证明了在仅有single policy coverage的合理假设下，纯粹基于专家选择的token-level路由存在本质上的"不可识别性"——即便存在一条最优路径，仅凭沿最优轨迹观测到的Q值也无法可靠地识别出哪个专家应被选中，揭示了以往token-level协作的主要瓶颈。

FusionRoute 的关键思路是引入了一个可训练的router模块，提供两个功能：

1、对于decoding过程中的每个token，输出一个路由权重。系统之后会选择权重最高的专家进行这个token的生成。

2、输出router logits，利用router的理解能力对expert的token logits进行补充生成。最终的logits合并专家logits和router logits。这种设计使得最终生成不再仅依赖于单一专家的输出，而是融合了expert能力与全局理解，从而在保持细粒度协作的同时，显著提升了生成的稳定性与鲁棒性。

在训练上，FusionRoute无需对专家进

在训练上，FusionRoute无需对专家进行额外微调，而是固定已有的专家，仅训练一个轻量级的router模块。训练分为两个阶段：

1、首先，在监督微调（SFT）阶段，训练router使其能够在给定上下文下学习如何组合不同专家的输出。具体而言，router自身会生成补充的logits，并通过next-token cross-entropy loss进行优化；同时，router输出的路由权重与多个expert提供的token分布加权得到最终的聚合logits，并通过专家选择损失对路由线性层进行端到端优化。值得注意的是，论文在路由损失中只保留了"信息性token"——即不同专家预测结果存在分歧的位置，避免标点、虚词等所有专家都能正确预测的token主导梯度，从而让路由真正学到的是专家之间的能力差异。经过这一阶段，router已能够学习基本的专家选择与语言能力。

2、第二个阶段是训练router logits的补充生成能力（CDPO）。具体来说，FusionRoute将router logits和专家logits合并起来，然后在偏好数据集上计算token的概率，并基于DPO进行优化。这里的一个关键设计是，专家提供的log-ratio项被作为不传梯度的"偏置项"处理——当专家本身已经能给出强策略时，该偏置项较大，router自身的梯度自然变小；当专家薄弱时，log-ratio gap缩小，router会获得更大的修正信号。这种机制让router在专家失效的位置才发力，自动实现"按需补充"。另一大挑战在于，单独训练router logits的补充生成能力会使得router的参数与输出路由权重的线性层不匹配。由此，FusionRoute设计了一种 混合训练策略 ，将监督微调（SFT）与基于偏好的优化（CDPO）结合在同一训练流程中。

实验1:在多个领域上显著提升了综合能力

论文使用了MergeBench里的数学专家模

论文使用了MergeBench里的数学专家模型，代码生成专家模型和指令跟随专家模型，涵盖Llama-3和Gemma-2两个模型种类。文章在五个基准上评估FusionRoute：数学推理任务GSM8K、MATH-500，代码生成任务HumanEval、MBPP以及指令跟随任务IfEval。基线包含不同的专家Sequence Selection（令所有模型均生成回答，并使用外部reward模型选择最优回答），以往的token-level协作范式Collab，两个Model Merging的方法（DARE, TaskArithmetic)，以及在数据集上直接微调的模型(“Fine-tuned” in Table 1)。实验结果如Table 1所示，FusionRoute取得了稳定的性能提升。更值得关注的是，FusionRoute在专家本身擅长的领域并没有牺牲性能——在GSM8K、HumanEval等任务上，它的表现与对应专家持平甚至略胜，说明这种细粒度协作真正做到了"取长补短"。

实验2:在通用数据集上显著提升整体生成质量

除了数学推理和代码生成等domain-specific任务之外，论文还进一步评估了FusionRoute在通用场景下的整体生成质量。为此，论文在PerfectBlend测试集上随机采样500条prompt，让各方法生成不超过300个token的回答，并使用GPT-4o进行pairwise比较，以Fine-tuned Model的回答作为参照计算win rate。实验结果表明，FusionRoute在通用数据集上依然能够优于微调模型以及其他协作方法，说明其能够融合不同expert的能力，能够在混合场景下生成更加高质量且更自然的回答。

另一个有趣的现象是在不同模型规模之间的对比上。在更大的8B Llama-3家族上，FusionRoute相对基线的优势显著扩大，而其他token-level协作方法（如Collab）和sequence-level选择方法反而出现明显退化；而在2B的Gemma-2家族上，纯专家选择类的方法表现尚可。这说明随着模型容量上升，"纯粹从专家中挑一个"的范式变得越来越脆弱——专家越强，候选之间的细微差别越难仅凭外部reward区分出来；而router提供的补充生成机制能够更充分地利用额外的表达能力，把模型容量真正转化为协作质量。换句话说，FusionRoute的设计哲学在更强的底座上反而更具优势。

FusionRoute的核心贡献可以从几个层

FusionRoute的核心贡献可以从几个层面来看。

在方法层面 ，FusionRoute首次将"专家选择"与"补充生成"统一在同一个轻量级router模块中。以往的多LLM协作要么是sequence-level的粗粒度融合，要么是token-level但纯粹基于选择的方案——前者效率低、粒度粗，后者依赖专家在每一个token上的正确性，鲁棒性不够。FusionRoute让router同时承担"指挥"和"补位"两个角色，既保留了token-level的细粒度优势，又通过补充logits修正专家在不擅长场景下的输出，从根本上提升了协作系统的稳定性。

在理论层面 ，论文给出了一个对该方向具有指导意义的结果——在仅有single policy coverage的合理假设下，纯粹依赖专家选择的token-level协作存在本质上的不可识别性，无法保证恢复出近似最优策略。这一不可能性结果解释了过去token-level方法在实践中表现不稳定的根源，也从理论上论证了router作为补充生成器的必要性——在加入补充logits之后，最终策略的可表达策略类被显著扩张，从而能够在更弱的假设下恢复近似最优。

在工程层面 ，FusionRoute既不要求各专家模型结构同构，也无需对专家进行任何额外的梯度更新，仅需训练一个轻量级router，就可以将一组现成的、结构异质的领域模型组装成一个综合能力更强的系统。这种"即插即用"的设计在实际部署中具有重要意义——当一个新的领域专家出现时，可以快速纳入协作框架，而无需推倒重训整个系统。

最重要的是，这些性能提升并不依赖于对expe

最重要的是，这些性能提升并不依赖于对expert模型的额外微调，而是通过更高效的推理协作机制实现的。这表明FusionRoute能够在保持较低额外成本的前提下，充分挖掘多模型之间的互补能力，从而实现更强的综合表现。沿着这一方向，多个专门化小模型的协作正在成为通用大模型之外一条具有现实价值的技术路径。

Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.

本文由Nuoya Xiong、Yuhang

本文由Nuoya Xiong、Yuhang Zhou、Hanqing Zeng、Zhaorun Chen、Furong Huang、Shuchao Bi、Lizhu Zhang、Zhuokai Zhao等研究者合作完成。论文第一作者Nuoya Xiong为CMU计算机学院二年级博士生，研究方向为大语言模型的后训练与强化学习，本工作完成于其在Meta实习期间。该项目由Meta AI的Zhuokai Zhao和Lizhu Zhang共同领导，合作者还包括来自Meta TBD团队的Shuchao Bi以及University of Maryland的Furong Huang教授。

近年来，大语言模型能力的提升，已不再仅仅依赖于更大的模型规模或更多的训练数据。越来越多的研究开始探索另一条路径： 通过多个专家模型的协作来完成生成任务 。

这一思路背后的直觉并不复杂：现实中往往不存在一个在所有任务上都同样出色的模型，而是会涌现出大量各有所长的“专家模型”。例如，专门针对数学数据训练的模型更擅长复杂推理，代码模型在程序生成和语法结构上表现更稳定，而指令微调模型则更擅长对话理解与交互表达。与其追求一个“无所不能”的统一大模型，不如将多个领域专家进行组合，让它们在各自擅长的子问题上发挥作用。这种方式不仅能够更充分地利用已有模型的能力，也避免了单一模型在所有维度上都需要做到极致所带来的训练成本与优化难度。

针对这一方向，论文提出了 FusionRoute ，一种基于 token-level路由的多LLM协作范式 。不同于以往在整段生成中选择单一模型，FusionRoute训练一个路由模型， 在每一步生成时，使用该路由模型动态判断当前这个token更适合由哪个专家模型来生成。这种更细粒度的路由方式，使模型能够在同一段生成过程中灵活切换不同专家，在推理、代码生成和自然语言表达等不同子任务之间进行动态分工，从而更充分地发挥各个模型的优势。

在此基础上，FusionRoute进一步利用

在此基础上，FusionRoute进一步利用路由器本身的理解能力，引入了一种 补充生成（complementary generation）机制 。除了进行expert选择之外，路由器还会为当前token提供额外的生成信号，并与expert的输出共同作用，形成最终结果。由此，路由器不再只是一个“选择器”，而成为生成过程中的参与者，进一步提升了整体表达能力。

相比sequence-level的协作方式，FusionRoute具有更高的灵活性和更细粒度的控制能力。同时，不同于传统MoE，FusionRoute的专家可以是结构各异、已经训练完成的独立模型，从而在实际部署中更加灵活、也更具工程可行性。

论文标题： Token-Level LLM Collaboration via FusionRoute arXiv地址： https://arxiv.org/pdf/2601.05106 代码地址： https://github.com/xiongny/FusionRoute

以往的sequence-level collaboration 在整段生成完成后再进行模型融合，讨论或选择。多个模型需要生成完整回答，再通过reranking或辩论得到最终结果。这种方式虽然简单，但存在明显问题：一方面计算开销较大（需要多次完整生成），另一方面协作粒度较粗，因此往往比较低效。

相比之下， 以往的token-level c

相比之下， 以往的token-level collaboration 将协作粒度细化到每一步生成，通过在多个模型之间进行token级别的选择来决定下一个token。这种方法能够实现更灵活的专家切换，但其核心仍然是“从多个候选中进行选择”。因此，一旦选择结果不稳定或某一步选择出现偏差，误差会在后续生成中不断累积，导致整体生成过程不够稳定。文章也通过理论推导，证明了在仅有single policy coverage的合理假设下，纯粹基于专家选择的token-level路由存在本质上的"不可识别性"——即便存在一条最优路径，仅凭沿最优轨迹观测到的Q值也无法可靠地识别出哪个专家应被选中，揭示了以往token-level协作的主要瓶颈。

FusionRoute 的关键思路是引入了一个可训练的router模块，提供两个功能：

1、对于decoding过程中的每个token，输出一个路由权重。系统之后会选择权重最高的专家进行这个token的生成。

2、输出router logits，利用router的理解能力对expert的token logits进行补充生成。最终的logits合并专家logits和router logits。这种设计使得最终生成不再仅依赖于单一专家的输出，而是融合了expert能力与全局理解，从而在保持细粒度协作的同时，显著提升了生成的稳定性与鲁棒性。

在训练上，FusionRoute无需对专家进

在训练上，FusionRoute无需对专家进行额外微调，而是固定已有的专家，仅训练一个轻量级的router模块。训练分为两个阶段：

1、首先，在监督微调（SFT）阶段，训练router使其能够在给定上下文下学习如何组合不同专家的输出。具体而言，router自身会生成补充的logits，并通过next-token cross-entropy loss进行优化；同时，router输出的路由权重与多个expert提供的token分布加权得到最终的聚合logits，并通过专家选择损失对路由线性层进行端到端优化。值得注意的是，论文在路由损失中只保留了"信息性token"——即不同专家预测结果存在分歧的位置，避免标点、虚词等所有专家都能正确预测的token主导梯度，从而让路由真正学到的是专家之间的能力差异。经过这一阶段，router已能够学习基本的专家选择与语言能力。

2、第二个阶段是训练router logits的补充生成能力（CDPO）。具体来说，FusionRoute将router logits和专家logits合并起来，然后在偏好数据集上计算token的概率，并基于DPO进行优化。这里的一个关键设计是，专家提供的log-ratio项被作为不传梯度的"偏置项"处理——当专家本身已经能给出强策略时，该偏置项较大，router自身的梯度自然变小；当专家薄弱时，log-ratio gap缩小，router会获得更大的修正信号。这种机制让router在专家失效的位置才发力，自动实现"按需补充"。另一大挑战在于，单独训练router logits的补充生成能力会使得router的参数与输出路由权重的线性层不匹配。由此，FusionRoute设计了一种 混合训练策略 ，将监督微调（SFT）与基于偏好的优化（CDPO）结合在同一训练流程中。

实验1:在多个领域上显著提升了综合能力

论文使用了MergeBench里的数学专家模

论文使用了MergeBench里的数学专家模型，代码生成专家模型和指令跟随专家模型，涵盖Llama-3和Gemma-2两个模型种类。文章在五个基准上评估FusionRoute：数学推理任务GSM8K、MATH-500，代码生成任务HumanEval、MBPP以及指令跟随任务IfEval。基线包含不同的专家Sequence Selection（令所有模型均生成回答，并使用外部reward模型选择最优回答），以往的token-level协作范式Collab，两个Model Merging的方法（DARE, TaskArithmetic)，以及在数据集上直接微调的模型(“Fine-tuned” in Table 1)。实验结果如Table 1所示，FusionRoute取得了稳定的性能提升。更值得关注的是，FusionRoute在专家本身擅长的领域并没有牺牲性能——在GSM8K、HumanEval等任务上，它的表现与对应专家持平甚至略胜，说明这种细粒度协作真正做到了"取长补短"。

实验2:在通用数据集上显著提升整体生成质量

除了数学推理和代码生成等domain-specific任务之外，论文还进一步评估了FusionRoute在通用场景下的整体生成质量。为此，论文在PerfectBlend测试集上随机采样500条prompt，让各方法生成不超过300个token的回答，并使用GPT-4o进行pairwise比较，以Fine-tuned Model的回答作为参照计算win rate。实验结果表明，FusionRoute在通用数据集上依然能够优于微调模型以及其他协作方法，说明其能够融合不同expert的能力，能够在混合场景下生成更加高质量且更自然的回答。

另一个有趣的现象是在不同模型规模之间的对比上。在更大的8B Llama-3家族上，FusionRoute相对基线的优势显著扩大，而其他token-level协作方法（如Collab）和sequence-level选择方法反而出现明显退化；而在2B的Gemma-2家族上，纯专家选择类的方法表现尚可。这说明随着模型容量上升，"纯粹从专家中挑一个"的范式变得越来越脆弱——专家越强，候选之间的细微差别越难仅凭外部reward区分出来；而router提供的补充生成机制能够更充分地利用额外的表达能力，把模型容量真正转化为协作质量。换句话说，FusionRoute的设计哲学在更强的底座上反而更具优势。

FusionRoute的核心贡献可以从几个层

FusionRoute的核心贡献可以从几个层面来看。

在方法层面 ，FusionRoute首次将"专家选择"与"补充生成"统一在同一个轻量级router模块中。以往的多LLM协作要么是sequence-level的粗粒度融合，要么是token-level但纯粹基于选择的方案——前者效率低、粒度粗，后者依赖专家在每一个token上的正确性，鲁棒性不够。FusionRoute让router同时承担"指挥"和"补位"两个角色，既保留了token-level的细粒度优势，又通过补充logits修正专家在不擅长场景下的输出，从根本上提升了协作系统的稳定性。

在理论层面 ，论文给出了一个对该方向具有指导意义的结果——在仅有single policy coverage的合理假设下，纯粹依赖专家选择的token-level协作存在本质上的不可识别性，无法保证恢复出近似最优策略。这一不可能性结果解释了过去token-level方法在实践中表现不稳定的根源，也从理论上论证了router作为补充生成器的必要性——在加入补充logits之后，最终策略的可表达策略类被显著扩张，从而能够在更弱的假设下恢复近似最优。

在工程层面 ，FusionRoute既不要求各专家模型结构同构，也无需对专家进行任何额外的梯度更新，仅需训练一个轻量级router，就可以将一组现成的、结构异质的领域模型组装成一个综合能力更强的系统。这种"即插即用"的设计在实际部署中具有重要意义——当一个新的领域专家出现时，可以快速纳入协作框架，而无需推倒重训整个系统。

最重要的是，这些性能提升并不依赖于对expe

最重要的是，这些性能提升并不依赖于对expert模型的额外微调，而是通过更高效的推理协作机制实现的。这表明FusionRoute能够在保持较低额外成本的前提下，充分挖掘多模型之间的互补能力，从而实现更强的综合表现。沿着这一方向，多个专门化小模型的协作正在成为通用大模型之外一条具有现实价值的技术路径。

Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.