LabHub

ブログ

LLMファインチューニングフレームワーク2026 — Axolotl / Unsloth / LLaMA-Factory / TRL / PEFT / TorchTune 徹底ガイド

2026-05-16 · 37 分で読めます · #llm#finetuning#axolotl#unsloth#llama-factory#trl#peft#torchtune#mosaicml#llm-foundry#modal#dpo#grpo#kto#qlora#fsdp#deepspeed#deep-dive#japanese

한국어English日本語

プロローグ — なぜ再びファインチューニングなのか

2025年初頭までは「ファインチューニングはもう終わった」という声が時折流れていた。GPT-4o・Claude 3.5・Gemini 1.5がコンテキスト1Mを超え、RAGとfew-shotでほぼすべてが解けるように見えたからだ。ところが2025年後半から雰囲気が変わった。DeepSeek R1のGRPO論文、MetaのLLaMA 3.3 / 4 リリース、そして7Bほどの小さなモデルをドメインに合わせてチューニングすればGPT-4より安く速く動かせるという事例が積み重なり、「ファインチューニングは再び一軍ツール」へと戻ってきた。

2026年5月時点の風景はこうだ。

この記事は12〜14章でその地図を描く。誰が何を得意としていて、自分たちの状況で何を選ぶべきかを整理する。

1章 · 2026年LLMファインチューニング地図 — 3 陣営

ツールを一列に並べると比較が難しい。3つの陣営に分けてみよう。

陣営代表ツール主な利用者
オープンソースフレームワークAxolotl, Unsloth, LLaMA-Factory, TRL, PEFT, TorchTune, LLM Foundry学術/スタートアップ/個人
クラウドファインチューニングAPIOpenAI, Anthropic, Cohere, Together, Modal, Fireworksエンタープライズ/プロダクトチーム
垂直統合 / ファンデーションラボUpstage, Sakana, Mistral, Cohere Labs, OpenAI Custom Models研究所/メーカー/R AND D 主導スタートアップ

この分類は完璧ではない。例えばTogetherはクラウドAPIでありながらLoRAファインチューニングをオープンソーススタックとほぼ同じ形で公開している。Modalはクラウド GPU を貸すだけのインフラに近い。それでも、この3陣営を頭に置いてツールを見ると、選択の軸が見える。

オープンソースフレームワーク陣営は「GPUさえあれば全部こちらで」という立場。Axolotl・Unsloth・LLaMA-FactoryはYAML/configファイル一枚で学習パイプラインを定義させ、その中でPEFT(アダプタ)・TRL(RL)・Accelerate(分散)がライブラリとして呼び出される。

クラウドAPI陣営は「データを渡せばGPU・チューニング・サービングまで全部やる」という立場。OpenAI・Anthropic・Cohereは自社モデルだけをチューニングし、Together・Modal・Fireworksはオープンモデル(Llama・Qwen・DeepSeek・Mistral)をチューニングさせる。

ファンデーションラボ陣営は自社モデルを作りながら、その上にドメインファインチューニングも併売するところ。韓国のUpstage、日本のSakana・ELYZA・PFN、米国のMistral・Cohereがここに座っている。

2026年のトレンドは この3陣営がお互いの領域へ侵食している ことだ。OpenAIがReinforcement Fine-Tuning(RFT)を公開し、AnthropicがConstitutional Finetuningを露出させ、Togetherが自前クラスタを増強し、Upstageがグローバル市場へSaaSで進出して、境目が曖昧になっている。

2章 · なぜファインチューニング? — RAG vs Finetuning vs Few-shot 決定表

ファインチューニングのツールを見る前に、「今ファインチューニングをすべきか」をまず問う必要がある。決定表はこう描ける。

状況おすすめ理由
最新事実/文書が頻繁に変わるRAGインデックスのみ更新、モデル再学習不要
出力フォーマット/スタイルの一貫性が必要Finetuning (SFT)システムプロンプトでは100%一貫しない
特定ドメイン語彙/略語Finetuning (SFT) + RAGモデルは表現、RAGは事実
人の選好(丁寧さ・安全性)を反映DPO / GRPO / KTOペア/スカラー選好データで学習
入力あたりのコスト・遅延を下げるFinetuning(小型)7BチューニングはGPT-4呼び出しより安くなる
1週間以内にPoC完了Few-shot プロンプティング学習しない、即座に検証
コード/数学のように思考が長くなるGRPO + RL強化学習で推論能力が深まる
データが100件未満Few-shot もしくは PEFT の小さい r小データはLoRA r=4–8で十分
データが100k件以上Full SFT もしくは LoRA r=64+大容量はフルチューンか大きいアダプタ
会社IPのモデルを作るセルフホスト + Axolotl/LLM Foundryモデル重みを自分で持つ

