“谁最快？”这句话看起来直截了当，实际最容易把人带偏。
目前可引用的资料里，没有一组测试同时锁定基础模型、数据集、序列长度、GPU 和训练参数。RTX 4090 上跑出的单卡结果，也不能直接套到 H100 集群。与其先找速度排名，不如先看自己卡在哪一步：是单卡容易 OOM，还是团队缺少顺手的操作界面，抑或训练配置需要反复执行和追溯。
三款工具的分工其实很清楚：Unsloth 主要处理单卡速度和显存问题；LLaMA-Factory 把训练入口、组件和导出操作接到了一起；Axolotl 更方便用配置文件管理实验和多卡训练。
一张 24GB 卡，先看 Unsloth
AI2AI 的 2026 年工具对比把 Unsloth 定义为面向速度优化的微调框架。它针对关键训练路径做了专门优化，其中包括 Triton 内核。
如果手里只有一张 24GB 显存的 RTX 4090，准备做 LoRA 或 QLoRA，又经常在训练启动后遇到 OOM，Unsloth 值得先跑一次短测。需要注意，LoRA 和 QLoRA 都属于参数高效微调，不能写成全量参数微调。
速度优势还有一个前提：目标模型已经进入 Unsloth 的适配范围。碰到 Llama-4 等较新的架构，应先核对当前版本是否支持对应的模型结构、量化方式和注意力实现。通用 Hugging Face 代码能够加载模型，不代表 Unsloth 的优化路径也已经覆盖。
LLaMA-Factory 的强项，是让更多人能开跑
LLaMA-Factory 降低门槛的关键是 LLaMA Board。模型路径、JSON 数据集、学习率和 Epoch 都能在页面里配置，同时还保留了 CLI。团队成员即使不熟悉 Python，也可以参与数据检查和训练试跑。
它把 PEFT、DeepSpeed、FlashAttention 等组件放进同一套操作方式里。需要频繁更换模型和数据集时，不必每次重新拼装训练脚本。不过，WebUI 只是入口，训练速度仍会受到底层依赖、量化配置、序列长度和批次设置影响。只看页面显示的总耗时，无法判断是哪一环拖慢了训练。
Jenova 的 2026 年指南提到，LLaMA-Factory 当时在 GitHub 上已有超过 70,600 颗星标和 8,600 次复刻，亚马逊、NVIDIA 和阿里云也被列为采用者。这些信息能说明项目的使用面和关注度，但不能代替同硬件、同参数的实测。
Axolotl 的价值，在于配置能进 Git
Axolotl 把模型、数据集路径、LoRA Rank 和训练参数集中写进 .yml 文件。对已经使用 Git、Kubernetes 或 CI/CD 的团队来说，这种方式很好理解：每次改动都有差异记录，配置可以随代码一起评审，需要时也能回滚。
需要 FSDP 等分布式训练方案时，Axolotl 也更贴近日常工程习惯。是否选择它，不只取决于 GPU 数量。实验要不要重复执行、参数是否必须追溯，往往比集群规模更能影响选择。
代价同样明确。YAML 配置和报错定位要求使用者理解训练参数，第一次跑通通常不如 WebUI 直接。配置文件也不会自动处理脏数据，正式训练前仍要检查数据格式和预处理结果。
三款工具放在一起看
| 工具 | 主要侧重 | 配置入口 | 可以优先考虑的场景 | 动手前先确认 |
|---|---|---|---|---|
| LLaMA-Factory | 训练组件整合、模型覆盖、降低操作门槛 | WebUI、CLI | 快速验证、多角色协作、频繁切换模型 | 加速组件和导出格式是否匹配 |
| Unsloth | 单卡速度、显存控制 | Python API | RTX 4090 等单卡环境、LoRA/QLoRA、显存紧张 | 目标模型和量化路径是否已经适配 |
| Axolotl | 配置管理、实验追踪、分布式训练 | YAML、CLI | 参数进入 Git、重复实验、多卡训练 | 能否接受配置和调试成本 |
测速之前，先把变量锁住
要让三款工具的结果真正可比，需要固定这些条件：
- 基础模型、模型版本和 tokenizer；
- 数据集切分、对话模板和预处理方式；
- 序列长度，以及是否启用 packing；
- 训练精度、量化方式和 LoRA Rank；
- 微批次、梯度累积和优化器配置；
- GPU、驱动、CUDA、PyTorch 与注意力实现；
- 多卡测试使用的分布式策略。
记录结果时，初始化和编译耗时应与稳定训练阶段分开。可以重点看 tokens/s 或单步耗时、峰值显存、是否出现 OOM、损失曲线，以及训练后能否正常合并和导出。拿不同配置下的一张总耗时截图硬比，得不出可复用的答案。
导出失败，比训练慢更麻烦
微调结束并不等于工作完成，权重还要交给推理环境。项目如果需要 GGUF、EXL2 等格式，最好在正式训练前确认当前版本是否支持，并用小规模适配器先走一遍合并、量化和加载。
LLaMA-Factory 提供适配器合并和导出入口；使用 Unsloth 时，要确认目标架构生成的权重能够被后续推理工具识别；Axolotl 便于接入已有训练流水线，但格式转换可能仍需单独处理。不要等整轮训练结束，才发现部署端接不住权重文件。
选谁，取决于你卡在哪一步
- 只有一张 RTX 4090，显存经常不够：先确认模型兼容性，再试 Unsloth，重点记录峰值显存和稳定吞吐。
- 需要 WebUI，或者要快速试多个模型：从 LLaMA-Factory 开始，操作和协作成本更低。
- 训练参数必须进入 Git，还要重复执行或使用 FSDP：Axolotl 更符合这套工作方式。
- 暂时拿不准：使用同一份数据和参数，各跑一次短测试，再决定正式训练用哪款工具。
工具可以缩短反馈时间，却不会替你修正错误标签、混乱格式或跑偏的任务目标。先用清洗过的数据把训练、评测和导出走通，再扩大规模，比追逐一张条件不明的速度榜更稳妥。
