corehu
GPU をレンタル
← すべての記事
DRAFTガイド

LLM ファインチューニングのための GPU 選び(VRAM ガイド)

CoreHu チーム·9 分で読めます

7B から 70B まで:フルファインチューニングと LoRA に必要な VRAM を計算し、バッチサイズ、シーケンス長、量子化が予算にどう影響するかを解説します。

01

VRAM が決め手になる理由

ファインチューニングでは、モデルの重み、勾配、オプティマイザの状態(Adam では重みの約2倍)、アクティベーションのすべてがメモリに同時に収まる必要があります。合計が VRAM に収まらなければトレーニングは始まりません。ぎりぎりで動くワークロードはスワップに溢れ、GPU のスループットが崩壊します。

そのため GPU 選びはまずメモリの問題です。VRAM が足りる中堅カードは、VRAM が足りない高速カードより常に効率的です。

02

モデルサイズ別の現実的な必要量

以下の範囲は、一般的なシーケンス長での bf16 トレーニングにおける実用的な数値です。シーケンス長とバッチサイズが増えると、上限側に近づくと考えてください。

  • 7B のフルファインチューニング:重み約14 GB+オプティマイザ状態約56 GB+勾配約14 GB → 2 × 80 GB なら余裕、1 × 80 GB ではぎりぎり。
  • 13B のフルファインチューニング:2 × 80 GB を推奨。
  • 34B のフルファインチューニング:4 × 80 GB クラスが必要。
  • 70B のフルファインチューニング:マルチ GPU 並列化を伴う 8 × 80 GB(A100/H100)クラスが必要。
  • LoRA/QLoRA:7〜13B モデルは単一の 24〜48 GB カードに収まります。70B では単一の 80 GB カードでの QLoRA が一般的です。

03

LoRA と量子化で予算を広げる

LoRA は重み行列を固定し、小さな低ランクの更新行列だけを学習します。学習対象の割合は通常 0.1〜1% です。これによりオプティマイザ状態と勾配のメモリの大部分が不要になります。

QLoRA はさらに一歩進み、ベースモデルを4ビット(NF4)に量子化し、計算時に必要な部分だけを16ビットに逆量子化します。比較的小さなチームが70B クラスのモデルを単一カードでファインチューニングする標準的な方法です。品質低下の程度はタスクとデータ品質に依存するため、必ず測定してください。

04

バッチサイズとシーケンス長の影響

アクティベーションメモリはシーケンス長にほぼ比例して増え、アテンション層では二乗で増えます。モデルの重みが全く変わらなくても、シーケンスを 2,048 から 8,192 トークンに増やすと、トレーニング時のメモリは目に見えて増加します。

実効バッチサイズ=デバイスごとのバッチ×勾配累積ステップ数。メモリが足りなくなったら、まずシーケンス長とデバイスごとのバッチを下げ、その後、累積で目標の実効バッチに戻します。

05

実践的な推奨

  • 24 GB クラス(例:RTX 4090):7〜13B モデルの QLoRA ファインチューニング。素早い実験に最適。
  • 48 GB クラス(例:L40S/A6000):7B のフルファインチューニング、または 13〜34B の QLoRA。
  • 80 GB クラス(A100/H100):70B の QLoRA、13B のフルファインチューニング。マルチ GPU ジョブのノード標準。
  • マルチ GPU トレーニングが必要なら、カードを個別にではなく、ノード/クラスター全体をまとめてレンタルしてください。NVLink と低レイテンシのネットワークが重要です。

06

チェックリスト

  • モデルのパラメータ数と目標とする手法(フル/LoRA/QLoRA)。
  • 最大シーケンス長と目標とする実効バッチサイズ。
  • データセットのサイズと永続ストレージの必要量。
  • 短時間のレンタルで実際のメモリ使用量を測定し、見積もり表を現場で検証する。

このページの記事はサンプルコンテンツです。CMS が接続されるまでは未公開のドラフトとして表示されます。