LLM（大規模言語モデル）まではいかずとも、超小規模な言語モデルであればこのご時世AIに質問しながら自作できるのではないか、と思い実際にやってみることにしました。

この記事は、あくまで「超入門」かつ文系Webエンジニアが書く記事ですので、Self-AttentionのQueryテンソルがどういう仕組みで更新されていくのか…みたいな、いわゆる数学的分野だったり、混合精度学習や勾配蓄積方式といったパフォーマンスチューニングのメソッドに関してはほぼ触れません。

実装言語も、理解しやすいようにPythonではなく普段使い慣れているTypeScriptを使用します。(Webエンジニアなので！)

どういう処理を経て言語モデルが構築されるのか、推論が行われるのか、モデルの構築から実際の推論までの一連の流れの中でどういった概念が登場するのか、そういった1段階抽象化したところにフォーカスを当てている記事です。

言い訳も済んだところで、早速言語モデル(以降LM)の世界に足を踏み入れてみましょう！

※ ちなみに筆者はHomemade GPT JSという記事の流れをベースに学習しました

GPTの命名について今一度考えてみる

GPT3.5といえば、昨今の生成AIブームのブレイクスルーとなったモデルですが、「GPT」が何の略語なのか今一度思い出してみましょう。

• G
  • Generative (生成可能な)
• P
  • Pre-Trained (事前訓練された)
• T
  • Transformer

Generative: これはその通りですよね。対話型の生成AIはレスポンスを生成することによって人間と会話しています。

Pre-Trained: これもその通りです。LMは学習(訓練)というフェーズを経て一般向けにリリースされます。学習が済んでいないLMにテキストを生成させても支離滅裂な文章だったり意味不明な文字列になるだけです。

Transformer: ではこれは一体何なのでしょうか。まあ答えを先に言ってしまうと、生成AIモデル構築のためのアーキテクチャの名称なのですが、このTransformerが昨今の生成AI(テキストベースのものに限らずSoraなどの動画生成AIなども含む)の設計の根底にあり、生成AIの凄まじい成長速度もこのTransformerがもたらしていると言っても過言ではありません。

Transformerの正体

先ほど「生成AIモデル構築のためのアーキテクチャ」と簡単に説明しましたが、もう少し深堀りしてみます。

時は2017年、Googleで働く研究者8人によってAttention Is All You Needという論文が発表されます。

ここで「データをこういう風に（Attentionという仕組みで）処理すれば、文脈をうまく理解できるよね」ということで提唱されたのがTransformerです。

※ Attentionの内部構造はゴリゴリの数式で表現されるため、今は細かい説明は省きます。

このAttentionという仕組みを「文章を先頭から順番に読むのをやめろ！テンソルごと全部一気にGPUにブチ込んで、全部の文字同士の関連性を『総当たり戦』で同時計算しろ！」という思想(方法)で実現するのがTransformerです。(だいぶ簡潔に説明しましたが)

Transformerが登場する以前はRNNといったアーキテクチャが主流でしたが、その仕組み上並列化が難しかったので、処理に時間がかかり生成AI技術の発展も遅かったのです。

そしてこのAttention Is All You Needを読み、「これを巨大化させて大量のテキストを読ませたらヤバいものができるのでは？」といち早く実行に移した会社こそがOpenAIでした。

Transformerの実装

実際にTransformerをコードとして実装に落とし込む場合、Google製のTensorflowやMeta製のPyTorchがよく用いられます。

今回はTypeScriptのNode.jsでモデル構築をしていくので、@tensorflow/tfjs-nodeを使用します。

※ これまた余談ですが、GPTは元々Tensorflowで構築されていましたが、2020年からPyTorchに切り替わったようです。

Webエンジニア視点でのTransformer

昨今の生成AIの根幹にあるTransformerとはなんぞや、という話をしました。

歴史的背景やTransformerそのものの特徴を捉えておかないとこれ以降ついてこれなくなってしまうので、モデルを自作する時に知っておくべき基礎知識としてTransformerの話をしたわけですが、Webエンジニアの観点で言ってしまえば、

