微调模型怎么跟原模型融合：权重合并到部署的完整流程

你按教程跑完一次微调，手里多了个几百 MB 的权重文件，却发现它单独根本跑不起来——要么得跟原模型叠在一起加载，要么干脆合不进推理框架。这篇按「先判断要不要合、再动手合、最后验证上线」的顺序，把每一步该看什么、卡住了怎么查讲一遍。

你按教程跑完一次微调，手里多了个几百 MB 的权重文件，结果发现它单独根本跑不起来：要么得跟原模型叠在一起加载，要么干脆合不进推理框架。这篇按「先判断要不要合、再动手合、过格式这一关、最后验证上线」的顺序讲一遍，每一步该看什么、卡住了按什么顺序查。

先说明适用边界：如果你用的是托管式微调服务、只拿到一个可调用的接口，那合并这一步平台已经替你做了，你只需要关注调用格式和评测；本文针对的是自己下载权重、自己上推理框架的场景。另一种不适用的情况是纯提示词或检索增强，那压根不存在权重合并。

先分清：你的权重是适配器还是完整模型

这一步判断错了，后面全白干。打开输出目录看文件构成：如果是几个小文件、加起来远小于原模型体积，那基本是适配器，必须和原模型配合使用；如果是一整套接近原模型体积的权重，通常可以直接加载。前者需要合并，后者多数情况不需要。

• 看输出目录里是几个小文件还是接近原模型体积的一整套权重；前者必须和原模型一起用。
• 适配器要确认挂在哪一层：只挂注意力层，还是也挂了前馈层，这决定合并脚本选哪个参数。
• 对不上的常见症状是加载时报维度不匹配，或日志里提示跳过某个层。
• 基座和微调框架的对应说明，到 /models 和 /stacks/fine-tuning 核对，别凭记忆。

合并四步：备份、对齐精度、执行、比对体积

1. 备份原模型把原模型权重复制一份再动手。合并是覆盖式操作，出错只能靠备份回滚，这一步不能省。
2. 对齐精度合并前统一精度，别一半 fp16 一半 bf16。混用容易数值溢出，表现是输出全变成重复或乱码。
3. 执行合并用训练框架自带的合并脚本，指定基座路径和适配器路径。跑完看日志有没有提示跳过的层。
4. 比对体积合并产物大小应接近原模型本身。明显偏小，说明只写进去了一部分，得回头查脚本参数。

建议同一套流程先在本地或小机器上跑通，确认产物能加载，再放到有卡的机器或云端重跑。这样调试成本最低。合并前后的显存和存储开销，可以先到 /models/deploy 按当时的说明估算。

合并完还要过格式这一关

训练框架的格式和推理框架要的格式往往不是一回事，中间通常要转一次。转换不是可选项，跳过它最常见的后果就是加载时报配置缺失或权重不识别。

• 转换后检查三件套是否齐全：分词器文件、配置文件、权重文件，缺配置文件是最常见的加载失败原因。
• 量化版和全精度版分开存放，别把量化后的产物当原版继续做增量训练。
• 转换完先本地加载一次、发一个请求，确认能出正常结果再打包上服务器。
• 显存够不够先算一遍，参照 /models/deploy 的口径，避免转换完才发现跑不起来。

部署上线：先小流量验证再切

合并和转换都过了，不等于效果一定变好。上线前必须做对比验证，用固定的一小组输入同时跑原模型和微调模型，逐条看差异，重点看有没有变傻、答非所问，或把训练集内容原样背出来。

正式上线先给一小部分流量或内部账号，观察一段时间再全量。配置里保留指向原模型的开关，回退只改一个参数，出问题能在一分钟内切回去。想知道各家推理服务当时的价格和延迟表现，去 /price-watch 看当期数字。

合并不上、效果变差时的排查顺序

按固定顺序查，别四处乱试。绝大多数问题都出在前两步，越往后概率越低。以下顺序从最常见到最少见排列。

1. 先查基座版本确认基座版本和微调时用的完全一致。版本错配是最隐蔽的坑，日志不一定报错，但效果就是不对。
2. 再查层名映射确认合并脚本的层名映射没漏，日志里通常有跳过的层数，有跳过就要查为什么。
3. 查提示词格式确认推理时的提示词格式和训练时一致。格式不对会明显掉效果，但模型本身没问题。
4. 最后回训练侧以上都没问题还是差，就回去看数据量、训练轮数和学习率，别在部署环节死磕。

如果排查中发现是基座选型本身不合适，可以到 /rankings 看各类模型当时的对比，换一个基座重训往往比在部署上硬调更快。自己搭推理服务的话，先用 /tools/speed-test 测一遍实际吞吐，再决定扩容方案。