計算予算に対して、モデルを大きくするより学習を十分に行うべきかを調べた研究

原題: Training Compute-Optimal Large Language Models
Jordan Hoffmann ほか, 2022 — arXiv:2203.15556

要点

3つだけ覚えるなら

1. 計算量が同じでも、配分で結果は変わる。 パラメータ数だけを増やすのではなく、モデルの大きさと学習トークン数をほぼ同じ割合で増やすのがよい、というのが論文の中心結論です（本文 §3.4）。
2. 小さくして、長く学ばせる。 70B パラメータを 1.4T tokens で学習した Chinchilla は、同じ学習計算量で 280B・300B tokens の Gopher を多くの評価で上回りました（本文 §4、Table 1）。
3. ただし「小さければよい」ではない。 結論は固定された学習計算量の中での最適配分です。大規模な直接比較は Chinchilla と Gopher の2本が中心で、データ品質、重複、バイアス、プライバシーも残ります（本文 §5、Appendix I）。

図1 — 同じ学習計算量でも、Gopher は 280B parameters / 300B tokens、Chinchilla は 70B parameters / 1.4T tokens。値は Table 1。図は原図の転載ではなく、本稿の説明用に新規作成。

問題

大きさだけを競うと、学習不足になる

大規模言語モデルの学習では、使えるアクセラレータ数と期間、つまり計算予算が先に決まることがよくあります。その予算を「もっと大きいモデル」に使うか、「より多くの文章を読ませる」ことに使うかが本論文の問いです（本文 §1）。当時の GPT-3、Jurassic-1、Gopher、MT-NLG は、モデルサイズが 175B から 530B と違っても、学習量はおおむね 270B〜300B tokens に集中していました（Table 1）。著者らは、ここに学習不足があると考えました。

前の常識との違い

先行研究 Kaplan et al. (2020) は、計算予算が増えたとき、データ量よりモデルサイズを速く増やす配分を推定していました。本論文は、学習率スケジュールを実際の学習トークン数に合わせ、より大きなモデルまで調べ直すと、モデルとデータはほぼ同率で増やす方がよいと報告します（本文 §2、§3.4）。ここでいう「計算最適」は、同じ FLOPs で学習損失をできるだけ低くする配分という意味です。モデル一般の絶対的な優劣ではありません。

方法

400超の学習実験から配分を推定

著者らは、70M から 16B 超のパラメータ、5B から 500B tokens の範囲で 400 を超えるモデルを学習しました（Abstract、本文 §1）。入力はモデルのパラメータ数、学習トークン数、計算量。出力は学習損失です。固定 FLOPs の下で損失が最小になるパラメータ数とトークン数を探します。

3通りの見方で同じ方向を確認

• 学習曲線の下端を拾う: モデルサイズごとに学習期間を変え、各計算量で最も損失が低い点を選ぶ（Approach 1、§3.1）。
• 同じ FLOPs で谷底を探す: 9段階の計算予算ごとにモデルサイズを変え、最終損失が最小になる点を求める（Approach 2、§3.2）。
• 損失関数を当てはめる: モデルの有限サイズによる損失と、学習不足による損失を含む関数を全実験にフィットする（Approach 3、§3.3）。

3手法は細部の推定値こそ違いますが、計算量が増えるときにモデルサイズと学習トークン数をほぼ同率で増やす、という方向で一致しました（Table 2）。

図2 — 3つの推定ルートの役割。数値グラフではなく、§3.1〜§3.4 の分析構造を示す説明図。

Chinchillaで大規模に確かめる

推定を実物で検証するため、著者らは Gopher と同じ学習 FLOPs で Chinchilla を学習しました。Chinchilla は 70B parameters / 1.4T tokens、Gopher は 280B / 300B tokens です。ただし完全な一変数比較ではなく、Chinchilla は AdamW、少し異なるデータ配分、修正版 tokenizer も使っています（本文 §4.1、Appendix G）。

証拠と限界

いちばん強い結果

