Cramming BERT, 2022-12-28

• Cramming: Training a Language Model on a Single GPU in One Day

• 2022-12-28

1 スケールアップとスケールダウン

トランスフォーマーアーキテクチャを用いた機械学習モデルの大規模な学習は、言語理解や自然言語生成を含む自然言語処理の多くのサブ分野で画期的な改善をもたらしている（Vaswani et al.2017; Dosovitskiy et al.2021; Radford et al.2019 ）。 現在では受け入れられている（しかし歴史的には驚くべき）これらのシステムの主要な動作は、確実にスケールすること、つまり、モデルのパラメータ数やデータ量が増加したときに継続的に性能を向上させることである。 Kaplanら(2020)が研究したように、これらの性能向上は様々なべき乗則によってよく記述される。これは、スケーリングが性能向上の鍵であるという支配的なパラダイムを設定するものです（Sutton, 2019）。 スケールの力は、極めて大規模なモデルの生産競争を引き起こし、その結果、言語モデルを訓練する能力があると感じる研究者や実務家がほとんどいない環境を作り出しました。 自然言語理解における多くの実用的なアプリケーションの基礎となる変換器となったオリジナルのBERTモデルDevlinら（2019）は、すでに訓練にかなりの量の計算を必要としていました。 しかし、Liuら（2019）の再現と改良は、計算のレベルを桁違いに引き上げることで、その性能をさらに向上させました。 このような事前学習済みのチェックポイントが様々な下流用途に普及するにつれ（Wolf et al., 2020）、最大の言語モデルの競争が産業ラボの焦点となったのです。 これにより、zettaFLOPスケール（Raffel et al., 2020; Yang et al., 2020; Zaheer et al., 2021）、後には非常に大きなyottaFLOPスケール（Brown et al., 2020; Black et al., 2022; Chowdhery et al., 2022; Rae et al., 2022）で計算量を犠牲にしつつ、 事前学習済み言語モデルの性能向上するトレーニング実行が行われるようになったのです。

私たちの目標は、この傾向を覆し、言語モデルの学習をどのようにスケールダウンするのが最適か、またその際にどのようなトレードオフが生じるかを調査することです。 1台のGPUで1日かけてゼロから学習した場合、控えめな研究者でもどの程度のダウンストリーム性能を達成できるのでしょうか？ このような控えめなリソースで、BERT の性能レベルまで言語モデルをトレーニングできることは、いくつかの興味深い意味を持ちます。 1つは、もしスケールダウンしたモデルの事前学習が、大規模な計算機による事前学習の実行可能なアナログであるならば、大規模モデルでは現在実現が困難な、さらなる学術的調査のホストを開くことになります。 例えば、既存の事前学習タスクと新しい事前学習タスクの違いに関する研究課題、モデルの予測値をデータポイントにトレースする（Ilyas et al., 2022）、メンバーシップ推論（Carlini et al., 2022）やデータポイズニング（Geiping et al., 2021）などのセキュリティに関する課題、 学習中に生じる安定性や一般化などのトピックに対する幅広い実証的調査（Nagarajan & Kolter, 2019; Jiang et al., 2019）、などだ。 同時に、法的要件により、出所が不確かな公開データで学習したモデルが許容されるかどうかが不明確であり、実務者が専門的または信頼できるデータソースを用いて言語モデルを再トレーニングすることに関心がある状況も想像できる（Wilka et al., 2017; Gold & Latonero, 2017）。 さらに、単にスケーリングノブを回すだけでなく、過去数年にわたるこの分野の研究の全体的な概念の進歩をベンチマークすることが動機となっています。 控えめなトレーニングリソースでBERTのようなパフォーマンスを達成するという目標は、2018年には考えられなかったと思われますが、現代の進歩と変圧器のトレーニング技術によって、これは現在可能かもしれません。

これらの疑問に答えるため、我々は「Cramming」と呼ぶ、テストの前日に言語モデル全体を学習する課題を検討します。 この研究では、まず学習パイプラインの様々な側面を調査し、どのような変更がスケールダウンシナリオで実際にパフォーマンスを向上させるかを確認します。 このような制約のある環境においても、大規模計算機で観測されるスケーリング則に忠実に従った性能が得られることを証明する。 この法則の当然の帰結として、スケールダウンは困難である。より小さなモデルアーキテクチャは勾配計算を高速化することができるが、時間の経過とともにモデルの全体的な改善率はほぼ一定に保たれる。 しかし、モデルサイズを犠牲にすることなく、勾配計算の実効速度を向上させることで、スケーリング則を利用した学習レシピの変更を発見し、改善を図ることができる。 最終的には、わずかな予算で、GLUEタスクでBERTに近い、時にはそれを超えるような、立派な性能を達成するモデルを訓練することができました1。

事前学習を多くの研究者ができるようにする意義を解いている。 論文の概要として、モデルをスケールダウンした状態で、様々な側面で変更がどのように影響するかを確認する。 そしてモデルサイズを犠牲にすることなく、勾配計算の実効速度を向上させることで、スケーリング則を利用した学習レシピの変更を発見した。 具体的には、この1台のGPU1日制約条件の元でGlueタスクをBERTあるいはそれを超えるようなモデルに事前学習することができた。

