💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

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

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つの陣営に分けてみよう。

| 陣営 | 代表ツール | 主な利用者 |

| --- | --- | --- |

| **オープンソースフレームワーク** | Axolotl, Unsloth, LLaMA-Factory, TRL, PEFT, TorchTune, LLM Foundry | 学術/スタートアップ/個人 |

| **クラウドファインチューニングAPI** | OpenAI, 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年の実務デフォルトはこうだ。

- **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 がサポートするトレーナーたち。**

| トレーナー | アルゴリズム | 用途 |

| --- | --- | --- |

| **SFTTrainer** | Supervised Fine-Tuning | 教師あり学習(chat/instruction tuning) |

| **RewardTrainer** | Pairwise reward model | RLHFのRMフェーズ |

| **PPOTrainer** | Proximal Policy Optimization | クラシックRLHF(InstructGPTスタイル) |

| **DPOTrainer** | Direct Preference Optimization | ペア選好データを直接学習 |

| **GRPOTrainer** | Group Relative Policy Optimization | DeepSeek R1 スタイルの RL |

| **KTOTrainer** | Kahneman-Tversky Optimization | 良い/悪い二値信号で学習 |

| **ORPOTrainer** | Odds Ratio Preference Optimization | SFT + DPO を一気に統合 |

| **CPOTrainer** | Contrastive Preference Optimization | DPO 変形、安定性強化 |

| **IPOTrainer** | Identity Preference Optimization | DPO のオーバーフィット補正 |

**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 関数を定義する。

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):

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

| アルゴリズム | データ | モデル数 | 強み | 弱み |

| --- | --- | --- | --- | --- |

**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

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

| モデルサイズ | GPU | おすすめ分散戦略 |

| --- | --- | --- |

| 7B | 1xA100 40GB | LoRA, 分散しない |

| 7B フルチューン | 1xH100 80GB | FSDP-1 (オプティマイザのみ) |

| 13B フルチューン | 4xA100 80GB | FSDP-2 (オプティマイザ + grad) |

| 70B QLoRA | 2xA100 80GB | QLoRA + FSDP-3 |

| 70B フルチューン | 8xH100 80GB | FSDP-3 + activation checkpointing |

| 405B QLoRA | 4xH100 80GB | QLoRA + FSDP-3 + CPU offload |

| 405B フルチューン | 64+xH100 | DeepSpeed 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

**韓国。**

- **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