LLM微調整フレームワーク4種を比較

現在、LLM のファインチューニングを担うオープンソースプロジェクトの主流は 4 つです。Unsloth、Axolotl、TRL、そして LLaMA-Factory はすべて、同じ基盤となる PyTorch と Hugging Face のスタックの上に構築されていますが、それぞれのエンジニアリングリソースをどこに注力しているかが異なります。

Unsloth はカーネルの書き換えに注力し、Axolotl は並列処理戦略の組み合わせを得意としています。TRL は他者が土台として利用するトレーナー API を定義しており、LLaMA-Factory は多様なモデルへの対応と、コード不要での運用を最適化しています。

本比較では、エンジニアが実際に直面する 3 つの軸——トレーニングのスループット、ピーク時の VRAM 使用量、そしてマルチ GPU スケーリング——に焦点を当てます。

各フレームワークを理解しましょう。

TRL はリファレンス実装層です。SFTTrainer、DPOTrainer、GRPOTrainer、KTOTrainer、RewardTrainer、RLOOTrainer を提供しており、Axolotl と LLaMA-Factory の両者がこれを呼び出しています。現在の安定版リリースは v1.8.0 です。

Unsloth はモデルコードの一部を手書きの Triton カーネルに置き換えています。逆伝播の手順も自動微分（autograd）で生成されるのではなく、手動で導出されています。Hugging Face 自身の解説によると、近似処理を導入していないため、標準的な QLoRA と比較しても精度の低下は 0% です。

Axolotl は、Transformers、PEFT、TRL、Accelerate、DeepSpeed を YAML で制御するラッパーです。その強みはカーネルレベルの工夫ではなく、並列処理戦略を柔軟に組み合わせられる点にあります。

LLaMA-Factory は ACL 2024 のシステムデモンストレーション論文で発表されたシステムであり、Gradio ベースの Web UI「LlamaBoard」を搭載しています。このリポジトリは 100 以上の LLM と VLM をカバーしています。

速度比較

Unsloth: 単一 GPU でのカーネルレベルによる高速化

Unsloth が公開したベンチマークによると、Llama 3.1 8B や Llama 3.3 70B のトレーニング速度が 2 倍に向上しています。このテストでは Alpaca データセットを使用し、バッチサイズを 2、勾配累積回数を 4 に設定しました。QLoRA はすべての線形層でランク 32 を使用しています。

MoE（Mixture of Experts）モデルにおける結果はさらに顕著です。Unsloth は NVIDIA B200 で unsloth/gpt-oss-20b-BF16 のファインチューニングを行いました。その結果、7K コンテキストでの 1 ステップあたりの処理時間は 712.33 ミリ秒でした。一方、標準的な Transformers v5 では 5,226.86 ミリ秒を要しており、Unsloth は約 7.3 倍の速度差を示しています。コンテキスト長が 4K の場合は 4.82 倍、1K の場合は 1.37 倍と、短くなるほど差は縮まります。

この傾向はモデルによって異なり、Unsloth のドキュメントでもこの高速化効果は 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 が 1 ステップあたり 2.07 秒でした。これに対し、TRL に FlashAttention-2 を組み合わせた構成は 2.87 秒を要しており、損失曲線が一致する中で約 1.39 倍の差が生じています。

Axolotl: カーネルは借用、並列処理はネイティブ

Axolotl は 2025 年 2 月、LoRA のためにカスタムな Triton カーネルと自動微分関数を追加しました。これは Unsloth を明確にインスピレーション源として挙げています。これらの機能は lora_mlp_kernel、lora_qkv_kernel、lora_o_kernel という設定でオプトイン（選択的有効化）可能です。

最近のリリースノートでは、SonicMoE LoRA のサポートも追加されました。これはグループ化された行列積演算をベースラインとした場合、最大 1.45 倍の高速化と 30% のメモリ削減を実現します。この数値は、単一の H100 SXM グラフィックカード上で Qwen3.5-35B-A3B モデルを 8 ビット LoRA で学習させた場合の結果です。

また Axolotl には、FlashAttention 2/3/4、xFormers、Flex Attention、SageAttention、Liger Kernel、Cut Cross Entropy、ScatterMoE も標準搭載されています。

TRL: 比較の基準となるフレームワーク

TRL は、単一 GPU のスループットという点では勝者ではなく、むしろ比較の基準（リファレンスポイント）として使われることが多いです。その代わり、「メモリ使用量の削減」や「トレーニング速度の向上」といったドキュメントで詳しく解説された、多様な最適化レバーを備えています。

これらのレバーには、パッキング、パディングフリーバッチ処理、 truncation（切り捨て）、Liger Kernel、そして GRPO 用の vLLM スリープモードなどが含まれます。TRL は Unsloth との公式統合も提供しているため、両者は排他的な関係ではなく併用可能です。

LLaMA-Factory: 委譲による高速化

LLaMA-Factory は独自のカーネルを実装していません。代わりに、他者の成果を設定フラグを通じて公開しています。

