友田 陽大
日本語English
Llama & open-weight LLMs
Llama
ファインチューニング
LoRA
生成AI
AWS Bedrock
Python
MLOps

Llama ファインチューニング実践：LoRA/QLoRA で自社データに特化させ本番投入する

オープンウェイトの強みは『重みを自社データで微調整できる』こと。Llama を LoRA/QLoRA でファインチューニングする手順を、まず『本当に必要か（RAG vs FT）』の判断から、データ準備・torchtune/TRL実装・評価ゲート・マージ＆デプロイ・ライセンス命名規約まで、本番運用の観点で実コードで解説します。

Published
Last updated
Updated
Reading time
10 min read
Author
友田 陽大
Chia sẻ
Mục lục

この記事のゴール

Llama を本番投入する全体像で述べたとおり、オープンウェイトを選ぶ最大の理由のひとつが「重みを自社データで微調整（ファインチューニング, FT）できる」ことです。本稿はその FT を、デモではなく本番——再現性・評価・コスト・ライセンスまで——の観点で、実コードで最後まで通します。

読み終えたとき、次の3つができる状態を目指します。

  1. そもそも FT が必要かを判断できる（多くの場合は RAG で足りる、を含めて）。
  2. LoRA/QLoRA で実際に回せる（torchtune と Hugging Face TRL の両経路）。
  3. 評価ゲートを通してから安全にデプロイでき、ライセンスの命名規約まで守れる。

信頼性の開示：私は AWS Bedrock / Vercel AI SDK を土台に生成AIシステムを本番運用しており、ドメイン特化（型番・専門語彙・出力フォーマットの固定）は音声接客の事例でも中心的な課題でした。本稿は「FT は最後の手段」という実務の順序に忠実です。盛った精度向上の数字は出しません。

まず疑う：その課題、本当にFTが要りますか？

FT は強力ですが、最初に手を出すべき道具ではありません。コスト・運用負荷・陳腐化リスクが大きいからです。次の順で検討してください。

手法効くもの効かないものコスト/運用
プロンプト/Few-shot形式の指示、簡単な振る舞い大量の知識、強い様式固定最小
RAG（検索拡張）最新知識・社内文書の参照、出典提示口調・出力様式の根本変更中（pgvector RAG）
ファインチューニング振る舞い・出力形式・口調・専門語彙の固定、レイテンシ短縮知識の鮮度（学習時点で凍結）大（データ・学習・評価・再学習）

鉄則：

  • 知識を足したい → まず RAG。モデルの中に事実を焼き込むのは陳腐化と幻覚の温床。
  • いつも同じ形式・口調・判断で答えさせたい、プロンプトが長くなりすぎた、専門語彙の取りこぼしを消したい → FT の出番。
  • 実務では RAG ＋ 軽い FT の併用が最も費用対効果が高い（知識は RAG、様式は FT）。

💡 「FT すれば賢くなる」は誤解です。FT が変えるのは主に振る舞いの分布であって、新しい事実の信頼できる記憶ではありません。事実は RAG に持たせるのが本番の定石です。

何を、どう微調整するか（現実的な対象とLoRA/QLoRA）

対象モデル：まず密モデルから

Llama 4 は MoEで総パラメータが巨大（Scout 109B / Maverick 400B）です。これをフルFTするのは相当な分散学習基盤を要し、最初の一歩には向きません。実務の現実的な対象は密（dense）モデル——Llama 3.3 8B / 70B や用途特化の小型版——で、ここに LoRA/QLoRA を当てるのが王道です。

LoRA と QLoRA を一言で

  • LoRA（Low-Rank Adaptation）：巨大な重みを凍結し、小さな低ランク行列だけを学習する。更新対象がごく一部なので、省メモリ・高速・成果物（アダプタ）が数十MB。
  • QLoRA：ベースモデルを 4bit 量子化して載せ、その上で LoRA を学習する。単一GPUでも 70B 級に手が届くのが利点。精度劣化は実用上小さいことが多い。
手法メモリ速度成果物向く場面
フルFT最大最遅モデル全体大規模・基盤を作り替える
LoRA小速アダプタ（小）標準。様式・語彙の固定
QLoRA最小速アダプタ（小）単一GPUで大きめモデル

データ準備：成否の9割はここ

FT の品質はデータの品質で決まります。モデルやハイパラの差は誤差です。

  • 形式：instruction/chat 形式の JSONL。1行＝1サンプル。
  • 品質 > 量：ノイズだらけの10万件より、手で磨いた1,000件。誤りは“正しく学習されてしまう”。
  • 重複排除：near-dup を除く。同じ例の重複は過学習を招く。
  • train/eval 分割：必ず評価用を切り分ける。これを混ぜると「自分の宿題を採点」する状態（リーク）になり、精度を錯覚する。
  • 多様性：本番で来る入力分布をカバーする。エッジケース・断り方（「分かりません」）も学習対象に入れる。
{"messages":[
  {"role":"system","content":"あなたは当社の見積もりアシスタント。数値は推測せず、無い情報は『不明』と返す。"},
  {"role":"user","content":"型番 TX-200 の標準納期は？"},
  {"role":"assistant","content":"TX-200 の標準納期は5営業日です。在庫状況により前後します。"}
]}

