大規模なモデルをグローバルに微調整できないわけではなく、LoRA の方がコスト効率が高いだけです。チュートリアルは準備完了です。

データ量とモデルパラメータの数を増やすことが、ニューラル ネットワークのパフォーマンスを向上させる最も直接的な方法であると一般的に認識されています。現在、主流の大型モデルのパラメータ数は数千億レベルにまで拡大しており、「大型モデル」がますます巨大化する傾向は強まるでしょう。

この傾向は多くのコンピューティング上の課題をもたらします。数千億のパラメータを持つ大規模な言語モデルを微調整するには、トレーニングに長い時間がかかるだけでなく、大量の高性能メモリ リソースも必要になります。

大規模モデルの微調整にかかるコストを削減するために、Microsoft の研究者は低ランク適応 (LoRA) テクノロジを開発しました。 LoRA の巧妙な点は、モデル本体は変更せずに、元の大型モデルに取り外し可能なプラグインを追加するのと同じである点にあります。 LoRA はプラグアンドプレイで、軽量かつ便利です。

LoRA は、カスタマイズされた大規模言語モデルを効率的に微調整するための最も広く使用されている効果的な方法の 1 つです。

オープンソースの LLM に興味がある場合、LoRA は学習する価値のある基礎技術であり、見逃してはいけません。

ウィスコンシン大学マディソン校のデータサイエンス教授であるセバスチャン・ラシュカ氏も、あらゆる角度から LoRA を調査しました。彼は長年機械学習の分野を研究しており、複雑な技術的概念を分解することに非常に熱心です。何百もの実験を経て、Sebastian Raschka 氏は LoRA を使用して大規模モデルを微調整した経験をまとめ、Ahead of AI 誌に発表しました。

著者の当初の意図を維持しながら、Machine Heart はこの記事を次のようにまとめました。

先月、私と同僚が Lightning AI で管理しているオープンソースの Lit-GPT ライブラリに基づいた LoRA 実験に関する投稿を共有し、実験から学んだ主な教訓について説明しました。さらに、LoRA テクノロジーに関連するよくある質問にもお答えします。大規模なカスタム言語モデルの微調整に興味がある場合は、これらの洞察がすぐに開始するのに役立つことを願っています。

簡単に言うと、この記事で説明する主なポイントは次のとおりです。

1. LLM トレーニング (または GPU でトレーニングされた任意のモデル) には避けられない確率性がありますが、マルチ LUN トレーニングの結果は依然として非常に一貫しています。
2. GPU メモリが限られている場合、QLoRA はコスト効率の高い妥協策を提供します。実行時間が 39% 増加しますが、メモリが 33% 節約されます。
3. LLM を微調整する場合、オプティマイザーの選択は結果に影響を与える主な要因ではありません。 AdamW、スケジューラ付き SGD、またはスケジューラ付き AdamW のいずれの場合でも、結果への影響は最小限です。
4. Adam は、モデル パラメータごとに 2 つの新しいパラメータを導入するため、メモリを大量に消費するオプティマイザーであると考えられることがよくありますが、これは LLM のピーク メモリ要件に大きな影響を与えません。これは、メモリの大部分が追加のパラメータを保持するためではなく、大きな行列の乗算のために割り当てられるためです。
5. 静的なデータセットの場合、複数回のトレーニングなどの複数の反復はうまく機能しない可能性があります。これは通常、過剰適合につながり、トレーニング結果が悪化します。
6. LoRA を組み込む場合は、モデルのパフォーマンスを最大化するために、キーと値のマトリックスだけでなく、すべてのレイヤーに適用されていることを確認してください。
7. LoRA ランクを調整し、適切な α 値を選択することが重要です。ちょっとしたヒント: α 値をランク値の 2 倍に設定してみてください。
8. 14GB の RAM を搭載した単一の GPU で、わずか数時間で 70 億のパラメータを持つ大規模なモデルを効率的に微調整できます。静的データセットの場合、LLM を「オールラウンダー」に強化し、すべてのベースライン タスクで優れたパフォーマンスを発揮することは不可能です。この問題を解決するには、多様なデータ ソースや LoRA 以外のテクノロジの使用が必要になります。