use_unsloth: true を設定すると Unsloth のパッチが有効化されます。プロジェクトのチェンジログによると、この経路では 170% の相対的な速度向上が報告されています。また、Unsloth の長文シーケンス学習については 117% の高速化と 50% のメモリ削減が実現できるとされています。さらに enable_liger_kernel: true や flash_attn: fa2 を通じて Liger Kernel と FlashAttention-2 もサポートしています。

VRAM

報告されているメモリ使用量の下限

Unsloth は、パラメータ数別に VRAM の必要量を整理した表を公開しています。これによると、8B モデルの 4-bit QLoRA では 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）で示したコンテキスト長のベンチマークは際立っています。

GPU VRAM | Unsloth のコンテキスト長 | Transformers + FA2 のコンテキスト長

---|---|---

8 GB | 2,972 | OOM (メモリ不足)

16 GB | 40,724 | 2,551

24 GB | 78,475 | 5,789

48 GB | 191,728 | 15,502

80 GB | 342,733 | 28,454

Unsloth はこれを、勾配チェックポイントアルゴリズムと Apple の Cut Cross Entropy を組み合わせた結果だと説明しています。例えば、80 GB の A100 で Llama 3.3 70B を処理する場合、Unsloth は 89,389 トークンを扱えますが、FA2 ベースラインでは 6,916 トークンに留まります。

MoE（Mixture of Experts）のメモリ事情

2026 年において、メモリの挙動が最も劇的に変化したのが MoE のトレーニングです。Unsloth は gpt-oss-20b のファインチューニングを 12.8 GB で実行可能だと報告しています。一方、Qwen3-30B-A3B を 16-bit LoRA で学習させるには 63 GB が必要です。

Unsloth の B200 による gpt-oss の実行では、コンテキスト長 8K で 47.43 GB の VRAM を使用しました。これに対し、Transformers v5 は 73.80 GB を必要とします。さらにコンテキスト長を 16K にすると、Transformers v5 はメモリ不足で停止しましたが、Unsloth は 55.13 GB で処理を完了しています。

この仕組みは、Split-LoRA（分割 LoRA）という形式を採用しています。PEFT は MoE の行列積演算を行う前に、すべてのエキスパートに対して LoRA の差分を materialize（実体化）します。一方、Unsloth は演算順序を入れ替えることで、同じ数学的効果を実現しつつ、この materialization を回避しています。

Axolotl は、この課題に異なるアプローチで取り組んでいます。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 に劇的に削減されています。

Multi-GPU

ここからランキングの逆転が始まります。Unsloth が単一 GPU で示した優位性は、複数 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 ベンチマークでは、この機能によるトレードオフが確認されています。

SP degree（並列度）を上げるとコンテキスト長はほぼ線形に拡大しますが、スループット効率は急激に低下します。具体的には、degree が 1 の場合、コンテキスト長は 17,408 で処理速度は 9,104 トークン/秒（GPU 数あたりのスピードアップ率 1.00 倍）ですが、degree を 2 にするとコンテキスト長が 34,816 に増える一方で、処理速度は 15,806 トークン/秒に低下し、効率も 86.8% になります。さらに degree が 3.82（実質 4）になるとコンテキスト長は 69,632 近くになりますが、効率は 33.8% にまで落ち込みます。degree 8 ではコンテキスト長が約 140,000 に達しますが、処理速度は 11,096 トークン/秒となり、効率も 15.2% となります。

この傾向は RTX 4090 でも同様で、SP degree 8 の場合、スピードアップ率は 0.88 倍に留まります。コンテキスト長を 32,768 トークンまで伸ばしても、学習速度はむしろ低下してしまいます。

Axolotl はまた、torchrun や Ray を通じてマルチノードトレーニングにも対応しています。

TRL の場合、2 つのシーケンス分割バックエンドが用意されています。TRL の分散トレーニングガイドでは、明確に区別されています。「コンテキスト並列化（Context Parallelism）」は FSDP2 上での Ring Attention を指し、「シーケンス並列化（Sequence Parallelism）」は DeepSpeed 上の ALST/Ulysses を指します。

Ring Attention を利用するには、Accelerate 1.11.0 以上が必要で、cp_size パラメータと cp_backend="torch"の設定が必要です。ただし現在は SDPA（Scaled Dot Product Attention）のみがサポートされており、FlashAttention はこのパスでは使用できません。また、シーケンス長は cp_size * 2 で割り切れる必要があります。

一方、ALST/Ulysses を利用するには DeepSpeed 0.18.1 以上と Accelerate 1.12.0 以上が必要です。sp_size パラメータと sp_backend="deepspeed"の設定を行い、FlashAttention-2 と併用可能です。ただし、これはアテンションヘッド数に制限され、num_heads >= sp_size の条件を満たす必要があります。

