TIES 和 DARE 是否能保证合并后的模型同时保留所有能力？

不能。它们用于减少任务向量的冗余或符号冲突，但最终能力仍取决于源模型关系、合并参数、Tokenizer、校准集和评测覆盖，必须经过独立回归验证。

不同基础模型或不同 Tokenizer 的模型可以直接合并吗？

通常不应直接合并。生产环境应优先选择同一基础检查点、相同架构和兼容词表的模型；需要词表联合或层级拼接时，应把它视为模型手术并单独验证。

模型合并是否完全不需要数据？

执行权重合并可以不使用原训练数据，但生产选权、冲突诊断和发布门禁仍需要校准集、能力保留集与独立测试集，否则无法判断合并是否真正有效。

TIES 和 DARE 应该二选一吗？

不必。TIES 重点处理小幅冗余更新和符号冲突；DARE 通过随机丢弃与重缩放稀疏化任务向量。生产中可把 Linear、TIES、DARE-Linear 和 DARE-TIES 作为有限候选，用同一套校准集和独立门禁比较。

LLM 模型合并上线生产实战：用 TIES/DARE、校准集与能力回归门禁降低参数干扰

背景：模型合并不是简单的权重平均

同一个基础模型经过代码、数学、客服或行业语料微调后，会形成多个能力侧重点不同的检查点。将它们部署为多个独立服务，意味着额外的显存、路由和运维成本；把它们合并为一个模型，则可能在不增加单次推理成本的情况下获得更广的能力覆盖。

风险在于，微调后的参数变化并不是可以无条件相加的「功能插件」。不同模型可能在同一参数位置产生方向相反的更新，也可能用大量幅度很小的变化表达噪声。直接平均有时有效，但一旦源模型距离较远、任务目标冲突或词表与模板不一致，合并模型可能同时丢失多个源模型的优势。

因此，生产模型合并应被视为一次完整的模型构建与发布流程，而不是离线脚本执行完就可以上线。

核心原理：从任务向量理解参数干扰

设基础模型参数为 θ₀，第 i 个微调模型为 θᵢ，它相对基础模型的任务向量为：

τᵢ = θᵢ - θ₀
θ_merge = θ₀ + Σ wᵢ · τᵢ'

其中，wᵢ 是源模型权重，τᵢ' 是经过裁剪、稀疏化或冲突处理后的任务向量。真正困难的部分不是求和，而是决定哪些更新值得保留、冲突时相信哪一侧，以及如何验证组合后的行为。

TIES：先裁剪，再确定符号共识

TIES-Merging 将干扰归纳为两类：大量冗余的小幅参数变化，以及不同任务向量在同一位置上的符号分歧。它的处理过程可概括为：

Trim：去掉幅度较小的更新，减少冗余；
Elect Sign：为每个参数位置确定整体符号方向；
Merge：只合并与最终符号一致的更新。

这使 TIES 比无条件平均更适合多个同源微调模型，但它仍然需要密度、权重和源模型组合的选择。符号共识只能降低一种干扰，不能证明业务能力必然相加。

DARE：随机丢弃任务增量并重新缩放

DARE 对任务向量中的部分参数增量进行随机丢弃，并将保留下来的增量按 1 / (1 - p) 重新缩放。论文实验显示，某些同源微调模型的任务增量具有较高冗余，较高丢弃比例仍可能保留能力。

生产上不应把论文中的高稀疏比例当作默认参数。不同模型、训练方式和任务冲突程度差异很大。正确做法是把 drop rate、源模型权重和随机种子纳入可复现的候选矩阵，并用独立评测筛选。

校准集：从「凭经验配权」转向行为约束

2026 年的 Output-Space Projection 研究将合并权重选择表述为基于校准输入和源模型输出的优化问题，并给出用于预测合并质量的诊断量。它目前更适合作为研究方向，而不是直接替代成熟合并工具，但给工程团队的启示很明确：

合并系数不能只靠直觉或排行榜搜索，应让一组代表真实业务分布的校准样本约束输出行为。

校准集用于选参数，发布评测集用于决定是否上线，两者必须分离，避免把门禁数据调成「已知答案」。

工程落地：把合并流程做成可回放流水线

第一步：建立源模型准入门禁

在执行合并前，至少验证：

源模型是否来自同一个精确基础检查点，而不只是名称相似；
架构、层数、隐藏维度、注意力头和参数 Shape 是否兼容；
Tokenizer、特殊 Token、Embedding 矩阵和 Chat Template 是否一致；
每个源模型是否有独立能力基线和已知退化项；
模型许可证是否允许合并、再分发和商业使用；
权重文件是否经过哈希校验和安全扫描。

MergeKit 支持从基础词表、词表并集或指定模型构建输出 Tokenizer，也允许配置特殊 Token 的 Embedding 来源。这种能力解决的是「如何构建」，不等于「自动正确」。特殊 Token 的来源、Chat Template 和停止符仍需单独回放。

第二步：为每个合并产物生成不可变指纹

模型文件之外，还应保存一份合并清单。下面是治理字段示例：

{
  "base_model_sha256": "...",
  "source_models": [
    {"name": "code-sft", "sha256": "...", "weight": 0.55},
    {"name": "math-sft", "sha256": "...", "weight": 0.45}
  ],
  "merge_method": "ties",
  "method_parameters": {"density": "candidate-grid"},
  "tokenizer_source": "base",
  "chat_template_sha256": "...",
  "dtype": "bfloat16",
  "tool_version": "pinned-version",
  "random_seed": 20260713,
  "calibration_set": "merge-calibration-v3",
  "evaluation_suite": "merge-release-gate-v5"
}

