QLoRAとは？NF4・Double Quantization・Paged Optimizerを解説

QLoRA（Quantized Low-Rank Adaptation、量子化したベースモデルを使う低ランク適応）は、事前学習済みLLM（大規模言語モデル）の重みを4-bitで凍結保存し、その重みを計算時に展開しながらLoRA adapterだけを学習する手法です。省メモリ化の中心は、正規分布を意識したNF4、量子化定数も圧縮するDouble Quantization、瞬間的なメモリ不足を緩和するPaged Optimizerです。ただし「モデル全体を4-bitのまま更新する」「4-bitなら必要VRAMはparameter数×0.5 byteだけ」と理解すると、実装とメモリ見積もりを誤ります。

3文要約
QLoRAはLoRAの何を変えたのか
「4-bit学習」を三つのdtypeへ分解する
forwardとbackwardでは何が起きるのか
block-wise量子化を式で理解する
NF4はなぜ等間隔の4-bitではないのか
Double Quantizationは何を二重量子化するのか
Paged Optimizerは何を退避するのか
QLoRAのメモリは七つの箱で考える
1. 7B・13B・65Bのraw weight比較
2. sequence lengthがOOMを起こす理由
論文の「65Bを48GB GPUで学習」をどう読むか
実装は七段階で検証する
1. target modulesは文字列ではなく実体を確認する
2. device mapは学習戦略ではない
dtypeの不一致は静かに速度と品質を変える
datasetとtokenizerの事故は量子化では直らない
保存・再読込・mergeは別工程として試験する
1. 量子化baseへのmerge
よくある失敗を症状から切り分ける
1. loadだけでOOMになる
2. forwardまたはbackwardでOOMになる
3. OOMは消えたが非常に遅い
4. trainable parameterが0、または少なすぎる
5. lossは下がるのに生成品質が悪い
6. save後に品質が戻る、または出力が変わる
Full Fine-tuning、LoRA、QLoRAの選び方
評価は品質・メモリ・速度・再現性を分ける
QLoRA論文の結果と限界
導入前の最終チェックリスト
1. modelと量子化
2. LoRAと学習
3. dataと評価
4. 保存と再読込
まとめ
関連記事
参考資料

3文要約

QLoRAで4-bitになる中心は凍結したベース重みの保存であり、行列積はBF16などの計算dtypeへdequantize（量子化値から近似的な実数へ復元）して行い、LoRA adapterを更新します。
NF4は重みの表現、Double Quantizationはblockごとの量子化定数、Paged Optimizerは一時的なメモリpeakという別の問題を担当します。
導入時はraw weight容量だけでなく、scale、adapter、gradient、optimizer state、activation、一時buffer、CPU転送、保存・再読込後の品質まで測る必要があります。

QLoRAはLoRAの何を変えたのか

QLoRA論文の基本構造はLoRAと同じです。事前学習済みのベース重みを凍結し、低ランクな更新差分だけを学びます。QLoRAが追加した重要な工夫は、forward（順伝播）に必要な巨大なベース重みを4-bitで保持することです。

通常のLoRAでベースをFP16またはBF16の2 byte/parameterで保持すると、65B parameterでは重みだけで約130GB必要です。4-bitの生データなら0.5 byte/parameterなので約32.5GBまで下がります。この差が、大きなモデルを限られたVRAMへ載せる入口になります。

比較軸	LoRA	QLoRA
ベース重み	FP16、BF16などで保持する構成が一般的	4-bitで量子化して保持
ベース重みの更新	しない	しない
学習対象	LoRA adapter	LoRA adapter
行列積	通常の浮動小数点weightを利用	blockを計算dtypeへ展開して利用
主な省メモリ箇所	gradient、optimizer state、checkpoint	左記に加えてベース重み
固有の注意	rank、alpha、target modules	量子化誤差、scale、kernel、device配置、paging

したがって、QLoRAはLoRAとは別の学習目的ではありません。SFT（Supervised Fine-Tuning、教師あり追加学習）でもDPO（Direct Preference Optimization、選好pairによる直接最適化）でも、更新対象としてQLoRA構成を選べます。LoRAの低ランク更新そのものは、前回の記事で詳しく説明しています。

