LLMメモリ要件:必要なGPU VRAMの量
- 活性化メモリ
- 分散トレーニング
- 完全Fine-Tuning
- GPUメモリ
- LLMトレーニング
- LoRA Fine-Tuning
- モデルスケーリング
- シーケンス長
- トレーニング最適化
- VRAM要件
- Ready Tensor
- Mohamed Abdelhamid
🏠
Home – All Lessons
⬅️
Previous – Week 4 Overview
➡️
Next – Memory Optimization Techniques
しかし、LoRAの代わりにLLaMA 3.1 1Bモデルの完全Fine-Tuningを行いたい場合はどうでしょうか?
4-bit量子化の代わりに完全精度を使用した場合はどうでしょうか?
7Bまたは13Bパラメータモデルにスケールアップしたい場合はどうでしょうか?
24GB VRAMを搭載したコンシューマーグレードRTX 3090で十分でしょうか? 40GB A100が必要でしょうか? 80GB H100が必要でしょうか?
このレッスンはこれらの質問に答えます。トレーニングが正確にどれだけのGPUメモリを必要とするかを計算する方法を学び、モデルが収まるかクラッシュするかを決定する4つのコンポーネントを理解します。
最後には、実行を押す前に、任意のモデル、任意のバッチサイズ、任意の精度のトレーニングメモリを推定する方法がわかります。
メモリが最初のスケーリング問題である理由
言語モデルのトレーニングは、計算コストが高いだけでなく、メモリコストも高いです。
13Bパラメータモデルを推論用にコンシューマーGPUで実行できます。しかし、Fine-Tuningしようとすると? 最初のバッチが完了する前にメモリ不足になるかもしれません。
この非対称性が根本的な課題を生み出します:Fine-Tuningしたいモデルは、アクセスできるハードウェアに収まらないことがよくあります。そして、計算(時間単位で購入できる)とは異なり、GPUメモリはハードリミットです。それに達すると、トレーニングは停止します。
そのため、メモリ要件を理解することはオプションではなく、真剣なLLMトレーニングプロジェクトの最初のステップです。
モデルを選択する前に、ハイパーパラメータを構成する前に、クラウドGPUをレンタルする前に、1つの質問に答える必要があります:
“これは収まるのか?”
このレッスンは、その質問に自信を持って答えるためのツールを提供します。トレーニング中にGPUメモリを消費する4つのコンポーネント、任意のモデル構成の要件を計算する方法、そして完全なトレーニングが推論よりも約10倍多くのメモリを消費する理由を学びます。
シンプルなMLPからBERT、LLaMA 3.1 8Bのような実際のモデルまで、具体的な例を見て、メモリがどこに使われるかを正確に示します。
最後には、Week 3のFine-TuningがColabで動作した理由、セットアップを変更したらどうなるか、より大きなモデルの計画方法を理解します。
フレームワークから始めましょう。
メモリ消費の4つのコンポーネント
言語モデルをトレーニングまたは推論すると、4つのものがGPUメモリのスペースを競います。それぞれを理解することが不可欠です。なぜなら、それらが一緒になって、トレーニング実行が収まるか失敗するかを決定するからです。
このレッスンの残りでは、トレーニング/Fine-Tuningに焦点を当てます。なぜなら、それが実際にメモリプレッシャーの源だからです。
1. モデルパラメータ(重み)
これらはネットワーク内の学習された数値、つまりモデルを定義するパラメータです。
特定の精度で保存されたNパラメータのモデルの場合:
- FP32 (32-bit浮動小数点): パラメータあたり4バイト
- FP16 / BF16 (16-bit): パラメータあたり2バイト
- INT8 (8-bit整数): パラメータあたり1バイト
例: FP32の1Bパラメータモデルには次が必要です:
1,000,000,000パラメータ × 4バイト = 4GB
十分シンプルです。しかし、これは始まりに過ぎません。
2. 勾配(バックプロパゲーションの作業メモリ)
バックプロパゲーション中、モデルは勾配を計算します。これらはトレーニング中に各パラメータに必要な調整を定義します。
これらの勾配は、モデルパラメータと同じ精度で保存されます。
モデルを凍結する(LoRAのように)場合、ほとんどのレイヤーの勾配は消えます。
そうでなければ、これはパラメータのメモリコストを倍にします。
FP32でその同じ1Bパラメータモデルの完全Fine-Tuningを選択した場合:
勾配 = さらに4GB
3. オプティマイザー状態(Adamの隠れたコスト)
最新のトレーニングのほとんどは、各パラメータに対して2つの追加値を追跡するAdamオプティマイザーを使用します:
- モーメンタム(1次モーメント推定)
- 分散(2次モーメント推定)
これらは通常、FP16またはBF16でトレーニングしている場合でも、FP32で保存されます(数値安定性のため)。
1Bパラメータモデルの場合:
オプティマイザー状態 = 1Bパラメータ × 2状態 × 4バイト = 8GB
これはトレーニング中に最大のメモリ消費者であることがよくあります。
注: SGDのようなより単純なオプティマイザーはモーメンタムのみを保存し、これを半分に削減します。しかし、Adamの優れた収束は通常、コストに見合う価値があります。
4. 活性化(順伝播フットプリント)
順伝播中、モデルは中間テンソル(活性化)を保存し、逆伝播が勾配を計算できるようにします。
モデルはバックプロパゲーションのためにこれらをメモリに保持する必要があります。
LLMで使用されるtransformerモデルの場合、活性化メモリは次に依存します:
- バッチサイズ
- シーケンス長
- モデルアーキテクチャ(つまり、レイヤー数、アテンションヘッド数、隠れ次元など)
他のコンポーネントとは異なり、活性化はバッチサイズに対して線形に成長し
、シーケンス長に対して2次的に成長します(アテンションのため)。これは「CUDA out of memory」エラーの驚くべき原因の1つです。
まとめ:メモリ式
このレッスン全体で使用するメンタルモデルは次のとおりです:
合計GPUメモリ ≈ トレーニング可能パラメータ + 勾配 + オプティマイザー状態 + 活性化
これを具体的にしましょう。先週QLoRAを使用してLLaMA 3.1 1Bで作業したことを思い出してください。代わりに完全精度でモデル全体を完全Fine-Tuningしたい場合を想像してください。必要なものは次のとおりです:
- モデルパラメータ: 1B × 4バイト = 4GB
- 勾配: 1B × 4バイト = 4GB
- オプティマイザー状態: 1B × 8バイト = 8GB
- 活性化: ~1 GB (勾配チェックポイントや勾配累積などの最適化を想定)
小計: ~17–18GB
CUDAカーネル、フレームワークバッファー、メモリフラグメンテーションからの追加オーバーヘッドもあり、さらに1〜2GB追加され、実際の合計は約18〜20GBになります。
合計: ~18–19GB
これは、ほとんどの初心者を驚かせるものです:4GBで読み込まれる1Bパラメータモデルは、トレーニングにほぼ5倍のメモリが必要です。
パラメータ自体は始まりに過ぎません。トレーニング中は、勾配、オプティマイザー状態、活性化のための個別のストレージが必要で、これらが一緒になってメモリ予算を支配します。
これが、先週完全Fine-Tuningの代わりにQLoRAを使用した正確な理由です。そして、この式を理解することが重要な理由です:トレーニング実行を構成する前に、それが収まるかどうかを知る必要があります。
ビデオウォークスルー – LLaMA 3.1 8Bトレーニングメモリ
このウォークスルーでは、8Bモデルの4つのFine-Tuningシナリオを比較します。最大メモリの完全精度セットアップから最小メモリのQLoRA構成まで。
精度、PEFTメソッド、メモリ最適化が要件を100GB以上から10GB未満に押し下げる様子を見ます。
次に来るもの:メモリボトルネックを軽減するツール
この時点で、パターンは明確です:メモリが真の制約であり、計算ではありません。トレーニングフットプリントは速く成長し、GPUは追いついていません。
そこで、コミュニティはGPUメモリを物理的限界をはるかに超えて引き伸ばすツールキットを構築しました。今週は、モデルが単一GPUの容量を超えたときにトレーニングを可能にするテクニックを学びます。
いくつかはメモリを直接削減します:
活性化チェックポイントは、計算とメモリをトレードします。順伝播中に保存する活性化を減らし、バックプロップ中に再計算します。
勾配累積は、多くの小さなマイクロバッチを使用して大きなバッチサイズをシミュレートし、メモリを一定に保ちながら有効バッチサイズを増やします。
FSDPとZeROは、各デバイスがモデルのスライスのみを保持するように、GPU全体でパラメータ、勾配、オプティマイザー状態をシャードします。これは、チームがどこでも80GBカードを必要とせずに70B+モデルをFine-Tuningする方法です。
他のものは、マルチGPUに移行したら速度に焦点を当てます:
分散データ並列化(DDP)は、トレーニングを高速化するためにGPU全体でバッチを分割します。GPUあたりのメモリを削減しませんが、作業する分散エコシステムの一部です。
そして極端なスケールで:
テンソルおよびパイプライン並列化は、個々のレイヤーまたは実行ステージをGPU全体に分割します。単一のレイヤーでさえGPUメモリを超える場合に必要です。
週の終わりまでに、研究室が数千億のパラメータを持つモデルをどのようにトレーニングするかを正確に理解し、自分でそれを行うツールを持つことになります。
すぐに適用できるテクニックから始めましょう:活性化チェックポイントと勾配累積です。
- Can Your GPU Handle It?
- Model Parameters (The Weights)
- Gradients (Backpropagation’s Working Memory)
- Optimizer States (Adam’s Hidden Cost)
- Activations (The Forward Pass Footprint)

コメント