Unsloth、Axolotl、TRL、LLaMA-Factoryを比較：LLMファインチューニングフレームワークの速度、VRAM、マルチGPU性能
重要ポイント
- •Unslothは手書きのTritonカーネルにより単一GPUで最大2倍の学習速度を実現し、gpt-oss-20bのようなMixture-of-Expertsモデルでは、8KコンテキストでTransformers v5に対して7.3倍の高速化を達成した。
- •Axolotlは最も包括的なマルチGPU並列化サポートを提供し、PyTorch DeviceMeshを通じてデータ、テンソル、コンテキスト、エキスパート並列を構成できる。一方、UnslothのマルチGPU機能はまだ限定的で、手動設定を必要とする。
- •LLaMA-Factoryは独自カーネルを書かず、設定フラグを通じて他のフレームワークに処理を委譲する。また、FSDP+QLoRA経路により、2基の24 GB GPUで70Bモデルをファインチューニングでき、本比較で文書化された最も低コストな経路となっている。
- •TRLはAxolotlとLLaMA-Factoryが内部で呼び出す基盤的なトレーナーAPI層として機能し、調整済みのデフォルトではなく正しいプリミティブを提供するため、ユーザーは並列化とメモリ最適化の設定を自ら用意する必要がある。
- •4つのフレームワークは互いの強みに収束しつつあり、UnslothはマルチGPUサポートを追加し、LLaMA-FactoryはMegatron-coreバックエンドを統合し、AxolotlはUnslothに着想を得たカーネルレベルの最適化を採用している。
現在、大規模言語モデルのファインチューニングでは、4つのオープンソースプロジェクトが主導的な位置を占めている：Unsloth、Axolotl、TRL、そしてLLaMA-Factoryだ。4つはいずれも同じPyTorchとHugging Faceの基盤スタックを包み込む形で構築されているが、エンジニアリングの注力点は異なる。Unslothは生の速度を得るためにカーネルを書き換える。Axolotlは構成可能な並列化戦略に注力する。TRLは他のフレームワークが基盤とするトレーナーAPIを定義する。LLaMA-Factoryはモデル対応範囲の広さとゼロコード運用を優先する。
Meta、Alibaba、GoogleなどのオープンウェイトモデルがプロプライエタリAPIとの品質差を縮めるなか、企業はトークン単位の高い利用料を支払うのではなく、ローカルでファインチューニングするケースを増やしている。そのため、GPU時間があらゆるカスタマイズパイプラインで支配的なコストであり続ける以上、フレームワーク層は直接的なコスト要因となる。
本比較では、実務者が日常的に直面する3つの軸、すなわち学習スループット、ピークVRAM使用量、マルチGPUスケーリングを評価する。
フレームワーク概要
TRLは参照実装レイヤーとして機能する。SFTTrainer、DPOTrainer、GRPOTrainer、KTOTrainer、RewardTrainer、RLOOTrainerを提供している。AxolotlとLLaMA-Factoryはいずれも内部でTRLを呼び出す。現在の安定版リリース系列はv1.8.0である。
Unslothは、モデリングコードの一部を手書きのTritonカーネルに置き換える。バックプロパゲーションのステップはautogradで生成されるのではなく、手動で導出される。Hugging Face自身の解説記事では、近似を導入していないため、標準QLoRAに対する精度劣化は0%だとされている。
Axolotlは、Transformers、PEFT、TRL、Accelerate、DeepSpeedの上に構築されたYAML駆動のラッパーである。主な差別化要因は、カーネルレベルの最適化ではなく、並列化戦略の構成可能性にある。
LLaMA-Factoryは、ACL 2024のシステムデモ論文で説明されており、LlamaBoardと呼ばれるGradioベースのWeb UIを備える。リポジトリは100を超えるLLMとVLMを対象としている。
速度
Unsloth：単一GPUでのカーネルレベルの向上
Unslothの公開ベンチマークでは、Llama 3.1 8BとLlama 3.3 70Bで学習速度が2倍になることが示されている。テスト設定ではAlpacaデータセット、バッチサイズ2、勾配累積4を使用した。QLoRAはすべての線形層に対してランク32で実行された。
Mixture-of-Experts（MoE）モデルでの結果はさらに顕著だ。UnslothはNVIDIA B200上でunsloth/gpt-oss-20b-BF16をファインチューニングし、8Kコンテキストで1ステップあたり712.33 msを報告した。Transformers v5は5,226.86 msであり、差は7.3倍となる。4Kコンテキストでは差は4.82倍に縮まり、1Kでは1.37倍にとどまる。
傾向の方向はモデルに依存する。UnslothのMoEドキュメントでは、この主張の範囲をgpt-ossに限定しており、そこではシーケンス長が伸びるほど高速化が大きくなるとしている。その要因はFlex AttentionとMoEカーネルにあると説明されている。
B200上のQwen3-30B-A3Bでは逆のパターンが見られる。報告された高速化は、1Kコンテキストで1.7倍から16Kで1.1倍へ低下する。メモリ削減率は逆方向に動き、約2%から15%へ上昇する。
H100上のQwen3-30B-A3Bでは最大1.77倍に達する。RTX PRO 6000上のGLM-4.7-Flashでは2.1倍に達する。AMDとの共同検証では、Llama-3.1-8B LoRA SFTが2.07 s/stepと測定された一方、TRLにFlashAttention-2を組み合わせた場合は2.87 s/stepで、損失曲線が一致した状態で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で、grouped_mmベースラインに対して最大1.45倍の高速化と30%のメモリ削減を実現するとしている。
AxolotlはFlashAttention 2/3/4、xFormers、Flex Attention、SageAttention、Liger Kernel、Cut Cross Entropy、ScatterMoEも提供する。
TRL：誰もが比較対象にするベースライン
TRLは通常、単一GPUでの生スループットで勝者になるというより、参照点として使われる。代わりに、メモリ使用量の削減と学習の高速化で説明されている幅広いメモリ・速度改善手段を備える。これらには、packing、padding-free batching、truncation、Liger Kernel、GRPO向けのvLLM sleep modeが含まれる。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とされている。
どちらの表も最小値を示している。実際の消費量は、バッチサイズ、シーケンス長、オプティマイザの選択によって変動する。
より鋭い差別化要因としてのコンテキスト長
固定コンテキスト長でのピークVRAMよりも、一定のVRAM予算で許容できる最大コンテキストの方が重要である。UnslothによるLlama 3.1 8B QLoRA、ランク32、バッチサイズ1でのコンテキスト長ベンチマークは際立っている。Unslothはこれを、同社の勾配チェックポイントアルゴリズムとAppleのCut Cross Entropyの組み合わせによるものとしている。80 GB A100上のLlama 3.3 70Bでは、89,389トークンを報告しており、FA2ベースラインの6,916と比較される。
MoEメモリの状況
2026年にメモリ挙動が最も大きく変化した領域はMoE学習である。Unslothはgpt-oss-20bのファインチューニングを12.8 GB以内で実行できると報告している一方、16-bit LoRAのQwen3-30B-A3Bには63 GBが必要だとしている。
B200上のgpt-oss実行では、Transformers v5が8Kコンテキストで73.80 GBを使用したのに対し、Unslothは47.43 GBを使用した。16KではTransformers v5がメモリ不足になった一方、Unslothは55.13 GBを使用した。
その仕組みはsplit-LoRAの定式化である。PEFTはMoE matmulの前に、すべてのエキスパートにわたってLoRAデルタを具体化する。Unslothは代わりに演算の順序を入れ替える。これは数学的には同一だが、具体化ステップを回避する。
Axolotlは同じ問題に対し、MoEエキスパート量子化で対応する。モデル読み込み時にエキスパート重みを量子化し、元のbf16テンソルを即座に解放する。この対応が必要になったのは、Transformers v5の変更により、エキスパート層がnn.Linearから融合されたnn.Parameter 3Dテンソルへ移行し、bitsandbytesが読み込み時にそれらを量子化できなくなったためである。Axolotlのドキュメントでは、quantize_moe_experts: trueによりGLM-4.7-Flash QLoRAの予約メモリが約127 GiBから約23 GiBへ低下したと報告されている。
マルチGPU
マルチGPUは、単一GPUでの順位が逆転する領域である。Unslothの単一GPUでの優位性はそのまま持ち越されない。
Axolotl：最も深い並列化マトリクス
AxolotlのマルチGPUガイドは、相互に排他的な3つのシャーディング戦略を提供する。DeepSpeed ZeROのステージ1から3、FSDP、DDPである。推奨される経路はFSDP2で、FSDP1は非推奨となっている。
これらに加えて、同社のN-D Parallelismガイドでは、PyTorchのDeviceMeshを通じてデータ、テンソル、コンテキスト、エキスパート並列を構成する。文書化されたサポートマトリクスでは、FSDP+TP、HSDP+TP、FSDP+CP、FSDP+TP+CP、FSDP+EPが確認されている。明示的にサポートされない組み合わせも2つある。v1ではエキスパート並列をTPまたはCPと組み合わせることはできず、純粋なDDPもそれらと組み合わせることはできない。
Axolotlのシーケンス並列はring-flash-attentionライブラリを使用する。Llama 3.1 8B QLoRAに関する公開H100ベンチマークは、そのトレードオフを示している。コンテキストはほぼ線形にスケールするが、スループット効率は崩れる。4090でSP degree 8の場合、同じベンチマークは0.88倍の高速化を記録しており、コンテキストが32,768トークンに達する一方で、学習自体は実際には遅くなっている。
AxolotlはtorchrunとRayによるマルチノード学習もサポートする。
TRL：2つのシーケンス分割バックエンド
TRLの分散学習ガイドは、2つのアプローチを明確に区別している。Context ParallelismはFSDP2上でRing Attentionを使用し、Accelerate 1.11.0以上を必要とし、cp_backend="torch"とともにcp_sizeを使い、現時点ではSDPAのみをサポートする。この経路ではFlashAttentionはサポートされない。シーケンスはcp_size * 2で割り切れる必要がある。
Sequence ParallelismはDeepSpeed上でALST/Ulyssesを使用し、DeepSpeed 0.18.1以上とAccelerate 1.12.0以上を必要とする。sp_backend="deepspeed"とともにsp_sizeを使い、FlashAttention-2と連携するが、アテンションヘッド数に制約され、num_heads >= sp_sizeが必要となる。
TRLのガイダンスは具体的だ。Ring Attentionは1M超のトークンシーケンスや制約のあるネットワークトポロジに適し、UlyssesはNVLinkまたはInfiniBandの相互接続と、およそ500kトークンまでのシーケンスに適している。TRL自身のRing Attentionベンチマークでは、Qwen3-8Bを1、2、4、8基のH100 GPUでファインチューニングしており、8 GPUでは300kトークンを超えるコンテキスト長が学習可能になった。
LLaMA-Factory：Megatronを備えた標準エンジン
LLaMA-Factoryの分散学習ドキュメントは、DDP、DeepSpeed、FSDPを対象としており、単一ノードおよびマルチノード実行向けのFSDP2とRayも含む。ドキュメントでは、テンソル並列とZeROを組み合わせるDeepSpeed AutoTPについても説明している。
2025年の最も重要な追加は、mcore_adapterを通じたMegatron-core学習バックエンドだった。これにより、本格的な大規模事前学習の経路が開かれた。FSDP+QLoRA経路では、2基の24 GB GPUで70Bモデルをファインチューニングできる。これは本比較で文書化されている70Bへの最も低コストな経路である。
摩擦点はインターフェースそのものにある。分散設定はLlamaBoardではなく、YAMLとCLIに存在する。ゼロコードUIを理由にLLaMA-Factoryを採用したチームは、1 GPUを超えてスケールする際にその性質を失う。
Unsloth：未解決の差分
UnslothのマルチGPUドキュメントでは、マルチGPUはAccelerateとDeepSpeedを通じて動作し、FSDPとDDPにアクセスできるとされている。ただし同時に、このプロセスは複雑で手動設定が必要であり、公式サポートはまだ告知段階だとも述べている。実用上の経路は、accelerate launch train.pyまたはtorchrun --nproc_per_node N_GPUS train.pyである。1基のGPUに収まらないモデルについては、device_map = "balanced"がモデルをデバイス間に分割する。
UnslothのPyPI掲載情報では、マルチGPUは利用可能だが大幅な改善が保留中とされている。Studioの変更履歴では、2026年3月時点で推論と学習向けの予備的な自動マルチGPU割り当てが説明されている。
総合すると、位置づけは明確である。UnslothはマルチGPUをサポートしているが、AxolotlとTRLが文書化しているような構成可能な並列化マトリクスはまだ提供していない。
各フレームワークの限界
Unslothは、テンソル、コンテキスト、エキスパート並列を第一級の設定として必要とする場合に限界がある。また、性能向上がアーキテクチャ固有のカーネルに由来するため、モデルがサポート対象リストにない場合にも制約を受ける。
Axolotlの難点は学習曲線にある。ユーザーはFSDP2とDeepSpeedの選択、SP degree、GPU数、シーケンス長、アテンションヘッドにまたがる割り切り条件を設定する必要がある。
TRLの限界はデフォルト設定にある。TRLは調整済みの設定ではなく、正しいプリミティブを提供する。ユーザーはAccelerate設定、メモリ最適化、並列化計画を自分で用意しなければならない。
LLaMA-Factoryの限界はUI境界にある。その抽象化は1ノードまでは有効だが、それを超えると薄くなる。
実務上の指針
サポート対象アーキテクチャでLoRAまたはQLoRAを実行する単一のコンシューマーGPUでは、Unslothが最も有力な選択肢である。コンテキスト長の余裕だけでも採用を正当化できる。
長いコンテキストと完全ファインチューニングまたはRLHFパイプラインを2～8基のGPUで扱う場合は、Axolotlが推奨される。FSDP2とシーケンス並列の組み合わせが、最もよく文書化された経路である。
カスタム学習ループ、新しいポストトレーニングアルゴリズム、またはHugging Faceとの密接な連携が必要な場合、TRLが構築の基盤となる。他のフレームワークが包み込んでいる層そのものだからだ。
最も広いモデル対応、エンジニア以外の運用者、最速の初回実行を重視する場合は、LLaMA-Factoryが適している。ただしスケール時にはCLIへ移行することになる。
これらの選択肢は相互排他的ではない。LLaMA-FactoryはUnslothをバックエンドとして実行できる。TRLはUnsloth統合を提供している。Axolotlは内部でTRLトレーナーを呼び出す。各フレームワークは互いの強みに明確に収束しつつある。UnslothはマルチGPUを追加し、LLaMA-FactoryはMegatronを追加し、AxolotlはUnslothに着想を得たカーネルレベルの手法を採用している。このことは、次のサイクルでは差別化の焦点が生の性能から開発者体験と統合範囲へ移る可能性を示唆している。
