※本記事は、Stanford UniversityのCS229: Machine Learning コースで2024年夏に行われた、Yann Dubois氏による特別講義の内容を基に作成されています。講演者のYann Dubois氏はStanford大学4年のCS博士課程の学生で、Percy Liang氏とTatsu Hashimoto氏の指導を受けています。彼の研究は、リソースが限られている場合のAIの効果を改善することに焦点を当てています。最近では、Alpacaチームの一員として、他のLLMを使用して言語モデルをより効率的にトレーニングおよび評価する研究に取り組んでいます。 この講義の詳細情報はhttps://stanford.io/ai でご覧いただけます。 本記事では、講義の内容を要約しており、原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの講義をご視聴いただくことをお勧めいたします。また、Stanfordが提供するオンラインコースやプログラムの詳細については、http://online.stanford.edu をご覧ください。
1. はじめに
1.1 LLMsの定義と概要
本日は大規模言語モデル（Large Language Models, LLMs）について話します。LLMsは、最近話題になっているチャットボットの基盤となる技術です。具体的には、OpenAIのChatGPT、AnthropicのClaude、GoogleのGeminiなどが代表的な例として挙げられます。今日の講義では、これらのLLMsがどのように機能するのか、その概要を説明します。1回の講義ですべてを網羅することは難しいですが、LLMsのトレーニングに必要な主要コンポーネントすべてに触れるよう努めます。
1.2 LLM開発の主要コンポーネント
LLMsのトレーニングには、いくつかの重要なコンポーネントがあります。
- アーキテクチャ：LLMsはニューラルネットワークであり、どのような構造を使用するかを考える必要があります。
- トレーニングロスとトレーニングアルゴリズム：これらのモデルを実際にどのようにトレーニングするかという点です。
- データ：これらのモデルをどのようなデータでトレーニングするのかという問題です。
- 評価：モデルの進捗をどのように測定し、LLMsの目標に向かって実際に進歩しているかを確認する方法です。
- システムコンポーネント：これらの非常に大規模なモデルを現代のハードウェアで実際に動作させる方法です。LLMsが非常に大きくなった現在、システムの側面が特に重要になっています。
これら5つのコンポーネントについて、今日の講義で詳しく説明していきます。
皆さんもご存じかもしれませんが、LLMsはすべてTransformerもしくはTransformerの変種をベースにしています。しかし、今日の講義ではTransformerのアーキテクチャについては詳しく説明しません。その理由は2つあります。1つは、数週間前にTransformerに関する講義を行ったことです。もう1つは、Transformerに関する情報はオンラインで豊富に見つけることができるからです。他の4つのトピックについては、あまり情報が出回っていないので、それらに焦点を当てたいと思います。
ここで注意しておきたいのは、アカデミアの多くが主にアーキテクチャとトレーニングアルゴリズム、損失関数に焦点を当てているということです。私も長年の研究者として、新しいアーキテクチャや新しいモデルを作ることが非常に重要だと考えてきました。しかし、実際には、実践で最も重要なのは、他の3つのトピック、つまりデータ、評価、システムです。これらは産業界が主に焦点を当てている分野です。
このような理由から、アーキテクチャについてあまり詳しく説明しないことにしました。残りの要素が実際には非常に重要だからです。
講義の概要として、プレトレーニングとポストトレーニングという2つの主要なパラダイムについて説明します。プレトレーニングは、一般的な言語モデリングパラダイムで、基本的にインターネット全体をモデル化するようにトレーニングします。ポストトレーニングは、より最近のパラダイムで、これらの大規模言語モデルを本質的にAIアシスタントにするプロセスです。
GPT-3やGPT-2を聞いたことがある人もいるでしょう。これらは主にプレトレーニングの領域に属します。一方、ChatGPTについては皆さんも聞いたことがあると思います。これはポストトレーニングの領域です。今日の講義では両方について説明しますが、まずはプレトレーニングから始めます。
2. LLMの構築における重要要素
LLMの構築には、複数の重要な要素が関わっています。ここでは、アーキテクチャ、トレーニングロスとアルゴリズム、データ、評価、システム要件の5つの主要な要素について説明します。
2.1 アーキテクチャ
LLMのアーキテクチャについて、皆さんもご存じの通り、現在のLLMはほぼすべてTransformerアーキテクチャまたはその変種をベースにしています。しかし、今回の講義ではTransformerの詳細には立ち入りません。その理由は2つあります。1つは、数週間前にTransformerに関する講義を行ったばかりだからです。もう1つは、Transformerに関する情報はオンラインで豊富に見つけることができるからです。他の4つのトピックについては、あまり情報が出回っていないので、それらに焦点を当てたいと思います。
2.2 トレーニングロスとアルゴリズム
トレーニングロスとアルゴリズムは、LLMの学習プロセスを決定する重要な要素です。これらは、モデルをどのように実際にトレーニングするかを定義します。LLMの場合、一般的に言語モデリングタスクに基づいたロス関数を使用します。具体的には、次のトークンを予測する際の負の対数尤度を最小化することが目標となります。
トレーニングアルゴリズムは、大規模な分散トレーニングが必要となるため、効率的な最適化手法が重要です。ただし、この講義ではトレーニングアルゴリズムの詳細には深入りしません。なぜなら、産業界では他の要素がより重要視されているからです。
2.3 データ
データは、LLM構築において最も重要な要素の一つです。多くの人が「LLMはインターネット全体でトレーニングされている」と言いますが、実際にはそれほど単純ではありません。「クリーンなインターネット」という言葉もよく聞きますが、これも明確に定義されているわけではありません。
実際のインターネットは非常に「汚い」データで溢れており、私たちが望むような代表的なデータセットとは程遠いものです。ランダムにウェブサイトをダウンロードしてみると、その内容の低質さに驚くことでしょう。それはWikipediaのような整理された情報源とは全く異なります。
データの収集と前処理には膨大な労力が必要です。ウェブクローラーを使用してインターネット全体からデータを収集し、そのデータをクリーニング、フィルタリング、重複除去などの処理を行います。さらに、不適切なコンテンツの除去、高品質なデータの選別、ドメインバランスの調整なども必要です。これらのプロセスは、LLMの性能に直接影響を与える重要な要素です。
データの重要性は、産業界で特に注目されている分野の一つです。後ほど、データ収集と前処理のプロセスについて詳しく説明します。
2.4 評価
評価は、モデルの進捗を測定し、LLMsの目標に向かって実際に進歩しているかを確認する方法です。LLMの評価には複数の側面があります。
まず、言語モデリングタスクに関する基本的な評価指標として、perplexityがあります。これは、モデルが次のトークンをどれだけ正確に予測できるかを測定します。
しかし、perplexityだけでは、モデルの実際の能力を完全に把握することはできません。そのため、質問応答、要約、翻訳など、様々なダウンストリームタスクでの性能も評価します。HELMやHuggingFace Open LLM Leaderboardなどのベンチマークは、これらの多様なタスクでのモデルの性能を総合的に評価するために使用されます。
さらに、ChatGPTのような対話型AIの場合、人間の評価者による主観的な評価も重要になります。これには、応答の質、一貫性、有用性などが含まれます。
評価は、モデルの改善方向を決定する上で極めて重要です。産業界では、この評価プロセスに多くのリソースが投入されています。後のセクションで、評価手法についてより詳しく説明します。
2.5 システム要件
システム要件は、これらの非常に大規模なモデルを現代のハードウェアで実際に動作させる方法に関するものです。LLMsが非常に大きくなった現在、システムの側面が特に重要になっています。
ここで注意しておきたいのは、アカデミアの多くが主にアーキテクチャとトレーニングアルゴリズム、損失関数に焦点を当てているということです。私も長年の研究者として、新しいアーキテクチャや新しいモデルを作ることが非常に重要だと考えてきました。しかし、実際には、実践で最も重要なのは、他の3つのトピック、つまりデータ、評価、システムです。これらは産業界が主に焦点を当てている分野です。
このような理由から、アーキテクチャについてあまり詳しく説明しないことにしました。残りの要素が実際には非常に重要だからです。
以上が、LLMの構築における5つの重要な要素の概要です。これらの要素は相互に関連しており、バランスよく考慮することが、高性能なLLMの開発には不可欠です。次のセクションでは、これらの要素のうち、特にデータ、評価、システムに焦点を当てて、より詳細に説明していきます。
3. プレトレーニング
3.1 言語モデリングの基本概念
言語モデリングは、LLMの基盤となる重要な概念です。高いレベルで言えば、言語モデルはトークンまたは単語のシーケンスに対する確率分布のモデルです。具体的には、P(X1からXL)という形式で表現されます。ここでX1は最初の単語、XLは文章の最後の単語を表します。
この概念をより具体的に説明するために、例を挙げてみましょう。「The mouse ate the cheese」という文があるとします。言語モデルの役割は、この文が人間によって発言される、あるいはオンラインで見つかる確率を提供することです。
次に、「The the mouse at cheese」という文を考えてみましょう。この文には文法的な誤りがあります。モデルは文法的な知識を持っているはずなので、この文がオンラインで見つかる可能性は低いと判断するはずです。
さらに、「The cheese ate the mouse」という文を考えてみましょう。この文は文法的には正しいですが、意味的におかしいです。モデルは通常チーズがネズミを食べないという事実を知っているはずなので、この文が出現する確率は最初の文よりもさらに低いと判断するはずです。
3.2 自己回帰型言語モデル
現在、最も一般的に使用されている言語モデルの種類は、自己回帰型言語モデルです。自己回帰型言語モデルの鍵となるアイデアは、単語の分布を個々の条件付き確率の積に分解することです。
具体的には、P(X1からXL) = P(X1) * P(X2|X1) * P(X3|X1,X2) * ... * P(XL|X1,...,XL-1)という形で表現されます。これは確率の連鎖則を適用しただけで、何も近似していません。単に分布をモデル化する一つの方法です。
より簡潔に書くと、Π(i=1からL)P(Xi|X<i)となります。これは、「過去のコンテキスト全体が与えられた次の単語の確率の積」を表しています。
自己回帰型言語モデルの具体的なタスクは、次の単語を予測することです。例えば、「She likely prefers」という文があった場合、次の単語として「dogs」が来る可能性があります。
このプロセスは以下のように進行します：
- まず、単語またはサブワードをトークン化します。
- 各トークンにIDを割り当てます（例：1, 2, 3...）。
- これらのトークンをモデル（ブラックボックス）に通します。
- モデルは次のトークンに対する確率分布を出力します。
- この分布からサンプリングして新しいトークンを得ます。
- 最後に、このトークンをデトークン化して単語に戻します。
ここで重要なのは、最後の2ステップ（サンプリングとデトークン化）は推論時にのみ必要だということです。トレーニング時には、最も可能性の高いトークンを予測し、実際に発生したトークンと比較するだけです。そして、その正しいトークンを生成する確率を高めるようにモデルの重みを調整します。
3.3 トークン化の重要性
3.3.1 Byte Pair Encoding (BPE)の詳細
トークン化は、LLMの性能に大きな影響を与える重要な要素です。通常、人々はトークン化についてあまり深く考えませんが、実際には非常に重要です。
まず、なぜ単純に単語ごとにトークン化しないのでしょうか？一つの理由は、単語よりも一般的なアプローチが必要だからです。例えば、単語にタイプミスがある場合、その単語に対応するトークンがない可能性があります。そうなると、タイプミスのある単語をLLMに入力する方法がわからなくなってしまいます。
また、単語という概念は言語によって異なります。例えば、タイ語のような言語では、単語間にスペースがないため、スペースで区切るという単純な方法でトークン化することができません。
次に考えられるのは、文字ごとにトークン化する方法です。つまり、aは1つのトークン、bは別のトークンというようにです。これは実際にうまく機能する可能性がありますが、問題は、シーケンスが非常に長くなってしまうことです。Transformerの講義で説明したように、シーケンスの長さが長くなると計算量が二次関数的に増加してしまいます。そのため、非常に長いシーケンスは避けたいのです。
トークナイザーは、これら2つの問題に対処し、一般的な部分文字列に特定のトークンを割り当てようとします。通常、平均して各トークンは3〜4文字程度になるように設計されています。
トークン化にはさまざまなアルゴリズムがありますが、ここでは最も一般的な2つのうちの1つであるByte Pair Encoding（BPE）について説明します。BPEのトレーニング方法は以下の通りです：
- まず、非常に大きなテキストコーパスから始めます。ここでは、LLMのトレーニングについてはまだ話していません。これは純粋にトークン化のためのステップです。
- このコーパス内の各文字に異なるトークンを割り当てます。
- テキストを通して、非常に頻繁に一緒に出現するトークンのペアを探します。最も頻繁に出現するペアをマージして新しいトークンを作ります。
- このプロセスを繰り返します。
例えば、「tokenizer token tokenization」というテキストがあるとします。まず、各文字を別々のトークンとして扱います。次に、最も頻繁に出現するペアを見つけます。この場合、「to」が3回出現しているので、これを新しいトークンとしてマージします。
このプロセスを続けると、「token」が1つのトークンになり、「izer」が別のトークンになる可能性があります。実際のトークナイザーでは、はるかに大きなコーパスでこのプロセスを行います。
3.3.2 トークン化の実例と課題
実際のトークナイザーがどのように単語を分割するかを見てみましょう。例えば、「tokenizer」という単語は、実際には「token」と「izer」の2つのトークンに分割されます。
トークン化にはいくつかの課題があります。例えば、スペースや句読点をどう扱うかという問題があります。理論的には、スペースや句読点を特別に扱う理由はなく、それぞれに独自のトークンを割り当て、他の文字と同様にマージプロセスを行うことができます。
しかし、実際にはトークナイザーのトレーニングに時間がかかるため、効率性の問題があります。すべてのトークンペアを考慮する必要があるからです。そのため、多くの場合、事前トークン化（pre-tokenization）と呼ばれるステップを行います。これは非常に英語に特化したアプローチで、スペースがある場合、そのスペースの前後のトークンを別々に扱い、スペースをまたいでマージしないようにします。これは単なる計算上の最適化であり、理論的にはスペースも他の文字と同じように扱うことができます。
トークン化は、LLMの性能に大きな影響を与える重要な要素ですが、同時に多くの計算上の利点や課題も持っています。将来的には、シーケンスの長さに対して二次関数的にスケールしない新しいアーキテクチャが開発され、文字単位やバイト単位のトークン化に移行する可能性もあります。しかし、現時点では、BPEなどの中間的なアプローチが広く使用されています。
3.4 評価指標：Perplexity
LLMの評価において、最も一般的に使用される指標の一つがPerplexityです。Perplexityは基本的に、モデルの検証損失を表現する方法です。しかし、通常の検証損失とは少し異なる点があります。
Perplexityの計算方法は、トークンあたりの平均損失を使用し、それを指数化します。具体的には、Perplexityは2の平均損失乗として計算されます。この方法を採用する理由は、人間が対数空間での思考が苦手であることと、結果をより解釈しやすい形に変換できるからです。
Perplexityの値は、トークナイザーの語彙サイズの1から語彙サイズまでの範囲に収まります。1は完璧な予測を意味し、語彙サイズと同じ値は完全にランダムな予測を意味します。
Perplexityの直感的な解釈としては、モデルが各トークンを生成する際に「躊躇している」トークンの数を表していると考えることができます。例えば、モデルが完璧であれば、躊躇することなく正確なトークンを選択するので、Perplexityは1になります。逆に、モデルが全く予測できない場合、語彙サイズ分の選択肢の中から完全にランダムに選んでいることになるので、Perplexityは語彙サイズと同じ値になります。
実際のモデルの進歩を示す例として、標準的なデータセットにおけるPerplexityの改善を見てみましょう。2017年から2023年の間に、Perplexityは約70から10未満に改善されました。これは、以前のモデルが各単語を生成する際に70個の単語の中から選択していたのに対し、現在のモデルは10個未満の単語の中から選択していることを意味します。これは大きな進歩を示しています。
しかし、Perplexityには限界があります。現在、学術的なベンチマークではあまり使用されなくなっています。その主な理由は、Perplexityが使用するトークナイザーや評価対象のデータに依存するためです。つまり、異なるモデル間で直接比較することが難しいのです。
それでも、Perplexityは依然としてLLMの開発プロセスにおいては重要な指標です。モデルの改善を追跡する内部的な指標として、多くの開発者がPerplexityを使用しています。
3.5 ベンチマーク：HELM、HuggingFace Open LLM Leaderboardなど
Perplexityの限界を補完するため、現在のLLMの評価では、より包括的なアプローチが採用されています。一般的な方法は、従来のNLPベンチマークを集めて、それらすべてにわたってモデルを評価することです。
具体的には、可能な限り多くの自動評価可能なベンチマークを収集し、それらすべてにわたってモデルを評価します。このアプローチを採用している代表的なベンチマークとして、スタンフォード大学が開発したHELMと、Hugging Faceが提供するOpen LLM Leaderboardがあります。これらは現在、最も一般的に使用されているベンチマークの2つです。
HELMを例に取ると、このベンチマークには様々なタイプのタスクが含まれています。その多くは、質問応答のような簡単に評価可能なタスクです。質問応答タスクの利点は、通常、正解が明確に定義されているため、モデルの出力を客観的に評価できることです。
評価の方法としては、言語モデルが正解を生成する確率を、他の答えを生成する確率と比較します。これが、基本的にこれらのモデルを評価する方法です。
より具体的な例として、MLUというベンチマークについて説明します。MLUは現在、LLMの学術的ベンチマークとして最も一般的に使用されているものの一つです。これは、大学医学、大学物理学、天文学など、様々な分野における多数の質問と回答のコレクションです。
例えば、天文学の分野で「Type Ia supernovaについて正しいのは何ですか？」という質問があり、4つの選択肢が提示されるとします。モデルの評価方法には主に2つのアプローチがあります：
1つ目は、モデルにこれらの回答を生成させ、各回答の生成確率を比較する方法です。
2つ目は、モデルに「A、B、C、Dのうち、どれが最も可能性が高いですか？」と直接質問し、モデルが最も可能性が高いと判断した選択肢を見る方法です。
後者の場合、モデルにABCDのどれが最も可能性が高いかを尋ね、次のトークンとしてA、B、C、Dのどれが最も可能性が高いかを見ます。つまり、モデルにはこの4つの選択肢しか答えられないように制約をかけ、その中での選択を見ることになります。
いずれの方法でも、正解がわかっているため、モデルの判断が正しいかどうかを客観的に評価することができます。
これらのベンチマークは、LLMの性能を多面的に評価するのに役立ちます。しかし、評価には依然として課題があります。例えば、制約のないテキスト生成タスクの評価は非常に難しいです。モデルが意味的に正しい回答を生成したとしても、それが期待される正確なトークンリストと一致しない場合、どのように評価すべきでしょうか。これは今後の課題の一つです。
4. データ収集と前処理
データは、LLMの構築において最も重要な要素の一つです。多くの人は、LLMがインターネット全体でトレーニングされていると言いますが、実際にはそれほど単純ではありません。「クリーンなインターネット」という言葉もよく聞きますが、これも明確に定義されているわけではありません。実際のインターネットは非常に「汚い」データで溢れており、私たちが望むような代表的なデータセットとは程遠いものです。ランダムにウェブサイトをダウンロードしてみると、その内容の低質さに驚くことでしょう。それはWikipediaのような整理された情報源とは全く異なります。
4.1 インターネットデータのクローリング
まず、インターネット全体をダウンロードすることから始めます。これは、ウェブクローラーを使用してインターネット上のすべてのウェブページ、または少なくともGoogleにインデックスされているすべてのウェブページをクロールすることを意味します。現在、これは約250億ページに相当し、データ量としては約1ペタバイトになります。
Common Crawlは、このようなウェブクローラーの一例です。多くの人々は独自のウェブクローラーを作成しますが、Common Crawlのような標準的なウェブクローラーも使用されます。Common Crawlは毎月、Googleによって発見された新しいウェブサイトを追加し、大規模なデータセットとして提供しています。
現在、Common Crawlには約250億のページが含まれており、これは106ギガバイト（1ペタバイト）のデータに相当します。これがLLMトレーニングの出発点となります。
4.2 データクリーニングのステップ
4.2.1 HTMLからのテキスト抽出
Common Crawlからランダムに取得したウェブページを見てみると、それが通常私たちが見るようなものではないことがわかります。これはHTMLページで、内容を見るのは難しいですが、よく見ると「テスティングワールドは、システムXの高性能サーバーの究極のソースです」といった内容が見つかります。そして、その後には三点リーダーが続いており、文章さえ完結していません。これが、ランダムなインターネットの実態です。
もちろん、このようなデータをそのまま使ってLLMをトレーニングしても、あまり有用ではありません。そのため、最初のステップとしてHTMLからテキストを抽出する必要があります。これは、先ほど私が試みたように、正しいテキスト部分を探し出す作業です。
しかし、このプロセスには多くの課題があります。例えば、数式の抽出は非常に複雑ですが、LLMのトレーニングにとっては重要です。また、多くのフォーラムには同じようなヘッダーやフッターがあり、これらを繰り返しデータセットに含めたくはありません。
4.2.2 不適切なコンテンツのフィルタリング
次のステップは、望ましくないコンテンツをフィルタリングすることです。これには、NSFW（Not Safe For Work）コンテンツ、有害なコンテンツ、個人を特定できる情報（PII）などが含まれます。通常、各企業はトレーニングに使用したくないウェブサイトのブラックリストを持っています。このブラックリストは非常に長く、そこからのデータはトレーニングに使用しません。
この作業を行う他の方法として、PIIを分類し、それを削除する小規模なモデルをトレーニングすることもあります。ここで挙げる各ポイントは、実際には大量の作業を必要とする難しいタスクですが、時間の関係上、簡単に説明していきます。
4.2.3 重複排除
三番目または四番目のステップは、重複排除です。先ほど説明したように、フォーラムにはヘッダーやフッターが常に同じものがあり、これらを削除したいと考えています。また、URLは異なっていても同じウェブサイトを表示しているケースも多くあります。
さらに、一般的な書籍からの段落が、インターネット上で何千回も、あるいは何万回も重複して出現することもあります。これらの重複も削除する必要があります。
重複排除も非常に難しい課題です。なぜなら、これを大規模に行う必要があるからです。
4.2.4 ヒューリスティックフィルタリング
重複排除を行った後、ヒューリスティックフィルタリングを行います。ここでは、低品質の文書を削除しようとします。これには、ルールベースのフィルタリングが使用されます。
例えば、外れ値のトークンがある場合、つまりウェブサイトのトークン分布が通常のトークン分布と大きく異なる場合、それは何か問題がある可能性があります。また、ウェブサイトの単語の長さが非常に長い場合も、何か奇妙なことが起きている可能性があります。
ウェブサイトに3つの単語しかない場合、それをトレーニングに使用する価値があるでしょうか？おそらくないでしょう。逆に、1000万語もある場合、そのページにも何か問題がある可能性があります。
このように、多くのルールを適用してフィルタリングを行います。各ステップは非常に複雑で、多くの作業が必要です。「インターネットでトレーニングする」と簡単に言いますが、実際にはこれらすべての処理が必要なのです。そして、私たちはまだこの問題を完全に解決できていません。
実際、世界中のデータの収集は、LLMの実用的な開発において非常に大きな部分を占めています。一部の人々は、これが実際には最も重要な部分だと言うかもしれません。
4.3 モデルベースのフィルタリング
データの前処理における次のステップは、モデルベースのフィルタリングです。これは非常に興味深い手法で、多くのデータをフィルタリングした後に適用します。この方法の基本的なアイデアは以下の通りです。
まず、Wikipediaのすべての内容を取り、Wikipediaから参照されているすべてのリンクを抽出します。Wikipediaから参照されているウェブサイトは、おそらく高品質なものであるという仮定に基づいています。次に、これらの参照されたウェブサイトからのドキュメントと、ランダムなウェブから取得したドキュメントを区別するための分類器をトレーニングします。
この分類器を使用して、処理中のデータがWikipediaの参照に似ているかどうかを判断し、より類似しているものを優先的に選択します。これは非常に効果的な方法で、データの品質を大幅に向上させることができます。
ただし、この方法を適用する際は、250億ページという膨大なデータ量を考慮する必要があります。そのため、通常は非常にシンプルな機械学習モデルを使用します。複雑なモデルを使用すると、処理に膨大な時間がかかってしまうからです。
4.4 ドメイン分類とデータバランシング
次のステップは、データを異なるドメインに分類することです。ここでいうドメインとは、例えばエンターテイメント、書籍、コード、その他の特定の分野を指します。この分類を行った後、各ドメインの重み付けを調整します。
具体的には、一部のドメインの重みを上げたり下げたりします。例えば、コードに関するデータの重みを上げることがよくあります。なぜなら、コードに関するデータでトレーニングを行うと、モデルの推論能力が向上するという観察結果があるからです。これは一般的な言語モデリングスキルの向上にも貢献します。
書籍も通常、重みを上げるドメインの一つです。一方で、エンターテイメント関連のコンテンツは通常、重みを下げます。
以前は、このプロセスを手動で行っていましたが、現在では自動化されたパイプラインが開発されています。
4.5 高品質データでの微調整
最後に、大規模言語モデルのトレーニングの最終段階で、非常に高品質なデータを用いて微調整を行います。この段階では、学習率を下げてトレーニングを続けます。
これは、基本的にモデルを高品質なデータにオーバーフィッティングさせる過程です。ここで使用されるデータには、通常Wikipediaが含まれます。つまり、最終的にはWikipediaの内容にオーバーフィッティングさせているのです。
また、人間が収集した高品質なデータも使用されます。これらのデータは、モデルの最終的な性能を大きく左右する重要な要素となります。
重要なのは、「インターネットでトレーニングする」と言うとき、それが実際には非常に多くの作業を必要とする複雑なプロセスだということです。そして、我々はまだこのプロセスを完全に解決できていません。
実際、良質なデータの収集は、大規模言語モデルの実用的な開発において非常に大きな部分を占めています。一部の人々は、これが実際には最も重要な部分だと言うかもしれません。
最後に、学術的なベンチマークで使用されるデータセットについて少し触れておきます。これらのデータセットは時間とともに大きくなっています。初期のものは約1500億トークン（約800GB）でしたが、現在では15兆トークンに達しています。これは、現在最高性能のモデルがトレーニングに使用しているデータ量とほぼ同じです。
具体的な例として、「The Pile」という学術的なベンチマークデータセットがあります。これには、PubMed Central（生物学関連の文献）、Wikipedia、Stack Exchange、GitHub、書籍などが含まれています。ただし、これは比較的小さなデータセットで、280Bトークンしかありません。実際には、これの100倍程度の大きさのデータセットが使用されています。
商用モデルについては、例えばLlama 2は22兆トークン、Llama 3は15兆トークンでトレーニングされました。GPT-4については正確な情報はありませんが、リークされた情報が正しければ、おそらく13兆トークン程度だと推測されます。
このように、データ収集と前処理は、LLMの開発において非常に重要かつ複雑なプロセスです。単に「インターネットでトレーニング」するだけでなく、膨大な量のデータを適切に処理し、高品質なデータセットを作成することが、モデルの性能向上に大きく寄与しているのです。
5. スケーリング法則
スケーリング法則は、LLMの開発において非常に重要な概念です。2020年頃から、あるいはそれ以前からも理論的・実証的に示されてきましたが、基本的には「より多くのデータでモデルをトレーニングし、モデルのサイズを大きくすれば、性能が向上する」という法則です。これは、この授業で教えてきたオーバーフィッティングの概念とは大きく異なります。LLMでは、モデルが大きいほど性能が良くなるのです。
5.1 コンピューティング、データ、パラメータのスケーリング
スケーリング法則の基本的な考え方は次のようなものです。より多くのデータとより大きなモデルが常により良い性能をもたらすことがわかっているので、データ量とモデルサイズを増やしたときに、性能がどの程度向上するかを予測できないだろうか？
驚くべきことに、この予測は実際に機能します。OpenAIの「Scaling Laws」という非常に有名な論文から、3つのグラフを見てみましょう。
1つ目のグラフでは、x軸に計算量（トレーニングに使用した計算量）、y軸にテスト損失（基本的には検証損失、perplexityの対数）をプロットしています。これらを対数スケールでプロットすると、スケーリング法則が線形になることがわかります。つまり、計算量を一定量増やすと、テスト損失が予測可能な量だけ減少します。
2つ目のグラフはデータに関するもので、同様の関係が見られます。データセットのサイズを増やすと、損失は予測可能な量だけ減少します。
3つ目のグラフはパラメータ数に関するもので、パラメータ数を増やすと、損失は予測可能な量だけ減少します。
これらのグラフは一見単純に見えるかもしれませんが、実際には非常に驚くべき結果です。なぜなら、これらのグラフを見ることで、2-3年後の性能を予測できるからです。コンピューティングパワーがどの程度増加すると仮定すれば、これらのモデルがどの程度の性能を発揮するかを予測できるのです。これには理論的な裏付けはなく、純粋に経験的な観察結果です。
5.2 スケーリング法則の実例：Transformers vs LSTMs
スケーリング法則の実際の応用例を見てみましょう。例えば、今月10,000台のGPUが利用可能になったとします。どのようなモデルをトレーニングすべきでしょうか？
TransformerとLSTMのどちらを使うべきか迷っているとします。まず、異なるスケールでTransformerをトレーニングします。x軸にパラメータ数、y軸にテスト損失をプロットします。同様に、異なるスケールでLSTMをトレーニングします。これらのポイントが得られたら、スケーリング法則にフィットさせます。
そして、計算量が10倍になった場合の性能を予測します。LSTMの場合、線形性が若干低くなりますが、それでも予測は可能です。このグラフから明らかに、Transformerの方が優れていることがわかります。
スケーリング法則を読む際に重要なのは、2つの要素があることです。1つはスケーリング率、つまりスケーリング法則の傾きです。もう1つは切片です。性能が悪くスタートしても、時間とともに改善する可能性があります。この例では、LSTMは両方の面で劣っていますが、別の例では、ある時点を過ぎると一方のモデルタイプが他方よりも優れているという予測ができる場合もあります。
5.3 最適なリソース配分：Chinchillaの法則
スケーリング法則のもう一つの興味深い応用は、トレーニングリソースの最適な割り当て方法を考えることです。より大きなモデルをトレーニングすべきか、それともより多くのデータで小さなモデルをトレーニングすべきか？
Chinchillaは、この問題に取り組んだ非常に有名な論文です。彼らのアプローチを少し詳しく見てみましょう。
まず、トレーニング損失を見ます。x軸にパラメータ数の違い、y軸にトレーニング損失をプロットします。グラフ上の各曲線は、同じ計算量（FLOPS）でトレーニングされたモデルを表しています。これを実現するために、トレーニングに使用するトークン数とモデルサイズを変化させますが、総計算量は一定に保ちます。
各曲線で最良のポイントを選び、そのポイントがどの計算量曲線に属し、どれだけのパラメータを使用したかをプロットします。これを対数-対数スケールでプロットし、再びスケーリング法則をフィットさせます。
これにより、例えば10^23 FLOPSのモデルをトレーニングしたい場合、使用すべきパラメータ数が100Bであることがわかります。同様に、FLOPSとトークン数についても行います。
Chinchillaの論文が見出した最適なパラメータ数は、トレーニングに使用するトークン20個につき1パラメータです。つまり、1パラメータ追加するごとに、20トークン多くトレーニングすべきということになります。
ただし、ここで注意すべき点があります。これは最適なトレーニングリソースの割り当てであり、推論コストは考慮していません。実際の企業は推論コストも考慮する必要があります。小さなモデルの方が、時間とともに推論にかかるコストが少なくなるからです。
推論コストを考慮した他の論文では、パラメータあたり約150トークンが最適であるとしています。これは、現在最高のモデルが実際にトレーニングに使用しているトークン数とパラメータ数の比率に近いものです。
5.4 スケーリング法則の実践的応用
スケーリング法則は、多くの疑問に答えるのに役立ちます。例えば：
- どのデータを使用すべきか？
- データの混合比率をどうすべきか？
- どのアーキテクチャを使用すべきか？
- モデルを幅広くするべきか、深くするべきか？
- より多くのGPUを購入すべきか、それともより多くのデータを収集すべきか？
これらはすべて、スケーリング法則を使って答えることができる質問です。
最後に、重要な教訓を共有したいと思います。2019年に発表されたRichard Sutton氏の有名なブログ記事について触れたいと思います。彼が気づいたこと（そして私を含む多くの人々がその時点では気づいていなかったこと）は、これらのスケーリング法則を見ると、計算量が増えれば必ずより良いモデルが得られるということです。
また、ムーアの法則やその変形によって、常により良い計算能力が得られることもわかっています。つまり、本当に重要なのは、計算を活用できるアーキテクチャを持つことだけなのです。
結果として、重要なのはシステム、データ、そしてアーキテクチャの小さな違い（活性化関数の選択など）ではありません。これが、多くの研究が産業界にとってはそれほど重要でない部分に焦点を当てている理由の一つです。私も長年そのような研究者の一人でした。
したがって、物事を過度に複雑にしないでください。シンプルなことをうまくスケールさせることが重要です。これは、OpenAIがChatGPTやそれ以前のGPTモデルで私たちに教えてくれたことです。
6. ポストトレーニング（Alignment）
ポストトレーニングの目的は、AIアシスタントを作ることです。言語モデリングだけでは、AIアシスタントとして望むような振る舞いは得られません。例えば、GPT-3のような純粋な言語モデルに「6歳児に月面着陸を説明してください」と尋ねると、完了として「6歳児に重力の理論を説明してください」のような応答が返ってくる可能性があります。これは、インターネット上では質問の後に別の類似した質問が続くことが多いためです。しかし、これはAIアシスタントとして望ましい応答ではありません。
アライメントの目標は、LLMがユーザーや設計者の指示に従うようにすることです。例えば、質問に対して実際に回答を提供したり、モデレーションの観点から不適切な内容を生成しないようにしたりすることが含まれます。
6.1 教師あり微調整（Supervised Fine-tuning, SFT）
6.1.1 SFTの手法と実装
教師あり微調整（SFT）は、人間が収集した望ましい回答でLLMを微調整するプロセスです。「教師あり」と呼ばれるのは、人間が提供した「正解」データを使用するためです。「微調整」は、すでにプレトレーニングされたモデルの重みを少し調整することを意味します。
具体的には、望ましい回答に対して言語モデリングを行います。つまり、次の単語を予測するタスクを、人間が提供した回答に対して行います。これがファインチューニングの部分です。そして、人間が提供した回答を使用することが「教師あり」の部分です。
SFTの実装は比較的straightforwardです。基本的には、プレトレーニングで使用したのと同じ言語モデリング損失を使用しますが、望ましい回答のデータセットに対して適用します。
6.1.2 SFTのデータ収集：人間 vs LLM生成
SFTに使用するデータを収集する方法には、主に2つのアプローチがあります：人間による生成とLLMによる生成です。
人間によるデータ生成は、質の高いデータを得るための直接的な方法です。例えば、Open Assistantというプロジェクトでは、オンラインで人々から質問と回答のペアを収集しています。具体的な例を挙げると、「monoposonyという用語の関連性について短い紹介を書いてください」という質問に対して、人間が適切な回答を書きます。
しかし、人間によるデータ収集には大きな問題があります。それは、非常に時間がかかり、高コストだということです。また、大量のデータを収集するのが難しいという課題もあります。
そこで、代替手段として、LLMを使用してデータ収集をスケールアップする方法が考えられます。これは私たちがAlpacaプロジェクトで行ったアプローチです。具体的には、人間が作成した175の質問回答ペアを使用し、当時最高のモデルであるtext-davinci-003（GPT-3.5）に、同様の質問と回答をたくさん生成するよう指示しました。この方法で、52,000のLLM生成の質問回答ペアを収集しました。
そして、この生成されたデータセットを使用して、当時最高のオープンソースの事前学習モデルであったLlama 7Bを微調整しました。これがAlpaca-7Bモデルになりました。
このアプローチの利点は、人間によるデータ収集に比べて非常に低コストで大量のデータを生成できることです。また、既存のLLMの能力を活用できるため、比較的質の高いデータを得ることができます。
実際の例を見てみましょう。Alpacaで生成されたデータの一例は次のようなものです：
質問：「アルゴリズムとは何ですか？」 回答：「アルゴリズムとは、問題を解決したり目標を達成したりするために使用される、段階的な指示のセットです。...」
このような回答は、2世代前のLLMによって生成されたものとしては、かなり良質だと言えます。
SFTには、データ量に関して興味深い特性があります。Limaという論文が示したところによると、SFTに使用するデータ量を2,000から32,000に増やしても、性能はあまり向上しません。つまり、スケーリング法則はここでは適用されません。
この直感的な理解は、SFTでは新しい知識を学習しているわけではなく、単に望ましい回答のフォーマットを学習しているということです。言い換えれば、事前学習済みのモデルは、すでにインターネット上のすべてのユーザーの分布をモデル化しています。SFTでは、このタイプのユーザーよりもあのタイプのユーザーを最適化すべきだと、モデルに伝えているだけです。
つまり、知識はすでに事前学習済みのLLMに含まれており、SFTは単に事前学習データセットで見たユーザーのタイプの1つに特化しているだけなのです。
6.2 人間のフィードバックからの強化学習（RLHF）
人間のフィードバックからの強化学習（RLHF）は、教師あり微調整（SFT）の問題点を解決するために導入された手法です。SFTには、人間の能力に制限されること、幻覚を引き起こす可能性があること、理想的な回答の生成が高コストであることなどの問題がありました。
RLHFの基本的なアイデアは、人間の行動を直接模倣するのではなく、人間の選好を最大化することです。具体的なプロセスは以下の通りです：
- 各指示に対して、モデルに2つの回答を生成させます。
- 通常、かなり良いモデル（SFTで微調整済みのLLM）を使用して回答を生成します。
- ラベル付け者に、これら2つの回答のうちどちらが好ましいかを選択してもらいます。
- 様々なアルゴリズムを使用して、モデルを微調整し、緑（好ましい回答）のような回答をより多く生成し、赤（好ましくない回答）のような回答を減らすようにします。
6.2.1 報酬モデリング
RLHFを実装する際の重要な問題は、どのような報酬を最適化するかです。ここでは、主に2つのオプションがあります。
1つ目のオプションは、ベースラインによって生成された出力と、現在のモデルによって生成された出力を比較し、人間にどちらが良いかを尋ねることです。ベースラインより良ければ+1、そうでなければ-1という二値の報酬を使用します。
しかし、二値の報酬には問題があります。それは、報酬が疎になり、情報量が少なくなることです。例えば、回答が少しだけ良かったのか、かなり良かったのかがわかりません。
そこで、2つ目のオプションとして、報酬モデルをトレーニングする方法があります。これは本質的に、2つの出力がどれだけ良いかを人間の視点から分類する分類器です。
具体的には、報酬モデルRを用意し、入力xと実際の出力y1（または y2）を与えて、exp(R(x,y1)) / (exp(R(x,y1)) + exp(R(x,y2)))という形式でソフトマックス関数を適用します。この報酬モデルを、人間の選好データに基づいてトレーニングします。
これにより、連続的な情報が得られ、二値の報酬よりも豊かな学習信号を提供できます。報酬モデルのロジットが高ければ、人間がその出力を強く好むことを意味します。
6.2.2 近接政策最適化（PPO）の詳細
報酬モデルを得たら、次はそれを最大化するようにモデルをトレーニングします。ここで使用されるのが、近接政策最適化（PPO）と呼ばれる強化学習アルゴリズムです。
PPOの目的関数は以下のようになります：
E[min(r(θ)A, clip(r(θ), 1-ε, 1+ε)A)]
ここで、r(θ)は新しい政策と古い政策の比率、Aはアドバンテージ（報酬モデルから得られる）、εはクリッピングパラメータです。
また、KLダイバージェンスを使用して、モデルが元の分布から大きく逸脱しないようにする正則化項も加えます。
実際のPPOの実装は、この理想化されたバージョンよりもはるかに複雑です。ロールアウト、クリッピング、その他多くの要素を考慮する必要があります。
PPOは、ChatGPTが使用した元のアルゴリズムです。OpenAIのブログ投稿によると、ChatGPTの開発プロセスは以下の通りでした：
- 教師あり微調整（SFT）を行う
- 人間の選好に基づいて報酬モデルをトレーニングする
- PPOを使用して複数のステップで微調整を行う（青い矢印で示されている部分）
この方法は、GPT-3とChatGPTの間の大きなブレークスルーとなりました。
6.2.3 直接選好最適化（DPO）の導入と利点
PPOには多くの課題があるため、約1年前にスタンフォード大学の研究者たちによって、直接選好最適化（DPO）と呼ばれる新しい手法が提案されました。DPOは本質的に、PPOを簡略化したものです。
DPOの基本的なアイデアは、強化学習を使用する代わりに、好ましい出力を生成する確率を最大化し、好ましくない出力を生成する確率を最小化することです。人間の選好（緑と赤の選択）を考えると、緑を最大化し、赤を最小化するということです。
DPOの損失関数は以下のようになります：
- log(σ(log pθ(y|x) - log pθ(y'|x) - C))
ここで、σはシグモイド関数、pθ(y|x)は入力xが与えられたときに好ましい出力yを生成する確率、pθ(y'|x)は好ましくない出力y'を生成する確率、Cは定数です。
DPOはPPOと比較して、いくつかの重要な利点があります：
- 実装がはるかに簡単です。
- 人間の選好データを直接使用します。
- 理論的に、PPOとDPOのグローバル最適解は（いくつかの仮定の下で）等価であることが示されています。
- 実験結果では、DPOはPPOと同等以上の性能を示しています。
これらの利点により、DPOは現在、少なくともオープンソースコミュニティでは標準的な手法となっています。産業界でも広く採用されていると考えられます。
RLHFは、SFTと比較して大きな性能向上をもたらします。例えば、要約タスクにおいて、事前学習モデルからSFT、そしてRLHF（PPOまたはDPO）へと進むにつれて性能が向上し、時には人間のリファレンス要約を上回る性能を示すことがあります。
また、RLHFに使用するデータ量は、SFTよりも多い傾向があります。SFTが5,000〜10,000、場合によっては50,000程度のデータ点を使用するのに対し、RLHFでは100万オーダーのデータ点を使用することが一般的です。ただし、これはまだプレトレーニングで使用される15兆トークンと比べればはるかに少ない量です。
7. ポストトレーニングの評価
7.1 評価の課題
ポストトレーニングの評価には多くの課題があります。まず、検証損失を使用できないという問題があります。あるモデルがPPOを使用し、別のモデルがDPOを使用している場合、検証損失を比較することはできません。
次に、パープレキシティも使用できません。これは、これらのモデルがアライメントされた後は適切にキャリブレーションされておらず、分布を提供しないためです。
さらに、人間が質問できる内容の多様性も課題となります。オープンエンドな質問応答、生成、要約など、様々なタスクをカバーする必要があります。
また、タスクがオープンエンドであるため、自動化が非常に難しいという問題もあります。
これらの課題に対処するため、実際のユーザーが実際のアプリケーションでモデルに尋ねるような質問を使用し、アノテーターに2つのモデルのうちどちらの出力が優れているかを評価してもらうアプローチが採用されています。
7.2 Chatbot Arena：ユーザー参加型評価
Chatbot Arenaは、現在最も一般的で信頼性の高いベンチマークの1つです。この評価方法は、インターネット上のランダムなユーザーに2つのチャットボットと盲目的に会話をしてもらい、多数の質問をして2つの回答を見て、どちらが優れているかを評価するというものです。
これを数十万人のユーザーに対して行い、実際の選好を得て、モデルのランキングを作成します。現在Chatbot Arenaにアクセスして、これらのモデルと直接対話することができます。
しかし、この方法にも潜在的な問題があります。Chatbot Arenaを使用したいと思う人々は、通常、より技術志向の人々です。そのため、質問の多くは技術関連のものになりがちです。
また、コストと速度の問題もあります。開発プロセスでこのような方法を使用したい場合、多くの人間に支払いをする必要があり、非常にコストがかかります。
7.3 AlpacaEval：LLMを用いた自動評価
これらの課題に対処するため、私たちは人間の代わりにLLMを使用する方法を考案しました。基本的なステップは以下の通りです：
- 各指示に対して、ベースラインと評価したいモデルの出力を生成します。
- GPT-4などの強力なモデルに、どちらの出力が優れているかを評価してもらいます。
- これをベンチマーク全体にわたって平均化し、ウィンレートを得ます。
このアプローチの利点は、Chatbot Arenaとの相関が98%と非常に高いことです。さらに、実行にかかる時間は3分未満で、コストも10ドル未満と非常に効率的です。
7.4 評価におけるバイアスと対策
しかし、このアプローチにもいくつかの課題があります。その中でも特に重要なのが、スプリアスな相関の問題です。
LLMは、人間と同様に長い出力を好む傾向があります。実際、人間も長い出力を好む傾向がありますが、LLMの場合、この傾向がより顕著です。
この問題を具体的に示すために、初期のAlpacaEvalのデータセットを見てみましょう。GPT-4を使って評価を行った場合、GPT-4自体のウィンレートは当然50%になります。しかし、GPT-4に「冗長に回答せよ」と指示すると、ウィンレートは64.4%に上昇します。逆に、「簡潔に回答せよ」と指示すると、ウィンレートは20%に低下します。
これは非常に問題のある結果です。なぜなら、モデルの実際の能力ではなく、単に出力の長さに基づいて評価が行われているからです。
この問題に対処するため、私たちは回帰分析を使用しました。具体的には、因果推論ツールを使用して長さを制御しました。その結果、現在のAlpacaEvalでは、長さの影響が大幅に減少しています。例えば、「冗長に回答せよ」と指示した場合でも、ウィンレートの上昇はわずかです。
評価は、LLM開発において非常に重要な要素です。適切な評価方法がなければ、モデルの真の性能を理解し、改善の方向性を決定することは困難です。Chatbot ArenaやAlpacaEvalのような新しい評価手法は、より包括的で信頼性の高い評価を可能にしています。しかし、バイアスの問題は常に存在し、我々はそれに対して継続的に取り組む必要があります。
8. システム最適化
LLMの開発において、システム最適化は非常に重要な要素です。すべての人にとってボトルネックとなるのは計算能力です。より多くのGPUを購入すれば良いのではないかと思われるかもしれませんが、GPUは高価であり、また希少です。例え1000万ドルを持っていたとしても、最高のGPUを今すぐに購入することはできません。
さらに、複数のGPUを使用する際には物理的な制限もあります。GPU間の通信には時間がかかるため、単純にGPUを増やすだけでは解決策にはなりません。そのため、リソースの割り当て方法や、パイプラインの最適化方法を考えることが非常に重要になります。
8.1 GPUアーキテクチャの基本
GPUの基本について説明しましょう。GPUは主にスループットに最適化されています。これはCPUがレイテンシに最適化されているのとは対照的です。GPUの考え方としては、1つのコマンドを多数のコアで同時に実行するというものです。
GPUの構造を見てみると、多数のストリーミングマルチプロセッサ（SM）があることがわかります。これは通常のCPUのアーキテクチャとは大きく異なります。GPUは高スループットの並列処理に最適化されているのです。
GPUはまた、高速な行列乗算に最適化されています。GPUで何かを実行する際、行列乗算を使用できれば、他の方法と比べて10倍ほど高速になります。これは少し厄介で、行列乗算でできることに制限されてしまうことを意味します。
GPUについてもう一つ注意すべき点は、計算能力がメモリと通信の速度よりも速く向上しているということです。つまり、通常のコードを実行すると、GPUのほとんどがアイドル状態になってしまいます。GPUに送信するデータの供給が追いつかないのです。この傾向は今後も続くでしょう。
8.2 メモリ階層と通信の最適化
GPUにはメモリ階層があります。これはCPUでも同様です。基本的に、コアに近ければ近いほどメモリ容量は小さくなりますが、速度は速くなります。コアから遠ければ遠いほど、メモリ容量は大きくなりますが、速度は遅くなります。
8.3 低精度演算の活用
低精度演算の活用は、システム最適化の重要なテクニックの一つです。基本的なアイデアは非常にシンプルです。浮動小数点数の精度を下げることで、GPUに送信するビット数を減らすことができます。ビット数が少なければ、通信が速くなり、メモリ消費も少なくなります。
深層学習の場合、実は小数点以下の精度はそれほど重要ではありません。例えば、行列乗算やSGD（確率的勾配降下法）を行う際、すでに多くのノイズが存在します。0.01で更新するか0.015で更新するかは、それほど重要ではありません。
そのため、32ビットの浮動小数点数（これは他の分野では標準的に使用される）の代わりに、16ビットの浮動小数点数を使用します。具体的には、行列乗算には16ビットを使用します。
トレーニングでは、自動混合精度と呼ばれる技術を使用します。一部の演算は32ビットで、他の演算は16ビットで行います。基本的な考え方としては、モデルの重みは32ビットで保存し、計算の直前に16ビットに変換します。そして、高速に計算を行い、最後に重みを32ビットで更新します。
重みの更新を32ビットで行う理由は、例えば学習率が非常に小さい場合でも、重みの変化を正確に反映させるためです。つまり、すべての計算は16ビットで行いますが、重みは実際には32ビットで保存されています。これが現在の標準的なアプローチです。
8.4 オペレータフュージョン
オペレータフュージョンは、通信が非常に遅いという問題に対処するためのもう一つの重要な最適化技術です。PyTorchの各行を実行するたびに、変数がGPUのグローバルメモリに移動されてしまいます。
例えば、次のようなコードを考えてみましょう：
x1 = x.cos()
x2 = x1.cos()このコードでは、まずxというデータをGPUのメインメモリからGPUのプロセッサに送り、cosine関数を適用し、結果をGPUのメインメモリに戻します。次の行では、再びデータをGPUプロセッサに送り、別のcosine関数を適用し、結果を戻します。
つまり、GPUのグローバルメモリ（DRAM）とコンピュート部分の間で、各行ごとにデータの往復が発生しています。これは非常に非効率的です。
オペレータフュージョンの基本的なアイデアは、一度だけ通信を行い、すべての計算を行ってから結果を戻すというものです。これが、フュージョンカーネルの本質です。
PyTorchでモデルの計算を高速化したい場合は、torch.compileをモデルに適用するだけです。これにより、モデルの速度が約2倍になります。torch.compileは、基本的にあなたのPyTorchコードをC++やCUDAに書き直し、通信を一度だけ行い、すべての操作を実行してから結果を戻すようにします。
8.5 その他の最適化技術：タイリング、並列化、Mixture of Experts
タイリングや並列化、Mixture of Expertsなど、他にも多くの最適化技術がありますが、時間の都合上、詳しく説明することはできません。
システム最適化は、LLMの開発において非常に重要な要素です。計算能力がボトルネックとなる中、GPUアーキテクチャの理解、メモリ階層の最適化、低精度演算の活用、オペレータフュージョンなどの技術を駆使することで、限られたリソースを最大限に活用することができます。これらの最適化技術は、より大規模で効率的なLLMの開発を可能にし、最終的にはより高性能なAIシステムの実現につながるのです。
9. LLM開発の実際のコストと規模
9.1 Llama 3 400Bの事例研究
Llama 3 400Bは現在、最高のオープンソースモデルの一つです。このモデルのトレーニングに関する具体的な数字を見ていきましょう。まず、このモデルは15.6兆トークンでトレーニングされました。パラメータ数は450億です。
これらの数字から、最適なトークン対パラメータの比率について少し考えてみましょう。先ほど説明したChinchillaの法則では、パラメータ1つに対して約20トークンが最適であるとされていました。一方、推論コストも考慮すると、約150トークンに1パラメータが最適だとする研究もあります。
Llama 3 400Bの場合、トークン対パラメータの比率は約40:1となっています。これは、Chinchillaの法則が示す最適値よりも少し多いですが、推論コストを考慮した場合の最適値よりは少ないです。
9.2 計算リソースとトレーニング期間
次に、このモデルのトレーニングに必要な計算リソースを計算してみましょう。LLMのトレーニングに必要なFLOPS（浮動小数点演算数）を概算する簡単な方法があります。それは、6 × パラメータ数 × トレーニングデータ量 です。
Llama 3 400Bの場合、この計算式を適用すると次のようになります：
6 × 45B × 15.6T = 3.8e25 FLOPS
この数字は非常に重要です。なぜなら、バイデン大統領の最近の行政命令では、1e26 FLOPSを超えるモデルには特別な精査が必要とされているからです。Metaはこの基準の2倍以下に抑えているので、特別な精査を避けることができました。
トレーニングに使用されたGPUについても情報があります。Metaは16,000台のH100 GPUを使用しました。H100のスループットがわかっているので、これを使って計算すると、トレーニングには約70日かかったと推定されます。これは2,600万GPU時間に相当します。
実際、Metaは3,000万GPU時間と発表しています。私の概算よりも少し多いですが、おそらくいくつかの課題があったのでしょう。
9.3 金銭的コストの見積もり
次に、このモデルのトレーニングにかかる金銭的コストを概算してみましょう。これは難しい推定ですが、もし私たちがこれだけのH100 GPUをレンタルしようとした場合を考えてみます。
H100のレンタル価格の下限は1時間あたり約2ドルです。2,600万GPU時間に2ドルを掛けると、5,200万ドルになります。実際にはこれより少し安くなるでしょうが、それほど大きな差はないはずです。
次に人件費を考えます。50人の従業員が年間50万ドルで働いたと仮定すると、2,500万ドルになります。
これらを合計すると、約7,500万ドルという数字が得られます。私の概算は1,000万ドル程度の誤差があるかもしれませんが、おおよその規模感としてはこのくらいだと考えられます。
9.4 環境への影響：炭素排出量
最後に、環境への影響を考えてみましょう。多くの人が、これらのモデルのトレーニングにかかるコストだけでなく、炭素排出量についても懸念を持っています。
私が計算したところ、このモデルのトレーニングで排出されるCO2は約4,000トンになります。これは、JFKからロンドンへの往復飛行を2,000回行うのと同等の排出量です。
確かに、これは大量の炭素排出です。しかし、世界全体の規模で見ると、現時点ではそれほど大きな問題とは言えません。ただし、将来的にGPT-6やGPT-7が開発される頃には、この数字が100倍になる可能性もあります。その時点で、炭素排出は真剣に考慮すべき問題になるかもしれません。
次のモデルについて考える際は、FLOPSが基本的に10倍になると想定すべきです。エネルギーを確保できて、十分なGPUを購入できれば、この規模でのスケーリングは可能です。
これらの数字は、LLM開発がいかに資源集約的で、技術的に挑戦的なプロセスであるかを示しています。同時に、環境への影響や倫理的な問題も含め、LLM開発の様々な側面をバランス良く考慮していく必要があります。
