---
title: "ファインチューニングの実行環境と実装｜必要GPUと学習コード"
url: "https://www.issoh.co.jp/tech/details/3955/"
published: 2024-10-25
updated: 2026-09-27
categories: ["LLM・RAG"]
publisher: "株式会社一創"
---

# ファインチューニングの実行環境と実装｜必要GPUと学習コード

ファインチューニングは、やると決めたあとに「どのGPUなら回るのか」「学習コードをどう書くのか」「うまくいったと何を見て判断するのか」で止まります。この記事はその実行段階と、画像・音声で変わる実装差を扱います。仕組みやRAGとの使い分け、そもそもやるべきかの判断は[LLMの追加学習とRAGの使い分け](/column/details/12965/)で、学習データの形式・件数・品質要件は[データセットの作り方](/tech/details/2790/)で扱っているので、そちらが未決なら先に読んでください。記述は2026年7月時点の公式ドキュメントとライブラリ実装に基づきます。

## まとめ：実行環境と学習コードの決めどころ

OpenAIは2026年7月時点でファインチューニング基盤を縮小しており、新規ユーザーには開放されていません。運用担当を置けるなら、オープンウェイトモデルをPEFT（LoRA）で学習させる構成が現実的な選択になります。

必要なGPUメモリは手法で桁が変わります。7Bクラスをbf16で読むと重みだけで約14GB。16GBのGPUでもLoRAは通りますが、系列長とバッチサイズを詰めるのが前提で、余裕を持たせるなら4bit量子化のQLoRA（重み側は概算4GB前後）に寄せます。学習コード自体はTRLとPEFTで20行ほどに収まる一方、学習率とmax\_lengthとデータ型の既定値をそのまま使うと結果が出ません。評価では損失だけを見ず、学習させていないタスクの劣化まで確認します。

## OpenAI基盤縮小後に残る実行経路

### 教師ありファインチューニングの対応モデルと新規受付停止

OpenAIの公式ガイドは、ファインチューニング基盤について「winding down（縮小中）」であり、新規ユーザーには開放されていない、既存ユーザーは当面のあいだ学習ジョブを作成できる、と明記しています。学習済みのモデルは、ベースモデルが廃止されるまで推論に使えます。教師ありファインチューニングの対応モデルとして残るのは gpt-4.1-2025-04-14、gpt-4.1-mini-2025-04-14、gpt-4.1-nano-2025-04-14 の3つです。

つまり「まずOpenAIのAPIで試してから考える」という2024年当時の入口は、これから始める組織には使えません。日本語の解説記事の多くはこの前提のまま書かれています。手順をなぞる前に、公式ページで対応状況を確認してください。

### マネージド継続とオープンウェイト移行の判断材料

GPUを持たず既存のクラウド契約内で完結させたいなら、Azure OpenAI Service、Amazon Bedrock、Vertex AI といったマネージドの学習機能が候補になります。ただし各社とも対応モデルの入れ替えと新規受付終了が進んでおり、2026年7月時点の可否は各社の提供状況ページで確認してください。

逆に、学習データを社外に出せない、モデルの重みを自社で保持したい、コストを推論回数ではなくGPU時間で管理したい。このいずれかに当てはまるならオープンウェイトの自前学習に寄せます。Qwen・Llama・Gemmaといった公開モデルに対しLoRAで差分だけを学習する形が、必要なGPUメモリと学習時間の両面で現実的です。rankやalphaの決め方を含む手法ごとの差は[PEFTとLoRAの手法比較](/tech/details/8203/)にまとめています。

## 必要GPUメモリの概算：手法別の内訳と16GBでの可否

### 手法別の重み保持量とオプティマイザ状態の内訳

必要量はパラメータ数から概算できます。bf16でモデルを読み込むと1パラメータあたり2バイトなので、7Bクラスの重みだけで約14GB。全パラメータを更新するフルファインチューニングでは、これに勾配とAdamWのオプティマイザ状態（1次・2次モーメント）が加わり、重みの数倍を要します。7Bのフル更新を単一の一般向けGPUで狙うのは現実的ではありません。

| 手法          | 7Bクラスの重み保持（概算） | 勾配・オプティマイザ状態 | 単一16GB GPUでの可否   |
| ----------- | -------------- | ------------ | ---------------- |
| フル更新（bf16）  | 約14GB          | 重みの数倍        | 不可               |
| LoRA（bf16）  | 約14GB          | アダプタ分のみ      | 条件付き（次のh3の設定が必要） |
| QLoRA（4bit） | 約4GB           | アダプタ分のみ      | 可                |

