模型合并这个话题我在社区里被问到过很多次。大家看到各家厂商的大模型各有绝活比如有的擅长写代码有的中文语料扎实有的推理能力强脑子里很自然会冒出一个想法能不能把几个模型“捏”在一起做一个全面更强的超级模型这个想法听起来很美好但真要动手做里面全是门道。今天我就把模型合并这件事拆开讲清楚它到底在合并什么技术上能不能实现合并之后是不是真的更强以及如果你自己想上手试一把应该怎么做。1. 合并的动机为什么有人想把大模型“揉”在一起1.1 单模型的天花板与长板短板先聊一个最朴素的问题为什么会有“合并模型”这种念头。用过几个不同大模型的人应该都有体会模型之间的能力差异非常明显。同一个问题A模型可能回答得又准又全B模型却开始胡编乱造反过来换一道题情况可能完全倒过来。这不是偶然而是模型训练数据和训练方式决定的。各家厂商的模型底子不同、训练语料不同、对齐方式不同最后长出来的“性格”也就不一样。我在本地同时部署过国内外好几款主流模型同一个提示词丢进去输出风格和准确率的差距肉眼可见。比如让它们分别做一道逻辑推理题国内某款模型的答案很简洁直接给结论另一款开源模型的推理过程更完整但偶尔会绕远路。这种差异恰好就是合并思路的起点——如果能把模型甲的推理能力嫁接到模型乙的语言风格上是不是就能得到一个更全面的模型这个想法在开源社区尤其流行因为开源模型之间没有商业壁垒权重文件都是公开的可以随意操作。像Llama、Mistral、Qwen、DeepSeek这些模型它们在Hugging Face上都有开放权重这给模型合并提供了最基础的原料。1.2 模型合并的真实目标不是“缝合怪”是取长补短很多人对模型合并有个误解以为合并就是把几个模型拼在一起像拼积木一样。实际上模型合并的目标不是简单的“112”而是在保持模型原有能力不崩溃的前提下把不同模型的优势整合进同一个权重空间。要理解这件事需要先明白一个概念大模型的“能力”不是某一个神经元单独决定的而是大量参数协作的结果。当你用模型A回答一个法律问题时起作用的是A中那些经过海量法律文本训练出来的参数模式当你用模型B写一首诗时起作用的是B中被诗歌语料强化的参数模式。合并模型本质上就是尝试把A的法律参数模式和B的诗歌参数模式放进同一个模型身体里让这个新模型同时具备这两种能力。但问题来了A和B的参数空间分布完全不同训练时的损失函数也不同怎么把它们硬焊在一起这就要说到模型合并真正依赖的几个技术方向。目前开源社区用得比较多的方案大致分成三类权重插值合并把两个模型的对应层权重做加权平均方法简单、计算量小但要求模型架构完全一致。基于表征对齐的合并先找到两个模型内部表征空间的对应关系再把一方的参数变换到另一方的空间里去这种方法可以跨架构操作但实现难度大。模型集成与路由严格说不算“合并”而是让多个模型同时推理再通过一个路由规则挑最优的输出。这种方法最稳但推理成本成倍增加。下面我逐个拆开细说。2. 合并的技术原理它到底在“合”什么东西2.1 权重插值合并最直观也最主流的路径如果两个模型的网络结构完全相同比如都是7B参数的Qwen2.5和Llama-3.1虽然后者通常不同但需要架构、层数、头数完全一致那么它们的权重矩阵形状是完全一样的。这时候最简单的合并方式就是逐层加权平均。公式大概长这样W_merged alpha * W_A (1 - alpha) * W_B其中alpha是合并比例一般取0.5表示两个模型各贡献一半权重。这个公式是模型合并里最基础、最常用的操作社区里常说的“模型插值”Model Interpolation就是这东西。听着是不是太简单了好像就是把两个模型的参数做一个加权平均这事真有用吗我最初也怀疑过这一点。后来我试着把两个不同厂商训练出来的同架构模型做权重平均结果发现一个很有意思的现象合并后的模型在两个模型的擅长任务上都有不错的表现有些场景甚至优于任何一个原模型。这其实可以从“损失景观”的角度解释神经网络训练时是在寻找一个低损失区域两个模型如果都是从这个区域里采样出来的它们的参数差通常不会太大取个平均值往往也能落在一个低损失位置上。但这个操作有个很致命的前提——两个模型必须架构一致。这就引申出一个大问题各家厂商的模型架构本身就不一样。2.2 跨架构合并模型结构不同的情况下能合吗现在市面上主流的开源模型架构上其实有很多不同。有的用的是标准Transformer解码器有的加了Grouped Query Attention有的采用了混合专家MoE结构有的在归一化方式上有差异化设计。把这些结构不同的模型强行合并根本不是“算加权平均”的事了。你要面对的是层数不一样怎么办注意力头数不一样怎么办嵌入维度不一样怎么办激活函数不一样怎么办社区里目前比较靠谱的跨架构方案是表征对齐思路。简单说模型A的第n层可能对应模型B的第n层但二者的表征空间并不对齐就像两个国家的人说不同的语言。要合并它们你得先学习一个“翻译矩阵”把模型A的表征空间映射到模型B的表征空间里去。这种方案的代表是mergekit库里的一些高级合并方法比如基于线性变换的映射合并。实际效果怎么样做过的人都懂能用但远不如同架构合并那样“无痛”。因为不同架构的模型训练目标虽然相似但内部特征的分布差异非常大强行对齐之后信息损失不可避免。所以目前开源社区里的模型合并绝大多数都集中在同架构、同尺寸的模型上。你想跨架构合并一个7B模型和一个70B模型基本可以放弃这个念想分布式训练领域倒是有些动态路由的思路但那不是严格意义上的“权重合并”更像是把不同模型塞进一个大系统里做分工协作。2.3 当前主流工具与生态现状做模型合并绕不开一个工具mergekit。这是目前社区内最常用的模型合并工具包支持多种合并方法也支持直接在Hugging Face上拉取模型权重。mergekit支持的方法主要有这么几种linear合并前面说的权重插值。task arithmetic任务算术把某个模型微调前后的权重差当成“任务向量”通过加减这些向量来实现能力的增减。TIES合并针对多个模型权重之间的符号冲突做处理先判断哪些权重重要再统一符号方向最后求平均。DARE合并随机丢弃部分权重差异再重新缩放据研究能有效降低噪声。slerp合并球面线性插值比普通的线性插值更平滑能减少“能力抵消”问题。我自己的实践下来如果两个模型基础差异不大直接用linear或者slerp就够了。如果想让合并后的模型在某一项能力上有显著提升task arithmetic更好用。而多个模型同时合并时TIES是首选因为它在处理参数冲突方面优势明显。这里多提一句slerp。线性插值其实是把权重向量沿直线方向取中间点但研究表明神经网络的权重空间并不是“平的”沿直线取平均容易掉进损失比较高的区域。slerp则是沿着高维球面的短弧线做插值想要在两个权重之间走一条更平滑的路径所以合并出来的模型在多数任务上更稳不容易出现能力崩坏的情况。2.4 合并流程的基本输入输出对入门者来说脑子里的模型合并流程图大概是这样的一堆权重文件经过一个合并脚本生成一个新权重文件。实际过程也确实如此但有几个非常关键的输入信息直接决定了合并结果好不好。首先tokenizer必须明确从哪边来。所有能合并的开源模型tokenizer在词表和分词方法上经常不一样。如果用模型A的tokenizer来加载合并后的权重却指望它保留模型B的词汇理解能力那基本不现实。tokenizer就是模型理解世界的“字典”这本字典是谁的新模型就更偏向谁。其次合并参数alpha的选择不是随便拍脑袋的。alpha太偏向模型A模型B的能力就体现出来了太偏向模型B模型A的优势又丢了。alpha怎么调要看你的具体任务倾向没有标准答案。我自己的经验是先0.5起步跑一遍评测再以0.05为步长微调反复几次找到最好的平衡点。最后合并前必须重新对齐模型配置。不同模型如果嵌入维度、层数、头数不同mergekit会直接报错。这些信息在模型的config.json里都有动手之前先看清楚别等到报错再排查。3. 合并后真的更强吗从实测效果说起3.1 合并优势的量化视角网上关于“合并模型比原模型更强”的说法很多但你要仔细看他们的评测数据会发现一个规律合并模型往往在综合平均分上有提升但在单项能力上很少能成为第一名。这种情况很容易理解。合并相当于把两种不同方向的能力拉到了同一个“均值”区域你可能会看到模型A在数学榜单上原本是70分模型B是60分合并后的模型能到75分模型A在代码榜单上原本是65分模型B是80分合并后的模型能到74分。看起来两块都有提升但提升的幅度其实不大远不如训练一个专用的微调模型来得直接。另外有一点要泼冷水很多评测榜单本身就有噪声。跑几次评测脚本分数上下浮动三四分都是正常的。有些社区冲榜的合并模型实际用起来给人的体验提升并没有榜单显示的那么夸张。3.2 什么任务的合并收益最明显那是不是所有场景都适合玩合并绝对不是。根据我自己和社区里的经验看合并收益最明显的场景主要有这么几类代码能力与通用能力的合并很多通用聊天模型的代码能力偏弱把代码专用模型与通用模型做合并往往能在不损失对话质量的情况下补上代码短板。中英文能力的互补合并国外模型在英文任务上强国内模型在中文任务上强把两者合并能得到一个“双语通吃”的模型。这个方向我实测效果不错中文语境下的连贯性提升特别明显。领域知识的注入把一个通用模型和一个法律/医疗领域微调模型合并能在保持通用对话能力的同时增加领域知识密度。但要注意领域微调模型本身可能因为灾难性遗忘而导致通用能力大幅缩水合并反而能把“遗忘”的部分找回来一部分。反过来哪些场景别碰合并我的建议是推理能力极强与推理能力极弱的模型合并是浪费。合并只会把强的拉低弱的抬高一点结果还是弱。多语言模型的合并要谨慎。模型A擅长英语和法语模型B擅长中文和日语合并后未必四种语言都通反而可能因为词表冲突导致某些语言乱码式输出。数学能力提升靠合并基本不要抱太大希望。“数学推理”主要依赖模型内部的推理链构建那玩意是结构性的不是简单加权平均就能焊上去的。合并最多能提升数字运算的稳定性但对复杂应用题该不会还是不会。3.3 实操案例我用合并把两者优势整合在一起我自己做过一个比较有代表性的实验用Qwen2.5-7B-Instruct和CodeQwen1.5-7B-Chat做合并。Qwen2.5-7B的通用对话能力很强代码能力中规中矩CodeQwen1.5的代码生成能力明显更强但通用对话经常跑偏说话语气也不太自然。我的目标很明确保留Qwen2.5的对话质量给它的代码能力加上buff。我在mergekit里选的方案是slerpalpha取0.7偏向Qwen2.5。合并完的模型我拿HumanEval和中文对话质量两个维度做评测结果如下模型HumanEval Pass1中文对话流畅度1-5分Qwen2.5-7B-Instruct55.6%4.7CodeQwen1.5-7B-Chat67.8%3.8合并模型alpha0.762.1%4.5从这个结果可以看到合并模型在代码能力上跟专用模型比还差一截但明显比原通用模型强在对话流畅度上则保留了通用模型的优势没有因为合并而“变傻”。对大部分人来说这种“综合水桶”反而更适合日常使用。不过也要注意这个实验是在同源模型之间做的。Qwen2.5和CodeQwen都属于Qwen家族训练底子高度相似所以合并效果相对理想。你换成完全不相干的两个厂商模型结果很可能不是这样。4. 实操指南如何从零开始合并一次模型4.1 环境和前期准备如果你看完上面的分析还愿意动手试一把那咱们就进入具体操作环节。先说硬件要求。合并过程本身不需要很强的算力因为只是对权重做运算7B模型合并时16GB内存的电脑基本就能跑最好有个8GB以上显存的GPU没有GPU纯用CPU也行就是慢一些。环境上需要准备的东西有Python 3.10以上PyTorch推荐2.0以上版本Hugging Face的transformers库mergekit库本身安装mergekit我用的是pip一行命令的事pip install mergekit如果你打算从Hugging Face拉权重直接装一下huggingface_hub然后写好模型名mergekit会自动下载。国内网络拉取Hugging Face的权重可能会慢可以先把模型用huggingface-cli或者镜像站下载到本地目录再在配置里指定本地路径。4.2 配置文件与合并参数调整mergekit推荐用YAML配置文件来描述合并方案这也是最清晰的方式。以下是我做Qwen合并时用的配置文件你直接参考这个格式改就行。# merge.yaml slices: - sources: - model: /path/to/Qwen2.5-7B-Instruct layer_range: [0, 28] - model: /path/to/CodeQwen1.5-7B-Chat layer_range: [0, 28] merge_method: slerp base_model: /path/to/Qwen2.5-7B-Instruct parameters: t: - filter: self_attn value: [0.7, 0.3, 0.3, 0.7] - filter: mlp value: [0.7, 0.3, 0.3, 0.7] - value: 0.7 tokenizer_source: model:/path/to/Qwen2.5-7B-Instruct dtype: bfloat16这里面有几点要特别注意slices里的layer_range如果两个模型都是32层Transformer你要把区间设成统一范围。如果层数不一致mergekit会报错所以务必先检查config.json。merge_method填slerp正如前面所说球面插值更稳。你用linear也能跑但效果可能有差别。parameters里的filter这个配置是让注意力层和MLP层分别用不同的合并强度。mergekit允许你针对特定层类型单独设置t值很多老手调优时都喜欢在这个地方做文章。tokenizer_source决定了新模型用谁的tokenizer。如果你更看重通用对话能力就取通用模型的tokenizer如果想要代码专用模型出效果就换成代码模型那边的tokenizer。4.3 运行合并与模型导出配置文件写好后运行一行命令就行mergekit-yaml merge.yaml ./ok-merged-model --copy-tokenizer这条命令会把合并结果写到./ok-merged-model目录下。--copy-tokenizer参数会把tokenizer一起复制过去省得后面手动处理。合并过程快的几分钟就能完慢的要看模型大小和机器性能。跑完后目录里会出现一堆权重文件包括safetensors格式的参数文件和config.json配置。你可以直接用transformers库加载这个目录也可以再用LLaMA.cpp转换成GGUF格式放到Ollama、LM Studio这类本地推理工具里用。转换GGUF格式大概是这个套路python llama.cpp/convert_hf_to_gguf.py ./ok-merged-model --outfile ok-merged.gguf然后把生成的GGUF文件拷到Ollama的模型目录里建一个Modelfile指向它用ollama create命令注册就能在本地用和原模型几乎一样的体验来测试合并模型了。4.4 合并效果的快速验证方法合并完成后别急着下结论先跑一轮评测是比较稳妥的做法。评测维度基本分三类通用能力用MMLU的几十道代表性题目测一下看看常识和推理能力有没有崩。代码能力拿HumanEval跑一遍算Pass1。对话体验这个必须人工测因为自动评测很难量“对话得像不像人话”。你直接拿几个常用场景问它比如让它写自我介绍、解释概念、瞎聊天观察输出是否自然。我一般还会在合并前把原模型也跑同样的评测做一个对比表格这样到底提升了还是退步了一眼就能看出来。5. 常见问题与典型踩坑5.1 合并后的模型输出全是乱码这个问题的出现频率特别高几乎所有第一次做合并的人都遇到过。原因十有八九是tokenizer来源没选对或者两个模型的词表差异太大。比如你把Llama系列的tokenizer硬套到Qwen的权重上中文输出大概率会变成一串“”符号。解决办法很简单tokenizer跟着你最看重的那个模型走不要随便选。另外合并之前最好确认一下两个模型的词表重叠度如果重叠度低合并效果一般也好不到哪去。5.2 合并后的模型“变傻了”通用能力暴跌这种情况常出现在两个模型架构相似但训练数据差异极大的合并里。比如把一个通用模型和一个专用领域模型合并领域模型那边的权重分布可能很“偏科”强行平均之后通用模型原本学好的知识被冲淡了。我踩过这个坑把Llama-3.1-8B和Mistral-7B做合并结果模型的常识问答能力大幅下降输出语气也变了。后来查资料发现这两个模型虽然都是7B级别但词汇表结构、训练超参差异都很大不适合粗暴合并。后来把合并方法改成TIES效果才稍微好一点但仍然不如单模型。这类问题的排查顺序是先确认两个模型的基座是否同源再看合并方法的选择最后检查alpha比例是否合理。90%以上的“合并变傻”案例原因集中于这三个环节。5.3 合并后模型输出内容空洞有些合并模型跑起来句子非常流畅但你仔细读发现它啥也没说。这个问题的根源是模型内部的知识密度被稀释了它保留了原有模型的“说话能力”但没有成功传承“知识记忆”。这时候可以试试把alpha往知识密度更高的那个模型偏一偏或者用task arithmetic的方式把“知识差异”单独当作一个向量加进去。另外还有一种思路不要合并完整权重只合并某一层或者某几层比如只合并后几层Transformer让前面的特征提取保持原样。5.4 关于“合并是不是最优解”的一点思考玩了挺久模型合并之后我逐渐有一个体会模型合并是权宜之计不是终极方案。它最大的意义在于低成本的模型能力集成。你用很低的算力甚至不需要重新训练就能得到一个“水桶型”模型这对中小企业或个人开发者来说性价比非常高。但如果你真的想要让模型在某个领域做到极致正确路径仍然是收集高质量数据做全量微调或继续预训练。合并做不到无中生有它只能把已经存在的能力做排列组合。另外模型合并的合法性在商用场景里也要留意。很多模型的权重许可证不同比如有的只允许研究用途有的允许商用但要求保留版权声明。合并前先把各个模型的license看清楚不要等模型上线了再吃官司。6. 聊点实践后的真实感受写到这里该讲的技术内容基本都讲完了。最后说一点我自己的切身体会模型合并这个技术外行看门槛高内行做起来其实门槛不高真正有技术含量的永远是判断力和调参经验。判断力体现在你要清楚自己为什么合并是想提升综合能力还是想补某一块短板。想明白了这个后面每一步决策都有了方向。调参经验则是靠一次次的实验堆出来的alpha取0.5和取0.7可能就在你CPU跑十几分钟的一念之差里产生出完全不同的两个模型。多记录多对比慢慢你就能找到手感。如果你手头有两三个开源模型真的建议找个周末自己动手合并一次。这个过程能让你非常直观地认识到大模型的黑盒到底有多黑——你做了最简单的加权平均模型行为却产生了复杂的化学变化这种体验比看一百篇论文都来得深刻。最后再提醒一句别盲信榜单分数也别被“合并即无敌”的说法忽悠。模型合并是一个好工具但它只是工具箱里的一把扳手不是万能钥匙。先用好手里的模型再考虑要不要合并它们。