トウシル公式アプリ
基盤モデル、大規模言語モデル
AIには基盤モデル（Foundation Model）、大規模言語モデル（LLM）などがあります。
基盤モデルとは、大規模な事前トレーニングされた言語モデルや画像モデルなどの基礎となる汎用的なAIモデルのことを指します。
基盤モデルと大規模言語モデルは密接に関係しています。
大規模言語モデルは自然言語処理タスクに特化した大規模な言語モデルを指します。大規模言語モデルはテキストデータから事前学習されており、さまざまな言語関連タスク（質問応答、機械翻訳、文章生成など）に転移学習させることができます。
一方、基盤モデルは大規模言語モデルに加えて、画像や動画などのマルチモーダルデータから学習された汎用的なモデルも含まれる、より広い概念です。
代表的な大規模言語モデル
代表的な大規模言語モデルを列挙します。
- GPT-3（OpenAI）– 1,750億パラメータのモデルで、高度な言語生成能力を持つ
- GPT-2（OpenAI）- GPT-3の前身で、15億パラメータ
- PaLM（Google）- マルチタスク対応の5,400億パラメータモデル
- BERT（Google）- 事前学習モデルの代表格で、双方向学習が特徴
- Megatron-Turing NLG（Microsoft/Nvidia）- 5,300億パラメータ
- Gopher（DeepMind）- マルチタスクに対応する2,800億パラメータモデル
- Jurassic-1（AI21 Labs）- 1,780億パラメータで高い一般化能力
- Bloom（Hugging Face/BigScience）– 1,760億パラメータの多言語対応モデル
- GLaM（Google）- 1兆パラメータの超大規模マルチモーダルモデル
- PaLM-E（Google）- マルチタスク対応の6兆パラメータの最新モデル
代表的な基盤モデル
代表的な基盤モデルを列挙します。
- GPT-3（OpenAI）- 大規模な言語モデルの代表格
- CLIP（OpenAI）- 画像とテキストの組で学習したマルチモーダルモデル
- Gopher（DeepMind）- マルチタスク対応の言語モデル
- PaLM（Google）- マルチモーダル対応の大規模言語モデル
- Flamingo（DeepMind）- 画像、テキスト、その他モダリティに対応
- Florence（Google）- PaLMをベースとした画像・テキストモデル
- OPT（Meta AI）- 175億パラメータの大規模言語モデル
- Yuan 1.0（Anthropic）- 構造化した事前学習で効率化
- GLaM（Google）- 1兆パラメータの超大規模マルチモーダルモデル
- LaMDA（Google）- 対話AIとして注目されたモデル
先行投資
基盤モデルの開発には莫大（ばくだい）な費用がかかります。例えば、OpenAIのGPT-3は推定約4,600万ドルの費用をかけて学習させたと報告されています。GoogleのPaLM開発費は2億4,000万ドル以上と見積もられています。DeepMindの基盤モデルへの投資額は正確には不明ですが、数億ドル規模とみられています。
基盤モデルへの投資には重複投資のリスクが存在します。結果として無駄な投資が生じてしまいます。どのようなアプローチが最終的に勝ち残るのか予測が難しい状況です。そのため、ベンチャーキャピタルは有望なプロジェクトを見極めにくく、結果的に失敗プロジェクトへの投資リスクが高まります。
さらに性能向上には継続的な投資が必要なため、一度投資したプロジェクトでも資金不足に陥れば行き詰まるリスクもあります。
20世紀初頭の1900年代から1910年代にかけて、米国では小規模な自動車メーカーが乱立し、業界に参入した自動車メーカーの数は100社を超えていたといわれています。当時は自動車産業がまだ黎明（れいめい）期にあり、技術的な標準化が進んでいなかったため、多くの企業が自動車製造に参入することができました。
しかし、のちにフォード自動車がT型フォードの量産方式を確立すると、大量生産による製造コストの削減が可能になり、競争力のある大手企業が台頭してきました。
その結果、小規模な自動車メーカーは次第に淘汰（とうた）され、1920年代後半にはフォード、ゼネラルモーターズ、クライスラーの「ビッグ3」が確立されるに至りました。当初は100社を超える自動車メーカーがあったものの、結局は寡占化が進行したのです。
このように、新しい産業が立ち上がる黎明期には、参入企業が乱立するのが一般的な現象です。基盤モデルの現状もこれと似た構造にあり、今後は自動車産業同様、大手企業主導への収れんが予想されています。
計算リソース
大手企業は自社のクラウドサービスとして、高性能な計算リソースをレンタル提供しています。例えばAmazon Web Services、Google Cloud、Microsoft Azureなどがそうです。これらのクラウドサービスを利用すれば、スタートアップはデータセンターに自前で投資することなく、必要な計算リソースをスケーラブルに調達できます。
これによりスタートアップは、既存の大規模言語モデルをクラウド上で転移学習させ、独自のFoundation ModelやLLMを効率的に構築することが可能になります。自社でデータセンターを構築するよりはるかに低コストで、大規模モデルの開発が実現できるのです。
また、クラウド上ではデータセットの保管・管理も容易になるため、基盤モデルの学習に必要な大量のデータにもアクセスしやすくなります。
こうした理由から、計算リソースとデータの両面でクラウドを活用し、既存大規模言語モデルをベースにして新たな基盤モデルを開発するアプローチが、スタートアップにとって現実的な選択肢となっているのです。
基盤モデルや大規模言語モデルの開発においてクラウドリソースを活用する場合の契約期間については、一般的な情報は限られています。ただ、一般論として以下のようなことが考えられます。
短期契約（単年度など）:
- 予算の制約からまずは短期で始める
- リソース需要が変動しやすい初期段階向き
- 将来的なスケーリングを見越して柔軟性を重視
中長期契約（3～6年程度）:
- 大規模な計算リソースを長期間確保したい
- リソースの安定的な供給とコストを抑えたい
- モデル開発の長期的なロードマップに合わせる
つまり、スタートアップの開発フェーズやリソース需要、財務状況によって、契約期間は大きく異なってくるものと考えられます。初期は柔軟性を重視し、中長期的には安定供給とコスト削減を狙うというのが一般的なパターンかもしれません。長期的な開発を見据えた場合、5年以上の長期契約も不自然ではないでしょう。
トークン
大規模な言語モデルや基盤モデルのリソース使用量を測る手法として、トークン（token）という単位が用いられています。
トークンとは、モデルが処理する最小の言語単位のことを指します。テキストデータを単語に分割した際の1単語がおおむね1トークンに相当します。ただし、単語の区切り方によっては、1単語が複数のトークンに分割されたり、逆に複数の単語が1トークンにまとめられたりします。
具体的には、モデルの学習に使われたボキャブラリー（語彙）に基づいて、テキストがトークン列に変換されます。あらゆる入力テキストは、このようにしてトークン列に変換された上で、モデルに渡されます。
そしてモデルは、入力トークン列から次のトークンを予測するという作業を繰り返すことで、テキスト生成やタスク遂行を行います。この際、モデルが処理するトークン数が計算リソース使用量の指標として用いられます。
トークンベースの課金モデルでは、ユーザーが入力したテキストのトークン数と、モデルが生成したテキストのトークン数の合計に応じて、利用料金が決定されます。
このようにトークンはAIモデルの入出力を表す基本単位となっており、リソース使用量の見積もりや、クラウドサービス利用料の算出基準になっています。
基盤モデルの構築においても、トークンは重要な指標として使われます。
モデルの学習（トレーニング）フェーズでは:
- 学習に使うデータセット中の単語がトークンに変換される
- モデルは、これらの入力トークン列から次のトークンを予測する作業を繰り返し学習する
- 従って、学習データセットの総トークン数が、トレーニングにかかるコストの目安になる
一方、推論（インファレンス）フェーズでは:
- ユーザーの入力テキストがトークン列に変換される
- モデルはその入力トークン列から出力トークン列を生成する
- 入力トークン数と出力トークン数の合計が、推論コストの基準になる
つまり、基盤モデルの構築においては、学習とインファレンスの両方の段階でトークン数が重要な指標となります。特に、学習データセットが大規模になればなるほど、トレーニングに要するトークン数は膨大になります。
トークン消費量の成長が鈍化するシナリオ
基盤モデルの開発には莫大な計算リソースとデータセットが必要なため、中小企業では継続的な投資が困難になります。結果として多くのスタートアップ企業が淘汰されると考えられます。
そうなれば、トークン消費量の大部分を大手企業が占めるようになり、新規参入企業によるトークン消費の増加は相対的に小さくなります。つまり基盤モデルの領域全体でのトークン消費量の伸びは鈍化する可能性があります。
トークンの使用量の計測自体には、必ずしもGPUやカスタムAIアクセラレータのような高価な専用ハードウエアは必要ありません。比較的廉価な汎用CPUでも十分に可能です。
トークンの使用量を計測するためには、以下の処理が行われます:
- 入力テキストをトークン列に変換する
- モデルが生成した出力テキストをトークン列に変換する
- 入力トークン数と出力トークン数を合計する
これらの処理は全て、比較的単純な文字列処理およびカウンティングで実現できます。高度な並列計算能力は特に必要ありません。
従って、トークン使用量の計測プロセス自体は、通常のCPUでも十分にこなすことができます。高価な専用ハードウエアは不要だといえます。
一方で、基盤モデルや大規模言語モデルの学習やインファレンスの実行そのものには、GPUやAIアクセラレータなどの並列処理能力が不可欠です。しかし、その際のトークン使用量のカウント自体は、別の安価な汎用CPUで十分に行えます。
アップルが消費者デバイスにAIを埋め込む場合、トークン課金の必要性は大きく変わってくる可能性があります。一般に、クラウドベースのAIサービスではトークン課金が一般的ですが、オンデバイスのAIではその必要性が低くなります。その理由は以下の通りです:
1．リソース消費が端末内に閉じている
オンデバイスAIでは、モデルの推論処理が全て端末内で完結する。クラウドリソースを消費しないため、トークンベースの課金が必要ない。
2．事前にモデルが組み込まれている
モデルは製品出荷時に端末にプリインストールされており、クラウド側でリアルタイムに推論を行う必要がない。
3．メモリ/電力消費の最適化が重要
オンデバイスではメモリ使用量や電力消費を抑えることが重要で、トークン数よりもこれらの指標が重視される。
4．オンデバイスAIの課金は製品価格に含まれる
トークンベース課金ではなく、製品価格に別途AIの価値が上乗せされる形になる可能性が高い。
従って、オンデバイスAIの場合、トークン課金の必要性は低下し、クラウドAIとはまた異なる課金モデルが求められることになります。ただし完全にオフラインでは動作しないケースもあり得るため、ハイブリッド課金モデルが検討される可能性もあります。
