Unsloth vs Axolotl vs TRL vs LLaMA-Factory：LLM微调框架在速度、显存和多GPU方面的对比
要点速览
- •Unsloth通过手写Triton内核在单GPU上实现最高2倍训练加速，在混合专家模型上优势更为显著，如gpt-oss-20b在8K上下文下相比Transformers v5实现了7.3倍加速。
- •Axolotl提供最全面的多GPU并行支持，通过PyTorch DeviceMesh组合数据、张量、上下文和专家并行，而Unsloth的多GPU能力仍然有限且需要手动设置。
- •LLaMA-Factory不编写自己的内核，而是通过配置标志委托其他框架的优化成果，其FSDP+QLoRA路径可在两块24 GB GPU上微调70B模型——这是本比较中文档记录的最经济路径。
- •TRL作为Axolotl和LLaMA-Factory内部调用的基础训练器API层，提供正确的原语而非调优后的默认配置，需要用户自行提供并行和内存优化方案。
- •四大框架正在明显趋同于彼此的优势——Unsloth增加多GPU支持，LLaMA-Factory集成Megatron-core后端，Axolotl采用受Unsloth启发的内核级优化。
目前有四个开源项目主导着大语言模型微调领域：Unsloth、Axolotl、TRL和LLaMA-Factory。四者均封装了相同的PyTorch和Hugging Face底层技术栈，但在工程投入的方向上各有侧重。Unsloth通过重写内核追求极致速度，Axolotl专注于可组合的并行策略，TRL定义了其他框架赖以构建的训练器API，LLaMA-Factory则优先考虑模型覆盖广度和零代码操作体验。
随着Meta、阿里巴巴、Google等公司发布的开放权重模型在质量上逐步缩小与专有API的差距，企业越来越多地选择在本地进行微调，而非支付按token计费的高昂费用——这使得框架层成为直接的成本杠杆，因为GPU时长仍然是任何定制化流程中的最大支出。
本对比从三个从业者常遇的维度进行评估：训练吞吐量、峰值VRAM占用和多GPU扩展能力。
框架概览
TRL充当参考实现层，提供SFTTrainer、DPOTrainer、GRPOTrainer、KTOTrainer、RewardTrainer和RLOOTrainer。Axolotl和LLaMA-Factory都在内部调用它。当前稳定发布线为v1.8.0。
Unsloth用手写Triton内核替换了部分建模代码。反向传播步骤采用手动推导而非自动微分生成。Hugging Face自己的文章指出，与标准QLoRA相比精度损失为0%，因为未引入任何近似处理。
Axolotl是一个基于YAML配置的封装层，构建于Transformers、PEFT、TRL、Accelerate和DeepSpeed之上。其核心差异化优势在于并行策略的可组合性，而非内核级优化。
LLaMA-Factory在一篇ACL 2024系统演示论文中有文档记录，包含一个名为LlamaBoard的Gradio Web UI。该仓库覆盖了100多个LLM和VLM。
速度
Unsloth：单GPU上的内核级增益
Unsloth的公开基准测试显示，Llama 3.1 8B和Llama 3.3 70B的训练速度达到2倍。测试使用Alpaca数据集，batch size为2，gradient accumulation为4。QLoRA在所有线性层以rank 32运行。
混合专家模型的增幅更为显著。Unsloth在NVIDIA B200上微调unsloth/gpt-oss-20b-BF16，报告8K上下文下每步712.33毫秒，而Transformers v5为5,226.86毫秒——差距达7.3倍。在4K上下文下差距缩小至4.82倍，在1K时仅为1.37倍。
趋势方向取决于模型。Unsloth的MoE文档将此声明限定于gpt-oss，在该模型上加速效果随序列长度增长，归因于Flex Attention和MoE内核。
Qwen3-30B-A3B在B200上呈现相反模式。其报告的加速比从1K上下文的1.7倍降至16K的1.1倍。内存节省方向相反，从约2%升至15%。
Qwen3-30B-A3B在H100上最高达到1.77倍。GLM-4.7-Flash在RTX PRO 6000上达到2.1倍。与AMD的合作测量Llama-3.1-8B LoRA SFT为2.07秒/步，而TRL加FlashAttention-2为2.87秒/步——差距1.39倍，且损失曲线一致。
Axolotl：借鉴内核，原生并行
Axolotl于2025年2月添加了用于LoRA的自定义Triton内核和autograd函数，明确引用Unsloth作为灵感来源。这些功能可通过lora_mlp_kernel、lora_qkv_kernel和lora_o_kernel选择启用。
近期的发布说明增加了SonicMoE LoRA支持，在单H100 SXM上对Qwen3.5-35B-A3B 8-bit LoRA实现了最高1.45倍加速和30%内存减少，基准为grouped_mm。
Axolotl还内置了FlashAttention 2/3/4、xFormers、Flex Attention、SageAttention、Liger Kernel、Cut Cross Entropy和ScatterMoE。
TRL：众人衡量的基准线
TRL通常作为参考点，而非原始单GPU吞吐量的冠军。它以在减少内存使用和加速训练中记录的丰富内存和速度调节手段来弥补。这些手段包括packing、padding-free batching、截断、Liger Kernel以及用于GRPO的vLLM睡眠模式。TRL还有官方Unsloth集成，因此两者并不互斥。
LLaMA-Factory：通过委托实现速度
LLaMA-Factory不编写自己的内核，而是通过配置标志暴露其他框架的优化成果。设置use_unsloth: true可激活Unsloth补丁，项目更新日志报告该路径带来170%的相对速度提升。Unsloth的长序列训练被列为117%速度和50%内存。LLaMA-Factory还支持enable_liger_kernel: true以及通过flash_attn: fa2启用FlashAttention-2。
VRAM
报告的内存下限
Unsloth发布了按参数量排序的VRAM需求表。4-bit QLoRA下列出8B模型需6 GB，70B需41 GB。相同模型在16-bit LoRA下分别需22 GB和164 GB。
LLaMA-Factory的README硬件表覆盖相同的4-bit QLoRA范围，列出7B为6 GB、30B为24 GB、70B为48 GB。70B的完整bf16微调列为600 GB。
两个表格描述的都是最低值。Batch size、序列长度和优化器选择都会影响实际消耗。
上下文长度是更鲜明的差异化因素
固定上下文长度下的峰值VRAM不如给定VRAM预算所允许的最大上下文长度重要。Unsloth在rank 32、batch size 1条件下对Llama 3.1 8B QLoRA的上下文长度基准测试结果十分突出。Unsloth将其归因于梯度检查点算法与Apple的Cut Cross Entropy的结合。在80 GB A100上对Llama 3.3 70B，报告支持89,389个token——而FA2基准线为6,916。
MoE内存故事
MoE训练是2026年内存行为变化最大的领域。Unsloth报告gpt-oss-20b微调仅需12.8 GB，而Qwen3-30B-A3B在16-bit LoRA下需63 GB。
在B200上的gpt-oss运行中，Unsloth在8K上下文使用47.43 GB，而Transformers v5使用73.80 GB。在16K时，Transformers v5内存溢出，而Unsloth使用55.13 GB。
其机制是split-LoRA方案。PEFT在MoE矩阵乘法之前将LoRA增量物化到所有专家上。Unsloth改为重新排列操作顺序，数学上完全等价但避免了物化步骤。
Axolotl通过MoE专家量化以不同方式解决同一问题，在模型加载时量化专家权重并立即释放原始bf16张量。这源于Transformers v5的一项变更：专家层从nn.Linear迁移到融合的nn.Parameter 3D张量，导致bitsandbytes无法在加载时量化。Axolotl的文档报告GLM-4.7-Flash QLoRA在使用quantize_moe_experts: true时，预留内存从约127 GiB降至约23 GiB。
多GPU
多GPU是单GPU排名逆转的地方。Unsloth在单GPU上的领先优势无法延续。
Axolotl：最深的并行矩阵
Axolotl的多GPU指南提供三种互斥的分片策略：DeepSpeed ZeRO阶段1至3、FSDP和DDP。FSDP2是推荐路径，FSDP1已被弃用。
在这些之上，其N-D并行指南通过PyTorch的DeviceMesh组合数据、张量、上下文和专家并行。文档化的支持矩阵确认了FSDP+TP、HSDP+TP、FSDP+CP、FSDP+TP+CP和FSDP+EP。两种组合明确不支持：专家并行在v1中无法与TP或CP组合，纯DDP也无法与它们组合。
Axolotl的序列并行使用ring-flash-attention库。其针对Llama 3.1 8B QLoRA的公开H100基准测试展示了这种权衡：上下文长度接近线性扩展，但吞吐效率急剧下降。在4090s上SP度为8时，同一基准测试记录到0.88倍加速——训练实际变慢了，而上下文达到了32,768个token。
Axolotl还通过torchrun和Ray支持多节点训练。
TRL：两种序列分割后端
TRL的分布式训练指南清晰地区分了两种方法。上下文并行使用FSDP2上的Ring Attention，需要Accelerate 1.11.0+，使用cp_size配合cp_backend="torch"，目前仅支持SDPA——该路径不支持FlashAttention。序列必须能被cp_size * 2整除。
序列并行使用DeepSpeed上的ALST/Ulysses，需要DeepSpeed 0.18.1+和Accelerate 1.12.0+。它使用sp_size配合sp_backend="deepspeed"，支持FlashAttention-2，但受注意力头数限制，要求num_heads >= sp_size。
TRL的指导很具体：Ring Attention适合1M+token序列和有限的网络拓扑，而Ulysses适合NVLink或InfiniBand互连以及约500k token以内的序列。TRL自己的Ring Attention基准测试在1、2、4和8个H100 GPU上微调Qwen3-8B，在8个GPU时可训练300k token以上的上下文长度。
LLaMA-Factory：标准引擎加Megatron
LLaMA-Factory的分布式训练文档涵盖DDP、DeepSpeed和FSDP，包括用于单节点和多节点运行的FSDP2和Ray。文档还描述了DeepSpeed AutoTP，它将张量并行与ZeRO结合。
其2025年最重要的新增是通过mcore_adapter引入的Megatron-core训练后端，开辟了真正的大规模预训练路径。FSDP+QLoRA路径可在两块24 GB GPU上微调70B模型——这是本比较中文档记录的最经济的70B路径。
摩擦点在于界面本身。分布式配置存在于YAML和CLI中，而非LlamaBoard中。因零代码UI而采用LLaMA-Factory的团队在扩展到单GPU之外时会失去这一特性。
Unsloth：待弥合的差距
Unsloth的多GPU文档指出，多GPU通过Accelerate和DeepSpeed实现，可使用FSDP和DDP。但文档同时说明该过程复杂且需要手动设置，官方支持仍在推进中。实际路径是accelerate launch train.py或torchrun --nproc_per_node N_GPUS train.py。对于单GPU无法容纳的模型，device_map = "balanced"可将模型分布到多个设备上。
Unsloth的PyPI页面将多GPU标记为可用但重大改进仍在进行中。Studio更新日志描述了截至2026年3月的推理和训练的初步自动多GPU分配功能。
综合来看，立场很明确：Unsloth支持多GPU，但尚未提供Axolotl和TRL文档中所记录的可组合并行矩阵。
各框架的局限性
当需要将张量、上下文或专家并行作为一等配置时，Unsloth会出现局限。当模型不在其支持列表中时也会受限，因为性能提升来自架构特定的内核。
Axolotl的局限在于学习曲线。用户需要配置FSDP2还是DeepSpeed、SP度以及涉及GPU数量、序列长度和注意力头数的整除约束。
TRL的局限在于默认设置。它提供正确的原语而非调优后的方案——用户需自行提供Accelerate配置、内存优化和并行计划。
LLaMA-Factory的局限在于UI边界。其抽象在单节点内表现优秀，但在此之上变得薄弱。
实用建议
对于单消费级GPU、受支持的架构、运行LoRA或QLoRA的场景，Unsloth是最佳选择——仅上下文长度的余量就足以证明这一点。
对于两到八个GPU、长上下文、完整微调或RLHF流程的场景，推荐Axolotl。FSDP2加序列并行是文档最完善的路径。
对于自定义训练循环、新型后训练算法或与Hugging Face紧密耦合的场景，TRL是构建基础，因为它是其他框架封装的底层。
对于最广泛的模型覆盖、非工程师操作人员和最快首次运行的场景，LLaMA-Factory是最佳选择——扩展时再转向CLI。
这些选择并不互斥。LLaMA-Factory可以将Unsloth作为后端运行。TRL提供Unsloth集成。Axolotl内部调用TRL训练器。各框架正在明显地趋同于彼此的优势——Unsloth增加多GPU支持、LLaMA-Factory集成Megatron、Axolotl采用内核级技巧——这表明在下一个周期中，差异化可能从原始性能转向开发者体验和集成广度。
