MLPerf InferenceがAIエージェント時代へ：マルチターンAgentic Inferenceベンチマークを新規追加

はじめに：推論ベンチマークはインテリジェントエージェントアプリケーションに追いつく必要がある

MLPerf Inferenceベンチマークスイートは、AIデプロイメント形態の変化に伴い進化を続けている。初期の推論ベンチマークは主に、画像分類・物体検出・音声認識・推薦システム・シングルターン言語生成などのタスクをカバーしていた。これらのワークロードは依然として重要だが、大規模言語モデルの本番環境における最も急成長する利用形態、すなわちマルチターンAgentic Inference（多ターンインテリジェントエージェント推論）を代表するには不十分となっている。

コーディングアシスタントを例にとると、それは単に一度のクエリに答えるだけではない。コードエージェントは通常、まずIssueを読み込み、ファイルを確認し、コマンドを実行し、失敗結果を観察し、コードを修正しながら繰り返し反復する。同様に、ワークフローエージェントは顧客情報を収集し、ツールを呼び出し、返却結果を解釈し、追加の質問を行い、タスクが完了するまで処理を継続する。両者に共通するのは、ワークロードが互いに独立したリクエストではなく、相互依存する複数のターンから構成されるトラジェクトリであり、各リクエストにはそれまでの完全な会話履歴が含まれるという点だ。

この変化はモデルサービングに4つの具体的な課題をもたらす：

• コンテキストの継続的な増大：トラジェクトリが進むにつれて、プリフィルのオーバーヘッドとKVキャッシュのプレッシャーが増大し続ける。
• KVキャッシュの再利用が重要な最適化となる：キャッシュ再利用はパフォーマンスとエネルギー効率に直接影響する。
• 出力長が非常に不安定：ツール呼び出しが短い場合もあれば、長い推論トレースが生成される場合もある。
• ターン間に依存関係が存在する：スループットは独立したリクエストレートだけでなく、クローズドループでのタスク進行能力でもある。

図1：マルチターンAgentic Inferenceシナリオの概要。1つのタスクが相互依存する複数のターンを経て進行する。

このような新しいワークロードをカバーするため、Agentic InferenceベンチマークがMLPerf Endpointsフレームワークに追加された。MLPerfの従来の測定原則を維持しつつ、このワークロード向けの重要な構成要素を定義している。それにはモデル選択・データセット構成・マルチターン負荷生成・出力検証、そしてプレフィックスキャッシングやSpeculative Decodingなどの最適化手段に対する制約が含まれる。

用語説明

• ターン：クライアントから発信されるユーザーリクエストまたはツールリクエスト1件と、それに対してモデルが生成する応答のこと。
• トラジェクトリ：1つのタスクまたはシミュレートされたユーザーに対応する、順序付きのターンシーケンス。後続のターンにはそれまでに蓄積された会話履歴が含まれる。

モデル選択：異なるアーキテクチャとサービング動作をカバー

このベンチマークには、長文脈を処理でき、Thinking能力を持つLLMが必要だ。エージェントアプリケーションにおける典型的なサービング動作、すなわち増大し続けるコンテキスト・KVキャッシュ再利用・可変出力長・厳密なマルチターン依存関係に対してストレステストを行うためである。MLCommonsは本ベンチマーク用にKimi K2.6とQwen3.6-35B-A3Bを選定した。

Kimi K2.6は優れたコーディング能力を持ち、モデル規模も主流の最先端エージェントシステムに近い。一方、Qwen3.6-35B-A3Bはよりコンパクトで、新しいGated DeltaNet（GDN）アーキテクチャを採用し、そのモデル規模において際立ったコーディング性能を発揮する。両者は異なるサービング動作・アーキテクチャ選択・Speculative Decodingパスをカバーする。なお、2つのモデルは同じ手法とデータセットを用いてそれぞれ独立して評価され、混合実行や単一スコアへの統合は行われない。

表1：モデルメタデータとベンチマーク設定。

データセットとタスク選択：コーディングとワークフローの2つのシナリオ

Agentic Inferenceベンチマークのデータセットは、異なるインフラボトルネックを引き起こすための2つのエージェント領域を組み合わせている。全体で613件のマルチターントラジェクトリを含み、そのうち113件がエージェントコーディングトラジェクトリ、500件がエージェントワークフロートラジェクトリだ。参照データセットにおいて、これらのトラジェクトリには合計30,335件のクライアント発信ターンと30,328件のアシスタントターンが含まれる。

MLCommonsは、実際に収集したトラジェクトリを用いたベンチマークテストにより、本番環境のサービングスタックの動作—実際のマルチターントラフィックにおけるSpeculative Decodingの挙動や、実際の負荷におけるエキスパートランクバランシングの効果を含む—をより忠実に再現できると強調している。

図2：Agentic Inferenceベンチマークは、コーディングエージェントとワークフローエージェントの2種類のマルチターントラジェクトリをカバーする。

表2：データセット構成と主要なストレスポイント。

Agentic Coding：DeepSWEのコードエンジニアリングトラジェクトリ

