【geek-terminalニュース】拡散LLM「Mercury 3」が毎秒1,000トークン超を主張、自己回帰の牙城は崩れるか

【事象の全貌と背景】

2026年10月19日前後、Inception社が商用拡散型LLM「Mercury 3」を公開したと報じられています。MarkTechPostとThe Decoderが取り上げており、The Decoderの見出しは「GPT-6 LunaとClaude Haiku 5.5を上回ると主張(claims)」という書きぶりです。まず断っておくと、今回の調査では両記事の本文を取得できていません。以下の数値や比較は、主にHacker Newsに投稿されたInception共同創業者でChief Scientistのvolodia氏の告知に基づく、同社側の主張です。編集部の指示にある「1068tok/s」という具体値も、今回の材料では確認できませんでした。告知で確認できたのは「1,000+ tokens per second」までです。真偽のほどは定かではありませんので、その前提でお読みください。

背景にあるのは、LLMの推論速度をめぐる長年の課題です。現在の主流である自己回帰モデルは、トークンを1個ずつ順番に生成します。そのため、推論モデルが長く考えるほど待ち時間が増えます。この壁に対して業界は、投機的デコードなど「自己回帰を保ったまま速くする」路線で戦ってきました。これに対し拡散LLMは、生成方式そのものを変える路線です。弊チャンネルでも過去にDMaxやDiffusionGemmaを扱いましたが、今回は「商用サービスとして出てきた」点が新しい論点になります。

【技術的ディープダイブ】

volodia氏の告知によると、Mercury 3の主張は次のとおりです。

・品質: 同じ推論エフォート設定で、GPT-6 LunaとClaude Haiku 5.5を複数のベンチマークで上回る
・速度: 広く入手できるNVIDIA Blackwell GPU上で毎秒1,000トークン超、上記モデルの4〜8倍
・コンテキスト: 1Mトークン(従来は260K)
・価格: 入力100万トークンあたり0.10ドル、出力100万トークンあたり0.35ドル(ローンチ時)
・提供形態: OpenAI API互換で、OpenRouter、Baseten、Vercelでも利用可能

同氏はさらに「拡散はスケールする」と強調しています。Mercury 1以降で総パラメータを40倍以上に拡大し、速度を犠牲にせず知能が上がり続けたそうです。理屈としては、拡散モデルは反復的なデノイジングで複数トークンを並列に生成します。そのため、推論モデルが1回答あたり長く考えるほど、同サイズの自己回帰モデルに対する速度優位が広がるという主張です。

ここまでは発表側の言い分ですが、周辺の学術情報で裏が取れる部分もあります。arXivのPV-Decoding論文は、近年の拡散言語モデルが離散的なデノイジングで競争力のある言語生成を支え、自己回帰型より豊富な並列性を提供すると述べています。先行研究としてInception Labsにも言及があります。一方、別のarXiv論文(Self-Decomposing Diffusion for Code Generation)は、拡散モデルがフロンティア級の自己回帰モデルにはまだ及んでいないと明記しています。同論文によれば、Gemini DiffusionやMercury 2.5、Seed Diffusion Previewといった高性能な拡散システムは重みを公開していません。さらに同論文は、並列デコードが正確になるのは、同時に確定するトークンが「すでに判明した情報を条件にほぼ独立」な場合に限ると指摘しています。この独立性が崩れると精度が落ちるため、コード生成のように依存関係の強い領域は構造的に難しいはずです。Mercury 3がこの壁をどう越えたのか、現時点では公開情報から判断できません。

【コミュニティの生々しい熱量と議論】

取得できたコミュニティの声はHacker Newsのスレッド1本のみで、Redditやlobste.rsの発言は含まれていません。罵倒や否定一辺倒のコメントもなく、全体として冷静な技術的突っ込みが中心でした。

最も具体的だったのがttul氏の指摘です。DeepSWEのスコアがMercury 3は46%で、Haikuの52%を下回る点について、コーディング向けのRL後学習が弱いのではと尋ねています。ただし「批判ではなく、これでも驚異的」と断ったうえで、「信頼できるなら毎秒1,000トークンの安価な選択肢は夢だ」と語っています。セキュリティレビューや細かい反復リファクタリングのような、最先端性能までは要らない作業を一気に片付けたいという期待です。

これに対しvolodia氏は、6ポイント差の理由は正確には説明できないと率直に認めました。そのうえで、自社の日常利用ではHaikuやLunaと同水準という体感を示しています。位置づけは、OpusやFableのような上位モデルに取って代わってハーネスの主役を張るものではなく、サブエージェント向けだと言います。大型モデルが出したカーネル最適化案を実装させ、その改善が本番投入された事例も紹介しており、同氏はこれを一種のRSI(再帰的自己改善)と呼んでいます。この事例は本人の証言にとどまり、独立した確認はありません。

AmazingTurtle氏は、総パラメータ数、重みの公開、ハーネス統合、ツール呼び出しの出来、ステップごとの固定待ち時間の有無を質問しました。回答は「重みは公開しない。標準APIで提供し、好みのハーネスに統合できる。Cursorでも数ステップで動かせる。ただしOpus級の性能はまだ期待しないでほしい」というものでした。パラメータ数への明確な回答は、取得範囲では確認できませんでした。

LarsDu88氏は最も本質的な疑問を出しています。Googleの研究では、H100上で大バッチサイズになると拡散型の速度メリットが落ちる傾向が示されたそうです。Mercury 3のバッチサイズ別トークン毎秒の公開値はあるのか、という質問です。volodia氏の返信は途中で切れており、回答は確認できませんでした。毎秒1,000トークン超という数字が、どのバッチサイズで測られたのかは重要な未確認事項です。

【今後の展望とエコシステムへの影響】

現時点で言えるのは、拡散LLMは「全面的な自己回帰の置き換え」ではなく、「低レイテンシが効く用途の特化枠」として先に実用域へ入りつつあるように見える、という点です。発表側もスレッド上の反応も、主力モデルではなくサブエージェントという位置づけで一致していました。大型モデルが計画を立て、高速で安価な拡散モデルが実装や検索、顧客対応の下回りを大量にさばく分業が、最も現実的な使われ方でしょう。早期パートナーはブラウザエージェント、家庭教師アプリ、リアルタイム検索、カスタマーサポートで試用していると言われています。

一方で、見極めるべき点は明確です。第一に、速度の測定条件(ハードウェア、バッチサイズ、対象モデル)が独立に再現されるか。第二に、「GPT-6 LunaやHaiku 5.5を上回る」という比較が、どのベンチマークと推論エフォートで成り立つのか。第三に、重み非公開のため、研究コミュニティが検証や改良をしにくい点です。arXivの論文が指摘するとおり大規模なオープン拡散コードモデルは依然少なく、APIでしか触れない状況が続きます。

投機的デコード競争との関係で言えば、これは代替ではなく併走の路線です。自己回帰が「速くする工夫」を積み重ねる一方、拡散は「並列に生成する方式」を磨いています。もし1Mコンテキストで低価格という条件が実運用で再現されれば、サブエージェント層では自己回帰の小型モデルの優位が揺らぐかもしれません。ただし、それは独立ベンチと実運用の報告が出そろってからの話です。現段階では、有望だが検証待ちの主張として追いかけるのが妥当でしょう。