同じ学習計算量で、Chinchilla は MMLU 57課題の 5-shot 平均が 67.6%、Gopher は 60.0% でした。個別では 51/57 課題で上、2課題で同じ、4課題で下です（Table 6、Figure 6）。BIG-bench 62課題の平均も 65.1% 対 54.4% で、Chinchilla が 10.7ポイント高く、58/62 課題で上回りました（本文 §4.2.4）。「小さいモデルを長く学習させる」という配分が、学習損失だけでなく下流評価にもつながったことが、この論文の強い証拠です。

出典: Table 1、Table 6、本文 §4.2.4。B = billion、T = trillion。

どこまで信じてよいか

• 大規模検証が少ない: 費用のため、大規模で対応する学習は Chinchilla と Gopher の2本だけで、中間規模の追加検証もありません。Chinchilla の再学習も行われていません（本文 §5、Appendix I）。
• 外挿の仮定がある: 計算量・モデルサイズ・トークン数の関係をべき乗則で表しますが、高計算量側には曲がりが観測されています。著者ら自身、最適モデルサイズをまだ大きく見積もっている可能性を述べています（本文 §5、Appendix E）。
• データ漏洩の可能性: Chinchilla は4倍超のデータを見るため、言語モデリング評価では train/test 重複が結果を押し上げる恐れがあります（本文 §4.2.1）。
• 安全性は自動改善しない: 評価は包括的ではなく、性別による性能差、毒性、Web データ中の個人情報が残ります。英語中心の研究用モデルで、下流利用には追加の安全・公平性対策が必要です（本文 §4.2.7、Appendix I）。
• データを増やせるとは限らない: 1.4T-token 学習では Wikipedia を 3.40 epochs、MassiveWeb を 1.24 epochs 使用しています（Table A1）。さらに大きな高品質コーパスを重複なく確保できるかは、別の実務課題です。

実務的な意味

設計会議で変えるべき問い

「最大で何Bのモデルを作れるか」から始めるのではなく、固定予算で、モデル容量と十分な学習データをどう組み合わせれば損失が最小になるか を先に推定する、というのが実務への読み替えです。小さいモデルで同等以上の性能が出れば、学習後の推論メモリと計算も軽くなります。これは論文が述べる帰結ですが、実際の費用はハードウェア、並列化、コンテキスト長、配信量にも左右されます。

図3 — 実務での意思決定への読み替え。上段は本文 §1・§4 の帰結、下段の注意点は本文 §5 と Appendix I に基づく。

この論文が言っていないこと

この結果は「どんな状況でもモデルを小さくせよ」「データを増やせば安全になる」「現在の全アーキテクチャでも比率が同じ」とは示していません。対象は主に autoregressive dense Transformer の事前学習です。別のアーキテクチャ、別言語、複数 epoch、データが枯渇する領域では、同じ3手法で配分を測り直す必要があります。

検証するときの質問

1. 自分たちのモデル群でも、複数の固定 FLOPs に明確な損失の谷が見えるか。
2. 学習率スケジュールを各トークン数に合わせても結論が残るか。
3. 重複除去後の下流評価でも改善が残るか。
4. 学習費だけでなく、想定利用量での推論費まで含めると最適点はどこか。
5. 追加データの品質、同意、個人情報、言語・集団ごとの偏りを監査できるか。

出典と用語

• 主資料: Hoffmann et al., Training Compute-Optimal Large Language Models, arXiv:2203.15556, 2022（要旨ページ / 本文HTML）。
• parameter / パラメータ: モデルが学習する数値。一般に多いほど容量と推論負荷が増える。
• token / トークン: 学習で数える文章の断片。ここでの「長く学習」は、より多くの token を見ること。
• FLOPs: 浮動小数点演算回数。本論文では学習計算量の物差し。
• compute-optimal / 計算最適: 固定 FLOPs の下で、学習損失を最小にするモデルサイズとトークン数の組み合わせ。
• 数値表記は本文版に合わせた。要旨には MMLU 67.5% とある一方、Table 6 と本文 §4.2.2 は 67.6% のため、本稿では詳細表の 67.6% を採用した。