2 我々の手を後ろに縛る：限られた計算機でのセットアップ

この調査を始める前に、私たちが関心を持っている制限の範囲について概説したいと思います。 詰め込みのルールは以下の通りである。

• 任意の大きさの変換器ベースの言語モデルを、完全にゼロから、マスク言語モデリングで学習させる。

• 既存の事前学習済みモデルをパイプラインのいかなる部分にも含めることはできない。

• 下流データを除く任意の生テキストを学習に含めることができる。つまり、学習済みモデルを必要としないサンプリング機構であれば、データのサンプリング方法とタイミングを適切に選択することで、高速化を実現することができる。

• 生データのダウンロードと前処理は、総計算量から除外される。前処理にはCPUベースのトークナイザー構築、トークン化、フィルタリングが含まれますが、表現学習は含まれません（例えば、単語埋め込みの事前学習は、最終的な実行時間にカウントされない限り、許可されません）。

• トレーニングは1つのGPUで24時間行われます。

• ダウンストリームの性能はGLUE (Wang et al., 2018)上で評価される。

GLUE上でのダウンストリーム・ファインチューニングは、ダウンストリームタスクの訓練データのみを用いた短時間の訓練に限られ（5エポック以下を考慮）、すべてのGLUEタスクに対してグローバルに設定されたハイパーパラメータで動作する必要があります。 ダウンストリームの微調整は、総計算予算から除外されます。 我々の実装では、古典的なrtx2080ti GPU（2018年9月リリース）と、より最新のrtxa4000またはrtxa6000 GPU（2020年10月リリース）による個別のセットアップの両方を分析します。 各ユニットに4つのCPUコアと32GBのRAMを組み合わせています。 なぜこのような制限があるのでしょうか？私たちは主に、Devlinら（2019）のオリジナルのBERTセットアップを、限られた計算量で再調査することに興味があります。 最適なサイズと形状はスケーリング法則に依存するため、トランスフォーマーの最適なアーキテクチャは固定されていません（Kaplanら、2020）。 既存モデルの使用制限により、既存モデルからの蒸留（Turc et al., 2019; Jiao et al., 2020; Sun et al., 2020; Wang et al., 2020b; Kaliamoorthi et al., 2021）や既存の大規模モデルに基づくデータフィルタリング（Golchin et al., 2022）は除外されるが、 いずれも最終的には既に処理した情報の圧縮と転送に関する問いに答えてくれるものである。 さらに、我々はBERTを訓練するために使用される元のデータセットにデータを制限したくない、より良いデータのキュレーションと品質を通じて可能な改善を可能にしたいと思います。 rtx2080ti GPUは、Devlinら（2019）より前にリリースされたことを考えると、この実験のための自然な候補ですが、より最近のrtxa4000も、より最近の消費者グレードのワークステーション変種として興味深いと思います。 最後に、シングルユーザーワークステーションの上限であるrtxa6000のテストも行いました。 微調整の段階では、オリジナルのBERT微調整および評価セットアップを模倣したいと思いますが、例えば、計算量の多い下流トレーニング（Bahri et al, 2021a）、複数のダウンストリームデータセットの使用（例えば、他のタスクを微調整する前にMNLIで事前訓練を継続（Izsakら、2021））、 および各GLUEタスクの拡張ハイパーパラメータ最適化（Devlinら、2019；Liuら、2019；Lanら、2019）などが挙げられる。

詳細なスペックが述べられている。 GPUは、RTX 2080Ti、RTX A4000、RTX A6000で、現実的な価格なのは RTX2080Ti、RTX A4000だろう。 ColabのGPUでも検証可能な範囲ではある（２４時間動かすのはしんどいものの） CPUは4つのコアで、ホストメモリは32GBとのこと

3 効率的な変換器に関する関連作業

BERT のトレーニングにはどれくらいの時間がかかるのでしょうか？ 一般的に、ハードウェアとソフトウェアのセットアップが乱暴に変化し、効率の尺度が異なるため、この質問に答えるのは困難です（Dehghani et al.、2021年）。 トレーニング実行の計算の上限は、実行のウォールクロックバジェット上で利用可能な（低精度の）浮動小数点演算の総数を見つけることによって確立することができます。 このピーク値は、高度に最適化されたモデルであっても実際の計算では到達しませんが（Chowdhery et al.、2022）、トレーニング実行の実現に必要な有償バジェットを表しています。 表1では、いくつかの選択された訓練実行の予算をまとめています。 TPU上でのBERTの最初のトレーニング実行の後、初期の反応では、GPU上で同等の結果を得るために最大11日間の計算を推定しました（Dettmers, 2018）。 しかし、特にソフトウェアにおける持続的な改善により、上限は大幅に減少しました (You et al., 2019; Narasimhan, 2019)。 しかし、レシピと実装は一般に、サーバーノード全体（GPUの場合）またはTPUスライスを必要とし、より大きなBERTアーキテクチャをターゲットにしています。

