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

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

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月時点の風景はこうだ。

• オープンソースフレームワークが Axolotl・Unsloth・LLaMA-Factory・TRL・PEFT・TorchTune の六強構図にまとまった。
• クラウドファインチューニングAPIは OpenAI・Anthropic・Cohere・Together・Modal の5つが事実上の標準。
• アルゴリズムはSFT(Supervised Fine-Tuning)の上に DPO → GRPO → KTO → IPO が順に積まれた。
• 分散学習は QLoRA + FSDP + DeepSpeed Zero が事実上の標準。

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

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

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

この分類は完璧ではない。例えば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 決定表

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

核となる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年の実務デフォルトはこうだ。

• GPUメモリが厳しい / 70Bモデル → QLoRA + r=16, alpha=32.
• GPUに余裕あり / 7–13Bモデル → LoRA + r=64, alpha=128.
• フルチューン可能 → DoRA もしくは フルチューン.
• データ100件未満 → IA3 もしくは LoRA r=4.

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が得意なこと。

• 柔軟性。 Llama・Mistral・Qwen・DeepSeek・Phi・Gemma・Mixtral — ほぼ全オープンモデル対応。
• アルゴリズムカバレッジ。 SFT・DPO・GRPO・KTO・ORPO・CPT(Continual Pretraining)まで。新しい論文のアルゴリズムが1〜2週間以内に入る。
• コミュニティ。 Discord に数千人、毎週 PR がマージされる。NousResearch・DeepSeek のような大手が利用事例を共有する。

弱点。

• YAML デバッグ地獄。 オプションが多すぎて、一度ミスると深いスタックでエラーが出てくる。
• メモリ最適化は Unsloth より弱い。 同じGPUでAxolotlがOOMする設定でもUnslothなら回ることが多い。

Axolotlを選ぶとき。

• 複数アルゴリズム(SFT → DPO → GRPO)を一つのツール内で比較したい → Axolotl.
• マルチノード分散学習が必要 → Axolotl + DeepSpeed Zero-3.
• ビジョンマルチモーダルモデルのチューニング(Llava・Qwen-VL) → 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が得意なこと。

• 単一GPUで最強。 A100 1枚, H100 1枚, さらにはRTX 4090 でも7〜13Bモデルのチューニングが速く安定する。
• メモリ効率。 24GB GPUで70B QLoRAが動く。他のツールはOOMする領域。
• ノートブック親和性。 Colab/Kaggleでそのまま動くノートブックを公式に提供。

弱点。

• マルチGPUが弱い。 2025年からマルチGPUサポートを始めたがAxolotlほど安定していない。FSDP/DeepSpeed統合は部分的。
• モデルカバレッジが狭い。 Llama・Mistral・Qwen・Phi・Gemma・DeepSeek 主流は全部できるが、非主流モデルは直接パッチが要ることもある。

Unsloth を選ぶとき。

• 個人開発者、GPU1枚、ノートブック/Colab → Unslothが事実上の正解。
• 小チーム、短いサイクル(週末ハッカソン) → Unsloth が最速で結果を出す。
• マルチノード学習が必要 → Axolotl もしくは TorchTune へ。

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 が得意なこと。

• 参入障壁が最低。 Web UIのおかげで非開発者でもモデルチューニングを試せる。
• 中国モデル1番乗り。 Qwen・DeepSeek・ChatGLM・Yi・InternLMなどは LLaMA-Factory が最速対応。
• フルパイプライン RLHF。 SFT → Reward Model → PPO が一つのツールで綺麗に流れる。

弱点。

• 英語ドキュメントが薄い。 コードは英語だが issues・discussions が中国語のことが多い。英語圏のコミュニティサポートは Axolotl ほど厚くない。
• 新アルゴリズム統合が保守的。 Axolotlが1週間以内にGRPOを入れたら、LLaMA-Factoryは通常2〜4週間。

LLaMA-Factory を選ぶとき。

• 非開発者/研究者が Web UI で始める → LLaMA-Factory.
• Qwen・DeepSeek・ChatGLM などの中国モデルチューニング → LLaMA-Factory.
• 一気に SFT + RM + PPO を授業課題のように比較 → 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 がサポートするトレーナーたち。

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を直接使うとき。

