度肝を抜かれた!MIT の研究者が Transformer 内にコンピュータを構築、LLM はもはや外部ツール不要か?

画像

LLM は国際数学オリンピック(IMO)で金メダルレベルの成績を収めることができる一方で、小学生レベルの算数計算でつまずくこともある。

この矛盾は長年、AI 業界全体を悩ませてきた。

現在、ある者が全く新しい解決策を提示した。それは、外部ツールを新たに追加するのではなく、Transformer の内部に直接「コンピュータ」を構築するというものだ。

あの「AK 氏(Andrej Karpathy 氏)」さえも驚嘆する凄まじさである。

画像

大規模言語モデルの致命的な弱点

現在最先端の言語モデルは数学的推論において驚異的なパフォーマンスを示している。GPT クラスのシステムは国際数学オリンピックで金メダルを獲得する水準に達し、未解決の科学的難問にも対処可能だ。

しかし、頑固な弱点が一つだけ存在し続けている。それが「純粋な計算タスク」である。

基本的な足し算で誤りを犯し、外部の力を借りなければ簡単な数独さえ解けない。「Sudoku-Bench」などのベンチマークテスト結果によれば、大規模モデルが補助なしで問題を解く成功率は極めて低い。

現在の回避策としては主に 2 つある。

1 つ目は「ツール呼び出し」だ。モデルがコードを記述し、外部のインタプリタがそれを実行して結果を返す。これは有効だが、実行自体はモデルの外部で行われる。

2 つ目は「エージェントのオーケストレーション」である。外部ループで中間状態を保存し、タスクを分解してモデルを繰り返し呼び出す。本質的にはモデルの外側に状態機械を付加しているに過ぎない。

この問題の本質は次のような例えで理解できる。人間は空を飛べないが、飛行機を作ったからといって人間が飛べるようになったわけではない。ただ、人間のために飛ぶ機械を作っただけだ。

今日の大規模モデルが計算タスクに直面している状況は全く同じだ。アルゴリズムを記述することはでき、ツールを調整してアルゴリズムを実行させることはできるが、自らアルゴリズムを実行することはできない。計算を実行できないシステムが、計算の本質を真に理解することはあり得ないのだ。


Transformer 内部にコンピュータを構築する

MIT で博士課程に在籍する Christos Tzamos 氏とその研究チームは、この問題に正面から挑んだ。

画像

彼らの核心的な解決策は、Transformer 内部に現代的な RAM 方式のコンピュータを実装し、任意の C 言語コードをモデルが直接実行可能なトークン列へコンパイルすることであった。

具体的には、Transformer の重みの中にWebAssembly インタプリタを実装した。WebAssembly とは低レベルの命令セットであり、C 言語や C++ などの言語から直接コンパイルできる。各命令は最大 5 つのトークンにマッピングされる。

「3+5」を実行するプロセスは以下の通りだ。モデルが WebAssembly の命令列を生成し、その後高速デコードモードへ切り替える。そして、同じ Transformer 内部でトークンごとにプログラムを実行し、完全な実行軌跡を出力する。

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

スタックの増加、加算のトリガー、結果の出力、マシンの停止。これら全てがモデル自身の出力ストリーム内で完結しており、外部呼び出しは一切行われない。

ツール呼び出しは不透明だ。モデルは制御権を明け渡し、ブラックボックスからの答えを受け取るだけである。一方、モデル内実行は透明である。全ての中間ステップが軌跡上に現れ、モデルはそのデコードループから離れることがない。


数独:最も困難な問題も解き明かす

数独は、長鎖かつ正確な計算を要するもう一つのストレステストである。

ニューラルネットワークによるアプローチは、単純な数独やランダムな数独では良好な結果を示すが、難問に直面すると崩壊してしまう。一般的な説明としては、「自己回帰モデルはトークンごとに答えを確定させるため、初期の誤りを修正できず、制約充足問題には本来的に不向きだ」とされる。

しかし、この研究は異なる答えを提示した。問題点は自己回帰というパラダイムそのものではなく、難問を解くには極めて長い実行軌跡が必要となる点にある。そして、標準的なアテンション機構では、長い文脈を生成するコストが高すぎることが原因だとした。

彼らのシステムは Transformer 内部でコンパイル済みの数独ソルバーを実行し、正解率 100%を達成した。これには世界で最も難しいとされるアルト・インカラ氏作成の数独も含まれており、3 分以内に正解を導き出している。

画像

これが普遍的に保証される理由は単純だ。コンパイルされたソルバー自体が正しければ、Transformer の実行結果もまた正しいからだ。学習によって得られたヒューリスティックな推測も、「モデルによる提案答え」と「外部システムによる検証答え」との間に生じる乖離も存在しない。


中核技術の突破口:指数関数的に高速化したアテンション機構

この方案を実際に機能させるには、さらに深い工学的障壁を克服する必要があった。

