7月22日、MarkTechPostが「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のスタックの上に構築されているが、エンジニアリング上の重点がまったく異なる。本記事はこの4フレームワークを速度・VRAM・マルチGPUスケーリングの3軸で実測比較した結果をまとめている。
各フレームワークの立ち位置
まず前提を整理しておく。
- TRL：
SFTTrainer、DPOTrainer、GRPOTrainerなどを提供するリファレンス実装層。AxolotlとLLaMA-FactoryはどちらもTRLを内部で呼び出している。 - Unsloth：モデリングコードの一部を手書きのTritonカーネルで置き換え、バックプロパゲーションも自動微分ではなく手動導出。近似を導入しないため、Hugging Faceの公式ブログによれば標準QLoRAと比べて精度劣化は0%とされている。
- Axolotl：YAML設定で動く並列化戦略のコンポーザ。カーネルの自作より、並列化戦略の組み合わせが差別化点。
- LLaMA-Factory：ACL 2024論文発のフレームワークで、100以上のLLM/VLMに対応。GradioベースのWeb UI「LlamaBoard」を持ち、コードなしで動かせる。
シングルGPUはUnslothが頭一つ抜ける
記事のなかで最も実務に直結するのが、コンテキスト長とVRAMの関係だ。Unslothが公開しているベンチマークは、同じVRAM予算でどれだけ長いシーケンスを扱えるかを如実に示している。
Llama 3.1 8B QLoRA（rank 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トークン |
比較対象はHugging FaceのtransformersライブラリにFlash Attention 2を組み合わせた標準構成（以下、Transformers+FA2）だ。8GBのGPUでTransformers+FA2がOOMになるところをUnslothは2,972トークン処理できる。16GBでは約16倍の差がつく。これはタイトルの「16倍差」が指しているのは学習速度ではなく、同一VRAM帯域で扱える最大コンテキスト長の比である点に注意されたい。この差はUnsloth独自のグラジェントチェックポイントアルゴリズムとAppleのCut Cross Entropyの組み合わせによるものだと記事は説明している。
学習速度の面では、Llama 3.1 8BとLlama 3.3 70BにおいてTransformers+FA2比で2倍の学習速度を報告している。MoE（Mixture of Experts）モデルではさらに差が広がる。記事ではOpenAIが公開したMoEモデルgpt-oss-20b（モデルカード参照）をNVIDIA B200で測定した結果として、8Kコンテキストで7.3倍（712ms vs 5,226ms/ステップ）という数字が示されている。ただしこのモデルは特定のアーキテクチャ上の特性を持つため、あくまでMoEモデルの代表的なケースとして受け取るのが適切だ。またこの倍率はシーケンス長とモデルアーキテクチャに強く依存し、Qwen3-30B-A3Bでは16Kコンテキストで1.1倍まで縮まる。
マルチGPUはAxolotlが本命
シングルGPUでのUnslothの優位はマルチGPU環境では逆転する。
Axolotlの並列化マトリクスは現時点で最も整備されている。DeepSpeed ZeRO（ステージ1〜3）、FSDP、DDPの3つのシャーディング戦略に加え、PyTorchのDeviceMeshを通じてデータ並列・テンソル並列・コンテキスト並列・エキスパート並列を組み合わせられる。サポートされる組み合わせはFSDP+TP、HSDP+TP、FSDP+CP、FSDP+TP+CP、FSDP+EPに及ぶ。
シーケンス並列（SP）のH100ベンチマーク（Llama 3.1 8B QLoRA）では：
| SP度数 | 最大コンテキスト | スループット効率 |
|---|---|---|
| 1 | 17,408 | 100.0% |
| 2 | 34,816 | 86.8% |
| 4 | 66,560 | 33.8% |
| 8 | 129,024 | 15.2% |
コンテキスト長はほぼ線形にスケールするが、スループット効率はSP度数4以降で急落する。4090でSP度数8にすると、コンテキストが32,768トークンに達する一方、実際の学習速度は1GPU時より遅くなる（0.88倍）。
TRLはFSDP2のRing AttentionとDeepSpeedのUlysses（ALST）という2つのシーケンス分割バックエンドを持つ。Ring Attentionは100万トークン超のシーケンスと限られたネットワークトポロジー向け、UlyssesはNVLink/InfiniBand環境で約50万トークンまでが適用範囲とされている。
UnslothのマルチGPUはAccelerateとDeepSpeedを通じて動作するが、記事は「設定が複雑で手動セットアップが必要」と明示しており、公式サポートは現在準備中の段階だと述べている。
LLaMA-Factoryは「最初の一歩」に強い
LLaMA-Factoryの強みはモデルカバレッジの広さとゼロコード操作だ。use_unsloth: trueのフラグ一つでUnslothの速度改善（170%の相対速度向上と報告）を利用でき、enable_liger_kernel: trueでLiger Kernelも有効になる。
2025年の重要な追加機能としてMegatron-coreバックエンドが加わり、大規模な事前学習への道も開かれた。またFSDP+QLoRAのパスで70Bモデルを24GBのGPU2枚でファインチューニングできるとされており、これはこの比較の中で70Bを動かす最安構成だと記事は指摘している。
ただし分散学習の設定はYAMLとCLIで行う必要があり、LlamaBoardのWeb UIは使えなくなる。
選択のガイドライン
記事がまとめた用途別の選択肢は以下のとおりだ：
- シングルコンシューマGPU + LoRA/QLoRA：Unsloth一択。コンテキスト長の余裕だけで選択理由になる。
- 2〜8GPU + 長コンテキスト + フルファインチューニングorRLHF：Axolotl。FSDP2とシーケンス並列の組み合わせが最も整備されている。
- カスタムトレーニングループ + 独自のポストトレーニングアルゴリズム：TRL。他のフレームワークが依存している層で直接作業する。
- モデルカバレッジ重視 + 非エンジニアオペレーター：LLaMA-Factory。スケールアウト時にCLIへ移行する。
なおこれらは排他的ではない。LLaMA-FactoryはUnslothをバックエンドとして動かせ、TRLもUnsloth統合を提供し、AxolotlはTRLトレーナーを内部で呼び出している。
詳細はUnsloth vs Axolotl vs TRL vs LLaMA-Factory: A Fine-Tuning Framework Comparison on Speed, VRAM, and Multi-GPUを参照していただきたい。