• 新アルゴリズム研究(自分の論文に使うため) → TRL 直接.
• カスタム reward function, カスタム rollout → TRL 直接.
• ただ LoRA + DPO 学習が目的 → Axolotl/Unsloth/LLaMA-Factory 経由で十分.

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 のデザイン哲学。

• Recipes。 YAML config の代わりに Python ファイル(recipe)で学習ループを定義。コードを直接書き換えてカスタマイズするのが容易。
• No magic。 transformers・PEFT・TRL をほぼ使わない。独自モデル実装、独自LoRA、独自学習ループ。深いところまで覗ける。
• PyTorch 最新機能を一番乗りで採用。 FSDP2, torch.compile, Liger Kernels, Triton kernel のような最新 PyTorch スタックを最初に受ける。

基本利用例。

# プリビルトの 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 が得意なこと。

• 純粋 PyTorch。 transformers 抽象を介さずモデルを直接扱うので、学習ループのデバッグが楽。
• 分散学習。 FSDP2 統合がもっとも滑らか。マルチノード学習が安定。
• メモリ効率。 Liger Kernels 統合で cross-entropy/RMSNorm/SwiGLU が fused カーネルで回る。

弱点。

• アルゴリズムカバレッジが狭い。 SFT・LoRA・QLoRA・DPO・PPO・GRPO はあるが、KTO・ORPO・SimPO のような変形はまだ無いか、遅れて入る。
• モデルカバレッジ。 Llama・Mistral・Gemma・Phi・Qwen・DeepSeek くらい。非主流モデルは自分で追加する必要あり。

TorchTuneを選ぶとき。

• 学習ループを深く見ながらデバッグしたい → TorchTune.
• PyTorch 新機能(FSDP2, torch.compile)を早く使いたい → TorchTune.
• 学科講義/研究室の標準として定着させたい → TorchTune(PyTorch公式なので安定性保証).

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 学習を前提とする。

• StreamingDataset。 S3/GCS/Azure Blob からペタバイト規模のデータを stream で読みながら学習。事前ダウンロードしない。
• FSDP/HSDP 最適化。 Composer ライブラリ(MosaicML独自)の上で分散学習効率が非常に高い。MFU(Model FLOPs Utilization)を50〜60%まで引き上げる。
• MPT モデルシリーズ。 MosaicMLが学習したMPT-7B/30B/Foundationの学習コードがそのまま公開。「このコードで本当にモデルを作った」という証拠。

基本利用例(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 を選ぶとき。

• 既に Databricks 顧客 → 自然な選択.
• 100B+ モデルのフルチューン、マルチノード学習 → MFU 効率と安定性で最強.
• セキュリティ/ガバナンス要件(Unity Catalog) → 他のツールでは解けない.

オープンソースで直接使うケースは段々減っている。 一般的な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)を明示的にサポートする点。

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

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 で非常に強い。

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 段階がある。

• ZeRO-1: オプティマイザ状態のみ sharding。
• ZeRO-2: オプティマイザ + gradient。
• ZeRO-3: オプティマイザ + gradient + 重みすべて。FSDPとほぼ同じ動作。

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年デフォルトマトリックス。

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

韓国。

• Upstage。 Solar モデルシリーズを作る韓国の LLM スタートアップ。2024年に Solar 10.7B で Hugging Face リーダーボード1位になったことがある。独自のファインチューニングプラットフォーム(Upstage AI Stack)を持ち、「DUS(Depth-Up-Scaling)」という独自モデル拡張手法で有名。2025年に韓国政府の国産LLMプロジェクト(K-LLM)の中核パートナーに選定。
• KT。 Mi:dm 2.0(ミドム)モデルを自社開発。韓国語・韓国文化特化に強み。2025年に KT クラウドの GPU インフラを本格化し、外部にファインチューニングサービスも公開し始めた。
• LG AI Research。 EXAONE 3.5/4.0 モデルシリーズ。化学・素材・法務のような特殊ドメインのファインチューニング事例が多い。2024年に EXAONE 3.5 をオープンウェイトで公開し、外部研究者が直接チューニング可能になった。
• 国内ファインチューニングインフラ。 NHN Cloud, NAVERクラウド, KTクラウドが H100/H200 GPU を時間あたり4〜8千ウォン台で提供。AWS/GCP 韓国リージョンより 30% ほど安い。

