8,276 文字
質問をする前から回答を考え始めるという能力をAIに与えることができたらどうでしょうか。実はそれは非常に可能であり、研究者チームがそのやり方を示す研究論文を発表したばかりです。以前、より高度なメモリをエージェントに提供することを考えた最初の論文やオープンソースプロジェクトのひとつであるMEM GPTについての動画を作りました。MEM GPTチームは集まって実際に「Leta」という会社を設立し、そして今、同じチームがこの新しい論文を発表したのです。
スリープタイム・コンピュートを使用すると、プロンプトを入力する前でもAIに考えさせることができ、計算コストを大幅に低減し、場合によってはより高品質な結果を得ることができるようになります。私たちはスリープタイム・コンピュートを導入しました。これにより、クエリが提示される前にコンテキストについてオフラインで考えることをモデルに許可します。まだ理解できない場合は、すべてを説明します。
まず彼らはテストタイム・スケーリングについて話し、それが本質的にあらゆる場所に存在することを述べています。これは新しいスケーリング法則として特定されており、基本的に問題に対してより多くのテストタイム・コンピュートを投入するほど、モデルの出力が向上します。テストタイム・コンピュートに馴染みがない場合、これは本質的に思考モデル（01、03、DeepSeek、Gemini 2.5など）のことです。これらのモデルは思考トークンを出力し、実際に出力を提供する前に推論して考えることで動作します。
しかし、テストタイム・コンピュートには主に2つの問題があります。1つ目は、思考には時間がかかるという点です。これは本当に難しい問題にとっては大丈夫かもしれませんが、ユースケースでレイテンシ制約がある場合、思考時間は非常に重要になる可能性があります。最小でも数秒から数分まで話しています。そしてその思考時間はすべて、GPUが稼働して思考トークンを処理する必要があります。そのため、テストタイム・コンピュートは非常に高価になる傾向があります。
論文の序論でも述べられているように、テストタイム・コンピュートによるパフォーマンス向上は、レイテンシとコストの大幅な増加を伴います。回答を数分待つ可能性があり、クエリあたり最大数十ドルのコストがかかる可能性があります。しかし、なぜこれらの処理がすべてテスト時に必要なのでしょうか？これらの欠点は、現在のテストタイム・コンピュートへのアプローチが問題はステートレスであると仮定していることにも一因があります。本質的にモデルは毎回、プロンプトに対して推論を実行するたびにコンテキストを理解し直さなければなりません。
クエリ、つまりプロンプトと、回答に必要なドキュメントやコードベースなどの背景情報（コンテキスト）は、テスト時にモデルに一緒に提供されます。この論文によると、特に同じコンテキストに対して複数のクエリを実行する場合、これは実際によく当てはまります。たとえば、コードベースをロードしてそのコードベースについて質問したい場合、プロンプトキャッシングを使用していても、モデルは依然として多くの冗長な計算を行う必要があります。
しかし実際には、多くのLLMアプリケーションは本質的にステートフルであり、永続的に再利用されるコンテキストとともに動作します。明らかなユースケースとしては、前述のコードベースやドキュメント処理、ドキュメントQ&A、ビデオ処理などがあります。LLMが毎回ゼロから始める必要がないユースケースは実に多数あります。
ここでドキュメントの質問応答が典型的な例として挙げられています。コーディングエージェントも大きな共通リポジトリで操作し、会話型アシスタントは過去の対話を維持する必要があります。毎回モデルに処理するための完全な生のコンテキストを提供するのではなく、モデルにプロンプトを入力する前に、あらかじめ一部の処理を行うとどうなるでしょうか？
これが図で示されているものです。ここに生のコンテキストがあります：「ジャグラーは800個のボールをジャグリングできる。ボールの1/4はテニスボールで、テニスボールの半分はインディゴ色であり、そのうちの1/10にはマークが付いている」。これが生のコンテキストです。標準的なテスト時には、生のコンテキスト全体と質問（「マークの付いたインディゴ色のテニスボールはいくつありますか？」「テニスボールは全部でいくつありますか？」）を渡し、モデルは毎回すべてを処理します。
しかし、スリープタイム・コンピュート戦略では、生のコンテキストを取り、「学習されたコンテキスト」を持ちます。基本的に、人間の脳が機能するのと非常に似た方法で、AIを使用してコンテキストに対する前処理を行い、それについての理解を深めます。この生のコンテキストから、LLMが最初にプロンプトされる前に理解したいくつかのことを見てみましょう：
「ジャグラーは800個のボールをジャグリングできる。素晴らしい、それがそこに書かれていることです。ボールの1/4はテニスボールで、つまり200個のテニスボールがあることになります。テニスボールの半分はインディゴ色で、結果として100個のインディゴ色のテニスボールがあります。」
基本的に、そのコンテキストについて質問される可能性が最も高いことを予測して前処理しているのです。なぜ前処理をテスト時に行うよりも重要なのでしょうか？テスト時に行われると、そのGPU使用量は10倍も高価になる可能性があります。モデルが回答を返すための厳しい期限がある場合、それはGPUの最も高価な時間です。
GPUがどのように使用されているかを考えてみてください。モデルにプロンプトを入力すると、GPUは処理を行いますが、処理が終わるとただ停止し、待機するだけです。その待機時間は有効活用できるはずです。本質的に需要と供給の問題であり、モデルにプロンプトを入力する時のGPUの需要は、GPUが本質的に「眠っている」時間よりもはるかに高くなります。
学習されたコンテキストの後、同じ質問をします：「マークの付いたインディゴ色のテニスボールはいくつありますか？」思考の連鎖全体を通じて再処理する代わりに、単に「答えは10です」と言います。「テニスボールは全部でいくつありますか？」「答えは200です」。ご覧のように、処理の総量は同様かもしれませんが、その多くはより安価な処理時間中に前処理されています。
論文でより明確に述べられているように、現在の状態、コンテキスト、モデルに提供する情報について、ユーザーの次の入力の前、あるいはその間にオフラインで有用な推論を行うことができます。これを「スリープタイム・コンピュート」と呼び、モデルとのインタラクションの間、つまりそれが通常はアイドル状態である「スリープタイム」に推論が行われます。
それでは、実際にはどのように機能するのでしょうか？基本的な部分を示しましたが、もう少し深く掘り下げてみましょう。これは、既存のコンテキストに関する推論からなる新しいコンテキストを生成するようにモデルにプロンプトすることで達成されます。基本的に、このデータセット、このドキュメント、このコードベースを取り、それらの間のつながりを理解し、このデータに対して尋ねられる可能性のある質問を予測します。
スリープタイムから再表現されたコンテキストは、テスト時にプロンプトで提供できます。つまり、GPUが通常は休止していたであろう間に理解したことをすべて、モデルのコンテキストとして提供することで、テスト時に追加処理を行う必要がなくなります。これにより、モデルは標準的なテストタイム・コンピュートの精度でユーザークエリに応答できますが、はるかに低いレイテンシで処理できるようになります。
具体的な例として、スリープタイム中のコーディングアシスタントは、ユーザー入力の前にアーキテクチャパターンを識別し、潜在的なデバッグ戦略を予測したり、最適化を推測したりできます。これは特に、ユーザーが同じコンテキストに対して複数の質問をする場合に役立ちます。
彼らはさらに進んで、スリープタイム・コンピュートのコストを償却し、クエリあたりの総平均コストを削減できると述べています。彼らが発見したのは、ほとんどの場合、スリープタイム・コンピュートは5倍少ないリソースを使用して、テストタイム・コンピュートの品質に匹敵するか、それを上回ることができるということでした。
また、スリープタイム・コンピュートをスケールアップできることも発見しました。スリープタイムでより多くの計算を行うほど、結果が向上し、テストした2つの異なるベンチマークで13%と18%の結果改善を達成しました。また、複数のクエリに対してスリープタイム・コンピュートを償却することで（基本的に一度前処理を行い、その前処理されたコンテキストを複数のクエリで使用できるようにすることで）、質問あたりの平均コストを2.5倍削減することができました。
すべてが完璧というわけではなく、テストタイム・コンピュートがまだ優れているケースがいくつかあります。これについては後で説明します。
彼らが使用したベンチマークについて説明しましょう。2つの異なるベンチマークを使用し、それらを現在のステートレスからステートフルベンチマークに変換しました。ステートレスベンチマークでは、ユーザーはLLMにクエリを提供します。前述のジャグラーの例を再び見てみましょう。「マークの付いたインディゴ色のテニスボールの数はいくつですか？」という質問も含まれています。
通常はベンチマークとなるこれを、コンテキスト（ジャグラーに関する情報）とクエリ（「マークの付いたインディゴ色のテニスボールの数はいくつですか？」）に分けることができます。AIにクエリを与える前に、コンテキストに対する処理を開始できます。
彼らがテストしたモデルは、推論モデル（テストタイム・コンピュートモデル）と非推論モデルの両方です。推論モデルには01、03 mini、Claude 3.7 Sonnet（拡張思考）、DeepSeek R1があり、非推論モデルにはGPT-4o miniとGPT-4oがあります。
いくつかの結果を見てみましょう。ここには2つの異なるグラフがあります。P1バージョンとP2バージョンです。P1は簡単な質問、P2はより難しい質問です。より少ない計算とより多くの計算と考えることができます。これはGPT-4o miniとGPT-4oに関するものです。
まず、ここにあるグレーの点線であるベースラインから始めましょう。これはスリープタイム・コンピュートを使用していないGPT-4o miniです。y軸には精度があり、高いほど良いです。x軸には質問あたりの平均テストタイムトークンがあります。質問に答えるためにテスト時に必要なトークン数です。高いからといって必ずしも悪いというわけではありませんが、より費用がかかることを意味します。
まず、モデルがより多く考えるほど、結果が向上することがわかります。テストタイム・コンピュートが素晴らしいことは知っていましたが、スリープタイム・コンピュートを追加するとどうなるかを見てみましょう。出力により少ないトークンが必要な質問の場合、大幅な向上が見られます。しかし、応答により多くのトークンが使用されると、最終的にテストタイム・コンピュートの方がより良いパフォーマンスを発揮し始めることがわかります。
GPT-4oも本質的に同じカーブを示しています。そして、右側のより難しい質問でも同じ傾向が見られます。しかし、思考期間中に使用する計算量を直接制御できない非推論モデルでどのようにこれをテストしたのでしょうか？
非推論モデル（GPT-4oとGPT-4o mini）では、テストタイム・コンピュートの量を変えるために、モデルにテスト時に異なる詳細さを使用するよう指示するプロンプトを構築しました。例えば、「単一の文で直接答える」対「最終的な答えを出力する前にあなたの推論をダブルチェックしてください」などです。Chain of Thought（思考連鎖）は、推論モデルに直接組み込まれる前は、単なるプロンプト戦略だったことを覚えておいてください。
前述のように、より低いテスト時間予算では、スリープタイム・コンピュートのパフォーマンスはベースラインよりも大幅に優れており、5倍少ない計算トークンでベースラインに匹敵するパフォーマンスを達成しています。
推論モデルについてはどうでしょうか？結果は基本的に同じことがわかりました。モデルの思考が少ないほど、スリープタイム・コンピュートの方が大幅に優れています。より簡単な質問に対しては、スリープタイム・コンピュートははるかに優れており、はるかに安価ですが、モデルが考え続けるようになると、全体的にはより良いパフォーマンスを発揮しますが、その思考には大きなコストがかかります。文字通りのコストで、GPUが稼働し、お金がかかります。また、これはGPUが稼働する最も高コストな時間（テスト時）に稼働するため、よりコストがかかります。
ここでは03 Miniの場合、約6,000トークンの思考時間まで精度が大幅に向上しています。Claude 3.7 Sonnetも同様に、約20,000以上のトークンの思考時間まで精度が大幅に向上しています。DeepSeek R1も01も同様の傾向を示しました。
つまり、コストに関係なく最高のパフォーマンスを得ようとするなら、テストタイム・コンピュートを増やすことが最善の方法です。しかし、コストが要因になる場合や、非常に難しい数学問題やコーディング問題を解決しようとしていない場合、スリープタイム・コンピュートは実際に非常に優れています。
モデルが回答を提供する前の推論時間であるテストタイム・コンピュートについてよく話していますが、あまり話題にならないもう一つのアプローチがあります。それは並列サンプリングです。これは基本的に、質問やプロンプトに対して複数の応答、複数の潜在的な回答をモデルに求め、その中から最良のものを選択することを意味します。しかし、並列サンプリングには大きな問題があります。どれが最良の回答なのかをどうやって知るのでしょうか？
複数の回答の中からどれを選べばよいかを知る方法がわかっているという大きな仮定があり、それがテストタイム・コンピュートほど人気がない理由です。しかし、実際には多くの場合、そうではありません。それを念頭に置いて、次の内容を聞いてください。すべてのタスクとモデルにおいて、スリープタイム・コンピュートは同じテストタイムトークン予算でパス@K（並列処理）を一貫して上回っています。これは、スリープタイム・コンピュートが標準的な並列テストタイム・スケーリングよりも推論時間計算をスケールするためのより効果的な方法であることを示しています。
しかし、質問さえしていない時にモデルに理解させるこのスリープタイム前処理は、どれだけスケールアップできるのでしょうか？彼らがこれをテストした方法は、本質的にこのスリープタイム・コンピュート中の前処理予算をスケールアップすることです。推論モデルでは、01と03 miniに対してスリープタイム・コンピュートプロンプトを適用する際の推論努力の量を変えることによって、スリープタイム・コンピュートの量をスケールアップします。
このベンチマークでスリープタイム・コンピュートをスケールアップすると、パフォーマンスが外側にシフトし、同様のテストタイム予算で13%向上します。つまり、モデルに実際にクエリする際の思考量は同じですが、より多くの前処理を行うことで、はるかに良いパフォーマンスを発揮することができます。より複雑なコンテキストを持つタスクでは、追加のスリープタイム・コンピュートが有益になる可能性があります。
実際にはこのようになります。こちらは低努力のスリープタイム・コンピュート、中程度の努力のスリープタイム・コンピュート、そしてここに高努力のスリープタイム・コンピュートがあります。スリープタイム中の前処理により多くの時間を与えるほど、精度が向上します。
複数のクエリに対してスリープタイム・コンピュートを償却することについて話しましたが、基本的な用語で説明させてください。前処理を一度行い、テストタイム・コンピュートが毎回行う必要があるように、再度前処理することなく、その前処理されたコンテキストに対して複数回クエリを実行できます。
これが重要な点であり、なぜスリープタイム・コンピュートがそのような重要なブレークスルーとなる可能性があるのかという理由です。レイテンシ最適化された推論は、大まかに言って10倍も高価になる可能性があります。つまり、実際にモデルにクエリを実行し、他の全員も同時にモデルにクエリを実行しようとしている場合、そのサーバー内で稼働しているGPUの推論コストはこれまでで最も高価になります。そのときが最も需要が高く、供給が最も低い時です。
そこで彼らは、スリープタイムとテストタイム・コンピュートの間のトレードオフが実際のドルではどのようになるかを理解しようとしました。テストタイムトークンのコストを上げてみました。なぜならテストタイムトークンの方がより高価だからです。また、コンテキストに基づいて質問が予測可能であればあるほど、スリープタイム・コンピュートの方がうまく機能することもわかりました。
これは、スリープタイム・コンピュートの大きな仮定がコンテキストがコンテキストに対して問われる質問に影響を与えるということだからです。このジャグラーの例を再度見てみましょう。コンテキストがボールの数、テニスボールの数、インディゴ色のボールの数、マークが付いたボールの数について話しているなら、おそらくそれらのボールについて質問されるでしょう。もし突然、海について質問したとしたら、その前処理はその質問にまったく役立たなかったでしょう。
彼らが発見したのは「スリープタイム・コンピュートは、クエリがコンテキストからより予測可能な設定で最も効果的かもしれないと仮説を立てた」ということで、それが実際に正しいかどうかを確認しようとしました。彼らが発見したのは次のとおりです。
x軸を上に移動するにつれて、コンテキストに基づく質問の予測可能性が高まり、y軸では精度を見ています。質問が予測可能になればなるほど、スリープタイム・コンピュートを使用した精度が向上します。基本的にこちらでも同じことが見られます。ただし、より難しい質問であるP2では、スリープタイム・コンピュートのパフォーマンス向上はあまり明確ではなくなります。
総合すると、調査結果はどうでしょうか？スリープタイム・コンピュートはいくつかのケースでかなりうまく機能します。クエリが予測困難であったり、コンテキストと無関係である設定では、スリープタイム・コンピュートの効果は低くなります。これは理にかなっています。質問さえ知らない前に前処理をすべて行い、その後、質問が前処理したものとまったく関係がない場合、行った作業はまったく意味がありません。
彼らは実際に「将来の研究の興味深い方向性として、予測可能な質問を持つ可能性のあるコンテキストを特定し、最終的には異なるコンテキストとクエリ間でスリープタイムとテストタイム間の推論計算を配分すること」と述べています。この動画で直接取り上げなかった他の興味深い発見もたくさんあります。ぜひこの論文をチェックしてみてください。下にリンクを貼っておきます。
ちなみに、もっと研究論文の解説を見たい場合は、ぜひ私たちのニュースレターforwardfuture.aiをチェックしてください。素晴らしいオリジナルコンテンツ、ニュースのまとめ、研究論文の解説、インタビューなど、forwardfuture.aiをぜひお勧めします。
この動画を楽しんでいただけたなら、ぜひ「いいね」と「登録」をお願いします。
コメント