Transformerの実装 = number[][][]型の多次元配列をこねくり回す処理の実装

と言っても過言ではありません。

Attentionといった難しそうな単語が既に出始めていますが、Transformerの一連のフローで行う「数学的処理」というのは巨大な多次元配列同士の掛け算と足し算の繰り返しに過ぎません。

そしてその計算というのはTensorflowがやってくれるので、我々はデータの流れに着目すればOKなのです。

それでは実際のモデル構築の話に移ります。

トークン化 (Tokenize)

トークンとは

文章の分割単位でありLMの処理単位です。(ネットワークにおけるパケットのようなもの)

LMは任意の粒度で文章を分割、重複を排除したそれぞれにIDを振り、後続の処理フェーズではこのIDを配列のインデックスとして使い、文字列を識別しています。

巷では単語のような単位と言われますが、1トークンあたりの情報量はモデルによって自由に定義できるので、例えば今回作成するLMが1文字1トークンという仕様だった場合ほしがほしいという文字列は6トークンになります。

実際のGPTなどの汎用LLMでは、サブワードという、よく使われる単語は1まとめにし、珍しい単語は細かく分割する手法がよく用いられます。

語彙とは

モデルがあらかじめ知っているトークンの一覧と、それに割り当てられたIDの対応表のことです。

ほしがほしいという文字列があり、先程同様1文字1トークンという仕様の場合、語彙は

となります。

トークン化とは

文字列を語彙のIDからなる配列に置き換えることです。

先程の採番ルールでいくとほしがほしいという文字列は[1, 2, 3, 1, 2, 4]となります。

文章の分割含め、このトークン化を行うプログラムをトークナイザーと呼び、例えばGPTが実際に使用しているOpenAI製のtiktokenなどが有名です。

例えば、Tiktokenizerというサイトでは実際にGPTがどういう粒度で単語を分割しているかが可視化出来ます。

モデルの学習・推論において、何らかの文字列をモデルに入力する際は必ずトークン化処理を挟みます。

その逆も然りで、モデルが出力した値を人間が読む際は、IDと語彙をマッピングしてデコードする処理を挟む必要があります。

埋め込み (Embedding)

トークン化の次は埋め込みを行います。

埋め込みとは、

• 機械学習的視点で言えば
  • 各トークンをd_model次元のベクトル空間に配置すること
• Webエンジニア的視点で言えば
  • 各トークンを要素数d_modelの配列に変換すること

です。

いきなりd_modelという単語が出てきて混乱するかもしれませんが、トークン化の次、この埋め込みという作業をするにはd_model・context_window・batch_sizeという3つのパラメーターについて知っておかなくてはなりません😭

d_model

各トークンを何次元の配列で表現するかの値です。

色で例えるならばビット数(8bitカラーとか24bitフルカラーとか)みたいなものです。

このd_modelが十分じゃないと「橋」と「箸」のような同じ読みの単語や、「Apple（果物）」と「Apple（会社）」のような複雑なニュアンスの違いを区別しきれなくなります。

かと言って、d_modelを引き上げると当たり前ですがその分扱うデータサイズも大きくなるので、PCのスペックと相談しながら決める必要があります。

d_modelを2だとすると、[1, 2, 3, 1, 2, 4] (ほしがほしい)は

のように表現できます。

初期状態ではTensorflowによって乱数が割り当てられますが、これらの値が学習が進むにつれ徐々に書き換えられていきます。

みんなが口を揃えていう「学習」の本質は、ここの数字をより最適な値に書き換えることだったわけです。

ちなみにGPT-3のd_modelは12288です。

context_window

モデルが1回に読み込める最大トークン数のことです。

context_windowが3だとして、先程d_modelをあてた配列を更に加工してみると

となります。

後半が消えちゃってるじゃん！と思われたかと思いますが、厳密には「3トークン分は後で別に処理するのでここでは考えない」という状態になっています。