核となる3原則。

  1. 事実はRAG、振る舞いはファインチューニング。 モデルが「何を知っているべきか」はRAG、「どう振る舞うべきか」はファインチューニング。
  2. SFT先、RL後。 どんなRLアルゴリズムもシードSFT無しでは上手くいかない。SFTで安定領域へ持っていってから、DPO/GRPO/KTOを重ねる。
  3. 小さいモデルで素早く検証。 7B のLoRAチューニングは1〜2時間で終わる。小さく速く回してから、70Bへスケールする。

この原則を持ってツールへ入っていく。

3章 · PEFT — LoRA / QLoRA / AdaLoRA / IA3 基礎

PEFT(Parameter-Efficient Fine-Tuning)は「全重みを学習せず、小さなアダプタだけを差し込んで学習しよう」というアイデアの総称。2021年Microsoftの LoRA 論文に始まり、2026年現在は事実上の標準になった。

LoRA(Low-Rank Adaptation)。 大きな重み行列 W に小さな2つの行列 A・B を加え、A・B のみを学習する。r=8/16/32 のような小さなrankでもフルチューン近い品質が出る、というのが核。重み更新量が1/100〜1/1000に減り、メモリ・ディスクも一緒に減る。

QLoRA。 Tim Dettmers の 2023 年論文。ベースモデルを4-bitに量子化したままLoRAだけ16-bitで学習する。70Bモデルを単一のA100 80GB一枚に載せてチューニングできるようにした決定的な技法。NF4(NormalFloat 4)量子化 + double quantization + paged optimizer が要。

AdaLoRA。 rank を学習中に動的に調整。重要なレイヤーには大きい r、重要でないレイヤーには小さい r を自動配分。Microsoft Researchの成果。

IA3(Infused Adapter by Inhibiting and Amplifying Inner Activations)。 LoRAより更に少ないパラメータ(レイヤーあたりベクター3つ)だけを学習。100件未満の極小データセットでLoRAより安定すると言われている。

DoRA(Weight-Decomposed Low-Rank Adaptation)。 2024年NVIDIAが提案。重みをmagnitudeとdirectionに分解し、directionだけをLoRAで学習する。フルチューンにより近い品質。

2026年の実務デフォルトはこうだ。

PEFTライブラリ自体はHugging Faceが作っており、ほぼすべてのフレームワーク(Axolotl・Unsloth・LLaMA-Factory・TRL・TorchTune)が内部でPEFTを呼ぶ。つまりPEFTは「土台」で、フレームワークがその上に乗る。

4章 · Axolotl — もっとも人気あるオープンソース

Axolotlは OpenAccess AI Collective が作り始め、2024年に会社化(Axolotl AI)されたオープンソースのファインチューニングフレームワーク。2025年シードラウンドを取り、GitHub スター9千超え。一言で言えば「YAML config 一枚で Llama・Mistral・Qwen・DeepSeek といったオープンモデルをフルチューン/LoRA/QLoRA/DPOで学習できるラッパー」。

なぜ Axolotl が1位になったか。 3つの決断が決定的だった。

  1. YAML config 中心。 データセット・モデル・ハイパーパラメータ・分散戦略を一つの YAML に束ねた。1コマンドで学習が回る。
  2. 全アルゴリズム対応。 SFT, LoRA, QLoRA, DPO, ORPO, KTO, GRPO, Reinforcement Learning, Continual Pretraining まで一つで。PEFT・TRL・Accelerate・DeepSpeedを内部から呼ぶ。
  3. フォーマット自動変換。 ShareGPT・Alpaca・ChatML・OpenAIなどのデータセットフォーマットを自動認識して変換する。

基本利用例。