「4-bit学習」を三つのdtypeへ分解する

QLoRAを理解する最短の方法は、storage dtype（保存形式）、compute dtype（計算形式）、trainable parameter dtype（更新対象の形式）を分けることです。

層	代表的な扱い	役割
ベース重みの保存	4-bit NF4	大部分を占めるweight memoryを減らす
行列積の計算	BF16、FP16など	4-bit codeをblockごとに展開して演算する
LoRA adapter	BF16、FP16、場合によりFP32	gradientを受け取りoptimizerが更新する
optimizer state	optimizer実装に依存	adapter parameterのmomentなどを保持する
activation	compute dtypeやkernelに依存	backwardに必要な中間値を保持する

「4-bit」という名前だけを見ても、全tensorのdtypeは分かりません。LayerNorm、embedding、出力headなどの非量子化moduleが別dtypeで残ることもあります。Transformersのbitsandbytes公式ガイドでも、量子化されるLinear layerと、それ以外のmoduleのdtypeは区別されています。

compute dtypeはhardwareとsoftware stackで選びます。BF16はFP16より指数部が広くoverflowに強い一方、対応していないGPUでは適切に実行できません。設定名だけBF16にしても、kernelがfallbackしたり、別moduleがFP32のまま残ったりします。学習開始前に、代表moduleの実dtypeとdeviceを列挙するのが安全です。

forwardとbackwardでは何が起きるのか

対象の線形層を単純化して考えます。通常のLoRAは、凍結したベース重み \(W_0\) と、学習する低ランク行列 \(A\)、\(B\) から出力を作ります。

\[h = W_0x + sBAx\]

QLoRAでは \(W_0\) をそのまま保持せず、4-bit codeと量子化用metadataとして保存します。量子化表現を \(Q(W_0)\)、必要なblockだけを計算dtypeへ戻す処理を \(\operatorname{dequant}\) とすると、概念的なforwardは次です。

h = \operatorname{dequant}(Q(W_0))x + sBAx

backward（逆伝播）では、lossからLoRAの \(A\) と \(B\) へ勾配が流れます。ベース経路も入力やadapterの勾配計算に使われますが、4-bit codeや元の \(W_0\) をoptimizerで更新するわけではありません。

対象	forwardで使う	gradientを保存する	optimizerが更新する
4-bitベース重み	はい	原則いいえ	いいえ
dequantize後の一時weight	はい	永続parameterではない	いいえ
LoRA行列 \(A,B\)	はい	はい	はい
activation	はい	backward用に必要	parameterではない

この区別により、ベース全体の高精度gradientとoptimizer stateを持たずに済みます。一方でadapterへ勾配を計算するためのactivationは消えません。長いsequenceでactivationが支配的なら、4-bit化だけでOut Of Memory（OOM、GPUメモリ不足）が解決しない理由はここにあります。

block-wise量子化を式で理解する

巨大なtensor全体を一つのscaleで量子化すると、少数の外れ値に範囲を合わせた結果、多くの小さい値を粗く丸めることがあります。QLoRAで使う量子化は重みをblockへ分け、blockごとに正規化用の定数を持ちます。

あるblockの重みを \(w_1,\ldots,w_B\)、正規化定数を \(c\) とします。概念的には、重みを \([-1,1]\) 付近へ正規化し、16通りのcodeへ写します。

c = \max_i |w_i|

q_i = Q_{\mathrm{NF4}}\left(\frac{w_i}{c}\right)

計算時は、codebook（codeと代表値の対応表）から値を取り出し、scaleを戻します。

\widehat{w_i} = c \cdot D_{\mathrm{NF4}}(q_i)

ここで \(\widehat{w_i}\) は元の \(w_i\) と完全には一致しません。差 \(\widehat{w_i}-w_i\) が量子化誤差です。実装ではzero、packing、block size、scaleの型など追加要素があり得ますが、重要なのは「4-bit codeだけでは復元できず、block metadataも必要」という点です。

blockを小さくすれば局所的な分布へ合わせやすい一方、block数が増えてscaleなどのmetadataが増えます。blockを大きくすればmetadataは減りますが、範囲の異なる値を同じscaleで表すため誤差が増える可能性があります。量子化には、誤差とmetadata overheadのtrade-offがあります。