さらに、LoRA に関するよくある質問 10 個にお答えします。

読者の皆さんが興味をお持ちであれば、LoRA をゼロから実装するための詳細なコードを含む、LoRA のより包括的な紹介をもう一度書きます。今日の記事では、主に LoRA の使用における重要な問題について説明します。正式に始める前に、いくつかの基本的な知識を追加しましょう。

LoRA の紹介

GPU メモリの制限により、トレーニング中にモデルの重みを更新するとコストがかかります。

たとえば、重み行列 W で表される 7B パラメータ言語モデルがあるとします。バックプロパゲーション中、モデルは損失関数を最小化するために元の重みを更新することを目的とした ΔW 行列を学習する必要があります。

重みは次のように更新されます: W_updated = W + ΔW。

重み行列 W に 7B 個のパラメータが含まれている場合、重み更新行列 ΔW にも 7B 個のパラメータが含まれており、行列 ΔW の計算には非常に多くの計算量とメモリが必要になります。

Edward Huらが提案したLoRAは、重み変化ΔWの部分を低ランク表現に分解します。具体的には、計算された ΔW を示す必要はありません。対照的に、LoRA は、下の図に示すように、トレーニング中に ΔW の因数分解表現を学習します。これが、LoRA の計算節約の秘密です。

上に示したように、ΔW の分解は、より大きな行列 ΔW を 2 つのより小さな LoRA 行列 A と B を使用して表す必要があることを意味します。 A の行数が ΔW と同じで、B の列数が ΔW と同じ場合、上記の分解は ΔW = AB と表すことができます。 (AB は行列 A と行列 B の乗算の結果です。)

この方法ではどのくらいのメモリが節約されますか?また、ハイパーパラメータであるランク r にも依存します。たとえば、ΔW に 10,000 行と 20,000 列がある場合、200,000,000 個のパラメータを保存する必要があります。 r=8 で A と B を選択した場合、A には 10,000 行と 8 列があり、B には 8 行と 20,000 列があり、10,000×8 + 8×20,000 = 240,000 個のパラメータとなり、200,000,000 個のパラメータの約 830 分の 1 になります。

もちろん、A と B は ΔW でカバーされるすべての情報をキャプチャすることはできませんが、これは LoRA の設計によって決まります。 LoRA を使用する場合、モデル W は事前トレーニング データセット内のすべての知識をキャプチャするためのフルランクの大きな行列であると想定します。 LLM を微調整する場合、すべての重みを更新する必要はなく、コア情報を取得するために ΔW よりも少ない重みを更新するだけで済みます。これが、AB 行列を通じて低ランク更新を実現する方法です。

LoRA の一貫性

LLM、つまり GPU でトレーニングされたモデルのランダム性は避けられませんが、LoRA を使用した複数の実験の後、LLM の最終的なベンチマーク結果は、さまざまなテスト セットで驚くべき一貫性を示しました。これは他の比較研究を実施するための優れた基礎となります。

これらの結果は、r=8 という小さな値を使用して、デフォルト設定で取得されたことに注意してください。実験の詳細については、私の別の記事をご覧ください。

記事リンク: https://lightning.ai/pages/community/lora-insights/

QLoRA コンピューティング - メモリのトレードオフ

QLoRA は、Tim Dettmers らによって提案された Quantified LoRA の略語です。 QLoRA は、微調整中にメモリ使用量をさらに削減する技術です。バックプロパゲーション中、QLoRA は事前トレーニング済みの重みを 4 ビットに量子化し、ページング オプティマイザーを使用してメモリ スパイクを処理します。

LoRA を使用すると GPU メモリを 33% 節約できることがわかりました。ただし、QLoRA の事前トレーニング済みモデルの重みの追加の量子化と逆量子化により、トレーニング時間は 39% 増加しました。

