关于这四者的每一篇对比，开头都是一张挂钟时间对比表；而被引用最多的那张——单张 A100 上 Unsloth 3.2 小时、LlamaFactory 3.4、Axolotl 5.8——没有原始出处、没有框架版本，而且看上去源自某家 GPU 厂商 2025 年那篇在 4090 上跑出来的博客。把它扔掉。真正能预测你未来十二个月的事实是结构性的：TRL 是训练器 API，Axolotl 与 LlamaFactory 导入它，而 Unsloth 在导入时重写它的源码。TRL 在 7 月发布了 1.9.2。另外三家里有两家仍然锁在 0.x 那条线上。
速览
四个项目，三个层级，以及一条依赖关系——它解释了人们归因于"理念不同"的大部分差异。
| 项目 | 它实际上是什么 | 它面向的 TRL | 最新版本 |
|---|---|---|---|
| TRL | 训练器 API——另外三者建立其上 | 它就是 TRL | 1.9.2，2026-07-28 |
| Axolotl | YAML／CLI 编排层 + 自己的 Triton 内核 | ==1.8.0 | 0.18.0，2026-07-17 |
| Unsloth | Triton 内核；给 transformers 打补丁、重写 TRL 源码 | <=0.24.0 | 2026.8.2，2026-08-03 |
| LlamaFactory | 零代码 CLI + Gradio 图形界面，架在 transformers／TRL 之上 | <=0.24.0 | 0.9.5，2026-05-30 |
动手之前先说两件杂务，因为这两件都会浪费你一个下午。原本位于 hiyouga/LLaMA-Factory 的仓库在 2026 年被改名为 hiyouga/LlamaFactory；旧链接仍会跳转。另外 Unsloth 有两条版本线，绝不能混为一谈——pip 库是 2026.8.2，而 GitHub 上的 v0.1.5xx-beta 标签版本化的是 Unsloth Studio，那是另一个产品。
三个层级，而非四个选项
每一个对它下面那层做了什么
TRL 是 Hugging Face 的训练器库，也是另外三者的构成材料。Axolotl 直接导入它的训练器——DPOTrainer、GRPOTrainer、KTOTrainer、RewardTrainer、vLLM 客户端——再加上一套 YAML 配置界面、一个 CLI，以及一批自己的 Triton 内核（其 LoRA 实现在注释里把思路归功于 Unsloth）。LlamaFactory 在 SFT 与奖励建模上包住 transformers.Trainer，在偏好训练阶段去取 TRL，然后在最上面盖一层 Gradio 图形界面。
Unsloth 做的是另一类事。它在导入时重新赋值 transformers 内部的函数、重写模型源码，而且——这一点值得内化——它会遍历 trl.trainer，取出每个 Trainer 类的源代码，用字符串替换打上补丁，再 exec 回去。这正是那些内核级加速的来源，也正是那些版本锁存在的原因。
版本锁就是产品决策
如果你重写另一个库的源码，你就只能支持那些你已经处理过其源码的版本。Unsloth 公布的依赖锁封顶在 trl<=0.24.0 与 transformers<=5.5.0，外加十三个单独排除的版本。LlamaFactory 同样封顶在 trl<=0.24.0。而 TRL 已经到了 1.9.2，它在 2026 年 3 月 30 日进入 1.0。Axolotl 则精确锁定 trl==1.8.0 与 transformers==5.14.1。
所以实际要问的问题不是哪个训练器最快，而是：当一个新模型家族发布、transformers 里支持到位之后，你还要等多久才能训练它？Axolotl 的答案是一次精确锁的版本提升，通常在几周内——它 2026 年的节奏大致是每月一版。Unsloth 的答案是它会直接、且往往很早地提供模型支持，但那是在它自己冻结的那份技术栈视图之上。LlamaFactory 的答案，以大约一年两次的发布节奏来看，是你可能得等着。这就是那笔交易，而且它在两个方向上都是真实的：精确锁对共享环境极不友好，你没法把 Axolotl 0.18.0 和任何需要另一个 transformers 版本的东西装在一起。
experimental 命名空间对其中一家是活着的风险
TRL 1.x 保持六个训练器为稳定态——SFT、DPO、GRPO、KTO、Reward 与 RLOO——并把一长串挪进了 trl.experimental，其中包括 ORPO、CPO、PPO、Online DPO 与 PRM。那里的稳定性契约写得很明白：该命名空间下的任何东西都可能在任意一次发布（包括补丁版本）中改变或被移除，且不作弃用预告。Axolotl 恰恰是从这个命名空间导入 ORPO、CPO 与 PRM 的。如果你在 Axolotl 上有一套生产中的 ORPO 配方，那么它离"上游一次补丁发布就挪走"只差一步，而保护着你的正是那个精确锁。
并行度这堵墙
真正逼你迁移的那根轴不是速度，而是当模型不再符合你最初假设时你所需要的并行形态。四者都做 DDP，四者也都通过 DeepSpeed ZeRO 或 FSDP 做分片数据并行。再往后它们急剧分叉，而且这种分叉是被文档写明的，不是推断出来的。
Axolotl 公布了四者中最明确的一张矩阵：FSDP2、HSDP、张量并行、上下文并行与专家并行，把有效的 2D 与 3D 组合逐一列出，把无效的组合直接抛 NotImplementedError——专家并行无法与 TP 或 CP 组合，DDP 无法与两者中任何一个组合。它还写下了一份异常长的"哪些东西不能一起用"的清单，读起来像一份陷阱清单，而它比一份特性列表值钱。TRL 通过 Accelerate 暴露张量并行，并且并排提供两套序列并行实现：跑在 FSDP2 上的 ring attention，它只支持 SDPA、不能用 Flash Attention；以及跑在 DeepSpeed 上的 ALST／Ulysses，它要求注意力头数能被并行规模整除。
LlamaFactory 在它 2026 年这条线上通过一个 HyperParallel 后端获得了张量并行与上下文并行，另有 Megatron-Core 与 Megatron-Bridge 适配器——但文档字符串把它们限定在预训练与 SFT 阶段的全量微调上，因此不支持 LoRA，也不支持任何偏好训练。Unsloth 三者皆无第一等的训练配置；它 README 里那些张量并行控制项是给 GGUF 推理用的，不是训练。
有一件事你应该听到一个措辞谨慎、而非自信满满的说法，因为各处来源之间确实相互矛盾。截至 2026 年，Unsloth 的多 GPU 支持在开源包中是存在且有文档的——通过 torchrun 做 DDP，通过 Accelerate 使用 FSDP 与 DeepSpeed；而按 rank 加载模型、每设备的 RoPE 缓存、以及感知 world size 的 GRPO 批次校验，在代码里都看得到。那段抛出"Unsloth currently does not support multi GPU setups"的老式硬拦截仍留在源码里，但给它打补丁的那个函数被注释掉了，因此它不再触发；一个仍然生效的版本只残存在一个遗留的训练辅助函数里。与此同时，厂商的定价页仍把多 GPU 列为付费档特性。两者尚未对齐——如果这个区别对你的计划要紧，先测再定。
各自真正正确的场合
在基础功能上，几家的特性差不多打平——四者都做 LoRA、QLoRA 与全量微调，四者都做 DPO 与 KTO——因此选择归结为你在边缘处需要什么。
| 如果你…… | 选 | 因为 |
|---|---|---|
| 用可验证奖励做智能体强化学习 | TRL，或 Axolotl | GRPO 在 TRL 1.x 中是稳定态并带环境集成；Axolotl 另加异步 GRPO。LlamaFactory 完全没有 GRPO——它在独立的 EasyR1 仓库里 |
| 需要在 MoE 上用 TP、CP 或专家并行 | Axolotl | 唯一把三者都作为第一等配置、并写明有效组合的项目 |
| 要把一个大模型塞进一到两张卡 | Unsloth | 那些内核工作是真的，显存下降幅度正是你接受那个版本锁的理由 |
| 想让非工程师也能发起训练 | LlamaFactory | LLaMA Board 是这里唯一成熟的训练图形界面；Unsloth Studio 还很新，且是另一种产品形态 |
| 在昇腾 NPU 上训练 | LlamaFactory | 第一等的 CANN 支持并提供预构建镜像。Axolotl 把昇腾的特性对齐列为不在范围内 |
| 需要音频或全模态微调 | LlamaFactory | 模态覆盖最广；Axolotl 自称其多模态路径为实验性、未达完整对齐 |
| 想跟上生态的节奏 | 直接用 TRL | 任何包装层按构造都落后于它，而你可以把 Liger 或 Unsloth 作为集成加进来 |
有两处锋利的边值得点名，因为它们都属于无声的那一类。Axolotl 曾有一个已于 2026 年 5 月修复的 bug：多模态训练路径对除一个模型以外的所有多模态模型，都忽略了 train_on_inputs、roles_to_train 与 train_on_eos——模型在整段对话上训练，而配置说的却是另一回事，且没有任何报错。另外，Unsloth 的许可证并不是徽章暗示的那个单一 Apache-2.0：核心包是 Apache-2.0，Unsloth Studio 是 AGPL-3.0，而承载内核与打补丁层的 unsloth_zoo 包声明的是 LGPL-3.0-or-later。如果你的法务评审假定整个项目是一个许可证，那它假定错了。
关于那张基准表
2026 年没有任何一份可信的、独立的四者正面对比发表出来。有四篇文章比较了它们；没有一篇公布配置、脚本或日志，而被引用最多的那一篇是逐字转引厂商说法，而不是自己跑了什么。那张广为流传的 A100 挂钟表没有原始归属，其最接近的祖先看上去是某家 GPU 厂商 2025 年 4 月那篇在 RTX 4090 上做的基准——一年前、不同硬件、而且是单卡，这意味着它对人们最常拿它去说的那根多 GPU 轴，什么也没说。
这个领域里文档最完整的数字来自 TRL 自己：Qwen3-8B 在一到八张 H100 上，accelerate 配置与脚本都已公布，在八卡时达到超过 30 万令牌的上下文长度。其余的一切——Unsloth 的 2 倍速度与省 70% 显存、它的 MoE 12 倍数字、以及 712 毫秒对 5,227 毫秒的 B200 单步耗时，Axolotl 的异步 GRPO 步进快 58%，LlamaFactory 那张明确标注为"估算"的整张显存需求表——都是项目自报的，且大多没有给出测试配置。这些说法未必是错的。它们只是不是你能核查的测量；而单卡上 512 令牌的 QLoRA 运行是受内核约束的，其结构性地讨好内核项目、惩罚编排层。
如果吞吐量决定你的选择，唯一站得住脚的做法是：用你自己的模型、你自己的序列长度、你自己的并行方案，在你自己的硬件上跑一个下午。这篇对比的其余部分，想告诉你的是哪个项目在六个月后仍然是一个可行的选择——而那是基准测试回答不了的问题。
常见问题
我能在 Axolotl 或 LlamaFactory 里面用 Unsloth 吗？
LlamaFactory 有一个 use_unsloth 开关，把 Unsloth 切进来作为加速后端，TRL 也提供了官方的 Unsloth 集成文档。Axolotl 则是写了自己的 Triton 内核，并把思路归功于 Unsloth。所以这些内核不止一处可达，但你会连同它们一起继承 Unsloth 的版本约束。
LlamaFactory 为什么没有 GRPO？
它的训练阶段是预训练、SFT、奖励建模、PPO、DPO 与 KTO——ORPO 与 SimPO 是作为 DPO 阶段的损失变体实现的，而不是独立的训练器。该项目对可验证奖励强化学习的答案是另一个仓库 EasyR1。如果 GRPO 是你的工作负载，这一条就是决定性的排除项。
Unsloth 现在还是一个库，还是变成一个 UI 了？
两者都是，而重心在 2026 年挪了。仓库描述与 README 现在以 Unsloth Studio 开头——一个在本地运行与训练模型的网页界面，而 pip 包被重新命名为"Unsloth Core"。这个库仍在积极开发——它在 2026 年 8 月 3 日刚发过版——但如果你上次看它是一年前，这个项目的重心已经移动了。
要为一个智能体微调模型，我该用哪个？
如果训练信号是对轨迹的可验证奖励，选 TRL 或 Axolotl，因为 GRPO 与环境集成在那里。如果你是在蒸馏一个更小的模型去承担智能体循环里的常规步骤，四者做监督微调都没问题，你应该改按运维适配度来挑。
Axolotl 的精确锁是不是意味着我不能升级 transformers？
在一个共享环境里，实际上是的——这就是精确锁的代价，也是 Axolotl 为何要提供 Docker 镜像与云端模板。它的好处是：一个给定的 Axolotl 版本具备范围锁项目所不具备的可复现性。
延伸阅读
本站相关：
- 开放权重的 RL 微调——你用这些工具究竟在做什么。
- 面向智能体的 RLVR 与 GRPO——那一列把四者之一排除掉的算法。
- 微调 vs RAG vs 提示词——你到底该不该微调。
- 提示、微调，还是 RL——在选工具之前先选干预手段。
- 面向智能体的自建推理——你刚训好的模型得跑在什么地方。