MLPerf v6.1、エッジ向けAgentic推論ベンチマークの結果を募集

2026年7月25日 30 約16分 MLC

MLC MLPerf 边缘AI Agentic AI 大模型推理基准测试

MLCommons Edge LLM Taskforceは、MLPerf Inference v6.1ラウンドに新たなEdge Agentic Inferenceベンチマークを導入すると発表した。コーディングコパイロット、ロボットコントローラー、プライベートローカルアシスタントなど、Agentic LLMがデバイス上で動作するケースが増加するにつれ、実際のエッジ環境の制約下でモデルがツールを呼び出す際の精度と応答速度をどう測定するかが、ますます重要になってきている。

今回のベンチマークでは初めてQwen3.6-27Bモデル（2026年4月22日リリース）を採用し、参照実装ではQ4_K_M GGUF量子化形式で単一のエッジアクセラレータ上で動作させる。提出者は精度閾値を満たす任意の許可された量子化方式を使用可能だ。ワークロードは2つの部分で構成される。決定論的かつLLMジャッジ不要の精度閾値評価に用いるBerkeley Function Calling Leaderboard v4（BFCL v4）と、シングルストリームの性能評価に用いる録画式Agenticコーディングリプレイである。両者が合わさって、デバイス上Agentの実際の課題を描き出す。増大し続けるツール呼び出しの長い対話を固定コンテキストウィンドウに収め、単一の対話ユーザーに対して十分な応答性を維持しなければならない。

提出締め切りは2026年7月31日。MLCommonsはハードウェアベンダー、エッジデバイスメーカー、推論システムの専門家に結果の提出を呼びかけ、デバイス上Agenticの推論評価基準の向上を目指している。

エッジ側Agentic AIベンチマークが必要な理由

応用AIはシングルターンのテキスト生成からマルチターンのAgenticワークロードへと移行しつつある。実際のAgenticセッションは「1回のプロンプトと1回の回答」ではなく、連続した軌跡である。各ターンでツールの出力とモデルの応答が増大し続ける対話履歴に追加され、モデルは短いツール呼び出しとより長い推論の間を行き来し、各ターンは前のターンの結果に厳密に依存する。

データセンター版MLPerf Agenticベンチマーク（9月リリース予定）が焦点を当てるのは別の課題だ。大規模なMixture-of-Expertsモデル、累積マルチターンコンテキストが100Kトークンを超える長期軌跡、そして並列スキャンによってGPUあたりのParetoフロンティアを求めることである。エッジ側はその対極にあり、本ベンチマークは主に以下の制約を対象とする。

固定メモリと電力予算：単一の小型アクセラレータがモデルの重み、KVキャッシュ、アクティベーションを同時に収容する必要がある。フルプレシジョンのフロンティアモデルは通常収まらないため、量子化が必須の選択肢となる。
単一の処理中リクエスト：エッジ推論は主に1人の対話ユーザーにサービスを提供し、データセンターのような数千もの並列セッションには対応しない。
固定のserved context window：参照実装ではserved contextを32Kトークンに固定している。これはデバイスの上限ではなく、制御されたベンチマークパラメータであるため、長い軌跡ではコンテキストウィンドウが枯渇する可能性があり、コンテキストの増加とトランケーションが測定可能な第一次の影響となる。
総スループットではなく単一ユーザーのレイテンシを重視：シングルスロットのエッジデバイスでは、スループットとレイテンシはほぼ逆数の関係にあるため、より重要な指標は単一ターンのTTFT、TPOT、エンドツーエンドのターンレイテンシであり、マルチストリームのデータセンターサーバーが最適化する集計QPS やトークンスループットではない。

このベンチマークはデータセンターAgenticの仕様からマルチターンの方法論を継承している。用語、決定論的リプレイ、JSONLデータセットスキーマ、インライン精度チェックが含まれ、エッジシナリオに特化した対応が施されている。エッジモデルと量子化方式、シングルストリームの負荷パターン、レイテンシ中心の指標、そして統計的堅牢性を持つ精度閾値がそれにあたる。

モデル選択：Qwen3.6-27BとQ4_K_M量子化

参照モデルはQwen3.6-27Bであり、llama.cpp（commit cfff1fc）を通じてQ4_K_M GGUF量子化形式で提供される。GGUFファイルはunsloth/Qwen3.6-27B-GGUF内のQwen3.6-27B-Q4_K_M.ggufから取得する。

MLCommonsがQwen3.6を選択した理由は、これがオープン（Apache 2.0）でツール呼び出し能力が高く、ネイティブのMTP投機的デコーディングヘッドを備えるモデルであるためだ。27Bのdenseモデルでありながら、アリババの報告によると主要なコードベンチマークで従来の397B-MoEフラッグシップモデルを上回り、SWE-bench Verifiedで77.2%を達成している。また、デプロイのしやすさも優れており、公式の重みはHugging FaceとModelScopeで公開され、コミュニティ版GGUFはllama.cppでそのまま動作する。

量子化はエッジデプロイにおける重要な選択だ。Q4_K_Mは4-bit K-quantの「Medium」グレードに該当する。重みは値あたり4ビットで格納され、BF16と比べて約4倍のメモリ圧縮を実現する。アテンションブロックはフィードフォワードブロックより高い精度を維持し、重要度加重（imatrix）キャリブレーションによって影響の大きい重みを保持する。結果として、27Bモデルはおよそ16.5GB VRAMで動作するのに対し、BF16では約54GBが必要であり、代償として精度損失は約2〜5%にとどまる。これがエッジGPUで動作可能かどうかの境界線となる。