# axolotl-llama3-lora.yml
base_model: meta-llama/Llama-3.1-8B-Instruct
load_in_4bit: true
adapter: qlora
lora_r: 16
lora_alpha: 32
lora_dropout: 0.05
lora_target_modules:
  - q_proj
  - v_proj
  - k_proj
  - o_proj
datasets:
  - path: tatsu-lab/alpaca
    type: alpaca
sequence_len: 4096
val_set_size: 0.05
num_epochs: 3
optimizer: adamw_torch
learning_rate: 0.0002
gradient_accumulation_steps: 4
micro_batch_size: 2
flash_attention: true
deepspeed: deepspeed_configs/zero2.json

これ一つで LLaMA 3.1 8B を Alpaca データセットで QLoRA 学習する。実行は axolotl train axolotl-llama3-lora.yml の一行。

Axolotlが得意なこと。

弱点。

Axolotlを選ぶとき。

5章 · Unsloth — 2倍速いQLoRA

Unsloth はオーストラリアの兄弟 Daniel と Michael Han が作ったファインチューニングライブラリ。2024年シードラウンドを取り、GitHub スター1.5万超え。スローガンは「2x faster, 50% less memory」。実際に同じGPUで同じデータを学習すると、Axolotlより1.5〜2倍速く、メモリを30〜50%少なく使う。

どうしてここまで速いのか。 UnslothはPyTorchの通常autogradを使わず、学習hot pathの中核演算(LoRAのforward/backward, RoPE, RMSNorm, SwiGLU など)を直接Tritonカーネルで書いた。メモリ割り当てもPyTorchデフォルトより攻撃的に再利用する。Unsloth Gradient Checkpointing という独自実装は PyTorch のデフォルトよりさらに 30% のメモリ節約を行う。

基本利用例。

from unsloth import FastLanguageModel
from trl import SFTTrainer
from transformers import TrainingArguments

model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="unsloth/llama-3.1-8b-instruct-bnb-4bit",
    max_seq_length=4096,
    dtype=None,
    load_in_4bit=True,
)

model = FastLanguageModel.get_peft_model(
    model,
    r=16,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
    lora_alpha=32,
    use_gradient_checkpointing="unsloth",
)

trainer = SFTTrainer(
    model=model,
    train_dataset=dataset,
    tokenizer=tokenizer,
    args=TrainingArguments(
        per_device_train_batch_size=2,
        gradient_accumulation_steps=4,
        warmup_steps=10,
        num_train_epochs=3,
        learning_rate=2e-4,
        fp16=not torch.cuda.is_bf16_supported(),
        bf16=torch.cuda.is_bf16_supported(),
        output_dir="outputs",
    ),
)
trainer.train()

Hugging Face TRLの SFTTrainer をそのまま使い、モデルロードだけを Unsloth で行う。だから既存のTRLコードとの互換性が良い。

Unslothが得意なこと。

弱点。

Unsloth を選ぶとき。

6章 · LLaMA-Factory — 使いやすい中国発フレームワーク

LLaMA-Factoryは中国・北京航空航天大学(Beihang University)のチームが始めたオープンソースのファインチューニングフレームワーク。2023年公開、2026年5月時点でGitHubスター4万5千超え。英語圏ではAxolotlほど知られていないが、中国・東アジアのユーザーベースが圧倒的に大きい。

なぜ LLaMA-Factory なのか。 3つの差別化ポイントがある。

  1. Web UI 提供。 llamafactory-cli webui 一行でブラウザからモデル・データセット・ハイパーパラメータを選んで学習を始められる。CLI/YAMLが負担なユーザーに最も親切。
  2. 膨大なモデルサポート。 Llama・Mistral・Qwen・DeepSeek・ChatGLM・Yi・InternLM・Baichuan — 中国モデルカバレッジが圧倒的。
  3. アルゴリズム整合性。 SFT, Reward Model, PPO, DPO, ORPO, KTO, SimPO, BAdam を一つのツールで。RLHFフルパイプラインを最も簡単に回せる。

基本利用例(CLI)。

llamafactory-cli train \
    --stage sft \
    --do_train True \
    --model_name_or_path meta-llama/Llama-3.1-8B-Instruct \
    --dataset alpaca_en \
    --template llama3 \
    --finetuning_type lora \
    --lora_target q_proj,v_proj \
    --output_dir saves/llama3-8b/lora/sft \
    --overwrite_output_dir True \
    --per_device_train_batch_size 2 \
    --gradient_accumulation_steps 4 \
    --lr_scheduler_type cosine \
    --learning_rate 5e-5 \
    --num_train_epochs 3.0 \
    --warmup_ratio 0.1

