拡散LLM Mercury 2.5は、コード補完をどこまで速くするか。

gen
gen

@gennnn 28本

サムネイル

毎秒1,107トークン。

Inception Labsが2026年9月に出した拡散LLM Mercury 2.5の、公称の出力スループットです。

エディタのコード補完をこれに差し替えたら爆速になるんじゃないかと思って中を追いかけたんですが、出てきた数字はむしろ逆でした。

毎秒1107トークンのMercury 2.5は、コード補完も速いのか。

公称スペックが強気です。

出力スループットが毎秒1,107トークン、コンテキストは26万トークン、知能は前世代のMercury 2から40%向上。

Inceptionは同クラスの比較対象として、GPT-5.6 Luna(Low)、Gemini 3.5 Flash-Lite、Claude Haiku 4.5を挙げています。

価格も強気で、今はローンチ割引が効いています。

100万入力トークンあたり約6円、100万出力トークンあたり約23円。

割引前が入力約30円、出力約113円なので8割引です(1ドル150円換算)。

叩き口はInception API、Baseten、OpenRouterの3つ。

Inception APIはOpenAI互換なので、base_urlを https://api.inceptionlabs.ai/v1 に、モデル名を mercury-2.5 に変えるだけで、手元のOpenAI SDKがそのまま通ります。

ここまで見ると、補完のバックエンドを乗り換えない理由がない気分になります。

ただ、コード補完で効く速さと、毎秒1,107トークンという速さは、測っているものが違います。

拡散LLMはなぜ速いのか。1文字ずつ書かない生成方式の中身

自己回帰型が1トークンずつしか進めない理由

GPTもClaudeも生成方式は自己回帰型です。

すでに出した文字列を毎回入力に戻して、次の1トークンを予測する。

これを最後まで繰り返します。

つまり出力が100トークンなら、モデルの前向き計算が100回走る。

前の1文字が確定しないと次の1文字を計算できないので、原理的に並列化できません。

AIの返答がタイプライターみたいに左から流れてくるあの挙動、演出じゃなくて計算構造そのものです。

拡散型は「下書き全体」を並列で直していく

拡散モデルは、この順番を捨てます。

最初にノイズだらけの雑な下書きを出力全体ぶん一気に置いて、それを何ステップかかけて全体同時に洗練していく。

画像生成の拡散モデルが砂嵐から絵を浮かび上がらせるのと同じ考え方を、テキストに持ち込んだものです。

こうすると100トークン出すのに前向き計算が100回いりません。

数十ステップの洗練で全体が仕上がるので、トークンあたりの計算回数が桁で減ります。

毎秒1,107トークンという数字は、この構造から出ています。

Mercury 2.5のレイテンシは、最初の1文字までがいちばん遅い

ここが面白いところです。

公開されている第三者のレイテンシ計測を並べると、Mercury 2.5は最初の1トークンが返るまでの時間が、全条件で最下位でした。

モデル
短い回答
JSON出力
600語の長文
Mercury 2.5
約1.0秒
約1.1秒
約5.3秒
Mercury 2
約0.4秒
約0.6秒
約0.6秒
Claude Haiku 4.5
約0.6秒
約0.6秒
約0.6秒
Gemini 3.5 Flash-Lite
約0.6秒
約0.6秒
約0.6秒

長文で5.3秒。

他が軒並み0.6秒前後で最初の文字を返しているところに、ひとりだけ桁の違う待ち時間が乗っています。

なんでこうなるかは、さっきの仕組みを思い出すと腹落ちします。

拡散型は出力全体の下書きを仕上げてから吐き出すので、最初の1文字が出るまでの時間が、ほぼ全部書き終わるまでの時間なんです。

書き始めてからは確かに爆速で、同じ計測で毎秒1,241トークン出ています(同条件のClaude Haiku 4.5は84トークン)。

でもそれは、完成品をまとめてダンプしている速さです。

リクエスト全体で均した実効レートを見ると数字はもっと素直で、Mercury 2.5は毎秒106トークン。

Mercury 2が364トークン、Gemini 3.5 Flash-Liteが214トークン、Claude Haiku 4.5が78トークンなので、全体で見れば速い部類ですらありません。

そしてコード補完で人間が体感するのは、まさにこの最初の1文字までの時間です。

カーソルを止めてからゴーストテキストが出るまで1秒待たされたら、補完としては使い物になりません。

手のほうが先に進みます。

コード補完用のモデルは、Mercury 2.5とは別に立っていました

補完専用のmercury-edit-2とFIMエンドポイント

公式ドキュメントのモデル表を上から下まで見ていて気づいたんですが、Inceptionは補完を mercury-2.5 にやらせるつもりがありません。

別モデルと別エンドポイントが立っています。

モデルID
用途
コンテキスト
エンドポイント
mercury-2.5
チャット、エージェント、構造化出力
26万
v1/chat/completions
mercury-edit-2
補完(FIM)と次の編集の予測
3万2000
v1/fim/completions と v1/edit/completions

FIMはfill-in-the-middleの略です。

カーソルより前のコードを prompt、後ろのコードを suffix として渡すと、間に入るべきコードだけが返ってくる。

ドキュメントにも、ユーザーがタイプしている最中のインライン補完に最も向く、と明記されています。

コンテキストが26万から3万2000に落ちているのがポイントで、これは劣化じゃなくて設計です。

拡散型のレイテンシは出力全体を仕上げる時間で決まるので、扱う窓と出力を小さく切るほど最初の応答が速くなる。

数行返せばいい補完なら、下書き1枚を仕上げるコストが小さく収まります。

Mercury Edit 2側の公称は、前バージョン比で提案の受け入れ率が48%向上、提案を出す基準は27%厳しくなった、というもの。

価格は100万入力トークンあたり約38円、出力約113円で、キャッシュに当たった入力は約4円まで落ちます。

Zedとの統合とProxyAI経由でも使えます。

2025年のMercury Coderは、今のモデル一覧に載っていません

これ、わりと罠なので先に書いておきます。

検索すると「Mercury Coder」というコード特化モデルが出てきますが、これは2025年に出た世代で、現在のInception公式のモデルページにもドキュメントのモデル表にも載っていません。

「拡散LLM コード補完」で検索すると当時の記事がまだ普通に上位に来るので、そこに書いてあるモデル名をそのままコピーして貼ることになります。

今叩くのは mercury-2.5mercury-edit-2 の2つ、と思っておくと余計な時間を溶かさずに済みます。

Mercury 2.5を、自分の開発フローのどこに置くか。

補完のバックエンドにMercury 2.5を直接指すのは、今のところ筋が悪いです。

そこは mercury-edit-2 の担当で、Inception自身がそう切り分けています。

じゃあMercury 2.5が微妙なのかというと逆で、公表されている事例は「出力が長くて、人間が1文字目を待っていない処理」にきれいに寄っています。

Augment Codeがコンテキスト圧縮に使っている例では、約150秒から27秒へ82%短縮。

ここまで長い処理だと最初の1秒は丸ごと誤差になるので、拡散型のスループットがそのまま効きます。

置き場所として素直なのは、エージェントが裏で回す長い要約、大量のリファクタ差分の生成、バッチのコード変換あたり。

人間が画面の前で1文字目を待っている経路からは外す、という切り分けです。

試すハードルはかなり低くて、APIには1億トークンの無料枠が付いています。

OpenRouterのモデルページからIDをコピーして、いつも投げているプロンプトのモデル名だけ差し替えれば、5分で自分のネットワーク込みのレイテンシが出ます。

公称値と体感のズレは、1回自分の環境で測ると一発で腹に落ちます。