Mercury 3はなぜ速い？複数トークンを並列生成する拡散型LLMの仕組み｜2026年10月27日版
LLMの返答を速くするには、文章の作り方そのものを変える手がある。Inceptionが10月19日に発表した「Mercury 3」は、複数のトークンを並列に生成する拡散型LLMだ。同社はNVIDIA GPU上で毎秒1,068トークンの生成速度を公表している。
注目点は、チャットの表示が速くなることだけではない。判断とツール操作を繰り返すAIエージェントでは、モデルを呼ぶたびに生じる待ち時間を減らせる可能性がある。ただし、生成速度と、依頼した仕事が終わるまでの時間は別々に測る必要がある。
2026年10月27日（日本時間）時点で確認できる公式発表と技術資料から、仕組みと導入時の見方を整理する。
- 技術の核心： 次のトークンを順番に出す代わりに、複数箇所を並列に更新する。
- 今回の進展： Mercury 3では、拡散型モデルの大規模化と高速生成の両立を打ち出した。
- 実務の焦点： 日本語の正確さ、ツール実行の成功率、処理全体の待ち時間を確認する。
Mercury 3で何が変わったのか
Inceptionは、Mercury 3を拡散型LLMの規模を拡大したモデルとして発表した。初代Mercuryに対して総パラメーター数を40倍超に増やしながら、高い生成速度を維持したという。
発表時の主な仕様は次の通りだ。
- 生成速度：NVIDIA GPU上で毎秒1,068トークン。
- コンテキスト長：100万トークン。
- 提供経路：InceptionのAPIプラットフォーム、OpenRouter、Baseten、Vercel。
これらはInceptionの公式発表に基づく。速度は同社公表値であり、日本からの接続や日本語の業務文書で同じ数値が出ることを保証するものではない。
重要なのは、拡散型LLMが高速な小型モデルにとどまるのか、より複雑な仕事にも広げられるのかという点だ。Mercury 3は、その問いに対してモデルの大規模化で答えようとする製品になる。
拡散型LLMは、文章をどう作るのか
違いは、出力を確定していく手順にある。
一般的な自己回帰型LLMは、すでにある入力と生成済みの文章をもとに、次のトークンを予測する。その結果を受けて、さらに次を予測する。文章を少しずつ伸ばす方式だ。
一方、Mercuryの技術報告では、ノイズを含む状態から出発し、複数のトークンを並列に更新しながら出力を整える方式を説明している。大まかな状態から、繰り返し修正して文章を仕上げていく。
「一度で全文完成」ではない
並列生成でも、計算が一回で終わるわけではない。複数箇所をまとめて改善する処理を繰り返す。
この方式では、一つずつ出力する場合よりもGPUの計算能力を活用しやすくなる。もっとも、並列に処理できるだけで自動的に高速になるわけではなく、推論エンジンの実装も効く。
Transformerと拡散は両立する
「拡散型」は、ニューラルネットワークの構造をすべて置き換えるという意味ではない。Mercuryの技術報告は、Transformerを使いながら、学習と生成の手順に拡散方式を採用していると説明する。
ネットワークの構造と、文章を生成する手順は別の設計要素なのだ。
なお、この仕組みの説明に用いた2025年6月公開の技術報告は、初期のMercury Coderを扱う資料である。Mercury 3固有の内部実装や性能を、そのまま示すものではない。
AIエージェントでは、どの待ち時間を減らせるか
速い文章生成が役立つ場面として、判断を何度も挟む処理がある。
例えば、業務システムのエージェントが次の順序で動くとする。
- ユーザーの依頼を読み、使うツールを選ぶ。
- ツールの結果を確認し、追加の処理を決める。
- 最終結果を文章にまとめる。
これは動作を説明するための例だ。各段階でモデルを呼び出すなら、その待ち時間が積み重なる。生成が処理の大きな割合を占める用途ほど、高速化の効果を得やすい。
ただし、外部データベースの応答やブラウザー操作が遅ければ、モデルだけ速くしても全体は大きく変わらない。また、速い回答でも判断を誤ってやり直しが増えれば、完了までに時間がかかる。
比較するときは、次の三つを分けたい。
- 応答開始までの時間： 最初の有用な返答が届くまで何秒かかるか。
- 生成中の速度： 出力が始まってから、どれだけ速く文章が増えるか。
- 仕事の完了時間： ツール操作や再試行を含め、正しい結果に到達するまで何秒かかるか。
毎秒のトークン数だけでは、利用者が感じる待ち時間までは判断できない。
API導入では、日本語と既存処理の相性を確かめる
InceptionはOpenAI互換APIを提供している。公式ドキュメントでは、ストリーミング、ツール利用、構造化出力などの機能を案内している。
既存のクライアントや開発ツールを使って試しやすい点は利点だ。ただし、APIの形式が近くても、同じプロンプトに同じ内容で答えるとは限らない。
日本の開発現場なら、まず用途を絞って比較すると判断しやすい。
- 日本語の問い合わせ対応： 敬語、製品名、社内用語を正しく扱えるか。
- データ抽出： 指定したJSON形式を守り、値も正しいか。
- ツール利用： 適切な関数を選び、引数を正しく渡せるか。
- 長文処理： 入力を増やしたとき、必要な根拠を拾えるか。
100万トークンを扱えることと、入力内の必要な情報を漏れなく使えることも別問題だ。導入判断では、既存モデルと同じ評価データを使い、速度と正答率を並べて確認したい。
継続ウォッチ：速度を業務の成果につなげられるか
Mercury 3で追うべきなのは、公表された高速生成が実際の処理でどこまで役立つかだ。
- 日本語の業務データでも、速さと正確さを両立できるか。
- 同時アクセスや長い入力で、応答時間がどう変わるか。
- ツール利用の失敗や再試行を含めても、仕事の完了が早まるか。
試すなら、まず一つの処理を選び、「成功した依頼1件あたりの所要時間と費用」を既存モデルと比べる。複数トークンの並列生成が実用上の強みになるかは、その数字に表れる。