Mercury 2公開、Diffusion型推論LLMでリアルタイム推論を狙う
Original: Mercury 2: Fast reasoning LLM powered by diffusion View original →
何が起きたか
Hacker Newsで、Inception LabsのMercury 2発表が共有された。発表では、従来のautoregressiveな逐次デコードが、実運用AIのlatencyボトルネックになっていると述べられている。
Mercury 2は、トークンを1つずつ生成する代わりに、Diffusionベースで複数トークンを並列に精緻化する設計だと説明される。これにより、厳しい応答時間でもreasoning品質を維持できるというのが中心的な主張だ。
公開された指標
- 発表ページには、NVIDIA Blackwell GPUで1,009 tokens/secという数値が記載されている。
- 同社は、従来的な生成方式に対して5倍超の高速化を主張している。
- 価格は入力1Mトークンあたり$0.25、出力1Mトークンあたり$0.75と掲載されている。
- OpenAI API互換とEarly Access提供が明示されている。
なぜ重要か
voice agentやcoding copilotのようにモデルを反復呼び出しする製品では、平均速度だけでなくtail latencyの改善が重要になる。Diffusion系推論が品質を維持しつつ遅延を削減できれば、UX設計と運用コストの両方に影響する。
もちろん、性能主張はワークロードやハードウェアで再検証が必要だ。それでもMercury 2は、非autoregressive系アプローチが研究話題から商用APIへ移行しつつある流れを示す事例になっている。
ソース
実運用チェックリスト
本番導入前には、短期間でも構造化された検証が必要だ。ドメイン内品質、同時実行時のlatency、オーケストレーションを含む総コストを合わせて評価するべきである。公開ベンチマークと実運用条件は一致しない場合が多い。
- 代表的なプロンプト/音声サンプルで回帰テストを作成する。
- 平均値だけでなくピーク時のtail latencyを計測する。
- 過剰順応や事実ドリフトなど失敗モードを明示的に追跡する。
Related Articles
r/LocalLLaMAが900 points超まで反応した理由はscore表ではない。local coding agentがcanvas bugとwave completion issueを見つけて直したという使用感だった。
r/LocalLLaMAがこの投稿を押し上げたのは、“trust me bro”な体験談の中に8-bit、64k context、OpenCode、Android debuggingという実使用条件が入っていたからだ。
AnthropicはClaudeの選挙安全策を数値で公開した。Opus 4.7とSonnet 4.6は600件の選挙ポリシー試験で100%と99.8%の適切応答を示し、米中間選挙関連の質問では92%と95%の割合でウェブ検索を起動した。
Comments (0)
No comments yet. Be the first to comment!