Unsloth vs Axolotl vs TRL vs LLaMA-Factory: A Fine-Tuning Framework Comparison on Speed, VRAM, and Multi-GPU

在大型語言模型（LLM）微調領域，開源社群近年來湧現出四個主流的框架：Unsloth、Axolotl、TRL 與 LLaMA-Factory。這些工具雖然都建立在 PyTorch 與 Hugging Face 生態系統的基礎之上，但它們各自的工程設計取捨卻截然不同，導致在實際使用時的效能表現、記憶體佔用與多 GPU 擴展能力各具特色。業界工程師與研究人員在選擇框架時，最常關注的三個維度分別是訓練吞吐量、峰值 VRAM 使用量以及多 GPU 的擴展效率，而這四套框架正好在這三個面向展現出明顯的差異。首先，Unsloth 的核心策略在於「重寫底層運算核心」。

它不滿足於直接使用 PyTorch 或 Hugging Face 提供的標準算子，而是針對 LLM 微調常見的運算瓶頸，重新編寫了 CUDA 與 Triton 內核。這種做法讓 Unsloth 能夠在相同硬體上獲得更高的計算效率，同時降低記憶體存取次數，進而減少 VRAM 的峰值需求。對於必須在單張消費級 GPU 上微調 7B 或 13B 參數模型的開發者而言，Unsloth 往往能帶來最顯著的記憶體節省，並且在訓練吞吐量上也有一定程度的提升。相較之下，Axolotl 的設計哲學則側重於「並行策略的靈活組合」。

它並非從零開始改寫運算核心，而是提供一套高度模組化的配置系統，讓使用者可以自由調度張量並行、管線並行、資料並行以及 ZeRO 最佳化等技術。這使得 Axolotl 在多 GPU 環境下特別有優勢，因為它可以根據 GPU 數量與節點間的網路頻寬，動態調整平行化策略，以求在吞吐量與 VRAM 之間取得最佳平衡。對於需要將模型規模擴展到 70B 甚至更大參數量的團隊來說，Axolotl 的彈性往往比單純追求單卡效率的框架更具吸引力。TRL 在四者中扮演的角色較為特殊，它實際上是一個「參考實作層」。

TRL 定義了 Hugging Face Transformers 生態系統中最常用的訓練器 API，包括 PPO、DPO 以及標準的監督式微調介面。後續許多框架（包括 Unsloth 與 LLaMA-Factory 的部分功能）都是基於 TRL 的 API 進行擴展與改寫。因此，TRL 的價值在於它提供了業界公認的標準訓練流程與介面設計，讓開發者無須從頭開發強化學習或偏好最佳化的訓練邏輯。不過，TRL 在原始版本的效能最佳化上較為保守，需要使用者自行搭配其他加速庫才能達到理想的速度與記憶體表現。LLaMA-Factory 則走的是另一條路線：它極力追求「模型覆蓋的廣度」與「零程式碼操作」。

這套框架支援為數眾多的開源模型，從 LLaMA、Mistral、Qwen 到 Gemma 等，幾乎涵蓋了市面上所有主流語言模型架構。同時，LLaMA-Factory 提供了圖形化介面與命令列參數配置，讓使用者不需要撰寫任何 Python 程式碼就能完成微調任務。這對於非技術背景的 AI 應用者或需要快速驗證多種模型效果的團隊來說，大幅降低了入門門檻。然而，這種廣泛的支援性也意味著 LLaMA-Factory 無法針對特定模型進行最深層的內核最佳化，因此在極致效能與 VRAM 節省上，通常不如 Unsloth 或 Axolotl 來得突出。

從訓練吞吐量的角度來看，Unsloth 由於重寫了關鍵運算核心，在單卡或小規模多卡環境下往往能達到最高 tokens/s 輸出。但當 GPU 數量增加到八張以上時，Axolotl 的彈性並行策略可能使其總吞吐量超越 Unsloth，因為它能夠更有效地利用跨節點頻寬。TRL 若未搭配其他加速庫，吞吐量通常落在後段；而 LLaMA-Factory 的吞吐量表現則取決於所選用的底層後端，其預設配置與 Unsloth 或 Axolotl 仍有差距。

在峰值 VRAM 方面，Unsloth 的內核改寫帶來了最顯著的記憶體節省，特別是在使用 QLoRA 或 LoRA 時，它能夠將 VRAM 需求壓至極低，讓單張 24GB 的 GPU 就能微調 13B 參數模型。Axolotl 透過 ZeRO 與 offload 機制也能有效降低記憶體峰值，但需要較複雜的配置。TRL 預設的記憶體管理較為傳統，通常需要較高的 VRAM 才能運作。LLaMA-Factory 則內建了多種記憶體節省選項，如梯度檢查點與混合精度訓練，但極限值仍不如 Unsloth 優秀。

至於多 GPU 擴展效率，Axolotl 憑藉其對多種並行策略的深度支援，在 4 到 64 張 GPU 的集群中表現最為穩定。Unsloth 雖然也支援多卡訓練，但其最佳化重點在單卡內核，擴展時可能出現通信瓶頸。TRL 的多 GPU 擴展依賴於 PyTorch 的 Distributed Data Parallel 或 DeepSpeed，需要使用者自行調整參數。LLaMA-Factory 則提供了簡化的多卡配置，擴展效率介於 Axolotl 與 Unsloth 之間。值得注意的是，這四個框架並非完全互斥。

許多進階團隊會將 TRL 作為訓練 API 的基礎，再搭配 Unsloth 的內核加速或 Axolotl 的並行配置來提升效能。LLaMA-Factory 則適合快速原型開發與模型比較。選擇哪個框架，最終取決於使用者的硬體資源、模型規模、以及對開發效率與運算效能之間權衡的容忍度。總而言之，Unsloth、Axolotl、TRL 與 LLaMA-Factory 雖然都源自相同的底層技術堆疊，但各自在工程投入上的不同選擇，塑造了它們在速度、記憶體與多卡擴展上的鮮明定位。

對於追求極致單卡效率的開發者，Unsloth 是最佳夥伴；對於需要靈活擴展至大型集群的團隊，Axolotl 提供了更全面的解決方案；TRL 則是生態系統的基石，適合那些希望掌握標準 API 並自行整合其他最佳化的使用者；而 LLaMA-Factory 則以最廣的模型支援與零程式碼體驗，降低了微調的技術門檻。隨著 LLM 微調技術持續演進，這四個框架也將不斷迭代，彼此之間的界線可能日漸模糊，但當下它們各自佔據的利基，仍值得從業者仔細評估。