llama_factory微调模型并导入ollama

很多人卡的不是训练本身，而是训练完之后那一步：LLaMA-Factory 里跑完的权重，怎么变成 Ollama 能认的模型。中间差着合并、格式转换、量化档位和 Modelfile 四道工序，任何一道没对上，Ollama 那边就是报错或者加载不了。这篇按「数据→训练→导出→导入→验证」的顺序把流程走一遍，重点标出容易踩的坑和判断标准，最后给一份排查顺序。

很多人卡的不是训练本身，而是训练完之后那一步：LLaMA-Factory 里跑完的权重，怎么变成 Ollama 能认的模型。中间差着合并、格式转换、量化档位和 Modelfile 四道工序，任何一道没对上，Ollama 那边就是报错或者加载不了。

这篇按「数据→训练→导出→导入→验证」的顺序把流程走一遍，重点标出容易踩的坑和判断标准。每一步都给出可判断的信号，而不是「大概这样应该就行」。最后附一份从后往前的排查顺序，遇到问题按顺序走，比反复重训省时间。

先想清楚这一步值不值得做

微调解决的是「行为」问题：固定格式输出、固定口吻、领域术语对齐、固定排版的判断。这类任务用提示词写不死、写长也不稳，微调就能把它固化成模型习惯。如果你的目标是让模型知道新的事实、新的产品信息、更新的政策，那它属于「知识」问题，微调和提示词都不是最优解。

• 行为类需求（固定 JSON 格式、统一客服口吻、按模板输出报告）优先考虑微调；知识类需求（新事实、新文档、新政策）优先考虑检索增强
• 数据少于几百条高质量样本时，别急着动手，先把样本攒够，标注一致性比条数更重要
• 如果样本标注本身就自相矛盾，微调只会让模型学歪，先把标注规范统一
• 任务本身需要强泛化能力（开放式写作、跨领域推理）时，微调往往带来退化，谨慎评估
• 不确定要不要做时，先用提示词 + 检索跑一遍对照，能达标就别上微调

行为对齐

让模型稳定按某种方式说话或输出，微调擅长这类

知识更新

让模型知道新东西，更适合检索增强而不是微调

样本一致性

同一输入的不同标注答案要统一，否则训练目标本身就是噪声

环境与数据：开工前把这两件事定死

环境部分最容易拍脑袋。显卡要按参数量和微调方式估：全参微调比 LoRA 高一大截，同一张卡跑小参数量加 LoRA 能过，换成全参就可能直接显存不足。建议先按小参数量加 LoRA 把整条管线跑通——训练、合并、转换、导入全都走一遍——再放大规模，这样排查问题时变量少。

数据格式优先对齐 LLaMA-Factory 自带的 alpaca 或 sharegpt 模板，字段名别自创。自己造字段名的时候，配置文件里对不上，报错还容易看错方向。训练集和验证集必须分家，留一小批完全不参与训练的样本，用来判断有没有过拟合。

1. 确认硬件档位按参数量和微调方式估显存，先按「小参数量 + LoRA」定方案
2. 对齐数据模板优先套用 alpaca 或 sharegpt 的字段结构，不自创字段名
3. 切分训练/验证集留一小批不参与的样本，后面用它判断过拟合
4. 小样本试跑先拿几十条样本跑通一轮，确认路径、配置、显存都没问题
5. 再上全量管线确认无误后，再替换成全量数据正式开始

训练配置：几个真正影响结果的旋钮

LLaMA-Factory 的配置项很多，但真正影响结果的没几个。学习率和训练轮数是最容易设过头的地方——先按官方示例的默认档位跑一遍，看验证集曲线的走向，再决定加还是减。曲线一直在往上冲、验证集却开始掉，那就是过头了。

LoRA 的秩和 target 模块决定「改多少」。只改注意力里的小范围，适合调整态度和格式；改得太宽，容易把基座原有的能力带偏。截断长度也要注意：必须覆盖你样本里最长的对话，不够长会被静默截掉，训练出来像是「没学会」，其实是样本根本没喂进去。

每一步都留 checkpoint，不要只留最后一个。训练到一半发现验证集掉下去了，能回退到中间那个版本对比，比重跑一遍省事得多。

训练完别急，先导出与合并

LoRA 产出的是适配器，不是完整权重。适配器本身只是一层增量，直接丢给 Ollama 是认不了的，必须先和基座合并成一个完整的模型。这一步很多人以为是「导出」就行，实际上导出和合并是两件事。