任何源模型、权重、密度、随机种子、Tokenizer 或工具版本变化，都应生成新的产物版本，不能覆盖旧模型。

第三步：先建立简单基线，再增加算法复杂度

建议至少构建三类候选：

候选类型	目的
Linear / Model Soup 基线	判断源模型是否本来就处于相近区域
TIES 候选	观察符号冲突处理是否改善能力保留
DARE-TIES 候选	验证任务向量稀疏化能否进一步减少干扰

不要一开始就使用复杂层级配权或大规模自动搜索。若简单平均已经稳定，复杂方法只会扩大参数空间和回归成本。若简单方法失败，应先分析源模型距离、冲突层和 Tokenizer 差异，而不是盲目扩大搜索。

第四步：设计平衡的校准集和能力保留集

一套可用的合并评测至少包含四部分：

源能力保留集：分别覆盖每个源模型最重要的任务；
冲突样本集：同一输入下，源模型倾向给出不同风格、格式或结论的样本；
基础能力集：验证常识、语言、指令遵循等基础能力没有明显退化；
平台门禁集：结构化输出、安全策略、多语言、长短输入和边界 Token。

校准集可以用于选择权重和密度，最终门禁集必须保持独立。还应保留源模型逐样本输出，支持对合并模型进行差异回放，而不是只看一个聚合分数。

第五步：使用多维发布门禁

生产门禁不应只比较平均准确率。至少检查：

每个源能力的保留程度，避免总分上涨但单项能力坍塌；
基础模型能力和安全边界是否回退；
拒答率、格式遵循、输出长度和语言分布是否突变；
Tokenizer、Chat Template、停止符和工具调用格式是否兼容；
推理后端能否正确加载，显存、吞吐和延迟是否符合预算；
使用相同清单和随机种子能否重建相同产物。

具体阈值必须由业务风险和历史波动确定，不应复制论文或公共排行榜的统一数字。

第六步：按普通模型版本进行灰度和回滚

合并模型需要独立模型 ID，不应伪装成任一源模型的新版本。推荐发布路径为：

offline evaluation → replay / shadow traffic → small canary → staged rollout → full release

回滚目标应是上一个稳定合并版本或明确的单一源模型。模型卡中应记录完整 Merge Tree、源模型版本、方法参数、评测结果和已知限制，避免后续团队无法解释模型能力来源。

适用场景与不适用边界

模型合并适合以下情况

多个模型来自同一基础检查点，分别完成了能力明确的微调；
希望减少多模型常驻显存和路由复杂度；
可以建立覆盖每个源能力的回归集；
接受合并结果需要多轮候选筛选，而不是一次生成即上线。

以下情况应谨慎或放弃直接权重合并

源模型架构、基础模型或 Tokenizer 差异较大；
某个源模型存在未解决的安全或格式退化；
业务要求所有能力严格单调提升；
没有独立评测数据，只能依赖公共排行榜；
团队无法保存和复现完整的合并配置与源制品。

常见误区

误区一：同一个模型家族就可以直接合并

模型名称相似不代表基础权重完全一致。不同 revision、词表扩展、RoPE 配置或层结构都会改变合并含义。应以哈希、配置和参数 Shape 为准。

误区二：TIES 或 DARE 能自动消除能力冲突

它们降低的是特定类型的参数干扰。任务目标本身矛盾、模板不兼容或源模型质量不稳定时，算法不能替代产品决策和评测。

误区三：排行榜总分提高即可上线

总分可能掩盖代码、数学、安全或特定语言能力的单项下跌。生产门禁必须保留按能力、语言、输入长度和业务场景的分桶结果。

误区四：模型合并不需要任何数据

权重计算可以是 Data-Free，但参数选择和风险判断不是。没有校准集和回归集，就无法知道合并产物是否保留了真正需要的能力。

误区五：只保存合并后的权重即可

没有源模型哈希、方法参数、随机种子、Tokenizer、模板和工具版本，产物不可重建，也无法审计能力变化来源。

上线检查清单

FAQ

Q：能否把不同基础模型的能力合并到一起？

传统任务向量方法通常依赖同源或高度兼容的参数空间。跨架构、跨词表或参数 Shape 不一致时，需要更复杂的层级拼接、Tokenizer 移植或模型手术，风险和评测成本显著提高，不应与普通模型合并混为一谈。

Q：合并模型表现不好，应该先调权重还是换方法？

先定位问题。若某项能力随源模型权重单调变化，可先调权重；若大量参数符号冲突，可测试 TIES；若任务增量高度冗余，可测试 DARE。若 Tokenizer、模板或基础检查点不一致，应先修复兼容性，而不是继续搜索合并参数。

参考资料

TIES-Merging: Resolving Interference When Merging Models — https://arxiv.org/abs/2306.01708
Language Models are Super Mario: Absorbing Abilities from Homologous Models as a Free Lunch — https://arxiv.org/abs/2311.03099
MergeKit GitHub Repository — https://github.com/arcee-ai/mergekit
Arcee’s MergeKit: A Toolkit for Merging Large Language Models — https://arxiv.org/abs/2403.13257
Model Merging by Output-Space Projection — https://arxiv.org/abs/2605.29101
Model Soups: Averaging Weights of Multiple Fine-Tuned Models Improves Accuracy without Increasing Inference Time — https://arxiv.org/abs/2203.05482