この一行でLLaMA 3.1 8Bを alpaca で LoRA SFT チューニングする。Web UIで同じオプションをフォーム入力でも可。

LLaMA-Factory が得意なこと。

弱点。

LLaMA-Factory を選ぶとき。

7章 · Hugging Face TRL — RL + DPO/GRPO/KTO

TRL(Transformer Reinforcement Learning)はHugging Faceが管理するRL/選好最適化ライブラリ。2022年lvwerraのプロトタイプから始まり、2024年Hugging Faceのメインラインアップ入りした。2026年5月時点GitHubスター1万2千。

TRLは「フレームワーク」というより「ライブラリ」だ。Axolotl・Unsloth・LLaMA-Factoryが内部でTRLを呼ぶ。TRLを直接使うのは、通常はアルゴリズム研究者かカスタム学習ループが必要な人。

TRL がサポートするトレーナーたち。

トレーナーアルゴリズム用途
SFTTrainerSupervised Fine-Tuning教師あり学習(chat/instruction tuning)
RewardTrainerPairwise reward modelRLHFのRMフェーズ
PPOTrainerProximal Policy OptimizationクラシックRLHF(InstructGPTスタイル)
DPOTrainerDirect Preference Optimizationペア選好データを直接学習
GRPOTrainerGroup Relative Policy OptimizationDeepSeek R1 スタイルの RL
KTOTrainerKahneman-Tversky Optimization良い/悪い 二値信号で学習
ORPOTrainerOdds Ratio Preference OptimizationSFT + DPO を一気に統合
CPOTrainerContrastive Preference OptimizationDPO 変形、安定性強化
IPOTrainerIdentity Preference OptimizationDPO のオーバーフィット補正

TRL + vLLM の RL 加速。 2025年の大きな変化は TRL に vLLM 統合が入ったこと。GRPO/PPOは学習中にモデルが応答を生成する必要があるが(rollout)、デフォルトのtransformers生成は遅すぎる。vLLMがその位置を埋めて、RL学習が5〜10倍速くなった。Axolotl・LLaMA-Factoryもこの統合をそのまま活用する。

基本利用例(DPO)。

from trl import DPOTrainer, DPOConfig
from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-3.1-8B-Instruct")
tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-3.1-8B-Instruct")

trainer = DPOTrainer(
    model=model,
    args=DPOConfig(
        output_dir="dpo-llama",
        beta=0.1,
        learning_rate=5e-7,
        num_train_epochs=1,
        per_device_train_batch_size=2,
    ),
    train_dataset=dataset,
    tokenizer=tokenizer,
)
trainer.train()

TRLを直接使うとき。

8章 · PEFT (HF) — アダプタ標準

PEFTライブラリはHugging Faceが管理するアダプタ標準。LoRA・QLoRA・AdaLoRA・IA3・LoHa・LoKr・OFT・VeRA・DoRA・X-LoRAを一つのインタフェースに束ねた。2026年5月時点GitHubスター1万7千。

ほぼ全てのファインチューニングフレームワークが内部でPEFTを呼ぶ。Axolotl・Unsloth・LLaMA-Factory・TRL・TorchTuneが独自LoRAを別実装せず、PEFTを標準として受け入れる。つまりアダプタフォーマット(adapter_config.json + adapter_model.safetensors)が互換なので、Axolotlで学習したLoRAをvLLM・Unsloth・TGI・Togetherでそのままロードできる。

PEFTの中核抽象。

from peft import LoraConfig, get_peft_model
from transformers import AutoModelForCausalLM

model = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-3.1-8B")
config = LoraConfig(
    r=16,
    lora_alpha=32,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM",
)
peft_model = get_peft_model(model, config)
peft_model.print_trainable_parameters()
# trainable params: 6,815,744 || all params: 8,037,261,312 || trainable%: 0.0848

このモデルをそのままTRLのSFTTrainer/DPOTrainerに入れればLoRAだけが学習される。

