Mercury 3｜並列生成の速さはエージェントの待ち時間をどこまで減らせるか

検索のたびにモデルの応答を待つエージェントなら、生成が速くなる効果を見込める。Mercury 3 は並列生成での高速化を掲げ、ツール呼び出しと構造化出力も備える。¹² ただ、外部ツールの応答や失敗後のやり直しを含めると、作業全体の短縮幅は変わる。

本稿は公開資料をもとに検討した。RoundUp では Mercury 3 の API を独自に測定していない。

導入試験は結果を確認できる作業から

導入試験では、回答を資料と照合できる仕事や、修正後にテストを実行できる仕事を選ぶ。照会なら、元のシステムに戻って結果を確認する。ツール呼び出しと構造化出力には既存のインターフェースを使えるので、比較用の実装も用意しやすい。³⁴

合格条件を固定したうえで、失敗した試行と別モデルへの引き継ぎも費用に含める。試験全体の支出を、受け入れ可能な結果の件数で割ると、業務に近い比較になる。これは本稿が提案する集計方法であり、Mercury の実測結果ではない。

長いコンテキストも個別に確かめたい。入力できる容量から、必要な根拠を正確に探し出せるとは判断できない。² 実際に使う日本語の資料や会話履歴で、情報の取りこぼしや指示の取り違えを確認する必要がある。

採用範囲を広げるかどうかは、作業を終えた時点の結果で決める。必要な正確さを保ちながら、時間と費用も減っていれば、生成の高速化を業務に活かせている。

拡散方式で変わる処理

初期 Mercury の技術報告では、Transformer を使い、ノイズを取り除く処理を繰り返しながら複数の位置のトークンを並列に更新する。拡散方式を採用しても、Transformer 自体を捨てるわけではない。学習の目標と文章を生成する手順が変わる。⁵

同報告は、並列処理によってデータ移動に対する計算の割合を高められると説明している。また、専用の推論エンジン、動的バッチ処理、独自カーネルにも触れている。⁵ 速度はこうした配信基盤の工夫にも支えられている。別の拡散モデルに、そのまま同じ速度を期待することはできない。

更新を繰り返すたびに計算は必要になる。一度にどれだけの内容を確定できるか、何回の更新が必要か、過去の計算を再利用できるかで効率は変わる。Block Diffusion の研究は、ブロック単位の生成と KV キャッシュの組み合わせを扱っている。⁶ Mercury 3 がこの論文と同じ方式を使っているかは確認できない。発表資料だけでは、内部のサンプリングやキャッシュの仕組みまでは分からない。¹

仕様と速度の数字を分けて読む

公式資料で確認できる主な項目をまとめた。生成速度はメーカーの測定値、コンテキストや出力上限はサービスの仕様である。価格は本稿の確認時点のものだ。¹²

項目	公表内容	判断に追加で必要なもの
生成速度	毎秒 1,068 トークン1	GPU、同時実行数、入出力長をそろえた測定
コンテキスト	100 万トークン2	長文から必要な情報を取り出す精度
最大出力	131,072 トークン2	長い応答の正確さと所要時間
通常の入力／出力料金	100 万トークン当たり 0.20／0.70 ドル2	再試行を含めた実際の費用
公開時の入力／出力料金	100 万トークン当たり 0.10／0.35 ドル2	割引の適用期間
推論設定	instant、low、medium、high。既定値は low7	設定ごとの品質と遅延

Inception は、初代に対して総パラメーター数を 40 倍超に増やしながら、同程度の速度を維持したとも説明している。¹ 条件をそろえて再現できれば、規模を大きくしても速度上の利点を保てるという見方を支える。ただし、学習効率まで比較するには、計算量やデータ、評価条件の情報が必要だ。製品発表だけで、同じ予算に対してどの方式が有利かまでは決められない。

比較するときは業務の合格条件を先に決め、各モデルでそれを満たす推論設定を探す。その設定での時間と費用を比べればよい。high という名前が同じでも、サービスが違えば計算量まで同じとは限らない。Mercury の文書でも、推論を増やす設定ほど待ち時間が長くなると説明されている。⁷

最初に使える回答はいつ届くか

Mercury の通常のストリーミングでは、整えた文章をブロック単位で返す。別途用意された diffusing モードでは、途中の更新を確認できるが、各更新にその時点の全文が含まれる。⁸ 表示側で両者を同じように追記すると、意図した表示にはならない。

音声アプリでは、いつ回答を読み上げ始められるかを測る。ツールを動かすなら、引数がそろって検証を終えるまでの時間になる。毎秒の出力数だけでは、どちらも分からない。混雑する時間帯に待たされないかも調べる。

短い引数を返す呼び出しと、長い資料を整理する応答では、生成を速める効果も変わる。もともと生成に使う時間が短ければ、削減できる余地は小さい。実際の応答長に合わせて測定することを勧める。

外部処理の順番は残る

公式のツール文書は、独立した操作の並列実行を認める一方、後の操作が先の結果に依存するときは順次実行するよう説明している。³ 別々の資料を検索することは並行して進められる。注文内容を確認してから変更方法を決める作業では、確認の結果を待つ必要がある。

ブラウザーの読み込みやデータベースへの照会は、生成を速めても待たなければならない。操作を間違えれば、やり直しも発生する。比較試験で作業の経過を保存しておくと、モデルが生成していた時間と、外部処理や修正に使った時間を分けて調べられる。

Mercury は JSON Schema を指定した応答に対応している。⁴ これで形式をそろえても、対象の選択や値の根拠まで正しいとは限らない。操作する前に、実際のデータと照合する必要がある。

参考文献

Footnotes

1. Inception 公式発表 — Mercury 3 の速度と規模に関する説明：Diffusion at Scale。 ↩ ↩² ↩³ ↩⁴ ↩⁵

2. Inception モデル文書 — 入出力上限、料金、対応形式：Models。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

3. Inception ツール文書 — 並列実行と依存関係の扱い：Tool Use。 ↩ ↩²

4. Inception 構造化出力文書 — JSON Schema の指定方法：Structured Outputs。 ↩ ↩²

5. Inception Labs 技術報告 — 初期 Mercury の学習方式と配信基盤。第三世代の完全な仕様書ではない：Mercury: Ultra-Fast Language Models Based on Diffusion。 ↩ ↩²

6. Arriola ほか — ブロック拡散とキャッシュ利用を扱う研究：Block Diffusion。 ↩

7. Inception 推論設定文書 — 設定と既定値、遅延の関係：Reasoning Efforts。 ↩ ↩²

8. Inception ストリーミング文書 — ブロック出力と途中状態の形式：Streaming & Diffusion。 ↩