Mercury 2は、Inception Labsが開発した拡散型言語モデルであり、従来のトランスフォーマーベースのモデルとは根本的に異なるアプローチを採用している。最大の特徴は、テキストを1トークンずつ順次生成するのではなく、画像生成の拡散モデルのように全体を反復的に洗練させていく点にある。この設計により、応答速度が劇的に向上し、ツール呼び出しやエージェント型ワークフローにおけるレイテンシの課題を解決する。Focus AI MCPベンチマークでは15問中15問正解を8.6秒で達成し、コストはわずか0.6セントという驚異的な結果を記録した。Inceptionは単発の実験ではなく、Mercury Edit 2というコーディング支援モデルも投入し、プロダクトラインとして展開を進めている。これは「どのモデルが最も賢いか」ではなく「どのアーキテクチャが実用レベルの速度と価格で十分な品質を提供できるか」という問いへのパラダイムシフトを示唆するものである。
Mercury 2とは何か
このモデルのこと、おそらく聞いたことないですよね。まず見てください。第一に、驚くほど速いんです。第二に、トランスフォーマーではありません。第三に、先ほど言ったように、おそらく聞いたことがないはずです。そして第四に、質問への応答プロセスが文字通りエレガントで美しいんです。モデルに質問することがこれほど美的な体験になるなんて、誰が想像したでしょうか。
さて、このモデルは一体何なのか。こんにちは、Kenyaです。ここはAttention Spentというチャンネルで、AIの新しいトピックの中で十分な注目を集めていないものについて、分かりやすい解説をお届けしています。そして今日お話しするのはMercuryです。惑星の方ではありませんよ。
驚異的なベンチマーク結果
最近、夫がOpen Routerで高ランクのモデルをテストしていたんですが、これまでほとんど気づかなかったあるモデルが突然、Focus AI MCPの評価で15問中15問正解を記録し、8.6秒で完了し、コストはわずか0.6セントだったんです。最初はこれ、どこからともなく現れてはまた沼地に消えていくような、ベンチマークのサプライズかなと思いました。私たち、沼地沿いの道に住んでいるんですけどね。
でも違ったんです。Mercury 2が2月にローンチされて以来、このモデルを作ったInceptionという会社は、Pinchbenchで2つ目のパフォーマンスストーリーを公開しました。そして3月30日、つい最近ですが、Mercury Edit 2を発表したんです。これはコーディングワークフローにおける次編集予測のための拡散モデルなんです。
プロダクトラインとしての展開
これはもう、単発のスタントではなく、プロダクトラインであり、レイテンシに敏感なAIがどこに向かっているのかという理論のように見え始めています。でも待ってください、基本的な質問から始めましょう。Mercury 2とは正確には何で、なぜ私たちが慣れ親しんでいるモデルとこれほど違う振る舞いをするのでしょうか。
Mercury 2はInception Labsから生まれたもので、同社は今、Mercuryを本番環境向けに構築された拡散言語モデルのファミリーとして位置づけようとしています。Mercury 2は、128,000トークンのコンテキストウィンドウ、ツール呼び出し、構造化出力、そしてOpenAI互換APIを備えたチャットモデルとして提示されています。その隣にはMercury Editというコーディングモデルがあり、fill in the middle、apply edit、next edit機能を持っています。
このプロダクトの表面を見れば、Inception Labsがどんな賭けをしているかが分かります。Inceptionは単に変わったモデルを作りたかったわけではありません。彼らが示そうとしているのは、異なるアーキテクチャが、レイテンシが多数の呼び出しにわたって積み重なり、実際に製品ができることを形作り始めるようなワークロードに、より適している可能性があるということなんです。
Focus AIベンチマークの意義
だからこそ、Focus AIの結果に注目する価値があるんです。これはおもちゃのベンチマークではありませんでした。モデルが準備できるようなベンチマークでもありませんでした。プロンプトを見てください。「私の実データを見て、2026年2月27日から3月8日までの10日間のRavenの活動を要約してください。注目すべき移動があれば、その期間のナラティブを作成してください。今日は2026年3月8日です。必ず10日間全体を含めるようにしてください」。
つまり、2月にドライブや充電がなければ、明らかに間違っているということです。39のモデルが、get drivesやget chargesといったものを含む20以上の実際のMCPツールにアクセスでき、プロンプトには罠が仕込まれていました。もしモデルが開始日を渡すのを忘れたら、最近の3月のデータしか見られず、そうすると自信満々に間違った話を語ることになります。
いくつかのかなり有名なモデルがまさにそれをやってしまいました。間違った話を。でもMercury 2は違いました。ツールも正しく使い、日付も正しく、話も正しく、しかもとても速く、とても安価にやってのけたんです。
トークンごとの生成がもたらす制約
なぜそれが重要なのかを理解するには、一歩下がって、ほぼLLM時代全体を形作ってきた設計習慣を見る必要があります。ほとんどの言語モデルは、テキストを順次、1トークンずつ生成します。この設定は驚くほどうまく機能し、私たちが今毎日使っている自己回帰型LLMの波全体を動かしてきました。
しかし、モデルがデモから実際のシステムへ移行すると、はるかに気づきやすくなる制約も伴います。それは、すべてのトークンがレイテンシを追加するということです。そして、より大きなワークフロー内でモデル呼び出しをスタックし始めると、そのレイテンシは複合的になります。
現代のAIシステムは、ますますパイプラインのように動作しています。あるシステムは文書を取得し、要約し、ツールを呼び出し、結果について推論し、そしてようやく答えを生成するかもしれません。エージェントはツールを選択し、外部情報を取得し、それを解釈し、次のステップを踏むかもしれません。これらすべてのケースで、遅延はもはや1つのモデル応答から来るものではありません。多くの生成ステップが互いに積み重なることから来るんです。レイテンシとして。
そして、それこそがMercuryが狙っているボトルネックなんです。
拡散モデルとしてのアプローチ
Mercuryは通常の左から右へのやり方でテキストを生成しません。代わりに、応答の粗いドラフトのようなものから始めて、それを反復的に洗練させていきます。インスピレーションは拡散モデルから来ています。
画像生成では、拡散モデルはノイズから始まり、全体を洗練させることで徐々にそれを一貫した画像に変えていきます。実際、魔法のように見えます。そしてMercuryはその基本的なアイデアをテキストに適用しています。だからこそ、こんなに美しく見えるんです。
1トークンずつコミットする代わりに、複数のトークンを一度に扱い、シーケンスが安定するまで洗練し続けます。最もシンプルな想像の仕方はこうです。従来のLMはタイプライターのように振る舞います。Mercuryはより編集者のように振る舞うんです。あなたがそこに書いたものを見てみましょうって感じです。
だからこそ、モデルが違って感じられるんです。単に速いだけではありません。答えが異なる質感で到着するように思えるんです。同社のベンチマーク条件下では、Mercury 2は約1,090トークン/秒と報告されています。だからこそ、ストリーミングというよりは到着のように感じられるんです。
公開情報の限界と明確な方向性
まだすべての内部詳細を持っているわけではなく、ここでは慎重になる価値があります。なぜなら、完全な公開システムカードも、正確なトレーニングレシピも、パラメータ数もないからです。しかし、アーキテクチャの賭けは十分明確です。Mercuryは、トークンごとの生成という構造的コストを削減しようとしているんです。
もしMercuryが単に速いだけだったら、単に速い好奇心だったら、興味深いでしょうが、忘れやすいでしょう。それを無視しにくくしているのは、Inceptionがその周りでより広範なケースを構築し始めたことなんです。
2月のローンチ以来、同社は先ほど言ったようにPinchbenchで2つ目の公開パフォーマンストーリーを追加しました。そこでは78%の成功率、そのクラスで最速の実行時間、そして100万トークンあたり1ドル未満の価格設定を主張しています。ちょっと考えてみてください。100万トークンあたり1ドルですよ。
ほぼ同時期に、MercuryはAzure、Microsoft、AWS Pathwaysを通じたデプロイメントのために位置づけられていて、公式のフレーミングは、モデルが勝つべき場所についてより明示的になりました。検索、RAG、音声、コーディング、そしてエージェントループです。
Mercury Edit 2の登場
Mercury Edit 2のローンチはその議論を強化しています。これは、次編集予測とコーディングワークフローのために構築された拡散モデルで、想像できる最もレイテンシに敏感なカテゴリの1つです。なぜなら、提案は開発者のフローの中で到着しなければならず、その瞬間がすでに過ぎ去った後ではだめだからです。
Inception Labsによれば、新バージョンの編集は以前のものより48%多く受け入れられ、表示する内容において27%より選択的になっているそうです。つまり、より速く、同時により有用になろうとしているということです。
いくつかの誤解を解く
さて、いつものように、いくつかの誤解を解いておきましょう。これは、拡散モデルがトランスフォーマーベースの通常のLMを置き換えようとしているという意味ではありません。自己回帰モデルは依然としてフロンティアの多くを支配しており、それらを取り巻くエコシステム全体が何年にもわたって最適化されてきました。
Mercuryにも、内部に関する重要な公開情報のギャップがまだあり、独立したベンチマークカバレッジは比較的薄いままです。ですから、ここでの正しい反応は「これがすべてを変える」でも「これは何でもない」でもありません。
正しい反応は注目することです。なぜなら、Mercuryはすでに、あまりにも馴染み深くなって気づかなくなっていた前提を、この分野に再検討させているからです。言語モデルは答えを1トークンずつ明らかにしなければならないという考え方です。
新しい評価軸の登場
そして、より多くのシステムがリアルタイムのインタラクション、ツールループ、コーディング支援、継続的なバックグラウンド推論を気にかけ始めたら、質問がシフトし始めます。もはや抽象的にどのモデルが最も賢いかだけではなくなります。
どのアーキテクチャが、実際の製品が実際に許容できる速度と価格で、十分な品質を提供できるかという質問になるんです。
だからこそ、Mercuryは注目する価値があるんです。今日一緒にいてくれてありがとうございます。皆さんの考えを聞きたいですし、もしMercuryを自分で試したことがあれば教えてください。シェア、いいね、チャンネル登録をお願いします。それではまたすぐにお会いしましょう。
コメント