だったらcontext_windowを6にして、全てのトークンを含めたほうが少し離れたトークン同士の関連性なども学習させられるんじゃないの？と思われるかもしれませんが、規模が大きくなってくるとそうも言ってられないのです。

確かにcontext_windowが大きければ大きいほど、遠く離れた文字同士の関連性を学習できるようになるため、前後の文脈(前提条件や伏線)を正確に踏まえた、論理的で一貫性のある高度な出力ができるようにはなるのですが、GPUの計算量はトークン数の2乗になるのでハードウェア的な限界がすぐに来てしまいます…。

というところで、context_windowもPCのスペックと相談しながら決める必要があります。

ちなみにGPT-3のcontext_windowは2048です。(GPT-5だと最大400000)

batch_size

context_window単位のトークンを何個ずつGPUに投げるかの値です。

batch_sizeが2の状態を配列で表現すると

となります。やっとnumber[][][]になりましたね！

ここは単純にPCのスペックとの兼ね合いで決定します笑

GPT-3などの論文では、スケールの大きさをアピールするためにbatch_sizeが「1回のバッチに含まれる合計トークン数」になっていることがよくあり、GPT-3の学習時の実際のbatch_sizeは

3.2Mトークン (合計トークン数) ÷ 2048トークン ＝ 約1562

となります。

トークン埋め込み

3つのパラメーターの解説も済んだところで、いよいよ「埋め込み」という作業に入っていきます。

埋め込みはさらに細分化すると

• トークン埋め込み
• 位置埋め込み

という2つのステップを踏むのですが、このうちトークン埋め込みに関しては実はd_modelの説明の時点で完了しています (!)

なぜなら埋め込みとは冒頭でも説明した通り

各トークンを要素数d_modelの配列に変換すること

だからですね。

位置埋め込み

とはいえ、それぞれのトークンが文章中のどの位置にあるのか、という情報が今だと各トークンに含まれていないので、ここから位置埋め込みというステップを踏む必要があります。

これがトークン埋め込みまで完了した状態のデータ([batch_size, context_window, d_model])だとして

のような位置埋め込み用のデータ([context_window, d_model])を用意します。(これも初期値はランダム)

これらを(batch_sizeごとの並列処理で)足し合わせることによって

というデータを作成します。(ほしがほしいをcontext_window=3で割るとほしの位置が同じなので同じ値になってしまっていますが、問題ないです笑)

これで位置埋め込み、ひいては埋め込みという作業の完了です！

ちなみに、この動画の13分22秒あたりから、埋め込みが実際どういうことなのかということが視覚化されており、非常にわかりやすかったのでおすすめです。

動画をご覧いただくとお分かりになるかと思いますが、要は配列に入っている数字はd_model次元空間における座標だったんですね。

そんなこんなでここまで長々と文章で説明してきましたが、埋め込み作業をTensorflowを使って実装すると以下のようなコードになります。

ちなみに、Tensorflowに渡す用の多次元配列のことを「テンソル」と呼びます。

それでは後続の自己注意機構による処理に移りましょう！

自己注意機構 (Self-Attention)

Transformerの核となるのがこの自己注意機構ですが、中身はほぼ数学、かつこの記事のコンセプトは「数学的分野に殆ど触れない」なので、そのメカニズムについて詳しくは解説しません。

超ざっくりどういうことをやっているかということをお話すると、

埋め込みで得られたテンソルから

• Query
• Key
• Value

という3つのデータを作成して

この数式に当てはめて計算を行います。

すると自己注意機構で計算した結果のテンソルが得られます。

これだけだと流石に不親切なので、Query・Key・Valueがそれぞれ何なのか、現実世界に例えてもう少し解説します。

自己注意機構はトークン同士の婚活パーティーに例えるとわかりやすいです。

• Query
  • 婚活パーティーで例えたら
    • 自分が求めている条件のメモ
  • 機械学習の文脈だと
    • トークンが文脈を理解するために「他のどんなトークンを探しているか」を表すデータ
  • 例
    • 私は『が』という助詞だけど、前にくっつく『名詞』を探しています！