⚠️ リークは“静かに”精度を盛る最悪のバグ。評価セットの一部が学習に混ざると、ベンチは上がるのに本番で滑ります。分割は最初に、決定的に（ハッシュで振り分ける等）行ってください。

実装A：torchtune（PyTorchネイティブ・公式）

Meta/PyTorch 公式の torchtune は、「トレーナも抽象も挟まない、素のPyTorch」が思想です。YAML で recipe を設定し、CLI で回します。

pip install torchtune

# 重みを取得（ライセンス同意済みのHFアカウントが必要）
tune download meta-llama/Llama-3.3-70B-Instruct \
  --output-dir ./Llama-3.3-70B-Instruct

# LoRA で単一デバイス学習（recipe と config を指定するだけ）
tune run lora_finetune_single_device \
  --config llama3_3/70B_lora_single_device \
  dataset.source=json \
  dataset.data_files=./data/train.jsonl

torchtune は config に学習率・LoRA rank・エポック・量子化などが宣言的にまとまっており、差分管理（誰がどの設定で回したか）が効きます。これは再現性＝本番運用の生命線です。

実装B：Hugging Face TRL + PEFT（QLoRA）

最も普及している経路。TRL の SFTTrainer に PEFT の LoraConfig を渡すだけで QLoRA になります。

# pip install trl peft transformers bitsandbytes datasets
import torch
from datasets import load_dataset
from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig
from peft import LoraConfig
from trl import SFTTrainer, SFTConfig

MODEL_ID = "meta-llama/Llama-3.3-70B-Instruct"  # 密モデルが現実的な対象

# QLoRA：ベースを 4bit(NF4) で載せる＝単一GPUでも大きめモデルに届く
bnb = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.bfloat16,
)
model = AutoModelForCausalLM.from_pretrained(MODEL_ID, quantization_config=bnb, device_map="auto")
tokenizer = AutoTokenizer.from_pretrained(MODEL_ID)

# 学習するのは低ランクのアダプタだけ。注意機構の射影行列を対象にするのが定番。
lora = LoraConfig(
    r=16, lora_alpha=32, lora_dropout=0.05,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
    task_type="CAUSAL_LM",
)

dataset = load_dataset("json", data_files={"train": "data/train.jsonl"})["train"]

trainer = SFTTrainer(
    model=model,
    train_dataset=dataset,
    peft_config=lora,
    args=SFTConfig(
        output_dir="out/llama-domain-lora",
        num_train_epochs=2,                 # 入れすぎは過学習。1〜3で様子を見る
        per_device_train_batch_size=1,
        gradient_accumulation_steps=8,      # 実効バッチを稼ぐ
        learning_rate=2e-4,
        bf16=True,
        logging_steps=10,
        save_strategy="epoch",
    ),
)
trainer.train()
trainer.save_model("out/llama-domain-lora")  # 成果物はアダプタ（小さい）

ポイントは 学習するのがアダプタだけなこと。ベース 70B は凍結・4bit のまま動くので、必要VRAMが現実的な水準に収まります。

実装C：マネージド（運用を AWS に寄せる）

学習基盤を持ちたくないなら AWS にマネージドで寄せます。

  • Bedrock のマネージドFT：本稿執筆時点で Llama 2 / Llama 3.2（Vision 含む）等が対象。学習データを S3 に置き、コンソール/APIでジョブを回すとカスタムモデルが払い出される。GPU 運用ゼロ。
  • SageMaker ＋ Bedrock Custom Model Import：torchtune/TRL で作った重み（Llama 2/3/3.1/3.2 系アーキ）を Bedrock に取り込み、既存の Converse API でそのまま叩く。

📌 正確性のための注記：マネージドFTの対応モデル・リージョンは更新されます。最新は Bedrock のモデルカスタマイズ対応表 を必ず確認してください。「やりたいモデルがマネージドFTの対象か」を先に確かめるのが事故防止になります。

評価ゲート：これ無しに本番へ出さない

FT で最も危険なのは「なんとなく良くなった気がする」で出すことです。ホールドアウトでFT前後を機械比較し、回帰を検出してから初めてデプロイします。

# evaluate.py — ベース vs FT後 を同じ評価セットで比較し、合否を判定する
import json, statistics
from typing import Callable

def run_eval(generate: Callable[[str], str], eval_path: str) -> float:
    """各サンプルを採点し平均スコアを返す。採点は完全一致/数値一致/LLM-judge等、用途で選ぶ。"""
    scores = []
    with open(eval_path) as f:
        for line in f:
            ex = json.loads(line)
            out = generate(ex["input"])
            scores.append(score(out, ex["expected"]))  # 0.0〜1.0
    return statistics.mean(scores)

base = run_eval(generate_base, "data/eval.jsonl")
tuned = run_eval(generate_tuned, "data/eval.jsonl")

# 改善が閾値未満、または既存能力の回帰があれば“不合格”としてデプロイを止める。
assert tuned >= base + 0.03, f"改善不足: base={base:.3f} tuned={tuned:.3f}"
print(f"PASS base={base:.3f} -> tuned={tuned:.3f}")