BERTの改良を議論する他の仕事は、元のBERTに近い計算設定をターゲットにしており、例えば、SqueezeBERT（Iandolaら、2020）は4日間、8枚のTitan RTXカードを採用しています。 Sellamら（2022）は、オリジナルのBERTトレーニング実行が異常値であり、そのトレーニング時間を2倍にすることでオリジナルの結果をより確実に再現することに言及しています。 限られたリソースでのBERTトレーニングのための私たちの中心的な比較ポイントは、全体的に同様の制限で24時間以内にBERTをトレーニングするという目標も試みたIzsakら（2021）の仕事ですが、8 V100GPUを備えたフルサーバノードを使用します。 Izsakら（2021）は、BERTLARGEアーキテクチャの変種を選択し、修正された学習率スケジュール、大きなバッチサイズ、スパース予測、パックシーケンスなどの様々な微調整を含む、128のシーケンス長で訓練しています。 我々はこの設定を、我々の計算予算（約15倍小さい）のベースライン設定として再評価しています。

効率的なトランスフォーマーの研究 近年、Vaswaniら（2017）で提案されたトランスフォーマーアーキテクチャを改善・修正するための研究が盛んに行われており、この分野の研究の最近の分類とレビューについてはTrevisoら（2022）を参照する。 いくつかのメタ研究では、提案された改善や修正について調査している。Narangら（2021）は、Raffelら（2020）のT5モデルパイプラインに適用された幅広いアーキテクチャの修正を、言語理解と翻訳の両方のタスクについて評価している。 T5のエンコーダ・デコーダ構造は、精神的にはオリジナルのトランスフォーマーセットアップに近いが、エンコーダコンポーネントを使用する場合はBERTと同様の動作をすることが理解されている（Liu et al.、2021a）。 TPUスライスの1.75日の計算で修正を評価することで、彼らはほとんどの改善が最終的な精度のゲインを確実に実現しないことを発見します。 Tayら（2021）は、同じ設定で作業し、T5由来のアーキテクチャの最適な形状と、モデルがスケーリングされたときのダウンストリーム性能に対する相対的な効果を評価します。 Tayら（2022a）の様々なアーキテクチャの改良のスケーリング動作のさらなる探求は、特にダウンストリーム精度を評価する際に、すべてのスケールでVaswaniら（2017）のオリジナルアーキテクチャを上回るわずかな修正しかないことを発見する。 Scaoら（2022）の極端なスケールのトレーニングに備えた改善を調査するメタスタディは、レイアウト、位置埋め込み、自己回帰モデルのデータソースへの小さな修正に焦点を当てており、他の極端に大規模なトレーニング実行は、 これまで同様にその設定において保守的でした（Brownら、2020; Blackら、2022; Raeら、2022)。 しかし、一般的に、これらの評価は、我々が使用する予定よりも大きな計算機設定を対象としており、改善点（多くの場合、学術的なソースから、小規模の評価で提案された）がより大きなスケールに変換されるかどうかに関係しているのである。

この研究では、(アップ)スケーリングの問題はさておき、限られた計算量にのみ焦点を当てます。 スケーリング則 具体的な改善点を見つけることの難しさは、Kaplanら(2020)のスケーリング則に反映されています。 Kaplanら(2020)は、広範囲のトランスフォーマーモデル形状において、モデルサイズ（非埋め込み層のパラメータ数として）のみが性能を強く予測することを見出しています。 さらに、固定された計算バジェットに対して、最適なモデルサイズを導き出すことができますが、性能とモデルサイズとの関連はわずかで、より大きなモデルは単位計算量あたりのデータ処理量が少ないものの、ほぼ同じマージンで高速化されます。 これらのスケーリング則の正確な係数と形状は、反復され続け（Hoffmannら、2022）、関連する設定に適応される（Bansalら、2022；Clarkら、2022；Bahriら、2021b）ものの、その全体の論理は、たとえ小さなスケールでのパワー則がややうまくいかない観測に適合するとしても、逃れがたいように思われます。

関連研究についての言及。 ここは言わんとすることがまだよく理解できていない。

4.調査

我々の実験的評価のために、我々はDevlinら（2019）のセットアップにかなりの数の提案された修正を実装し、セクション2で説明したように我々の限られた計算機設定におけるそれらの利点についてテストする。 我々はまず、共通の実装と初期データセットアップを明らかにし、次にアーキテクチャ、トレーニング、データセットの改善を調査する。

4.1 実装の詳細

