AIスタートアップのInceptionが、Diffusion技術を言語生成に応用した推論特化型LLM「Mercury 2」を正式公開した。NVIDIA Blackwell GPU上で毎秒約1,000トークンというスループットを達成しており、これは速度最適化モデルの中でも最速クラスとされる既存モデルの5倍以上に相当する数値だ。

なぜ「1トークンずつ」生成するのか——自己回帰型の構造的限界

現在市場に出回っているほぼすべての大規模言語モデル（LLM）は、自己回帰型（autoregressive）と呼ばれるアーキテクチャを採用している。これは文字通り「1トークンずつ順番に生成する」方式であり、GPT系、Claude系、Gemini系のいずれも根本的にはこの仕組みで動いている。

この方式の問題点は、生成速度が本質的にシリアル処理によって上限を設けられる点にある。OpenAI、Anthropic、Googleといった大手各社はここ数年、専用チップ・最適化されたサービングスタック・モデル圧縮技術を組み合わせてスループットを改善してきたが、いずれも「同じ1トークン生成ループをどう速くするか」という枠組みの中での改善に過ぎない。

Inceptionが採用した「拡散（Diffusion）モデル」アプローチ

Inceptionは、スタンフォード大学・UCLA・コーネル大学の研究者たちが創業したスタートアップで、拡散モデルの言語適用における商用化に特化している。画像・動画生成の分野でよく知られる拡散モデルの技術をテキスト生成に転用した「拡散型LLM（dLLM）」を開発しており、Mercury 2はその最新世代にあたる。

Mercury 2の動作原理は、自己回帰型とは根本的に異なる。まず出力全体の「大まかなスケッチ」を生成し、そこからノイズ除去（denoising）と呼ばれる反復的な精緻化プロセスを経て最終的なテキストを完成させる。この処理では複数のトークンを並列で洗練させるため、1回のニューラルネットワーク評価で処理できる有効な作業量が自己回帰型と比較して大幅に増える。

速度優位性が「専用ハードウェアではなくモデルの構造そのものに由来する」点も重要だ。特殊なインフラに頼らずとも並列処理によってスループットが向上するため、推論コストを抑えながらレイテンシを削減できるという構造になっている。

速度ベンチマーク：毎秒約1,000トークンの意味

Artificial Analysisの手法に準じた標準ベンチマークでは、Mercury 2はNVIDIA Blackwell GPU上で毎秒約1,000トークンのアウトプットスループットを達成している。比較として、Claude 4.5 Haikuの推論モードは毎秒約89トークン、GPT-5 Miniは約71トークンとされており、速度面での差は約11〜14倍に上る。

品質面では、Claude 4.5 HaikuやGPT-5 Miniと同等水準のベンチマーク結果を示しているとされており、「速さと品質のトレードオフがない」という訴求がなされている。

対象ユースケース：エージェントループ・リアルタイム音声・コーディング支援

Mercury 2が特に設計上の優位性を発揮するとされるのは以下のユースケースだ。

  • AIエージェントループ: 推論→実行→検証を繰り返すアーキテクチャでは、1ステップあたりのレイテンシが積み重なりやすい。毎秒1,000トークンの処理速度は、ループの反復を現実的な時間内に収めるための要件になりうる
  • リアルタイム音声・検索: 応答速度がユーザー体験を直接左右する用途
  • 大規模コーディング・編集支援: 長いコードベースに対して即座にフィードバックを返す用途

Mercury 2モデルはすでにInception APIを通じて提供が開始されており、エンタープライズ向けの本番ワークフローへの組み込みも想定されている。

実務への影響

エンジニアへの示唆

自律型AIエージェントをシステムに組み込む際、モデルの推論速度は実用上の制約になりやすい。ツール呼び出しの待ち時間、ループの反復コスト、ユーザーへの応答速度のいずれも、スループットが直接響いてくる。速度最適化されたモデルの選択肢が増えることは、エージェント設計の幅を広げる可能性がある。

IT管理者・意思決定者への示唆

推論コストは生成AIの運用において見過ごされがちだが、大量リクエストを処理するシステムでは積み重なりが大きい。コスト効率と速度を両立するモデルの選択肢として、既存の大手モデルとの比較検討に値する。ただしMercury 2は現時点でInception独自のAPIからの提供であり、AzureやAWS Bedrockのようなマネージドプラットフォームでの提供ではない。エンタープライズ採用を検討する際は、セキュリティ・コンプライアンス・サポート体制の確認が必要になる。

筆者の見解

AIエージェント設計に関わる立場から見ると、速度問題はずっと「解決待ちの構造的制約」だった。エージェントが自律的にループで動く設計——判断・実行・検証を繰り返すハーネスループ型のアーキテクチャ——では、1ステップのレイテンシが全体のスループットを支配する。この文脈で並列拡散型アプローチが本番グレードの推論品質を保ちながら速度を実現できるなら、エージェントアーキテクチャ設計の前提が変わってくる可能性がある。

ただし、ここで冷静に見ておきたい点もある。ベンチマーク数値は「NVIDIA Blackwell GPU上での計測」という特定条件付きであり、一般的なクラウド推論環境での再現性は別途確認が必要だ。また、品質面の「同等」がどの程度の一致率なのかは、実際のユースケースで試してみないとわからない。速度の数字だけに飛びつくのではなく、「自分の用途で何を最大化したいか」を整理した上で比較評価することをお勧めしたい。

Diffusion技術をテキストに適用するというアプローチは、アーキテクチャとして注目に値する方向性だ。自己回帰型が当たり前になりすぎた業界に、並列精緻化という別の道があることを示した点は素直に面白い。この領域の技術が今後どう成熟するか、引き続き追っていきたい。

出典: この記事は Inception Launches Mercury 2, the Fastest Reasoning LLM — 5x Faster Than Leading Speed-Optimized LLMs の内容をもとに、筆者の見解を加えて独自に執筆したものです。