很多人在 LLaMA Factory 里把 LoRA 跑完了，loss 也看着顺眼，结果卡在最后一步：Ollama 那边 create 完没反应，或者跑起来答非所问。问题基本不在微调本身，而在中间那几步——基座选了哪个、adapter 有没有合并、模板有没有对上、GGUF 怎么来的。这篇按顺序把这条链路拆开，每一步告诉你该检查什么、错了会有什么现象，数字类的东西去站内页面核当时的版本。
在 LLaMA Factory 里把 LoRA 跑完、loss 曲线看着也顺眼，结果一到 Ollama 就卡住：create 完没反应，或者能跑起来但答非所问。这种情况八成不是训练本身的问题，而是中间那几步没接上——基座选了哪个、adapter 有没有合并、对话模板有没有对上、GGUF 到底是怎么来的。这篇就按这条链路从头到尾拆一遍。
链路上每一步出错的「症状」其实挺不一样，先记住这个对应关系，后面排查会快很多：基座选错，通常是模型能加载但完全不像微调过的样子；adapter 没合并，多半是加载失败或输出乱码；模板没对上，表现是能答但格式怪、容易复读；GGUF 转换掉层，就是体积明显偏小、回答变短变呆。具体版本、档位这类会变的数字，都去站内页面核当时的实际情况。
先确认微调产物长什么样，别急着导出
很多人一跑完就想直接转格式，结果转一半发现手里东西根本不对。下手之前先花两分钟看清楚训练输出目录里到底有什么，这一步判断错了，后面全是白干。
- 分清你手里是纯 adapter、合并后的全量权重，还是已经是 GGUF——这三种后续走的路完全不同，纯 adapter 不能直接拿去 create；
- 翻训练输出目录里的 adapter 配置文件，确认它记录的基座，和你要转的基座必须是同一个，中途换过基座就白转；
- 顺手核一下对话模板：微调时用的模板和 Ollama 侧跑的模板对不上，是最常见的「能加载但答得怪」原因；
- 导出前先做小样本人工测试，随手问几个问题看回答是否合理，别等转完格式才发现问题，返工成本差好几倍。
| 产物类型 | 能不能直接给 Ollama 用 | 下一步 |
|---|---|---|
| 纯 LoRA adapter | 不能 | 先和基座合并成全量权重 |
| 合并后的全量权重 | 不能直接读，需转格式 | 转成 GGUF 再导入 |
| 已转好的 GGUF | 可以 | 写 Modelfile 用 create 导入 |
合并权重与转 GGUF：这一步最容易出兼容问题
顺序错了是这一步最常见的坑。一定先在 LLaMA Factory 侧把 adapter 合并成完整权重，再拿合并结果去转 GGUF，不要拿 adapter 直接转。转换工具、目标量化档位都要和 Ollama 侧支持的格式对齐，档位怎么选没有绝对答案，按你机器的显存和实测效果来定，换算口径可以到 /tools 里的转换工具页看。
- 合并权重在 LLaMA Factory 里用导出/合并功能把 adapter 和基座合成完整权重，产出一个独立目录，确认里面模型文件齐全。
- 转 GGUF用转换脚本把合并结果转成 GGUF，注意指定正确的模型类型和量化档位，转换过程留意有没有报缺文件。
- 验产物看输出的 GGUF 体积，和原基座对不上是正常的，量化本来就会改大小；但如果明显偏小，往往意味着中途掉了层，需要回看日志。
转换报错时优先查三件事：基座架构是否被转换工具支持、配置文件里的模型类型字段写没写对、分词器文件有没有一起带上。这三条能覆盖大部分报错，比一上来重装环境高效得多。
导入 Ollama：Modelfile 写不对等于没转
到了导入这步，真正决定成败的是 Modelfile。用 create 方式导入本地 GGUF 时，FROM 指向文件路径，同时把对话模板、停止符、系统提示都显式写进去。模板要和你微调时的格式严格一致——差一个角色标签，输出就可能退化成复读或者自问自答。
# 示例结构，字段值按你自己的文件路径和模板填
FROM ./your-model.gguf
TEMPLATE """你的对话模板"""
PARAMETER stop "你的停止符"
SYSTEM "你的系统提示"
# 然后用 create 导入
ollama create 你的模型名 -f Modelfile导入后做两轮测试：先用基础问答做冒烟测试，看模型能不能正常对话；再专门测微调想强化的那个任务，两类都过才算成功。批量或离线迁移的场景，先在一台小机器上验证通过再推内网，别一次性铺开。迁移路径、本地文件处理这些，可以到 /tools 里找对应工具。
验收与排查：跑不通时按这个顺序查
出了问题时最容易犯的错是一上来就怀疑训练。其实按固定顺序倒排，几分钟就能定位到是哪一环。顺序是：基座对不对 → 合并有没有成功 → GGUF 能不能被读 → Modelfile 模板对不对 → 提示词格式对不对。
- 加载成功但答非所问，先换回原始基座跑同一句，能区分是微调没学好还是模板问题；
- 速度慢、显存吃紧属于部署侧问题，先量一遍基线再谈优化，延迟横向对比可以到 /tools/speed-test；
- 想省掉自己搭转换链条，也可以对比托管微调服务，选型口径看 /stacks/fine-tuning；
- 每次只改一个变量再测，同时改多处会分不清到底哪个起效。
| 现象 | 最可能的位置 | 先查什么 |
|---|---|---|
| create 完没反应 | 导入环节 | GGUF 路径和格式是否被支持 |
| 能加载但答得怪 | 模板环节 | 微调模板与 Modelfile 是否一致 |
| 输出乱码或加载失败 | 权重环节 | adapter 是否已正确合并 |
| 回答变短变呆 | 转换环节 | GGUF 是否中途掉层、档位是否过激 |
常见问题
微调完必须先合并 adapter 才能转 Ollama 吗？
绝大多数情况下要。Ollama 侧吃的是完整权重或 GGUF，纯 adapter 不是它能直接加载的形态。先合并成全量权重，再转 GGUF，链路最稳。只有当你明确用的是支持在线挂 adapter 的推理框架时，才可能跳过合并这一步。
转换成功了，但 Ollama 里回答质量明显比 LLaMA Factory 里差，为什么？
先查模板。两边对话模板、停止符、系统提示不一致，是最常见的原因，表现就是答非所问或复读。其次查量化档位，量化越激进损失越大。最后才怀疑训练本身。建议同一句测试题在两边各跑一遍对照。
整条链路要花多久，什么时候不该自己转？
耗时主要看你转换和量化用的机器，训练本身之外的部分通常比训练快得多。如果你只是想验证效果、不打算长期自托管，或者团队没人维护这套流程，更省事的路是走托管微调服务，具体目录可看 /stacks/fine-tuning。