• Key
  • 婚活パーティーで例えたら
    • 自分のアピールポイントが書かれたプロフィールカード
  • 機械学習の文脈だと
    • トークンが他のトークンから探された時に「自分はどういう属性を持っているか」をアピールするデータ
  • 例
    • 私は『星（ほし）』という名詞です！属性はキラキラ光るもので、『が』の前にいます！
• Value
  • 婚活パーティーで例えたら
    • 連絡先
  • 機械学習の文脈だと
    • マッチング（QueryとKeyの相性計算）が成立した後に、実際に相手のトークンにブレンドしてあげる意味の成分データ
  • 例
    • マッチング成立ですね！それでは、私『星』が持つ「夜空に光る天体」という意味の成分をあなたに分け与えます！

こんな感じで、自己注意機構では各トークンの情報交換を行います。(※ただし例として扱っている「ほしがほしい」の6文字だけだと情報が少なすぎるのでここまで高度な推論は当たり前ですができません)

その結果、各トークンのベクトル(d_modelのサイズのnumber[])に前後の文脈の成分が織り込まれます。(織り込まれると言っても数字が書き換わるだけで、テンソルの形は[batch_size, context_window, d_model]から変わりません。)

自己注意機構をTensorflowで実装すると以下のようになります。

Feed-Forward Network

自己注意機構を通ったテンソルは次にFeed-Forward Network(FFN)という機構に入っていきます。

こちらも数学的な処理を行う部分なので詳しいメカニズムは書きませんが(というか自分も解説できない)、先程の婚活パーティーの話を延長すると、FFNでは「婚活パーティーで得た新しい情報を持ち帰り、自分ひとりで(1つのトークンごとに独立して)じっくり考え、自分磨きをする」ということをしています。

FFNでは主に2つの処理が行われていて、

• 各トークンをd_modelの4倍の次元に拡張する
  • 例：婚活パーティーで得た情報を、一旦大きいサイズのノートいっぱいにできる限り書き出して視野を広げる (見落としがちな隠れた複雑な関係性を見つけやすくする)
• 各トークンを元のd_model次元に圧縮する
  • 例：広げた情報の中から、本当に必要な要素をピックアップして自分の中に落とし込む

ということをやっています。

Tipsなぜ「4倍」という倍率なのか？

Answer: Attention Is All You Needを執筆した研究者たちが色々な倍率で実験を行った結果、表現力とコンピューターリソースと兼ね合いで最もバランスが良かったのが4倍だからです。 これはGPTなどの汎用LLMも同じだそうで、暗黙の了解的な側面もあります。 場合によっては将来的に8倍などがデファクトスタンダードになっているかもしれませんね。

Answer: Attention Is All You Needを執筆した研究者たちが色々な倍率で実験を行った結果、表現力とコンピューターリソースと兼ね合いで最もバランスが良かったのが4倍だからです。 これはGPTなどの汎用LLMも同じだそうで、暗黙の了解的な側面もあります。 場合によっては将来的に8倍などがデファクトスタンダードになっているかもしれませんね。

FFNを通り終えたテンソルに対しては、LayerNormという処理を挟み、FFNによって大きくなったベクトルの数字を計算しやすいちょうどいい範囲に整頓します。(オーバーフローを防ぐためという意味合いもあります)

FFN(とLayerNorm)をTensorflowで実装すると以下のようになります。

logitsの中身

FFN(とLayerNorm)を通して最終的にlogitsというデータが得られていますが、これは一言でいうと「語彙1つ1つに対して次の語彙として使われそうな可能性スコアが振られたもの」です。(確率とはちょっと違う)

具体的には

• 「ほ」のスコア：-1.2
• 「し」のスコア：0.5
• 「が」のスコア：-3.0
• 「い」のスコア：5.8

のように語彙のサイズ分テンソルの足し算と掛け算の結果が並んでいます。

ただこれだとマイナスの数字があったり、合計しても100にならなかったりと数字の規模がバラバラなので、後続の処理でSoftmax関数(Transformerが提供)を利用して確率に変換します。

学習

