Call for Submission: Edge Agentic Inference Benchmark for MLPerf Inference v6.1
TL;DR · AI 摘要
MLCommons推出MLPerf Inference v6.1边缘代理推理基准,使用Qwen3.6-27B量化模型评估边缘设备多轮对话性能。
核心要点
- Qwen3.6-27B模型采用Q4_K_M GGUF量化格式部署
- 基准测试包含BFCL v4和agentic-coding replay双工作负载
- 边缘设备内存和功率预算限制模型必须量化部署
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- Edge Agentic Inference Benchmark
- 核心机制
- Qwen3.6-27B量化部署
- 双工作负载设计
- 评估指标
- BFCL v4准确率门控
- 单用户延迟指标
- 边缘挑战
- 内存/功率预算限制
- 上下文窗口截断
金句 / Highlights
值得收藏与分享的关键句。
Qwen3.6-27B模型量化为Q4_K_M GGUF格式以适应边缘设备内存限制
BFCL v4提供确定性准确率门控,agentic-coding replay测试单流性能
边缘设备固定32K token上下文窗口导致长轨迹需严格截断处理
提交征稿:MLPerf推理v6.1边缘智能代理推理基准 - MLCommons
提交征稿:MLPerf推理v6.1边缘智能代理推理基准
在单个边缘加速器上对多轮智能代理大语言模型进行基准测试
2026年7月9日
MLCommons边缘大语言模型特别工作组很高兴推出MLPerf推理v6.1轮次的边缘智能代理推理基准。随着智能代理大语言模型(如代码协作者、机器人控制器和私有本地助理)越来越多地在设备端运行,衡量这些模型在真实边缘预算下调用工具的效率和速度变得前所未有的重要。
本轮次我们将首次推出Qwen3.6-27B模型(2026年4月22日发布),该模型以Q4_K_M GGUF量化格式(参考实现的格式 – 提交者可使用任何符合精度阈值的允许量化方式)部署在单个边缘加速器上,搭配两个互补的工作负载:用于确定性、无需裁判的精度门控的伯克利函数调用排行榜v4(BFCL v4),以及用于单流性能评估的智能代理编码回放记录。这两者共同捕捉了设备端代理的复杂现实:必须在严格上下文限制内完成的长对话,且需对单个交互用户保持响应性。
提交截止日期为2026年7月31日。我们邀请所有硬件厂商、边缘设备制造商和推理系统专家提交结果,共同提升设备端智能代理推理的性能标准。
为何要在边缘部署智能代理AI
从单次文本生成向多轮智能代理工作负载的转变,是应用AI领域最重要的趋势之一。真实的智能代理会话并非一个提示和一个回答,而是一个轨迹:每次交互都在增长的对话历史中追加工具输出和模型响应,模型在短工具调用和长推理之间交替,且每次交互严格依赖前一次交互。
数据中心MLPerf智能代理基准(9月发布)将在大规模场景下衡量这一特性 – 大型专家混合模型、累计多轮上下文达到10万+ token的长轨迹,以及生成每GPU帕累托前沿的并发扫描。而边缘场景则是完全不同的挑战,这正是本基准的目标:
• 固定的内存和功耗预算:单个小型加速器(内存有限)必须容纳权重、KV缓存和激活值。全精度前沿模型无法容纳,因此需要量化模型。
• 单个在途请求:边缘服务主要面向单个交互用户,而非数千个并发会话。
• 固定的服务上下文窗口:参考实现将服务上下文固定为32K token – 这是一个受控的基准参数,而非设备上限 – 长轨迹可能耗尽该窗口。这使得上下文增长和截断成为首要的、可测量的智能代理工作负载特性,而非取决于设备内存的变量。
• 单用户延迟,而非聚合吞吐量。在单插槽边缘设备上,吞吐量和延迟互为倒数,因此关键指标是单设备的每轮首令牌延迟(TTFT)、每轮总延迟(TPOT)和端到端轮次延迟 – 而非多流数据中心服务器优化的聚合QPS/token吞吐量。
该基准继承了数据中心智能体规范中的多轮智能体方法论——术语、确定性回放、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)进行服务。选择Qwen3.6的原因在于其作为开源(Apache 2.0)工具调用模型的卓越能力,具备原生MTP推测解码头,其27B稠密模型性能超越阿里巴巴此前发布的397B-MoE旗舰模型(在主要编程基准测试中达到77.2%的SWE-bench Verified指标),同时部署便捷:Hugging Face和ModelScope官方权重及社区GGUF构建版本(如unsloth)均可在llama.cpp下直接运行。
量化是边缘场景的核心选择。Q4_K_M属于4位K-量化"中等"级别:权重以4位/值存储(相比BF16实现4倍内存缩减),注意力模块的精度高于前馈模块,重要性加权(imatrix)校准保留了最具影响力的权重。该方案使27B模型在约16.5GB显存中运行(相比BF16的约54GB),仅需付出约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 | 关闭 context size | 32768(32K) parallel slots |
在该工具调用工作负载中,刻意禁用推理功能;虽然会降低单轮准确性,但能显著减少时间消耗(详见准确性指标章节)。该基准已在多家厂商的边缘加速器上验证,证实该工作负载和方法论具有可移植性。
基准任务
基准测试使用两个具有不同角色的数据集。
准确性数据集:伯克利函数调用排行榜v4(BFCL v4)测试模型是否能正确、确定性地调用函数且无需LLM评委。该数据集包含三类单轮请求(一个提示→一个结构化工具调用):非实时(non_live)和实时(live,通过AST匹配黄金标签评分)以及幻觉(二元检查模型在可用工具无关时是否拒绝调用函数)——并包含与进程内Python模拟器的可选多轮智能体对话。这些类别取自公开的gorilla-llm/gorilla-eval-set数据集(运行时自动下载)。评分仅针对单轮数据集,按类别采样至稳定的约995样本估计值:非实时72%(约712样本),实时17%(约171),幻觉11%(约112),且子集下限设为25,因此任何≤25条目的子集都会完整保留。
性能数据集。该数据集是 MLPerf Agentic 基准的一个子集 – 记录了多轮代理编码轨迹(例如从真实仓库中提取的 SWE-bench 风格任务,如 astropy),以确定性方式重放作为性能工作负载,并针对单设备边缘服务进行扩展。参考数据集包含 20 次对话 / 1,007 轮交互,规模设计确保任何轨迹都不会超出 32K-token 的服务上下文限制(输入长度峰值约 23.5K tokens)。由于没有溢出情况,所有轮次均可完整执行:运行过程有效且零轮次丢失,在单设备边缘设备上以并发度 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": { "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 检查器将预测调用(函数名和每个参数)与黄金标注进行比对,因此评分精确且可复现。在代理编码性能工作负载中,相同机制适用于多轮轨迹:模型生成 bash 工具调用,执行器记录这些调用,内联检查器将规范化的 shell 可执行文件的多重集交并比(IoU)与记录的真实轨迹进行比对并打分。
性能指标
边缘基准测试报告的是单加速器上的单流、每轮延迟,而非每 GPU 的吞吐量指标。单个模拟用户闭环重放轨迹:发送一轮交互,等待完整流式响应,暂停预录制的轮次间延迟,发送下一轮交互 – 始终仅有一个在途请求(target_concurrency = 1,单线程 worker,单连接),与单槽位 llama.cpp 服务器匹配。报告指标包括 TTFT(首次生成令牌时间)、TPOT(每输出令牌耗时)、每轮端到端延迟,以及 ISL/OSL 分布(p50/p90/p99/max)。
准确性指标
准确性采用统计稳健性更高的 BFCL v4 单轮门控指标进行评分:所有单轮类别样本量约 995 个,可在边缘设备上合理时间内完成。选择单轮指标是因为其在大样本量和不同设备上的评分稳定,而小规模多轮门控指标则存在脆弱性——n=57 的多轮门控指标具有约 ±11.6 pp 的 95% 置信区间,Q4 量化内核差异会导致不同设备上的单条目判定结果翻转。多轮指标作为非评分参考指标保留。
参考单轮准确率(Qwen3.6-27B-Q4_K_M,随机种子 42,温度 0;与硬件无关,两次独立运行结果一致):
| 类别 | 准确率 | 备注 | |--------------|----------|--------------| | non_live (AST) | 82.59% | 约 712 个样本 | | live | 84.12% | 约 171 个样本 | | hallucination | 97.16% | 约 112 个样本 | | 总体 (~995) | 86.23% | 门控指标(样本加权) | | non_live-normalized | 87.96% | 门控指标(上述三个类别的平均值) |
存在两种门控指标:总体指标为所有约 995 个单轮样本的样本加权准确率;归一化指标为三个类别得分的类别平衡平均值(每个类别权重相等,与类别规模无关)。各分类行数据为组成指标,非门控指标。
通过/失败标准是对两个门控指标应用 3% 的单边区间:提交结果只有在总体和归一化单轮得分分别 ≥ 0.97 × 对应参考值时才通过,无上限(得分越高不会失败)。
| 门控指标 | 参考值 | 通过阈值(0.97 ×) | |--------------|----------|---------------------| | 总体 | ≥ 83.64% | ≥ 85.32% |
"Reasoning off" 是参考提交配置。在该工具调用工作负载中,启用服务器端推理不会带来准确率提升,反而显著增加运行时间:在准确率门控指标中,关闭推理得分为 86.23%,而开启推理仅为 78.19%(下降 8 个百分点);在性能回放中,开启推理仅使 IoU 提升 0.004(0.6374 vs 0.6335),但运行时间延长约 60%。
参与基准测试
这是展示您的边缘硬件和软件栈在准确率和延迟方面运行真实多轮工具调用工作负载的绝佳机会。MLPerf Inference v6.1 的提交面向 MLCommons 成员开放。请于 2026 年 7 月 31 日前加入 MLCommons 提交您的结果。
• 模型:Qwen/Qwen3.6-27B,以 Q4_K_M GGUF 格式提供 – Qwen3.6-27B-Q4_K_M.gguf 来自 unsloth/Qwen3.6-27B-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 边缘大语言模型工作组和 MLPerf Inference 工作组在制定此基准测试过程中提供的反馈和指导。
MLPerf Inference
作者
Palanivel Guruva reddiar (任务组主席,NVIDIA),Zihao Kong (NVIDIA),Zhihan Jiang (NVIDIA),Harshil Vagadia (NVIDIA),Azeez Ishaqui (Atlas Inference),Thomas Braun (Atlas Inference)
分享
- 通过电子邮件分享
- 在Facebook上分享
- 在LinkedIn上分享
- 在X上分享
- 复制链接