Transformer を実行者(エグゼキュータ)として用いる際、構造的な欠陥が存在する。標準的な自己回帰デコードでは、各ステップで増え続ける履歴シーケンスとの相互作用が必要となる。本物のコンピュータはコンパクトな状態を更新するだけで、各命令の計算量はほぼ一定だ。対して Transformer は t 番目のトークンを生成する際、長さ t の接頭辞と相互作用しなければならない。KV キャッシュが再計算のオーバーヘッドを節約するとしても、キャッシュをスキャンするコストはシーケンス長に比例して線形に増大する。

その結果、1 ステップあたりの計算量が軌跡の長さに比例して線形に増大し、t 個のトークンを生成するための総コストは 2 乗則(O(t²))になってしまう。これが Transformer の古典的なボトルネックだ。

研究チームの突破口は、実行軌跡という構造化されたシナリオにおいて、Transformer のアテンション機構が全く異なるデコードパスを辿れると発見した点にある。

重要な制約条件は、アテンションヘッドの次元を 2 次元に限定することであった。

この制約が物事を質的に変化させた。

2 次元の場合、アテンションのクエリは幾何学的な言葉で再定義できる。過去の全トークンのキーベクトルは平面上の点群を構成し、各クエリはその集合上での最大内積探索、つまり给定された方向において凸包(convex hull)上で最も遠い点を見つけることと等価になる。これは計算幾何学における古典的な問題であり、対数時間複雑度(O(log n))のデータ構造で解決可能だ。

これにより、標準デコードにおける線形スキャン(各キーを個別にスコアリング)が凸包クエリ(幾何学的データ構造を維持し、各検索でわずかな点にのみアクセスする方式)に置き換えられた。

その効果は絶大で、1 ステップあたりのデコードコストがΘ(t) から O(log t) へ低減された。

実測結果においても、HullKVCache と標準 KVCache の 1 ステップあたりの所要時間は、シーケンス長の増加に伴い極めて顕著な差を示した。

画像

システム全体の CPU 上でのスループットは毎秒 3 万トークンを超え、数百万ステップにわたるプログラムの連続実行を可能にしている。


2 次元で十分なのか?

この制約は強すぎないだろうか?

研究チームの答えはこうだ。「チューリング完全性を実現する上であれば、2 次元のアテンションで十分である」と論文内で証明済みだという。

モデル自体は完全に標準的な PyTorch 製の Transformer であり、カスタマイズされたアテンションカーネルもなければ、スパースマスクも存在しない。d_model=36n_heads=18であり、各ヘッドは正確に 2 次元、7 層のネットワークとなっている。特筆すべきはその重みそのものだけだ。

モデル全体としては任意の層数、任意のヘッド数、任意の埋め込み次元を持つことが可能であり、2 次元という制約は各ヘッド内部のキー・値ペアにのみ作用する。その代償として、より多くのヘッドを持たせることができる。

ソフトマックス・アテンションに関しても近似案が機能する。トップ k 個のキーを検索し、それらのキーにのみソフトマックスを適用することで、O(k + log n) のデコードコストを達成可能だ。同様の発想は 3 次元ヘッド(3 次元凸包に基づく)へも拡張可能だが、次元が高くなるほど効率は急速に低下するだろう。


今後何が可能になるか

この研究が開くのは単なるモデル最適化の方向性だけでなく、ソフトウェアとニューラルネットワークとの間に新たなインターフェースを創出するものだ。

ハイブリッドシステム:言語モデルが計画や推論を担当し、内部実行エンジンがアルゴリズムの実行を担う。両者の境界は外部 API 呼び出しではなく、同じ前方伝播プロセス内の異なるパスとなる。実行軌跡が前方伝播の一部であるため、プロセス全体が微分可能だ。勾配は計算そのものを伝搬していくことになり、これは外部ツールとは本質的に異なる点である。

重みへのプログラムのコンパイル:現在のプロトタイプは重みの中にインタプリタを学習させたものだ。しかし、研究チームが構築したコンパイル機構はさらに先へ進める。任意のプログラムをトークン列として表現するのではなく、直接 Transformer の重みの中へコンパイルすることが可能になる。これはつまり、重みそのものがソフトウェアのデプロイ先となり得ることを意味する。

勾配降下法を超えた学習:論理が重みへコンパイル可能であれば、勾配降下法はモデルを変更する唯一の方法ではなくなる。重みコンパイルは別の道を提供し、ネットワークへ直接的に構造やアルゴリズム、そして信頼性の保証を注入することを可能にする。

ソフトウェアライブラリのように成長する AI システム:現代のソフトウェアエコシステムは、モジュールや抽象化、再利用可能なコンポーネントを蓄積することで進化してきた。AI システム内部でも同様のプロセスが起こり得る。新しい計算能力がモデルの内部実行エンジンへ段階的に追加されていくのだ。


研究チームが描く究極のビジョンはこうだ。未来の AI システムはソフトウェアを「利用する」だけでなく、ソフトウェアを「内包する」ようになる。学習された表現とコンパイル済みのアルゴリズムを単一の計算基盤へと統合するのだ。その世界では、ソフトウェアそのものがモデルの一部となる。

詳細は以下のサイト(英語)を参照されたい。

https://www.percepta.ai/blog/can-llms-be-computers

-- 以上 --


分享網址
AINews·AI 新聞聚合平台
© 2026 AINews. All rights reserved.