NF4はなぜ等間隔の4-bitではないのか

4-bitで表せるcodeは16通りです。単純なuniform quantization（等間隔量子化）では、正規化した範囲へ代表値をほぼ等間隔に置きます。しかし、事前学習済みweightは0付近に多く、端の値は少ないという分布を示すことがあります。同じ16点なら、値が密な領域へ多くの代表値を割り当てたほうが平均的な誤差を減らせます。

NF4（4-bit NormalFloat）は、独立な正規分布から得られた値という仮定のもとで、各quantization binの確率質量を揃える考え方からcodebookを作ります。0を正確に表せるよう調整し、正規化した重みを16レベルへ写します。

観点	Uniform 4-bit	NF4
代表値の配置	値の範囲でほぼ等間隔	正規分布の確率質量を意識
得意な前提	範囲内へ比較的一様に分布	0付近へ密集する正規分布に近い重み
0の扱い	設計に依存	正確な0を含むよう構成
注意点	中央の解像度が不足し得る	分布が仮定から外れると優位性は保証されない

NF4が「どんなtensorにも最適」という意味ではありません。QLoRA論文が示す情報理論的な最適性は分布の仮定に基づきます。重み以外のactivation、外れ値の強いtensor、学習で分布が変化し続けるparameterへ、そのまま同じ結論を広げるべきではありません。QLoRAでベース重みを凍結する設計は、この前提とも整合します。

Double Quantizationは何を二重量子化するのか

block-wise量子化では、各blockの4-bit codeに加えて量子化定数 \(c\) を保存します。例えば64 parameterごとにFP32 scaleを1個持つだけでも、scaleは1 parameter当たり0.5 bitのoverheadです。

\frac{32\ \mathrm{bit}}{64\ \mathrm{parameter}} = 0.5\ \mathrm{bit/parameter}

Double Quantizationは、重みを同じ手順で二回丸めるのではありません。最初の量子化で生じた量子化定数の集合を、さらにblockへまとめて量子化します。

元のweight blockを4-bit codeへ変換し、blockごとの定数を得る。
その定数列を再び量子化し、第二段の定数と低bit表現で保持する。
計算時はmetadataを復元してからweightをdequantizeする。

QLoRA論文は、この工夫で平均約0.37 bit/parameterを削減したと報告しています。65B parameterへ単純換算すると次です。

65\times10^9 \times \frac{0.37}{8} \approx 3.01\times10^9\ \mathrm{byte}

十進表記なら約3.0GBです。ただし0.37 bitは論文の設定における平均値です。モデル構造、量子化対象、block size、metadata形式が違えば同じ値になる保証はありません。

Paged Optimizerは何を退避するのか

QLoRAでベース重みは凍結されるため、ベース全体のoptimizer stateはありません。それでも、長いsequenceやgradient checkpointing（forwardの一部を再計算してactivation保存量を減らす手法）を使うと、特定のstepで一時的なメモリpeakが発生します。

Paged OptimizerはNVIDIA Unified Memoryを利用し、必要に応じてoptimizer stateのpageをGPU VRAMとCPU RAMの間で移動できるようにします。役割は、平均使用量には余裕があるのに瞬間的なpeakでOOMになる事態を緩和することです。

誤解	実際
optimizerを常にCPUだけで計算する	必要に応じてpageを移動する仕組み
VRAMを無限に増やす	CPU RAMにも上限があり、転送帯域とpage faultのcostがある
学習を高速化する	主目的はOOM回避で、転送が多いと遅くなり得る
activationをすべてpagingする	Paged Optimizerが直接扱う中心はoptimizer state
4-bit化の代わりになる	ベースweight削減とは別の層を担当する

毎stepで大規模なpage移動が起きるなら、OOMを避けてもthroughput（単位時間当たりの処理量）が大きく低下します。GPU使用率だけでなく、step time、host RAM、CPU-GPU転送量も確認します。pagingは設計上の余裕を作る安全弁であり、恒常的な不足を隠す無料の拡張VRAMではありません。

QLoRAのメモリは七つの箱で考える

