目前有四個開源專案主導大型語言模型微調領域：Unsloth、Axolotl、TRL 與 LLaMA-Factory。四者都封裝相同的底層 PyTorch 與 Hugging Face 技術棧，但在工程投入重點上有所不同。Unsloth 透過重寫 kernels 追求原始速度。Axolotl 專注於可組合的平行化策略。TRL 定義其他框架建構其上的 trainer API。LLaMA-Factory 則優先考量模型覆蓋廣度與零程式碼操作。

隨著 Meta、Alibaba、Google 等公司的開放權重模型縮小與專有 API 之間的品質差距，企業愈來愈傾向於在本地微調，而不是支付按 token 計費的高額成本；因此框架層成為直接影響成本的槓桿，因為 GPU 時間仍是任何客製化流程中的主要支出。

本文比較實務人員經常遇到的三個面向：訓練吞吐量、峰值 VRAM 使用量，以及多 GPU 擴展能力。

框架概覽

TRL 是參考實作層。它提供 SFTTrainer、DPOTrainer、GRPOTrainer、KTOTrainer、RewardTrainer 與 RLOOTrainer。Axolotl 與 LLaMA-Factory 內部都會呼叫它。目前穩定版本線為 v1.8.0。

Unsloth 以手寫 Triton kernels 取代部分模型程式碼。反向傳播步驟是手動推導，而不是由 autograd 產生。Hugging Face 自家的文章指出，與標準 QLoRA 相比，其準確度下降為 0%，因為沒有引入近似。

Axolotl 是一個以 YAML 驅動、封裝 Transformers、PEFT、TRL、Accelerate 與 DeepSpeed 的工具。它的關鍵差異化在於平行化策略的可組合性，而非 kernel 層級最佳化。

LLaMA-Factory 記錄於一篇 ACL 2024 系統展示論文，並包含名為 LlamaBoard 的 Gradio 網頁 UI。該儲存庫涵蓋超過 100 個 LLM 與 VLM。

速度

Unsloth：單 GPU 上的 kernel 層級收益

Unsloth 的已發布基準測試顯示，Llama 3.1 8B 與 Llama 3.3 70B 的訓練速度達到 2x。測試設定使用 Alpaca 資料集、batch size 2，以及 gradient accumulation 4。QLoRA 在所有線性層上以 rank 32 執行。

Mixture-of-Experts（MoE）模型的結果更明顯。Unsloth 在 NVIDIA B200 上微調 unsloth/gpt-oss-20b-BF16，回報在 8K context 下每步 712.33 ms，而 Transformers v5 為 5,226.86 ms，差距達 7.3x。在 4K context 下差距縮小至 4.82x，在 1K 則僅為 1.37x。

趨勢方向取決於模型。Unsloth 的 MoE 文件將這項特定聲明限定於 gpt-oss；在該模型上，速度提升會隨序列長度增加而擴大，原因歸功於 Flex Attention 與 MoE kernels。

B200 上的 Qwen3-30B-A3B 則呈現相反模式。其回報速度提升從 1K context 的 1.7x 下降至 16K 的 1.1x。記憶體節省則朝相反方向變化，從約 2% 上升至 15%。

H100 上的 Qwen3-30B-A3B 最高可達 1.77x。RTX PRO 6000 上的 GLM-4.7-Flash 達到 2.1x。與 AMD 的一項合作測得 Llama-3.1-8B LoRA SFT 為 2.07 s/step，而 TRL 加 FlashAttention-2 為 2.87 s/step；在 loss 曲線相符的情況下，差距為 1.39x。

Axolotl：借用 kernels，原生平行化

Axolotl 於 2025 年 2 月為 LoRA 加入自訂 Triton kernels 與 autograd functions，並明確提及 Unsloth 作為靈感來源。這些功能可透過 lora_mlp_kernel、lora_qkv_kernel 與 lora_o_kernel 選擇性啟用。

