先说结论
技术上可以"合并"，但"合并"有好几种含义，结果差异巨大。
权重平均与模型融合（Model Merging），是把多个同架构、同tokenizer的开源模型合并成一个，方法得当常常能实现1+1大于1，等于白嫖多个模型的能力。跨厂商闭源模型（GPT、Claude、Gemini、文心、通义、豆包等）不开放权重，无法直接合并，只能做集成、路由、蒸馏、Agent协作，本质是协作而非合并。合并后不一定更好：同源同架构合并常有惊喜，异构模型强行合并容易互相拖累，闭源模型做系统级集成提升有上限，且成本和延迟都会上升。
一、先分清"合并"的五种含义
很多人说"合并大模型"，指的不是同一件事，常见有五种。
第一种是权重平均。多个同架构模型的参数直接取平均。仅限同架构开源模型，有时有提升，有时直接崩。
第二种是模型融合（Model Merging）。用Task Arithmetic、TIES、DARE、SLERP等方法做参数层面的合并。仅限同架构、同tokenizer的开源模型，方法得当常能实现1+1大于1。
第三种是集成与路由（Ensemble / Router）。多个模型分别推理，对结果做投票，或者按问题类型路由分发。可以跨厂商、在API级别操作，通常能稳定提升，但成本较高。
第四种是蒸馏（Distillation）。用大模型教小模型，或者多个teacher模型融合。可以跨厂商，但需要训练，小模型会变强，上限受teacher限制。
第五种是级联与Agent协作。多个模型分工、互相调用。灵活度高，但工程复杂度也高。
所以"各大厂商的模型能不能合并"要分情况回答：开源同架构模型可以真正合并权重，闭源跨厂商模型只能做系统级协作。
二、真正的模型合并怎么做
2.1 权重平均（Weight Averaging）
最朴素的做法，把两个同架构模型的权重直接取平均。合并后的参数等于模型A的参数乘以权重，加上模型B的参数乘以权重，两个权重之和为1。
问题也很直接：两个模型微调方向差异大时，平均后可能两边能力都丢，出现"均值塌陷"。
这个方法的优势是实现简单，一行代码就能完成。适用场景是同一基座模型在不同数据集上微调后的合并，且任务之间相关性较高。
2.2 SLERP（球面线性插值）
SLERP的全称是Spherical Linear Interpolation。它解决的问题是：权重平均在高维空间中走的是直线，但高维空间中直线路径可能穿过低概率区域，导致合并效果不佳。
SLERP的做法是把两个参数向量看作球面上的点，沿着球面弧线做插值。这样插值路径始终在高维球面上，避免了穿过"无人区"。
当两个向量方向接近时，SLERP和线性插值差别不大；当方向差异较大时，SLERP能更好地保持两个模型各自的特征。目前这是两个模型融合最常用的方法，MergeKit中的slerp默认也只支持两个模型融合。
2.3 Task Arithmetic（任务向量算术）
Task Arithmetic的核心洞察是：微调后的模型减去基座模型，得到的是一个"任务向量"，这个向量代表了模型在该任务上学到的能力。
具体操作是：先计算每个微调模型相对于基座模型的任务向量，然后把这些任务向量按权重相加，再加回基座模型，得到合并后的模型。
用公式表示就是：任务向量等于微调模型减去基座模型，合并后的模型等于基座模型加上权重系数乘以任务向量。等于给模型"加技能"，比如数学能力加代码能力。
这个方法的好处是可以控制每个任务的权重。如果某个任务更重要，就加大它的任务向量权重；如果某个任务想弱化，就减小权重甚至取负值。适用场景是多个不同任务的微调模型合并，且任务之间相对独立。
2.4 TIES（Trim, Elect Sign, Merge）
TIES是针对Task Arithmetic的改进方法，解决了任务向量合并时的两个问题：参数冲突和冗余。
TIES分三步。第一步是Trim，把每个任务向量中绝对值很小的参数置零，只保留重要的参数更新，减少冗余和噪声。第二步是Elect Sign，对于每个参数位置，看多个任务向量在该位置的符号，取多数符号作为最终符号，解决不同任务向量在同一参数上符号冲突的问题。第三步是Merge，只对符号一致且非零的参数做平均，得到最终的任务向量。
TIES的效果通常优于简单Task Arithmetic，尤其在任务数量较多时，能有效减少任务之间的干扰。适合一次融合多个专家模型。
2.5 DARE（Drop And REscale）
DARE的核心发现是：微调后的任务向量中，大部分参数变化是冗余的，真正重要的变化只占很小一部分。
DARE的做法是：随机丢弃大部分任务向量中的参数变化（论文发现丢90%甚至99%影响都不大），然后把保留的参数按比例放大，以补偿丢弃带来的影响。这样得到的稀疏任务向量在合并时冲突更少，效果反而更好。
DARE通常和TIES配合使用：先用DARE稀疏化任务向量，再用TIES做符号选举和合并。这个组合在当前的开源模型合并实践中效果较好。
2.6 工具与示例
社区主力工具是MergeKit，由Arcee AI开源，支持linear、slerp、ties、dare等方法，轻量封装有LazyMergekit。
下面是一个TIES融合的配置示意，layer需按实际模型完整填写：
yaml
slices:
- sources:
model: base_model
layer_range: [0, 32]
- sources:
model: ft_math
layer_range: [0, 32]
model: ft_code
layer_range: [0, 32]
merge_method: ties
base_model: base_model
parameters:
normalize: true
近两年研究也在往子空间、谱系方向走（TSV-Merge、ResMerge、SA-Merging等），但生产上最常用的仍是SLERP、TIES、DARE这套组合。
2.7 为什么同架构合并常有效
同架构模型共享相同的表示空间，权重差异可以近似看作"能力方向"。合并相当于在参数空间里做多任务学习，有时能缓解灾难性遗忘，还能结合多个模型的强项。
前提是：同架构、同tokenizer、同预训练基础，且微调数据差异够大但不太冲突。
三、闭源模型不能合并权重，只能协作
GPT、Claude、Gemini、文心、通义、豆包不开放权重，架构、tokenizer、训练数据、对齐方式全不相同，只能通过API调用。能做的有五件事。
第一件是集成（Ensemble）。多个模型同时回答，投票、打分选最佳，或者用另一个模型当裁判（LLM-as-a-Judge）。推理和事实性任务上通常比单模型好，代价是N倍推理成本和延迟。
第二件是路由（Router）。训练一个分类器或小模型判断问题类型，分发给最擅长的模型。代码问题路由给Claude或DeepSeek Coder，中文知识路由给文心或通义，数学问题路由给GPT或Gemini，长文总结路由给Kimi或Claude。性价比高，但路由错一次就拖累整体。
第三件是级联（Cascade）。小模型先答，置信度低再升大模型。省成本，但延迟不稳定。
第四件是蒸馏（Distillation）。拿多个强模型的输出当训练数据，蒸馏进一个开源模型，等于"吸收"多家能力。贵在数据和算力，且上限受学生模型容量限制。
第五件是Agent协作。多个模型分角色，互相评审、辩论、调工具。复杂任务可能超过单模型，但token消耗大、稳定性难控。
四、合并后一定更好吗？不一定
会更好的情况：同架构开源模型能力互补，融合方法得当；路由和集成策略准确，任务分布匹配；蒸馏数据质量高、学生容量够；Agent分工明确且有验证机制。
不会更好甚至更差的情况：异构模型强行权重平均，直接崩；能力高度重叠，合并收益低；路由错误，比单模型差；集成多个弱模型，不如一个强模型；teacher本身有幻觉，学生继承错误。再加上成本、延迟、维护复杂度上升，工程上不一定划算。
一个关键认知：模型合并不是"大力出奇迹"，本质是"在参数空间做多任务学习"。它有效，是因为同源模型共享表示空间；跨厂商闭源模型没有这个基础，只能做系统级协作。
五、工程落地建议
开源模型路线：优先选同架构、同tokenizer的模型，用MergeKit试SLERP、TIES、DARE，在小验证集上评估，别只看benchmark，注意license兼容性。
闭源API路线：先做路由，再做集成，用LLM-as-a-Judge做自动评估，用缓存、级联、按任务分层控制成本，别迷信多模型投票，有时单强模型更稳。
生产系统：合并和集成只是手段，评估集才是核心，盯延迟、成本、稳定性、可观测性，保留回退策略，路由失败回默认强模型，模型、prompt、路由策略全部版本化。
六、总结
同架构开源模型可以真正合并权重，方法得当常能1+1大于1；跨厂商闭源模型不能合并，只能集成、路由、蒸馏、Agent协作，可能更好，但成本、延迟和复杂度都会上升。合并不是万能药，评估集和工程取舍才是关键。
参考 Yadav et al., TIES-Merging: Resolving Interference When Merging Models
Yu et al., Language Models are Super Mario: Absorbing Abilities from Homologous Models as a Free Lunch（DARE）
Ilharco et al., Editing Models with Task Arithmetic
MergeKit：github.com/arcee-ai/mergekit
LazyMergekit：github.com/mlabonne/LazyMergekit