ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

mergekit-multi 多阶段模型合并指南:基于 YAML 多文档配置编排复杂合并流水线

mergekit-multi 多阶段模型合并指南:基于 YAML 多文档配置编排复杂合并流水线 大模型模型优化AI 应用【免费下载链接】mergekitTools for merging pretrained large language models.项目地址https://gitcode.com/gh_mirrors/me/mergekit点击查看免费下载mergekit-multi是 mergekit 提供的命令行工具用于执行包含多个相互依赖阶段stage的复杂模型合并工作流它可以串联多次合并操作、把前一步的输出作为后续步骤的输入、自动解析合并步骤之间的依赖关系并缓存中间结果以加速重复运行。读完本文你将掌握mergekit-multi的完整命令用法、YAML 多文档配置格式含最终合并与全命名合并两种形态、关键命令行选项以及其背后的依赖图调度与懒执行原理。什么是 mergekit-multimergekit-multi解决的是一次合并不够用的问题。常规的 mergekit-yaml 只执行一次合并而现实中的模型融合方案往往需要分阶段递进例如先用linear将两个领域微调模型平均得到一个中间模型再以该中间模型为输入用slerp向另一个指令微调模型插值最后用dare_ties把前两步产物与更多模型做一次任务向量合并得到最终模型。这种合并的合并merge of merges正是mergekit-multi的核心场景。它允许你将多次合并操作串联chain在一起使用前一次合并的输出作为后续合并的输入自动处理各合并步骤之间的依赖关系缓存中间结果让重复运行更快默认启用懒执行。入口命令为mergekit-multi其实现位于 mergekit/scripts/multimerge.py在 pyproject.toml 的[project.scripts]中注册为mergekit-multi mergekit.scripts.multimerge:main。基本命令结构mergekit-multi config.yaml \ --intermediate-dir ./intermediates \ ([--out-path ./final-merge] | 仅当配置中存在未命名合并时需要) \ [options]其中config.yaml一个 YAML 文件内含多个由---分隔的 YAML 文档document每个文档都是一份独立的 mergekit 合并配置--intermediate-dir可缩写-I存放中间合并结果的目录必填--out-path最终合并结果的输出路径仅当配置中存在一个未命名无name字段的合并时必填。命令行定义见 mergekit/scripts/multimerge.pyconfig_file是位置参数要求文件存在--out-path是可选的会在主函数中进一步校验--intermediate-dir必填。此外mergekit-multi通过add_merge_options继承了 mergekit 的全部标准合并选项并且其--help输出使用PrettyPrintHelp按类别分组展示。out-path 的取值规则--out-path与配置中是否存在未命名合并是成对约束的源码中的校验逻辑如下multimerge.py若配置中存在未命名合并即某个 YAML 文档没有name字段则该合并被视为最终合并--out-path为必填项否则直接报错--out-path is required when configuration contains an unnamed final merge若配置中所有合并都有名字则不需要--out-path全部结果都会写入--intermediate-dir。配置文件格式核心约定配置文件是一个包含多个 YAML 文档的文件每个文档用---分隔各自包含一份完整的 mergekit 合并配置并遵守以下规则每个中间合并必须带有name字段作为唯一标识符重复的name会直接报错Duplicate merge name name最终合并不应带有name字段配置中最多只能有一个未命名合并否则报错Multiple unnamed merge configurations are not supported每个文档内部使用 mergekit 标准的配置参数merge_method、models、base_model、parameters等关键在models列表中可以通过其他合并的name来引用前序合并的输出作为本次合并的输入模型。配置解析在 load_config 中完成先用yaml.safe_load_all读取所有文档剔除name字段后用MergeConfiguration.model_validate校验每个文档然后扫描每个配置中引用的模型名凡是命中已知合并名的都会在运行时被替换为intermediate_dir/name的实际本地路径见patched_configmultimerge.py。标准配置参数说明每个 YAML 文档内可用的标准配置参数由 mergekit/config.py 定义包括字段说明merge_method合并方法必填。如linear、slerp、dare_ties、task_arithmetic等完整清单见 docs/merge_methods.mdmodels参与合并的输入模型列表每项是{ model: ... , parameters: {...} }相互之间用name引用前序合并base_model某些合并方法如slerp、task_arithmetic、dare_ties需要的基础模型parameters合并参数如weight、density、t、lambda等也可下沉到单个模型级别dtype/out_dtype合并运算与输出权重的数据类型tokenizer_source/tokenizer输出 tokenizer 的构建方式union、base或指定模型路径chat_template输出模型的对话模板含最终合并的示例multimerge.yaml下面这份配置演示了三种方法linear→slerp→dare_ties的完整流水线其中前两步是带name的中间合并最后一步是不带name的最终合并name: first-merge merge_method: linear models: - model: mistralai/Mistral-7B-v0.1 - model: BioMistral/BioMistral-7B parameters: weight: 0.5 --- name: second-merge merge_method: slerp base_model: first-merge # 引用上一次合并的输出 models: - model: NousResearch/Hermes-2-Pro-Mistral-7B parameters: t: 0.5 --- # 最终合并无 name merge_method: dare_ties base_model: mistralai/Mistral-7B-v0.1 models: - model: second-merge parameters: density: 0.6 weight: 0.5 - model: teknium/OpenHermes-2.5-Mistral-7B parameters: density: 0.8 weight: 0.5要点解读second-merge的base_model直接写成first-mergemergekit-multi 会将其解析为./intermediates/first-merge这个本地目录最终合并的models中second-merge同样会被解析为中间结果路径因此最终合并实际是在合并上一步的合并产物和原始模型模型名解析发生在patched_config中它遍历整个配置的数据结构凡是model字段的路径与某个合并名完全一致的就替换为os.path.join(intermediate_dir, base)multimerge.py。全部命名的示例如果希望所有合并都是中间合并不产出最终模型可以全部携带namename: first-merge merge_method: task_arithmetic ... --- name: second-merge merge_method: slerp ... --- name: third-merge merge_method: linear ...这种写法不需要--out-path三个合并的结果会分别落在--intermediate-dir下的first-merge/、second-merge/、third-merge/。实际运行命令对应含最终合并的配置运行命令为mergekit-multi multimerge.yaml \ --intermediate-dir ./intermediates \ --out-path ./final-merge \ --cuda对应全部命名的配置则省略--out-pathmergekit-multi multimerge.yaml --intermediate-dir ./intermediates关键命令行选项mergekit-multi专属选项如下见 multimerge.py选项说明--intermediate-dir/-I存放中间合并结果的目录必填。所有带name的合并都会以intermediate_dir/name保存--out-path最终合并的输出路径仅当配置中存在未命名合并时必填--lazy/--no-lazy是否跳过已存在的中间合并。默认--lazytrue若某个合并的输出目录中已存在config.json且至少一个权重文件则跳过该步骤--no-lazy强制全部重新执行此外mergekit-multi继承了 mergekit 的全部标准合并选项mergekit/options.py 中MergeOptions定义的字段会自动生成 CLI 参数常用包括--cuda/--device device在 GPU / 指定设备上做矩阵运算device支持auto自动探测--out-shard-size size输出分片大小支持k/m/b后缀如5B默认5B--multi-gpu使用多 GPU 并行图执行引擎--low-cpu-memory把结果与中间值存放在加速器上适合 VRAM 大于 RAM 的场景--gpu-rich--cuda --low-cpu-memory --read-to-gpu --multi-gpu的组合别名--copy-tokenizer/--no-copy-tokenizer是否把 tokenizer 复制到输出默认开启--safe-serialization/--no-safe-serialization是否以 safetensors 保存输出默认开启--trust-remote-code信任来自 Hugging Face 仓库的远程代码危险选项--allow-crimes允许混用不同架构危险选项--random-seed seed为随机性合并方法如 DARE 类设置固定随机种子--num-threads/-jCPU 并行线程数--write-model-card/--no-write-model-card是否生成 README.md 模型卡与mergekit_config.yml默认开启-v可重复提高日志详细程度。工作原理依赖图调度与懒执行1. 解析配置并构建依赖关系load_configmultimerge.py完成两件事读取全部 YAML 文档得到merge_configs以name为键、None表示最终合并以及通过patched_config扫描出每个合并引用了哪些中间合并得到dependencies映射。patched_config同时会把引用到的合并名改写成intermediate_dir/name的本地路径这样后续每次run_merge就能直接读取磁盘上的中间模型。2. 递归建图检测循环依赖make_tasksmultimerge.py为每个合并创建一个 MergeModelTask并通过input_merges字段把依赖的合并任务递归地串联起来带name的合并输出到intermediate_dir/name未命名合并输出到--out-path若在递归过程中再次遇到正在构建中的任务会抛出Circular dependency detected involving name即配置中存在循环引用时直接报错。3. 拓扑排序顺序执行构建好的任务集合交给 Executor来自 mergekit/graph.py执行。Executor 通过build_schedulegraph.py使用 networkx 对任务依赖图做字典序拓扑排序networkx.lexicographical_topological_sort生成一个同时满足依赖顺序、并按priority/group_label排序的执行计划随后按序执行每个MergeModelTask。MergeModelTask.execute内部会用解析好的配置调用 run_mergemergekit/merge.py完成加载模型、规划合并图、写权重与 tokenizer 等全流程。值得说明的是mergekit-multi外层 Executor 使用math_devicecpu、storage_devicecpumultimerge.py注释中明确指出内层执行器负责处理加速器——即每个单独合并真正跑矩阵运算时仍会使用你在命令行传入的--cuda/--multi-gpu等设备选项外层只负责编排顺序与传递结果路径。4. 懒执行命中即跳过MergeModelTask.executemultimerge.py在执行前检查若lazy为 True且输出目录中已存在config.json并且存在以下任一权重文件之一model.safetensors pytorch_model.bin model.safetensors.index.json pytorch_model.bin.index.json则记录日志Model already exists at path, skipping并直接返回该路径跳过本次合并。这就是默认行为下重复运行会秒过已完成的中间步骤的原因如需强制重跑所有合并例如参数或输入模型发生了变化使用--no-lazy。实践建议与注意事项复用与缓存--intermediate-dir是工作流的核心资产。中间合并按name落盘后你既可以在后续阶段引用它也可以单独用mergekit-yaml加载它做其他实验默认懒执行让多轮迭代只重算真正变化的步骤。为每个中间步骤命名命名不仅是引用手段也是目录名intermediate_dir/name。建议使用语义化名称如base-avg、chat-slerp便于追溯。依赖只在models的模型引用中生效合并名引用通过模型路径匹配识别multimerge.py因此把前序合并写在models[].model或base_model中均可被解析但务必保证字符串与前序name完全一致。最终合并唯一性未命名合并只能有一个且必须配合--out-path否则 CLI 会直接拒绝运行。设备与内存每个阶段独立执行并写盘中间模型不常驻内存因此整体内存峰值由单次最大合并决定需要加速时加--cuda多卡环境可用--multi-gpu。与单一 mergekit-yaml 的区别mergekit-yaml一次只执行一份配置mergekit-multi则把多份配置、跨阶段引用与缓存编排统一在一个 YAML 文件与一条命令中。延伸阅读mergekit README多阶段合并章节合并方法指南linear、slerp、dare_ties 等参数详解MergeConfiguration 与参数定义图执行引擎 Executor 与拓扑排序run_merge 单次合并执行流程mergekit-multi 入口实现赞分享大模型模型优化AI 应用【免费下载链接】mergekitTools for merging pretrained large language models.项目地址https://gitcode.com/gh_mirrors/me/mergekit点击查看免费下载相关推荐Sandcastle 并行多分支合并阶段实战深入解析 merge-prompt.md 与分支合入流水线Sandcastle 并行多分支合并阶段实战深入解析 merge prompt.md 与分支合入流水线 本文聚焦 Sandcastle 仓库中 paralle终极指南如何用iptv-checker高效管理500IPTV频道3分钟快速部署教程终极指南如何用iptv checker高效管理500IPTV频道3分钟快速部署教程 还在为IPTV播放源频繁失效而烦恼吗面对成百上千个频道列表手动测试后端任务调度音视频MergeKit模型合并工具箱指南MergeKit模型合并工具箱指南 项目目录结构及介绍 MergeKit是一个用于合并预训练语言模型的工具包旨在资源受限环境下执行复杂的模型合并操作。以下是大模型模型优化AI 应用上一篇go-openai文件处理详解音频转录与图像生成实战下一篇Visdom环境变量完全指南快速自定义你的可视化工作空间创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表