4-bit raw weightの計算だけでは、学習に必要なVRAMを見積もれません。少なくとも次の内訳へ分けます。

QLoRA学習時のweight・metadata・adapter・activationなどのメモリ内訳

メモリ要素	QLoRAでの扱い	主な調整レバー
量子化ベースweight	大きく減る	bit幅、量子化対象、backend
scale・codebook・packing metadata	追加で必要	block size、Double Quantization
LoRA parameter	小さいが増える	rank、target modules
LoRA gradient	学習対象分だけ必要	rank、target modules、dtype
optimizer state	adapter分だけ必要	optimizer種類、stateのbit幅、paging
activation	量子化しても残る	sequence length、micro batch、checkpointing
一時buffer・runtime	kernel実装ごとに必要	attention実装、device配置、library version

さらにCUDA context、allocatorのreserved領域、通信buffer、dataset batchなどもあります。メモリmonitorでは「現在割り当て中」と「frameworkが予約中」を分け、GPUだけでなくCPU RAMとswapも見ます。GPU VRAMが低く見えても、CPUへ大量offloadされていれば実行速度やhost memoryが問題になります。

7B・13B・65Bのraw weight比較

量子化前のparameter数を \(N\)、1 parameter当たりのbit数を \(b\) とすると、生のweight容量は次です。

M_{\mathrm{raw}} = N \times \frac{b}{8}\ \mathrm{byte}

十進表記の単純計算は次のとおりです。

公称parameter数	16-bit raw weight	4-bit raw weight	差
7B	約14GB	約3.5GB	約10.5GB
13B	約26GB	約6.5GB	約19.5GB
65B	約130GB	約32.5GB	約97.5GB

これは「モデルがそのVRAMへ必ず収まる」という表ではありません。公称parameter数と実parameter数の差、量子化しないmodule、metadata、adapter、activation、一時bufferを加える必要があります。OSでGiB表示する場合は1GiBが \(2^{30}\) byteなので、十進GBとも値がずれます。

sequence lengthがOOMを起こす理由

ベースweightはsequence lengthを変えてもほぼ同じですが、activationとattention関連memoryは入力長、batch、layer数、hidden size、kernelに応じて増えます。したがって、短いpromptでロード確認できても、学習用の最大長ではOOMになることがあります。

切り分けでは、次の順に測ると原因を絞れます。

モデルload直後のVRAM。
forward後のpeak。
backward後のpeak。
optimizer step後のpeak。
sequence lengthとmicro batchを半分にしたときの変化。

load時点で不足するならweight・device配置が中心です。forward/backwardで急増するならactivationや一時buffer、optimizer stepだけで増えるならstateやpagingを疑います。

論文の「65Bを48GB GPUで学習」をどう読むか

QLoRA論文は、65B parameter modelを単一の48GB GPUでFine-tuningできたと報告しました。これは、4-bit base、LoRA、Double Quantization、Paged Optimizerを組み合わせた省メモリ効果を示す代表的な結果です。

ただし次の条件を外して、「どの65Bモデルでも48GBなら学習できる」と一般化してはいけません。

model architectureと実parameter数
quantization blockと対応kernel
sequence lengthとmicro batch
gradient accumulationとcheckpointing
LoRA rankとtarget modules
optimizer、dtype、一時buffer
library、driver、GPU世代

raw 4-bit weightだけで約32.5GBなので、48GBとの差約15.5GBへすべてのmetadata、adapter、activation、runtimeを収める必要があります。長いcontextや広いtarget modulesでは条件が変わります。論文の数値は「可能性を示した実験結果」であり、容量計画の保証値ではありません。

実装は七段階で検証する

現在のHugging Face系構成では、PEFTの量子化ガイドが、4-bit load、NF4、Double Quantization、compute dtype、k-bit学習用の準備、LoRA挿入という流れを示しています。重要なのは設定例をコピーすることではなく、各段階の不変条件を確認することです。