LoRAは元の重みを凍結して低ランクの差分だけを学習するため、勾配とオプティマイザ状態が学習対象のパラメータ分だけで済みます。QLoRAはさらに重みを4bitで読み込むので、重み側が概算4GB前後まで落ちます。8Bクラスを扱う場合はこの概算値が1割強上振れると見ておいてください。

### 16GBに収めるための設定：バッチサイズ・勾配蓄積・チェックポイント

表の「条件付き」は、重み14GBを載せた残りで活性化をまかなうという意味です。活性化メモリは系列長とバッチサイズの積でほぼ決まるので、削る順番は決まっています。

まず per\_device\_train\_batch\_size を1まで落とし、実効的なバッチサイズは gradient\_accumulation\_steps で稼ぎます。8ステップ蓄積すれば、メモリ上は1件ずつ処理しながら勾配更新はバッチ8件相当になります。次に max\_length を実データの分布に合わせて切り詰める。学習データの9割が512トークン以内なら2048は無駄です。

勾配チェックポイントはTRLでは既に効いています。SFTConfig の gradient\_checkpointing は TrainingArguments の既定（False）と異なり True が既定なので、追加設定は不要です。ここまでやってもCUDA out of memoryが出るなら、系列長を削るよりQLoRAに切り替えるほうが確実です。

### Google Colabとローカル環境の使い分け

Google Colabの公式FAQは、利用できるGPUやTPUの種類は時期によって変動し、リソースは保証も無制限でもないと明記しています。ノートブックの実行時間にも上限があります。学習の途中で切断される前提でチェックポイントを保存する設定にしておいてください。

数時間で終わる検証は無料枠、本番の学習は有料GPUかローカル環境。この切り分けが安全です。ローカルに寄せる場合は、量子化に対応したドライバとbitsandbytesが動く構成かを先に確認します。

## 学習コード：TRL 1.9とPEFTによるLoRA学習の最小構成

### 最小コードと既定値のまま起きる取りこぼし

TRL 1.9.0、PEFT 0.19.1、transformers 5.14.1（いずれも2026年7月時点の最新版）の組み合わせなら、LoRA学習は次の分量で書けます。

```
import torch
from datasets import load_dataset
from trl import SFTConfig, SFTTrainer
from peft import LoraConfig

dataset = load_dataset("trl-lib/Capybara")

trainer = SFTTrainer(
    model="Qwen/Qwen3-0.6B",
    train_dataset=dataset["train"],
    eval_dataset=dataset["train"].select(range(100)),
    peft_config=LoraConfig(),
    args=SFTConfig(
        output_dir="out",
        learning_rate=1e-4,
        max_length=2048,
        model_init_kwargs={"dtype": torch.bfloat16},
        per_device_train_batch_size=1,
        gradient_accumulation_steps=8,
        eval_strategy="steps",
        eval_steps=50,
    ),
)
trainer.train()
```

短く書ける代わりに、既定値のまま使うと結果が出ない箇所があります。

まず学習率です。SFTConfig の learning\_rate の既定は 2e-5 ですが、これはモデル全体を更新する前提の値です。TRLの公式ドキュメントは、アダプタ学習では新しいパラメータだけを学習するため 1e-4 程度の高めの値を使うよう案内しています。既定のまま回すと、損失は下がるのに振る舞いが変わらないという、判断に困る結果になりがちです。

次に max\_length です。既定は1024で、これを超える系列は切り詰められます。長い文書を学習させているつもりで後半が丸ごと落ちている、という取りこぼしはここで起きます。上のコードで2048を明示しているのはそのためです。

最後にデータ型です。model に文字列でモデル名を渡した場合、args.model\_init\_kwargs で dtype を指定しないと float32 になります。transformers v5 の from\_pretrained は設定から推論しますが、SFTTrainer に文字列を渡す経路はその挙動と異なるため、指定を省くとメモリを倍消費します。

なお eval\_dataset を渡さないと検証損失が記録されず、後述の過学習判定ができません。上の例では簡略に学習セットの一部を流用していますが、実際には学習に使っていないデータを充てます。分割の考え方は[データセットの作り方](/tech/details/2790/)に書いています。

### 量子化設定の追加だけで済むQLoRA移行

16GBのGPUで8Bクラスを扱うなら、量子化設定を渡してQLoRAにします。importと dataset は前掲のコードから引き継ぎます。

