MLPerf Inference v6.1 にエッジ向けエージェント推論ベンチマーク追加
本文の状態
日本語全文を表示中
詳細モードで約16分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
MLCommons Inference
MLCommons はエッジデバイス向けに、ツール呼び出しの精度と応答性を測定する新しいベンチマークを MLPerf Inference v6.1 に導入し、Qwen3.6-27B モデルを用いた実装例を示した。
AI深層分析を開く2026年8月1日 14:06
AI深層分析
キーポイント
エッジ・アジェンティック・インフラの定量化
MLCommons Edge LLM Taskforce は、オンデバイスで動作するコーディングコパイロットやロボットコントローラーなどのツール呼び出し能力を測定するための新ベンチマークを発表した。
厳格なエッジ環境のシミュレーション
本ベンチマークは、単一の小型アクセラレーターでの固定メモリ・電力予算、32K トークンのコンテキスト制限、および単一ユーザーへの応答性を前提とした条件で構成されている。
Qwen3.6-27B モデルとワークロードの採用
参照実装として 2026 年 4 月 22 日にリリースされた Qwen3.6-27B モデルを Q4_K_M GGUF 量子化で用い、BFCL v4 と記録されたコーディング再生ワークロードを組み合わせた。
データセンター型ベンチとの対比
従来のデータセンター向けベンチが並列処理と大規模コンテキストを重視するのに対し、本エッジ向けベンチは単一リクエストでの逐次応答性と文脈の成長・トリミングに焦点を当てる。
シングルユーザーレイテンシ重視
マルチストリームの集計スループットではなく、単一エッジデバイスにおける1ターンごとのTTFT、TPOT、エンドツーエンドのターン遅延が主要指標となる。
重要な引用
measuring how well and how fast these models call tools under a real edge budget is more important than ever
A fixed memory and power budget: A single small accelerator (with a limited amount of memory) must hold weights, KV cache, and activations.
The reference fixes the served context at 32K tokens – a controlled benchmark parameter, not a device ceiling
On a single-slot edge device, throughput and latency are reciprocal to each other, so the metrics that matter are per-turn TTFT, TPOT, and end-to-end turn latency on one device – not the aggregate QPS/token throughput a multi-stream datacenter server optimizes for.
編集コメントを表示
編集コメント
2026 年という未来の日付を含むモデルやリリース情報が示されており、これは将来のロードマップまたはシナリオを示唆するものである。このベンチマークは、データセンターからエッジへ移行する AI アーキテクチャの課題を明確に浮き彫りにし、実装の標準化に向けた重要な一歩となるだろう。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
MLCommonsのエッジLLMタスクフォースは、MLPerf Inference v6.1ラウンド向けに「エッジ・エージェント推論ベンチマーク」の新たな枠組みを発表します。コード支援ツールやロボット制御、プライベートなオンプレミス型アシスタントなど、エージェント型LLMがデバイス上で動作するケースが増える中、「実際のエッジ環境の制約下で、これらのモデルがいかに正確かつ高速にツールを呼び出せるか」を測定することの重要性はかつてないほど高まっています。
今ラウンドでは、2026年4月22日にリリースされたQwen3.6-27Bモデルを採用します。推論形式はQ4_K_M GGUF量子化(参考実装のフォーマット)とし、提出者は精度閾値を満たす限り任意の許容される量子化形式を使用可能です。このモデルを単一のエッジアクセラレータ上で動作させ、2つの補完的なワークロードと組み合わせます。1つ目は、判定者不要で決定論的な精度検証を行う「Berkeley Function Calling Leaderboard v4(BFCL v4)」です。2つ目は、シングルストリームの性能を評価するための記録されたエージェント型コーディングの再生データです。
これらによって、デバイス上で動作するエージェントが直面する現実的な課題——ハードなコンテキスト制限の中で収めなければならない長く複雑化するツール呼び出しの対話や、単一のインタラクティブユーザーに対して応答性を感じさせる必要性など——を包括的に捉えることができます。
提出期限は2026年7月31日です。ハードウェアベンダー、エッジデバイスメーカー、推論システム専門家の方々の参加を歓迎し、結果の提出を通じてオンデヴァイス・エージェント推論の基準を引き上げていきましょう。
なぜエッジでエージェントAIなのか
テキスト生成を単発から多段階の自律型ワークロードへ移行する動きは、応用 AI における最も重要なトレンドの一つです。実際の自律型セッションとは、1 つのプロンプトと 1 つの回答で完結するものではなく、各ターンでツールの出力やモデルの応答が会話履歴に追加され続ける軌跡です。ここではモデルが短いツール呼び出しと長い推論を交互に行い、すべてのターンが直前の結果に厳密に依存します。
データセンター向け MLPerf 自律型ベンチマーク(9 月に実施予定)は、この複雑さを大規模で測定するものです。ここでは大規模な混合専門家モデル(MoE)や、累積的な多段階コンテキストが 10 万トークンを超える長期の軌跡を扱い、並行処理のスウィープを通じて GPU ごとのパレートフロンティアを生成します。
一方、エッジ環境は対照的な課題を抱えています。このベンチマークが狙うのはまさにその領域です。
・固定されたメモリと電力予算:限られたメモリを持つ単一の小型アクセラレーターで、モデルの重み、KV キャッシュ、活性化値をすべて保持する必要があります。フル精度の最先端モデルは収まらないため、モデルは量子化されます。
・1 つの進行中のリクエストのみ:エッジでの推論サービスは、数千もの並行セッションではなく、単一の対話型ユーザーが主役です。
・固定された提供コンテキストウィンドウ:参照環境では提供コンテキストを 32K トークンに固定します。これはデバイスの物理的な上限ではなく、制御されたベンチマークパラメータです。これにより、長期の軌跡がこの限界を飽和させることが可能になります。その結果、コンテキストの成長と切り捨ては、自律型ワークロードにおける主要な影響要因として測定されることになります。これはデバイスごとのメモリ容量に依存して変動するものではなく、明確に制御された条件での評価です。
「シングルユーザーのレイテンシ」を重視し、「集計スループット」は対象外です。単一のスロットを持つエッジデバイスでは、スループットとレイテンシは互いに反比例する関係にあるため、重要なのは 1 デバイスあたりの 1 トークンごとの TTFT(Time To First Token)、TPOT(Tokens Per Output Token)、そしてエンドツーエンドのターンレイテンシです。マルチストリームのデータセンターサーバーが最適化する集計 QPS やトークンスループットは、このベンチマークでは測定しません。
本ベンチマークは、データセンター向けエージェント仕様に含まれる「多ターン・エージェント手法」の用語、決定論的再生(deterministic replay)、JSONL データセットスキーマ、およびインライン精度チェックを引き継ぎつつ、エッジ環境に特化しています。具体的には、エッジモデルと量子化技術、シングルストリームの負荷パターン、レイテンシ中心の指標、そして統計的に堅牢な精度ゲートが適用されます。
モデル選定
参照モデルは「Qwen3.6-27B」です(https://qwen.ai/blog?id=qwen3.6-27b)。これは llama.cpp(コミット cfff1fc)を用いて、Q4_K_M GGUF 量子化された形式で提供されます(https://huggingface.co/unsloth/Qwen3.6-27B-GGUF)。このモデルを選定した理由は、Apache 2.0 ライセンスのオープンソースでありながら、ネイティブな MTP(Multi-Token Prediction)推測デコーディングヘッドを備え、そのサイズ以上の性能を発揮するツールコール対応モデルだからです。アリババによると、この密度型 27B モデルは、主要なコードベンチマークにおいて以前の 397B-MoE フラグシップモデルを上回る性能(SWE-bench Verified で 77.2%)を示しています(https://qwen.ai/blog?id=qwen3.6-27b)。さらに、Hugging Face や ModelScope での公式ウェイト公開に加え、llama.cpp で直接動作するコミュニティ製 GGUF ビルド(例:unsloth)も利用可能で、デプロイが容易です。
量子化は、エッジデバイスにおける決定的な選択です。Q4_K_M は 4 ビットの K-quant「Medium」ティアに分類され、重みは 1 値あたり 4 ビットで保存されます(BF16 に比べメモリ使用量が約 4 分の 1)。アテンションブロックはフィードフォワードブロックよりも高い精度で保持され、重要度に基づく (imatrix) キャリブレーションによって最も影響の大きい重みが維持されます。その結果、27B モデルを VRAM 約 16.5 GB で動作させることが可能になります(BF16 では約 54 GB 必要)。精度は約 2〜5% の低下にとどまりますが、この差が「エッジ GPU で動くか動かないか」を分けます。参考実行に使用された GGUF ファイルは、unsloth/Qwen3.6-27B-GGUF から提供されている Qwen3.6-27B-Q4_K_M.gguf です。
参照用サンプリングパラメータは以下の表の通りです。
| パラメータ | 値 |
|---|---|
| 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 |
このツール呼び出しワークロードでは、推論機能は意図的に無効化されています。これは単発の精度を低下させるだけでなく、所要時間が大幅に増加するためです(詳細は「精度評価指標」セクションをご参照ください)。本ベンチマークは複数のベンダーが提供する多様なエッジアクセラレーターで検証されており、ワークロードと手法が移植可能であることが確認されています。
ベンチマークタスク
本ベンチマークでは、異なる役割を担う 2 つのデータセットを使用します。
精度評価用データセットとして採用されるのは、Berkeley Function Calling Leaderboard v4(BFCL v4)です。これは、モデルが関数を正しく、決定論的に呼び出せるか、そして LLM による判定を介さずに検証できるかをテストするものです。
このベンチマークは、単一ターン(プロンプト 1 つに対して構造化されたツール呼び出し 1 つ)の要求を対象としており、3 つのカテゴリに分類されます。非ライブ(non_live)とライブ(live)は、それぞれゴールドラベルとの AST マッチングに基づいて採点され、ハルシネーション(hallucination)は利用可能なツールが関連しない場合にモデルが関数呼び出しを拒否するかどうかの二値チェックです。また、プロセス内 Python シミュレーターを用いたオプションのマルチターン・エージェント対話も含まれます。
カテゴリデータは、パブリックリポジトリ「gorilla-llm/gorilla-eval-set」から取得され、実行時に自動ダウンロードされます。採点対象となるゲートは単一ターンのセットのみで、カテゴリごとに安定した約 995 サンプルの推定値になるようサンプリングされています。具体的には、非ライブが 72%(約 712 サンプル)、ライブが 17%(約 171 サンプル)、ハルシネーションが 11%(約 112 サンプル)です。また、サブセットの下限値は 25 と設定されており、25 エントリー以下のサブセットはすべて完全に含まれます。
パフォーマンス用データセット
MLPerf エージェントベンチマークのサブセットであり、複数回にわたるエージェントによるコーディングの軌跡(astropy などの実リポジトリから抽出された SWE-bench スタイルのタスク)を記録したものです。これらはパフォーマンス負荷として決定論的に再生され、単一デバイスのエッジ環境での推論用にスケールされています。
参照セットは 20 件の会話(合計 1,007 ターン)で構成されており、どの軌跡も提供されるコンテキストの上限である 32K トークンを超過しないように設計されています。最大入力長は約 23.5K トークンです。オーバーフローが発生しないため、すべてのターンが正常に完了します。つまり、ドロップされたターンはゼロであり、単一のエッジデバイス上で並列度 1(一度にリクエストを一つだけ処理)で実行しても、適切な時間内に完了します。
このデータセットは、それ自体が正解の基準(グランドトゥルース)としても機能します。各軌跡で記録されたツール呼び出しは、推論遅延測定中に実行されるゼロコストのインライン精度チェック(実行された呼び出し間のマルチセット IOU)を駆動するため、正確性と遅延は同じパスから得られます。
リクエストとレスポンスの例
モデルの OpenAI 互換エンドポイント /v1/chat/completions に、利用可能なツールスキーマを含む単一ターンの関数呼び出しリクエストが送信されます。
}
,
{
"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」フィールドは文字列型で、値は「celsius」または「fahrenheit」のいずれかです。
必須項目として「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 チェッカーは、予測された呼び出し(関数名と各引数)を正解ラベルと比較します。これにより、スコアリングは正確かつ再現可能になります。
エージェント型コーディングの性能評価ワークロードでは、同様のメカニズムが複数回の対話軌跡に適用されます。モデルが bash ツールの呼び出しを発行し、ランナーがそれを記録します。その後、インラインチェッカーが正規化されたシェル実行ファイルと記録された正解軌跡との間のマルチセット交差率(IoU)をスコアリングします。
Performance Metrics
エッジベンチマークでは、GPU 全体の処理能力(スループット)の限界値ではなく、単一のアクセラレーター上で動作するシングルストリームの 1 トークンあたりのレイテンシを報告します。この評価では、1 人の模擬ユーザーがループ処理を行い、ターンを送信して完全なストリーミング応答を待ち、事前に記録されたターン間の待機時間を挟んで次のターンを送信するという流れを繰り返します。つまり、常にインフライト中のリクエストは 1 つのみ(target_concurrency = 1、ワーカー数 1、接続数 1)であり、llama.cpp サーバーのシングルスロット構成に合致しています。
報告されるメトリクスには、TTFT(最初のトークンまでの時間)、TPOT(出力トークンあたりの時間)、ターンごとのエンドツーエンドレイテンシ、および p50/p90/p99/max 値で表される ISL/OSL の分布が含まれます。
精度指標
精度は、統計的な信頼性を重視して BFCL v4 のシングルターンゲートスコアを採用しました。これは、全カテゴリから約 995 サンプルをサンプリングし、エッジデバイスでも合理的な時間で完了するように設計されています。シングルターンを選定した理由は、そのスコアがサンプル数 n が大きい場合や異なるデバイス間でも安定しているのに対し、小規模なマルチターンゲートは脆いためです。例えば、n=57 のマルチターンゲートでは 95% 信頼区間で約±11.6 ポイントの変動が生じ、Q4 量子化カーネルの違いによってデバイス間で評価結果が反転するケースさえあります。そのため、マルチターンはスコアリング対象外のリファレンスアーティファクトとしてオプションで保持されています。
参考となるシングルターンの精度(モデル:Qwen3.6-27B-Q4_K_M、シード値 42、温度 0;ハードウェアに依存せず、サーバーを毎回 freshly リスタートした 2 つのシード済み実行で同一の結果):
| カテゴリ | 精度 | 備考 |
|---|---|---|
| non_live (AST) | 82.59% | ~712 サンプル |
| live | 84.12% | ~171 サンプル |
| hallucination | 97.16% | ~112 サンプル |
ゲート指標は全体の 2 つがあります。1 つ目は「Overall」で、約 995 件のシングルターンサンプル全体におけるサンプル加重精度です。2 つ目は「Normalized」で、3 つのカテゴリスコアのカテゴリバランス型平均値(各カテゴリのサイズに関わらず等しくカウントされる)です。カテゴリごとの行はゲートではなく構成要素です。
合格・不合格の基準は、両方のゲート指標に対して 3% の片側バンドを適用するものです。提出された結果が Overall および Normalized のシングルターンスコアそれぞれについて、対応するリファレンス値の 0.97 倍以上(≥ 0.97 ×)であれば合格となります。なお、上限は設けられておらず、スコアが高ければ高いほど不合格になることはありません。
| ゲート指標 | リファレンス | 合格閾値 (0.97 倍) |
|---|---|---|
| Overall | 86.23% | ≥ 83.64% |
| non_live-normalized | 87.96% | ≥ 85.32% |
リファレンス提出設定では「Reasoning off(推論機能なし)」が採用されています。このツール呼び出しワークロードにおいては、サーバーサイドで推論機能を有効にしても精度にメリットはなく、むしろ実行時間が大幅に増加します。実際、精度のゲート基準で見ると、「Reasoning off」は 86.23% を記録する一方、「Reasoning on(推論機能あり)」では 78.19% と 8 ポイントも低下しています。また、パフォーマンス再プレイにおいても、「Reasoning on」はインライン IoU をわずかに +0.004 (0.6374 vs 0.6335) しか向上させず、実行時間は約 60% 長くなっています。
ベンチマークへの参加
これは、エッジハードウェアとソフトウェアスタックが、精度とレイテンシの両面で実際のマルチターン・ツール呼び出しワークロードをどのように処理できるかを示す絶好の機会です。MLPerf Inference v6.1 の提出は MLCommons 会員限定で受け付けています。2026 年 7 月 31 日までに結果を提出するには、MLCommons への加入が必要です。
• モデル:Qwen/Qwen3.6-27B を使用。unsloth/Qwen3.6-27B-GGUF リポジトリから Q4_K_M 量子化された「Qwen3.6-27B-Q4_K_M.gguf」をロードします。
• 精度評価用データセット:gorilla-llm/gorilla-eval-set(BFCL v4 のシングルターン)。ランタイム時に自動的にダウンロードされます。
• リファレンス実装:mlcommons/endpoints – examples/10_Edge_Agentic_Example/。必須設定ファイル「online_edge_full_run.yaml」を実行することで、同一サーバー上で性能と精度の両方を連続して評価できます。「-accuracy-only」オプションを指定すれば、ゲート機能のみを単独で実行可能です。
• 提出締切:2026 年 7 月 31 日。
このリファレンス実装は、OpenAI 互換の Chat Completions エンドポイントを駆動するため、llama.cpp の参照サーバーに限らず、任意の推論システムをベンチマークできます。エッジアクセラレーターをお持ちの方は、例の README に従うことで、リファレンスの精度とレイテンシの数値を再現可能です。皆様からの提出をお待ちしています!
謝辞
本ベンチマークの開発にあたり、MLCommons エッジ LLM タスクフォースおよび MLPerf Inference ワーキンググループからご助言をいただきましたことに感謝いたします。
この記事は「Call for Submission: Edge Agentic Inference Benchmark for MLPerf Inference v6.1」として、最初に MLCommons で公開されました。
原文を表示
The MLCommons Edge LLM Taskforce is excited to introduce a new Edge Agentic Inference benchmark for the MLPerf Inference v6.1 round. As agentic LLMs – coding copilots, robotics controllers, and private on-prem assistants – increasingly run on-device, measuring how well and how fast these models call tools under a real edge budget is more important than ever.
For this round we debut the Qwen3.6-27B model (released April 22, 2026), served as a Q4_K_M GGUF quantization (reference implementation’s format – submitters may use any allowed quantization that meets the accuracy threshold) on a single edge accelerator, paired with two complementary workloads: the Berkeley Function Calling Leaderboard v4 (BFCL v4) for a deterministic, judge-free accuracy gate, and a recorded agentic-coding replay for single-stream performance. Together they capture the messy reality of on-device agents: long, growing tool
calling conversations that must fit within a hard context wall and feel responsive to a single interactive user.
The submission deadline is July 31, 2026. We invite all hardware vendors, edge-device makers, and inference-system experts to submit results and help raise the bar for on-device agentic inference.
Why Agentic AI at the Edge
The shift from single-shot text generation to multi-turn agentic workloads is one of the most consequential trends in applied AI. A real agentic session is not one prompt and one answer – it is a trajectory where each turn appends tool outputs and model responses to a growing conversation history, the model alternates between short tool calls and longer reasoning, and every turn depends strictly on the one before it.
The datacenter MLPerf Agentic benchmark (coming up in September) measures this at scale – large mixture-of-experts models, long-horizon trajectories whose cumulative multi-turn context runs to 100K+ tokens, and a concurrency sweep that produces a per-GPU Pareto frontier. The edge regime is the opposite problem, and it is what this benchmark targets:
• A fixed memory and power budget: A single small accelerator (with a limited amount of memory) must hold weights, KV cache, and activations. Full-precision frontier models do not fit, so the model is quantized.
• A single in-flight request: Edge serving is dominated by one interactive user, not thousands of concurrent sessions.
• A fixed served context window. The reference fixes the served context at 32K tokens – a controlled benchmark parameter, not a device ceiling – so long trajectories can exhaust it. This makes context growth and truncation first-order, measured effects of the agentic workload rather than something that varies with per-device memory.
• Single-user latency, not aggregate throughput. On a single-slot edge device, throughput and latency are reciprocal to each other, so the metrics that matter are per-turn TTFT, TPOT, and end-to-end turn latency on one device – not the aggregate QPS/token throughput a multi-stream datacenter server optimizes for.
This benchmark inherits the multi-turn agentic methodology – terminology, deterministic replay, the JSONL dataset schema, and the inline accuracy check – from the datacenter agentic specification and specializes it to the edge: an edge model and quantization, a single-stream load pattern, latency-centric metrics, and a statistically robust accuracy gate.
Model Selection
The reference model is Qwen3.6-27B (https://qwen.ai/blog?id=qwen3.6-27b), served with llama.cpp (commit cfff1fc) as a Q4_K_M GGUF quantization (https://huggingface.co/unsloth/Qwen3.6-27B-GGUF). Qwen3.6 was selected because it is an open (Apache 2.0), capable tool-calling model with native MTP speculative-decoding head that punches above its size – a dense 27B that Alibaba reports (https://qwen.ai/blog?id=qwen3.6- 27b) beats the prior 397B-MoE flagship on major coding benchmarks (77.2% SWE-bench Verified), yet deploys easily: official weights on Hugging Face and ModelScope plus community GGUF builds (e.g. unsloth) that run directly under llama.cpp.
Quantization is the defining edge choice. Q4_K_M is a 4-bit K-quant “Medium” tier: weights are stored at 4 bits/value (a 4× memory reduction versus BF16), attention blocks are kept at higher precision than the feed-forward blocks, and importance-weighted (imatrix) calibration preserves the highest-impact weights. The result fits the 27B model in ~16.5 GB of VRAM (versus ~54 GB for BF16) at a ~2–5% accuracy cost – the difference between “runs on an edge GPU” and “does not.” The exact GGUF used for the reference runs is Qwen3.6-27B-Q4_K_M.gguf from unsloth/Qwen3.6-27B-GGUF.
Reference sampling parameters used are listed in the table below:
Parameter Value
temperature 0
top_k 1 (Moot under temperature=0)
top_p 1.0 (Moot under temperature=0)
seed 42
max_new_tokens 1024
repetition_penalty 1
reasoning off
context size 32768 (32K)
parallel slots 1
Reasoning is deliberately disabled on this tool-calling workload; it lowers single-turn accuracy while costing far more time (see Accuracy Metric section). The benchmark has been validated across a range of edge accelerators from multiple vendors, confirming that the workload and methodology are portable.
The Benchmark Task
The benchmark uses two datasets with distinct roles.
Accuracy dataset: The Berkeley Function Calling Leaderboard v4 (BFCL v4) tests whether the model calls functions correctly, deterministically, and without an LLM judge. It spans single-turn requests (one prompt → one structured tool call) in three categories – non_live and live (graded by AST match against gold labels) and hallucination (a binary check that the model refuses to call a function when the available tools are irrelevant) – and optional multi-turn agentic conversations against in-process Python simulators. The categories are drawn from the public gorilla-llm/gorilla-eval-set (auto-downloaded at runtime). The scored gate is the single turn set only, per-category sampled to a stable ~995-sample point estimate: non_live 72% (~712 samples), live17% (~171), and hallucination11% (~112), with a subset_floor of 25 so any subset of ≤ 25 entries is taken in full.
Performance dataset. A subset of the MLPerf Agentic benchmark – recorded multi-turn agentic coding trajectories (SWE-bench-style tasks drawn from real repositories e.g., astropy), replayed deterministically as a performance workload, and scaled for single-device edge serving. The reference set comprises 20 conversations / 1,007 turns, sized so that no trajectory overflows the 32K-token served context (peak input length ~23.5K tokens). Because nothing overflows, every turn completes: the run is valid with zero dropped turns, and a single pass at concurrency 1 (one request in flight at a time) completes in a reasonable time on a single edge device. The dataset also serves as its own ground truth – each trajectory’s recorded tool calls drive a zero-cost inline accuracy check (multiset IOU of the executed calls) that runs during the latency measurement, so correctness and latency come from the same pass.
Example Request and Response
A single-turn function-calling request is sent to the model’s OpenAI-compatible /v1/chat/completions endpoint, carrying the available tool schemas:
},
{
"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"]
}
}
}
]
}
The model responds with a structured tool call:
{
"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’s AST checker compares the predicted call – function name and each argument – against the gold label, so scoring is exact and reproducible. In the agentic-coding performance workload, the same mechanism applies to multi-turn trajectories: the model emits bash tool calls, the runner records them, and the inline checker scores the multiset intersection-over union (IoU) of the canonicalized shell executables against the recorded ground-truth trajectory.
Performance Metrics
The edge benchmark reports single-stream, per-turn latency on a single accelerator rather than a per-GPU throughput frontier. A single simulated user replays trajectories closed-loop: send a turn, wait for the full streamed response, pause for the pre-recorded inter-turn delay, send the next turn – exactly one in-flight request at all times (target_concurrency = 1, one worker, one connection), matching the single-slot llama.cpp server. The reported metrics are TTFT (time to first token), TPOT (time per output token), end-to-end latency per turn, and ISL/OSL distributions, as p50/p90/p99/max.
Accuracy Metric
Accuracy is the scored BFCL v4 single-turn gate, chosen for statistical robustness: the full set of single-turn categories is sampled to ~995 samples, completing in a reasonable time on an edge device. Single-turn was chosen because its score is stable at large n and across devices, whereas a small multi-turn gate is brittle – an n=57 multi-turn gate carries a ~±11.6 pp 95% confidence interval, and Q4 quantization-kernel differences cause per-entry verdicts to flip across devices. Multi-turn is retained as an optional, non-scored reference artifact.
Reference single-turn accuracy (Qwen3.6-27B-Q4_K_M, seed 42, temperature 0; hardware independent, and identical across two seeded runs with a freshly restarted server each pass):
CategoryAccuracyNotes
non_live (AST)82.59%~712 samples
live84.12%~171 samples
hallucination97.16%~112 samples
Overall (~995)86.23%gated metric (sample weighted)
non_live-normalized87.96%gated metric (mean of the above three categories)
There are two gated metrics: Overall, the sample-weighted accuracy across all ~995 single-turn samples, and Normalized, the category-balanced mean of the three category scores (so each category counts equally regardless of size). The per-category rows are components, not gates.
The pass/fail criterion is a 3% one-sided band applied to both gated metrics: a submission passes only if its Overall and Normalized single-turn scores are each ≥ 0.97 × their respective references, with no upper bound (a higher score never fails).
Gated metricReferencePass threshold (0.97 ×)
Overall86.23%≥ 83.64%
non_live-normalized87.96%≥ 85.32%
Reasoning off is the reference submission config. On this tool-calling workload, enabling server-side reasoning gives no accuracy benefit and costs far more wall-clock: on the accuracy gate, reasoning-off scores 86.23% versus reasoning-on’s 78.19% – an 8-point drop – and on the performance replay, reasoning-on moves inline IoU by only +0.004 (0.6374 vs 0.6335) while taking ~60% longer run-time.
Join the Benchmark
This is your opportunity to show how your edge hardware and software stack runs real multi-turn tool-calling workloads – on both accuracy and latency. Submissions for MLPerf Inference v6.1 are open to MLCommons members. Join MLCommons to submit your results by July 31, 2026.
• Model: Qwen/Qwen3.6-27B, served as a Q4_K_M GGUF – Qwen3.6-27B-Q4_K_M.gguf from unsloth/Qwen3.6-27B-GGUF.
• Accuracy dataset: gorilla-llm/gorilla-eval-set (BFCL v4 single-turn), auto-downloaded at runtime.
• Reference implementation: mlcommons/endpoints – examples/10_Edge_Agentic_Example/. A single mandated config (online_edge_full_run.yaml) runs performance and accuracy back-to-back against the same server; –accuracy-only runs the gate alone.
• Submission deadline: July 31, 2026.
The reference implementation drives any OpenAI-compatible Chat Completions endpoint, so you can benchmark arbitrary inference systems – not just the llama.cpp reference server. Anyone with an edge accelerator can reproduce the reference accuracy and latency numbers by following the example README. We look forward to your submissions!
Acknowledgements
We thank the MLCommons Edge LLM Taskforce and the MLPerf Inference Working Group for their feedback and guidance in developing this benchmark.
The post Call for Submission: Edge Agentic Inference Benchmark for MLPerf Inference v6.1 appeared first on MLCommons.
AI算出
主要ニュースainew評価標準
AI エージェント推論の基準となる新たなベンチマークが具体化され、Qwen3.6-27B という特定のモデル名とバージョンが明記されているため、新規性と検索価値は極めて高い。ただし、日本企業や日本固有の事情に関する言及がないため、日本の関連性は低く設定する。
6つの評価軸を見る
- AI関連度
- 100
- 情報源の信頼性
- 25
- 新規性
- 75
- 調べる価値
- 75
- 重複の少なさ
- 100
- 日本での有用性
- 25
関連記事
News to Guide
ニュースの次に確認する
発表内容を、現在の料金や仕様と照らし合わせられる関連ガイドです。
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み