近期版本說明加入 SonicMoE LoRA 支援，針對單張 H100 SXM 上的 Qwen3.5-35B-A3B 8-bit LoRA，相較 grouped_mm baseline 最高提供 1.45x 加速與 30% 記憶體降低。

Axolotl 也內建 FlashAttention 2/3/4、xFormers、Flex Attention、SageAttention、Liger Kernel、Cut Cross Entropy 與 ScatterMoE。

TRL：所有人用來比較的基準

TRL 通常是參考點，而非原始單 GPU 吞吐量上的勝出者。它以廣泛的記憶體與速度控制手段補足這點，相關內容記錄於降低記憶體使用量與加速訓練。這些手段包括 packing、無 padding batching、truncation、Liger Kernel，以及用於 GRPO 的 vLLM sleep mode。TRL 也提供官方 Unsloth 整合，因此兩者並非互斥。

LLaMA-Factory：透過委派取得速度

LLaMA-Factory 不撰寫自己的 kernels。相反地，它透過設定旗標暴露其他框架的最佳化。設定 use_unsloth: true 會啟用 Unsloth patch，專案 changelog 回報該路徑帶來 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、序列長度與 optimizer 選擇都會影響實際消耗。

Context 長度是更明確的差異化因素

固定 context 長度下的峰值 VRAM，不如既定 VRAM 預算可支援的最大 context 重要。Unsloth 針對 Llama 3.1 8B QLoRA、rank 32、batch size 1 的 context 長度基準測試結果相當明顯。Unsloth 將此歸因於其 gradient checkpointing 演算法結合 Apple 的 Cut Cross Entropy。對於 80 GB A100 上的 Llama 3.3 70B，它回報可達 89,389 tokens；相較之下，FA2 baseline 為 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 context 使用 47.43 GB，而 Transformers v5 使用 73.80 GB。在 16K 時，Transformers v5 記憶體不足，Unsloth 則使用 55.13 GB。

其機制是一種 split-LoRA 公式。PEFT 會在 MoE matmul 之前，將 LoRA delta 具體化到所有 experts 上。Unsloth 則重新排序運算；數學上等價，但避免了 materialization 步驟。

Axolotl 透過 MoE expert quantization處理相同問題，在模型載入期間量化 expert 權重，並立即釋放原始 bf16 tensor。這是因為 Transformers v5 的變更：expert layers 從 nn.Linear 移至融合的 nn.Parameter 3D tensors，使 bitsandbytes 無法在載入時量化它們。Axolotl 文件回報，使用 quantize_moe_experts: true 後，GLM-4.7-Flash QLoRA 的 reserved memory 從約 127 GiB 降至約 23 GiB。

多 GPU

多 GPU 是單 GPU 排名反轉之處。Unsloth 在單 GPU 上的領先無法延續。

Axolotl：最深入的平行化矩陣

Axolotl 的多 GPU 指南提供三種互斥的 sharding 策略：DeepSpeed ZeRO stages 1 through 3、FSDP 與 DDP。FSDP2 是推薦路徑，FSDP1 已棄用。

在此之上，其 N-D Parallelism 指南透過 PyTorch 的 DeviceMesh 組合 data、tensor、context 與 expert parallelism。文件中的支援矩陣確認支援 FSDP+TP、HSDP+TP、FSDP+CP、FSDP+TP+CP 與 FSDP+EP。另有兩種組合明確不支援：expert parallelism 在 v1 中無法與 TP 或 CP 組合，純 DDP 也無法與它們組合。

Axolotl 的序列平行化使用 ring-flash-attention 函式庫。其針對 Llama 3.1 8B QLoRA 的已發布 H100 基準測試說明了取捨：context 幾乎線性擴展，但吞吐效率大幅下降。在 4090s 且 SP degree 8 的同一基準中，速度提升記錄為 0.88x；也就是訓練實際變慢，但 context 達到 32,768 tokens。

Axolotl 也透過 torchrun 與 Ray支援多節點訓練。

TRL：兩種序列切分後端

