LLM微調整フレームワーク4種を比較
Unsloth、Axolotl、TRL、LLaMA-Factoryの4大オープンソースフレームワークを速度、VRAM使用量、マルチGPUスケーリングの観点から詳細に比較分析し、各ツールの技術的優位性と適したユースケースを明確にした。
キーポイント
Unsloth のカーネル最適化による劇的な速度向上
Triton カーネルの書き換えと手動導関数により、特に MoE モデルや長いコンテキスト長において最大7.3倍の高速化を達成し、精度低下なしで QLoRA を実現している。
Axolotl の並列戦略と Unsloth からの技術吸収
YAML ドライブ型の構成管理に優れ、2025年2月に Unsloth に触発されたカスタム Triton カーネルを実装し、LoRA 最適化をオプションとして提供している。
TRL の基盤層としての役割と LLaMA-Factory の網羅性
TRL は SFTTrainer や DPOTrainer など他フレームワークが依存する標準的なトレーナー API を定義しており、LLaMA-Factory は 100 以上のモデル対応とゼロコード操作に特化している。
ハードウェアとモデル構成によるパフォーマンスの多様性
Unsloth の速度向上率はモデル（Llama vs Qwen）やコンテキスト長、GPU（B200, H100, AMD など）によって大きく変動し、一律の優位性を示すものではない。
Unsloth のコンテキスト長と VRAM 効率性
Unsloth は勾配チェックポイントリングと Cut Cross Entropy を組み合わせることで、固定 VRAM 予算で他フレームワークより大幅に長いコンテキスト長（例：80GB で Llama 3.1 8B が約 34 万トークン）を処理可能である。
MoE 学習におけるメモリ最適化の仕組み
Unsloth は PEFT の標準的な実装（全エキスパートに LoRA デルタを事前展開する方式）ではなく、演算順序を再配置してデルタの展開を回避する「split-LoRA」形式を採用し、MoE モデルの学習メモリ使用量を劇的に削減している。
各フレームワークの戦略的違い
TRL は単体での速度よりも多様なメモリ最適化レバーと Unsloth 連携を強みとし、LLaMA-Factory は独自のカーネル開発ではなく Unsloth や Liger Kernel などの外部ツールを設定で呼び出すことで高速化を実現している。
重要な引用
Unsloth rewrites kernels. Axolotl composes parallelism strategies. TRL defines the trainer APIs the others build on.
Hugging Face’s own writeup notes accuracy degradation is 0% versus standard QLoRA, because no approximations are introduced.
The MoE results are larger. Unsloth fine-tuned unsloth/gpt-oss-20b-BF16 on an NVIDIA B200. It reports 712.33 ms per step at 8K context, versus 5,226.86 ms for Transformers v5.
Unsloth reorders the operations instead, which is mathematically identical but avoids the materialization.
Peak VRAM at a fixed context is less interesting than the maximum context a given VRAM budget allows.
Axolotl's docs report GLM-4.7-Flash QLoRA dropping from roughly 127 GiB to roughly 23 GiB reserved memory with quantize_moe_experts: true.
影響分析・編集コメントを表示
影響分析
この記事は、LLM のファインチューニングにおける主要なオープンソースツールの技術的差異を明確にし、エンジニアがリソース制約（VRAM）や速度要件に基づいて最適なフレームワークを選択するための決定的な指針となる。特に Unsloth のカーネル最適化技術が業界標準に与える影響と、Axolotl によるその技術の普及は、今後のファインチューニングのパフォーマンスベンチマークを再定義する可能性がある。
編集コメント
Unsloth の MoE モデルに対する7倍超の速度向上は、大規模モデルの実用的なファインチューニングにおけるボトルネック解消への大きな一歩です。ただし、Qwen や GLM モデルでのパフォーマンス差が示す通り、ハードウェアやアーキテクチャに依存する側面が強いため、導入時には自社の環境でのベンチマークが必須となります。
現在、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 をカバーしています。
(function(){
var f=document.getElementById('mtp-ft-frame');
if(!f) return;
window.addEventListener('message',function(e){
if(!e.data||typeof e.data!=='object') return;
var h=e.data.mtpFtHeight;
if(typeof h==='number'&&h>200&&h
速度比較
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 枚を超えるとスループット効率は急激に低下します。
本記事「Unsloth vs Axolotl vs TRL vs LLaMA-Factory: A Fine-Tuning Framework Comparison on Speed, VRAM, and Multi-GPU」は、MarkTechPost に掲載されたものです。
原文を表示
Four open source projects dominate LLM fine-tuning today. Unsloth, Axolotl, TRL, and LLaMA-Factory all wrap the same underlying PyTorch and Hugging Face stack. They diverge on where they spend engineering effort.
Unsloth rewrites kernels. Axolotl composes parallelism strategies. TRL defines the trainer APIs the others build on. LLaMA-Factory optimizes for breadth of model coverage and zero-code operation.
This comparison covers three axes engineers actually hit: training throughput, peak VRAM, and multi-GPU scaling.
Understand each framework
TRL is the reference implementation layer. It ships SFTTrainer, DPOTrainer, GRPOTrainer, KTOTrainer, RewardTrainer, and RLOOTrainer. Axolotl and LLaMA-Factory both call into it. The current stable release line is v1.8.0.
Unsloth replaces parts of the modeling code with hand-written Triton kernels. Backpropagation steps are manually derived rather than autograd-generated. Hugging Face’s own writeup notes accuracy degradation is 0% versus standard QLoRA, because no approximations are introduced.
Axolotl is a YAML-driven wrapper over Transformers, PEFT, TRL, Accelerate, and DeepSpeed. Its differentiator is composability of parallelism strategies, not kernel work.
LLaMA-Factory is an ACL 2024 system demonstration paper with a Gradio web UI called LlamaBoard. The repository covers 100+ LLMs and VLMs.
(function(){
var f=document.getElementById('mtp-ft-frame');
if(!f) return;
window.addEventListener('message',function(e){
if(!e.data||typeof e.data!=='object') return;
var h=e.data.mtpFtHeight;
if(typeof h==='number'&&h>200&&h
Speed
Unsloth: kernel-level gains on a single GPU
Unsloth's published benchmarks show 2x training speed for Llama 3.1 8B and Llama 3.3 70B. The setup used the Alpaca dataset, batch size 2, and gradient accumulation 4. QLoRA ran at rank 32 on all linear layers.
The MoE results are larger. Unsloth fine-tuned unsloth/gpt-oss-20b-BF16 on an NVIDIA B200. It reports 712.33 ms per step at 8K context, versus 5,226.86 ms for Transformers v5. That is a 7.3x gap. At 4K the gap is 4.82x, and at 1K it is only 1.37x.
The trend direction is model-dependent, and Unsloth's docs scope this claim to gpt-oss. There, the speedup grows with sequence length, credited to Flex Attention and the MoE kernels.
Qwen3-30B-A3B on B200 runs the other way. Its reported speedup falls from 1.7x at 1K to 1.1x at 16K. Memory savings move the opposite direction, rising from about 2% to 15%.
Qwen3-30B-A3B on H100 reaches up to 1.77x. GLM-4.7-Flash on RTX PRO 6000 reaches 2.1x. A collaboration with AMD measured Llama-3.1-8B LoRA SFT at 2.07 s/step. TRL plus FlashAttention-2 took 2.87 s/step, a 1.39x gap with matching loss curves.
Axolotl: kernels borrowed, parallelism native
Axolotl added custom Triton kernels and autograd functions for LoRA in February 2025, explicitly citing Unsloth as inspiration. They are opt-in through lora_mlp_kernel, lora_qkv_kernel, and lora_o_kernel.
Recent release notes add SonicMoE LoRA support. It delivers up to 1.45x speedup and 30% memory reduction over a grouped_mm baseline. That figure is for Qwen3.5-35B-A3B 8-bit LoRA on a single H100 SXM.
Axolotl also ships FlashAttention 2/3/4, xFormers, Flex Attention, SageAttention, Liger Kernel, Cut Cross Entropy, and ScatterMoE.
TRL: the baseline everyone measures against
TRL is usually the reference point rather than the winner on raw single-GPU throughput. It compensates with breadth of memory and speed levers documented in Reducing Memory Usage and Speeding Up Training.
Those levers include packing, padding-free batching, truncation, Liger Kernel, and vLLM sleep mode for GRPO. TRL also has a first-party Unsloth integration, so the two are not mutually exclusive.
LLaMA-Factory: speed by delegation
LLaMA-Factory does not write its own kernels. It exposes other people's work through config flags.
Setting use_unsloth: true activates the Unsloth patch. The project's changelog reports 170% relative speed from that path. Unsloth's long-sequence training is listed at 117% speed and 50% memory. It also supports enable_liger_kernel: true and FlashAttention-2 via flash_attn: fa2.
VRAM
Reported memory floors
Unsloth publishes a VRAM requirements table sorted by parameter count. It lists 6 GB for an 8B model in 4-bit QLoRA and 41 GB for 70B. LoRA at 16-bit costs 22 GB and 164 GB for the same models.
LLaMA-Factory's README hardware table covers the same regime for 4-bit QLoRA. It lists 6 GB at 7B, 24 GB at 30B, and 48 GB at 70B. Full bf16 fine-tuning of 70B is listed at 600 GB.
Both tables describe minimums. Batch size, sequence length, and optimizer choice move the real number.
Context length is the sharper differentiator
Peak VRAM at a fixed context is less interesting than the maximum context a given VRAM budget allows. Unsloth's context length benchmarks for Llama 3.1 8B QLoRA at rank 32 and batch size 1 are stark.
GPU VRAMUnsloth contextTransformers + FA2 context
8 GB2,972OOM
16 GB40,7242,551
24 GB78,4755,789
48 GB191,72815,502
80 GB342,73328,454
Unsloth attributes this to its gradient checkpointing algorithm combined with Apple's Cut Cross Entropy. For Llama 3.3 70B on an 80 GB A100, it reports 89,389 tokens. The FA2 baseline reaches 6,916.
The MoE memory story
MoE training is where memory behavior has shifted most in 2026. Unsloth reports gpt-oss-20b fine-tuning inside 12.8 GB, while Qwen3-30B-A3B at 16-bit LoRA needs 63 GB.
Its B200 gpt-oss run used 47.43 GB at 8K context where Transformers v5 used 73.80 GB. At 16K, Transformers v5 went out of memory and Unsloth used 55.13 GB.
The mechanism is a split-LoRA formulation. PEFT materializes the LoRA delta across all experts before the MoE matmul. Unsloth reorders the operations instead, which is mathematically identical but avoids the materialization.
Axolotl attacks the same problem differently. Its MoE expert quantization quantizes expert weights during model loading, freeing the original bf16 tensor immediately.
The reason is a Transformers v5 change. Expert layers moved from nn.Linear to fused nn.Parameter 3D tensors. bitsandbytes could no longer quantize them on load. Axolotl's docs report GLM-4.7-Flash QLoRA dropping from roughly 127 GiB to roughly 23 GiB reserved memory with quantize_moe_experts: true.
Multi-GPU
This is where the ranking inverts. Unsloth's single-GPU lead does not carry over.
Axolotl: the deepest parallelism matrix
Axolotl's multi-GPU guide offers three mutually exclusive sharding strategies: DeepSpeed ZeRO stages 1 through 3, FSDP, and DDP. FSDP2 is the recommended path, and FSDP1 is deprecated.
On top of those, its N-D Parallelism guide composes data, tensor, context, and expert parallelism through PyTorch's DeviceMesh. The documented support matrix confirms FSDP+TP, HSDP+TP, FSDP+CP, FSDP+TP+CP, and FSDP+EP.
Two combinations are explicitly unsupported. Expert parallelism cannot compose with TP or CP in v1. Pure DDP cannot compose with them either.
Axolotl's sequence parallelism uses the ring-flash-attention library. Its published H100 benchmark for Llama 3.1 8B QLoRA supports the tradeoff.
SP degreeMax contextContext scalingTokens/secSpeedup / GPU count
117,4081.00x9,104100.0%
234,8162.00x15,80686.8%
466,5603.82x12,31433.8%
8129,0247.41x11,09615.2%
Context scales close to linearly. Throughput efficiency collapses. On 4090s at SP degree 8, the same benchmark records 0.88x speedup. Training got slower while context reached 32,768 tokens.
Axolotl also supports multi-node training through torchrun and Ray.
TRL: two sequence-splitting backends
TRL's distributed training guide draws a clean distinction. Context Parallelism means Ring Attention on FSDP2. Sequence Parallelism means ALST/Ulysses on DeepSpeed.
Ring Attention needs Accelerate 1.11.0+, uses cp_size with cp_backend="torch", and currently supports SDPA only. FlashAttention is not supported on that path. Sequences must divide by cp_size * 2.
ALST/Ulysses needs DeepSpeed 0.18.1+ and Accelerate 1.12.0+. It uses sp_size with sp_backend="deepspeed" and works with FlashAttention-2. It is bounded by attention head count, requiring num_heads >= sp_size.
TRL's guidance is specific. Ring Attention suits 1M+ token sequences and limited network topology. Ulysses suits NVLink or InfiniBand interconnects and sequences up to roughly 500k tokens.
TRL's own Ring Attention benchmark fine-tuned Qwen3-8B across 1, 2, 4, and 8 H100 GPUs. At 8 GPUs, context lengths above 300k tokens became trainable.
LLaMA-Factory: standard engines with Megatron
LLaMA-Factory's distributed training docs cover DDP, DeepSpeed, and FSDP, including FSDP2 and Ray for single-node and multi-node runs. The docs also describe DeepSpeed AutoTP, which combines tensor parallelism with ZeRO.
Its most consequential 2025 addition was a Megatron-core training backend through mcore_adapter. That opens a genuine large-scale pretraining path.
The FSDP+QLoRA path fine-tunes a 70B model on two 24 GB GPUs. That is the cheapest documented route to 70B in this comparison.
The friction point is the interface. Distributed configuration lives in YAML and CLI, not in LlamaBoard. Dev teams that adopted LLaMA-Factory for its zero-code UI lose that property when they scale past one GPU.
Unsloth: the open gap
Unsloth's multi-GPU documentation states that multi-GPU works through Accelerate and DeepSpeed, giving access to FSDP and DDP. It also states the process is complex and requires manual setup, with official support still being announced.
The practical route is accelerate launch train.py or torchrun --nproc_per_node N_GPUS train.py. For models too large for one GPU, device_map = "balanced" splits the model across devices.
Unsloth's PyPI listing marks multi-GPU as available with major improvements pending. The Studio changelog describes preliminary automatic multi-GPU allocation for inference and training as of March 2026.
Read together, the position is clear. Unsloth supports multi-GPU. It does not yet offer the composable parallelism matrix that Axolotl and TRL document.
Where each one breaks
Unsloth breaks when you need tensor, context, or expert parallelism as first-class config. It also breaks when your model is not in its supported list, since gains come from architecture-specific kernels.
Axolotl breaks on the learning curve. You configure FSDP2 versus DeepSpeed, SP degree, and divisibility constraints. Those constraints span GPU count, sequence length, and attention heads.
TRL breaks on defaults. It gives you correct primitives, not tuned ones. You supply the Accelerate config, the memory optimizations, and the parallelism plan.
LLaMA-Factory breaks at the UI boundary. Its abstraction is excellent up to one node and thin above it.
Choosing
Single consumer GPU, supported architecture, LoRA or QLoRA: Unsloth. The context-length headroom alone justifies it.
Two to eight GPUs, long context, full fine-tuning or RLHF pipelines: Axolotl. FSDP2 plus sequence parallelism is the best-documented path.
Custom training loops, novel post-training algorithms, tight Hugging Face coupling: TRL. You are building on the layer the others wrap.
Broadest model coverage, non-engineer operators, fastest first run: LLaMA-Factory. Then move to CLI when you scale.
These choices are not exclusive. LLaMA-Factory can run Unsloth as a backend. TRL ships an Unsloth integration. Axolotl calls TRL trainers internally.
Key Takeaways
Unsloth wins single-GPU speed and context length; multi-GPU remains its documented weak point.
Axolotl ships the deepest parallelism matrix: FSDP2, DeepSpeed, TP, CP, and EP composable via DeviceMesh.
TRL is the primitive layer others wrap, now with Ring Attention and ALST/Ulysses sequence splitting.
LLaMA-Factory trades depth for breadth: 100+ models, zero-code UI, Megatron backend, CLI-only distributed setup.
Sequence parallelism scales context near-linearly but throughput efficiency drops sharply past four GPUs.
The post Unsloth vs Axolotl vs TRL vs LLaMA-Factory: A Fine-Tuning Framework Comparison on Speed, VRAM, and Multi-GPU appeared first on MarkTechPost.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み