ここからはいよいよ学習に入っていくのですが、やることは大きく分けて

• 予測
• 損失計算
• パラメーター更新

の3つです。

このうち「予測」に関しては実はもうやり終えていて

これまで出てきた

• 埋め込み
• 自己注意機構
• FFN

を通して最終的にlogitsが得られたかと思いますが、この一連の処理こそが予測なのです！ (まだ各トークンのパラメーターが乱数の状態なので予測っぽさはないですが)

なのでここでは、残りの「損失計算」と「パラメーター更新」にフォーカスして解説していきます。

損失計算

損失計算とは予測と答えを見比べてどのくらい誤差があるのかを測ることを言います。

当たり前ですが予測した結果に対して答えが無いと、どの方向にトークンのパラメーターを調整したら良いのか判断できません。

ではどうやって解答データを用意するのでしょうか？

答えはとても単純で、埋め込み時に用意したトークン化した文字列、から1トークン分ずらしたトークン化文字列を解答データとして用意します。

例えばcontext_windowが3という前提のもと、[1, 2, 3] (ほしが)が問題だとしたら、[2, 3, 1] (しがほ)が解答です。

「え？こんな単純な仕組みなの？」と自分も最初思ったのですが、どうやらAIの研究者たちも最初は「こんな単純な仕組みではAIは賢くならないだろう」と考えていたみたいです。

しかし、この仕組み(Next-Token Predictionと呼ばれている)でパラメーター数(d_modelの大きさなど)を数千億に巨大化させ、インターネット全土のテキストを数万枚のGPUで読ませた結果、突如として人間を超えるような推論能力が生まれたみたいで、この現象の原因は今現在も完璧には究明できていないみたいです。

コンピューターサイエンスって人間が築いてきたものなのに究明できてないの面白いですよね。

もちろんGPTなどの汎用LLMの学習にもNext-Token Predictionが用いられています。

ともかく、これで解答データの用意ができました。

パラメーター更新

予測結果と解答の差をもとに、次回の予測ではその差がより小さくなるように各トークンのパラメーターを更新します。

といっても、ここはTensorflowのAPIを呼び出すだけなので特に解説できることはないです…。

実装的には以下のようなコードになります。

stepsというパラメーターが初めて出てきましたが、これは見ての通り学習プロセスのループ回数ですね。

ちなみにGPT-3の発表論文で公開されている総学習トークン数と最大バッチサイズを元に計算するとGPT-3のstepsは10万回強と推測されるみたいでした。

推論

学習が完了したらいよいよ推論です！

推論は、

1. 渡されたプロンプト(トークン)からlogitsを算出
2. logitsをtemperatureで調整する
3. 次に来るトークンを1つ選ぶ
4. 渡されたプロンプト+これまでに自分が選んだトークンからlogitsを算出…

というのを終わりが来るまで繰り返して行います。

temperature

これまでd_modelやcontext_windowなど色々なパラメーターが登場しましたが、推論ではtemperatureというパラメーターが登場します。

temperatureは1.0を基準として、それより低くすると最も次に確率の高い無難なトークンが、高くすると確率の低いレアなトークンも選ばれるようになるパラメーターです。要はAIの独創性をここで調整します。

AIに全く同じプロンプトを投げても毎回レスポンスが異なるのはこれが理由だったわけですね。

ちなみにGPT-3ではtemperatureは1.0に設定されていたみたいです。

推論の繰り返しにおける終わりの合図はなんなのか

先程、推論は終わりが来るまで処理を繰り返すと述べましたが、これはもう少し具体的に言うと「<|endoftext|>トークンが来るまで」ということになります。(もちろんモデルによってここのルールは異なりますが、LMの推論ループ終了はこのルールであることが多いです。)

<|endoftext|>とは訓練データ中のセクションの終わりを示す特殊トークンで、通常のトークン化のようにendとかtextとかで分割するのではなくこの文字列まるまるを1トークンとして扱います。

例えばX(Twitter)のポストをLMに学習させるケースを考えると、ポストの文末に<|endoftext|>を差し込むことによって「ここでこのポストは終わり」というのを学習できるようにします。