参照サンプリングパラメータ

Parameter	Value
temperature	0
top_k	1（temperature=0の場合は実質的に影響なし）
top_p	1.0（temperature=0の場合は実質的に影響なし）
seed	42
max_new_tokens	1024
repetition_penalty	1
reasoning	off
context size	32768（32K）
parallel slots	1

このツール呼び出しワークロードにおいて、reasoningは意図的にオフにされている。有効にするとシングルターンの精度が低下し、処理時間が大幅に増加するためだ。MLCommonsは、このベンチマークが複数ベンダーの様々なエッジアクセラレータ上で検証済みであり、ワークロードと方法論の移植性が確認されていると述べている。

ベンチマークタスク：精度と性能の2データセット

このベンチマークは異なる役割を担う2つのデータセットを使用する。

精度データセット：BFCL v4

Berkeley Function Calling Leaderboard v4（BFCL v4）は、モデルが正確かつ決定論的に関数を呼び出せるかどうかをLLMジャッジなしでテストする。シングルターンのリクエスト、すなわち「1つのプロンプトから1つの構造化ツール呼び出し」をカバーし、主に3つのカテゴリに分類される。

non_live：ASTマッチングによりゴールドラベルと照合。
live：同様にASTマッチングで評価。
hallucination：利用可能なツールが質問と無関係な場合に、モデルが関数呼び出しを拒否できるかを判定する二値チェック。

また、BFCL v4にはオプションのマルチターンAgenticダイアログも含まれており、プロセス内Pythonシミュレータで実行される。カテゴリは公開されているgorilla-llm/gorilla-eval-setから取得され、実行時に自動ダウンロードされる。

今ラウンドのスコアリング閾値はシングルターンセットのみを使用し、カテゴリ別サンプリングにより統計的に安定した約995サンプルポイントで推定される。non_liveが72%（約712サンプル）、liveが17%（約171サンプル）、hallucinationが11%（約112サンプル）である。またsubset_floorを25に設定しており、エントリ数が25以下のサブセットはすべて完全に含まれる。

性能データセット：録画式Agenticコーディングリプレイ

性能データセットはMLPerf Agenticベンチマークのサブセットで、録画済みのマルチターンAgenticコーディング軌跡を含む。これらのタスクはSWE-benchに類似した形式で、astropyなどの実際のコードリポジトリに由来し、決定論的リプレイ方式を性能ワークロードとして採用し、スケールは単一デバイスのエッジサービスに合わせて調整されている。

参照セットは20セグメントのダイアログ、1,007ターンを含み、すべての軌跡が32Kトークンのserved contextをオーバーフローしないよう設計されており、ピーク入力長は約23.5Kトークンである。コンテキストのオーバーフローは発生しないため、各ターンは完了する。並列数1、一度に1つの処理中リクエストのみという条件下で、単一のエッジデバイスが合理的な時間内に完全な実行を完了でき、有効な実行にはゼロのドロップターンが要求される。

このデータセット自体がground truthも担う。各軌跡内の録画済みツール呼び出しがゼロコストのインライン精度チェックを駆動し、レイテンシ測定と同時並行で実行される。精度は実行済みコールのmultiset IOUでチェックされるため、正確性とレイテンシが同一の実行から得られる。

リクエストとレスポンスの例

シングルターンのファンクションコーリングリクエストは、利用可能なツールスキーマとともに、OpenAI形式互換の/v1/chat/completionsエンドポイントへ送信される。例えば、ユーザーがサンフランシスコの現在の気温（摂氏）を尋ねる場合、リクエストには以下のようなツール定義が含まれる。

{
  "messages": [
    {
      "role": "user",
      "content": "What is the current temperature in San Francisco, in Celsius?"
    }
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_current_weather",
        "description": "Get the current weather for a given location.",
        "parameters": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "City and state, e.g. San Francisco, CA"
            },
            "unit": {
              "type": "string",
              "enum": ["celsius", "fahrenheit"]
            }
          },
          "required": ["location", "unit"]
        }
      }
    }
  ]
}

モデルは構造化されたツール呼び出しを返すべきである。

{
  "choices": [
    {
      "message": {
        "role": "assistant",
        "tool_calls": [
          {
            "type": "function",
            "function": {
              "name": "get_current_weather",
              "arguments": "{\"location\": \"San Francisco, CA\", \"unit\": \"celsius\"}"
            }
          }
        ]
      },
      "finish_reason": "tool_calls"
    }
  ]
}

BFCL v4のASTチェッカーは、予測された呼び出しをゴールドラベルと関数名および各引数について逐一照合するため、評価の精度と再現性が確保される。

意義

このEdge Agentic Inferenceベンチマークは、評価の重点を従来のスループットからデバイス上のAgentの実際の使用体験へと移行させる。限られたメモリと電力の下で、モデルが長いコンテキストとマルチターンのツール呼び出しにおいて精度を維持しながら、単一ユーザーに対して許容可能な応答レイテンシを提供できるかが問われる。エッジAI推論能力を証明したいチップ、デバイス、システムベンダーにとって、MLPerf Inference v6.1は次世代のデバイス上AIアプリケーションにより適した、公開された評価フレームワークを提供している。