デフォルトでは、LoRA は 16 ビットの浮動小数点精度を持ちます。

• トレーニング時間: 1.85 時間
• メモリ使用量: 21.33GB

4ビットの通常の浮動小数点を持つQLoRA

• トレーニング時間: 2.79時間
• メモリ使用量: 14.18GB

さらに、モデルのパフォーマンスにはほとんど影響がないことがわかりました。これは、QLoRA を LoRA トレーニングの代替として使用し、一般的な GPU メモリのボトルネックの問題をさらに解決できることを示唆しています。

学習率スケジューラ

学習率スケジューラは、モデルの収束を最適化し、過剰な損失値を回避するために、トレーニング プロセス全体にわたって学習率を下げます。

コサインアニーリングは、コサイン曲線に従って学習率を調整するスケジューラです。学習率は最初は高く、その後は滑らかに減少し、コサインのようなパターンで徐々に 0 に近づきます。コサイン アニーリングの一般的なバリエーションはハーフ サイクル バリエーションであり、下の図に示すように、トレーニング中にコサイン サイクルの半分だけが完了します。

私の実験では、LoRA 微調整スクリプトにコサインアニーリング スケジューラを追加したところ、SGD のパフォーマンスが大幅に向上しました。しかし、Adam および AdamW オプティマイザーに対するその利点は小さく、追加してもほとんど変化はありません。

次のセクションでは、Adam に対する SGD の潜在的な利点について説明します。

アダム vs SGD

Adam および AdamW オプティマイザーは、ディープラーニングで人気があります。 70 億個のパラメータを持つモデルをトレーニングする場合、Adam を使用するとトレーニング中にさらに 140 億個のパラメータを追跡できます。これは、他の条件を変更せずにモデル パラメータの数を 2 倍にすることと同じです。

SGD はトレーニング中に追加パラメータを追跡できないので、ピークメモリの点で SGD が Adam より優れている点は何でしょうか?

私の実験では、AdamW と LoRA (デフォルト設定 r=8) を使用して 7B パラメータの Llama 2 モデルをトレーニングするには、14.18 GB の GPU メモリが必要でした。同じモデルを SGD でトレーニングするには、14.15 GB の GPU メモリが必要です。 AdamW と比較すると、SGD は 0.03 GB のメモリしか節約しません。これは無視できるほど小さい値です。

なぜメモリの節約がこんなに少ないのでしょうか?これは、LoRA を使用する場合、LoRA によってモデル パラメータの数が大幅に削減されるためです。たとえば、r = 8 の場合、7B Llama 2 モデルの 6,738,415,616 個のパラメータのうち、トレーニング可能な LoRA パラメータは 4,194,304 個のみです。

数字だけ見ると、4,194,304 個のパラメータは多いように思えるかもしれませんが、実際には 4,194,304 × 2 × 16 ビット = 134.22 メガビット = 16.78 メガバイトしか占めません。 (オプティマイザーの状態を保存およびコピーする際の追加オーバーヘッドにより、0.03 Gb = 30 Mb の差が見られました。) 2 は Adam によって保存される追加パラメータの数を表し、16 ビットはモデルの重みのデフォルトの精度を指します。

LoRA 行列の r を 8 から 256 に拡張すると、SGD が AdamW よりも優れていることが明白になります。

• AdamWを使用すると17.86 GBのメモリを消費します
• SGDを使用すると14.46 GBを消費します

したがって、行列のサイズが大きくなると、SGD のメモリ節約が重要な役割を果たします。 SGD は追加のオプティマイザー パラメーターを保存する必要がないため、大規模なモデルを処理するときに Adam などの他のオプティマイザーよりも多くのメモリを節約できます。これは、メモリが限られたトレーニングタスクにとって非常に重要な利点です。

反復トレーニング

従来のディープラーニングでは、トレーニング セットを複数回反復することが多く、各反復はエポックと呼ばれます。たとえば、畳み込みニューラル ネットワークをトレーニングする場合、数百のエポックを実行するのが一般的です。では、複数回の反復トレーニングは、指示の微調整にも影響を与えるのでしょうか?

