【ITニュース解説】Mercury 2.5 and the 1,000+ tokens/sec era: what fast LLM output changes in agent and RAG design

大規模言語モデル（LLM）の進化は目覚ましいが、中でもその出力速度が劇的に向上しているというニュースは、システムエンジニアを目指す人にとって非常に興味深い進展だ。Inception社が開発した「Mercury 2.5」というモデルは、1秒間に1,000トークン以上という驚異的な速度でテキストを生成できると報じられている。これは、従来のLLMの動作原理や、それを利用したシステム（エージェントやRAGなど）の設計に大きな変化をもたらす可能性を秘めている。

まず、LLMの出力速度がなぜこれほど重要なのかを理解しよう。ほとんどのLLMは「自己回帰（autoregressive）」という方式で動作する。これは、一つ前の単語や文字（トークンと呼ぶ）に基づいて次のトークンを予測し、それを順番に生成していく仕組みだ。まるで一文字ずつ手書きで文章を書いていくようなもので、出力の長さが長くなればなるほど、それに比例して時間がかかる。しかし、Mercury 2.5のようなモデルは、このような逐次的な生成方法とは異なるアプローチをとっている可能性がある。記事では「拡散型モデル（diffusion-style language models）」に言及しており、これは複数のトークン位置を並行して、何度か繰り返し修正しながらテキストを生成する方式だと考えられる。これにより、一度に多くの情報を処理できるため、全体の生成ステップ数は減り、結果的に高速な出力が可能になるというわけだ。

ただし、高速な出力速度が、必ずしもシステム全体の迅速な動作を意味するわけではない点に注意が必要だ。速度を評価する際には、三つの異なる指標を区別して考える必要がある。一つ目は「最初のトークンまでの時間（TTFT：Time to First Token）」で、これはプロンプト（入力）を処理し始めてから最初の出力が生成されるまでの時間だ。二つ目は「出力トークン/秒（Output tokens/sec）」で、これは生成が始まってからの純粋な出力速度を指す。そして三つ目は「タスク全体にかかる時間（End-to-end task time）」で、これはLLMの生成だけでなく、データベースの検索、外部ツールの呼び出し、ネットワーク通信など、タスク完了までに必要な全ての工程を含む時間だ。たとえば、LLMが500トークンの回答を0.5秒で生成できたとしても、その前にデータベース検索に2秒、外部API呼び出しに1秒かかっていれば、タスク全体としては3.5秒以上かかることになる。この場合、LLMの生成速度だけを改善しても、全体のボトルネック（遅延の原因）は解消されない。システム全体のどこに時間がかかっているのかを正確に把握することが、性能改善の第一歩となる。

このような高速なLLMの出力は、特に「エージェント」の設計に大きな影響を与える。エージェントとは、LLMが思考し、計画を立て、ツールを使いながら複雑なタスクを段階的に実行していくシステムのことだ。例えば、ReActのようなエージェントは、現状認識、思考、行動、観察といったステップを繰り返すことで目標を達成する。一つのステップで300トークン程度の思考を8回繰り返すエージェントであれば、合計で2,400トークンを生成することになる。従来の速度では、これだけで数十秒かかっていた純粋な生成時間が、1,000トークン/秒のモデルなら数秒で完了するようになる。 この「思考の予算」が時間的に安くなることは、エージェント設計にいくつかの重要な変化をもたらす。例えば、これまでレイテンシ（遅延）を避けるために省略していたような、より詳細な計画立案、自己批判、生成結果の複数回の検証といったプロセスを実行できるようになる。また、「ベスト・オブ・N」と呼ばれる手法が実用的になる。これは、LLMに複数の候補案を生成させ、それらを評価器でチェックして最適なものを選ぶというものだ。並行して候補を生成し、高速に評価できるため、より堅牢な結果を得やすくなる。ユーザーインターフェース（UX）も大きく変わるだろう。テキストエディタやターミナルでエージェントを利用する際、その出力が瞬時に表示されるようになれば、人間とのインタラクションがよりスムーズで自然なものになる。ただし、重要な注意点もある。たとえモデルが高速でも、その「賢さ（Intelligence Index）」が不明であったり、品質が低ければ、誤ったツール呼び出しや不正確な推論を高速に実行するだけになってしまう。速いけれど間違った答えを出すモデルは、単に失敗が速くなるだけだ。そのため、新しいモデルを導入する際には、必ず自身のタスクでその品質を評価することが不可欠となる。