最近の追加。 2025年PEFT 0.10系で入った変化は2つ。

  1. VeRA(Vector-based Random Matrix Adaptation)。 LoRAより10倍少ないパラメータで同等の性能。多タスク学習に適する。
  2. X-LoRA(Mixture-of-Experts LoRA)。 複数のLoRAを学習しておき、入力ごとにルーターがどのアダプタを使うかを決める。マルチドメインモデルに有利。

ディスク/メモリ効率。 8Bモデルのフルチューン重みは16GB(bf16)だが、LoRA r=16 アダプタは30MB程度。アダプタ50個をサーバーに載せておきリクエストごとにhot swapするパターンが2025年に本格化した。Mistral・Together・Anthropic の Custom Models が同じアイデアを使う。

9章 · TorchTune — PyTorch 公式

TorchTuneはPyTorchチームが直接作る公式ファインチューニングライブラリ。2024年1.0リリース、2026年5月時点GitHubスター5千。他のフレームワークより後発だが、「PyTorchネイティブ、外部依存最小」という哲学が明確。

TorchTune のデザイン哲学。

基本利用例。

# プリビルトの recipe を使う
tune run lora_finetune_single_device \
    --config llama3_2/8B_lora_single_device

# 自前 recipe を書く
tune ls  # 利用可能な recipe 一覧
tune cp llama3_2/8B_lora_single_device my_recipe.yaml
# my_recipe.yaml を編集後
tune run lora_finetune_single_device --config my_recipe.yaml

TorchTune が得意なこと。

弱点。

TorchTuneを選ぶとき。

10章 · LLM Foundry (MosaicML → Databricks)

LLM FoundryはMosaicMLが作り、2023年Databricksが13億ドルで買収した。2026年5月現在、Databricks Mosaic AI プラットフォームの中核学習スタック。GitHub に公開(Apache 2.0)、全コードがオープン。

LLM Foundry の強みは「大規模」。 Axolotl・Unsloth が単一マシンか小さなクラスタを狙うなら、LLM Foundry は最初から数百〜数千 GPU 学習を前提とする。

基本利用例(Databricks Mosaic AI Training API)。

from databricks.mosaic_ai import TrainingClient

client = TrainingClient()
run = client.create_training_run(
    model="meta-llama/Llama-3.1-70B",
    training_data="s3://my-bucket/sft-data/",
    config={
        "task": "INSTRUCTION_FINETUNE",
        "training_duration": "3ep",
        "learning_rate": 5e-7,
    },
)
print(run.status)  # PENDING -> RUNNING -> COMPLETED

Databricksワークスペースの中ではこれだけで完結し、学習されたモデルはUnity Catalogに自動登録されMosaic AI Model Servingですぐ配信される。

LLM Foundry を選ぶとき。

オープンソースで直接使うケースは段々減っている。 一般的なGPUクラスタではAxolotl/TorchTuneのほうが楽で、Databricks外でLLM Foundryを直接回すのはセットアップが重い。だからLLM Foundryは「Databricks内で自動的に使われるもの」へ落ち着きつつある。

11章 · クラウド — Modal / Together / OpenAI / Anthropic / Cohere

GPUを買ったり借りたりしたくないチーム向けの道がある。クラウドファインチューニング API だ。2026年5月時点で5つの陣営。

Modal。 サーバーレスGPUインフラ。ファインチューニング専用ではないが、GPUを分単位で借りられるのでファインチューニングワークロードの人気バックエンドになった。Pythonデコレータでクラウド GPU 関数を定義する。

import modal
app = modal.App("finetune-llama")
image = modal.Image.debian_slim().pip_install("axolotl", "unsloth")

@app.function(image=image, gpu="A100-80GB", timeout=3600)
def train(config_path: str):
    import subprocess
    subprocess.run(["axolotl", "train", config_path])

@app.local_entrypoint()
def main():
    train.remote("config.yml")

このコードを modal run finetune.py 一行で実行。GPUが自動で起動し、学習が終わると自動で止まる。時間あたり1.5〜4ドル(A100/H100)。

Together AI。 Llama・Qwen・Mistral・DeepSeekなどオープンモデルのファインチューニング/サービング統合プラットフォーム。ファインチューニングはLoRAかフルチューンを選べる。

together fine-tuning create \
    --training-file file-xxx \
    --model meta-llama/Llama-3.1-70B-Instruct-Reference \
    --lora \
    --lora-r 16