エージェントコーディングトレースは、DataCurve（datacurve.ai）のDeepSWEデータセットから取得している。このデータセットは、リポジトリレベルのバグや機能要件に基づくソフトウェアエンジニアリングタスクで構成されている。典型的なトラジェクトリはユーザーが問題を説明するところから始まり、アシスタントが一連のbashコマンドを通じてコードリポジトリを調査する。具体的にはファイルの検索・ソースコードの閲覧・テストの実行・エラーの観察・実装の修正を繰り返し行う。

この種のトラジェクトリの特徴は深さにある：中央値のトラジェクトリは通常、数十ターンを含む。コマンド出力・ファイル内容・テストログが蓄積されるにつれて会話履歴は継続的に増大するため、長文脈スケジューリングとKVキャッシュ容量のプレッシャーを検証するのに適している。

Agentic Workflow：エンタープライズカスタマーサポートとオーケストレーションシナリオ

Workatoのエージェントワークフロートレースは、エンタープライズカスタマーサポートとビジネスオーケストレーションのシナリオから取得している。顧客がサポートを求め、エージェントがツールを使って注文照会・配送追跡・ポリシー確認・チケットのエスカレーション・アカウント問題の解決を行う様子をシミュレートしている。

コーディングトラジェクトリと比較すると、このワークフロートラジェクトリは通常より浅いが、大量のツール定義とビジネスルールを含む大規模な共有システムプロンプトを持つ。関連トレースはWorkatoが提供している。Workatoはエンタープライズ向けのエージェント制御・実行プレーンであり、これらのデータは合成トラジェクトリで、企業顧客向けカスタマーサービスエージェントのオーケストレーションにおけるWorkatoの本番経験をモデル化したものだ。

なぜ2種類のワークロードを組み合わせるのか？

• コーディングトレースは多数のターンを経て急速にコンテキストを拡張する。
• ワークフロートレースは比較的大きな共通プレフィックスから始まり、その後の増加は比較的緩やかだ。
• コーディングは主にKVキャッシュ容量と長文脈スケジューリングをストレステストする。
• ワークフローは主に共有プレフィックスの再利用とルーティングのローカリティをストレステストする。
• 組み合わせワークロードにより、システムが特定のエージェントトラフィック形状のみに最適化されることを防ぎ、さらにコンテキスト認識ルーティング能力を検証できる。

クライアント設計：MLPerf Endpointsにマルチターンクローズドループワークロードを対応させる

完全なエンドツーエンドのエージェントワークロードを実行するため、MLCommonsはMLPerf Endpointsにマルチターンサポートを導入した。提出者はvLLM・SGLang・TensorRT-LLMまたはその他のサービングフレームワークを使ってOpenAI互換エンドポイントを起動し、クライアントをそのエンドポイントに向けるだけで、エンドツーエンドのベンチマークテストが完了する。

クライアントはマルチターン動作を処理し、中核的なメカニズムには以下が含まれる：

• クローズドループリプレイ：アクティブな会話は一度に1ターンのみ発行し、次のターンに進む前にモデルの完全な応答を待機する。
• ターゲット同時実行数：ロードジェネレーターはターン間の依存関係を破壊せずに、アクティブなユーザーまたは会話の数を制御する。
• ターン間遅延：データセットに含まれるツールまたはユーザーターンの待機時間を使用して実際のリズムを維持する。この遅延はモデルサービングのレイテンシに算入されない。
• 会話認識ルーティング：各トラジェクトリは安定したX-Session-IDリクエストヘッダーを送信し、ルーターがKVキャッシュのローカリティを維持しやすくする。
• キャッシュソルティング：システムプロンプトの周囲に決定論的なソルトマーカーを付加することで、同一トラジェクトリ内での正当な再利用を許可しつつ、トラジェクトリをまたいだ無効な再利用を防ぎ、ベンチマークが本番ワークロードに近くなるよう保証する。
• 決定論的プロンプト再構成：将来のプロンプトはモデルのリアルタイム出力に依存せず、事前に録音されたデータセットから構築される。これにより、生成された出力を測定しながらも、パフォーマンス実行の再現性が保証される。
• 生成済みトークンキャッシュのクリア：異なるプラットフォーム間の公平な比較のため、空白文字を挿入することでKVキャッシュ内の生成済みトークンをクリアし、パフォーマンス結果がこれらのトラジェクトリを生成したシステムに依存しないよう保証する。

核心的な意義：単一リクエストのスループットからタスク進行効率へ

Agentic Inferenceベンチマークの価値は、評価の焦点を従来の独立したリクエスト処理能力から、実際のエージェントアプリケーションにおいてより重要なクローズドループ実行効率へと拡張した点にある。サービングシステムにとって、長文脈・マルチターン依存関係・キャッシュ再利用・ツール呼び出しのリズム・可変出力長の間でいかにバランスを取るかが、エージェントアプリケーションの可用性とコスト効率を直接決定する。

コーディングアシスタント・エンタープライズワークフローエージェント・自動化実行システムが本番環境に移行するにつれて、Agentic Inferenceのようなベンチマークは推論プラットフォームの能力を測る重要な補完的指標となるだろう。それはモデル自体をテストするだけでなく、vLLM・SGLang・TensorRT-LLMなどの推論サービングスタックが実際のマルチターントラフィックにおけるスケジューリング・キャッシング・ルーティング能力もテストする。