はじめに
2026年のLLMファインチューニングの状況は、かつてないほど高性能であると同時に断片化されています。2年前、ファインチューニングとは単一GPUでYAML設定と祈りを込めてLoRAを実行することを意味していました。今日、チームは少なくとも5つの本格的なフレームワークから選択し、それぞれが独自の設計哲学、パフォーマンス特性、エコシステム統合を持っています。フレームワークの選択は、トレーニング速度、メモリ効率、モデル品質、トレーニングパイプラインの運用複雑性に実際の影響を与えます。
このガイドでは、最も広く採用されている4つのファインチューニングフレームワーク：Axolotl、Unsloth、TorchTune、TRL（Transformer Reinforcement Learning）の徹底的で実務者向けの比較を提供します。アジアのMLコミュニティで強固な地位を確立したLLaMA-Factoryも取り上げます。各フレームワークはニッチを開拓しており、それらのニッチを理解することが情報に基づいた選択をする上で不可欠です。
この比較は、複数のモデルアーキテクチャ、GPU構成、トレーニング方法にわたる実際のトレーニング実行に基づいています。このガイドのすべてのベンチマークと設定例は、2026年初頭の時点で現在のハードウェアとソフトウェアバージョンで検証されています。
2026年のLLMファインチューニングの現状
2026年のファインチューニングは、2024年とは根本的に異なる環境で運用されています。ベースモデルはより大きく高性能になり、ファインチューニングが少ない例でも優れた結果を達成することが多くなっています。量子化対応トレーニングは、4ビットファインチューニングモデルがフル精度のモデルと競争できるまでに成熟しました。DPOやGRPOなどのポストトレーニングアライメント手法は、選好学習においてRLHFを大きく置き換え、ツールも追いついています。
ハードウェアの状況も変化しました。NVIDIAのH200とAMD MI300Xがクラウド環境で80GB以上のVRAMを利用可能にし、32GBのRTX 5090がコンシューマグレードのトレーニングカードの標準となりました。FSDPを介したマルチGPUトレーニングが、PyTorchとのより緊密な統合により、多くのワークロードでDeepSpeedを置き換えて標準的なアプローチとなりました。
モデル側では、オープンウェイトエコシステムが爆発的に成長しました。Llama 4、Mistral Large 2、Qwen 3、DeepSeek-V3はすべてファインチューニング用の強力なベースモデルを提供しています。各フレームワークのモデルサポート範囲が重要な差別化要因となっています。
フレームワーク概要
Axolotl
Axolotlはマルチメソッドファインチューニングを簡素化するコミュニティプロジェクトとして始まり、エコシステムで最も機能が充実したフレームワークに成長しました。Hugging Face TransformersとPEFTをラップし、事実上すべてのトレーニングパラメータをカバーするYAMLベースの設定システムを追加しています。Axolotlの強みは幅広さです：他のどの単一フレームワークよりも多くのトレーニング方法、モデルアーキテクチャ、データセット形式をサポートしています。
Unsloth
UnslothはAxolotlとは正反対のアプローチを取ります。Hugging Faceスタックをラップする代わりに、Tritonを使用して重要なトレーニングカーネルを再実装し、標準実装に対して2〜5倍の高速化を実現しています。単一GPUのパフォーマンスとメモリ効率に徹底的に集中し、限られたハードウェア予算で作業する実務者にとって最適なフレームワークとなっています。
TorchTune
TorchTuneはMetaの公式ファインチューニングフレームワークで、ネイティブPyTorchプリミティブの上にゼロから構築されています。可能な限り外部依存関係を避け、サードパーティライブラリの代わりにtorch.compile、DTensor、FSDP2を使用しています。これにより、PyTorchエコシステムとの最も緊密な統合と、新しいPyTorchリリースでの最も予測可能な動作を提供します。
TRL
Hugging Faceが維持するTRLは、人間のフィードバックからの強化学習および関連するポストトレーニング手法の標準ライブラリです。SFTをサポートしていますが、コアの強みはアライメントトレーニングです：DPO、GRPO、KTO、ORPO、および選好最適化手法の完全なファミリー。主要なワークロードが教師ありファインチューニングではなくアライメントである場合、TRLが自然な出発点です。
LLaMA-Factory
LLaMA-Factoryは、アクセシビリティに重点を置いたファインチューニング用のWeb UIとCLIを提供します。Hugging Face Transformersをラップし、幅広いメソッドとモデルをサポートしています。WebインターフェースによりML エンジニアリングチーム以外にもファインチューニングを民主化したいチームに人気があります。
アーキテクチャと設計哲学
これらのフレームワーク間のアーキテクチャの違いは表面的ではありません。ファインチューニング開発者体験がどうあるべきかについての根本的に異なる信念を反映しています。
Axolotlのアーキテクチャは設定駆動です。単一のYAMLファイルがベースモデル、アダプタタイプ、データセット形式、トレーニングハイパーパラメータ、ハードウェア設定のすべてを指定します。これによりAxolotlは非常に再現性が高くなります。誰かにYAMLファイルを渡せば、まったく同じトレーニング実行を再現できます。欠点は設定空間が膨大で、オプション間の関係が必ずしも明確ではないことです：
base_model: meta-llama/Llama-4-Scout-17B-16E
model_type: AutoModelForCausalLM
tokenizer_type: AutoTokenizer
load_in_4bit: true
adapter: qlora
lora_r: 32
lora_alpha: 64
lora_dropout: 0.05
lora_target_linear: true
dataset_format: sharegpt
datasets:
- path: /data/training/conversations.jsonl
type: sharegpt
conversation: chatml
sequence_len: 8192
sample_packing: true
pad_to_sequence_len: true
gradient_accumulation_steps: 4
micro_batch_size: 2
num_epochs: 3
learning_rate: 2e-4
lr_scheduler: cosine
warmup_steps: 100
optimizer: adamw_bnb_8bit
bf16: auto
tf32: true
flash_attention: true
gradient_checkpointing: true
wandb_project: llama4-finetune
wandb_run_id: scout-qlora-v1
Unslothのアーキテクチャは、アテンション、LoRAフォワードパス、損失計算の標準PyTorch実装を置き換えるカスタムTritonカーネルを中心に構築されています。APIは意図的にミニマルです：
from unsloth import FastLanguageModel
model, tokenizer = FastLanguageModel.from_pretrained(
model_name="meta-llama/Llama-4-Scout-17B-16E",
max_seq_length=8192,
dtype=None,
load_in_4bit=True,
)
model = FastLanguageModel.get_peft_model(
model,
r=32,
target_modules=["q_proj", "k_proj", "v_proj", "o_proj",
"gate_proj", "up_proj", "down_proj"],
lora_alpha=64,
lora_dropout=0,
bias="none",
use_gradient_checkpointing="unsloth",
random_state=42,
)
TorchTuneはレシピベースのアーキテクチャを使用します。各トレーニング方法は、読んで、理解して、修正できる自己完結型のPythonスクリプト（「レシピ」）です。設定はTOMLファイルを使用します：
[model]
_component_ = "torchtune.models.llama4.llama4_scout_17b_16e"
[tokenizer]
_component_ = "torchtune.models.llama4.llama4_tokenizer"
path = "/models/llama4-scout/tokenizer.model"
[dataset]
_component_ = "torchtune.datasets.chat_dataset"
source = "/data/training/conversations.jsonl"
conversation_style = "sharegpt"
[optimizer]
_component_ = "torch.optim.AdamW"
lr = 2e-4
weight_decay = 0.01
[training]
batch_size = 2
epochs = 3
gradient_accumulation_steps = 4
compile = true
TRLはHugging Face Trainerパターンに従い、各アライメント方法用の専門トレーナーで拡張しています：
from trl import SFTTrainer, SFTConfig
from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import LoraConfig
model = AutoModelForCausalLM.from_pretrained(
"meta-llama/Llama-4-Scout-17B-16E",
torch_dtype="auto",
attn_implementation="flash_attention_2",
)
training_args = SFTConfig(
output_dir="./output",
per_device_train_batch_size=2,
gradient_accumulation_steps=4,
num_train_epochs=3,
learning_rate=2e-4,
lr_scheduler_type="cosine",
warmup_steps=100,
bf16=True,
max_seq_length=8192,
packing=True,
gradient_checkpointing=True,
)
peft_config = LoraConfig(
r=32,
lora_alpha=64,
lora_dropout=0.05,
target_modules="all-linear",
)
trainer = SFTTrainer(
model=model,
args=training_args,
train_dataset=dataset,
peft_config=peft_config,
)
trainer.train()
トレーニング方法のサポート
サポートされるトレーニング方法の範囲はフレームワーク間で大きく異なります。現在のサポートマトリクスは以下の通りです：
SFT（Supervised Fine-Tuning）は5つすべてのフレームワークでサポートされています。これは最低要件です。違いは各フレームワークがSFTをどれだけ効率的に実装するか、特にサンプルパッキング、シーケンス並列処理、メモリ最適化に関して現れます。
DPO（Direct Preference Optimization）はTRL、Axolotl、LLaMA-Factoryで完全にサポートされています。TorchTuneは2025年末にDPOサポートを追加しました。UnslothはTRL統合レイヤーを通じてDPOをサポートしています。
GRPO（Group Relative Policy Optimization）はDeepSeekの研究に続いて推論モデル向けの好まれるアライメント手法として台頭しました。TRLが最も成熟したGRPO実装を持っています。AxolotlはTRL委任を通じてサポートしています。TorchTuneは2026年初頭からネイティブGRPOを提供しています。
PPOを使用したRLHFはTRLで引き続きサポートされていますが、ほとんどのユースケースで好まれなくなりました。PPOトレーニングループの複雑さと不安定さがDPOとGRPOを魅力的な代替手段にしました。
QAT（Quantization-Aware Training）はPyTorchの量子化プリミティブを通じてTorchTuneでネイティブにサポートされています。Unslothはカスタムカーネルを通じてQATをサポートしています。AxolotlとTRLはbitsandbytesおよびGPTQとの統合を通じてQATをサポートしています。
単一GPUパフォーマンス比較
単一GPUパフォーマンスは、フレームワーク間で最も劇的な違いが見られる領域です。同じデータセット、ハイパーパラメータ、ハードウェア（NVIDIA A100 80GB）を使用して、Llama 3.1 8B QLoRAファインチューニングで4つすべてをベンチマークしました。
トレーニング設定：QLoRA r=32、シーケンス長4096、バッチサイズ2、勾配蓄積4、1000ステップ、BF16精度。
Unslothは一貫して最速の単一GPUトレーニングを提供し、同じ設定でTRLの通常2〜3倍高速です。高速化は3つのソースから来ています：複数の操作を単一のGPUカーネルランチに統合するフューズドTritonカーネル、フルランク中間テンソルの実体化を避けるカスタムLoRA実装、および再計算を削減する最適化されたグラディエントチェックポインティング実装です。
torch.compileを有効にしたTorchTuneは、より長いトレーニング実行でTRLに対して約1.5倍の高速化を達成しますが、コンパイルステップで数分の起動オーバーヘッドが追加されます。30分未満の短いファインチューニング実行では、このコンパイルコストがランタイムの改善を相殺する可能性があります。
Axolotlのパフォーマンスは、同じ基盤のHugging Faceトレーニングループを使用しているため、同等の設定ではTRLと本質的に同一です。Axolotlの価値は生の速度ではなく設定の利便性にあります。
メモリ効率も同様のパターンに従います。Unslothのカスタムカーネルは、標準実装と比較してピークメモリ使用量を30〜50%削減し、他のフレームワークがグラディエントオフロードやより大きなカードを必要とする場合でも、単一GPUでのトレーニングを可能にすることがよくあります。
マルチGPUスケーリング
マルチGPUトレーニングでは状況が変わります。TorchTuneはPyTorchのFSDP2とDTensorプリミティブ上に直接構築されているため、最も強力なマルチGPUストーリーを持っています：
tune run --nproc_per_node 8 full_finetune_distributed \
--config llama4_scout/17B_full.toml
TRLとAxolotlはFSDPまたはDeepSpeedをラップするHugging Face Accelerateを分散トレーニングに使用します：
accelerate launch --num_processes 8 \
--mixed_precision bf16 \
--use_fsdp \
--fsdp_sharding_strategy FULL_SHARD \
train.py
UnslothのマルチGPUサポートは歴史的に最も弱い領域でした。カスタムTritonカーネルは単一GPU実行用に設計されており、2025年と2026年を通じてマルチGPUサポートは改善されましたが、代替手段よりも多くの手動設定が必要です。
複数ノードにわたる大規模トレーニング実行では、TorchTuneとTRL/AxolotlのDeepSpeed統合が最も実戦で検証されたオプションです。TorchTuneの利点は、Accelerate、DeepSpeed、Transformers間で時々発生するバージョン互換性の問題を回避できることです。
設定と開発者体験
開発者体験は初期設定を超えて、デバッグ、再現性、新しいチームメンバーの学習曲線にまで及びます。
AxolotlのYAML設定は同時にその最大の強みであり弱みでもあります。単一のYAMLファイルがトレーニング実行を完全に指定し、再現を容易にします。しかし、YAMLファイルは数百行に膨れ上がる可能性があり、あまり一般的でないオプションのドキュメントは時々不完全です。設定の問題をデバッグすることはGitHubのissueを検索することを意味することが多いです。
Unslothは最もPython的な体験を提供します。設定がコードであるため、IDEがオートコンプリートと型チェックを提供します。PyTorchに慣れた人にとって学習曲線は緩やかです。欠点は、再現性が宣言的な設定ファイルではなくPythonスクリプトの共有を必要とすることです。
TorchTuneはTOML設定とレシピアーキテクチャで中間点を見つけています。レシピは実行可能なコードとドキュメントの両方として機能する読みやすいPythonファイルです。何か問題が発生した場合、レシピのソースコードを読んで実行フローを理解できます。この透明性は、トレーニングプロセスを理解し修正する必要があるチームにとって価値があります。
TRLは馴染みのあるHugging Face Trainerパターンに従います。チームがすでに推論とデータ処理にHugging Faceを使用している場合、TRLは最も少ない新しい学習を必要とします。TrainingArgumentsパターンはよくドキュメント化されており、広く理解されています。
メモリ最適化テクニック
メモリ効率は、手持ちのハードウェアでトレーニングできるかどうかを決定します。各フレームワークは異なるテクニックを提供します：
# Unsloth: automatic memory-efficient LoRA
model = FastLanguageModel.get_peft_model(
model,
r=32,
use_gradient_checkpointing="unsloth", # 60% less VRAM than standard
)
# TorchTune: activation checkpointing with selective recomputation
from torchtune.training import ActivationCheckpointing
model = ActivationCheckpointing(model, checkpoint_every_n_layers=2)
グラディエントチェックポインティングは普遍的にサポートされていますが、実装は異なります。Unslothの実装は最もメモリ効率が高く、最もコストの低い操作のみを選択的に再計算します。TorchTuneの実装は最も設定可能で、レイヤーレベルの粒度を許可します。
CPUオフロードはオプティマイザ状態をCPU RAMに移動し、トレーニング速度を犠牲にしてGPUメモリ要件を劇的に削減します。TRLとAxolotlはDeepSpeed ZeRO Stage 3を通じてこれをサポートしています：
{
"zero_optimization": {
"stage": 3,
"offload_optimizer": {
"device": "cpu",
"pin_memory": true
},
"offload_param": {
"device": "cpu",
"pin_memory": true
}
}
}
量子化オプティマイザは標準Adamをメモリのごく一部を使用する8ビットまたは4ビットバリアントに置き換えます。すべてのフレームワークがbitsandbytesの8ビットAdamをサポートしています。Unslothはさらにカスタム量子化オプティマイザ実装を提供します。
いつ何を使うか：判断マトリクス
フレームワークの選択は、ベンチマークのヘッドラインではなく、具体的な要件によって決定されるべきです。
単一GPUで作業し、最大のトレーニング速度とメモリ効率が必要な場合はUnslothを選択してください。個人の実務者、小規模チーム、コンシューマハードウェアや単一クラウドGPUでトレーニングするあらゆるシナリオでUnslothが明確な勝者です。RTX 4090や単一A100でQLoRAを実行する場合、Unslothが最速で目標に到達させてくれます。
最も緊密なPyTorch統合でマルチGPUフルファインチューニングが必要な場合はTorchTuneを選択してください。大規模トレーニングジョブを実行し、PyTorchバージョン間の再現性が必要で、外部依存関係を最小化したいチームに適しています。MetaのLlamaモデルのファインチューニングにも最適で、新しいLlamaアーキテクチャに対するファーストパーティサポートを受けられます。
主要なワークロードがアライメントトレーニング（DPO、GRPO、KTO、ORPO）の場合はTRLを選択してください。TRLは選好最適化手法の最も成熟した完全な実装を持っています。ワークフローがHugging Faceエコシステムに深く統合されている場合も自然な選択です。
単一ツールで最大の柔軟性が必要な場合はAxolotlを選択してください。Axolotlは他のどのフレームワークよりも多くのモデルアーキテクチャ、トレーニング方法、データセット形式をサポートしています。多くの異なるモデルをトレーニングし、単一の一貫したインターフェースが必要なチームに適しています。
非MLエンジニアにファインチューニングジョブを実行させる必要がある場合はLLaMA-Factoryを選択してください。Web UIが参入障壁を大幅に下げ、CLIはスクリプト化されたワークフローに簡単です。
データセットの準備とフォーマット処理
ファインチューニングフレームワークを選択する際に最も過小評価される側面の1つは、データセットの準備をどのように処理するかです。実世界のトレーニングデータは乱雑で、一貫性がなく、フレームワークがそのまま期待する正確な形式であることはめったにありません。
AxolotlはShareGPT、Alpaca、OpenAIチャット完了、カスタムフィールドマッピング付きJSONL、生の完了形式を含む12以上のデータセット形式をサポートしてここで優れています。データセット前処理パイプラインがトークン化、チャットテンプレート適用、サンプルパッキングを1パスで処理します：
datasets:
- path: /data/sharegpt_conversations.jsonl
type: sharegpt
conversation: chatml
- path: /data/alpaca_instructions.jsonl
type: alpaca
- path: /data/completions.jsonl
type: completion
field_instruction: prompt
field_output: response
TRLは標準のHugging Face datasetsライブラリを使用し、メッセージ配列を持つ会話形式のデータを期待します。カスタム形式の変換には前処理関数の記述が必要です：
from datasets import load_dataset
def format_conversations(example):
messages = []
for turn in example["conversation"]:
messages.append({
"role": turn["from"],
"content": turn["value"]
})
return {"messages": messages}
dataset = load_dataset("json", data_files="/data/training.jsonl")
dataset = dataset.map(format_conversations)
Unslothはデータセットの処理をユーザーに委任し、一般的な形式用のヘルパー関数を提供しますが、前処理は自分で行うことを期待しています。これは、より多くのボイラープレートコードのコストで最大の柔軟性を提供します。
TorchTuneは一般的な形式用のデータセットビルダーを提供し、データセット構築における型安全性を重視しています。データセットクラスがトレーニング前に各例の構造を検証し、長いトレーニング実行中ではなく早期にフォーマットの問題を検出します。
複数の短い例を単一のシーケンスに連結してGPU利用率を最大化するサンプルパッキングは、可変長の例を持つデータセットの重要な最適化です。AxolotlとTRLはサンプルパッキングをネイティブにサポートしています。Unslothは独自の最適化されたパッキングアルゴリズムを実装しています。TorchTuneは2025年半ばにサンプルパッキングを追加し、クロスサンプルアテンションマスキングなどのエッジケースを正しく処理します。
トレーニング中の評価とベンチマーキング
トレーニング中のモデル品質の評価は、過学習の検出、最適なチェックポイントの選択、実行の比較に不可欠です。各フレームワークはトレーニング中の評価に異なるアプローチを取ります。
TRLは、評価データセット、カスタムメトリクスコールバック、自動ベストチェックポイント選択をサポートするHugging Face Trainer上に構築されているため、最もシームレスな評価統合を提供します：
from trl import SFTConfig
training_args = SFTConfig(
output_dir="./output",
evaluation_strategy="steps",
eval_steps=100,
save_strategy="steps",
save_steps=100,
load_best_model_at_end=True,
metric_for_best_model="eval_loss",
per_device_eval_batch_size=4,
)
AxolotlはYAML設定を通じて評価頻度、メトリクス選択、チェックポイント管理の類似オプションで評価をサポートしています。評価メトリクスに基づく早期停止もサポートしています：
eval_steps: 100
save_steps: 100
eval_batch_size: 4
early_stopping_patience: 5
load_best_model_at_end: true
TorchTuneのレシピアーキテクチャは、評価ロジックがレシピPythonファイル自体に存在することを意味し、どのメトリクスがいつ計算されるかを完全に制御できます。カスタム評価ロジックの追加、ベンチマークスイートの実行、トレーニング中のサンプル出力の生成も可能です：
# Inside a TorchTune recipe
if step % eval_interval == 0:
model.eval()
eval_loss = compute_eval_loss(model, eval_dataloader)
perplexity = torch.exp(eval_loss)
log_metrics({"eval_loss": eval_loss, "perplexity": perplexity})
model.train()
Unslothには組み込みの評価フックが含まれておらず、ユーザーが外部で評価を実装するか、TRLの評価インフラストラクチャが適用されるTRL SFTTrainer内でUnslothを使用することに依存しています。
アライメントトレーニングに特化して言えば、評価は損失曲線よりもニュアンスがあります。TRLはDPOトレーニング中にリファレンスモデルに対する勝率評価をサポートし、アラインされたモデルが意図した方向に改善されているかの直接的な指標を提供します。
プロダクション展開の考慮事項
ファインチューニングは、結果のモデルが確実に展開できる場合にのみ価値があります。各フレームワークはエクスポートと展開について異なるストーリーを持っています。
すべてのフレームワークは標準的なHugging Faceモデル形式をエクスポートし、vLLM、TGI、またはHugging Faceモデルハブ形式をサポートする推論フレームワークで提供できます。LoRAアダプタは展開前にベースモデルにマージするか、動的アダプタローディングをサポートするフレームワークを使用して別々に提供できます。
Unslothはllama.cppおよびOllama展開用の最適化されたGGUFエクスポートを提供します：
model.save_pretrained_gguf(
"output_model",
tokenizer,
quantization_method="q4_k_m"
)
TorchTuneはモバイルおよびエッジ展開用にExecuTorchと統合されており、展開ターゲットがクラウドサーバーを超える場合にユニークな利点です。
プロダクショントレーニングパイプラインでは、トレーニングワークフローのコンテナ化を検討してください：
docker run --gpus all -v /data:/data -v /models:/models \
axolotl-train:latest \
accelerate launch -m axolotl.cli.train /data/config.yaml
フレームワーク、PyTorch、CUDAツールキットのバージョンを固定してください。トレーニング結果はバージョン間で大きく異なる可能性があり、環境間の非再現性のデバッグはML運用における最も時間のかかる問題の1つです。
どのフレームワークを選択しても、初日から実験追跡に投資してください。Weights and Biases、MLflow、あるいは構造化されたログディレクトリでさえ、トレーニング実行間で結果を比較する必要がある際に何時間もの混乱を節約してくれます。すべてのフレームワークがW&B統合をサポートしており、キャプチャされるメタデータ（設定、ハードウェア、トレーニング曲線、評価メトリクス）は、モデル品質とトレーニング効率に関する情報に基づいた決定を下すために不可欠です。