学習が終わると学習済みモデルが Together インファレンスに自動登録される。料金はトークン課金か、専用エンドポイントの時間課金。

OpenAI。 GPT-4.1, GPT-4o-mini, o4-miniなど自社モデルのチューニング。2024年末からReinforcement Fine-Tuning(RFT)も公開。RFTはユーザーがgrader functionを定義するとその信号でRL学習を回してくれる。

from openai import OpenAI
client = OpenAI()

job = client.fine_tuning.jobs.create(
    training_file="file-xxx",
    model="gpt-4o-mini-2024-07-18",
    method={"type": "supervised"},  # もしくは "dpo", "reinforcement"
)

Anthropic。 Claude 3.5 Haikuからファインチューニングを公開し始めた(2024年末)。2026年5月時点でClaude 4 Sonnet/HaikuのSFTとConstitutional Finetuning(憲法的価値整合)を公開。ただし利用可能範囲は営業ライン経由のことが多く、全顧客がセルフサービスで触れるわけではない。

Cohere。 Command R/R+モデルのSFTファインチューニング。Cohereの差別化はRAGと結合したファインチューニング(retrieval-aware finetuning)を明示的にサポートする点。

どのクラウドを選ぶべきか。

状況おすすめ
オープンモデル + 重みを持ち帰る必要ありModal もしくは Together
OpenAIモデルだけを使う(エコシステムロックイン)OpenAI ファインチューニング
Claudeモデル, エンタープライズ営業ライン有りAnthropic Claude finetuning
RAG ベースのチャットボット, Cohere エコシステムCohere finetuning
自前コードをそのまま、クラウドだけ借りたいModal

12章 · DPO / GRPO / KTO アルゴリズム — どれを選ぶか

2024〜2026年に選好最適化アルゴリズムが爆発した。この章で中核4つを比較する。

PPO(Proximal Policy Optimization)。 2022年InstructGPT論文が使ったクラシックRLHFアルゴリズム。Reward Model を別途学習し、RM の reward 信号で PPO を回してポリシーを最適化する。安定だがRM学習が必要で、4つのモデル(policy, ref, value, reward)を同時に立ち上げないといけないのでメモリ負担が大きい。

DPO(Direct Preference Optimization)。 2023年RafailovのスタンフォードEnterprise論文。「RM無しでもペア選好データから直接ポリシーを学習できる」という核アイデア。policyとrefの2モデルだけ要るのでメモリ負担が半分。2024年に事実上の標準になった。弱点はオーバーフィットしやすく、ペアデータの品質に非常に敏感なこと。

KTO(Kahneman-Tversky Optimization)。 2024年ContextualAIの Ethayarajh 論文。ペアデータの代わりに「この応答は良い/悪い」というbinary信号だけで学習可能。ペアが集められない状況(顧客の thumbs up/down データ)に適する。行動経済学の prospect theory(損失回避)をモデル化。

GRPO(Group Relative Policy Optimization)。 2024年DeepSeekのDeepSeekMath/R1論文で導入。PPO変形だが value model を無くした。1プロンプトに応答をK個生成し(通常4〜16個)、そのK個の reward 平均を baseline にして advantage を計算。value head 学習が抜けるのでメモリ・コードがシンプル。数学・コードのように検証可能な reward で非常に強い。

アルゴリズムデータモデル数強み弱み
PPOペア → RM学習後 reward4 (policy, ref, value, reward)安定, 深い RL重い, RM 学習必要
DPOペア (chosen / rejected)2 (policy, ref)軽くて速いオーバーフィットしやすい
KTObinary (良い/悪い)2 (policy, ref)ペアを集めなくてよい信号が弱い
GRPO検証可能な reward (正解一致など)2 (policy, ref) + K rollouts数学/コードで強いrollout コスト
ORPOペア (SFT と統合)1 (policy のみ)一段階で完結新しいので検証不足
SimPOペア (reference-free)1 (policy のみ)ref モデル不要安定性低い
IPOペア (DPO regularized)2 (policy, ref)DPO オーバーフィット防止DPO より学習が遅い

2026年推奨シーケンス。

  1. SFT。 常に第一段階。高品質 instruction データ 10k〜100k 件。
  2. DPO もしくは KTO。 選好データがあれば DPO、binary 信号だけなら KTO。
  3. GRPO。 数学・コード・logic のように検証可能な reward があるドメイン。

