【ITニュース解説】Fine-tuning a 7B model needs 112 GB. The model is only 14 GB of it.
2026年10月03日に「Dev.to」が公開したITニュース「Fine-tuning a 7B model needs 112 GB. The model is only 14 GB of it.」について初心者にもわかりやすく解説しています。
ITニュース概要
7Bモデルのファインチューニングは、モデル本体14GBに対し、更新に必要な情報で112GBものメモリが必要だ。LoRAやQLoRAは、この「更新のための帳簿付け」コストを削減し、効率的に学習する技術。特にQLoRAはモデルも圧縮し、少ないGPUで大規模モデル調整を可能にする。
ITニュース解説
大規模言語モデル(LLM)のファインチューニング、つまり既存の訓練済みモデルを特定のタスクに合わせて追加で訓練するプロセスは、近年非常に注目されている技術だ。しかし、このファインチューニングには、モデルのサイズからは想像できないほど大量のメモリが必要となる場合があり、多くのシステムエンジニア志望者にとってはその実態が驚きかもしれない。
例えば、70億のパラメータを持つモデル(通称7Bモデル)があるとする。このモデルの重み(パラメータ)を半精度浮動小数点数(fp16)で表現すると、通常は14ギガバイト(GB)程度のメモリしか必要としない。これは、1つのパラメータが2バイトのメモリを使うため、70億パラメータであれば140億バイト、つまり14GBとなる計算だ。しかし、実際にこの7Bモデルをファインチューニングしようとすると、実に112GBものメモリが必要になることが明らかになっている。モデル自体のサイズである14GBを大幅に超えるこの98GBは一体どこへ消えているのだろうか。
このメモリ消費の大部分は、モデルの重みを更新するために必要な「帳簿付け」に費やされている。ファインチューニング中のメモリは、主に以下の3つの要素で構成されている。
-
モデルの重み(Weights): これが私たちが通常「モデルのサイズ」として認識しているもので、fp16で2バイト/パラメータを消費する。7Bモデルであれば14GBにあたる。
-
勾配(Gradients): モデルの重みを最適化するために計算される、各パラメータの更新方向と大きさを表す情報だ。これもfp16で2バイト/パラメータを消費する。つまり、重みと同じく14GBが必要となる。
-
オプティマイザの状態(Optimizer State): モデルの訓練には、Adamなどの最適化アルゴリズムが使われる。これらのオプティマイザは、訓練を効率的に進めるために、過去の勾配の移動平均などの情報を保持する。具体的には、重みの高精度版(fp32、4バイト/パラメータ)と、その重みに対応する2つのモーメントバッファ(それぞれfp32で4バイト/パラメータ)が必要となり、合計で12バイト/パラメータを消費する。7Bモデルの場合、これは84GBにもなる。
これら3つの要素を合計すると、1つのパラメータあたり2(重み)+ 2(勾配)+ 12(オプティマイザの状態)= 16バイトのメモリが必要となる。70億パラメータのモデルであれば、16バイト × 70億 = 112GBという計算になるのだ。この内訳を見ると、モデルの重み自体が占めるのはわずか14GBであり、残りの98GBは勾配とオプティマイザの状態、特にオプティマイザの状態が84GBと、全体の約75%を占めていることがわかる。つまり、ファインチューニング時のメモリ消費は、モデルそのものよりも、その更新に必要な「帳簿付け」によって支配されているのだ。
この大量のメモリ消費を解決するために考案されたのが、「LoRA(Low-Rank Adaptation)」という技術だ。LoRAの基本的な考え方は、ファインチューニングの対象を、モデル全体の重みから、ごく一部の小さな追加パラメータに限定するというものだ。具体的には、元の巨大なモデルの重みは「凍結」され、訓練中に更新されないようにする。これにより、凍結された重みに対しては勾配やオプティマイザの状態を計算する必要がなくなり、それらにかかるメモリコストを丸ごと削減できる。その代わりに、元のモデルの各層にごく小さな「アダプタ」と呼ばれる行列を注入し、このアダプタのパラメータのみを訓練するのだ。
このアダプタは非常に小さく、例えばLlamaのような7Bモデルの場合、訓練対象となるパラメータは元のモデルのわずか0.06%程度、およそ400万パラメータに過ぎない。これにより、勾配やオプティマイザの状態を保持する必要があるのはこの小さなアダプタ部分だけで済むため、GPUメモリの要件を劇的に削減できる。既存の研究では、LoRAを使うことで訓練パラメータ数を10,000分の1に、GPUメモリ要件を3分の1に削減しつつ、ファインチューニングと同等かそれ以上のモデル品質を達成できると報告されている。さらにLoRAの利点として、訓練後にこの小さなアダプタを元のモデルの重みに統合できるため、推論時に余分な計算ステップが発生せず、追加の遅延が生じない点も大きい。
LoRAは大幅なメモリ削減を達成したが、それでもまだ一つ大きなコストが残っていた。それは、凍結されたベースモデルの重み(fp16で14GB)だ。これをさらに削減するために登場したのが、「QLoRA(Quantized LoRA)」という技術だ。QLoRAは、LoRAの仕組みをベースにしつつ、凍結されたベースモデルの重みをさらに少ないビット数(例えば4ビット)に「量子化」して保存する。量子化とは、数値をより少ない情報量で表現することで、メモリ消費を劇的に減らす技術である。
QLoRAでは、ベースモデルを4ビットで保存することにより、そのメモリ使用量を14GBから約3.5GBへと大幅に削減する。訓練の際には、4ビットで保存されたベースモデルから勾配が流れ、LoRAアダプタは通常通り高精度(fp16など)で訓練される。これにより、LoRAでは実現できなかった、より大規模なモデルのファインチューニングが、限られたメモリのGPUでも可能になる。例えば、ある研究では650億パラメータのモデルを48GBのGPUでファインチューニングできると報告されている。ただし、QLoRAには一つトレードオフがある。4ビットに量子化された重みは、計算を行う際に毎回高精度に戻す(逆量子化する)必要があるため、通常のLoRAよりも訓練に時間がかかるという欠点がある。これはメモリを節約するための代償であり、速度とメモリのどちらを優先するかという選択を迫られることになる。
まとめると、大規模言語モデルのファインチューニングに必要なメモリは、単にモデルの重みのサイズだけでは決まらない。その更新に必要な勾配やオプティマイザの状態といった「帳簿付け」が、はるかに大きなメモリを消費する。
- フルファインチューニングは、パラメータあたり16バイトすべてを支払い、すべての重みを更新するため、最もメモリを消費するが、最も柔軟性が高い。ハードウェアの制約がない場合や、モデルの事前訓練データとタスクが大きく異なる場合に有効だ。
- LoRAは、ベースモデルの重み以外の14バイトの「帳簿付け」コストを停止し、凍結された重み(2バイト/パラメータ)と小さなアダプタのみを扱うことで、メモリを大幅に削減する。
- QLoRAは、LoRAの考え方をさらに進め、残るベースモデルの重み(2バイト/パラメータ)を4ビットに量子化することで、さらに約0.5バイト/パラメータまで圧縮する。
つまり、「7Bモデルは14GB必要だ」という話を聞いた場合、それはモデルをただ読み込むだけの「推論」に必要なメモリを指していることが多い。実際にファインチューニングを行う際には、その裏にある98GB、つまり「帳簿付け」に必要な膨大なメモリについても意識する必要がある。これらのメモリ最適化技術を理解することは、限られたリソースで高性能なAIモデルを開発・運用していく上で、システムエンジニアを目指す者にとって不可欠な知識となるだろう。