TL;DR（要約）
言語モデルは研究レベルの難しい数学問題を解くことができる一方、多くのステップや長い文脈を必要とする単純な計算タスクには苦労します。2つの数値を掛け算したり、小さな数独を解いたりするさえ、外部ツールに頼らない限りほぼ不可能です。
しかし、LLM自身がコンピューターのように信頼性が高く効率的になるには、何が必要なのでしょうか。
この問いに対する答えとして、私たちは文字通りトランスフォーマー内にコンピューターを構築しました。任意のC言語コードを、モデル自身が数百万ステップを秒単位で確実に実行できるトークンに変換します。
以下に示すのは、多くのステップを含む最適化問題、すなわちハンガリー法による最小費用完全マッチング(1)を解く際の動作です。
[インタラクティブデモ：ユーザーが10×10のコスト行列を入力し、モデルはハンガリー法を使用して最小費用完全マッチングを解きます。35,277トークン/秒、316,797トークン、7,669行/秒の速度で実行されます。「行1を割り当て中...」、「縮約コストでダイクストラ実行中...」、「デュアル変数を更新中...」といった実行トレースがトークンとして出力されます。各行の割り当てとコストが逐次表示され、最終的なマッチングがグラフで示されます。]
モデルは外部ツールを呼び出すのではありません。代わりに、トランスフォーマーの重みを介してプログラムを直接実行し、トークンごとに実行トレースを生成し、CPU上で1秒あたり3万トークン以上の速度で結果をストリーミングします。
重要な技術的アイデアは、実行トレース用の新しいデコーディングパスです。これにより、モデルのアテンション検索を線形スキャンから対数時間で実行されるクエリに変換し、単一のトランスフォーマー実行内で数百万もの正確な実行ステップを可能にします。
---
動機：LLMは計算できない
最先端の言語モデルは、国際数学オリンピック(2)で金メダルレベルに達したり、未解決の数学・科学問題(3)に取り組んだりできるなど、驚くほど困難な数学を解くことができます。
同時に、残念ながら依然としてギャップが残っています。最先端のモデルでも、純粋に計算的なタスクでつまづくことがあります。基本的な足し算でもミスをし、外部のヘルプなしに単純な数独さえ解けません。Sudoku-Benchなどのベンチマークは、この失敗モードを特に明確に示しており、補助なしの解決率は低いと報告されています(4)。
実践では、このギャップを埋めるために2つの回避策を使います。
・ツール使用：モデルがコードを書き、外部のインタープリタがそれを実行し、モデルが結果を報告します。ツール統合型アプローチは、数学的推論を測定可能に改善します(5)。
・エージェンティックオーケストレーション：外側のループが中間状態を保存し、タスクを分解し、短い文脈でモデルを繰り返し呼び出し、事実上、状態機械を外部に取り付けます。
これらのアプローチは非常に有用ですが、重要な制限を浮き彫りにしています。LLMは長期にわたる正確な計算を独自に確実に実行できないため、実際には実行を外部ツールやオーケストレーションシステムに委任することが多いのです。
類似例でこの違いを明確にしましょう。人間は飛ぶことができません。飛行機を造ってもそれは変わりません。私たちが飛ぶための機械を造っただけです。
現在の言語モデルも同じ状況にあります。タスクが正確な計算を必要とする場合、外部システム（インタープリタ、コード実行環境、エージェントループ）を接続し、それらのシステムに計算を任せます。
しかし、それは能力がモデルの外側にあることを意味します。モデル自体は根本的に不利な状況にあります。推論している計算を自分で実行できないため、タスクを繰り返し別のシステムに委譲しなければなりません。
その結果、モデルはアルゴリズムを説明したり、それらについて推論したり、それらを実行するツールをオーケストレーションしたりできますが、ステップ自体を実行することはできません。計算できないシステムは、計算が何であるかを真に内面化することはできません。
したがって、本当の問いは、モデルが計算について話したり、ツールを通じてアクセスしたりできるかどうかではありません。本当の問いは、それが内部的に計算を実行できるかどうかです。信頼性が高く、効率的に、非常に長期間にわたって実行できるかどうか。もしできれば、計算の調整者であるのをやめ、自身がコンピューターになるでしょう。
---
LLMをコンピューターに変える方法
表面上は何も壊れてはいません。LLMを動かすトランスフォーマーアーキテクチャは信じられないほどの能力を持っています。多くの研究が、さまざまなバリアントのトランスフォーマーがチューリングマシンをシミュレートし、したがってあらゆる有効なコンピューターをシミュレートできるため、複雑な計算を実行できることを示しています(6)。最近の研究は、トレーニングを通じてさえこれらの計算能力を達成できることを示しています(7)。
しかし、理論的な普遍性は実用的な実行と同じではありません。モデルはコンピューターをシミュレートするのに十分な表現力を持っていても、実際にはひどいコンピューターになりえます。古典的な普遍性の結果は、実際の機械での単純な操作が、シミュレートされたモデルでの長いステップ列に対応するような構築に依存することが多いです。言い換えれば、表現能力だけが実用的な実行効率を保証するわけではありません。
私たちはこれに対処するために、純粋に理論的な計算モデルではなく、トランスフォーマー内に現代的なRAMコンピューターを実装します。私たちの構築では、各命令はわずか数トークン（最大5トークン）に対応します。
しかし、それだけでは不十分です。より深い問題はデコーディングプロセス自体にあります。
トランスフォーマーには、実行者としての構造的な不利な点があります。標準的な自己回帰的デコーディングでは、各ステップが完全に蓄積された履歴と相互作用します。実際のコンピューターは、各命令でほぼ一定の作業でコンパクトな状態を更新します。一方、トランスフォーマーは、プレフィックスが成長し続ける中で、一度に1トークンを生成しながら継続的にそのプレフィックスと相互作用します。KVキャッシュは過去のキー・バリュー射影の再計算を回避しますが、デコーディングは依然としてキャッシュされたプレフィックスに注意を払う必要があるため、ステップごとの作業はシーケンス長と結びついたままです(8)。
私たちは、この不利な点を取り除くために、トランスフォーマーアーキテクチャ自体が実行型トレースに対して効率的なデコーディング方式を認めることを示します。重要な技術的突破口は、ルックアップヘッドをヘッド次元2に制限することです。これにより、支配的な検索・更新操作が、シーケンス長に対して対数時間（この構造化された実行環境の場合）で計算できるデコーディングパスが可能になります。これは、標準的なプレフィックス全体にわたるアテンションスキャンではなく、対数時間で実行されます。
これは、トランスフォーマー内で任意のプログラムを数百万ステップ実行できるほど強力です。
この記事の残りでは、これがどのように機能するかを説明します。必要に応じてスキップしてください：
・計算とは何か？ — モデル内実行がツール使用とどう異なるか：トランスフォーマーがプログラムをステップごとに自分で実行します。
・その他のデモ：数独 — トランスフォーマー内でコンパイルされたソルバーを実行し、世界で最も難しい数独とされるArto Inkalaの数独を解きます。
・計算はどうエンコードされるか？ — 追加のみのトレースとしての実行と、トランスフォーマーが過去のステップを見て状態を再構成する方法。
・指数関数的に高速なアテンション — 核心的な突破口：2Dヘッドがアテンションを凸包クエリに変換し、百万ステップのトレースにわたる対数時間デコーディングを可能にします。
・次は何か？ — より豊かなアテンション、大規模な訓練、プログラムを重みにコンパイルし、ソフトウェアのようにAIシステムを成長させること。
---
計算とは何か？
現在、モデルが何かを計算する必要がある場合、コードを書きます。例えば、3+5を足すために、モデルは以下を出力するかもしれません：
python -c "print(3+5)"
生成はその時点で一時停止します。外部ツール使用メカニズムがコードブロックを傍受し、サンドボックス化されたインタープリタに送信し、結果（8）をトークンストリームに注入します。モデルは再開し、今や答えを知っています。
これは機能しますが、実際の実行はモデルの外側で行われました。モデルは計算を指定し、外部システムがそれを実行するのを待っていました。
私たちのトランスフォーマーもプログラムを出力しますが、外部ツールのために一時停止するのではなく、同じトランスフォーマー内でステップごとにそのプログラムを自分で実行します。
これを実現するため、私たちはトランスフォーマーの重み内にWebAssemblyインタープリタを実装しました(9)。WebAssemblyは、高速で決定論的な実行のために設計された低レベルの命令セットであり、CやC++などの言語がコンパイルできる汎用的なターゲットです。3+5を計算するために、モデルは以下のように書きます：
{ i32.const 03 00 00 00 i32.const 05 00 00 00 i32.add 00 00 00 00 output 00 00 00 00 }
モデルは次に高速デコーディングモードに切り替わり、同じトランスフォーマー内でステップごとにプログラムを自分で実行し、トークンの実行トレースを生成します：
03 00 00 00 commit(+1,sts=1,bt=0) 05 00 00 00 commit(+1,sts=1,bt=0) 08 00 00 00 commit(-1,sts=1,bt=0) out(08) halt
各行にはモデルが生成するトークンが含まれます。スタックが成長し、addが発火し、結果が出力され、停止します。すべてモデル自身の出力ストリーム内で、外部の往復なしに行われます。
[比較図：ツール使用（外部）とモデル内実行（当社）の比較。ツール使用ではPythonコードが外部インタープリタに送信され結果が返されます。モデル内実行ではWebAssemblyコードがトランスフォーマー内で直接実行されます。]
重要な違いは、ツール使用は不透明であることです。モデルは制御を引き渡し、ブラックボックスの答えを受け取ります。モデル内実行は透明です。すべての中間ステップがトレースに表示され、モデルは自分自身のデコーディングループを離れることはありません。
---
その他のデモ：数独
数独は、正確な長期計算に対する有用なストレステストでもあります。学習されたニューラルアプローチは、簡単またはランダムな数独で強いパフォーマンスを達成できますが、難しいものでは完全につまづきます(10)。一般的な説明は、自己回帰的モデルは本質的に制約充足問題には適しておらず、トークンごとに回答にコミットし、早期のミスを修正できないためであるとされています(11)。しかし、私たちの完全に自己回帰的なシステムはこれらのベンチマークで100%の精度を達成しており、本当のボトルネックは自己回帰的パラダイム自体ではなく、難しい数独を解くには非常に長い実行トレースが必要であり、標準的なアテンションでは長い文脈の生成が prohibitive に高価になることであることを示唆しています。これはまさに、私たちの高速アテンションパスが対処する問題です。
私たちのシステムは、トランスフォーマー内部で完全に正しいコンパイル済み数独ソルバーを実行します。アルゴリズムの代わりに立つ学習されたヒューリスティクスも、「モデルが解を提案した」と「外部システムがそれを検証した」の間のギャップもありません。トランスフォーマーはステップごとにソルバーを実行します。
保証はベンチマーク特有のものではなく普遍的です。コンパイルされたソルバーが正しければ、トランスフォーマーの実行も正しいということです。実際には、これによりモデルはArto Inkalaの数独など、有名な難問さえ解くことができ、3分以内に正しい解に達します。
[インタラクティブデモ：Arto Inkalaの数独パズルが入力され、21個の初期ヒントが与えられます。モデルは30,921トークン/秒、844,799トークン、6,811行/秒の速度で深さ優先探索を実行します。「制約を伝播中...」、「深さ優先探索を開始...」、「行8列7で3を試行...」といったログが表示されます。最終的に完成した数独が表示されます。]
---
計算はどうエンコードされるか？
自己回帰的トランスフォーマーを考える有用な方法は、それが独自の履歴の中に生きる機械であるということです。従来のコンピューターは、操作の結果として更新できる編集可能なメモリを持っています。しかしトランスフォーマーにはそのようなものはありません。
固定されたプロンプト（入力またはプログラム）があります。そして、成長し続けるトレース（モデルが生成するトークン）があります。各ステップで、モデルは少数のクエリ（アテンションヘッド）を通じて過去を「振り返る」ことができ、それから1つ以上のトークンを追加する必要があります。このプロセスを通じて、動作する機械をエンコードする方法を見つける必要があります。
このモデルとエンコーディングの仕組みについて直感を得るために、以下のことを考えるのが役立ちます。
---
追加のみのトレースとしての計算
トランスフォーマーがどのようにプログラムを内部的に実行できるかを理解するには、計算を少し珍しい方法で考えるのが役立ちます。
計算のステップがすべて次の行に書かれているノートを想像してください。一度書かれたら、それ以前の行は変更できず、ノートは成長するだけです。
・最初の数行には入力（プロンプト）が含まれます。
・各新しい行は計算の次のステップを記録します。
・各ステップで、それ以前の行を振り返ることは許されますが、編集はできません。
これは、自己回帰的トランスフォーマーの動作に驚くほど近いものです。プロンプトは入力、生成されたトークンは成長し続けるトレースを形成し、各新しいトークンはアテンションを介して少数の過去の位置を見た後に生成されます。
以下はおもちゃの例です。文が与えられたら、動詞の数が奇数か偶数かを数えます。各トレーストークンは、正確に2つの位置に注意を払います。対応する入力単語（それが動詞かどうかを確認するため）と、前のトレーストークン（実行中のパリティを読み取るため）です。
[図：プロンプト「the cat runs and the dog jumps over fences quickly」に対し、トレーストークンE0, E0,...が生成される様子。各ステップは入力の単語と前のトレースを参照します。]
各ステップは文の長さに関係なく、わずか2つのルックバック（プロンプトへの1つとトレースへの1つ）しか必要としないことに注目してください。これが重要な洞察です。多くのアルゴリズムは、各ステップが少数の固定された過去の位置を読むだけで済む、追加のみのトレースとして表現できます。
計算は、各ステップが少数の回数だけ過去を振り返る必要がある、追加のみのトレースとして表現できるか？
答えはイエスです。私たちのシステムでは、モデルはそのようなトレースを明示的に生成します。それが生成するトークンは、仮想マシンの進化する状態を表します。命令ポインタ、メモリとスタックの操作、算術、制御フロー、出力です。モデルは、関連する過去のステップを見るだけで現在の状態を再構成します。
技術的注記：トランスフォーマーは何を振り返れるか？
トランスフォーマーでは、振り返り操作は単に過去のトークンを調べるよりも表現力豊かです。各ステップは、どのトークンを生成するかを決定する際に計算された中間状態も読むことができます。これらは、異なるアテンション層に保存されている値に対応します。こう考えてください。各アテンションヘッドは共有された一次元配列のように機能します。トークンを処理する際、ヘッドはまずあるインデックスに単一の値を書き込み、それから（潜在的に異なる）インデックスで単一の値を読むことができます。順番に、1回の書き込みの後に最大1回の読み込みです。各トークンは、以前のトークンによって公開された値を読み、将来の決定に知らせるために値を公開します。
この読み書きプリミティブに加えて、アテンションは累積和も計算できます。これにより、命令ポインタ、オペランドスタックの深さ、コールスタックの深さをデルタ増分の累積和として追跡できます。インデックスルックアップと合計を組み合わせることで、複雑な計算を実行するのに十分です。
この記事の残りは、効率性の課題に焦点を当てます。たとえトランスフォーマーがそのような実行トレースを表現できたとしても、標準的なデコーディングではトレースが長くなるにつれて増大するコストを支払います。私たちの高速デコーディングパスはこの不利な点を取り除き、2Dヘッドの制限が高速パスを可能にする重要な鍵となります。
---
鍵となる突破口：指数関数的に高速なアテンション
実際のコンピューターは、各命令でほぼ一定の作業でコンパクトな状態（レジスタ、スタック、メモリ）を更新することで、長いプログラムを実行します。
標準的なトランスフォーマーはトークンを生成することで「状態を進め」、各次のトークンは永遠に成長し続けるプレフィックスに対するアテンションによって計算されます。KVキャッシュは以前に計算されたキー・バリューの射影を再利用しますが、基本的なスケーリングを除去しません。各ステップでクエリは依然としてキャッシュのサイズと相互作用する必要があり、そのサイズは生成されたトークンの数に応じて成長します。これが、デコーディング研究がしばしばIO問題になる理由です。ボトルネックは「KVキャッシュを十分速くし、それに対してスコアを付ける」ことになります(12)。
しかし、KVキャッシュをどれほど速くしても、 fundamentallyなスケーリングは残ります。t番目のデコーディングステップは依然として長さtのプレフィックスと相互作用します。これは、ステップごとの作業がトレース長に応じて線形に増加し、tトークンを生成する総コストが二次関数的に増加することを意味します。これはトランスフォーマーのよく知られたボトルネックであり、より高速な代替案を設計する方法は活発な研究分野です(13)。
以下で説明するように、私たちのアプローチはこの二次関数的な爆発に対処し、指数関数的に高速なアテンション検索を実現します。Θ(t)の時間を費やすのではなく、私たちの方法はO(log t)の時間を必要とします。以下は、私たちのHullKVCacheと標準的なKVCacheを比較した場合の実際の動作です：
[比較デモ：HullKVCache（シアン）と標準KVCache（琥珀色）の比較。HullKVCacheは41,709トークンを31,037トークン/秒で生成し、9,580行で1.3秒で完了します。標準KVCacheは4,505トークンを673トークン/秒で生成し、合計258.9秒かかります。グラフはトークン生成数と時間を示しています。]
私たちが関心のあるワークロード（モデルがステップごとに少数の構造化された検索を繰り返し実行する長い実行トレース）では、ステップごとのスケーリングの違いが蓄積されます。
線形スキャンデコーダーは、トレースが成長するにつれて増大し続けるコストを支払います。凸包ベースのデコーダーは、ステップごとのコストを対数時間で実行される検索プリミティブに実質的に結びつけたままにします。長期間にわたって、これは実現可能なものを変えます。標準的なデコーディングの下では実用的ではない計算が、数百万ステップ実行可能になります。
これはまた、ペイオフが単調で決定論的なスパン、つまり正確なコピー、状態機械のステップ、または長い機械的なトレースで最も明確に現れる理由でもあります。これはまさに、完全なアテンションバジェットを費やしたくないステップです。
---
高速パス：2Dアテンション
私たちはこの速度向上を、質問を切り替えることで得ます。私たちは変換器を全面的に高速化しようとしているのではなく、また新しいアーキテクチャを導入したいわけでもありません。
代わりに、私たちはバニラのトランスフォーマーに焦点を当てますが、扱いやすいパラメータ化の下で。具体的には、ヘッドの次元が小さい場合、つまり2Dの場合に焦点を当てます。
これはトランスフォーマー全体が小さいことを意味しません。層の数、ヘッドの数、埋め込みの大きさはいくらでも大きくできます。単に、トランスフォーマーの層間で使用される埋め込みが、より多くのヘッドを結果として生じるような小さなチャンクに分割されることを意味します。n_heads = d_model / 2。
もちろん、この制限は特定のタスクでコストを伴い、すべてに対する魔法の答えではありません。例えば大規模モデルの訓練においてこれがどれほど制限となるかはまだ探求中ですが、十分に柔軟で効率的に訓練でき、非常に複雑なロジックを捉えることができることがわかっています。
実際、チューリング完全性のためには、2Dアテンションがあれば十分です！そして、私たちがこのブログで示すように、RAMコンピューター全体を表現するのに十分な柔軟性があります。これは、トランスフォーマーに高速パスを構築する上で重要な促進者です。抽象的な推論と計画は元のパスの一部であり続けますが、重い計算タスクは高速パスを通ることができます。
モデル自体は完全に標準的なPyTorchトランスフォーマーで、何も異端ではありません：
class VanillaTransformer(nn.Module): def __init__(self, vocab, d_model=36, n_heads=18, n_layers=7, d_ffn=36): super().__init__() self.tok = nn.Embedding(vocab, d_model) self.attn = nn.ModuleList([ nn.MultiheadAttention(d_model, n_heads, batch_first=True, bias=False) for _ in range(n_layers) ]) ...
注目してください。d_model = 36、n_heads = 18は、ヘッドあたりちょうど2Dを与えます。d_model = 256の場合、n_heads = 128となります。このアーキテクチャは7層、標準的なnn.MultiheadAttention、およびゲート付きフィードフォワードネットワークを使用します。カスタムアテンションカーネルも疎なマスクもありません。バニラのPyTorchだけです。それを特別なものにしているのは重みだけです。
2Dアテンションがどのようにしてこれらの印象的な速度向上をもたらすか見てみましょう。
---
2Dアテンションの幾何学的視点
アテンションメカニズムは以下のように機能します：
・各過去のトークンはキーベクトルk_jと値v_jを提供します。
・現在のステップはクエリベクトルqを形成します。
・各キーに対して関連性スコアq・k_jが計算されます。
・ヘッドは、スコアのソフトマックスで重み付けられたすべてのキーの値の合計を返します。
私たちの高速パスに重要な特殊な場合では：
・各キーは2D、k_j ∈ R^2です。
・クエリq ∈ R^2は平面上の方向と考えることができます。
・私たちはその方向でドット積を最大化する点の値が欲しいのです（ハードマックスアテンション）。同点の場合は平均を計算します。
最大化クエリが履歴全体に渡ってグローバルであっても、そのような2Dアテンションクエリに対数時間で応答できる効率的なデータ構造が存在します。これはまさに計算幾何学における古典的な「支持点」クエリです。方向qが与えられたら、凸包上でその方向で最も遠い点を見つけます。トークンが生成されるにつれてそのようなデータ構造を維持することで、過去の点全体の集合に対して効率的に検索できます。
ヘッド次元を2に制限することで、高速パスが可能になります。推論中に、総当たりスキャン（「すべてのキーに対してスコアを付ける」）を、凸包上のわずかな点の部分集合だけを見ることで最大値が見つかる構造に置き換えることができます。
技術的注記：なぜ2次元で十分か？
メモリとスタック操作を実装するには、各アテンションヘッドが「インデックスiに最後に保存された値を与えてください」というクエリに答える必要があります。このインデックスルックアップが2Dキーを必要とします。インデックスjを2Dキーk_j = (2j, -j^2)として保存してください。インデックスiをルックアップすることは、方向q = (i, 1)でクエリを行うことに相当します。なぜなら、argmax_j{(2j, -j^2)・(i,1)} = iだからです。二次項-j^2は、j≠iの場合にペナルティとして機能し、exact matchだけがargmaxで勝利することを保証します。
アテンションは累積和も計算できます。これを使用して、命令ポインタやスタックの深さなどの量を追跡します。すべてのキーが同じ値に設定されている場合、アテンションはすべての値を均等に平均し、現在のトークン位置tを掛けることで実際の合計を回復します。これには1D（あるいは0D）キーしか必要ありません。インデックスルックアップが私たちを2Dに迫ります。
---
次は何か？
私たちはトランスフォーマーがコンピューターになれることを示し、それはソフトウェアとニューラルネットワークの間に新しいインターフェースを開きます。プログラムがモデル自身の推論ループ内で効率的に実行できるようになれば、はるかに大きな設計空間が開きます。
---
より豊かなアテンション機構
簡単のため、私たちの構築ではハードマックスアテンションを使用します。しかし、それは根本的な制限ではありません。正確なソフトマックスアテンションを同じ効率で維持できるかどうかはまだわかりませんが、トップkスパースソフトマックスアテンションでそれを近似することは簡単です。トップkのキーを取得し、それらに対してのみソフトマックスを実行します。入れ子になった凸包全体にわたって点を保存することにより、これはO(k + log n)のデコーディングコストを生み出します。
これは、幾何学的な高速パスが私たちの実行構築に限定されないことを意味します。原則として、これはデコーディング時に2Dヘッドを持つ任意のトランスフォーマーを高速化し、完全な線形スキャンを効率的な幾何学的検索に置き換えることができます。同じ機構は3D凸包を介して3Dヘッドにも自然に拡張されますが、高次元では急速に非効率になります。重要な問いは、2Dがすでに速度向上の大半を捉えているか、それともわずかに大きなヘッドが大幅に多くの能力を解き放つかどうかです。
[図：kスパースソフトマックスは入れ子の凸包からトップkのキーを取得し、それらに対してのみソフトマックスを適用します。コストはO(k + log n)です。]
---
2Dヘッドを持つ大規模モデルの訓練
ここで使用される2Dヘッドパラメータ化は、本質的に小さいわけではありません。パラメータ総数は、より多くのヘッドと層を使用できるため、標準的なトランスフォーマーと比較可能なままです。本当の問いは、これらのモデルが大規模に訓練されたときにどれほど有能になるかです。
その問いは、純粋な能力を超えて重要です。これらのモデルは、いくつかのモードで有用です。より一般的なモデルと組み合わせた専用の高速パスとして。単一システム内の高速/低速ハイブリッドアーキテクチャの一部として。または、高速にトークンを提案し、通常のアテンションモデルが検証して受理する推測的実行モデルとして。最終的な能力の上限に関係なく、これらはすでにより大きなモデルを高速化するための強力なシステムプリミティブを示唆しています。
[図：標準トランスフォーマー（4ヘッド×d_h=64）と2Dヘッドトランスフォーマー（128ヘッド×d_h=2、d_model=256で同じ予算）の比較。展開モード：高速パス（計算専用実行）、高速/低速ハイブリッド、推測的デコーディング。]
ここで提示されたシステムは、実行機として設計されたスタンドアロンのトランスフォーマーです。自然な次のステップは、これを大規模言語モデルと組み合わせ、正確な計算が必要なときにこの実行パスを呼び出すようにモデルを訓練することです。そのようなハイブリッドシステムでは、言語モデルが計画と推論を行い、実行コンポーネントがアルゴリズムを実行します。
実行トレースはフォワードパスの一部であるため、プロセス全体は微分可能のままです。私たちは計算自体を通じて勾配を伝播することさえできます。これは外部ツールとは根本的に異なります。より大きなモデルに直接統合できる、訓練可能な計算基板になります。
---
重みへのプログラム埋め込みと勾配降下を超えた訓練
現在のプロトタイプでは、モデルはその動作が重みにエンコードされたインタープリタを学習します。しかし、これらの重みを生成するためのコンパイル機構はさらに進むことができます。原則として、任意のプログラムはトークンシーケンスとして表現する必要なく、直接トランスフォーマーの重みにコンパイルできます。
それにより、重み自体がソフトウェアの展開ターゲットになります。ソフトウェアのような振る舞いを学習するだけでなく、モデルは字面通り、内部回路の一部としてコンパイルされたプログラムロジックを含むことができます。
[図：C言語のfib関数がトランスフォーマーの重み（W_Q, W_K, W_V, W_O, W_ff）にコンパイルされる様子。「重みは展開ターゲットとなる」。]
ロジックが重みにコンパイルできるなら、勾配降下はモデルを変更する唯一の方法ではなくなります。重みコンパイルは、ネットワークに直接構造、アルゴリズム、および保証を挿入する別のルートを提供します。
真剣に受け止めると、これは訓練全体の全く異なる図式を示唆します。データで重みを最適化するだけでなく、モデルの一部を直接書くことも含みます。その考えを十分に推し進めると、経験から学習するだけでなく、自分自身の重みを変更または拡張し、事実上、内部機構の一部を書き換えるシステムが得られます。
---
ソフトウェアのようにAIシステムを成長させる
最後に、ソフトウェアがニューラルアーキテクチャの一部になるなら、AIシステムは今日のソフトウェアライブラリのように、時間をかけて成長する方法を必要とします。現代のソフトウェアエコシステムは、モジュール、抽象化、再利用可能なコンポーネントを蓄積することで進化します。AIシステムでも同様のプロセスが最終的に起こるかもしれません。そこでは、新しい計算能力がモデルの内部実行エンジンに段階的に追加されます。
[図：ソフトウェアエコシステムがモジュールを蓄積するように、AIシステムは計算能力を段階的に追加できます。新しい能力はシステム全体を再訓練せずに既存の回路に接続されます。]
私たちの仕事は、トランスフォーマーが自分自身の推論ループ内で効率的にプログラムを実行できることを示しています。より広い視野は、将来のAIシステムがソフトウェアを使用するだけでなく、それを含み、学習された表現とコンパイルされたアルゴリズムを単一の計算基板内に統合することです。その世界では、ソフトウェア自体がモデルの一部になります。
---
結びの言葉
私たちは、トランスフォーマーが自分自身の推論ループ内で効率的にプログラムを実行できることを示しました。外部ツールとしてではなく、モデル自体の一部として。これは、学習された表現とコンパイルされたアルゴリズムを単一の計算基板内に統合するAIシステムへの道を開きます。
私たちはこれが重要だと考えています。なぜなら、医療、サプライチェーン、金融機関における不確実性の下での逐次的意思決定など、私たちが関心を持つ最も困難な問題は、柔軟に推論しつつ確実に計算できるシステムを必要とするからです。
私たちは現在これらのシステムを構築しており、人材を募集しています。言語モデル、強化学習、実世界の意思決定システムの交差点にある問題に取り組みたい場合は、https://jobs.ashbyhq.com/perceptaからご応募ください。