段階	決めるもの	確認するもの
1. base固定	model ID、revision	想定したparameter数とlicense
2. 量子化設定	4-bit、NF4、Double Quantization	Linear layerが実際に量子化されたか
3. 計算設定	BF16/FP16、attention実装	hardware対応、代表moduleのdtype
4. k-bit学習準備	gradient checkpointingなど	input gradient経路、cache設定
5. LoRA挿入	rank、alpha、target modules	module名、個数、trainable比率
6. 学習	data、loss、optimizer	finite loss、gradient、peak memory
7. 保存・再読込	adapter、base revision、tokenizer	別processで同じ出力を再現できるか

代表的な設定名には、4-bit load、NF4 quantization、double quantization、BF16 computeがあります。ただし名前と既定値はlibrary versionで変わり得ます。実験記録には設定値だけでなく、Transformers、PEFT、bitsandbytes、PyTorch、CUDA、driverのversionも残します。

target modulesは文字列ではなく実体を確認する

QLoRA論文は広い層へLoRAを適用する構成を検討し、現在のPEFT公式ガイドにはarchitecture差を吸収する方法として全Linear layerを対象にする指定があります。しかし、モデルによってmodule名や出力headの扱いは違います。

設定後に最低限、次を確認します。

挿入されたLoRA moduleの完全な名前と個数。
trainable parameterが0ではないこと。
LoRA以外に意図せずtrainableなparameterがないこと。
rankと行列形状から計算したparameter数と実数が合うこと。
一つのbatchでadapterへ有限なgradientが入ること。
出力headやembeddingも更新するなら保存対象に含まれること。

「all-linear」という名前でも、libraryが出力headを除外するか、独自moduleを認識するかは実装に依存します。対象を広げれば適応力が増える可能性がある一方、adapter、gradient、optimizer state、計算量も増えます。

device mapは学習戦略ではない

自動的なdevice配置でモデルがloadできても、それだけで分散学習の設計が完了したとは限りません。CPU offloadを含む配置はVRAMを低く見せますが、転送がbottleneckになり得ます。また複数GPUでは、data parallel、parameter sharding、pipelineなどでgradient同期と保存方法が異なります。

学習前にmoduleごとのdeviceを列挙し、意図しないCPU配置がないか確認します。単一batchが通っただけでなく、複数stepのstep timeとhost RAMを測ります。自動配置を使う場合も、結果としてどこへ何が置かれたかをartifactへ保存します。

dtypeの不一致は静かに速度と品質を変える

QLoRAでは複数dtypeが共存するため、暗黙のcast（型変換）が起きやすくなります。

症状	疑う箇所	確認
lossがNaNになる	FP16 overflow、学習率、入力値	compute dtype、gradient norm、最初にNaN化したmodule
想定より遅い	未対応kernel、FP32 fallback、CPU offload	profiler、module dtype/device、転送量
VRAMが想定より多い	非量子化module、cache、一時buffer	parameter別dtype、forward/backward peak
出力が大きく崩れる	量子化誤差、tokenizer、template	非量子化LoRAとの同条件比較
load時に型error	version不整合、backend非対応	version matrixと公式対応表

BF16が使えるhardwareなら有力な選択肢ですが、常に最速・最高品質とは限りません。GPU世代、kernel、mixed precision設定によって変わります。base weightのstorage dtypeと、LayerNormやadapterのdtypeを混同せず、実tensorから確認します。

datasetとtokenizerの事故は量子化では直らない

QLoRAが改善するのは主に学習時memoryです。データ品質、prompt形式、label mask、chat templateの問題はそのまま残ります。むしろ限られた計算資源で一回の学習を大切にするなら、開始前の小さな検証が重要です。

system、user、assistantの境界がtoken列で正しいか。
assistant部分だけを学習する設計なら、label maskが正しいか。
padding tokenとEOS tokenを同一視した影響を理解しているか。
最大長で重要な回答部分がtruncateされていないか。
trainとvalidationに同一promptや近い派生が漏れていないか。
new tokenを追加した場合、embedding resizeと保存対象が整合しているか。

new tokenのembeddingや出力headを更新したのにadapterだけ保存すると、再読込後に学習結果が欠けます。反対にそれらを更新しないなら、追加tokenが十分に学習されない可能性があります。量子化設定とデータ設定を別のchecklistで管理します。

保存・再読込・mergeは別工程として試験する

QLoRAの成果物は、多くの場合、量子化されたbase modelそのものではなくLoRA adapterです。再現にはadapter以外の情報も必要です。