我々は、PyTorch（Paszke et al., 2017）ですべてを実装し、「ソフトウェアくじ」（Hooker, 2021）からの利益を制限するために、確立されたコンポーネントにさらに結果を偏らせるであろう、特殊な実装を使用しない。 我々は、PyTorchフレームワークの実装レベルですべてを維持し、すべてのコンポーネントに適用可能な自動演算子融合（Sarofeen et al.、2022）のみを許可します。 最終的なアーキテクチャの変種を選択した後にのみ、我々は次にDaoら（2022）に記載された効率的な注意カーネルを再有効化する。 我々は、標準的な16ビットおよび32ビット浮動小数点精度（完全な32ビットフロート、スケーリングされた16ビット（Rasleyら、2020）および純粋なbfloat16（Wang & Kanwar、2019）以上）の自動混合精度（Micikeviciusら、2018）の同じ設定を用いてすべての実験とアブレーション研究を実行する。 我々の設定において、オフロード(Ren et al., 2021; Rasley et al., 2020)の利点は見いだせません)。 初期データ設定 私たちは、Devlinら(2019)のオリジナルの生テキストソースに近いアナログで調査を開始し、英語のWikipedia (20220301.en)と英語のブックコーパスの最近のダンプを使い、Tan (2019); Bandy & Vincent (2021) の解説を参照した。 全てのテキストを強制的に小文字にし、アクセントと非アスキー文字を取り除き、このデータのみに基づいて英語のトークナイザーをゼロから作成します。 語彙サイズ2 15 = 32768 (Wu et al., 2016)のWordPieceを選択した。 BPE (Sennrich et al., 2016) や SentencePiece with Unigrams (Kudo, 2018; Kudo & Richardson, 2019) では性能に大きな変化がないことを確認した。 小さい語彙サイズ(2 12 , 2 13 , 2 14)はパフォーマンスが低下し、大きい語彙サイズ(2 16)は信頼できるほど良くはならなかった。 トークン化されたデータを長さ128のランダムなシーケンスにパックし、無関係なフラグメントをで分離する。このセパレータを削除したことによる性能への影響は最小限であった。 また、事前学習でトークンを入れても影響は見られなかった。 短い配列長は、我々がターゲットとしているダウンストリームアプリケーションにとって十分であり、注意の計算を簡素化することができます。 データを完全なシーケンスにパックすると、より単純なシーケンスロスに制限されるが、利用可能な計算機を最適に使用するLiuら（2019）；Izsakら（2021）。 対象となる計算機設定の場合、このシーケンス長は、gtx2080ti上のベースBERTアーキテクチャのほとんどのバリエーションで64から96のマイクロバッチサイズになり、これをより大きなバッチサイズに蓄積します。 私たちの限られた計算予算で、これは、データポイントが再訪されないシングルエポックトレーニング（Komatsuzaki, 2019; Hernandez et al.

auto operator fusionのみ許可とあるが、何かはわからない。 Daoら（2022）に記載された効率的な注意カーネルを再有効化している。 演算精度については多くの研究を踏襲している。 語彙サイズは2^15のWordPieceを選択、語彙サイズの変化で良い結果は得られなかった。 系列長を短くすることは、後段の処理にとって十分であれば簡素化することが可能。

4.2 アーキテクチャの変更

効率的に学習をスケールダウンする最も明白な方法は、モデルアーキテクチャを修正することである。 直感的に、詰め込み体制ではより小さい／より低い容量のモデルが最適である可能性が高いと思われる。 このセクションでは、モデルの種類と学習効率の関係について研究しています。

スケーリング則はスケールダウンの強い障壁となることがわかります。 トークンごとの学習効率はモデルサイズに強く依存するが、トランスフォーマーのタイプには依存しない。 さらに、小さいモデルは学習効率が悪く、スループットの向上はほとんど見込めません。 幸いなことに、同じサイズのモデルであれば学習効率はほぼ一定であるため、パラメータ数をほぼ一定に保ちながら勾配計算を高速化するアーキテクチャの改良によって、性能を向上させることができます。 このため、単一の勾配ステップの計算時間にどのような影響を与えるかを主な基準として設計を選択することができ、アーキテクチャの選択が非常に容易になります。

低リソース領域でもスケーリング則は成立する

近年、多くの研究がオリジナルの変換器を高速化するためのアーキテクチャの改良を開発しています。 これらの方法の多くは、大規模なT5アーキテクチャの学習を改善することは発見されていません Narangら (2021); Tayら (2022a). しかし、データスループットが最重要視される低コンピュート環境では、もしかしたらこの方法が有効なのかも？Kaplanら(2020)は、高リソース領域でスケーリング則を観測しており、リソースが大きくなっても限界まで強く保持するようです。 驚くべきことに、これらの法則は極端な計算量のダウンスケールにおいても成立し、低コストのトレーニングに対する障壁となるのです。 図1では、文献にある多くの変換器のバリエーションについて、スケーリング則の効果を例示しています。ここでは、セクション4.3で後述するように最適化された学習ハイパーパラメータを用いて各アーキテクチャバリエーションを学習しています。 これらのアーキテクチャ変種を、前正規化と回転埋め込みを組み込んだ共有ベースラインモデルに適用する。 図1は、すべてのアーキテクチャを同じ時間予算で実行し、トークンの総数に対するMLM損失の進捗を視覚化したものです。 トランスフォーマーの種類とサイズを変えても、24時間後の最終的な損失にはほとんど影響がないことがわかります。 より多くのパラメータを持つモデルは、MLMの損失が勾配ごとに速く減少するため、より効率的に学習することができます。 しかし、小さいアーキテクチャは、遅い学習効率を高いスループットで補うため、限られた予算でより多くのトークンを処理することができます。 図1は、学習の初期段階（最初の1Bトークン）において、アーキテクチャの違いが予測できないことを示しています。 その後、トークンごとの効率は乗法定数（対数軸による水平方向のシフト）のみで異なっています。 この定数はモデルの種類ではなく、ほぼ完全にモデルサイズに依存するため、学習終了時には全ての選択肢が1.9前後のMLMロスに到達します。