TRL のガイダンスは非常に具体的です。Ring Attention は 100 万トークン以上のシーケンスや、ネットワークトポロジーが限定的な環境に適しています。一方、Ulysses は NVLink や InfiniBand による高速インターコネクトを備えた環境向けで、約 50 万トークンまでのシーケンスに最適化されています。

TRL が実施した Ring Attention ベンチマークでは、Qwen3-8B を 1 から 8 枚の H100 GPU にわたって微調整しました。8 枚の GPU を使用すれば、30 万トークンを超えるコンテキスト長でも学習が可能になります。

LLaMA-Factory：Megatron を備えた標準エンジン

LLaMA-Factory の分散トレーニングドキュメントには、DDP、DeepSpeed、FSDP（シングルノードおよびマルチノード対応）、さらに FSDP2 や Ray に関する記述が含まれています。また、テンソル並列性と ZeRO を組み合わせた DeepSpeed AutoTP の解説も掲載されています。

2025 年に最も重要な追加として、mcore_adapter を介した Megatron-core ベースのトレーニングバックエンドが導入されました。これにより、大規模な事前学習への道が開かれました。

FSDP と QLoRA を組み合わせたアプローチでは、70B モデルを 24GB の GPU 2 枚で微調整可能です。これは今回の比較において、70B モデルを扱うための最もコスト効率の高いルートです。

一方で課題となるのはインターフェースです。分散設定は LlamaBoard ではなく、YAML ファイルや CLI コマンドで行います。ゼロコード UI を求めて LLaMA-Factory を採用した開発チームでも、1 枚の GPU から複数枚にスケールする際にはこの特性を失ってしまいます。

Unsloth：開かれた課題

Unsloth のマルチ 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 の変更履歴によると、推論とトレーニングにおける自動マルチ GPU 割り当ての予備機能は 2026 年 3 月時点で提供開始される見込みです。

これらを総合すると、Unsloth がマルチ GPU をサポートしていることは明確ですが、Axolotl や TRL が文書化しているような「組み合わせ可能な並列性のマトリクス」はまだ提供されていません。

それぞれの限界点

Unsloth は、テンソル並列性、コンテキスト並列性、またはエキスパート並列性を第一級の設定項目として必要とする場合に機能しません。また、モデルがサポートリストに含まれていない場合も同様です。性能向上はアーキテクチャ固有のカーネルに依存しているためです。

Axolotl は学習曲線において壁にぶつかります。FSDP2 と DeepSpeed の選択、SP デグリー（並列度）、および割り当て制約の設定が必要です。これらの制約は GPU 数、シーケンス長、アテンションヘッドの数などにまたがります。

TRL はデフォルト設定で限界を迎えます。正しいプリミティブを提供しますが、チューニング済みのものではありません。ユーザー自身が Accelerate の設定、メモリ最適化手法、並列化プランを構築する必要があります。

LLaMA-Factory は UI の境界で機能しなくなります。1 ノードまでの範囲ではその抽象化は優れていますが、それを超えると薄っぺらくなります。

選び方

単一のコンシューマー GPU を使用し、サポート対象のアーキテクチャで LoRA または QLoRA を行う場合：Unsloth が最適です。コンテキスト長の余裕だけで十分価値があります。

2〜8 台の GPU を使い、長いコンテキストやフルファインチューニング、RLHF パイプラインを扱う場合：Axolotl が推奨されます。FSDP2 とシーケンス並列性の組み合わせが最も文書化された確実な道です。

カスタムトレーニングループ、新規のポストトレーニングアルゴリズム、Hugging Face への密接な連携が必要な場合：TRL を選びましょう。他のフレームワークがラップしている基盤層の上に構築する必要があるからです。

モデル対応範囲の広さ、エンジニア以外のユーザーによる操作性、初回実行までの速さを重視するなら LLaMA-Factory が最適です。規模を拡大する段階では CLI への移行を検討しましょう。

これらの選択肢は排他的ではありません。LLaMA-Factory は Unsloth をバックエンドとして利用できますし、TRL も Unsloth の統合機能を備えています。また、Axolotl は内部で TRL のトレーナーを呼び出しています。

主要なポイント

Unsloth は単一 GPU での速度とコンテキスト長の処理において優位ですが、マルチ GPU 環境についてはまだドキュメント上の弱点となっています。

Axolotl は最も深い並列化マトリクスを提供します。FSDP2、DeepSpeed、TP（テンソル並列）、CP（カーネル並列）、EP（エピソード並列）を DeviceMesh を介して柔軟に組み合わせ可能です。

TRL は他フレームワークがその上に構築する基盤層であり、現在は Ring Attention や ALST/Ulysses によるシーケンス分割機能も実装されています。

LLaMA-Factory は深さよりも広さを重視しており、100 種類以上のモデルに対応し、コード不要の UI を提供。ただし、分散設定は CLI のみとなります。

シーケンシャル並列化はコンテキスト長をほぼ線形に拡張できますが、GPU が 4 枚を超えるとスループット効率は急激に低下します。