日本。

• Sakana AI。 東京に本社を置く、Google Brain出身のDavid HaとLlion Jones(トランスフォーマー共著者)が創業した会社。2024年シリーズAで4.5億ドルvaluation。「evolutionary model merging」というユニークなアプローチ(複数モデルを進化アルゴリズムで混ぜて新モデルを作る)で有名。日本語特化モデル EvoLLM-JP シリーズ。
• Stockmark。 金融・法務ドメインに特化した日本の LLM 会社。Stockmark-13B のような日本語 LLM を自社学習。
• ELYZA。 東京大学発のスタートアップ。Llama 2/3 を日本語で continual pretraining + finetuning して「ELYZA-japanese-Llama」シリーズを公開。2024年KDDIが買収。
• PFN(Preferred Networks)。 日本の巨人。PLaMo シリーズで独自 LLM を学習し、MN-Core という自社アクセラレータまで作る。産業ドメイン(製造・医療)のファインチューニングに強い。
• Sakana の evolutionary model merging。 2024年の論文が話題を呼んだ。2つの日本語モデル(Shisa, ELYZA)を進化アルゴリズムで混ぜて、それぞれより良い性能の新モデルを作った。「学習なしでもモデルを改善できる」という可能性を示した。

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

• 英語ベースモデル(Llama・Mistral)を韓国語/日本語で continual pretraining → その上で instruction tuning するのが標準レシピ。
• 自社 GPU クラスタを構築する会社が増えている。米国クラウド依存がコスト・主権問題で引っ掛かる。
• Axolotl・LLaMA-Factory が圧倒的によく使われる。Unsloth は速いがマルチノードの弱点で大きな会社はあまり使わない。

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

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

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

• フレームワーク: Unsloth. 単一 GPU で最高効率, Colab ノートブックそのまま回る.
• アルゴリズム: LoRA SFT → DPO. KTO/GRPO はデータ集めが難しい.
• モデルサイズ: 7–13B. 4-bit QLoRA で単一 24GB GPU に載せる.
• データセット: 1k–10k件. 量より質.

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

• フレームワーク: TorchTune もしくは Axolotl. 学習ループを深く掘る必要あり.
• アルゴリズム: 論文書くなら直接実装がベスト, TRL の GRPOTrainer を base に.
• モデルサイズ: 7B → 70B へ漸進拡張.
• 分散: FSDP-2/3 もしくは DeepSpeed Zero-3.

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

• フレームワーク: Axolotl(最速のアルゴリズムカバレッジ).
• インフラ: Modal(サーバーレス GPU)もしくは Together(学習 + サービング統合).
• アルゴリズム: SFT → DPO. 一貫性・スタイル整合が一番.
• モデルサイズ: 8–13B. コスト/品質バランス.
• データ: ドメインデータ 5k–50k 件 + 一般 instruction データ mix.

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

• フレームワーク: LLM Foundry(既に Databricks 使用)もしくは自社クラスタ + Axolotl.
• クラウド: OpenAI ファインチューニング(エコシステムロックイン)もしくは Anthropic 営業ライン.
• アルゴリズム: SFT + DPO + 可能なら GRPO.
• モデルサイズ: 70B+. 自社 70B チューニングが GPT-4 呼び出しより安くなる.
• ガバナンス: モデル重みを自社保管, audit log, lineage tracking.

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

• フレームワーク: 自前構築. Axolotl・TorchTune・LLM Foundry を fork して独自パッチ.
• インフラ: 数百〜数千 GPU クラスタ, RDMA/InfiniBand.
• アルゴリズム: 新アルゴリズム開発, 論文を書く.
• データ: 自前クロール・ラベリングパイプライン.

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