スケーリング則を利用する

トークン単位の性能はモデルサイズと密接に関係しているため、スケーリング則は変換器のサイズとタイプを大きく変更することで大きな利益を得ることを阻んでいるように見えます。 その結果、Schwarzschild（2021）のようにBPTTで訓練しても、漏斗型変換器アーキテクチャを用いた場合（Daiら、2020；Nawrotら、2022）、FFN層を落とした場合（Sridharら、2022）、リカレント層を用いた場合（Lanら、2019）、何の改善も見られません。 アーキテクチャをディープナローにリスケーリングしても（Tay et al., 2021; Wies et al., 2021）、何の利得も得られない。 この原理は、効率的にスケールダウンするための1つの扉を閉ざす一方で、別の扉を開きます。 勾配効率は同じサイズのすべてのモデルに対してほぼ一定であるため、モデルサイズをほぼ一定に保ちながら計算を高速化するアーキテクチャの選択を迅速に検索することによって、スケーリング則を利用することができます。 このカテゴリには、明らかな最適化が多数含まれており、以下では、それらに加えて、わずかではあるが価値ある/無料の利点をもたらす他のいくつかの調整について説明します。

アテンションブロック

我々はすべてのQKVバイアスを無効にします(Dayma et al., 2021)。 これは、計算の層を取り除くことによってスケーリング則を利用し、モデルサイズをほぼ一定に保ちながら、前方および後方通過をいくらか速くするものです。 我々は、これがGPU上でより良く並列化し、若干の性能向上をもたらすため、注目ヘッドの数を減らすことで勾配コストを減らせることを発見した（Merity, 2019; Araabi & Monz, 2020; Liu et al., 2021b; Javaheripi et al., 2022）。 しかし、ヘッドの量を減らすと微調整の性能も低下するため、最終的には12ヘッドすべてを維持する。 ソフトマックス演算への置き換えによるメリットは見いだせない(Richter & Wattenhofer, 2020)。 さらに、オリジナルの多頭自己アテンション機構を維持する。 効率的な注意（Sukhbaatar et al., 2019; Beltagy et al., 2020; Wang et al., 2020a; Liu et al., 2021c）、効率的注意の研究（Tay et al., 2020a；b）は大量に行われている。 しかし、最大配列長を128に設定したため、我々の設定において注意の複雑さはあまり気にならない。 これを検証するために、最近提案されたFLASH機構(Hua et al., 2022)を実装したが、利点は見いだせなかった。 我々はさらに、Lee-Thorpら（2021）で提案されたFourier attentionを実験するが、何の改善も見出せない。 ロータリー埋め込み（Su et al., 2021; Black et al., 2022）は小さな利点をもたらすが、速度の低下によって相殺されるため、最終的にこれらを採用しないことにした。

ここでようやく系列長が通常512であるが128に落とされていることが分かった。これは効果は大きそう。 また、QKVの重みのバイアスは無効化されている（もともとどうだっけ？）

フィードフォワードブロック

我々は、すべての線形層のバイアスを無効にすることから経験的な利得を見つける（Daymaら、2021）。 注意層と同様に、これはモデルサイズに顕著な影響を与えることなく、勾配計算を加速することによってスケーリング則を活用する。 その結果、モデルの改善速度を損なうことなく、より高いスループットを得ることができる。 元のフィードフォワードブロックはほとんど変更せず、GELU以外の活性化に変更しても何のメリットも見いだせなかった。 我々は、ブロックをゲート線形ユニットに再順序付けすることから小さな改善を見出す（Dauphin et al.、2017）。 他の仕事、例えば（Black et al., 2022）とは対照的に、我々はゲーティングによる隠れ次元の半減を補償するために、FFNブロックのパラメータ数を増加させない。 エンベッディングを行う。我々は、Huaら(2022)に記載されているように、鱗状正弦波位置埋め込みを実装し、学習されたまたは鱗状正弦波埋め込みに対する漸進的な利点を見出した。 入力と出力の埋め込みを切り離すことによる改善は見られない（Chung et al.、2020）。 Lanら(2019)からの入力エンベッディングを因数分解する提案は、我々の設定において利得を提供しない。 我々は、埋め込みブロックの最後にレイヤーの正規化を含める。

線形層のバイアスも無効化する。 「鱗状正弦波位置埋め込みを実装し、学習されたまたは鱗状正弦波埋め込みに対する漸進的な利点を見出した。」はポイントかも。

レイヤー構造

多くの研究で観察されるように、我々は、レイヤーノームによる事前正規化がポストレイヤーノームよりも有益であることを見出す（Baevski & Auli, 2018; Xiong et al.、2020）。 Liu et al., 2020b; Shleifer et al., 2021）のような、この修正の他のバリエーションから追加の利益を見いだすことはできない。 さらに、Layer NormalizationをRMS Normalizationに置き換えても利得は得られない(Zhang & Sennrich, 2019)。 我々は、事前正規化の重要な効果は、学習を安定させ、より大きな学習率とウォームアップの削減を可能にすることであり、それ自体を含むことによる利点は限られていると考えていることに留意する。 また、(Zhang & He, 2020)で説明されているように、層全体を確率的に削除することによる利点はない。