この3段階の上に Mixture-of-Agents RLHF のような新しい手法(複数エージェントが互いに評価しながら学習)が2025年から試されているが、まだ実験段階。

13章 · FSDP / DeepSpeed Zero / QLoRA — 分散学習

大きなモデルを学習するにはGPU一枚では足りない。重み・オプティマイザ状態・gradient を複数 GPU に分ける必要がある。これを解く中核技法3つを整理する。

FSDP(Fully Sharded Data Parallel)。 PyTorch 公式の分散戦略。データ並列だが、重み・gradient・オプティマイザ状態をGPU間でshardingする。forward/backward 時に必要な重みだけ集めて(all-gather)、終わったらまた分ける。メモリはN枚 GPU で 1/N に縮むが、通信コストが増える。

from torch.distributed.fsdp import FullyShardedDataParallel as FSDP
from torch.distributed.fsdp import MixedPrecision
import torch

model = FSDP(
    model,
    mixed_precision=MixedPrecision(
        param_dtype=torch.bfloat16,
        reduce_dtype=torch.bfloat16,
        buffer_dtype=torch.bfloat16,
    ),
)

DeepSpeed Zero。 Microsoft の分散学習ライブラリ。ZeRO-1/2/3 段階がある。

DeepSpeedはZeRO-Infinity(CPU/NVMe offload)とZeRO-Offload(CPUにオプティマイザ状態を逃がす)が強力で、GPUメモリが本当に厳しいときに効く。短所はPyTorch FSDPより統合の深さが浅く、torch.compile/FSDP2のような新機能統合が遅いこと。

QLoRA + FSDP。 Tim Dettmersの代表作。4-bit量子化されたベースモデル + LoRA アダプタ学習 + FSDP 分散。70Bモデルを2枚のA100 80GBに載せてLoRA学習できる。Axolotl・Unsloth・TorchTune・HuggingFace TRLすべてこの組合せをサポートする。

2026年デフォルトマトリックス。

モデルサイズGPUおすすめ分散戦略
7B1xA100 40GBLoRA, 分散しない
7B フルチューン1xH100 80GBFSDP-1 (オプティマイザのみ)
13B フルチューン4xA100 80GBFSDP-2 (オプティマイザ + grad)
70B QLoRA2xA100 80GBQLoRA + FSDP-3
70B フルチューン8xH100 80GBFSDP-3 + activation checkpointing
405B QLoRA4xH100 80GBQLoRA + FSDP-3 + CPU offload
405B フルチューン64+xH100DeepSpeed ZeRO-3 もしくは FSDP-3 + Megatron

Liger Kernels。 2024年LinkedInが公開したTritonカーネル集。CrossEntropy/RMSNorm/SwiGLU/RoPEをfusedで回し、メモリ20〜30%節約 + 速度10〜20%向上。Axolotl・Unsloth・TorchTuneがすべて統合。2026年にはほぼデフォルトでオンにするオプションになった。

14章 · 韓国 / 日本 — Upstage / KT / LG AI / Sakana / Stockmark / ELYZA / PFN

韓国。

日本。

韓国・日本共通パターン。

15章 · 誰が何を選ぶべきか — 決定ガイド

ここまで見たツール・アルゴリズム・インフラをペルソナ別に整理する。

ペルソナ A: 個人開発者, GPU 1枚(RTX 4090 もしくは Colab Pro)

ペルソナ B: 学術研究者, クラスタ 4–8 枚 GPU

ペルソナ C: シード–シリーズ A スタートアップ

ペルソナ D: エンタープライズ / 200名以上

ペルソナ E: ファンデーションモデルラボ

ペルソナ F: 韓国 / 日本ドメイン特化

最後の一言

2026年のLLMファインチューニングは 「GPU 1枚だけでも始められて、数千枚あっても終わりが見えない」 領域だ。小さく始めて、何が効くかを測定して、それから拡張するのが正解。ツールは脇役で、データ品質と評価が結局すべてを決める。

参考 / References

原文を読む: https://www.youngju.dev/blog/culture/2026-05-16-llm-finetuning-frameworks-2026-axolotl-unsloth-llama-factory-trl-peft-torchtune-deep-dive.ja

コメント

まだコメントはありません。

ログインするとコメントできます