base modelのIDと正確なrevision。
tokenizer revision、special tokens、chat template。
quantization方式、block関連設定、compute dtype。
LoRAのrank、alpha、dropout、target modules。
追加で保存したembeddingや出力head。
library、CUDA、backendのversion。
学習時のprompt形式と評価条件。

保存直後に同じprocessで推論できるだけでは不十分です。新しいprocessでbaseとadapterを読み込み、固定入力に対するlogitsまたは生成結果を比較します。base revisionが違うとshape errorになる場合も、読み込めるのに品質だけ変わる場合もあります。

量子化baseへのmerge

LoRAの更新は、浮動小数点baseなら概念的に次のようにmergeできます。

W_{\mathrm{merged}} = W_0 + sBA

4-bit codeへ \(BA\) をそのまま加算することはできません。一般にはbaseを浮動小数点へdequantizeし、更新を加算し、必要なら別途quantizeし直します。この過程では次が起き得ます。

dequantize中に大きなCPU RAMまたはVRAMが必要になる。
再量子化の丸めでmerge前と出力が変わる。
元のNF4 blockと同じmetadataにならない。
adapterを切り替える運用上の利点が失われる。
配布時にbase modelのlicense条件も関係する。

merge済みmodelはadapterとは別artifactとして扱い、merge前、浮動小数点merge後、再量子化後をそれぞれ評価します。検証が終わるまでは元adapterとbase revisionを残します。

よくある失敗を症状から切り分ける

loadだけでOOMになる

まず本当に4-bit Linearへ置換されたか、非量子化moduleがどのdtypeか、device配置に重複がないかを確認します。raw 4-bit計算へmetadataとruntime分を足し、GPUへ載せる前のhost RAM peakも測ります。model IDを変えた結果、想定よりparameter数が多い場合もあります。

forwardまたはbackwardでOOMになる

sequence length、micro batch、attention実装、gradient checkpointingを確認します。base weightではなくactivationが原因なら、LoRA rankだけを下げても効果は限定的です。最大長を半分にしたときpeakが大きく減るなら、activation側の可能性が高いと判断できます。

OOMは消えたが非常に遅い

CPU offload、Unified Memoryのpage移動、未対応kernelによるfallbackを疑います。GPU VRAMだけ見ず、CPU RAM、swap、PCIe転送、step timeを測ります。毎stepでpagingしているなら、micro batchやsequence lengthを調整して定常的にVRAM内へ収めるほうが速い場合があります。

trainable parameterが0、または少なすぎる

target module名がarchitectureと一致していない可能性があります。module一覧と挿入結果を出力し、数式から期待parameter数を計算します。対象名の部分一致で、意図しない層だけが選ばれる場合にも注意します。

lossは下がるのに生成品質が悪い

label mask、chat template、padding、truncate、validation leakageを先に確認します。そのうえで同じdata・seed・step数による非量子化LoRAと比較し、量子化固有の差か学習設計の差かを分けます。lossだけでなく固定promptの生成を保存します。

save後に品質が戻る、または出力が変わる

adapterとbase revision、tokenizer、quantization config、追加保存moduleを確認します。new tokenのembeddingや出力headを学習したのに保存されていないことがあります。別processでの再読込testを学習pipelineへ組み込みます。

Full Fine-tuning、LoRA、QLoRAの選び方

選択肢	強み	主なmemory	trade-off	向く条件
Full Fine-tuning	全weightを直接更新できる	base、gradient、optimizer state、activation	最も重く、checkpointも大きい	十分な計算資源と深い適応が必要
LoRA	更新と保存が小さい	高精度base、activation、adapter state	base weightは大きいまま	baseを無理なく載せられ、量子化誤差を避けたい
QLoRA	base weightも大幅に減らせる	4-bit base、metadata、activation、adapter state	kernel制約、量子化誤差、dequantize、paging	VRAM制約下で大きなbaseを試したい

QLoRAが常に最善ではありません。モデルが十分小さくBF16 LoRAで余裕があるなら、構成が単純で速度やdebug性に優れる可能性があります。反対に、QLoRAを使って一段大きいbaseを選ぶことで、小さいbaseをFull Fine-tuningするより良い品質を得られる場合もあります。比較するときはparameter数、data、学習budgetが同一かを明記します。