「レイヤーノームによる事前正規化がポストレイヤーノームよりも有益である」もポイントか

ヘッドブロック

我々は、非線形ヘッドを削除しても悪影響がないことを発見した。 我々はさらにデコーダバイアス(Radford et al., 2019)を落とし、スパーストークン予測(Liu et al., 2019; Izsak et al., 2021)を用いてメモリを獲得することができる。 さらに学習を安定させるために、最後のLayer Normを追加する。

ここは様々なポイントがある。

4.3 訓練設定の変更

我々は、BERT-base アーキテクチャに対するトレーニングハイパーパラメータの影響を研究している。 オリジナルの BERT トレーニングレシピは、当然のことながら、詰め込み設定におけるモデル性能が低い結果となるため、多くの標準的な選択を再検討する。

目的

我々は、15％のマスキング率でトークンの完全にパックされたブロックにマスクされた言語モデリングのみで訓練し、Devlinらのオリジナルの設定である。 (2019)では、全マスクの10%をランダムな単語で埋め、10%を変更しない。 より大きな率、例えば(Wettig et al., 2022)で提案された40%でのマスキングによる改善は見られない、付録を参照。 また、前述の20%ルールを有効にしても無効にしても差は見られない。 平均二乗誤差(Hui & Belkin, 2021)やL1損失など、マスク言語の目的に対する他の関数を評価したが、利点は見いだせなかった。

最適化器の選択

我々は、Adam (Kingma & Ba, 2015)を選択したオプティマイザとして維持し、(Loshchilov & Hutter, 2017)に記載されているように0.01の重み減衰、β1 = 0.9 、β2 = 0.98 、ε = 10-12とする。 余分なコストをかけずに学習を安定させるために、クリップ値0.5で勾配クリッピングを含む。 これらのパラメータを合理的に変化させても、顕著な変化は見られない。 他の一次適応型オプティマイザ（Shazeer & Stern, 2018; Liu et al., 2020a）をテストしましたが、我々の設定での利点は見つかりませんでした。 さらに、高次のオプティマイザを用いた利点も見いだせないが（Yadav, 2020; Anil et al., 2021）、特に高次のオプティマイザでは実装に大きなばらつきがあることに注意する。

学習率のスケジュールとピーク

Izsakら（2021）の助言に従い、学習率スケジュールを予算と連動させ、予算がゼロになると学習率が減衰するように再スケール化した。 興味深いことに、図2において、グローバルに多数の学習率形状が同様の損失低減をもたらす一方で、スケジュールの選択によっていくつかの利益を得ることができることが観察された。 我々は、10-3のピーク学習率を持つ単純な1サイクル学習率（Smith & Topin, 2018）が、我々の予算内で最小の事前学習損失をもたらすことを見出した。

バッチサイズスケジュール

我々の設定の特殊性は、単一のGPUに制限されているため、このGPUに入るマイクロバッチサイズ（ほとんどの実験で96）は、最適なバッチサイズよりも数倍小さいという点です。 この設定における最適なバッチサイズは、プリトレーニングロスを最小にするためには約1536であり、2080tiのダウンストリームパフォーマンスを最大にするためには4032であることがわかりました。 つまり、2080tiでは、勾配を蓄積し、それぞれ16回と42回のフォワード/バックワード・パスごとに更新を実行するだけです。 より大きなA4000とA6000カードでは、これは128/256のマイクロバッチサイズと4096の最終バッチサイズに相当し、我々は再びこれを蓄積します。 幸いなことに、積極的なバッチサイズスケジュールを用いることで、小さなスピードアップを見つけることができます。 この結果、トレーニングの早い段階でより進歩し、性能にわずかな利点をもたらす。 また、自動的かつ適応的なバッチルール（De et al., 2017; Bollapragada et al., 2018a;b）を実験したが、これらの適応的スケジュールからの最良の結果は、固定された線形スケジュールに類似していることがわかった。 簡略化のために、我々はただより単純な線形スケジュールに固執する。

ドロップアウトの削除

Devlinら（2019）のオリジナルのBERTモデルは、Vasw aniら（2017）のようにドロップアウトを含み、総計算予算に対してトレーニングデータが小さいときにオーバーフィッティングを防止するものである。 正則化として有用である一方、ドロップアウトは、関連する特徴がドロップされると更新が発生しないため、各パラメータが見る勾配更新の数を効果的に減少させる。 同時に、更新の実行時間はドロップアウトの存在に強く影響されないため、ドロップアウトは1秒あたりの更新を正味で減少させることになります。 crammingの設定では、学習データは計算量に比べ大きい。 シングルエポックスケジュールによりオーバーフィッティングは不可能であり、パラメータ更新数を最大化するため、プリトレーニング中はドロップアウトを無効化する(Brown et al., 2020)。 下流の微調整の際にドロップアウトを再度有効にし、ドロップアウト値を0.1に設定する。 さらに、長さカリキュラム（Li et al., 2022）（付録参照）とトークンドロップアウト（Hou et al., 2022）を実験したが、我々の設定での利得は見いだせなかった。

4.4 データセットの最適化

