本文へ
ハクソク

世界を動かす技術を、日本語で。

マーキュリー3:大規模な拡散

元記事: 原文(inceptionlabs.ai)

概要

  • Mercury 3 は、これまでで最も高性能な拡散型LLMとして登場
  • GPT-6 Luna や Claude Haiku 5.5 を超える性能と高速性を実現
  • 1,000トークン/秒超の速度で、コスト効率も大幅向上
  • 40倍以上のパラメータ拡張 により知能も大幅向上
  • さまざまなリアルタイムアプリケーションで既に実運用中

Mercury 3:最先端拡散型LLMの登場

  • Mercury 3 は、拡散型LLMとして最高水準の性能と速度を両立
  • 主なベンチマークで GPT-6 Luna や Claude Haiku 5.5 を上回る実力
  • 1,068トークン/秒 の生成速度をNVIDIA GPU上で実現
  • 1Mトークン の長大なコンテキストウィンドウ(従来の約4倍)
  • 価格は 入力100万トークン0.20ドル/出力100万トークン0.70ドル
    • ローンチ時は 50%オフ (入力0.10ドル/出力0.35ドル)
    • キャッシュ済みトークンはさらに 90%割引

拡散型LLMのスケーラビリティ

  • Mercury 1 で商用拡散型LLMの実用性を証明
  • 40倍以上のパラメータ増加 に成功、知能は 3倍向上
  • オートレグレッシブモデル同様、スケーリング則が適用可能であることを証明
  • 複雑なユースケース にも十分対応可能な性能

Mercury 3の実運用事例

  • ブラウザ操作エージェント

    • ステップごとの遅延が蓄積しやすいが、 高速応答 で効率向上
    • Mind2Webタスク50件中50%成功 (GPT-6.1-Solより高い達成率)
    • 同じトークン数・エージェントステップで コスト大幅削減
  • インタラクティブ教育

    • 即時フィードバック により、生徒の集中力維持
    • 1秒程度で高品質な回答やヒントを返す
    • 既存システムとの互換性 も高い
  • リアルタイム検索エージェント

    • 数十文書を処理しつつ 2秒未満で回答
    • スマートグラス等の 超低遅延要求 にも対応
    • Octen AI でのテストで最速・高品質を両立
  • カスタマーサポート

    • 規制業種でも 正確かつ高速な応答 を実現
    • Lorikeet 等で実運用、他モデルより評価・生産環境で高性能

Mercury製品ポートフォリオ

  • Mercury 3 がリアルタイムAI製品群のフラッグシップ
  • Mercury Voice
    • 音声アプリ向け 超低遅延 特化モデル
    • Audivi AI、Altur、OpenCall等で採用
  • Mercury Decide
    • 高頻度分類用途向け 意思決定モデル
    • JevBenchやLegalBenchで Jev を上回る性能

導入方法・利用開始

  • Inception API Platform、 OpenRouter、 Baseten、 Vercel で提供開始
  • OpenAI API互換 で、既存スタックに そのまま組み込み可能
  • エンタープライズ向けに 専用キャパシティ・自動スケーリング・コンプライアンス制御 も提供
  • 100万トークン無料トライアル や APIドキュメント も公開中
  • エンタープライズ評価支援 も実施中—用途適合、設計、運用パフォーマンスもサポート

Mercury 3 が実証したのは、 拡散型LLMのスケールと実用性。 今すぐリアルタイムAIの新時代を体験可能。

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

実際のモデルサイズがどれくらいなのか、トレーニングプロセスが従来のLLMとどう違ったのか、すごく気になるな。どちらにしても素晴らしい仕事だし、数ヶ月遅れで最先端に追いつくのが新しい参加者にとって実現可能なことに思えるのはすごいけど、やっぱりコストは高いよね。

@volodia(インセプションの共同創設者)がここにコメントしてるけど、フラグが立ってて死んでるのが変だな。おかしい、そんなことないはずだ。誰か直してくれない?

└

モデレーターにメールを送るのが、一番いい方法だよ。そういう問題を知らせるには。

もし彼らのベンチマークが信じられるなら、かなり進展があったみたいだね。もっとオープンなウェイト拡散LLMが見られるといいな(今は拡散Gemmaがあるけど)。それに、拡散LLMが自立し始めたら、結構な変化があるんじゃないかな?もしこれが10倍のスループットで動いてるなら、同じハードウェアでかなり多くのトークンを扱えることになるし。追記:リポジトリで試してみたけど、今のところかなり良さそう。意外と驚いてる。

なんでGoogleが去年のGemini Diffusionデモで実質的に何もしなかったのか、まだ理解できないな。めっちゃクールで速かったのに、急に静かになっちゃった。数ヶ月前にDiffusion Gemmaをリリースしたけど、それもあまり話題になってないよね。

└

うまくいかなかったのかもね?

└

彼らのプレプリントでは、小さいバッチサイズでうまくいくって書いてあったけど、今のところほとんどのプロダクションデプロイメントは複数のユーザーにサービスを提供するためにかなり大きなバッチサイズになってるよ。

└

研究は得意だけど、製品はイマイチ?

└

Difussion Gemmaは、同等の自己回帰モデルに比べてかなりパフォーマンスが悪かった(特に、2つのモデルクラスの間に見られるような一定のギャップではなく、タスクやベンチマークが難しくなるほどギャップが悪化していったから)。スケールで速度の利点が打ち消されちゃったのはあまり驚きじゃないね。

└

このトークは、彼らがどこにいるかのアップデートみたいなものだよ:https://youtu.be/r305-aQTaU0?si=j3IqG9BAT0uumPeA 高レベルで言うと、標準的な自己回帰モデルのようにメモリ帯域幅を減らすためにバッチ処理の恩恵を受けないから、個別の低並行ユーザーにはレイテンシを減らすのに優れていて、特定のタスクでより良い結果を出すけど、スケールではトークンあたりのコストがかなり高くなるってことだね。

└

グーグルのせいじゃないよ。私たちのせいだね。llama.cpp はそれをサポートしてないし、vllm はホスト RAM にオフロードできない。huggingface transformers はサポートしてるけど、Diffusion Gemma のような MoEs のための f16 量子化しかできない。拡散が本当に効く低スペックのマシンでは使えない。目の前に素晴らしいモデルがあるのに、みんな見逃してるよ。拡散モデルを使えば、フレーズをちゃんと禁止できるし、モデルの出力を一切重みを触らずにデセンソーやデスロピファイできるんだ。

うーん、少なくともOpenrouterでは、deepseek v4.1がtogether/baseten/fireworks経由で、レイテンシーとインテリジェンスでmercury 3を上回ってるみたい。Ttftはmercuryでかなり遅いし。

Hacker Newsで議論の続きを見る

同じ出典の記事