```
from transformers import BitsAndBytesConfig

trainer = SFTTrainer(
    model="Qwen/Qwen3-8B",
    train_dataset=dataset["train"],
    eval_dataset=dataset["train"].select(range(100)),
    peft_config=LoraConfig(),
    quantization_config=BitsAndBytesConfig(
        load_in_4bit=True,
        bnb_4bit_quant_type="nf4",
        bnb_4bit_compute_dtype=torch.bfloat16,
    ),
    args=SFTConfig(
        output_dir="out",
        learning_rate=1e-4,
        max_length=2048,
        per_device_train_batch_size=1,
        gradient_accumulation_steps=8,
        eval_strategy="steps",
        eval_steps=50,
    ),
)
trainer.train()
```

ここで model\_init\_kwargs を書いていないのは、4bit読み込みでは計算時のデータ型が bnb\_4bit\_compute\_dtype 側で決まるためです。それ以外の設定は前掲と揃えてあります。

bnb\_4bit\_quant\_type の既定は fp4 ですが、Hugging Faceの公式ドキュメントは4bitのベースモデルを学習する用途では nf4 を使うべきだとしています。既定のままにしない。また quantization\_config は peft\_config と組み合わせたときにQLoRAとして機能し、モデルが既にインスタンス化されている場合は無視されます。文字列でモデルを指定する形を崩さないでください。VRAMをさらに削り学習を速くしたい場合は、[Unslothによる高速化](/tech/details/8159/)を挟む選択肢もあります。

## テキスト以外のモデルで変わる実装

### YOLO系とVLMで分かれる学習の枠組みとmax\_length

YOLOのような物体検出モデルは、テキストのSFTとは学習の枠組みが別です。画像とアノテーション（バウンディングボックス座標とクラス）の対を用意し、そのモデル固有の学習スクリプトを使います。TRLのSFTTrainerが対象とするのは、公式ドキュメントが「causal language models のみサポート」と明記する言語モデルと、視覚言語モデル（VLM）です。VLMには image 列（1サンプル1画像）または images 列（1サンプル複数画像）を持つデータセットを渡します。

このとき SFTConfig の max\_length は None にします。既定の1024で切り詰めると画像トークンが落ち、学習時にエラーになるためです。テキストの感覚で max\_length を残したまま画像を流すと、原因の分かりにくい失敗になります。

### 音声モデルを追加学習する効き所とサンプリングレート要件

音声認識モデルは、上記のサポート範囲（causal LMとVLM）に含まれません。Whisperなどを学習させる場合は transformers の Trainer と各モデルのプロセッサを直接使います。

データ側で最初に効くのがサンプリングレートです。transformersの WhisperFeatureExtractor は sampling\_rate の既定値が16000で、公式のサンプルコードもデータセットを Audio(sampling\_rate=16000) にキャストしてから特徴量を作ります。モデルが前提とするレートと入力が揃っていないと、件数を増やしても認識精度は上がりません。データ準備の工数は、音声の正規化と書き起こしの品質確認にその大半が消えます。

では追加学習の効き所はどこか。固有名詞の誤変換そのものは、実はプロンプトでもある程度直せます。OpenAIの音声認識ガイドは、prompt パラメータで誤って書き起こされる単語や略語を補正できるとし、DALL·EやGPT-3を例に挙げています。ただし同ガイドは whisper-1 がプロンプトの先頭224トークンしか参照しないことも明記しており、社内の型番や製品名を数百語の辞書として渡す使い方はここで頭打ちになります。語彙リストが224トークンに収まらない規模になったとき、あるいは訛りや収録環境といった音響的な差が原因のとき。この2つが、プロンプトでは届かず追加学習に切り替える境目です。

## 学習後の検証：記録指標と固定質問による回帰確認

### 過学習の検知：検証損失と記録指標

学習が終わったあと、損失の値だけを見て成否を判断すると失敗します。TRLは学習中に loss、mean\_token\_accuracy、entropy、grad\_norm を記録します。学習損失が下がり続けているのに検証側の損失が下がらなくなった時点が、過学習の入口です。前掲のコードで eval\_strategy を指定しているのは、この折り返し点を見るためです。

### 破滅的忘却の検知：固定質問による回帰確認

特定用途に強く適応させると、それ以前にできていた汎用的な応答が劣化します（破滅的忘却）。学習前のモデルで通っていた質問を、主要なユースケース分（目安として10問前後）固定しておき、学習後に同じ質問を通して比較してください。この固定質問を用意せずに学習を回すと、劣化に気付くのは本番投入後になります。

