llamafactory和ollama区别

很多人第一次看到这两个名字，会以为它们是同一类东西，于是在同一台机器上纠结装哪个。实际上一头是「改模型」的工具链，一头是「跑模型」的运行环境，硬拉到一个维度比较就错了。这篇按「你现在要干什么」拆开讲：什么情况下只装推理工具就够、什么时候必须上训练框架、两边能不能串成一条流水线，以及各自的硬件和许可证前提。

很多人第一次看到这两个名字，会以为它们是同一类东西，于是在同一台机器上纠结装哪个。实际上一头是「改模型」的工具链，一头是「跑模型」的运行环境，硬拉到一个维度比较就错了。这篇按「你现在要干什么」拆开讲。

判断口径其实很简单：你要问的问题里如果包含「让它更懂我的业务数据、改语气、改输出格式」，方向在微调；如果只是「在本机不联网地把模型跑起来对话、给别的程序调接口」，方向在推理。前者对应 LLaMA-Factory 这类训练框架，后者对应 Ollama 这类本地推理与服务工具。两者不是二选一，同一条流水线上常常都要走一遍。

先分清两头：一个是改权重，一个是跑权重

训练/微调框架

读入基座权重和你的数据，产出新的权重文件或适配器，交付物是模型本身

本地推理工具

把已有权重加载起来，对外提供接口或对话界面，交付物是能调用的服务

适配器

挂在基座旁边的一小份增量参数，体量远小于全量权重，便于分发和回退

承接关系要理清：训练框架不负责把模型变成日常可用的服务，推理工具也不会改你的模型。真心想改行为，用训练框架产出适配器；只想用起来，直接给推理工具一个权重。评估模型好不好用，两边都不是必需，先看站内评测页横向比更划算。

• 要改行为、改风格、改领域术语准确度：走训练框架这一侧
• 要在本机/内网把已有模型跑起来对话或供程序调用：走推理工具这一侧
• 要训练完再上线：先用训练框架产出适配器，合并后再交给推理工具加载
• 只是评估多个开源模型哪个更合适：先按站内评测页横向比，再决定要不要本地落
• 只是想省钱或图隐私把通用模型搬到本地：不涉及训练，别被「微调」两个字带偏

硬件与耗时差别：训练吃显存，推理吃吞吐

微调阶段的显存开销和训练方式、批量大小强相关，普遍高于同参数量的纯推理。具体档位按模型规模和量化方式，到 部署测算（/models/deploy） 和站内显存估算页面按当时的数字核。推理侧更在意首字延迟和每秒生成速度，量化档位可以直接换性能；训练侧量化能省显存，但会影响收敛表现，不能简单照搬推理的档位。

1. 显存不够时的下调顺序先降批量大小和序列长度，观察是否还能跑完一轮；再换 LoRA 这类参数高效方法；仍不够才降模型规模，别一上来就砍基座。
2. 验证推理侧性能用同一段提示词反复跑，记录首字延迟和生成速度；换量化档位后重测，确认能接受再固定。具体测法可参考站内工具目录里的测速工具。
3. 隔离训练与生产环境训练环境依赖多、版本敏感，尽量和生产推理环境分开；同一台机器上至少用不同的虚拟环境或容器，避免互相污染。

按场景对照：五类需求分别落到哪一边

按「你现在要干什么」对号入座，比比较工具本身有用得多。下面五类是最常见的落点，注意每类的「不需要什么」往往比「需要什么」更省时间。

• 场景 A 内网问答、数据不出机器：只装推理工具即可，知识注入交给检索方案而不是训练
• 场景 B 需要固定输出格式、固定话术风格、领域术语准确：先试提示词与检索，仍不满意再考虑小规模微调
• 场景 C 要把本地模型接进 Dify 这类应用编排平台：重点看推理工具是否暴露兼容接口、模型名能否被平台识别，和训练框架无关
• 场景 D 要训练再部署：训练与推理最好分开两台机器或两套环境，训练环境依赖多、版本敏感
• 场景 E 只是评估多个开源模型哪个好用：先按站内评测页横向比，再决定要不要本地落

不适用的情况也要说清楚：如果需求本质是「把话术固定下来」，提示词工程往往就能覆盖，不必进入训练；如果需求本质是「把资料查准」，检索方案比微调更可控，因为资料可以随时增删，不用重训。

落地前的检查项与常见返工点

选型差错的成本，多半不在装错工具，而在许可和运维没提前确认。下面这几项建议在动手前过一遍，能省掉大量来回。

1. 确认许可证边界基座权重能不能商用、微调后的权重受不受原许可证约束，这两件事要分开确认，到站内许可证对照页核对当时的条款口径。
2. 分开训练数据与推理知识库前者进了权重，改起来要重训；后者随时可增删。日常更新优先走后者，别把两条路混为一谈。
3. 列出回退方案模型换代时，训练产出的适配器往往需要重训或重新合并，提前写清楚回退到哪个基座与哪个适配器组合。
4. 按顺序排查先确认推理侧能单独跑通同一个基座，再排查训练配置，最后才怀疑数据格式，这个顺序能省掉大量来回。

一头改权重，一头跑权重；先把「你要改行为还是只想用起来」问清楚，工具选择自然就定了。