LoRA / QLoRA / Adapter

全部を学習するのは、なぜ重い？

モデル全体を更新する方法をフルファインチューニング（full fine-tuning）と呼びます。重いのは、重みそのものに加えて、学習には「勾配」と「オプティマイザの状態」が必要だからです。

大規模学習のメモリを分析したZeROの論文は、混合精度でAdamを使う場合、1パラメータあたり約16バイト（16bitの重み2・勾配2、オプティマイザが持つ32bitの重みのコピー・1次モーメント・2次モーメントで計12）が必要だと見積もっています。7Bモデルなら 70億 × 16 ≒ 112GB。ここに学習途中の値（活性化）の分が加わります。

LoRA：重みに「低ランクの差分」を足す

LoRA（Low-Rank Adaptation）は2021年にMicrosoftの研究者らが提案した方法です。モデルの中の大きな行列 W（たとえば 4096×4096）をそのまま凍結し、学習で生じる変化 ΔW を、細長い2つの行列の積 B×A で表します。

flowchart TD
  X["入力 x"] --> W["元の重み W
凍結・学習しない"]
  X --> A["A
r × 4096"]
  A --> B["B
4096 × r"]
  W --> S["足し合わせる"]
  B --> S
  S --> Y["出力 Wx + BAx"]

r はランク（rank）と呼ばれ、8〜64程度の小さな数にします。4096×4096の行列は約1,678万個の数字ですが、r=16なら A と B を合わせて 16×4096×2 ≒ 13万個。学習する量は約0.8%で済みます。

論文では、GPT-3 175Bを例に、Adamでのフルファインチューニングと比べて学習するパラメータを1万分の1に、GPUメモリを3分の1に減らせたと報告しています。しかも品質は同等以上でした。さらに学習後は B×A を元の W に足し込めるので、推論が遅くならないのも大きな利点です。

QLoRA：土台を4bitに縮めてLoRAを学ぶ

LoRAで学習するパラメータは減っても、凍結した元の重みはGPUメモリに載せる必要があります。7Bモデルを16bitで持つと、それだけで約14GBです。そこで、土台の重みを4bitに量子化したまま凍結し、その上でLoRAを学習するのがQLoRA（2023年）です。

QLoRAの論文は、3つの工夫を紹介しています。

• NF4（4-bit NormalFloat）: 正規分布に近い重みに合わせて目盛りを配置した4bit形式
• 二重量子化（double quantization）: 量子化に使うスケール自体も量子化して、さらにメモリを削る
• ページドオプティマイザ（paged optimizers）: メモリが一時的に足りなくなったとき、オプティマイザの状態をCPU側に逃がす

論文では、65Bパラメータのモデルを48GBのGPU 1枚で微調整でき、16bitでのフルファインチューニングと同等のタスク性能を保てたと報告しています。量子化そのものについては第10章を参照してください。

メモリはどれくらい減る？

7Bモデルを例に、学習時に必要なメモリのうち「重み・勾配・オプティマイザ状態」の部分をざっくり比べてみます（学習途中の値＝活性化は含みません）。

LoRA部分は全体の1%未満なので、その勾配とオプティマイザ状態は数百MB程度に収まります。実際には活性化の分が文脈の長さやバッチの大きさに応じて加わるので、表の数字は「最低限これくらい」の目安と考えてください。活性化は、途中の値を保存せずに計算し直す勾配チェックポイント（gradient checkpointing）で減らせます。

Adapterとその仲間たち

「元の重みを凍結して小さな部品だけ学ぶ」という発想は、LoRAより前からありました。2019年のHoulsbyらの論文は、Transformerの各層の間に小さなネットワーク（Adapter）を差し込み、そこだけを学習する方法を提案しました。

現在の言語モデルの微調整では、LoRA系がほぼ標準になっています。結合すれば推論コストが増えない点と、ツールの対応が厚い点が大きな理由です。なお、文脈によっては「アダプタ」がLoRAの重みファイルを指す一般名詞として使われることもあるので、どちらの意味か注意しましょう。

LoRAの派生：DoRA・rsLoRA・初期化の工夫

LoRAには多くの改良版があります。Hugging FaceのPEFTライブラリは、2026年10月時点で数十種類の手法を収録しています。よく見かけるものを挙げます。

• rsLoRA: 係数を alpha ÷ r ではなく alpha ÷ √r にする工夫。ランクを大きくしたときの学習を安定させる（PEFTでは use_rslora=True）。
• PiSSA・OLoRA・EVAなどの初期化: A と B の初期値を、元の重みの特異値分解やデータから決めて、収束を速める。
• LoftQ: QLoRA向けの初期化。量子化で生じた誤差を打ち消すようにLoRAの初期値を決める。
• LoRA+: A と B で学習率を変えると効率が上がる、という提案。

まずは素のLoRAで始め、うまくいかないときに試すくらいの位置づけで十分です。なお2024年の論文「LoRA Learns Less and Forgets Less」は、LoRAはフルファインチューニングほど新しいことを学ばない一方、元の能力も忘れにくいと報告しています。どちらを選ぶかは「何を優先するか」次第です。

学習したLoRAの使い方：結合とマージ

学習が終わると、手元にはBaseモデルと、小さなアダプタのファイル（PEFTなら adapter_model.safetensors と adapter_config.json）が残ります。使い方は大きく2通りです。

1. そのまま載せる: Baseモデルを読み込み、その上にアダプタを載せて使う。差し替えや取り外しが自由。
2. 結合する（merge）: B×A を元の重みに足し込み、普通のモデルとして保存する。PEFTの merge_and_unload() がこれにあたり、推論時の遅延がなくなる。GGUFに変換して配りたいときもこの形にすることが多い。

さらに、別々に学習した複数のアダプタを1つに合成することもできます。PEFTの add_weighted_adapter は、重み付きの足し算（linear）のほか、TIES や DARE といったモデルマージの手法を選べます。TIESは「符号がぶつかる更新を整理してから足す」、DAREは「差分の一部をランダムに捨てて残りを拡大してから足す」工夫です。

たくさんのLoRAを1台で配る

アダプタが小さいことは、配信でも大きな武器になります。顧客ごと・用途ごとにLoRAを用意しても、Baseモデルは1つをGPUに載せておけば済むからです。

flowchart TD
  R1["リクエスト
model=営業用"] --> S["推論サーバー"]
  R2["リクエスト
model=法務用"] --> S
  R3["リクエスト
Baseのまま"] --> S
  S --> M["共通のBaseモデル
GPUに1つ"]
  S --> L["小さなLoRA群
必要な分だけ載せ替え"]

• vLLM: --enable-lora で起動し、--lora-modules 名前=パス でアダプタを登録。リクエストの model 欄でアダプタを選べ、Baseモデルへのリクエストと混ぜて処理できます。同時に扱う数は max_loras、最大ランクは max_lora_rank で指定します。
• llama.cpp（llama-server）: --lora でGGUF形式のアダプタを複数読み込み、リクエストごとに lora 欄で強さ（scale）を指定できます。ただしLoRAの設定が違うリクエストどうしはまとめて処理（バッチ化）されないため、性能が落ちることがあると説明されています。

研究では、2023年の「S-LoRA」が、アダプタをCPUメモリに置いて必要なものだけGPUに載せる工夫などで、数千個のLoRAを同時に配信できることを示しました。vLLMとサーバー型ランタイムについては第9章も参照してください。

はじめてのLoRA：設定の目安

数字はあくまで目安です。TRLのドキュメントも、アダプタの学習では新しいパラメータだけを学ぶため、1e-4程度の高めの学習率を使うのが一般的だとしています。データの質と量のほうが結果に効くことが多いので、まずは小さなデータで試し、評価しながら調整しましょう。ツールの選び方は第14章で扱います。