QLoRAとUnslothでオープンソースLLMをファインチューニング：2026年完全ガイド
GPT-4やClaudeでプロトタイプを作った。うまく動く。そして請求書が届く。先月のAPI費用$12,000。しかも毎月40%ずつ増えてる。
これ、AIエンジニアなら誰もがぶつかる壁なんですよね。プロトタイプから本番環境に移行しようとした瞬間、マネージドAPIのコストは持続不可能になり、レイテンシ要件は厳しくなり、そして気づくんです。インターネット全体の知識じゃなくて、自分のドメインを本当に理解するモデルが必要だって。
その答えがオープンソースLLMのファインチューニングです。QLoRA（Quantized Low-Rank Adaptation）とUnslothのおかげで、A100 GPUのクラスタもMLの博士号もいらなくなりました。VRAM 24GBのコンシューマGPU 1枚、つまりRTX 4090やGoogle Colabの無料T4だけで、数十億パラメータのモデルをあなたのタスクでGPT-4を上回るように仕上げられるんです。
このガイドではゼロから本番デプロイまで全部カバーします。ファインチューニングがなぜ効くのか、QLoRAがコンシューマハードウェアでどう実現しているのか、データセットの準備方法、実際のトレーニングコード、評価戦略、デプロイまで。コード例は全部プロダクション検証済みです。
プロンプティングではなくファインチューニングすべきタイミング
コードに入る前に、ファインチューニングが本当に正しい選択なのはどんな時か、はっきりさせておきましょう。いつも正解ってわけじゃないんです。
プロンプティング / RAG が適している場合：
- タスクが汎用的（要約、翻訳、ドキュメントQ&A）
- データが頻繁に変わる（ナレッジベース、サポートチケット）
- モデルが何をすべきかまだ探索中
- 数日以内にデプロイが必要
ファインチューニングが適している場合：
- プロンプティングでは安定して出力できない特定のスタイル、フォーマット、振る舞いを学習させたい
- 一貫した入出力パターンを持つ明確なタスクがある
- スケールでレイテンシとコストが重要（ファインチューニング済み7Bモデルはトークンあたりの価格がGPT-4の10〜50分の1）
- ドメイン固有の用語を深く理解させたい
- ドメイン固有の事実に関するハルシネーションを減らしたい
本番環境で最もよく見るファインチューニングのユースケース：
| ユースケース | プロンプティングの限界 | ファインチューニングの強み |
|---|---|---|
| 社内API向けコード生成 | モデルが自社SDKを知らない | 自社固有のパターンと慣習を学習 |
| 医療/法律文書分析 | 汎用モデルは慎重すぎる | 自信を持ったドメイン特化出力 |
| 構造化データ抽出 | プロンプトベースのフォーマットは不安定 | 一貫したスキーマ準拠 |
| カスタマーサポートのトーン統一 | システムプロンプトが長い会話でドリフト | 組み込まれた声と個性 |
| カスタムスキーマのSQL生成 | コンテキストにスキーマを入れるとトークン消費 | 内在化されたスキーマ知識 |
ここで大事なポイントがあります。ファインチューニングは新しい知識をモデルに教えるものじゃないんです。新しい振る舞いを教えるものです。ファインチューニングされたモデルはデータベースを丸暗記するんじゃなくて、あなたのドメインのパターンで推論する方法、特定フォーマットで出力する方法、組織の慣習を確実に適用する方法を学ぶんです。
LoRAとQLoRAを理解する
問題：フルファインチューニングはコストがかかりすぎる
従来のフルファインチューニングはモデルのすべてのパラメータを更新します。7Bパラメータモデルの場合：
- メモリ： FP32でモデル重みだけで約28GB、オプティマイザ状態に約28GB、勾配に約28GB。合計：VRAM最低約84GB。
- ハードウェア： A100 80GB GPUが複数枚必要。
- コスト： クラウドGPUインスタンスで時間あたり$10〜50、トレーニングに数時間〜数日。
- リスク： 破壊的忘却（Catastrophic Forgetting）——特定タスクの学習中に汎用能力を失ってしまう。
LoRA：ゲームチェンジャー
LoRA（Low-Rank Adaptation）のコアアイデアはシンプルです。全パラメータを更新する必要はない。 事前学習済みモデルをファインチューニングする時、重み変化は低い内在ランク（low intrinsic rank）を持つ傾向があるんです。つまり更新行列をもっと小さい２つの行列に分解できるというわけです。
d × k次元の重み行列Wを直接更新する代わりに、Wをフリーズして小さい行列A（d × r）とB（r × k）だけを学習します。ここでr（ランク）はdとkよりもずっと小さい：
オリジナル: W (4096 × 4096) → 更新パラメータ16.7M個
LoRA: A (4096 × 16) + B (16 × 4096) → 更新パラメータ131K個
削減率: 学習パラメータ99.2%削減
フォワードパスは output = W·x + α·B·A·x になります。推論時にはB·AをWにマージできるので、元のモデルと比較して追加レイテンシはゼロです。
# LoRAの概念的な実装 import torch import torch.nn as nn class LoRALayer(nn.Module): def __init__(self, original_layer: nn.Linear, rank: int = 16, alpha: float = 32): super().__init__() self.original = original_layer self.original.weight.requires_grad = False # 元の重みをフリーズ d_in = original_layer.in_features d_out = original_layer.out_features # 低ランク分解行列 self.lora_A = nn.Parameter(torch.randn(d_in, rank) * 0.01) self.lora_B = nn.Parameter(torch.zeros(rank, d_out)) self.scale = alpha / rank def forward(self, x): # 元の計算（フリーズ）+ 低ランク更新 original_output = self.original(x) lora_output = (x @ self.lora_A @ self.lora_B) * self.scale return original_output + lora_output def merge(self): """推論時にコストゼロでLoRA重みを元に統合。""" self.original.weight.data += (self.lora_A @ self.lora_B).T * self.scale
QLoRA：誰でもできる時代が来た
QLoRA（Quantized LoRA）が3つのブレイクスルーを起こして、コンシューマハードウェアでのファインチューニングを可能にしました。
-
4ビットNormalFloat（NF4）量子化： ベースモデルを分布認識量子化方式で4ビットに圧縮。7Bモデルが約14GB（FP16）から約3.5GBに。
-
二重量子化： 量子化定数自体も量子化し、パラメータあたり0.37ビット追加節約（7Bモデルで約325MB）。
-
ページドオプティマイザ： GPUメモリが不足した場合、オプティマイザ状態をCPU RAMにオフロード。トレーニング中のOOMクラッシュを防止。
結果：24GB GPUでの7Bモデル、48GB GPUでの13Bモデルのファインチューニングが可能に。 メモリの内訳：
フルファインチューニング（7Bモデル）:
モデル重み（FP32）: ~28 GB
オプティマイザ状態: ~28 GB
勾配: ~28 GB
合計: ~84 GB → A100 80GB × 2が必要
QLoRAファインチューニング（7Bモデル）:
モデル重み（NF4）: ~3.5 GB
LoRAアダプター（FP16）: ~0.1 GB
オプティマイザ状態: ~0.4 GB
勾配 + 活性化: ~4.0 GB
合計: ~8.0 GB → RTX 4090（24GB）で余裕を持って動作
フルファインチューニングとQLoRAの品質差は？ほとんどのベンチマークで1〜2%以内——ハードウェア要件10分の1の削減に対して無視できるレベルのトレードオフです。
環境をセットアップする
ハードウェア要件
| GPU | VRAM | 最大モデルサイズ | トレーニング速度 |
|---|---|---|---|
| T4（Colab Free） | 16GB | 7B（ギリギリ） | 10Kサンプルでエポックあたり約1.5時間 |
| RTX 3090/4090 | 24GB | 7B（余裕）、13B（ギリギリ） | 10Kサンプルでエポックあたり約45分 |
| A100 40GB | 40GB | 13B（余裕）、34B（ギリギリ） | 10Kサンプルでエポックあたり約20分 |
| A100 80GB | 80GB | 70B（アグレッシブ量子化で） | 10Kサンプルでエポックあたり約15分 |
インストール
Unsloth使用（標準HuggingFaceトレーニングの2〜5倍高速）：
# 新しい環境を作成 conda create -n finetune python=3.11 -y conda activate finetune # CUDAサポート付きPyTorchをインストール pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 # Unslothをインストール（bitsandbytes, transformers, peft, trlを自動処理） pip install "unsloth[colab-new] @ git+https://github.com/unslothai/unsloth.git" pip install --no-deps xformers trl peft accelerate bitsandbytes # 評価用 pip install rouge-score nltk scikit-learn
ベースモデルの選択（2026年3月時点）
ベースモデルの選択は思っている以上に重要です。現在の状況：
| モデル | パラメータ | コンテキスト長 | 強み | ライセンス |
|---|---|---|---|---|
| Llama 4 Scout | 109B総 / 17Bアクティブ (MoE) | 10M | 最新Metaフラグシップ、超大規模コンテキスト、H100必要 | Llama 4 Community |
| Llama 3.1 8B | 8B | 128K | 入門者向け品質対サイズ最高比率 | Llama 3.1 Community |
| Mistral Small 4 | 32B | 128K | 多言語、強い推論、Apacheライセンス | Apache 2.0 |
| Gemma 3 27B | 27B | 128K | マルチモーダル、強いコーディング、Google生態系 | Gemma License |
| Qwen 2.5 7B | 7B | 128K | 中国語＋英語バイリンガル最適 | Apache 2.0 |
| Phi-4 14B | 14B | 16K | コンパクト、強い推論 | MIT |
初めての方への推奨： Llama 3.1 8Bから始めましょう。コミュニティが最大で、チュートリアルが最も多く、リソース対品質比が最高です。パイプラインが動いたら、その時にLlama 4 ScoutやGemma 3 27Bに切り替えてください。Llama 4 ScoutはMoE（Mixture-of-Experts）アーキテクチャを使用しており、総109Bパラメータですがトークンあたりアクティブなのは17Bだけ——見かけ以上に効率的です。
データセットを準備する
ここでファインチューニングプロジェクトの成否が分かれます。モデルは与えるデータの品質に依存します。500個の優れた品質のサンプルが50,000個の凡庸なサンプルに勝ちます。
データフォーマット：チャットテンプレート
現代のファインチューニングは会話型フォーマット（チャットテンプレート）を使います：
{ "conversations": [ {"role": "system", "content": "PostgreSQL最適化を専門とするシニアバックエンドエンジニアです。"}, {"role": "user", "content": "5000万行のテーブルでこのクエリが30秒かかっています：\n\nSELECT * FROM orders WHERE customer_id = 12345 AND status = 'pending' ORDER BY created_at DESC LIMIT 10;"}, {"role": "assistant", "content": "複合インデックスが足りないのが原因ですね。分析してみましょう：\n\n**問題：** `(customer_id, status, created_at)` のインデックスがないため、PostgreSQLが5000万行のシーケンシャルスキャンを実行し、結果をソートしています。\n\n**解決策：**\n```sql\nCREATE INDEX CONCURRENTLY idx_orders_customer_status_created\nON orders (customer_id, status, created_at DESC);\n```\n\n**なぜ効果的か：**\n1. WHEREとORDER BYの3カラムすべてをカバーするインデックス\n2. インデックスの`created_at DESC`がORDER BYと一致し、ソート操作を排除\n3. `SELECT *`を特定カラムに変えればIndex Only Scanが可能\n4. `CONCURRENTLY`で作成中のテーブルロックを防止\n\n**予想改善：** このクエリパターンで約30秒→10ms未満。"} ] }
データ品質チェックリスト
トレーニング前にデータセットをこの基準で監査してください：
def audit_dataset(dataset): issues = [] for i, example in enumerate(dataset): conversations = example['conversations'] # チェック1: 最小会話長 if len(conversations) < 2: issues.append(f"Example {i}: 2ターン未満") # チェック2: 応答品質（長さプロキシ） assistant_msgs = [c for c in conversations if c['role'] == 'assistant'] for msg in assistant_msgs: if len(msg['content']) < 50: issues.append(f"Example {i}: 応答が非常に短い ({len(msg['content'])} chars)") if len(msg['content']) > 8000: issues.append(f"Example {i}: 応答が非常に長い ({len(msg['content'])} chars)") # チェック3: 空メッセージなし for c in conversations: if not c['content'].strip(): issues.append(f"Example {i}: {c['role']}の空メッセージ") # チェック4: ロール交互確認 roles = [c['role'] for c in conversations if c['role'] != 'system'] for j in range(1, len(roles)): if roles[j] == roles[j-1]: issues.append(f"Example {i}: 連続した{roles[j]}メッセージ") # チェック5: データ漏洩チェック for c in conversations: if any(phrase in c['content'].lower() for phrase in ['as an ai', 'i am an ai', 'language model']): issues.append(f"Example {i}: {c['role']}メッセージでの身元漏洩の可能性") return issues
必要なサンプル数の目安
タスクによって変わります：
| タスクタイプ | 最低 | 適正 | 収穫逓減 |
|---|---|---|---|
| スタイル/トーン適応 | 50〜100 | 200〜500 | >1,000 |
| ドメイン特化Q&A | 200〜500 | 1,000〜3,000 | >10,000 |
| コード生成（特定SDK） | 500〜1,000 | 2,000〜5,000 | >15,000 |
| 複雑な推論チェーン | 1,000〜2,000 | 5,000〜10,000 | >20,000 |
80/10/10ルール：
- 80%トレーニング用
- 10%バリデーション用（トレーニング中のオーバーフィッティング監視）
- 10%最終評価用（トレーニング中は絶対に見せない）
from datasets import load_dataset, DatasetDict def prepare_splits(dataset_path): dataset = load_dataset("json", data_files=dataset_path, split="train") dataset = dataset.shuffle(seed=42) # 80/10/10分割 train_test = dataset.train_test_split(test_size=0.2, seed=42) val_test = train_test['test'].train_test_split(test_size=0.5, seed=42) return DatasetDict({ 'train': train_test['train'], 'validation': val_test['train'], 'test': val_test['test'], })
合成トレーニングデータの生成
サンプルが不足している場合、強力なモデル（GPT-4、Claude）を使って小さいモデル用のトレーニングデータを生成できます。この手法は合成データによる知識蒸留と呼ばれ、プロダクション環境で広く使われています。
import openai import json SYSTEM_PROMPT = """PostgreSQL最適化の専門家として動作するファインチューニングモデルの トレーニングデータを生成しています。 PostgreSQLのパフォーマンス問題に関するリアルなユーザー質問と エキスパートレベルの回答を生成してください： - リアルなテーブル名とサイズを持つ具体的なSQLクエリ - EXPLAIN ANALYZE出力の解釈 - CREATE INDEX文を含む具体的なインデックス推奨 - パフォーマンス改善の見積もり 各回答はコード例付きで200-500語であること。""" async def generate_training_examples(n_examples: int = 500): client = openai.AsyncOpenAI() examples = [] topics = [ "大テーブルでの遅いJOINクエリ", "ORMでのN+1クエリ問題", "インデックス付きカラムでのフルテーブルスキャン", "高書き込みシナリオでのロック競合", "VACUUM後のクエリプラン退行", "コネクションプール枯渇", "インデックスブロートの検出と修復", ] for i in range(n_examples): topic = topics[i % len(topics)] response = await client.chat.completions.create( model="gpt-4o", messages=[ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": f"トピック：{topic}についてトレーニング例を生成してください。" f"複雑度とテーブルスキーマを多様化してください。"} ], temperature=0.9, response_format={"type": "json_object"}, ) example = json.loads(response.choices[0].message.content) examples.append(example) return examples
重要な注意点： 合成データのサンプルを必ず手動でレビューしてください。LLMはもっともらしく聞こえるが技術的に間違ったアドバイスを生成することがあります。合成サンプルの最低10〜20%は人間によるレビュー時間を確保すべきです。
Unslothでトレーニングする
いよいよメインイベントです。完全なトレーニングスクリプトをお見せします：
from unsloth import FastLanguageModel from trl import SFTTrainer from transformers import TrainingArguments from datasets import load_dataset # ───────────────────────────────────────── # 1. 4ビット量子化でモデルをロード # ───────────────────────────────────────── model, tokenizer = FastLanguageModel.from_pretrained( model_name="unsloth/Meta-Llama-3.1-8B-Instruct", max_seq_length=4096, # トレーニング用最大シーケンス長 dtype=None, # 自動検出：旧GPUはfloat16、Ampere+はbfloat16 load_in_4bit=True, # QLoRA：4ビットNF4でベースモデルをロード ) # ───────────────────────────────────────── # 2. LoRAアダプターを設定 # ───────────────────────────────────────── model = FastLanguageModel.get_peft_model( model, r=32, # LoRAランク — 高いほど容量↑、VRAM↑ lora_alpha=64, # スケーリングファクター — 通常ランクの2倍 target_modules=[ # 適応するレイヤー "q_proj", "k_proj", "v_proj", "o_proj", # Attentionレイヤー "gate_proj", "up_proj", "down_proj", # MLPレイヤー ], lora_dropout=0.05, # わずかなドロップアウトで正則化 bias="none", # バイアス項は学習しない use_gradient_checkpointing="unsloth", # 長いコンテキストでVRAM 60%節約 random_state=42, ) # 学習可能パラメータを確認 model.print_trainable_parameters() # 出力: trainable params: 83,886,080 || all params: 8,113,831,936 || trainable%: 1.034% # ───────────────────────────────────────── # 3. データセットをロードしてフォーマット # ───────────────────────────────────────── dataset = load_dataset("json", data_files="training_data.jsonl", split="train") def format_chat(example): """会話をLlama 3チャットテンプレートにフォーマット。""" messages = example['conversations'] text = tokenizer.apply_chat_template( messages, tokenize=False, add_generation_prompt=False, ) return {"text": text} dataset = dataset.map(format_chat, remove_columns=dataset.column_names) # ───────────────────────────────────────── # 4. トレーニングを設定 # ───────────────────────────────────────── training_args = TrainingArguments( output_dir="./outputs", per_device_train_batch_size=4, # VRAMに応じて調整 gradient_accumulation_steps=4, # 実効バッチサイズ = 4 * 4 = 16 num_train_epochs=3, # 2-4エポックが一般的 learning_rate=2e-4, # QLoRA標準値 lr_scheduler_type="cosine", # ウォームアップ付きコサイン減衰 warmup_ratio=0.05, # 全ステップの5%をウォームアップに weight_decay=0.01, # 軽い正則化 logging_steps=10, save_strategy="steps", save_steps=100, eval_strategy="steps", eval_steps=100, fp16=not torch.cuda.is_bf16_supported(), bf16=torch.cuda.is_bf16_supported(), optim="adamw_8bit", # 8ビットAdamでVRAM節約 seed=42, max_grad_norm=0.3, # 安定性のための勾配クリッピング report_to="wandb", # オプション：Weights & Biasesロギング ) # ───────────────────────────────────────── # 5. トレーナーを初期化して開始 # ───────────────────────────────────────── trainer = SFTTrainer( model=model, tokenizer=tokenizer, train_dataset=dataset, args=training_args, max_seq_length=4096, dataset_text_field="text", packing=True, # 短いサンプルをパッキングして効率化 ) print("ファインチューニング開始...") stats = trainer.train() print(f"トレーニング完了: {stats.metrics['train_runtime']:.0f}秒") print(f"最終ロス: {stats.metrics['train_loss']:.4f}")
ハイパーパラメータチューニングガイド
上のデフォルト値はほとんどのケースでうまく動きますが、チューニングが必要な場合のガイドです：
LoRAランク（r）：
r=8：最小限の適応。シンプルなスタイル変更に適合。r=16：デフォルト。ほとんどのタスクに適合。r=32：高い容量。複雑なドメイン適応に適合。r=64+：フルファインチューニングに近い容量。ほとんど不要。
目安：r=16から始めてください。バリデーションロスが早く停滞したら32に上げ、すぐにオーバーフィットするなら8に下げましょう。
学習率：
2e-4：QLoRA標準。ここから開始。1e-4：より保守的。トレーニングが不安定な場合。5e-5：非常に保守的。非常に小さいデータセット（<200サンプル）向け。
エポック数：
- 1〜2：大規模データセット（>10Kサンプル）
- 2〜4：中規模データセット（1K〜10Kサンプル）
- 4〜8：小規模データセット（<1Kサンプル）
- オーバーフィッティングに注意： バリデーションロスが上がり始めたのにトレーニングロスは下がり続けている場合、オーバーフィッティングです。トレーニングを止めてください。
from transformers import EarlyStoppingCallback trainer = SFTTrainer( model=model, tokenizer=tokenizer, train_dataset=train_dataset, eval_dataset=val_dataset, # 重要：バリデーションセットを提供 args=training_args, callbacks=[ EarlyStoppingCallback( early_stopping_patience=3, # 3回の評価ステップで改善なければ停止 early_stopping_threshold=0.01 # 最小改善閾値 ), ], max_seq_length=4096, dataset_text_field="text", packing=True, )
トレーニングロスカーブの正常値
健全なトレーニングはこのように推移します：
Loss
4.0 |X
| X
3.0 | X
| X
2.0 | X X
| X X X
1.0 | X X X X X X ← プラトー（良い、収束した）
|
0.0 +─────────────────────────────────────
0 200 400 600 800 1000
Steps
危険シグナル：
- ロスが下がらない → 学習率が低すぎるかデータに問題
- ロスが0付近まで落ちる → 深刻なオーバーフィッティング、エポック削減またはデータ追加
- ロスが非常にノイジー → バッチサイズが小さすぎるか学習率が高すぎる
- ロスが突然急上昇 → 勾配爆発、学習率を下げる
モデルを評価する
トレーニングは半分に過ぎません。評価がファインチューニングモデルがベースモデルを実際に改善したかどうかを教えてくれます。
自動評価
import torch from rouge_score import rouge_scorer import json def evaluate_model(model, tokenizer, test_dataset, max_samples=100): """ファインチューニングモデルの総合評価。""" model.eval() scorer = rouge_scorer.RougeScorer(['rouge1', 'rougeL'], use_stemmer=True) results = { 'rouge1_scores': [], 'rougeL_scores': [], 'format_compliance': [], 'avg_response_length': [], 'examples': [], } for i, example in enumerate(test_dataset.select(range(min(max_samples, len(test_dataset))))): conversations = example['conversations'] prompt_messages = [] expected_response = "" for msg in conversations: if msg['role'] == 'assistant' and msg == conversations[-1]: expected_response = msg['content'] else: prompt_messages.append(msg) inputs = tokenizer.apply_chat_template( prompt_messages, tokenize=True, add_generation_prompt=True, return_tensors="pt" ).to(model.device) with torch.no_grad(): outputs = model.generate(inputs, max_new_tokens=1024, temperature=0.1, do_sample=False) generated = tokenizer.decode(outputs[0][inputs.shape[1]:], skip_special_tokens=True) rouge_scores = scorer.score(expected_response, generated) results['rouge1_scores'].append(rouge_scores['rouge1'].fmeasure) results['rougeL_scores'].append(rouge_scores['rougeL'].fmeasure) results['avg_response_length'].append(len(generated)) expected_has_code = '```' in expected_response generated_has_code = '```' in generated results['format_compliance'].append(expected_has_code == generated_has_code) if i < 10: results['examples'].append({ 'prompt': prompt_messages[-1]['content'][:200], 'expected': expected_response[:300], 'generated': generated[:300], 'rouge1': rouge_scores['rouge1'].fmeasure, }) summary = { 'avg_rouge1': sum(results['rouge1_scores']) / len(results['rouge1_scores']), 'avg_rougeL': sum(results['rougeL_scores']) / len(results['rougeL_scores']), 'format_compliance_rate': sum(results['format_compliance']) / len(results['format_compliance']), 'avg_response_length': sum(results['avg_response_length']) / len(results['avg_response_length']), 'examples': results['examples'], } return summary
LLM-as-Judge評価
主観的な品質評価には、より強力なモデルを審判として活用します：
async def llm_judge_evaluation(examples, judge_model="gpt-4o"): """強力なLLMを使って応答品質を評価。""" client = openai.AsyncOpenAI() scores = [] for ex in examples: response = await client.chat.completions.create( model=judge_model, messages=[{ "role": "system", "content": """ファインチューニングモデルの応答品質を評価しています。 以下の次元で各応答を評価してください（1-5点）： 1. 技術的正確性：技術的主張は正しいか？ 2. 完全性：質問のすべての側面を扱っているか？ 3. フォーマット準拠：期待される出力フォーマットに従っているか？ 4. 実行可能性：ユーザーがすぐに適用できるか？ JSONで回答: {"accuracy": N, "completeness": N, "format": N, "actionability": N, "reasoning": "..."}""" }, { "role": "user", "content": f"質問: {ex['prompt']}\n\n回答: {ex['finetuned_response']}" }], response_format={"type": "json_object"}, ) score = json.loads(response.choices[0].message.content) scores.append(score) return scores
モデルの保存とデプロイ
保存オプション
トレーニング後、3つの保存オプションがあります：
# オプション1：LoRAアダプターのみ保存（~100-300MB） model.save_pretrained("./my-lora-adapter") tokenizer.save_pretrained("./my-lora-adapter") # オプション2：統合して16ビットで完全モデル保存（~14GB for 7B） model.save_pretrained_merged("./my-model-merged", tokenizer, save_method="merged_16bit") # オプション3：llama.cpp / Ollama用にGGUFエクスポート model.save_pretrained_gguf("./my-model-gguf", tokenizer, quantization_method="q4_k_m") # オプション4：Hugging Face Hubにプッシュ model.push_to_hub("your-username/my-fine-tuned-model", token="hf_...") tokenizer.push_to_hub("your-username/my-fine-tuned-model", token="hf_...")
vLLMでデプロイ（本番推奨）
vLLMは本番LLMサービングの標準です：
import openai client = openai.OpenAI(base_url="http://localhost:8000/v1", api_key="dummy") response = client.chat.completions.create( model="./my-model-merged", messages=[ {"role": "system", "content": "PostgreSQL最適化の専門家です。"}, {"role": "user", "content": "1億行のテーブルでシーケンシャルスキャンが発生しています..."}, ], temperature=0.3, max_tokens=1024, ) print(response.choices[0].message.content)
Ollamaでデプロイ（ローカル/エッジ）
ローカル開発やエッジデプロイには、GGUFにエクスポートしてOllamaを使います：
cat > Modelfile << 'EOF' FROM ./my-model-gguf/unsloth.Q4_K_M.gguf TEMPLATE """{{ if .System }}<|start_header_id|>system<|end_header_id|> {{ .System }}<|eot_id|>{{ end }}<|start_header_id|>user<|end_header_id|> {{ .Prompt }}<|eot_id|><|start_header_id|>assistant<|end_header_id|> """ PARAMETER temperature 0.3 PARAMETER num_ctx 4096 SYSTEM "PostgreSQL最適化の専門家です。" EOF ollama create my-pg-expert -f Modelfile ollama run my-pg-expert "遅いGROUP BYクエリのチューニング方法は？"
本番チェックリスト
デプロイ前
- 評価スコアがベースラインを超過： テストセットでベースモデルを有意な差で上回る
- 破壊的忘却なし： 汎用タスクでもテストして基本能力の維持を確認
- ガードレール設置： 有害、バイアス、スコープ外の出力テスト、コンテンツフィルタリング実装
- レイテンシベンチマーク： 現実的な負荷下でP50、P95、P99レイテンシを測定
- コスト見積もり： GPUコンピュート含むリクエストあたりコストを計算、APIベース代替案と比較
デプロイ後モニタリング
- 出力品質の経時追跡： 本番リクエストのランダムサンプルで自動評価を設定
- 分布ドリフト監視： ユーザークエリがトレーニングデータと変化し始めたらモデル品質が低下する
- モデルのバージョニング： セマンティックバージョニング（v1.0.0、v1.1.0）使用、ロールバック能力維持
- リトレーニング頻度： 本番データが蓄積されるに伴い定期的リトレーニングを計画
よくある落とし穴と回避方法
落とし穴1：悪いデータでの学習
症状： もっともらしく聞こえるが事実と異なる応答を生成。
原因： 人間のレビューなしに合成トレーニングデータを使用。
対策： ドメイン専門家に最低10%のトレーニングデータを必ずレビューさせる。1つの誤った例が数百の関連出力を汚染する。
落とし穴2：小さいデータセットでのオーバーフィッティング
症状： トレーニングロスが0に近づくが、出力がパターン化し、トレーニング例をそのまま暗記しているように見える。
原因： 少ないサンプルに対してエポックが多すぎる。
対策： エポック削減、LoRAドロップアウトを0.1に増加、より低いLoRAランク使用、またはデータセット拡充。
落とし穴3：チャットテンプレートの不一致
症状： モデルがゴミ出力、トークン繰り返し、またはシステムプロンプトを無視。
原因： トレーニング時と推論時で異なるチャットテンプレートを使用。
対策： トレーニングデータのフォーマットと推論プロンプト構築の両方で必ずtokenizer.apply_chat_template()を使用する。手動でチャットプロンプトを構築しないこと。
落とし穴4：破壊的忘却
症状： 特定タスクは良好だが、ファインチューニング前にできた基本タスクができなくなる。
原因： 汎用知識を上書きする攻撃的なファインチューニング。
対策： より低い学習率（2e-4の代わりに5e-5）、より少ないエポック、または汎用データの混合（トレーニングセットの10〜20%を汎用サンプルに）。
落とし穴5：量子化効果の無視
症状： FP16ではうまく動くファインチューニングモデルがGGUF量子化後に大幅劣化。
原因： 設計されていないモデルへのアグレッシブな量子化（Q2_K、Q3_K）。
対策： デプロイ量子化にはQ4_K_MまたはQ5_K_Mを使用。量子化後に必ずベンチマークして品質維持を確認する。
コスト比較：ファインチューニング vs API
現実的な本番シナリオで計算してみましょう：
シナリオ： 月100,000リクエスト、平均入力500トークン＋出力500トークン。
| アプローチ | 月額コスト | レイテンシ（P50） | コントロール |
|---|---|---|---|
| GPT-4o API | ~$1,500 | 800ms | 低 |
| Claude 3.5 Sonnet API | ~$1,800 | 600ms | 低 |
| GPT-4o-mini API | ~$30 | 400ms | 低 |
| セルフホスト Llama 3.1 8B（A10G） | ~$350 | 120ms | 完全 |
| セルフホスト ファインチューニング 8B（A10G） | ~$350 | 120ms | 完全 + ドメイン専門性 |
ファインチューニングモデルの運用コストはベースモデルと同じですが、ドメイン特化の出力品質はより高くなります。
損益分岐点： ほとんどのチームで、月30,000〜50,000リクエスト前後からセルフホスティングがAPI呼び出しより安くなります。
2026年の注目すべき新技術
Unsloth Studio（2026年3月）： Unslothがオープンソースのノーコードインターフェイスをリリースしました。データ準備、トレーニング、デプロイを単一のGUIで処理できます。VRAM 70%削減、2倍高速なトレーニングを目指しています。上記のPythonスクリプトがハードルに感じる方には、参入障壁を大幅に下げるツールです。
DoRA（Weight-Decomposed Low-Rank Adaptation）： 重み更新で大きさと方向を分離する2024年のイノベーション。LoRAを1〜3%一貫して上回り、追加オーバーヘッドは無視できるレベル。PEFTライブラリに統合済み。
GaLore（Gradient Low-Rank Projection）： 勾配を低ランク空間に射影することで、LoRAレベルのメモリコストでフルファインチューニング品質を実現。まだ実験段階だが有望。
LoRAマージとModel Soups： 複数のLoRAアダプター（それぞれ異なるタスクで学習）を重み平均で1つのモデルに統合。別々のモデルデプロイなしでマルチタスク特化が可能。
GRPO（Group Relative Policy Optimization）： マルチステップロジックとチェインオブソートを実行する「推論AI」モデルを学習させる技法。UnslothはVRAM 5GBだけでGRPOをサポート。DeepSeek-R1のような次世代推論モデルがこの方式で学習されています。
報酬モデルファインチューニング（RLHF/DPO）： SFT後にDirect Preference Optimization（DPO）を使った2番目のトレーニングパスで、モデル出力を人間の好みに合わせる。
# SFT後のDPOトレーニング（スケッチ） from trl import DPOTrainer, DPOConfig dpo_config = DPOConfig( output_dir="./dpo-output", beta=0.1, # KLダイバージェンスペナルティ強度 learning_rate=5e-6, # SFTよりずっと低く per_device_train_batch_size=2, num_train_epochs=1, ) dpo_trainer = DPOTrainer( model=sft_model, ref_model=None, # PEFTで暗黙的参照を使用 args=dpo_config, train_dataset=preference_dataset, tokenizer=tokenizer, ) dpo_trainer.train()
まとめ
オープンソースLLMのファインチューニング、もはや研究室だけの話じゃなくなりました。QLoRAとUnslothがあれば、コンシューマGPU 1枚、1時間以内で、あなたのタスクでGPT-4を上回るモデルが作れます。
大事な原則をまとめます：
- 量より質。 500個の良質なサンプルが50,000個のそれなりなサンプルに勝ちます。
- 小さく始める。 最小限のデータセットでLlama 3.1 8B + QLoRAから。パイプラインが動いたらスケールアップ。
- 評価は弹まなく。 自動メトリクス（ROUGE、フォーマット準拠）+ LLM-as-judge + 手動レビュー。３つ全部やりましょう。
- 本番環境のモニタリングは必須。 ユーザークエリが変わればモデル性能もドリフトします。定期的なリトレーニングを計画しましょう。
- ファインチューニングしないべき時を見極める。 RAGやプロンプティング改善で解決するなら、そっちの方が安くて速いです。
クローズドソースとオープンソースの差は毎月縮まっています。このガイドのテクニックで、APIより安く、速く、プライベートで、かつ特化した本番AIシステムを構築できます。
関連ツールを見る
Pockitの無料開発者ツールを試してみましょう