我々は、スケーリング法則が、アーキテクチャの修正によって（計算効率を超える）大きな利得を得るための障壁となることを上記で発見した。 しかし、スケーリング則は、より良いデータで学習することを妨げるものではありません。 1秒間に多くのトークンを学習する能力を使い果たしたら、より優れたトークンを学習することを目指さなければなりません。 我々は、より良いダウンスケーリングへの2つのデータベースの経路を考える。 まず、既存のデータを様々な方法でフィルタリング、処理、ソートする。 第二に、データソースを交換することである。

この目的のために、Gutenberg、Books3、Wikipedia (en)からの生テキストのみを含むThe Pile (Gao et al., 2020)のいくつかのサブセットを使って実験する。 これらのPileデータセットから、最初の4×106エントリーをトークン化し、我々のシングルパスに十分なトークンを生成する。 また、Common Crawl (Raffel et al., 2020) の巨大なクリーン版であるC4も人気のあるデータソースであり、ここから最初の20×106エントリをストリーミングする。 各データ・ソースに対して、セクション 4.1 で説明したように、独自の WordPiece トークナイザを再 生成します。 これら4つのソースのうち、PileがダウンストリームMNLI性能の面で最も優れていることがわかります。 しかし、特にC4データセットについては、追加処理によってさらに改善できることが判明した。

まず、Leeら(2022)に記載されているように、正確な部分文字列の重複排除を評価したが、我々のケースではダウンストリーム性能に役立たないことが分かった。 次に、圧縮不可能なデータに対するフィルタリングをテストします。 トークン化器そのものを使って、C4セットからうまく圧縮できないすべての学習シーケンスを削除します。単純に閾値t、例えばt = 0.3を設定し、エントリ内のトークン数が生の文字数のt倍より大きいすべてのエントリをデータセットから削除します。 これにより、例えば圧縮しにくいHTMLやmarkdownのコードで構成されたシーケンスなどを削除することができます。 驚くべきことに、この結果、C4が大幅に改善され、表2にまとめられています。

次に、2つの方向からさらにいくつかの改善が見られました。 1つ目は、トークン化されたすべてのシーケンスを何らかの指標でソートすること、2つ目は、最終的なバッチサイズを大きくすることです。 フィルタリングのために、我々はすべてのトークン化されたシーケンスをその平均（1グラム）トークンの有病率でソートし、可能性の高いシーケンスが最初に現れるようにする。 これは、より大きなコーパスから抽出することで、可能性の低いシーケンスに到達することがないため、若干強化することができる効果があります。 最後に、（セクション4.3で述べたように）学習の最後にバッチサイズを4032/4096に増加させることは、C4では不釣り合いに効果的ですが、bookcorpus-wikipediaではそれほどでもありません。 どちらの修正も最終的にはデータ分布の揺らぎによって学習が阻害される可能性を減らすことができると考えている。

語彙サイズ

また、(Devlin et al., 2019)に記載されている32768というオリジナルの語彙サイズが詰め込み体制で最適かどうかを確認する。 先験的に、これは成立しないかもしれない。語彙が大きければ大きいほど、固有トークンと固有トークン間の関係を訓練中に学習する必要がある。 一方、語彙のサイズを大きくすると、データはさらに圧縮され（ある時点で消滅しますが）、詰め込み学習時に摂取できるトークンの固定数に、より多くの情報を圧縮することが可能になります。 図3では、ブックコーパスとウィキペディアのデータにおいて、語彙サイズが大きいほど平均GLUEスコアが高くなることがわかりますが、MNLIタスクでは元の32768語彙サイズ付近で効果が頭打ちになっています。 今後、この語彙サイズを維持する。

5. glueの性能の微調整