評価は品質・メモリ・速度・再現性を分ける

QLoRAの成功を「OOMせずlossが下がった」だけで判断しないよう、四つの軸を別々に記録します。

評価軸	最低限の指標	比較対象
品質	validation loss、task metric、固定prompt生成、人手確認	base、LoRA、QLoRA
メモリ	load後、forward、backward、step後のpeak、host RAM	同じsequenceとbatch
速度	tokens/sec、step time、初回compile、page transfer	warm-up後の定常区間
再現性	別process再読込、base revision、version、seed	保存前後のlogits・生成

品質比較では量子化以外の条件を揃えます。QLoRAだけ大きなbase、長い学習、異なるdatasetなら、「量子化の影響」は切り出せません。実用上の総合比較としては意味がありますが、原因分析の実験とは分けます。

生成評価では、短い一問一答だけでなく、長文、format遵守、未知入力、安全性、学習外taskも含めます。adapterをmergeまたは再量子化するなら、その後も同じsuiteを実行します。

QLoRA論文の結果と限界

QLoRA論文は1,000を超えるFine-tuned modelを用い、複数のmodel family、scale、instruction datasetを比較しました。Guanaco model familyではchatbot performanceを人手やGPT-4による評価も含めて検討し、限られたmemoryで大規模modelをFine-tuningできることを示しました。

一方、論文自身もchatbot benchmarkの信頼性に注意を向けています。自動評価者と人間評価が完全には一致せず、benchmarkによって順位が変わる可能性があります。「16-bit Fine-tuning performanceを保持」という結論も、評価task、data、model、指標の範囲で読む必要があります。

QLoRAの本質的な貢献は、単一scoreでFull Fine-tuningを置き換えたことではありません。凍結した4-bit baseを通してadapterを学習する実用的な構成と、NF4、Double Quantization、Paged Optimizerを組み合わせ、大規模な比較を可能にした点にあります。

導入前の最終チェックリスト

modelと量子化

base model IDとrevisionを固定した。
量子化対象moduleと非量子化moduleを列挙した。
NF4、Double Quantization、compute dtypeを明示した。
GPU、driver、CUDA、PyTorch、Transformers、PEFT、bitsandbytesの対応を確認した。
load直後のVRAMとhost RAMを記録した。

LoRAと学習

target module名と挿入数を確認した。
trainable parameter数を式と実測で照合した。
adapterへ有限なgradientが流れることを一batchで確認した。
sequence length、micro batch、checkpointing、optimizerを記録した。
forward、backward、optimizer stepごとのpeakを測った。

dataと評価

chat template、label mask、padding、truncateをsample token列で確認した。
trainとvalidationの重複を確認した。
base、LoRA、QLoRAを同条件でも比較した。
lossだけでなく固定promptの生成とtask metricを保存した。
throughput、paging、CPU RAMも評価した。

保存と再読込

adapterとbase revision、tokenizer、quantization configを一緒に管理した。
new tokenや出力headを更新した場合、保存対象へ含めた。
新しいprocessで再読込testを行った。
merge前後、再量子化前後を別artifactとして評価した。
modelとdatasetのlicense、配布条件を確認した。

まとめ

QLoRAは「モデル全体を4-bitで更新する手法」ではなく、4-bitで凍結したベース重みを計算時に展開し、LoRA adapterへ勾配を流すFine-tuning構成です。NF4は正規分布に近いweightを16レベルで表す問題、Double Quantizationはblock metadataを減らす問題、Paged Optimizerは瞬間的なmemory peakを耐える問題を担当します。

省メモリ効果を正しく見積もるには、raw 4-bit weightに加えて、scale、adapter、gradient、optimizer state、activation、一時bufferを分けて測ります。実装では、dtype、target modules、device配置、data形式、保存・再読込を検証し、品質、memory、速度、再現性の四軸でLoRAやFull Fine-tuningと比較してください。

前回：LoRAとは？低ランク更新の仕組み・rank・メモリ・実装を詳しく解説

QLoRAとは？NF4・Double Quantization・Paged Optimizerと実装上の注意点