計算量最適化された大規模言語モデルの学習（Chinchillaスケーリング則）

企業において自社の大規模言語モデルを事前学習する企画会議を想定してみます。経営陣から「次世代モデルのために確保したクラウドGPUの計算予算を前回の2倍に増額する」と通達されたとします。このとき、技術チームの前には重大な設計の分岐路が現れます。追加された計算予算の多くをモデルのパラメータ規模の拡大に投じ、前回の2倍や3倍の巨大なモデルを作るべきでしょうか。それとも、モデルの拡大は適度にとどめ、その分だけより多くの文章データ（トークン）を収集して長時間学習させるべきでしょうか。事前学習の計算量は、大まかにはモデル規模と読み込ませるトークン数の積で決まります。固定予算のもとで最高の性能を得るには両者のバランスをどう取るべきか、現場のエンジニアにとって明確な判断基準が求められていました。

2020年前後のAI研究では、モデルを巨大化させることが性能向上への最善策と信じられていました。その根拠とされたのが、OpenAIのKaplanらによる2020年のスケーリング則です。Kaplanらは、計算予算が増加した際にはデータ量よりもパラメータ数を優先して増やすべきだと報告しました。具体的には、計算量の増加に対してパラメータ数を約0.73乗のペースで急速に増やす一方、トークン数は約0.27乗という緩やかなペースで増やす配分を提示したのです。この指針に従い、175BのGPT-3、178BのJurassic-1、280BのGopher、さらには530BのMegatron-Turing NLGといった巨大モデルが開発されました。しかし、これらはいずれも3000億トークン前後の比較的一定したデータ量で学習されており、モデルの体躯に比べて読書量が著しく不足しているのではないかという疑念が生じました。

DeepMindのリサーチサイエンティストであるJordan HoffmannやリサーチエンジニアのSebastian Borgeaudらは、既存の大規模言語モデルが能力に対して著しく学習不足（アンダートレインド）な状態にあると考えました。先行研究の実験を精査した著者らは、学習率を徐々に下げるコサイン学習率スケジュールの設定に着目します。先行研究では、学習の途中で評価を行う際、スケジュールの終点と実際の学習ステップ数が厳密に一致していませんでした。学習率が十分に下がりきる前の途中で損失を測定すると、長時間かけて多くのデータを学習させた際の効果が実際よりも小さく見えてしまいます。物理学出身でスケーリングダイナミクスを研究するHoffmannらは、この実験設定の不整合が「データを増やしても効果が薄い」という誤った見立てを生み、業界全体をパラメータ偏重へ誘導していた可能性を指摘しました。

Hoffmannらが示した中心的なブレークスルーは、計算最適な学習を行うにはモデルのパラメータ数と学習トークン数をほぼ等しい比率で拡大すべきである、という結論です。すなわち、モデル規模を2倍にするのであれば、学習トークン数も2倍に増やす必要があります。事前学習の総計算量はパラメータ数とトークン数の積におおむね比例するため、計算予算が4倍に増えた際にはパラメータ数を2倍、トークン数も2倍というように、双方を等しい比率で引き上げる配分が最も効率的であると示されました。企画会議の例に戻れば、予算が倍増した際にパラメータ数だけを一方的に巨大化させるのではなく、モデル規模の拡大とデータ量の追加を歩調を合わせて進めるべきだという方針転換を意味します。ここで注意すべきは、パラメータ数とトークン数の絶対値を数値として一致させるという意味ではない点です。単位も桁数も異なる二つの要素について、計算予算の増加に対する「拡大ペース（比率）」を等しくそろえるべきだという主張です。

この結論を導くため、著者らは予測のずれを示す損失を三つの要素の和として定式化しました。第一は、どれほど巨大なモデルに膨大なデータを読ませても言語本来の曖昧さによって残る固有の誤差（不可約な損失）です。第二は、パラメータ数が有限であることによる表現能力の不足分です。第三は、学習させたトークン数が有限であることによる知識や文脈の不足分です。パラメータ数だけを増やせば第二の不足は減りますが、第三のデータ不足が放置されれば全体の損失は下がりきりません。逆にデータだけを増やしてもモデル容量が足りなければ頭打ちになります。著者らのアプローチは、総計算予算という制約の中で二つの不足項が減少する速度を測定し、両者が最もバランスよく釣り合う配分点を導き出すものでした。

著者らはパラメータ数が異なる400以上の言語モデルを学習させ、得られた損失の推移を三つの手法で多角的に分析しました。第一は、各実験の学習ステップ数にコサインスケジュールの終点を厳密に一致させ、達成される最小損失の包絡線を追跡する方法です。ここではパラメータ数とトークン数の最適な増加指数がともに約0.50と推定されました。第二は、同一の計算量を使う複数のモデルを並べて損失が最小となる点を求めるIsoFLOP解析です。この極小点の軌跡から、パラメータ数は約0.49乗、トークン数は約0.51乗で増やすべきだと推計されました。第三は、実験データ全体へ先の損失モデルを当てはめる手法で、パラメータ減少指数が約0.34、トークン減少指数が約0.28となり、最適な増加ペースはパラメータ数が約0.45乗、トークン数が約0.55乗と算出されました。三つの分析はいずれも、先行則の偏りとは異なり、パラメータとトークンをほぼ均等な割合で増やすべきだという結論で一致しました。