合并的前提是基座版本和训练时用的完全一致。换一个大版本或者换一个来源的基座去合并，产出的东西大概率是坏的，而且坏得不明显——能加载、能回答，但质量就是不对。合并完的权重是原始精度，体积大，直接拿去本地推理通常跑不动，所以下一步还要量化。

• 确认合并用的基座和训练时的基座完全一致，来源、版本都要对
• 合并后先用 LLaMA-Factory 自己的推理命令跑几条测试样本，通了再进下一步
• 不要跳过本地推理验证直接去转换格式，问题会混在一起，排查更难
• 合并产物原始精度体积大，先规划好磁盘空间再执行
• 把合并用的基座信息、适配器路径、合并时间记录在一起，后面复现要用

转 GGUF：Ollama 真正吃的那一步

Ollama 走的是 llama.cpp 那条线，需要 GGUF 格式的文件。HuggingFace 那种目录结构（config、权重分片、tokenizer 一堆文件）要经过转换脚本才能变成单个 GGUF。转换脚本最好用和 llama.cpp 配套的版本，版本错配是最常见的一类报错来源，报错信息还经常不指向真正的原因。

量化档位按你的显存选。档位高了跑不动，档位低了质量掉。具体某个档位对显存和磁盘的影响，到 模型部署页面（/models/deploy） 按参数量算一遍，别凭感觉挑。转换完先用 llama.cpp 的命令行直接加载一次，确认文件本身能跑起来，再交给 Ollama。这一步是最省时间的隔离测试。

# 转换完先用 llama.cpp 命令行加载验证，确认文件本身没问题
# 具体命令按你本地的 llama.cpp 版本文档执行
./llama-cli -m /path/to/your-model.gguf -p "测试提示词" -n 128

导入 Ollama：Modelfile 与加载

到了 Ollama 这一步，Modelfile 是核心。里面最关键的两件事：FROM 指向你转好的 GGUF 文件路径，以及对话模板要和你训练时用的模板一致。模板不一致的表现很典型——模型能答，但答非所问，或者不带你要的格式。很多人这时候会误判成「微调失败了」，其实是模板没对上。

导入之后，用一段训练集之外的测试样本，对比微调前和微调后的输出。只看训练集里的样本会得出错误结论，因为训练集里的样本本来就被模型「见过」，表现好是正常的。另外上下文长度别开太大，显存不够的时候会直接加载失败，先开小一点跑通，再往上调。

1. 写 ModelfileFROM 指向 GGUF 路径，模板参数对齐训练时的对话模板
2. 执行导入用 ollama create 把 Modelfile 构建成模型，观察输出有无报错
3. 最小验证用一句简单提示词确认模型能正常加载和回复
4. 对比测试用训练集外的样本，对比微调前后的输出差异
5. 调上下文加载失败时先降上下文长度，确认能跑通再逐步加上去

验收清单与故障排查顺序

验收看三件事：格式对不对、口吻变没变、基座原有能力有没有明显退化。只看第一件容易乐观，只看第三件容易悲观，三件一起看才是完整判断。退化是常见代价，程度能不能接受取决于你的场景。

排查顺序建议从后往前：先确认 GGUF 能独立加载，再看 Modelfile 模板，再看合并版本，最后才怀疑训练本身。这个顺序的合理性在于——越靠后的环节出问题概率越高，而且验证成本越低。反过来从训练开始查，是把成本和概率都押反了。

如果排查下来发现，你要解决的其实是知识更新而不是行为对齐，那回头补数据的效果通常不如直接接检索。这是方向问题，不是微调技巧能补的。

上线前的几条实用提醒

把训练配置、数据版本、基座版本记在一起。后面换基座、复现实验、对比不同版本效果的时候，这份记录能省很多时间。微调产物体积会比基座明显变大，磁盘和备份策略提前规划，别跑完才发现盘满了。

许可证问题别忽略，基座和微调产物的商用边界可能不一样，合规的话先到 安全与合规页面（/safety） 把这条线过一遍。另外，如果你最终是要接应用而不是本地自娱，先想清楚是走 Ollama 这条线还是走推理框架那条线，两条路的取舍参考 推理部署页面（/inference）。

• 训练配置、数据版本、基座版本统一记录，复现和排障都要用
• 磁盘和备份策略提前规划，微调产物比基座大不少
• 许可证与商用边界先过一遍，别等上线才发现问题
• 明确最终跑在本地还是接应用，再决定导入哪条推理链路
• 部署方案定下来之前，去站内的部署和合规页面把当时的资料核对一遍