「RAG（Retrieval Augmented Generation）」と呼ばれるシステムにも、高速LLMは大きな変化をもたらす。RAGは、LLMが回答を生成する際に、外部の知識ベース（データベースなど）から関連情報を検索（Retrieval）し、それをもとに回答を生成（Generation）する技術だ。RAGでは、情報を埋め込み（embedding）して検索したり、検索結果を並び替えたり（reranking）、プロンプトを組み立てたりするプロセスが、LLMの生成よりも時間を要することが多い。 高速なLLMの登場により、これまでレイテンシのボトルネックになりがちだったプロセスをLLM自身に任せられるようになる。例えば、ユーザーの質問をLLMがより詳細なクエリに書き換えたり、複数の質問に展開したりする「クエリ書き換え」や「マルチクエリ展開」が、時間的な負担なしに実行できるようになる。また、検索で得られた多くの候補の中から、LLM自身が最適なものを再ランキング（reranker）する手法も現実的になる。大量の候補を高速に評価できるため、より質の高い情報を選び出すことが可能になる。さらに、生成された回答の各主張が、検索で得られた情報源と一致しているかを確認する「回答検証」も、非同期処理ではなく、リアルタイムに実行できるようになる。 Mercury 2.5が持つ260,000トークンという非常に長い「コンテキストウィンドウ」（一度に扱える情報の量）も注目に値する。これは、LLMに膨大な量の情報を一度に与えられることを意味し、単純な情報検索のステップを省略できる誘惑に駆られるかもしれない。しかし、コンテキストが長くなると入力トークン量が増え、コストも増える。また、一般的に長いコンテキストでは、LLMの性能が不安定になったり、関連性の低い情報に惑わされたりすることもあるため、その品質を注意深く評価する必要がある。システムプロンプトや静的な文書など、変化しない情報をコンテキストの冒頭に配置し、頻繁に変わる情報を後方に配置することで、キャッシュ割引（cache discount）などのコストメリットを最大限に活用できる可能性もある。

コストについても現実的に考える必要がある。100万出力トークンあたり0.75ドルという価格設定は、高速な生成と相まって、LLMを使った実験の自由度を大きく高めるだろう。しかし、生成速度が速いからといって、エージェントが10倍多くの推論ステップを実行するように設計すれば、それに比例して総コストも増大する。重要なのは、1回あたりの呼び出しコストではなく、「タスク成功あたりにかかるトークン数」を追跡し、最適化することだ。

最後に、利用する環境の制約も考慮する必要がある。Mercury 2.5のようなモデルは、プロプライエタリ（所有権のある）なホスト型モデルであり、通常はインターネット経由で提供される。もし、機密性の高いデータを社内ネットワークから外部に出せないという制約があるチームであれば、このようなホスト型モデルを直接利用することはできない。この場合でも、今回のニュースが示す「高速化によって設計が変わる」という示唆は非常に有用だ。モデルへのアクセスを抽象化されたインターフェースの背後に隠しておくことで、ホスト型モデルの性能リーダーと、自分たちのGPUで実行可能なオープンソースモデルの性能を、レイテンシと精度という観点から容易に比較検討できるようになる。リーダーボードの速度評価は、あくまで特定の環境での結果であり、自分たちの環境で同じ性能が出る保証はないため、実際に計測することが重要だ。

結論として、1,000トークン/秒を超える出力速度は、LLMの生成レイテンシがエージェントやRAGシステムのボトルネックではなくなりつつある明確な兆候だ。しかし、これはモデルの品質を保証するものではないため、必ず自身のタスクで品質を評価する必要がある。この新しい速度を最大限に活用するためには、システムのどこが本当に遅いのかを再評価し、これまでは時間的に難しかった検証や再ランキング、深い推論などに「解放された時間」を賢く使うことが求められる。そして、常にモデルを交換しやすい柔軟な設計を心がけることが、今後のLLMの進化に対応するための鍵となるだろう。