答えは「いいえ」です。Alpaca のサンプル命令の微調整の 50,000 データセットの反復回数を 2 倍にすると、モデルのパフォーマンスが低下しました。

したがって、複数回の反復は命令の微調整には有益ではない可能性があると結論付けます。 1k サンプルの LIMA 命令微調整セットで​​も同じ動作が観察されました。モデルのパフォーマンスの低下は過剰適合によって引き起こされる可能性があり、具体的な理由についてはさらに調査する必要があります。

より多くのレイヤーでLoRAを使用する

次の表は、選択されたマトリックス (つまり、各トランスフォーマーのキーマトリックスと値マトリックス) に対してのみ LoRA が機能する実験を示しています。さらに、クエリ重みマトリックス、投影層、マルチヘッドアテンションモジュール間のその他の線形層、および出力層でも LoRA を有効にできます。

これらの追加レイヤーの上に LoRA を追加すると、7B Llama 2 モデルのトレーニング可能なパラメータの数は 4,194,304 から 20,277,248 へと 5 倍に増加します。より多くのレイヤーに LoRA を適用すると、モデルのパフォーマンスが大幅に向上しますが、より多くのメモリスペースも必要になります。

さらに、私は 2 つの設定のみを検討しました: (1) クエリと重みマトリックスに対してのみ LoRA を有効にする、(2) すべてのレイヤーに対して LoRA を有効にする。LoRA をより多くのレイヤーと組み合わせて使用​​した場合の効果を調査すると興味深いでしょう。投影層で LoRA を使用するとトレーニング結果に有益かどうかがわかれば、モデルをより適切に最適化し、パフォーマンスを向上させることができます。

LoRA ハイパーパラメータのバランス: R と Alpha

LoRA を提案した論文に記載されているように、LoRA は追加のスケーリング係数を導入します。この係数は、順方向伝播プロセス中に LoRA 重みを事前トレーニングに適用するために使用されます。この拡張には、前述のランクパラメータ r と、次のように適用される別のハイパーパラメータ α (アルファ) が含まれます。

上図の式に示すように、LoRA 重みの値が大きいほど、影響が大きくなります。

以前の実験では、パラメータ r=8、alpha=16 を使用した結果、2 倍の拡張が実現しました。 LoRA を使用して大規模モデルの重みを減らす場合、アルファを r の 2 倍に設定するのが一般的な経験則です。しかし、この規則が r の値がさらに大きい場合にも当てはまるかどうかは興味深いです。

r=32、r=64、r=128、r=512 も試しましたが、わかりやすくするために省略しました。しかし、r=256 が最もうまく機能するようです。実際、alpha=2r を選択すると最適な結果が得られます。

単一のGPUで70億パラメータモデルをトレーニングする

LoRA を使用すると、単一の GPU でサイズが 70 億のパラメータを持つ大規模な言語モデルを微調整できます。この特定のケースでは、QLoRA の最適設定 (r=256、alpha=512) を使用して AdamW オプティマイザーを搭載した A100 で 17.86 GB (50,000 のトレーニング サンプル) のデータを処理するのに約 3 時間かかります (こちらが Alpaca データセットです)。

この記事の残りの部分では、皆さんが抱くかもしれないその他の質問にお答えします。

10の質問

Q1: データセットはどの程度重要ですか?

データセットは非常に重要です。私は 50,000 個のトレーニング例を含む Alpaca データセットを使用しています。とても人気があるのでアルパカを選びました。この記事はすでに非常に長いため、さらに多くのデータセットでのテスト結果についてはこの記事では説明しません。

Alpaca は合成データセットであり、今日の基準からすると少し古くなっている可能性があります。データの品質は重要です。たとえば、6 月に私は、わずか 1,000 個の例で構成された厳選されたデータセットである LIMA データセットについて説明する記事を書きました。

記事リンク: https://magazine.sebastianraschka.com/p/ahead-of-ai-9-llm-tuning-and-dataset

