很多人把 LLaMA-Factory 和 Ollama 当成二选一的工具，其实它们管的是两件事：一个管把通用模型训成你自己的模型，一个管把训好的模型变成能调用的接口。这篇按「谁干什么、交界处怎么对接、哪一步最容易断」的顺序捋一遍，给一套能照着走的流程和对照表，顺便说清什么情况下这套组合并不合适。
很多人第一次接触这两个名字，会下意识把它们当成同类工具去比较，其实它们管的是完全不同的两件事。一个是把通用底座模型训成你自己的模型，另一个是把训好的模型变成能对外调用的本地接口。硬要类比的话，前者像车间，后者像门店。
所以「llama-factory与ollama」这个组合真正值得讲的不是谁更好，而是它们中间那条交接链路怎么走通、哪一步最容易断。下面按「谁干什么、交界处怎么对接、各自盯什么配置、什么情况下别用」的顺序捋一遍，你照着排查就行。
先把两个工具的角色分开：一个管训，一个管跑
分不清职责，排查问题就会乱猜。一个简单的判断口径：只要问题里出现数据集、学习率、LoRA 配置、loss 曲线，那就是训练侧的事；只要出现端口、并发、模型标签、调用地址，那就是推理侧的事。两边的日志和报错风格都不一样，先归位再动手。
- LLaMA-Factory
- 产出是一份权重目录（适配器或合并后的完整权重），强项在训练配置、数据格式和训练脚本编排，本身不提供对外的常驻服务
- Ollama
- 产出是一个本地 HTTP 服务和命令行入口，负责把已有权重加载进显存、按需切换、暴露接口，不训练也不改权重
- 共同前提
- 两边都要能读到同一份模型底座，底座对不上，后面所有参数调整都是白费
- 涉及训练数据清洗、模板字段对齐、显存占用与批量大小，归训练侧；
- 涉及模型标签命名、上下文长度设置、分层卸载开关，归推理侧；
- 两边的报错要分开看：训练侧崩多半是数据或显存，推理侧崩多半是格式或量化档位；
- 如果只是想试用别人已经发布好的模型，这两个工具其实都不用碰，直接拉一个现成标签就能跑；
- 只有当你要的是「自己的模型」而不是「别人的模型」时，这条链路才有必要走完整。
交界处：微调产出的权重怎么交给 Ollama
这条链路最容易断的地方就在交接处。训练产出的通常是 HuggingFace 格式目录，而推理侧读的是转换并量化后的格式加一份描述文件，中间必须做一次合并与转换。这一步不通，后面调参调到天亮也没用。
- 合并权重如果只训了适配器，先把适配器合并回完整权重，得到一个结构完整的目录；验证方法是尝试直接加载该目录，能正常载入说明合并没出问题。
- 转换与量化把合并后的权重转成推理侧能读的格式，并按显存选择量化档位。档位怎么取舍不要凭感觉，去 /models/deploy 按你的显卡算一遍当时的数字再定。
- 写描述文件并起标签描述文件里指向转换后的权重文件，起一个能一眼看出底座和量化档位的标签名，别用 model1、test 这种名字，以后你自己都分不清。
- 命令行先验一轮先用命令行跑一次单轮对话，确认能出正常内容；这一步过了再接接口，接口过了最后才接上层应用。
验证顺序这件事值得强调：跳过命令行直接接应用，出问题时你分不清是权重坏了、量化档位选错了，还是调用代码写错了，排查成本会翻好几倍。
不适用的情况也要说清：如果你只是做小规模适配器试验、暂时不想维护这条转换链路，可以先用训练框架自带的推理脚本看效果，确认值得上线再做转换，不必每次训练都走完整条链。
数据与配置：两端各自要盯的字段
训练侧和推理侧各有几个字段是高频翻车点。训练侧主要是字段名和序列长度，推理侧主要是上下文和显存相关开关。把它们列成清单逐条核，比事后猜问题快得多。
| 位置 | 要盯的项 | 常见翻车表现 |
|---|---|---|
| 训练侧 | 数据字段与模板是否对齐 | 字段名对不上，训练直接报错或静默学歪 |
| 训练侧 | 训练集与验证集是否真分开 | 验证指标虚高，上线效果反而差 |
| 训练侧 | 序列长度是否超出显存上限 | 中途爆显存，或者自动截断丢掉关键内容 |
| 推理侧 | 标签与量化档位是否对应 | 标签写的是高精度，实际加载的是低档位 |
| 推理侧 | 上下文长度是否覆盖实际输入 | 长输入被截断，回答答一半 |
| 推理侧 | 显存不足时的分层卸载是否开启 | 加载即失败，或首字延迟异常高 |
还有个共同的坑是版本不对齐：换了底座或者换了量化方式之后，之前调好的参数不能照搬，必须重新用极小样本跑一遍全链路验证。数据准备这块的细节，可以配合 finetune-dataset-prep 那篇一起看。
什么时候别用这套组合
这套组合很适合个人和小组做本地验证，但它有明确的边界。跨过边界还硬用，后面维护成本会盖过收益。
- 需要高并发、多副本一致性的线上服务，推理侧的单机定位不合适，选型思路可以看 vllm-vs-ollama-selection；
- 只是想要更强的模型能力、对数据不出内网没有硬性要求的，微调加本地部署的投入通常不划算，租卡与调用的分界可以看 self-host；
- 团队里没有人愿意长期维护转换脚本和版本对齐的，这条链路会变成负担，因为每次换底座都要重走一遍；
- 数据集本身没整理干净、样本量也不够的，先把数据做扎实比换工具重要，规模估算参考 fine-tune-data-sizing；
- 只是做一次性演示、不打算长期维护的，用训练侧自带推理脚本快速看效果就够了，不必接推理服务。
工具本身不难，难的是承认每一步都有它自己的验证成本。下一步想把这条链路走稳，建议先到站内模型部署与硬件对照页按你手上的卡核一遍量化档位和显存余量，再决定走不走完整流程。→
常见问题
LLaMA-Factory 和 Ollama 是不是重复的工具，选一个就行？
不重复。前者做训练，产出权重；后者做加载和对外服务，消费权重。只有在你完全不打算微调、只用别人已发布的模型时，Ollama 单独就能满足需求，这种情况才用不上 LLaMA-Factory。
微调完的模型能不能直接被 Ollama 加载？
一般不能直接加载。训练产物多为 HuggingFace 格式或适配器目录，Ollama 需要 GGUF 加 Modelfile。中间要做合并、转换、量化三步，具体档位按你的显存到 /models/deploy 算一遍再决定。
这套组合最快多久能看到效果？
取决于数据是否现成、显存是否够跑你选的模型规模。建议先把全链路用极小样本跑通一次，确认训练、转换、加载、调用四步都通，再投入时间准备完整数据集和调参，这样返工成本最低。