<|endoftext|>を学習したモデルは推論の際も「そろそろ1セクション終わるな」と判断した場合に<|endoftext|>を出すので、それをJSでハンドリングしてループを終了→推論して生成したテキストを表示するという仕組みです。

これらの推論の一連の流れをTensorflowで実装すると以下のようなコードになります。

完成した超小規模言語モデルで遊んでみる

ここまでの

• トークン化
• 埋め込み
• 自己注意機構
• Feed-Forward Network
• 学習
• 推論

を実際にTensorFlow.js(Node.js)にて実装したので遊んでみます。(ソースコードはFUGAMARU/vslmにて公開しています)

超小規模なのでApple Siliconでも学習させられるだろう、という考えのもと、まずは以下のスペックのPC・設定で学習させてみました。

1文字1トークンという仕様、かつ訓練データのTinyStoriesが3〜4才児が理解できる単語のみを含む短編小説のデータセットなので、出力された文字列が

• 文章っぽい文字の配置になっている
• 実際に存在する単語が文章中にいくつか登場している

であれば実験成功と言えます。

いくつか推論させてみた結果が以下になります。

"the " と入力

the gamed Bob fun to Lucy. So, hollowere very hole. She saw thad a big, but and became opened helped, but so have and found it with t learned the favoring the titer. and starteday. She like to firest. her to go helped toot and the the one hole casket poside. ave theiralay ind and ladanoued. Sugghed and hes pocked to her amainves Anda tund the ste o f hee he ploud at the bird when toda Ama f got she bo bre sthe palked ton's kellinala.

"a " と入力

a not, but Tom was so be friends. The friend to star, a little bowed and see up the can the began hool. Mia he was so have farme every and proom help youse with a plan tious mad ball strark hitthe room scared agardeng nable They lat shat wappened.

"my " と入力

my book a her and the could of mouse it was a fun box had fun was it. She warm, "I'm bug tree would near a bird so it! The looked bird the faround apple. They wom smid, "I am sapple girl and thent day, on the wis mom leent. friend scary.

いずれのレスポンスも、先程挙げた

• 文章っぽい文字の配置になっている
• 実際に存在する単語が文章中にいくつか登場している

を満たしていて、他にも「ピリオドが来たら次にスペースを入れてその次に大文字のアルファベットを入れる」というような基本的な英文法も再現されていますね。学習は成功したと言えそうです👏

何度かthe で推論させていたのですが、1度the sky.とだけ推論されたことがありました笑

とても風流なAIに育ったようです🎐

規模を大きくしてみる

これで満足できずにさらなる高みを目指したくなってしまうのが人の性。

家に12GBのVRAMを積んだRTX 3060搭載PCが眠っているので、これを使ってLMの規模を大きくしてみます。(VR用にあえてVRAMが少し多いグラボを選んでいたのですが、機械学習で使う時が来るとは…)

PCスペックと設定は以下です。

SimpleStoriesは先程使用したTinyStoriesにインスパイアされて作成された、同じく短編小説のデータセットです。

• トークナイザーを自作のものから汎用ライブラリのものに移行
  • 単語単位で文章を解釈できるように
• 使用する訓練データのサイズを5MBから1.5GBへと一気に増量
• context_windowやd_model等の各種パラメーターも増強

等をしたおかげで、流石にRTX 3060でも耐えきれずにエラーが出るようになってしまいました…。

そこで、

• Node.js実装のスクリプトをPythonに移行
  • Python版Tensorflowの方がハードウェア最適化されている
• 混合精度学習、勾配蓄積方式、多層化といったハードウェア最適化のロジックの盛り込み
  • だから先程は登場しなかったlayersやaccumulation_stepsといったパラメーターが増えている

をAIにやってもらいました😇 (LM構築の基本は勉強できているのでここでAI使うのは許して🥺)

格闘の末になんとか学習を完了させられたので、またいくつかプロンプトを投げて推論させてみます。

“This is ” と入力