LIMA を提案する論文のタイトルにあるように、アライメントには「少ないほど良い」です。LIMA のデータ量は Alpaca より少ないですが、LIMA に基づいて微調整された 65B Llama モデルは Alpaca の結果よりも優れています。同じ構成 (r=256、alpha=512) を使用して、データ サイズが 50 倍の Alpaca と同様のモデル パフォーマンスを LIMA で取得しました。

Q2: LoRA はドメイン適応に適していますか?

この質問に対する明確な答えはまだありません。経験上、知識は通常、事前トレーニング データセットから抽出されます。通常、言語モデルは事前トレーニング データセットから知識を吸収し、命令の微調整の役割は主に LLM が命令に適切に従うのを支援することです。

限られた計算能力は大規模言語モデルのトレーニングを制限する主な要因であるため、LoRA は特定のドメインの特殊なデータセットで使用して、既存の事前トレーニング済み LLM をさらに事前トレーニングすることもできます。

また、私の実験には 2 つの算術ベンチマークが含まれていたことにも注目する価値があります。どちらのベンチマークでも、LoRA で微調整されたモデルのパフォーマンスは、事前トレーニング済みの基本モデルよりも大幅に低下しています。これは、Alpaca データセットに対応する算術例が不足していないため、モデルが算術知識を「忘れる」ためだと推測します。モデルが算数の知識を「忘れてしまった」のか、それとも単に指示に反応しなくなっただけなのかを判断するには、さらなる研究が必要です。しかし、ここでは 1 つの結論を導き出すことができます。「LLM を微調整するときは、関心のあるすべてのタスクの例を含むデータセットを用意しておくことをお勧めします。」

Q3: 最適な r 値をどのように決定しますか?

この問題に対するより良い解決策はまだありません。最適な r 値を決定するには、各 LLM および各データ セットの特定の状況に基づいた特定の分析が必要です。 r の値が大きすぎると過剰適合につながり、r の値が小さすぎるとモデルがデータセット内の多様なタスクを捕捉できなくなる可能性があると推測します。データセット内のタスクの種類が増えるほど、必要な r 値が大きくなるのではないかと思います。たとえば、基本的な 2 桁の演算を実行するモデルのみが必要な場合は、r の値を非常に小さくすれば十分な場合があります。しかし、これはあくまでも私の仮説であり、それを検証するにはさらなる研究が必要です。

Q4: すべてのレイヤーで LoRA を有効にする必要がありますか?

私は、(1) クエリと重みマトリックスに対してのみ LoRA を有効にする、(2) すべてのレイヤーに対して LoRA を有効にするという 2 つの設定のみを検討しました。 LoRA をより多くのレイヤーと組み合わせて使用​​することでどのような効果が得られるか、さらに研究する価値があります。投影層で LoRA を使用するとトレーニング結果に有益かどうかがわかれば、モデルをより適切に最適化し、パフォーマンスを向上させることができます。

さまざまな設定 (lora_query、lora_key、lora_value、lora_projection、lora_mlp、lora_head) を考慮すると、探索できる組み合わせは 64 個あります。

Q5: 過剰適合を避けるにはどうすればいいですか?

一般に、r はトレーニング可能なパラメータの数を決定するため、r が大きいほど過剰適合につながる可能性が高くなります。モデルが過剰適合している場合、最初に検討すべきことは、r 値を下げるか、データセットのサイズを増やすことです。さらに、AdamW または SGD オプティマイザーの重み減衰率を上げたり、LoRA レイヤーのドロップアウト値を上げたりすることもできます。

私の実験では LoRA のドロップアウト パラメータを調査しませんでした (固定ドロップアウト率 0.05 を使用しました) が、LoRA のドロップアウト パラメータも調査する価値のある問題です。

Q6: オプションとして他のオプティマイザーはありますか?

