- Mercury は拡散（Diffusion）方式を活用した新しい商用大規模言語モデル（LLM）
- このモデルはTransformer構造に基づき、複数のトークンを並列に予測する特徴がある
- Mercury Coder は最初の拡散LLMセットで、コード作成向けに開発され、MiniとSmallの2つのサイズで提供される
- NVIDIA H100 GPUで1109（Mini）、737（Small）トークン/秒のスループットを記録し、同等の品質で既存の速度重視モデルと比べて最大10倍高速な性能を示す
- 実利用ベンチマークやCopilot Arenaなどの開発者評価でも品質2位・速度1位を記録し、公開API と プレイグラウンド も提供されている
概要
- Mercury は拡散（diffusion）に基づく新しい大規模言語モデルシリーズで、商用規模で動作する次世代LLMである
- すべてのモデルはTransformerアーキテクチャでパラメータ化されており、複数のトークンを並列に予測するよう学習されている
- 本レポートでは主にコード生成アプリ向けに設計された Mercury Coder の最初のラインアップを紹介する
- Mercury Coderは現在 Mini と Small の2つのモデルサイズで提供されている
主な貢献
- Mercury Coderは速度と品質のバランスにおいて新たなstate-of-the-art水準を達成している
- 外部評価機関であるArtificial Analysis基準では:
- Mercury Coder Mini: 毎秒1109トークン
- Mercury Coder Small: 毎秒737トークン をNVIDIA H100 GPUで記録
- 最高速のフロンティアモデルと比べ、平均で最大10倍高速でありながら同等の品質を示す
- 多様なプログラミング言語および活用事例のコードベンチマークにおける追加評価結果も提供している
- 実際の開発者環境（Copilot Arena）でも
- 誰でも利用できる 公開API ( platform.inceptionlabs.ai ) と 無料チャットプレイグラウンド( chat.inceptionlabs.ai ) をサポートしている
目次構成の説明
- Introduction（紹介）
- Inception Mercury Model Family（モデルファミリーの説明）
- 学習プロセス（Training）
- 推論方法（Inference）
- Capabilities（モデル機能）
- ベースライン性能（Baselines）
- コード生成能力（Coding Capabilities）
- 評価ベンチマーク（Evaluation Benchmarks）
まとめ
- Mercuryは革新的な拡散ベースLLM設計と並列予測構造を組み合わせることで、コード生成分野で圧倒的な速度と高い品質を実現している
- 多様なサイズのモデル、強力な実サービスベンチマーク、容易なアクセス性を通じて、商用環境と開発環境の両方で競争力のある選択肢を提供する
1件のコメント
Hacker Newsの意見
LLMエージェントが導入されると、テスト性能がさらに深刻なCPUボトルネックにつながる見込みで、すでに今でもすべてのチームがCI速度のせいでボトルネックを抱えている状況だと強調している
エージェントが人間より100倍速くコードを書けても、テストに1時間かかるなら意味がないという状況
私が関わった多くのプロジェクトでは、変更が反映されるのを待つ間に無駄になる開発者の時間が多く、実行の多くはI/Oまたはワーカー不足によってボトルネックになっていた
コーディングエージェントが単純なチケットをすばやくPRに変換し、テスト失敗に反応してリアルタイムで修正するようになると、CIボトルネックはさらに悪化するだろう
ほとんどのプロジェクトのテスト環境には改善の余地が大きいが、実際には何年も大きな進展がないまま、遅いCIと高いコストを当然視してきた空気がある
ビルドを完全に隔離するためにキャッシュを無効化したり、オンプレミスから遅いクラウドVMへ移行したりして、CIがむしろさらに遅くなっている
Mercuryの速度は異常なほど速く、何度か試した限りではコード品質も素晴らしく正確だったが、今度はテスト実行までこの速度に追いつかせることが課題として残る
私が関わったほとんどのプロジェクトで、PR承認待ちの間に開発者の時間が無駄になるという点にはあまり納得できない
企業の立場では開発者の時間はマシン時間よりはるかに高価なので、開発者から不満が出るならCIワーカーを倍増させればよい問題だ
Googleではテストの不安定性をデバッグする際、1万台のマシンで1万回テストして、まれに発生する失敗を見つけることもあった
私の今の職場も似た仕組みを提供しており、コマンド一つで全テストを1,000ワーカーに並列実行し、1M LOCのプロジェクトでも5分以内にフィードバックを得ることを目指している
ビルドを完全に隔離することとキャッシュを使わないことは別問題であり、ビルドを完全に隔離しつつも、あらゆるキャッシュは最大限活用すべきだという見方
実装速度が速くなれば、ボトルネックはPM側へ移り、その場合は変更がより直列化されることで衝突が大幅に減る現象が起きると予想する
仕様定義言語（TLA+など）の復活の可能性もあり、エージェントがそれを高速に記述・検証することで、統合テスト全体の数が減るかもしれない
バックグラウンドエージェントが重複コードを整理する際に、重複テストも一緒に整理できる可能性がある
AIは人間のエンジニアチームと違ってモノリシック構造でより効率的に働けそうで、そうなればローカルで回せるテストカバレッジが増え、flakyの減少とCI負荷の低減につながる
AIが効率を高めても、それに応じてさらに多くのコード、より高速なコード生成と実行によって新しい問題は出続け、人間のエンジニアが解決すべき新たな課題も継続的に現れるだろうという確信がある
LLMは100行未満のちょっとした修正や、ラバーダック的な役割なら悪くないが、大規模プロジェクトのCIパイプラインにLLMを直接組み込むと、数百時間単位の生産性低下につながる恐れがある
本来コードを書く力を伸ばすべき時間に、プロンプト調整やコンテキスト調整ばかりすることになるなら意味がない
LLMツーリングに対する自信が過剰すぎると感じており、複雑なシステムにはうまく適用できないと思う
重要なリポジトリに監督なしでLLMを投入することは、「銃を突きつけられでもしない限り」あり得ないという強い不信感
結局LLMの出力を半分やり直すことになり、それなら最初から自分でやったほうがましだという立場
自動車以前は燃料、オイル、整備などにほとんど金を使わなかったが、システムが発展するにつれて、それに見合う周辺インフラとコストが付随する構造だ
AIでボトルネックを解消したり、より多くの機能を作って収益を最大化したりし、その追加収益でさらに多くのCIリソースを確保するという循環になる
AIは開発者を10人増やしたのと変わらず、当然サポートコストも増える
効率性を論理的に説明して、より多くのCIリソースを確保したり、最適化の方向性を示したりできるかを振り返るべきだという見方
CIリソース1台あたりのコストがどれくらいなのか気になる
Pythonアプリでastral.shのツールチェーンとuvパッケージのインストール＋キャッシュ活用により、CI速度を大きく改善した経験がある
近いうちにmypyの代わりにastralの型チェッカーへ移行する予定で、そうなればさらに速くなる見込み
フロントエンドを持つアプリではPlaywrightテストが最も遅い部分だろうが、それも他のアプリでは当てはまらない
（追記: もしMikeで合っているなら、2000年代初頭のGoogle Mapsで一緒に働いていたSREだと記憶しており、信頼できる意見だ）
私がMercury playgroundで正規表現パターンを依頼したところ、モデルが自分で計画を立て、パターンを書いたあとテスト生成を始めた
ところが延々とテストを増やし続け、コンテキスト上限に達したところで応答が途切れてしまった経験がある
30件ほどを過ぎるとテスト結果のコメントを誤って付け始め、120件を超えたあたりからはテスト入力そのものがおかしくなり、ランダム文字が大量に出てきた
パターン自体も正解ではなかったが、この「無限ループ」現象のほうがさらに興味深い問題だった
ちなみに、ごく最近まで一般的なLLMでも、こうした「ほぼ無限ループ」のように見える反復出力をすることがあったのを覚えている
出力が少しずつだけ変わるパターンに閉じ込められることがあった
この事例は、「トークン予測だけではコードを正確に作れない」ことを示す代表的な証拠だと思う
LLMはそもそもコード思考に適した設計ではないという評価
技術レポートを読んだところ、Mercuryが論文 Lou et al. 2023, SEDD をベースにしていることを確認した
私がおそらく初めてSEDDをfrom-scratchで再実装し、コードも公開している
複雑なデノイジング手法も自分で実装した
既存のSEDDよりもクリーンで読みやすいように設計してあり、単一GPUでおもちゃデータセットなら数時間で動かせる
ちなみにDeepMindにもdiffusionベースのGeminiモデルがある（リンク）
実際に試してみたところ、Mercuryのように速度は異常なほど速かったが、回答品質は他のGeminiと比べてかなり落ちていた
軽く使ってみた限りでは、速度は印象的だが正答率がかなり下がる現象には同意する
Gemini Diffusionデモが無料なのか気になる
数日間ウェイトリスト待ちなので、実際に試せる機会がなくて残念だ
個人的にはこうした進展にとても期待している
最近ゲームジャムでAIを使って簡単なゲームをコーディングしたが、結果を待つ時間が全体の半分以上を占めていた
プロンプトごとに1〜2分かかる状況で、10秒待つだけで済むなら、従来1回テストしている間に5〜10回は実験できる
まだMercuryは実用的に使えるほど成熟していないが、Claude 3.0も1年前は不十分だったので、今後はさらに良くなる見込みだ
これからが本当に楽しみな時期だ
Mercury playgroundを使ってみたが、速度は本当にすごい
diffusion modeの可視化も新鮮だが、実質的には可視化された線ノイズから徐々により正確な状態へ磨かれていく過程を見せているようだ
実際には、ランダムなベクトル空間から徐々に確信度の高いトークンへ収束していく過程だと見ている
一部のテキストdiffusionモデルは連続的な潜在空間（latent space）を使うが、性能はあまり良くない
最近ではたいてい実際のトークン出力予測に集中し、各ステップで前の値を修正しながら最終結果へ収束していく
私が書いたテキストdiffusionの動作原理の解説も参考になる
リンク : https://chat.inceptionlabs.ai/
本当に信じられないほど速いと感じた
たいていのGPU近傍コードには性能最適化の余地が非常に大きい
ただし、arXiv論文が実際の研究というよりマーケティングに近いのではないかという疑問もある
別の意見も歓迎する
Mercuryモデルの価格設定
出力トークン100万個あたり1ドル、入力トークン100万個あたり0.25ドル
詳しい料金ポリシーはこちらを参照
性能重視なら、MercuryとGroq（Llama 3.1 8b、Llama 4 Scout）を比較した場合、性能は似ていたがGroqの価格のほうがかなり有利だった
diffusionモデルのオープンソース登場を期待しつつ注目している
playgroundのコードとAPI応答に
gpt-3.5-turboと"openai": trueという項目が見えたので、実際には独自のdLLMではなくOpenAIを呼んでいるのではないかと気になった右上のdiffusion effect機能は単なるアニメーション効果に見える
すべて魅力的に聞こえるが、
サービスにユーザー投稿を送信すると、世界的に非独占的で、永続的かつロイヤリティ不要、無償で全面的に譲渡可能なライセンスをInceptionに付与することになるという利用規約だ
つまり、ユーザーのコンテンツをAIモデル訓練目的に使える
（ただし、OpenRouter経由のアクセス分は学習に使わないという例外条項がある）