最後に、Wang et al. (2018)のGLUEベンチマークで、Devlin et al. (2019)のようにWNLIを除いた性能を系統的に評価する。 我々は、前のセクションの間、MNLI（m）のみを使用し、完全なGLUEスコアに基づいてハイパーパラメータをチューニングしないことに注意します。 我々は、セクション2で敷設された同じ制約の下で、事前学習されたBERT-baseチェックポイントと我々のモデルの両方を微調整する。 BERT-baseでは、バッチサイズ32、学習率2×10-5で5エポックの間、すべてのデータセットを微調整しました。 詰め込まれたモデルについては、これは最適ではなく、バッチサイズ16、コサイン減衰を伴う学習率4×10-5からわずかな改善が得られることがわかります（このセットアップは、事前学習されたBERTチェックポイントを改善しません）。 表3および表4は、GLUEダウンストリームタスクにおけるこのセットアップの性能を示しています（5ダウンストリーム試験にわたる中央値として）。 そこでは、元のBERT-ベースチェックポイント、予算に達した後に停止したBERT事前訓練設定の再現、(Izsak et al., 2021)に記載されたセットアップ、および各GPUセットアップについて1日訓練した修正レシピを比較しています。 全体として、性能は驚くほどまともで、特にMNLI、QQP、QNLI、SST-2の大きなデータセットでは、下流の微調整により完全なBERTモデルと詰め込まれた変種の間に残る差異を滑らかにすることができます。 さらに、限られた予算での素朴なBERT訓練と、(Izsak et al., 2021)に記載されたレシピの両方に対する実質的な利得を見出すことができます。 Izsakら、2021）については、記述されたレシピはもともとフル8 GPUサーバーブレードのために設計され、この実験ではより小さなGPUにそこにBERT-大規模モデルを絞ることは、私たちのシナリオでこのレシピの性能劣化の大部分に責任があります。 全体として、詰め込まれたモデルは、小さいデータセットであっても、ほとんど機能します。 しかし、平均値はCoLA（Corpus of linguistic acceptability）（Warstadtら、2019）で大幅に低下しています。 この挙動は興味深く、我々は2つの仮説を提示する。 まず、微調整のために選択されたグローバルハイパーパラメータが、特にCoLAに適合していないことが考えられる。 CoLaの性能はハイパーパラメータに関して脆い可能性があり、Jiao et al. (2020)はCoLaのみで長くトレーニングしたり、Joshi et al. (2020)はCoLaのみで長く訓練したり、Joshiら(2020)はCoLaのみで少なく訓練したりしています。 それにもかかわらず、BERTについては、グローバルなハイパーパラメータのセットが存在し、詰め込み型モデルの欠陥を指摘している。 第二の仮説として、これらのモデルは、CoLAでうまくやるために十分なデータを記憶する前に、より多くのテキストを処理する必要があることが考えられる。 これは、Liu et al. (2021d)は、中間BERTチェックポイントをプローブする際に、CoLAが他の下流タスクと比較して比較的早く学習されることを発見しています。 一方、特にCoLAに関する欠陥は、BERTをより小さなアーキテクチャに蒸留するアプローチ（Sun et al., 2019; Turc et al., 2019; Mukherjee et al., 2021）にも共通し、これは言語的受容性のための限られた能力を伴う可能性がある。

5.1 アブレーション - どの変化が本当に重要なのか？

表5では、この研究で議論されたすべての変更のアブレーション研究の要約を示す。 前のセクションと同様に、変更をアーキテクチャ、トレーニング、およびデータの 3 グループに分類し、 すべての変更を元の BERT レシピにリセットすることによって、各グループを削除しています。 ここで、PreNormレイヤー構造などのアーキテクチャの変更は、トレーニングセットアップで説明したより積極的な学習率スケジュールを可能にするため、いずれの場合もまず最小限の変更を行う必要があることがわかります。 このことを考慮すると、アーキテクチャの変更により平均GLUEスコアが約2ポイント、データの変更により約1ポイント、トレーニングの変更により約半分のポイントが得られることがわかります。

5.2 トレーニングが長くなるとどうなるか？

また、これまで述べてきた詰め込み式のレシピをより多くの予算で使用した場合にどうなるかを検証する。 このため、A6000 GPU8台で48時間モデルを学習させたところ、合計208エクサFLOP（c.f.）となった。 表1. これまでの設定をそのまま適用し、48時間という新たな予算をカバーするために、学習率スケジュールを単純にスケーリングしています。 表6で、我々は、議論されたレシピがより大きな計算バジェットに直ちに一般化されることがわかります。 これは、少なくとも、今、（セクション4.4でソートされた）データセットが小さすぎて、何度も繰り返されていることから、驚くべきことです。 新たに学習されたモデルは、特にMNLIとSST-2で強力な性能を持ち、元のBERTチェックポイントを大幅に上回り、LiuらのroBERTA-baseチェックポイントと同様の範囲に収まります（Liu et al. (2019)のroBERTA-baseチェックポイントと同様の範囲に入るが、これはより多くの計算量で学習されたものである。 しかし、（再び）CoLAなどの他のタスクでは、新しいモデルは、より大きな計算領域でもほとんど改善しません。

6 LIMITATIONS

この研究では、MLM目標で学習された変換器ベースのアーキテクチャに調査を限定しました。 しかしながら、セクション2で提起された詰め込みの一般的なタスクは、これらの制約を緩和した場合でも興味深いものであると考える。 特に目的語に対しては多くの修正が提案されている（Joshi et al., 2020; Bao et al., 2020; Bajaj et al., 2022; Tay et al., 2022b）。 一方、Artetxe et al. (2022)とWang et al. (2022)は、MLMが事前学習目的としてはまだよく持ちこたえることを発見したが、ELECTRA (Clark et al., 2019; 2020; He et al., 2021) などの他の提案は、詰め込みモデルにとって有益であるかもしれない採用することができる。 また、最適なアーキテクチャはトランスフォーマーベースではないかもしれない(Merity, 2019; Fusco et al., 2022; Peng, 2021)。

7 結論

我々は、トランスフォーマーベースの言語モデルが、非常に限られた計算量の設定に詰め込まれた場合に、どの程度の性能を達成できるかを議論し、いくつかの修正により、GLUE上で適切な下流性能につながることを発見しました。 しかし、Kaplanら(2020)の多くの示唆を経験的に見いだし、言語モデルを詰め込むことは難しいようです。 (2020)の多くの示唆がこの領域でも保持され、より大きなモデルによる改善は、その遅い速度によって相殺される例もあります。 我々は、この研究が、セクション2で定式化した詰め込み問題の探求のためのベースラインを提供し、近年トランスフォーマーアーキテクチャに提案された多くの改善とトリックにさらなる光を当てることができればと願っている。