導き出された配分則の妥当性を現実の大規模環境で検証するため、著者らは新たな言語モデル「Chinchilla」を構築しました。比較対象には、DeepMindが以前に開発した主力モデル「Gopher」が選ばれました。Gopherは280Bパラメータを持ち、約300Bトークンで学習されていました。これに対しChinchillaは、パラメータ数を4分の1の70Bに絞り込む一方、Borgeaudらが構築した分散学習基盤を活用して学習トークン数を4倍超の1.4兆トークンへと大幅に増やしました。両者の事前学習に投入された計算予算は、約5.76掛ける10の23乗FLOPsという同等の水準に厳密に統制されています。Chinchillaは、先行モデルと同じ計算予算を使いながら、配分先を「モデルの大きさ」から「読書量の充実」へと組み替えた対照実験でした。

著者らはMMLU、BIG-bench、MATH、GSM8Kなど、学術界で標準的なベンチマークを用いてChinchillaを評価しました。総合的な理解力を問うMMLUにおいて、Chinchillaは67.5%のスコアを記録し、同一計算量で学習されたGopherの60.0%を上回りました。この67.5%と60.0%の差は「7.5パーセントポイントの差」であり、相対的に7.5%向上したという意味ではありません。さらにChinchillaは、Gopherだけでなく、175BのGPT-3、178BのJurassic-1、そして当時の最大級モデルであった530BのMegatron-Turing NLGに対しても、幅広い下流評価タスクにおいて一貫して優れた成績を収めたと著者らは報告しました。

この実験が証明したのは、同一の事前学習計算予算のもとでは、パラメータ数を無闇に大きくするよりも、適度な規模のモデルに大量のデータを読ませる方が損失を低く抑えられ、下流タスクの性能も高くなるという事実です。これはパラメータ数の大きさこそが性能の決定打であるという見方を覆す実証的根拠となりました。一方で、この評価が示せなかった範囲も存在します。ChinchillaとGopherの比較では、パラメータ数やトークン数に加え、データ構成や学習条件も同時に異なっています。そのため、下流タスクで見られた性能差の全量を配分比率の変更のみに帰属させる単一要因の除去実験ではありません。また、これらの結果はすべて原著論文内の著者報告に基づくものであり、独立した第三者による同一条件での追試結果ではない点にも留意が必要です。

本研究がもたらした決定的な影響は、「既存の大規模言語モデルは著しくデータ不足（アンダートレインド）である」という認識をAIコミュニティに定着させたことです。それまでの開発現場では、後継モデルを出すたびにパラメータ数をどれほど巨大化させたかが誇示されていました。しかしHoffmannらの指摘以降、モデル規模ばかりを肥大化させる開発は非効率と見なされるようになりました。限られた計算予算を投じるなら、高品質なデータを大量に集め、モデルに十分に読ませることこそが性能を高めるという理解が確立されたのです。これにより、開発の力点は単なるパラメータ拡大から、データセットの規模拡大と効率的な学習基盤の構築へと移行しました。

この開発思想の転換は、その後のオープンウェイトモデルの潮流に直接受け継がれました。Metaの「LLaMA」開発チームは、従来のモデルが著しくデータ不足であったという本研究の指摘を直接の着想源として挙げています。LLaMAは、かつてなら数百B規模のモデルを作っていたような学習予算を、7B、13B、65Bといったコンパクトなモデルに1兆トークン以上の大量データを投入するアプローチへと振り向けました。さらにその後のMistralなどの高効率モデルも、この「コンパクトな骨格に大量のデータを学習させる」という設計方針を踏襲しています。巨大化偏重の時代が終わり、徹底的に学習された小型・中型モデルが実用環境で活躍する現代の動向は、本研究の発見に明確な起源を持っています。

ここで冒頭の企画会議の例に戻り、本研究の結論が現実のビジネス判断と乖離する境界を整理します。論文が最適化したのは、あくまで「事前学習時の計算資源（FLOPs）」の枠内での損失低減にすぎません。しかし実際の製品運用では、モデルはリリース後に何百万回、何千万回もの推論要求を処理します。運用時の推論コストの観点では、モデルのパラメータ規模は必要メモリ量や応答速度、サーバー運用費に直結します。70Bのモデルを運用する費用は、280Bのモデルを運用するより大幅に安価です。そのため、莫大な推論需要が見込まれる商用サービスでは、事前学習の計算最適点を超えてモデルに過剰なトークンを読ませる「オーバートレーニング」を行い、小さく締まったモデルを作る方が、システムの生涯総費用としては合理的になる場合があります。

第二の限界は、本研究がトークン数を単なる数量として扱い、データの「質」や「重複度」を同一の数式の中で定量化していない点です。現実には、粗悪なウェブテキストを大量に読ませるのと、洗練された解説文や論理的なデータを読ませるのとでは、1トークンの持つ学習効果は大きく異なります。データ枯渇時の合成データの活用についても、原著論文の範囲には含まれていません。さらに、本研究の対象は純粋な事前学習に限られます。現代の生成AI製品に欠かせない指示チューニングや強化学習といった事後学習、あるいは推論時に追加の計算資源を消費して思考させる技術が最終的な実用性能にどう作用するかは、このスケーリング則からは判断できません。

現代の読者が本研究から学ぶべき持続的な教訓は、モデルの優劣を判断する際にパラメータ数の大きさという単一の指標に惑わされてはならないという点です。投じた計算予算に対し、モデル規模とデータ量がどのようなバランスで配分されているかという構造に着目する必要があります。一方で、本論文の結論をあらゆる場面に適用できる普遍的な教義として捉えるべきではありません。特定のハードウェア構成や分散学習環境への依存性、極限スケールでのハイパーパラメータ調整の難しさなど、実践的な制約が存在します。読者が次に確認すべき証拠は、データの質を厳密に統制した環境でもこの比率が維持されるのか、そして推論や事後学習までを含めたトータルコストの観点から自社の目的に適した投資配分がなされているかという実証データです。