★ FEATURED ARTICLE 大概半个月前我接到一个看起来挺常规的任务把几个在不同垂直领域微调过的大语言模型合并回一个统一模型要求是各领域能力尽量不退化。听起来像是把几杯果汁倒进一个杯子结果倒完之后我盯着评测曲线看了整整一个下午——生物医学问答掉了11个点金融实体抽取掉了8个点而代码生成居然还涨了2个点。这种“有人欢喜有人忧”的结果让我开始认真研究MergeBench也就是这篇博文的主题一个专门用来衡量“合并领域特化大语言模型”Domain-Specialized LLM Merging效果的基准测试。MergeBench解决的核心问题很简单也很现实当你有多个针对特定领域微调好的模型如何把它们合到一起同时保留各自的专业能力以及这个合并过程是否真的可靠、可复现、可比较。这篇文章我会从为什么模型合并成为一个刚需开始讲然后拆解MergeBench到底在测哪些维度再把我自己跑合并且用类似思路做评测的过程、踩过的坑、以及从结果里反推出来的经验全部写出来。适合谁看一是正在做模型合并的算法工程师二是想评估不同合并方案但不知道从哪下手的同学三是对领域特化模型碎片化问题感兴趣的人。1. 领域特化模型越堆越多合并到底解决了什么问题1.1 模型碎片化的真实场景先还原一个典型的业务场景。某团队有一个开源底座模型之后围绕四条业务线各微调了一份专属模型金融方向的Fin-Lex负责研报情感分析和实体抽取生物医学方向的Bio-Read负责文献问答和术语解释代码方向的Code-Forge负责补全与单测生成客服方向的Agent-Intent负责多轮意图识别。每份模型都是在一个通用底座上继续训练得到的效果也确实好单领域评测都碾压底座。但麻烦也跟着来了。一份模型对应一份服务四个模型就是四条推理链路每个都需要独立的显存、独立的部署脚本、独立的更新流程。更麻烦的是线上流量不是按领域平分的——某天金融查询特别多另外三个模型的算力都在空转。这种“模型碎片化”带来的资源浪费和运维复杂度很多做垂直模型落地的团队都深有体会。1.2 合并凭什么和继续训练、蒸馏、MoE放在一起比面对碎片化常规思路无非四条。第一把四个领域的训练数据拼起来继续训练一个统一模型但这要求数据还能被合规访问且训练成本高第二做知识蒸馏用四个专家模型分别蒸馏给一个学生模型同样需要访问数据和额外训练第三做成MoE架构保留四个专家加路由但推理时的显存开销和复杂度并没有真正降下来第四就是参数合并直接把四个微调后的模型“在参数空间里”融合成一个不需要原始数据集也不需要重新训练。MergeBench真正关注的就是第四条路。参数合并之所以诱人是因为它有几个硬优势数据不落地保护隐私合并过程比训练便宜几个数量级模型结构不变部署链路不用动。但同时它也有一个致命的不确定性——合并后的效果非常依赖方法、超参数和模型之间的“兼容性”。MergeBench的价值就是把这团不确定的东西变成一套可以横向对比的量化指标让你在做选择之前先看到证据。2. MergeBench的评测蓝图到底在测哪些能力2.1 领域模型池与任务集合怎么搭MergeBench的第一步是定义“合并测试环境”。它选择了一个清晰的范式先固定一个底座模型在若干领域上用可控的数据微调出一组专家模型构成领域模型池。领域数量通常为4到6个太少体现不出冲突太多又会让评测成本爆炸。每个专家模型都是严格基于同一底座使用固定比例的领域数据训练确保它们之间的差异只来自“领域数据”而不是训练设置。任务集合的构建也有讲究。它不会只拿一个大而全的通用benchmark来测因为那测不出“领域特化”的价值。更合理的做法是为每个专家模型配备两个层面的评测集一个是该领域的核心能力测试比如金融模型的实体边界识别和情感极性判断另一个是跨领域干扰测试比如金融模型在做完合并后会不会在通用常识上崩掉。这套组合拳的目标是既测“合并后你还行不行”也测“合并后你变没变傻”。2.2 三个评测维度能力保持、冲突消解、分布外泛化MergeBench把合并质量拆成了三个可量化维度。第一个维度叫能力保持率计算方式是合并模型在专家领域测试集上的得分除以原始专家模型在同一测试集上的得分。保持率接近1说明这个合并方法几乎没有破坏领域能力低于0.85基本可以判定合并失败。第二个维度是冲突消解率。多个领域模型合并时参数更新方向经常互相打架甲领域要往东调某个权重乙领域要往西调。MergeBench会统计这类参数冲突的强度并观察合并算法到底能消解多少冲突。你可以把它理解成“合群程度”两个能力都强但个性都拧的模型合起来往往谁都不服谁。第三个维度是分布外泛化。这一点不是直接测合并模型的平均分而是看它在训练时没见过的邻近任务、换个提示模板、或者轻微变形的输入下能不能依然保持稳定输出。合并如果只是简单地把权重平均很容易在分布内表现尚可、分布外迅速退化。MergeBench特意加这个维度是为了防止某些方法“背答案”。2.3 控制变量与防泄漏设计做基准测试最容易死在数据泄漏上MergeBench在设计时对这个问题的处理值得借鉴。它要求领域专家模型在微调时使用的训练数据、合并后调超参数用的验证数据、最终打分的测试数据三者严格隔离。如果测试集里的某一题曾经出现在某领域模型的训练语料里那这个得分就是虚高的。另一个被很多自建评测忽略的点是提示模板的均衡。不同领域任务原本就有不同的提示风格代码补全用纯文本金融抽取用带标签格式问答用生成式。如果任其自然合并模型可能只是学会了“适配某个领域的数据格式”而不是真正学到了领域知识。MergeBench会为每个任务固定一套统一的、与领域无关的评测模板再额外保留一组异质的提示变体专门用来衡量格式敏感性。这个细节直接决定了基准结果的代表性。3. 从任务向量到稀疏编辑合并方法在MergeBench下的表现规律3.1 权重平均为什么在多数场景下表现平庸所有合并方法都有一个共同的起点简单权重平均也就是把所有专家模型的参数逐元素取均值。这个基线实现起来只有几行代码但效果往往很平庸。原因在于神经网络参数空间中存在排列对称性——两个结构相同但训练路径不同的模型可能功能上等价参数摆放位置却完全不同。直接把参数逐位相加相当于把两本内容相同但排版不同的书硬叠在一起字是叠上了行却对不齐。权重平均还有一个隐藏问题各专家的“音量大”程度不一致。某个在大量数据上训练过的金融模型其参数相对底座的偏移量可能远大于某个数据量少的客服模型。等权平均之后嗓门最大的专家会主导最终模型其余领域的能力被稀释。MergeBench的评测里经常能看到这个现象——一份看起来平均分尚可的报告细看每个领域分数方差极大。3.2 任务向量家族TIES与DARE在干什么权重平均不够好于是研究者把目光转向“任务向量”。所谓任务向量就是专家模型参数减去底座模型参数得到的差值捕捉的是微调带来的“定向变化”。合并过程就变成底座参数加上所有任务向量的加权和。这等于把“合并模型”从“直接调和参数”转化成“叠加更新方向”逻辑更清晰也能分离出每个领域到底改了哪些参数。TIES-Merging在此基础上做了三件事裁剪、符号表决、归一化合并。第一步把每个任务向量中幅度最小的部分剪掉保留有实质贡献的参数第二步对每个参数位置看保留的任务向量里正负更新方向哪个占多数让次要方向服从主要方向第三步只把符号一致的任务向量做加权平均。这套流程后来被很多工作验证是稳的它的核心思想是冲突不是用来强解的而是先让少数派让步。DARE的思路则更激进。它发现微调后的任务向量里绝大多数参数都是冗余的于是随机丢掉不少比例的更新量再把剩下的部分按比例放大最终合并。从MergeBench报告看DARE在任务向量本身比较稀疏时效果很好但如果两个专家模型的更新都密集且冲突严重随机丢弃会让关键参数也被误伤。所以它更适合“微调幅度小、更新集中”的场景全参微调的专家模型直接套DARE效果往往会掉。3.3 我观察到的共性规律把MergeBench公布的方法横向看完能抽出几个不太好听但很真实的规律。第一没有普世最优解。每个合并方法都有自己适合的“冲突光谱”。轻量微调的模型之间DARE和简单任务向量加权就很够用全参微调且领域差异大的模型TIES这类带冲突消解的会明显更稳。第二平均分是最会骗人的指标。有的方法平均分很高但因为直接把某个专家能力给牺牲掉了放到实际业务里根本不可用。MergeBench的价值恰恰在于把这种“偏科”暴露出来而不是用高均分掩盖。第三合并基线之间的差距远小于“合并方法选错”的差距。也就是说只要先选对方向——是用任务向量还是稀疏编辑——比事后调参重要得多。4. 实操搭建一套可复现的MergeBench式评测流程4.1 最小可行的实验配置清单读基准是一回事自己搭一套能跑的评测流程是另一回事。我基于类似思路搭过一版简化版MergeBench下面给出最小可行配置可以直接复用。模型池建议4个专家模型加1个底座全部用同一种微调方式LoRA或全参二选一不要混用。混用会导致任务向量幅度不可比。领域的选取尽量拉开差异我这边选了金融、生物医学、代码、客服四类结构差异越大越容易暴露方法的缺陷。每个专家模型的评测集按7比2比1切分7成做微调训练2成做合并参数选择1成做最终测试。评测指标统一用准确率和生成式F1不混用不同体系的分数。合并时固定一套流程加载底座模型逐个加载专家模型的LoRA权重把它们合并进主权重并保存对全参微调模型则直接计算任务向量。基线至少跑三个——朴素权重平均、任务向量加权、TIES——再加一个你真正想验证的新方法一共四个。每种方法在验证集上选择一个最优合并系数例如在0.1到0.9之间以0.1步长搜一次。最后在测试集上跑三次随机采样报告均值加减标准差。4.2 合并后评测最容易踩的三个坑每个坑我都亲自踩过写出来供绕行。第一个坑是分词器不一致。很多微调代码为了适配领域会扩展词表或调整特殊tokens。合并之前如果不做对齐模型参数的embedding矩阵尺寸都对不上直接报错还算是客气的更惨的是不报错、静默产生乱码输出。处理办法是合并前统一强制使用底座的tokenizer配置任何领域新增的token都要映射回原有词表实在映射不了就把对应embedding行置零并在后续微调中冻结。第二个坑是RMSNorm或LayerNorm的数值尺度敏感。现代底座模型很多用RMSNorm这类归一化层的缩放参数对平均操作非常敏感。两个专家的Norm权重差一点直接平均后整个隐藏状态的尺度都会漂移。我的做法是把归一化层单独隔离出来不参与任务向量计算保留底座的原始值如果非合不可也至少要做逐层归一化后再加权。第三个坑是评测时的解码参数不一致。合并模型和专家模型在生成式任务上的输出分布差异会被temperature和top-p的细微差别放大。你可以想象两个模型同一题给出差不多的候选答案一个采样模式选到A另一个选到B最终分数差很多但这不是合并的锅。控制变量之后我才发现有些合并方法看起来崩了其实是解码配置不合适。4.3 结果解读别只看平均分从评测结果里找规律比跑出数字本身难得多。我的习惯是每次结果出来先看三个东西。第一是看最差领域分。合并模型的最低单项能力往往决定了业务上能不能上线。平均分再高金融实体抽取掉到不可用水平这个合并就是失败的。第二是看方差。同一合并方法跑三次如果标准差超过两个点说明它对初始化或采样顺序敏感这种不稳定本身就是风险。第三是看验证集和测试集分数差。验证集用的合并系数在测试集上如果性能出现断崖式下跌说明合并已经过拟合到了验证分布这时候要回头检查是不是优化过度。我曾经认为某个新合并方法效果惊艳平均分比TIES高了将近3个点。结果按最差领域一看客服意图识别直接崩了13个点。原因是这个方法天然会把“少数服从多数”做到极致弱领域在更新方向上完全被其他三个领域淹没。这个教训被记进团队文档里之后后来所有合并方案报告都强制附最差领域分析。5. 从评测结果反推训练侧的改进思路5.1 微调方式对合并成功率的影响MergeBench这类基准带来的一个反直觉结论是合并效果好不好不只是合并方法决定的从微调那一刻就已经决定了。全参微调得到的专家模型参数更新分散在整个权重矩阵里且不同专家的更新方向高度独立合并时冲突概率大。LoRA微调则天然把更新限制在低秩子空间各家专家的任务向量“方向”更容易对齐。在MergeBench式的控制变量实验里LoRA微调的专家模型在合并后的平均保持率通常能比全参微调高出几个点。这个差距在稀疏合并方法下尤其明显因为只有低秩的更新量才容易被裁剪并保留主干。但这不意味着LoRA一定更好。LoRA的秩和alpha选择会影响任务向量的幅度。我用同一个领域数据微调了两次一次秩16、一次秩64合并后后者在领域保持率上明显占优因为可学习的参数多表达能力更接近全参微调同时仍保持了低秩带来的方向一致性。5.2 合并系数超参数比你想象的更敏感合并系数是实验里最被人忽视、又最容易翻车的旋钮。任务向量加权公式里的那个lambda其取值直接决定“专家模型经验”和“底座通用能力”之间的天平往哪边倒。lambda偏小合并模型趋于底座数据量少的领域能力会消失lambda偏大合并模型趋于专家叠加可能变得过拟合且通用能力下降。我的经验是不同的领域适合的lambda区间可能完全不同。金融专家数据量大、更新稳定可以承受更大的lambda客服专家数据量小稍微加一点就过拟合。如果所有领域共用一个系数那最后一定有人吃亏。别人在评测时也会观察到最优lambda通常落在0.3到0.6之间但在这个区间内每变化0.1某些领域的分数就能波动3到5个点。所以每次合并实验验证集上的系数搜索网格必须记录下来否则结果无法复现。5.3 向多语言与多模态扩展时要注意什么MergeBench的思路有很强的扩展性但在非纯文本场景下需要额外增加注意事项。多语言场景最核心的问题是词表覆盖不均匀。某些语言在底座词表里本来token就少微调后新增的token会造成embedding矩阵扩张不同语言专家模型合并时矩阵尺寸不一致的概率极高。这要求基准对“允许扩展词表”的动作单独设一个维度否则结果会被对齐操作本身干扰。多模态场景的问题则在模块边界。语言模型那头合并好了视觉编码器那头还各自为政这算合并成功还是失败一套可信的评测要明确划定合并范围是只合语言层还是语言层加视觉塔一起合。我个人倾向于先合语言层并冻结视觉编码器实验结果会稳定很多。你可以在模型池里同时放两个不同视觉塔的变体这样评测还能看出“模块间兼容性”对合并质量的影响这比单纯看总分会更有参考价值。6. 最后聊几句心得体会我最近这次合并实验最终选定的是基于TIES的变体并配合逐领域独立的合并系数最终把生物医学问答的掉点从11个点收窄到3个点以内金融实体抽取保持率恢复到0.94。这个过程谈不上惊艳但它让我对MergeBench这类基准产生了很大的信任感。它教会我的最重要的一件事是模型合并不是炼丹它更像拼乐高先看零件之间的咬合方式再想怎么用力比你用再多蛮力都重要。最后可以分享一个很小的技巧在正式评测之前花十分钟做一次“冲量测试”——把两个差异最大的专家模型合并然后跑十几个典型样例人工看一眼输出的logit分布是不是正常。这个粗糙的冒烟测试能在正式跑评测前帮你筛掉九成以上的配置错误。模型合并本身不复杂但它的可复现性、可控性比大多数人想象的要更讲究有了MergeBench这样能横向比较的尺子这个方向才算真正进入可以工程化的阶段。
阅读完成 · 觉得有帮助？