• ベースモデル: Llama 3.x, Qwen 2.5/3, もしくは Upstage Solar / EXAONE / Stockmark / ELYZA.
• レシピ: Continual Pretraining(ドメインテキスト 1B+ tokens) → SFT(instruction 5k–50k) → DPO.
• インフラ: NHN/NAVER/KT クラウド(韓国), さくらインターネット・GMO・PFN クラスタ(日本).
• フレームワーク: LLaMA-Factory(中国モデル互換性)もしくは Axolotl(英語圏互換性).

最後の一言

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

参考 / References

• Axolotl — https://axolotl.ai/
• Axolotl GitHub — https://github.com/axolotl-ai-cloud/axolotl
• Unsloth — https://unsloth.ai/
• Unsloth GitHub — https://github.com/unslothai/unsloth
• LLaMA-Factory GitHub — https://github.com/hiyouga/LLaMA-Factory
• Hugging Face TRL — https://huggingface.co/docs/trl
• TRL GitHub — https://github.com/huggingface/trl
• PEFT — https://huggingface.co/docs/peft
• PEFT GitHub — https://github.com/huggingface/peft
• TorchTune — https://pytorch.org/torchtune/
• TorchTune GitHub — https://github.com/pytorch/torchtune
• LLM Foundry — https://github.com/mosaicml/llm-foundry
• Databricks Mosaic AI — https://www.databricks.com/product/machine-learning/mosaic-ai
• Modal — https://modal.com/
• Together AI Fine-tuning — https://docs.together.ai/docs/fine-tuning-overview
• OpenAI Fine-tuning — https://platform.openai.com/docs/guides/fine-tuning
• OpenAI Reinforcement Fine-Tuning — https://platform.openai.com/docs/guides/reinforcement-fine-tuning
• Anthropic Fine-tuning — https://docs.anthropic.com/en/docs/build-with-claude/fine-tuning
• Cohere Fine-tuning — https://docs.cohere.com/docs/fine-tuning
• LoRA paper (Hu et al., 2021) — https://arxiv.org/abs/2106.09685
• QLoRA paper (Dettmers et al., 2023) — https://arxiv.org/abs/2305.14314
• DoRA paper (Liu et al., 2024) — https://arxiv.org/abs/2402.09353
• DPO paper (Rafailov et al., 2023) — https://arxiv.org/abs/2305.18290
• KTO paper (Ethayarajh et al., 2024) — https://arxiv.org/abs/2402.01306
• GRPO / DeepSeekMath (Shao et al., 2024) — https://arxiv.org/abs/2402.03300
• DeepSeek R1 — https://arxiv.org/abs/2501.12948
• ORPO paper (Hong et al., 2024) — https://arxiv.org/abs/2403.07691
• SimPO paper (Meng et al., 2024) — https://arxiv.org/abs/2405.14734
• IPO paper (Azar et al., 2023) — https://arxiv.org/abs/2310.12036
• IA3 paper (Liu et al., 2022) — https://arxiv.org/abs/2205.05638
• AdaLoRA paper (Zhang et al., 2023) — https://arxiv.org/abs/2303.10512
• VeRA paper (Kopiczko et al., 2023) — https://arxiv.org/abs/2310.11454
• PyTorch FSDP — https://pytorch.org/docs/stable/fsdp.html
• DeepSpeed ZeRO — https://www.deepspeed.ai/tutorials/zero/
• Liger Kernels — https://github.com/linkedin/Liger-Kernel
• vLLM — https://github.com/vllm-project/vllm
• Mixture-of-Agents — https://arxiv.org/abs/2406.04692
• Upstage Solar — https://www.upstage.ai/feed/product/solarmini-introduction
• KT Mi:dm — https://www.kt.com/biz/mi-dm.html
• LG AI EXAONE — https://www.lgresearch.ai/exaone
• Sakana AI — https://sakana.ai/
• Sakana evolutionary model merging — https://sakana.ai/evolutionary-model-merge/
• Stockmark — https://stockmark.co.jp/
• ELYZA — https://elyza.ai/
• Preferred Networks PLaMo — https://www.preferred.jp/en/projects/plamo/
• MosaicML acquisition by Databricks (2023) — https://www.databricks.com/company/newsroom/press-releases/databricks-completes-acquisition-mosaicml