今年 5 月にリリースされた Sophia は試してみる価値があります。Sophia は、言語モデルの事前トレーニング用のスケーラブルな確率的 2 次オプティマイザーです。次の論文「Sophia: 言語モデルの事前トレーニングのためのスケーラブルな確率的 2 次オプティマイザー」によると、Sophia は Adam の 2 倍の速度で、より優れたパフォーマンスを実現できます。つまり、Sophia は Adam と同様に、勾配分散ではなく勾配曲率を介して正規化を実行します。

論文リンク: https://arxiv.org/abs/2305.14342

Q7: メモリ使用量に影響する他の要因はありますか?

精度と量子化の設定、モデル サイズ、バッチ サイズ、トレーニング可能な LoRA パラメータの数に加えて、データセットはメモリ使用量にも影響します。

Llama 2 のブロック サイズは 4048 トークンです。つまり、Llama は一度に 4048 トークンのシーケンスを処理できます。マスクが後のトークンに追加されると、トレーニング シーケンスが短くなり、メモリを大幅に節約できます。たとえば、Alpaca データセットは比較的小さく、最長シーケンス長は 1304 トークンです。

最大シーケンス長が 2048 トークンの別のデータセットを試したところ、メモリ使用量が 17.86 GB から 26.96 GB に急増しました。

Q8: 完全な微調整や RLHF と比較した LoRA の利点は何ですか?

RLHF の実験は行いませんでしたが、完全な微調整を試みました。完全な微調整には少なくとも 2 つの GPU が必要で、各 GPU は 36.66 GB を占有し、微調整を完了するには 3.5 時間かかりました。ただし、ベースライン テストの結果は良好ではなく、これは過剰適合または最適でないパラメーターによって発生している可能性があります。

Q9: LoRA の重みを組み合わせることはできますか?

答えはイエスです。トレーニング中は、LoRA の重みと事前トレーニング済みの重みを分離し、各フォワードパスでそれらを結合します。

現実世界では、アプリケーションのユーザーごとに 1 セットずつ、複数の LoRA 重みセットを持つアプリケーションがあると仮定すると、ディスク領域を節約するためにこれらの重みを個別に保存するのが理にかなっています。同時に、事前トレーニング済みの重みをトレーニング後の LoRA 重みと結合して単一のモデルを作成することもできます。この方法では、すべてのフォワードパスで LoRA の重みを適用する必要がなくなります。

 weight += (lora_B @ lora_A) * scaling

上記のように重みを更新し、結合した重みを保存できます。

同様に、LoRA 重みセットを多数追加し続けることができます。

 weight += (lora_B_set1 @ lora_A_set1) * scaling_set1 weight += (lora_B_set2 @ lora_A_set2) * scaling_set2 weight += (lora_B_set3 @ lora_A_set3) * scaling_set3 ...

このアプローチを評価するための実験はまだ行っていませんが、Lit-GPT に付属の scripts/merge_lora.py スクリプトを使用すれば可能です。

スクリプトリンク: https://github.com/Lightning-AI/lit-gpt/blob/main/scripts/merge_lora.py

Q10: レイヤーごとの最適ランク適応はどのように機能しますか?

簡単にするために、ディープ ニューラル ネットワークでは通常、各レイヤーに同じ学習率を設定します。学習率は最適化する必要のあるハイパーパラメータであり、さらに、レイヤーごとに異なる学習率を選択できます (PyTorch では、これはそれほど複雑なことではありません)。

ただし、これは余分なコストがかかる上に、​​ディープ ニューラル ネットワークで調整するパラメータが他にも多数あるため、実際にはほとんど行われません。異なるレイヤーに異なる学習率を選択するのと同様に、異なるレイヤーに異なる LoRA r 値を選択することもできます。私自身はまだ試していませんが、このアプローチを詳細に説明した論文があります: LLM 最適化: レイヤーごとの最適ランク適応 (LORA)。理論的には、このアプローチは有望であり、ハイパーパラメータを最適化するための余地が大きくあります。

論文リンク: https://medium.com/@tom_21755/llm-optimization-layer-wise-optimal-rank-adaptation-lora-1444dfbc8e6a