TRL 的分散式訓練指南清楚區分兩種方法。Context Parallelism 在 FSDP2 上使用 Ring Attention，需要 Accelerate 1.11.0+，使用 cp_size 與 cp_backend="torch"，目前僅支援 SDPA；此路徑不支援 FlashAttention。序列長度必須能被 cp_size * 2 整除。

Sequence Parallelism 在 DeepSpeed 上使用 ALST/Ulysses，需要 DeepSpeed 0.18.1+ 與 Accelerate 1.12.0+。它使用 sp_size 與 sp_backend="deepspeed"，並可搭配 FlashAttention-2，但受 attention head 數量限制，要求 num_heads >= sp_size。

TRL 的建議相當具體：Ring Attention 適合 1M+ token 序列與受限的網路拓撲；Ulysses 適合 NVLink 或 InfiniBand 互連，以及最長約 500k tokens 的序列。TRL 自家的 Ring Attention 基準測試在 1、2、4 與 8 張 H100 GPU 上微調 Qwen3-8B；在 8 張 GPU 時，超過 300k tokens 的 context 長度變得可訓練。

LLaMA-Factory：搭配 Megatron 的標準引擎

LLaMA-Factory 的分散式訓練文件涵蓋 DDP、DeepSpeed 與 FSDP，包括用於單節點與多節點執行的 FSDP2 與 Ray。文件也描述 DeepSpeed AutoTP，該方法將 tensor parallelism 與 ZeRO 結合。

它在 2025 年最重要的新增功能，是透過 mcore_adapter 加入 Megatron-core 訓練後端，開啟真正的大規模預訓練路徑。FSDP+QLoRA 路徑可在兩張 24 GB GPU 上微調 70B 模型；這是本比較中記錄成本最低的 70B 路徑。

摩擦點在於介面本身。分散式設定位於 YAML 與 CLI，而不是 LlamaBoard。採用 LLaMA-Factory 零程式碼 UI 的團隊，在擴展到超過一張 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 changelog描述，截至 2026 年 3 月，推論與訓練已有初步的自動多 GPU 分配。

整體來看，情況很清楚：Unsloth 支援多 GPU，但尚未提供 Axolotl 與 TRL 文件中描述的可組合平行化矩陣。

各框架的限制

當 tensor、context 或 expert parallelism 需要作為一級設定時，Unsloth 會遇到限制。若模型不在其支援清單中也會受限，因為效能收益來自架構特定 kernels。

Axolotl 的限制在學習曲線。使用者必須設定 FSDP2 與 DeepSpeed 的取捨、SP degree，以及跨 GPU 數量、序列長度與 attention heads 的整除限制。

TRL 的限制在預設值。它提供正確的 primitives，而不是已調校的設定；使用者必須自行提供 Accelerate config、記憶體最佳化與平行化計畫。

LLaMA-Factory 的限制在 UI 邊界。它的抽象在單節點內有效，但在更高層級上較薄弱。

實務選擇建議

若是在單張消費級 GPU 上、支援的架構中執行 LoRA 或 QLoRA，Unsloth 是最強選擇；僅 context 長度餘裕就足以支持這點。

若是兩到八張 GPU、長 context，以及完整微調或 RLHF pipelines，建議使用 Axolotl。FSDP2 加序列平行化是文件最完整的路徑。

若是自訂訓練迴圈、新型 post-training 演算法，或與 Hugging Face 緊密耦合，TRL 是可建構其上的基礎，因為它是其他框架封裝的那一層。

若需要最廣泛的模型覆蓋、非工程人員操作，以及最快的初次執行，LLaMA-Factory 最合適；擴展時再轉向 CLI。

這些選擇並非互斥。LLaMA-Factory 可以將 Unsloth 作為後端執行。TRL 內建 Unsloth 整合。Axolotl 內部呼叫 TRL trainers。這些框架正明顯朝彼此優勢靠攏——Unsloth 增加多 GPU、LLaMA-Factory 加入 Megatron、Axolotl 採用 kernel 層級技巧——這意味著在下一個週期中，差異化可能從原始效能轉向開發者體驗與整合廣度。

來源：MarkTechPost