評価は用途に合わせた採点関数が肝です。構造化出力なら完全一致/スキーマ準拠率、要約なら LLM-judge、分類なら F1。「本番で何が正解か」を数値化できて初めて、FT は工学になります。

デプロイとライセンス（命名規約に注意）

  1. アダプタをマージ：LoRA アダプタをベースに統合し、単一の重みにする（推論を軽くするため）。
  2. サーブ：vLLM で自前サーブするか、Bedrock Custom Model Import で Converse から叩く。
  3. コストを見積もる：自前運用は推論コストの設計で損益分岐を出してから。

⚖️ ライセンス必読：Llama Community License では、Llama を使って作った派生モデルを配布・提供する場合、モデル名の先頭に「Llama」を付けることが求められます（例：Llama-YourCompany-Support-8B）。さらに Built with Llama 表示が必要です。社内利用のみなら配布には当たりませんが、外部提供する瞬間に命名・表示義務が発生します。詳細はピラー記事のライセンス章を参照してください。

よくある落とし穴

  • 破滅的忘却（catastrophic forgetting）：特化に振りすぎて、元の汎用能力が落ちる。汎用タスクも評価セットに混ぜて回帰を監視する。
  • 過学習：エポック過多・データ過少で、評価が悪化する。早期に eval を見て止める。
  • データリーク：評価が学習に混入。分割を最初に決定的に。
  • 小さすぎるデータ：数十件で様式は変わらない。数百〜数千の良質例を狙う。
  • RAGで足りたのにFTした：知識追加は RAG が基本。FTで事実を焼くと陳腐化する。

まとめ

ファインチューニングは「賢くする魔法」ではなく、「振る舞いを設計どおりに固定する工学」です。だからこそ、RAGで足りないかを先に疑い、データ品質に投資し、評価ゲートを通し、ライセンス命名を守る——この規律が、デモと本番を分けます。

ドメイン特化した Llama を、RAG との役割分担・評価ハーネス・コスト設計・ライセンス対応まで含めて本番に載せたいなら、実績をご覧のうえご相談ください。一人 × 生成AIで、PoC から本番運用まで一気通貫で設計します。

出典・公式リソース

※ 対応モデル・リージョン・ライセンスは更新されます。実装前に必ず一次情報を確認してください。

Câu hỏi thường gặp

RAG とファインチューニング、どちらを先にやるべき？
RAG が先です。知識・鮮度は RAG、振る舞い・様式は FT。多くの案件は RAG＋プロンプトで要件を満たし、足りない様式固定だけ軽い LoRA を足す、が費用対効果の最適点です。
どれくらいのデータが必要？
様式・口調の固定なら数百〜数千の良質サンプルが目安。量より質。手で磨いた少数が、雑多な大量に勝ちます。
Llama 4（MoE）も微調整できる？
技術的には可能ですが、巨大MoEのFTは分散基盤が要り最初の一歩には不向き。まず Llama 3.3 8B/70B などの密モデル＋LoRA/QLoRA から始めるのが現実的です。
GPUが無くてもできる？
できます。Bedrock のマネージドFT（対象モデルは要確認）なら GPU 運用ゼロ。検証だけなら小型モデルを Colab/単一GPUの QLoRA で回せます。
成果物（アダプタ）はどれくらいの大きさ？
LoRA アダプタは数十MB級。ベースとは別に配布・差し替えでき、複数ドメイン用のアダプタを使い分ける運用も可能です。
友田

友田 陽大

Người phát triển sản phẩm đoạt Giải thưởng Bộ trưởng (METI). Với TypeScript + Python + AWS, tôi một mình triển khai trọn gói SaaS, chuyển đổi số công nghiệp và AI tạo sinh (RAG) sẵn sàng cho production — từ phân tích yêu cầu đến hạ tầng và vận hành.

Hồ sơXem dự ánXnoteGitHub

I can take on the implementation from this article as an engagement

Self-hosting infrastructure for open-weight LLMs — build, production operations, and cost optimization

I've run Qwen3-8B-AWQ and 4-bit quantized Llama 3 in production on vLLM, operated as a reproducible inference stack on spot GPUs (Tesla T4) with Terraform. Quantization choice, VRAM and throughput sizing, swappable models behind a provider abstraction, and resumption after forced preemption — I design and implement inference infrastructure that stays up.

Discuss self-hosting an LLMSee vLLM / quantized models shipped to productionXem dự án liên quan

Nhận cả dự án trọn gói lẫn vai trò cố vấn kỹ thuật. Hãy bắt đầu bằng buổi tư vấn miễn phí 30 phút.

最短ルート：カレンダーから直接予約

相談内容が固まっている方は、フォーム送信よりその場で日程を確定する方がスムーズです。下記から空き時間をお選びください。

  • 30分のオンライン無料相談
  • Google Meet / Zoom / Microsoft Teams
  • NDA 商談前締結可・無理な営業はいたしません
無料相談の空き枠を予約する

Bài viết liên quan

Xem tất cả bài trong “Llama & open-weight LLMs”

Cũng đáng đọc