This is - Phoenix!” he exclaimed. He was happy to be with his new friend, Kim. They spent the afternoon talking and laughing together. Leo learned that sharing joy could bring more happiness than keeping it all to himself.

“It was ” と入力

It was icensils!” he exclaimed, eyes wide. “What does it do?” The woman smiled softly, realizing that sometimes, treasures can be found in the most unexpected places.

“I have ” と入力

I have 302!” he said, bouncing on his toes. “You’re the best robot ever!” Maria laughed. They both had fun in their little world of toys and games.

謎にエクスクラメーションマークやダブルクォーテーションが入るクセがついていたりしてどれも完璧な文章とは言い難いですが、例えば

The woman smiled softly, realizing that sometimes, treasures can be found in the most unexpected places.

の箇所は

女性は優しく微笑んだ。時として、宝物は思いもよらない場所で見つかるものだと気づいたのだ。

と、意味が通じる文章になっていますね。

ただまあ逆に言えば、PCのスペックも上げて、パラメーターも強化して、ロジックを最適化してもこの程度の文章しか生成できません。

GPTなどの汎用LLMがいかに大規模な言語モデルかを思い知らされますね、、

推論か、回答か

ここまで記事を読んでくださった方の中には「汎用LLMってプロンプトに対して回答してくれるのが普通なのに推論しかできてないじゃん」と疑問に思われた方もいるでしょうが、実は汎用LLMのあれも回答ではなく推論に過ぎないのです(!)

例えばユーザーが「日本の首都はどこ？」というプロンプトを投げたとします。

するとChatGPTなどのバックエンドは、ユーザーから受け取ったプロンプトをそのままGPTなどのLMに対して投げるのではなく

というような対話形式のフォーマットに変換したプロンプトを投げます。

その結果GPTが「User:から始まる質問文がありAI:で始まっているから、自分がUser :の問いかけに対する回答を推論するんだな」と認識し、プログラムでAI: 以降に推論された文字列をピックしてユーザーにレスポンスとして表示している、といった仕組みになっています。

なので汎用LLMの開発においては、今回の記事で扱った学習行為(=事前学習)と、一問一答のデータを学習させる指示学習、という2段階の学習工程を経ます。

今回は事前学習のみを行っているので、プロンプトに対する回答というよりかは、プロンプトの続きを推論するモデルが完成したわけです。

〆

今まで「Transformer」や「トークン」、「ContextWindow」といった用語はもちろん耳にしたことはあったのですが、それぞれがLMの構築においてどういった役割を果たしているのか具体的なイメージまで付いていなかったので、今回のLM自作を通してより用語の理解の解像度を上げることが出来ました。

TransformerをベースとするLMは、1トークン生成するごとにユーザーから受け取ったプロンプトやこれまでに自分が生成したテキストの関係性を自己注意機構で計算し直すため、計算量がとんでもないことになっています。

もちろん、毎回こんな計算をしているわけにはいかないので汎用LLMでは計算結果をキャッシュするのですが、このキャッシュの容量が非常に大きいのです。

キャッシュの容量が大きいとGPUとメモリの転送速度も極めて重要になってくるのですが、いかんせん普通のVRAMだと帯域幅が全く足りません。

そこで、DRAMを何枚も積み重ねたHBM(High Bandwidth Memory)という超高性能メモリ、をGPUの横に搭載したHBM搭載グラボというのをAI企業がこぞって買い漁っている。

だからDRAM価格の歴史的高騰が今発生しているというわけなんですね。

LMの動作原理を学ぶとこういった視点でもニュースが見られるようになるので非常に興味深いです。

すごい余談ですが、DRAMの価格高騰に関する解説記事は以下の2つが詳しいです。

• 【特集】AI巡るメモリ争奪戦――2026年はPC、スマホに“冬”が到来 - PC Watch
• ASCII.jp：【パソコンが買えない】本当は起きていないメモリー不足!? それでもPC向けメモリーの高騰が今年末頃まで続くと予想する理由

(なんだこの締めは)

この記事は 2026/03/21 12:20:33 にビルドされました