- Published on
LLMファインチューニング2026 完全ガイド - LoRA · QLoRA · DoRA · GaLore · Unsloth · Axolotl · TRL · PEFT · MLX-LM 深層解析
- Authors

- Name
- Youngju Kim
- @fjvbn20031
プロローグ — 2026年、ファインチューニングが「ユーザの道具」になった年
2021年6月、MicrosoftのEdward Huが発表したLoRA論文は、「百万個のパラメータだけ学習してもGPT-3レベルの適応ができる」と示した。当時、ファインチューニングはスーパーコンピュータの仕事だった。2023年5月、Tim DettmersがQLoRAを出して、65Bモデルを単一の48GB GPUに押し込んだ。それからファインチューニングは「研究者の仕事」から「エンジニアの仕事」へと移った。
そして2026年5月の今、ファインチューニングは**「ユーザの道具」**だ。M3 Ultra Mac Studio一台で70BモデルをLoRAチューニングできる。Unslothが4ビット量子化を自動処理し、TRLのSFTTrainerが5行でSFTを終わらせる。AxolotlとLLaMA-FactoryはYAML一枚で全てのハイパーパラメータを外部化した。AppleのMLX-LMはM4 Max MacBook ProでMistral 7BをLoRA学習する。これらすべてが4年の間に起こった。
ファインチューニングはもはや「モデルを最初から学習し直す」ことではない。 90%以上の場合、答えはLoRA系列のPEFT(Parameter-Efficient Fine-Tuning)だ。そしてPEFTの中でも、どの変種を選ぶかが効率・品質・ハードウェア要件を決める。
本稿が扱うこと:
- フルファインチューニング vs PEFT — いつ何を使うか
- LoRAの数学と直感 (Hu et al., 2021)
- QLoRA — 4ビットNF4とダブル量子化 (Dettmers, 2023)
- DoRA — 重み分解 (NVIDIA, 2024)
- GaLore — 勾配射影 (Zhao, 2024)
- PiSSA, LoRA+, rsLoRA, VeRA, LoftQ, OFT, BOFT
- PEFT 0.14 — Hugging Face統合API
- TRL 0.13 — SFT, DPO, ORPO, KTO, IPO, GRPO, RLOO
- Unsloth — 2倍速学習
- Axolotl 0.6 — YAMLベースのマルチGPU
- LLaMA-Factory — 100以上のモデル、Web UI
- MLX-LMとMLX-Tuner — Apple Siliconオンデバイス
- Torchtune — Meta PyTorchのレシピ
- データセット — ShareGPT, OpenHermes, Magpie, Tülu, Nectar
- DPO vs PPO — RLHFの代替
- 合成データ — Augmentoolkit, Distilabel, Self-Instruct
- サービング用の量子化 — GGUF, AWQ, GPTQ, EXL2
- ハードウェア — H100/H200, A100, 4090/5090, M3/M4, MI300X
- クラウド — Together, Modal, RunPod, vast.ai, Lambda Labs
- 韓国・日本モデルのファインチューニング
- どのツールを選ぶべきか
- 参考資料
1章 · フルファインチューニング vs PEFT — GPUメモリの算術
ファインチューニングの最初の決定は「すべての重みを学習するか、一部だけ学習するか」だ。答えはほとんど常に一部だけである。理由はGPUメモリの算術で明確だ。
フルファインチューニングのメモリ算術
7Bモデルをフルファインチューニングするとしよう。fp16の重みだけで14GB。Adamオプティマイザは重みごとにモメンタムと分散の二つの状態をfp32で持つので、重みの4倍 = 56GB。勾配は重みと同じサイズで14GB。活性化はシーケンス長に比例して数十GB追加される。合計100GB以上が7Bモデルのフルファインチューニングの現実だ。H100 80GB一枚では不可能だ。
70Bはこの数字を10倍すれば良い。1TBのメモリ。8x H100ノード一台でも厳しい。
PEFTのメモリ算術
LoRAで7Bを学習すると?ベースの重み14GBはそのまま(または4ビットで3.5GB)。LoRAアダプターは通常ベースの0.11% — 7M70Mパラメータでfp16なら14140MB。オプティマイザ状態はこのアダプターだけを扱うので同様に小さい。活性化は似ているが、ベースが4ビットなら活性化メモリも減る。**合計820GB**で7Bを学習できる。RTX 4090 24GB一枚で十分だ。
フルファインチューニングが合理的な場合
それでもフルファインチューニングが答えになる場合がある:
- 分野がベースから大きく外れているとき — 医療・法律・他言語・ドメイン特化語彙。LoRAはベース分布の小さな適応に強いが、大きな分布のシフトはフルファインチューニングのほうが安全だ。
- 品質の最後の1%を絞り出すとき — 評価ベンチマークで最上位を狙うとき、LoRAがフルファインチューニングに少し及ばないことがある。
- ベースを持っているとき — 社内ベースモデルビルダーなら、LoRAを経ずに直接フルへ行ける。
それ以外の95%のケースはPEFTが答えだ。
2章 · LoRA — Low-Rank Adaptation (Hu et al., 2021)
LoRAのアイデアを一文で言うと: 「重みの更新は低ランクだ」。フルファインチューニング時にWがW + dWに変わるとして、dWは通常フルランクではなく非常に低いランクを持つという観察だ。
数学
ベース重みW(サイズd×k)に対して、LoRAは二つの小さな行列A(d×r)とB(r×k)の積でdWを近似する — ここでr << min(d, k)。学習時はWを凍結してA・Bだけを更新する。推論時には二つの選択肢がある:
- マージ — W + A・Bを事前計算して新しい重みとして保存。推論オーバーヘッドなし。
- アダプターを保持 — Wをそのまま置きA・Bを別のアダプターとして適用。複数のアダプターをホットスワップできる。
主要なハイパーパラメータは三つ:
- rank
r— アダプターのサイズ。通常8~64。大きいほど表現力が上がりメモリも増える。 - alpha — スケーリング係数。通常rの2倍 (r=16ならalpha=32)。実際の更新は
(alpha/r) * A*B。 - target_modules — どのレイヤーにLoRAを付けるか。アテンションのq/k/v/oが基本だが、MLPまで付けると品質が向上する。
実用ガイド (2026年基準)
- r=16, alpha=32が安全なデフォルト。r=8はメモリが厳しいとき、r=64は品質を絞り出すとき。
- target_modulesはq_proj・k_proj・v_proj・o_proj・gate_proj・up_proj・down_projの7つすべてに付けるのが標準になった(「all-linear」)。最初のLoRA論文はqとvだけだったが、すべての線形層に付けるのが一般的だ。
- 学習率はフルファインチューニングの10~100倍大きく(1e-4 ~ 5e-4)。LoRAの小さなパラメータはより積極的な学習率に耐えられる。
- dropoutは0.05~0.1。過適合防止のため。
3章 · QLoRA — 4ビットNF4とダブル量子化 (Dettmers, 2023)
Tim DettmersのQLoRA(2023年5月)を一文で言うと: 「ベースを4ビット量子化した状態でLoRA学習すれば、メモリが4倍減る」。
主要な貢献3つ
- NF4 (NormalFloat 4-bit) — 正規分布に最適化された4ビット量子化。事前学習された重みは平均0で分散の小さい正規分布に近いので、正規分布の分位点に4ビットエンコーディングを割り当てる。INT4より正確だ。
- Double Quantization — 量子化定数(スケール)も量子化する。最初の量子化で各ブロックごとにfp32スケールが1個、これをさらに量子化してメモリを減らす。平均0.5ビット/パラメータの追加節約。
- Paged Optimizers — NVIDIA Unified Memoryでオプティマイザ状態をCPU↔GPUページにスワップ。OOMを避けて学習安定性を上げる。
実用的なメモリ削減
7B fp16 = 14GB → 7B NF4 = 3.5GB。4倍削減。オプティマイザ状態もLoRAアダプターだけを扱うので小さい。結果: 7BモデルをRTX 3090 24GB一枚で学習可能。
QLoRAは2026年現在、LoRA学習の事実上のデフォルトになっている。Unsloth・Axolotl・LLaMA-Factoryすべてが、QLoRAを一級オプションとして提供する。
QLoRAの微細な短所
4ビットベースはfp16ベースより学習が少し不安定なことがある。だから非常に大きな分布シフト(言語転換・ドメイン特化)はfp16ベースのほうが安全だ。また4ビットに量子化されたベースにアダプターを学習した後、アダプターを再びfp16ベースにマージするときに微細な品質損失が出ることがある。LoftQがこれを解決しようとする(7章)。
4章 · DoRA — Weight-Decomposed LoRA (NVIDIA, 2024)
NVIDIAのShih-Yang Liuが2024年に発表したDoRA(Weight-Decomposed Low-Rank Adaptation)。一行要約: 「重みの変化を方向と大きさに分解すれば、LoRAがより良くなる」。
直感
重み行列Wを二つの要素に分解する:
- 大きさ(magnitude)
m— Wの各列のノルム。 - 方向(direction) — ノルムで割った単位ベクトル。
DoRAは方向にはLoRAを適用し、大きさmは別の学習可能パラメータとして置く。フルファインチューニングの学習パターンを分析すると、フルファインチューニングは大きさと方向の両方を大きく変えるが、LoRAは二つが結合して不自然に動くというのがDoRA論文の観察だ。
実験結果
- 同じrでLoRAより1~3ポイント良いベンチマークスコア。
- 小さなr(r=4・8)でDoRAの利点がより大きい — フルファインチューニングに近い表現力。
- 追加メモリはほぼ無視できるレベル(magnitudeベクトルだけ追加)。
PEFTのサポート
Hugging Face PEFT 0.10からDoRAを use_dora=True 一行で有効化できる。2026年現在、新しいLoRA学習の30%程度がDoRAで使われるという非公式統計がある。
5章 · GaLore — Gradient Low-Rank Projection (Zhao, 2024)
Jiawei Zhao(Meta)の2024年3月の論文GaLore。一行要約: 「重みはフルランクだが勾配は低ランクだ — 勾配を低ランクに射影してメモリを減らそう」。
何が違うか
LoRAはアダプター(低ランク)を学習してベース重み自体は凍結する。結果として学習されるパラメータが少ない — 表現力の上限がある。GaLoreは全体の重みを学習しつつ、オプティマイザの状態(Adamのモメンタム・分散)を低ランクの部分空間に置く。N ステップごとにSVDで勾配の主成分方向を見つけ、その方向だけをオプティマイザ状態として持つ。
結果: フルファインチューニングの表現力 + LoRAに近いメモリ。
メモリ節約
7Bフルファインチューニングのオプティマイザ状態は56GB(fp32 Adam) → GaLoreでは7~14GBに減る。重み自体と活性化はフル学習と同じなので、合計メモリはLoRAより大きいがフルファインチューニングの半分以下。
短所
- SVD計算コストが追加される(N ステップごと)。
- 学習速度がLoRAより遅い(重み全体の更新)。
- コード統合がLoRAほど滑らかではない。
GaLoreは「LoRAでは足りないがフルファインチューニングはメモリ不足」のニッチを狙う。2026年現在はニッチだが、シェアが伸びている。
6章 · PEFTの変種 — PiSSA, LoRA+, rsLoRA, VeRA, LoftQ, OFT, BOFT
LoRA以降、数多くの変種が出た。2026年現在PEFT 0.14がサポートする主要なものを短くまとめる。
- PiSSA (Principal Singular values and Singular vectors Adaptation, 2024) — A・Bをランダムではなくベース Wの SVD上位成分で初期化。学習初期の安定性と収束速度が向上。
- LoRA+ (2024) — A と Bの学習率を別々に設定する。Bの学習率をAより16倍程度大きくすると収束が早くなるという観察。
- rsLoRA (Rank-Stabilized LoRA, 2024) — スケーリングを
alpha/sqrt(r)に変えて、大きなrでも学習が安定するようにする。基本のLoRAはrが大きくなると学習率調整が難しくなる問題を解決。 - VeRA (Vector-based Random Matrix Adaptation, 2024) — A・Bを固定(ランダム初期化後に凍結)して、二つの小さなベクトル d, bだけを学習。パラメータをLoRAの1/10に減らす。マルチタスクに効率的。
- LoftQ (LoRA-Fine-Tuning-Aware Quantization, 2023) — QLoRA の量子化誤差をLoRA アダプターが補償するように初期化。QLoRA出発点の品質が上がる。
- OFT/BOFT (Orthogonal Fine-Tuning, 2023) — 重みの直交変換だけを学習。マルチモーダル・画像モデルに有用。
- AdaLoRA (2023) — レイヤーごとの重要度に応じてrを動的に割り当て。
これらの変種は「基本のLoRAよりわずかに良い」という微細な利益だ。90%のケースは普通のLoRAで十分だ。変種は評価ベンチマークで最上位を狙うときに試す。
7章 · Hugging Face PEFT 0.14 — 統合API
Hugging FaceのPEFTライブラリは上で挙げたすべての変種の統合APIだ。2026年5月現在、0.14がstable、0.15がbetaだ。
基本的な使い方
from peft import LoraConfig, get_peft_model
from transformers import AutoModelForCausalLM
model = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-3.2-3B")
config = LoraConfig(
r=16,
lora_alpha=32,
target_modules="all-linear",
lora_dropout=0.05,
bias="none",
task_type="CAUSAL_LM",
use_dora=False, # TrueにするとDoRA
)
model = get_peft_model(model, config)
model.print_trainable_parameters()
# trainable params: 24,313,856 || all params: 3,236,000,000 || trainable%: 0.75
アダプターの保存とロード
model.save_pretrained("./my-lora-adapter")
# 後でロード
from peft import PeftModel
base = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-3.2-3B")
model = PeftModel.from_pretrained(base, "./my-lora-adapter")
アダプターのマージ
merged = model.merge_and_unload()
merged.save_pretrained("./merged-model")
マルチアダプター
PEFTは一つのベースに複数のアダプターを同時に置いてホットスワップできる — 同じモデルインスタンスを英語・日本語・韓国語アダプターに即時に切り替えられる。推論サーバで非常に有用。
8章 · TRL 0.13 — SFT, DPO, ORPO, KTO, IPO, GRPO, RLOO
TRL(Transformer Reinforcement Learning)はHugging FaceのRLHF・アライメント(alignment)ライブラリだ。2026年5月現在、0.13がstable、GRPO・RLOOといった最新アルゴリズムが一級市民として追加された。
SFTTrainer (Supervised Fine-Tuning)
最もよく使う道具。チャットデータセットでSFTを終わらせる。
from trl import SFTTrainer, SFTConfig
config = SFTConfig(
output_dir="./sft-output",
num_train_epochs=3,
per_device_train_batch_size=4,
gradient_accumulation_steps=4,
learning_rate=2e-4,
bf16=True,
packing=True,
max_seq_length=4096,
)
trainer = SFTTrainer(
model=model,
args=config,
train_dataset=dataset,
peft_config=lora_config, # PEFTと統合
)
trainer.train()
DPOTrainer (Direct Preference Optimization)
ペアデータ(prompt, chosen, rejected)でアライメント。PPOよりずっと単純で安定的。
ORPOTrainer (Odd Ratio Preference Optimization)
SFTとDPOを一度に行う新生アルゴリズム(2024)。別のリファレンスモデルがないのでメモリ節約。
KTO (Kahneman-Tversky Optimization)
プロスペクト理論(prospect theory)から着想を得たアライメント。ペアではなく単一のラベル(良い・悪い)データでもアライメント可能。
GRPO (Group Relative Policy Optimization)
DeepSeek-R1が使ったアルゴリズム。推論能力学習に強い。2026年現在、reasoningモデル学習の標準。
RLOO (REINFORCE Leave-One-Out)
ベースライン推定にleave-one-outを使うことで、PPOより単純でありながら効果的。
9章 · Unsloth — 2倍速学習、メモリ50%節約
Unsloth(Daniel HanとMichael Han兄弟、2024)はシングルGPUファインチューニングのゲームチェンジャーだ。一行要約: 「手書きTritonカーネルでLoRA/QLoRA学習を2倍速く」。
どう速いのか
- 手書きTritonカーネル — Transformersの一般的なPyTorchカーネルを直接書いたTritonカーネルに置き換える。アテンション・RMSNorm・rotary embeddingすべてカスタム。
- メモリ効率的なbackward — チェックポイント・再計算を最適化して活性化メモリを50%削減。
- 4ビット自動量子化 — UnslothがNF4量子化 + double quantizationを自動で適用。
- モデル特化パッチ — Llama・Mistral・Gemma・Phi・Qwenそれぞれに最適化されたパス。
使用例
from unsloth import FastLanguageModel
model, tokenizer = FastLanguageModel.from_pretrained(
model_name="unsloth/llama-3.2-3b-instruct-bnb-4bit",
max_seq_length=4096,
load_in_4bit=True,
)
model = FastLanguageModel.get_peft_model(
model,
r=16,
target_modules=["q_proj", "k_proj", "v_proj", "o_proj",
"gate_proj", "up_proj", "down_proj"],
lora_alpha=32,
use_rslora=False,
use_dora=False,
)
その後SFTTrainerで学習。結果: RTX 4090 24GBでLlama 3.2 8Bを4時間で学習 (同じデータでvanilla Transformersは8~10時間)。
制約
- マルチGPUサポートがvanillaより弱い(2026年5月基準、Unsloth ProのマルチGPUは別途有料)。
- サポートモデルがリスト内に限定。新しいアーキテクチャはパッチを待つ必要がある。
10章 · Axolotl 0.6 — すべてをYAMLで
Axolotl(OpenAccess AI Collective、2023~)を一行要約: 「YAML一枚ですべてのハイパーパラメータを外部化せよ」。
なぜYAMLなのか
Pythonスクリプトで書かれた学習コードは再現が難しい。誰がどの学習率・バッチサイズ・アダプター設定で学習したかをgitに残すには、コード自体が変数だ。YAMLはこれを単一の真実の源(single source of truth)にする。
設定例
base_model: meta-llama/Llama-3.2-3B
model_type: LlamaForCausalLM
tokenizer_type: AutoTokenizer
load_in_4bit: true
adapter: qlora
lora_r: 16
lora_alpha: 32
lora_target_modules:
- q_proj
- k_proj
- v_proj
- o_proj
datasets:
- path: tatsu-lab/alpaca
type: alpaca
sequence_len: 4096
sample_packing: true
gradient_accumulation_steps: 4
micro_batch_size: 2
num_epochs: 3
learning_rate: 2e-4
bf16: auto
optimizer: paged_adamw_32bit
強み
- マルチGPU・DeepSpeed・FSDP が一級サポート。4x H100で70B学習が自然。
- すべてのPEFT変種 をサポート(LoRA・QLoRA・DoRA・GaLore)。
- データセット形式の自動変換 — alpaca, sharegpt, jsonlなど自動認識。
- WandB・MLflow統合。
弱み
- YAMLが巨大になることがある。オプションが100を超える。
- デバッグ時にコードの中に入る必要がある — 抽象化の代償。
11章 · LLaMA-Factory — 100以上のモデル、Web UI
HiYouga (Zheng et al., 2023) のLLaMA-Factoryを一行要約: 「ファインチューニングのGUI時代」。
特徴
- 100以上のモデルをサポート — Llama, Mistral, Gemma, Qwen, Phi, ChatGLM, Yi, Baichuan, InternLMなどほぼすべての主要オープンモデル。
- LLaMA Board Web UI — 学習・評価・チェックポイント管理をブラウザで。
- すべての学習方式 — Full, LoRA, QLoRA, DoRA, GaLore, BAdam, freeze, PT, SFT, RLHF (PPO, DPO, KTO, ORPO, SimPO)。
- 中国語・英語データセットビルトイン — Alpaca-zh, Belle, Firefly, Magpieなど。
使い方
pip install llamafactory
llamafactory-cli webui
ブラウザでモデル・データセット・学習方式をクリックで選択、学習開始。非コーダーのユーザーもアクセスできる。韓国・日本・中国企業の社内LLMファインチューニングに急速に普及した。
誰が使うか
- モデルビルダーの素早い実験(YAMLを書く前のプロトタイプ)。
- 非コーダーR&D — データサイエンティストがコードなしでファインチューニング。
- 社内モデルカードの実演 — 営業・マーケが直接デモ。
12章 · MLX-LMとMLX-Tuner — Apple Siliconオンデバイス
Appleは2023年12月にMLX(Machine Learning eXperience)フレームワークを公開した。PyTorchと似たAPIだが、**統合メモリアーキテクチャ(Unified Memory Architecture)**に最適化されているため、M1~M4チップでCPUとGPUが同じメモリプールを見る。
MLX-LMの意味
- M3 Ultra Mac Studio(192GB統合メモリ)で70BモデルのLoRAファインチューニングが可能。
- M4 Max MacBook Pro(128GB)でMistral 7B / Llama 3.2 8Bのフルファインチューニングが可能。
- ノートでデータが外部に出ずにファインチューニング — 医療・法律・機密データに強み。
使用例
pip install mlx-lm
python -m mlx_lm.lora \
--model mistralai/Mistral-7B-v0.3 \
--train \
--data ./my_data \
--iters 1000 \
--lora-layers 16 \
--batch-size 4
制約
- 学習速度はH100より遅い — Apple GPUのFLOPSがデータセンターGPUに及ばない。
- マルチマシン分散はサポートが弱い。
- 新しいモデルアーキテクチャはMLX変換を待つ必要がある。
それでも**「自分のノートでファインチューニング」**の意味は大きい。韓国・日本の小さなチームがクラウド費用なしで実験を回せる。
13章 · Torchtune — Meta PyTorchの公式レシピ
TorchtuneはMeta PyTorchチームが2024年4月に公開したライブラリ。一行要約: 「PyTorchネイティブ、メモリ効率、レシピベース」。
哲学
- レシピ = 学習スクリプト。各ユースケース(LoRA・フル・QLoRA・DPOなど)ごとに独立したスクリプトがある。
- 継承ではなく複製 — 新しいユースケースは既存のレシピをコピーして修正する。抽象化地獄を避ける。
- PyTorchネイティブ — Hugging Face Transformersの依存なし。モデル・オプティマイザ・データセットすべて直接実装。
使い方
pip install torchtune
tune download meta-llama/Llama-3.2-3B-Instruct \
--output-dir /tmp/Llama-3.2-3B \
--hf-token YOUR_TOKEN
tune run lora_finetune_single_device \
--config llama3_2/3B_lora_single_device
強み
- メモリ効率 — 活性化チェックポイント、fp8オプティマイザ(experimental)。
- FSDP2ネイティブサポート — マルチGPUが自然。
- PyTorchチーム直接メンテナンス — 新しいPyTorch機能を早く受ける。
弱み
- 生態系がHugging Faceより小さい。
- モデルサポートがAxolotl・LLaMA-Factoryより狭い。
14章 · データセット — ShareGPT, OpenHermes, Magpie, Tülu, Nectar
良いファインチューニングの70%はデータだ。2026年現在よく使われるオープンSFTデータセット。
- ShareGPT — ChatGPTの会話をユーザが共有したデータ(GPT-3.5~4時代)。90K以上の対話。多様性が良い。ライセンスはグレーゾーン(OpenAI規約 vs ユーザ共有)。
- OpenHermes 2.5 (Teknium) — 1M以上のキュレーションされたインストラクション。Hermesシリーズの学習データ。
- Magpie (Xu et al., 2024) — Llama-3-Instructをself-promptingして作ったデータ。「自分で自分に質問させる」技法。
- Tülu 3 SFT Mix (Allen AI, 2024) — TüluシリーズのSFTミックス。多様なインストラクションと推論データ。
- Nectar (Berkeley, 2023) — 7-wise GPT-4ランキングペアデータ。DPOによく使われる。
- UltraFeedback — 64Kペアデータ、AIフィードバックベース。
- HelpSteer / HelpSteer2 (NVIDIA) — Helpfulness・Correctness・Coherence・Complexity・Verbosityの5軸スコア。
- Code Alpaca — 20Kコードインストラクション。
- Dolphin (Eric Hartford) — uncensoredデータセットシリーズ。
データの質は量より重要
LIMA論文(Meta, 2023)が示した: 1,000個のよくキュレーションされた例が50,000個の平凡な例よりSFT結果が良い。2026年現在、学習データのキュレーションは「より多く」ではなく「より良く」が標準になった。
15章 · DPO vs PPO — RLHFの進化
InstructGPT(2022)とChatGPT(2022)の時代はPPO(Proximal Policy Optimization)が標準だった。PPOは次のものを要求する: ベースモデル、報酬モデル、リファレンスモデル、actor、critic。4つのモデルを同時にGPUに載せる必要があった — メモリ爆発。
DPOの登場 (2023)
StanfordのRafailov et al.が2023年5月に発表したDPO(Direct Preference Optimization)を一行要約: 「報酬モデルなしに直接ペアデータで方策を最適化せよ」。
数学的にDPOはPPOと同じ最適化を、ペアデータに対する単純な分類損失に変換する。結果:
- 報酬・criticモデルが不要 → GPUメモリ半分。
- 学習が安定 — PPOの報酬ハッキングを回避。
- コードが単純 — 数十行で終わる。
2026年現在の競争
- DPO — 依然としてRLHFのデフォルト。
- ORPO — SFTとDPOを一つに。リファレンスモデル不要。メモリさらに節約。
- KTO — ペアではなく単一ラベルでもアライメント可能。データ収集が楽。
- GRPO — 推論モデル学習に強い(DeepSeek-R1が使用)。
- RLOO — PPOの単純化、効率的。
- SimPO — より単純なペア損失。2024年に台頭。
いつPPOを使うか? ほとんど使わない。2026年現在、PPOは学習インフラがすでによく構築された大きなラボでのみ保存される(例: OpenAI内部)。新規に始めるならDPOやその後継者が答えだ。
16章 · 合成データ — Augmentoolkit, Distilabel, Self-Instruct
良いSFTデータがない?作れ。2026年現在、合成データ生成がファインチューニングの一級市民になった。
Self-Instruct (Wang et al., 2022)
元祖。小さなシードインストラクション175個をLLMに与えて新しいインストラクションを生成させ、再びLLMが答えを作るブートストラップ。Alpaca・Wizard・Magpieの土台。
Augmentoolkit (e-p-armstrong, 2024)
原文テキストからQAペアを生成するパイプライン。PDF・本・内部文書をSFT可能な形式に変換する。
Distilabel (Argilla → Hugging Face, 2024)
Argillaチーム(現Hugging Face所属)が作った合成データフレームワーク。段階的パイプラインを定義する — インストラクション生成、答え生成、AI評価、フィルタリング。UltraFeedbackがDistilabelで作られた。
NeMo Curator (NVIDIA)
大規模データキュレーション — 重複除去、品質フィルタリング、PII除去。事前学習・SFT両方に使われる。
Magpieの技法
Llama-3-Instructに空のプロンプトだけを与えると、モデルが自分で「ユーザの番」を生成する — これをインストラクションとして使い、再びモデルが答える。コスト0(自己生成)で1M以上のデータを作る。短所: モデルのバイアスがそのまま入る。
合成データの落とし穴
- モデル崩壊(model collapse) — 合成データだけで学習し続けると多様性が消える。
- 品質フィルタリングが必須 — AI判定・人間サンプル検査がないとノイズだけが溜まる。
- ライセンス — どのモデルで作った合成データをどこまで使えるか(OpenAI規約など)。
17章 · サービング用の量子化 — GGUF, AWQ, GPTQ, EXL2
ファインチューニングされたモデルをサービングするには量子化が必要だ。学習時のQLoRA 4ビットとは別に、推論時の量子化形式が別途ある。
- GGUF (llama.cpp) — CPU・Apple Silicon・組み込みの標準。Q4_K_M、Q5_K_M、Q8_0など多様な量子化オプション。Ollama、LM Studio、JanがすべてGGUF。
- AWQ (Activation-aware Weight Quantization) — 活性化分布を見て重要な重みを保存する4ビット量子化。サーバGPU推論によく使われる。
- GPTQ — 重みごとのreconstruction error最小化。AWQ以前の標準、いまだに広く使われる。
- EXL2 (ExLlama) — 量子化率をレイヤーごとに変える — 「重要なレイヤーは6ビット、重要でないレイヤーは3ビット」式。同じビットレートで品質最上。
- bitsandbytes 8/4-bit — 学習用量子化。サービングにも使えるが推論速度は上の形式より遅い。
ワークフロー
- fp16/bf16でLoRA学習 → アダプターをベースにマージ。
- マージされたモデルをGGUF (CPU/Mac)、AWQ (サーバGPU)、EXL2 (RTX推論)に変換。
- 変換されたモデルをvLLM、TGI、llama.cpp、Ollamaでサービング。
2026年現在最もよくある流れ: PyTorchでLoRA学習 → マージ → GGUFに量子化 → Ollamaでサービング。
18章 · ハードウェア — H100/H200, A100, 4090/5090, M3/M4, MI300X
ファインチューニングのハードウェアは2026年現在以下の通り。
NVIDIAデータセンター
- H100 (Hopper, 80GB HBM3) — 2022年発売、依然として標準。fp8サポート。一枚約 $30,000。
- H200 (Hopperリフレッシュ, 141GB HBM3e) — 2024年発売。より大きなVRAMとより速い帯域幅。70Bモデルの推論・学習に有利。
- A100 (Ampere, 40/80GB) — 2020年から。依然としてクラウド標準。H100より安く可用性が良い。
- B200/B100 (Blackwell, 2024 GA → 2025本格) — Hopper後継。fp4推論、より大きなチップ。
NVIDIAコンシューマ
- RTX 4090 (24GB GDDR6X) — シングルGPUファインチューニングのコスパ王。7~8B QLoRA学習可能。
- RTX 5090 (32GB GDDR7, 2025) — 次世代。70B QLoRA可能な限界直前。
- RTX 6000 Ada (48GB) — ワークステーション。13~30B学習。
Apple Silicon
- M3 Ultra (192GB UMA, Mac Studio) — 70Bモデルを統合メモリに載せる。
- M4 Max (128GB UMA, MacBook Pro) — ノートで13~30B学習。
- M4 Pro (64GB) — 7~13B学習可能。
AMD
- MI300X (192GB HBM3) — 2023年発表、2024年クラウド採用拡大。ROCm・PyTorchサポート。H100の代替。
- MI325X / MI350 (2025~2026) — 次世代。
どう選ぶか
- 学習頻度少 + 7B/13B → クラウドレンタル(時間単位 3)。
- 毎日学習 + 7B/13B → RTX 4090/5090単一。
- 毎日学習 + 30B/70B → クラウドH100 8-GPUノード。
- データ外部流出禁止 → M3 Ultra Mac Studio (192GB)。
19章 · クラウド — Together, Modal, RunPod, vast.ai, Lambda Labs, Replicate
GPUを買わず借りるのが普通だ。2026年現在の主要オプション。
- Together.ai — ファインチューニングAPI。ファイルアップロード → SFT/DPO/LoRA終了。Llama・Mistral・Qwenなどホスト。事後推論も統合。
- Modal — サーバレスGPU。PythonデコレータでGPU関数を定義。学習スクリプトをクラウドに配置するのが自然。
- RunPod — 時間単位GPUレンタル。4090、A100、H100すべて。価格が最も安い方。PodsとServerless。
- vast.ai — P2P GPUマーケット。最も安い — 他人のGPUを借りる。安定性は貸主によって異なる。
- Lambda Labs — H100 / H200 GPUクラスタに強い。大規模分散学習に親和的。
- Replicate — モデルホスティング中心だが学習APIもある。
- Coreweave — 大規模H100 H200クラスタ。
- Fireworks / Anyscale — サービング中心、学習も一部。
- Hugging Face Endpoints / Inference / AutoTrain — HF生態系に最も自然。
価格感覚 (2026年5月基準、おおよそ)
- A100 80GB: 2/時間 (RunPod, vast.ai)
- H100 80GB: 4/時間
- 8x H100ノード: 30/時間
- 7B QLoRA学習1回 (3 epoch、100K samples): A100で4~8時間、16
20章 · 韓国・日本モデルのファインチューニング
韓国・日本のLLM生態系は、自国のベースモデルビルダーとファインチューニングコミュニティの両方が活発だ。
韓国
- HyperCLOVA X / HyperCLOVA SEED (Naver) — Naverの自社韓国語ベース。2025年のSEED公開で一部の重みを外部に開放。韓国語の語順・敬語・文化的文脈の学習量がグローバルモデルより多い。
- KoLLMシリーズ (Kakao) — Kakaoの韓国語ベース。KakaoTalkデータで強化。
- EXAONE (LG AI Research) — 韓国語・英語ともに強力な32B/8Bベース。オープン重み公開。
- Saltlux Luxia — Saltluxのエンタープライズ韓国語モデル。コールセンター・文書パイプラインに特化。
- Bllossom — 韓国語SFTデータセットとLlamaベースの韓国語ファインチューンモデルシリーズ。コミュニティ主導。
- KULLM (高麗大) — 学界の韓国語LLM。SFTデータセット公開。
日本
- ELYZA-japanese-Llama — Llamaベースに日本語追加事前学習+SFT。自然な日本語出力。
- LINE japanese-large-lm (LY Corporation) — LINEが作った日本語LM。1B / 3.6B / 36Bシリーズ。
- Rinnaシリーズ — 日本語GPT/BERTシリーズ、長い日本語LMビルダー。
- Karakuri-LM — 日本語ビジネスドメイン強化。
- Stockmark — 日本語ビジネスニュース・金融ドメイン。
- CyberAgent OpenCALM — 日本語オープンモデルシリーズ。
- PLaMo (Preferred Networks) — 日本語・英語ベース。
韓・日のファインチューニングパターン
- ベース + 言語アダプター — グローバルベース(Llama・Qwen・Mistral)に韓国語/日本語LoRAを付けるパターンが最も一般的。
- 二重学習 — 英語インストラクションデータに自国語データを混ぜてSFT、その後自国語DPOでトーンアライメント。
- 敬語・敬体のアライメント — 韓国語・日本語ともに話法が豊富でトーンが大きな差別化要因。DPO/KTOがよく使われる。
21章 · どのツールを選ぶべきか — 決定木
最後にまとめ。状況別の推奨組み合わせ。
初めてLoRAをやってみる個人
- ハードウェア: RTX 4090またはRunPod A100 1枚。
- データ: Alpaca、OpenHermesといった入門SFTデータセット。
- ツール: Unsloth + TRL SFTTrainer。コード30行で開始。
- ベース: Llama 3.2 3BまたはMistral 7B。
会社内部データで社内モデル
- ハードウェア: クラウドH100 1~8枚またはM3 Ultra(データ外部禁止時)。
- データ: 社内ウィキ・チケット・顧客問い合わせ変換 + 合成QA(Augmentoolkit)。
- ツール: Axolotl(YAML再現性)またはLLaMA-Factory(Web UI)。
- ベース: Llama 3.x、Qwen 2.5、Mistral 7B/22Bの中でライセンス適合するもの。
韓国語/日本語特化モデル
- ベース: HyperCLOVA SEED、EXAONE、Qwen 2.5(多言語強い)、ELYZA、LINE LMの中で。
- データ: 自国語インストラクション + 英語インストラクション混合(7:3)。
- ツール: Axolotl + DPO。韓国語・日本語のトーンアライメントが大きな差別化要因。
推論(reasoning)モデル
- データ: 数学・コード問題と段階的解法。
- ツール: TRL + GRPO。DeepSeek-R1方式。
- ベース: Qwen 2.5-Math、Llama 3.1 8B/70B。
ノートで小さく
- ハードウェア: M3/M4 Mac。
- ツール: MLX-LM。
- ベース: Mistral 7B、Llama 3.2 3B/8B。
素早いプロトタイプ
- クラウドAPI: Together.aiファインチューニングAPI — ファイルアップロード → 完了。
- 時間: 1時間以内に最初のSFT結果が見える。
22章 · 参考資料
主要論文
- LoRA (Hu et al., 2021) — https://arxiv.org/abs/2106.09685
- QLoRA (Dettmers et al., 2023) — https://arxiv.org/abs/2305.14314
- DoRA (Liu et al., 2024) — https://arxiv.org/abs/2402.09353
- GaLore (Zhao et al., 2024) — https://arxiv.org/abs/2403.03507
- DPO (Rafailov et al., 2023) — https://arxiv.org/abs/2305.18290
- ORPO (Hong et al., 2024) — https://arxiv.org/abs/2403.07691
- KTO (Ethayarajh et al., 2024) — https://arxiv.org/abs/2402.01306
- LIMA (Zhou et al., 2023) — https://arxiv.org/abs/2305.11206
- Magpie (Xu et al., 2024) — https://arxiv.org/abs/2406.08464
- DeepSeek-R1 (DeepSeek, 2025) — https://arxiv.org/abs/2501.12948
ライブラリ公式ドキュメント
- PEFT — https://huggingface.co/docs/peft
- TRL — https://huggingface.co/docs/trl
- Unsloth — https://docs.unsloth.ai/
- Axolotl — https://axolotl.ai/
- LLaMA-Factory — https://github.com/hiyouga/LLaMA-Factory
- MLX-LM — https://github.com/ml-explore/mlx-lm
- Torchtune — https://pytorch.org/torchtune/
- Distilabel — https://distilabel.argilla.io/
- llama.cpp — https://github.com/ggerganov/llama.cpp
韓・日LLM生態系
- HyperCLOVA X — https://www.ncloud.com/product/aiService/clovaStudio
- EXAONE — https://www.lgresearch.ai/exaone
- ELYZA — https://elyza.ai/
- LINE japanese-large-lm — https://engineering.linecorp.com/
エピローグ — ファインチューニングはもう秘密ではない
本稿の一文要約: 2026年のLLMファインチューニングは「ユーザの道具」だ。 LoRAが単純なアダプターから出発してDoRA・GaLoreまで進化する間、UnslothがシングルGPU学習を2倍速くし、AxolotlとLLaMA-Factoryが参入障壁を消した。M3 Ultra Mac Studio一台で70BモデルをLoRAチューニングできる時代になった。
残された問いは「できるか」ではなく**「何を学習させるか」**だ。良いデータ、良い評価、良いユースケース — これが2026年のファインチューニングエンジニアの本当の仕事だ。
「ツールはもはやボトルネックではない。データがボトルネックだ。」
— LLMファインチューニング2026、了。