あわせて、目的そのものの達成も数えます。出力形式を固定したかったのなら、指定どおりの形式で返った割合を数える。評価指標を精度や再現率に置き換える前に、何を達成したら成功なのかを件数で数えられる形にしておくほうが、判断は速くなります。

## 実装に進む前に止まるべき条件

環境が用意できても投資が回収できないケースには、着手前に判別できる条件があります。なお「社内文書の知識を覚えさせたい」という目的の場合は、そもそも追加学習が適さない可能性が高いので、[RAGとの使い分けの判断基準](/column/details/12965/)を先に確認してください。

### 学習データを人手で作れる体制が無い場合

模範回答を書けるのは、その業務を理解している担当者だけです。この工数を確保せずに既存ログを流用すると、ログに含まれる誤った応答まで学習させることになります。データ作成の担当者と時間が確保できない段階でGPUを借りるのは、順番が逆です。

### 評価の合格ラインを決めていない場合

「精度を上げたい」という目的のまま学習を回すと、結果が出たかどうかを誰も判定できず、再学習の判断もできません。着手前に、固定質問と合格件数を決めておきます。ここが決まっていないうちは、環境構築に進まず設計へ戻すべきです。

## ファインチューニングの実装に関するよくある質問

### ファインチューニングにはどのくらいのGPUが必要ですか？

7Bクラスをbf16のLoRAで学習すると重みだけで約14GBを占めるため、16GBのGPUではバッチサイズを1にして勾配蓄積で補い、系列長も実データに合わせて詰める必要があります。4bit量子化のQLoRAなら重み側は概算4GB前後まで下がり、16GBクラスでも余裕が生まれます。フルファインチューニングは勾配とオプティマイザ状態で重みの数倍を要するため、単一の一般向けGPUでは想定しないでください。

### 学習データは何件・どんな形式で用意しますか？

件数の目安と、JSONLやchat形式の書き方、品質を決める条件は[データセットの作り方](/tech/details/2790/)にまとめています。実装側で押さえるのは、学習用と検証用を分けること、そして検証用は学習に一切使わないことの2点です。

### YOLOなどの画像モデルも同じ手順で学習できますか？

考え方は同じですが、枠組みが別です。物体検出モデルは画像とバウンディングボックスのアノテーションを用意し、そのモデル固有の学習スクリプトを使います。TRLのSFTTrainerで扱えるのは言語モデルと視覚言語モデルで、視覚言語モデルの場合は image 列を持つデータセットを渡し、SFTConfig の max\_length を None にします。

### 音声データのファインチューニングは何が違いますか？

TRL 1.9.0 のSFTTrainerがサポートするのは causal LM と視覚言語モデルで、音声認識モデルは含まれません。transformers の Trainer と各モデルのプロセッサを直接使います。データ側では、モデルが前提とするサンプリングレートへの変換が必須です。WhisperFeatureExtractor の既定は16000で、公式サンプルもデータセットを16kHzにキャストしてから特徴量を作っています。

### 音声モデルをファインチューニングするメリットは何ですか？

固有名詞の補正はプロンプトでもある程度可能ですが、OpenAIの音声認識ガイドは whisper-1 がプロンプトの先頭224トークンしか参照しないと明記しています。社内の型番や製品名が数百語規模になるとこの枠に収まりません。語彙リストが大きい場合と、訛りや収録環境といった音響面の差が原因の場合が、追加学習に切り替える判断どころです。

### OpenAIのAPIでまだファインチューニングできますか？

2026年7月時点の公式ガイドでは、基盤は縮小中で新規ユーザーには開放されていません。既存ユーザーは当面のあいだ学習ジョブを作成でき、学習済みモデルはベースモデルが廃止されるまで推論に利用できます。これから始める場合は、他社のマネージドサービスかオープンウェイトの自前学習を前提にしてください。

## 関連記事

- [ファインチューニングとは？LLMの追加学習の仕組み・RAGとの違いと使い分けを解説](/column/details/12965/)
- [ファインチューニング用データセットの作り方｜サンプル形式・件数・品質の要件](/tech/details/2790/)
- [PEFTとLoRAの違いとは？仕組み・使い方・QLoRA/DoRAとの比較を実装例つきで解説](/tech/details/8203/)
- [Unslothとは？読み方・使い方・対応モデルと高速ファインチューニングの仕組み](/tech/details/8159/)
- [転移学習とは？ファインチューニング・特徴抽出との違いと実装判断を解説](/tech/details/13301/)

---

出典: [ファインチューニングの実行環境と実装｜必要GPUと学習コード](<https://www.issoh.co.jp/tech/details/3955/>)（株式会社一創）