Agentic Inference for MLPerf Inference

TL;DR · AI 摘要
MLPerf新增多轮代理推理基准,通过Kimi和Qwen模型评估LLM服务系统在上下文增长、KV缓存复用等场景下的性能。
核心要点
- 代理推理基准需支持上下文增长和KV缓存复用优化
- Kimi K2.6与Qwen3.6-35B-A3B模型分别代表不同架构的领先系统
- 基准测试包含多轮对话轨迹和工具调用输出验证
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- MLPerf代理推理基准
- 核心挑战
- 上下文增长
- KV缓存复用
- 输出长度变化
- 回合依赖性
- 模型选择
- Kimi K2.6 (MoE+MLA)
- Qwen3.6-35B-A3B (MoE+GDN)
金句 / Highlights
值得收藏与分享的关键句。
上下文增长导致KV-cache压力随轨迹递增,成为性能瓶颈
Qwen3.6-35B-A3B采用Gated DeltaNet架构实现紧凑模型的卓越编码性能
基准测试通过独立模型评估避免结果混淆,不进行模型组合评分
MLPerf 推理的代理推理 - MLCommons
MLPerf 推理的代理推理
用于衡量在扩展上下文场景下LLM服务系统以及闭环代理工作流的新多轮基准测试。
2026年7月8日
引言
MLPerf 推理基准套件必须与AI部署模式同步演进。早期的推理基准主要聚焦于图像分类、目标检测、语音识别、推荐系统和单轮语言生成。这些工作负载仍然重要,但它们已无法涵盖当前大语言模型在生产环境中最快增长的应用方式之一:多轮代理推理。
例如,一个代码助手远比单个查询复杂。代理需要阅读问题、检查文件、运行命令、观察失败、编辑代码,并可能多次迭代。类似地,工作流代理会收集客户信息、调用工具、解释结果、提出后续问题,直到任务完成。在这两种情况下,工作负载都表现为轨迹:一系列相互依赖的轮次,每个请求都包含到当前为止的对话历史。
这从四个方面改变了服务系统的挑战:
- 轨迹中上下文持续增长,因此预填充和KV缓存压力会随时间增加。
- KV缓存复用现在成为性能和效率的关键服务优化手段。
- 输出长度差异显著,从紧凑的工具调用到长篇推理轨迹。
- 轮次依赖性使吞吐量成为闭环进度的衡量标准,而非独立请求速率。
图1. 多轮代理推理场景示意图。
代理推理基准将此类工作负载纳入MLPerf Endpoints框架。它保持MLPerf通用的测量原则,同时定义了工作负载特定的组件:模型选择、数据集组成、多轮负载生成、输出验证,以及前缀缓存和推测解码等优化的约束条件。
术语定义
- 轮次(Turn):一个客户端发出的用户或工具请求及其对应的模型响应。
- 轨迹(Trajectory):一个任务或模拟用户的一系列有序轮次;后续轮次包含累积的对话历史。
模型选择
该基准需要具备长上下文处理能力和推理能力的LLM,以考验代理应用的服务行为:上下文扩展、KV缓存复用、输出长度变化和严格的轮次依赖性。为此,我们选择了Kimi K2.6和Qwen3.6-35B-A3B模型。Kimi K2.6具备最先进的代码处理能力,其大型模型配置代表了领先的代理系统;Qwen3.6-35B-A3B体积更紧凑,引入了新的门控DeltaNet(GDN)架构和卓越的代码处理性能。这使基准覆盖了不同的服务行为、架构选择和推测解码路径。两个模型均采用相同的方法论和数据集进行评估。为避免歧义,每个模型生成独立结果;两个模型不会同时运行或合并为单一评分。
| 模型 | Kimi K2.6 | Qwen3.6-35B-A3B | |------|-----------|-----------------| | 架构 | MoE + MLA | MoE + Gated DeltaNet/Attention | | 参数 | 1T / 32B active | 35B / 3B active | | 上下文 | 262,144 tokens | 262,144 tokens | | 设置 | Thinking; temp=1.0; top_p=0.95; preserve_thinking | temp=1.0; top_p=0.95; top_k=20; presence=1.5; repetition=1.0; preserve_thinking | | 推测解码 | nvidia/Kimi-K2.6-Eagle3 | head |
模型内部原生的MTP支持
表1. 模型元数据和基准设置
数据集和任务选择
基准数据集结合了两个智能领域,分别针对不同的基础设施瓶颈。它们共同包含613条多轮轨迹:113条智能编码轨迹和500条智能工作流轨迹。在参考数据集中,这些轨迹包含30,335个客户端发出的回合和30,328个助手回合。通过使用真实采集的轨迹进行基准测试,工作负载模拟了服务栈中的实际行为,包括在真实多轮流量下推测解码和专家排名平衡的表现。
领域 | 规模 | 主要压力点 --- | --- | --- 智能编码 | 113条轨迹;15,981个客户端回合 | 深度轨迹;增长上下文;键值缓存容量 智能工作流 | 500条轨迹;4,316个客户端回合 | 大型共享提示;前缀重叠;前缀缓存效率
表2. 数据集组成和平均标记统计
智能编码轨迹来自DataCurve(datacurve.ai)的DeepSWE数据集,该数据集包含围绕仓库级错误和功能请求构建的软件工程任务。典型的轨迹以用户描述问题的请求开始,随后助手通过一系列bash命令调查仓库。代理搜索文件、阅读代码、运行测试、观察错误、编辑实现并迭代。这些轨迹深度较大:中位数轨迹包含数十个回合,随着命令输出、文件内容和测试日志的累积,对话历史持续增长。
Workato的智能工作流轨迹来自企业客户支持和编排场景。它们代表模拟客户请求帮助时的交互,代理使用工具检索订单、跟踪运输、检查政策、升级案例或解决账户问题。这些轨迹通常比编码轨迹浅,但包含大量共享系统提示,包含许多工具定义和业务规则。智能工作流轨迹由Workato提供,Workato是企业的智能控制和执行平面。这些数据是基于Workato生产经验编排企业客户支持代理的合成轨迹。
两个领域故意设计为不同:
- 编码轨迹在多轮交互中激增增长。
- 工作流轨迹以大型公共前缀开始,增长较慢。
- 编码压力测试键值缓存容量和长上下文调度。
- 工作流压力测试共享前缀复用和路由局部性。
- 组合工作负载防止系统仅针对单一智能流量模式进行优化,并压力测试上下文感知路由。
客户端设计
我们向MLPerf Endpoints引入了多轮支持,使基准能够针对标准服务栈驱动完整的端到端智能工作负载。提交者只需使用vLLM、SGLang、TensorRT-LLM或其他服务框架启动一个与OpenAI兼容的端点,然后将客户端指向该端点进行完整的端到端基准测试。
客户端处理多轮行为:
- 闭环回放:一个活跃对话一次发出一个回合,并等待完整模型响应后才进行下一轮。
- 目标并发:负载生成器控制活跃用户或对话数量,同时不破坏回合依赖关系。
- 轮次间延迟:数据集提供的等待时间在工具或用户轮次之间保留真实节奏,不将延迟计入模型服务延迟。
- 对话感知路由:为每条轨迹发送稳定的 X-Session-ID 头,使路由器能够保持键值缓存(KV-cache)局部性。
- 缓存加盐:系统提示符周围的确定性盐标记允许轨迹内有效重用,同时阻止轨迹间无效重用,确保基准测试能代表生产工作负载。
- 确定性提示重建:未来的提示基于预录制数据集而非实时模型输出构建,这在保持性能运行可重复性的同时仍能测量生成输出。
- 生成令牌缓存清除:为实现对所有平台的公平基准测试,通过引入空格字符将生成的令牌从 KV 缓存中清除,确保性能与生成轨迹的系统无关。
性能指标
主要性能图表是帕累托曲线,每个点对应固定并发量的基准测试结果。提交者需按照 MLPerf Endpoints 规则提交完整的帕累托曲线。
- Y轴:每系统每秒输出令牌数,衡量聚合服务吞吐量。
- X轴:每用户每秒输出令牌数,计算方式为每轨迹输出令牌数 /(端到端时间 - 总延迟)。
两个轴代表了服务系统的互补视角。X轴(每用户每秒输出令牌数)反映单个代理完成任务的速度;向右移动表示任务完成更快。Y轴(每系统每秒输出令牌数)反映所有活跃代理完成的总工作量;向上移动表示聚合吞吐量更高、系统利用率更高。随着并发量增加,系统可能完成更多总工作量,但每个代理完成任务的速度可能变慢。帕累托曲线使这种权衡可见。
图2. 展示智能体推理性能的图表
准确性指标
准确性以三级层次结构强制执行,使帕累托曲线衡量可用的智能体进展,而非较短、质量较低或更易服务的响应。
- OSL均值:防止系统通过截断响应或改变答案长度分布来提高吞吐量。检查要求生成输出保留工作负载预期的平均输出序列长度。
- 内联准确性:捕捉报告的精确性能配置期间的行为偏移。它基于性能运行本身生成的输出,并将其与数据集中保留的真实值进行比较,包括编码工具调用动作检查和工作流意图-代码检查,因此无需单独推理过程。
- 独立准确性:验证超越轮次级相似性的任务级能力。独立评估将使用 SWE-bench Verified 数据集中的 200 个任务,检查提交的模型配置是否能端到端解决代表性任务。
帕累托曲线上的每个点都必须运行所有三个层次,且每个分数必须满足预定义阈值。每个层次和 Kimi K2.6、Qwen3.6-35B-A3B 的阈值分别定义。
准确性等级
内联准确性
63.08%
55.86%
OSL每轮次均值范围
[404,494]
[355,434]
独立准确性
76.5%
67.0%
表3. 暂定的准确值,可能会更改。
参考实现
提交者只需使用vLLM、SGLang、TensorRT-LLM或其他服务框架启动一个兼容OpenAI的服务器,然后将MLPerf Endpoints客户端指向该端点以运行完整基准测试。MLPerf Endpoints智能体推理README文件包含示例配置、命令行和设置步骤。
结论
智能体推理是当今AI领域发展最快的應用之一,其复杂程度远超现有的单轮文本生成。智能体工作流具有独特的服务模式约束:上下文扩展、严格的轮次依赖、工具中介延迟、共享前缀、长尾轨迹,以及必须在与性能相同的配置上运行的输出质量检查。
智能体推理基准以可复现的形式将这些约束引入MLPerf。通过将深度编码轨迹与共享前缀工作流轨迹相结合,该基准测试衡量服务系统是否能在保证硬件效率的同时,为真实多轮用户提供有效进展。
随着智能体应用在生产大语言模型流量中占比增加,行业需要衡量真正关键系统性能的基准:保持缓存局部性、调度长上下文、维持输出质量,以及平衡整体吞吐量与用户进度。该基准是实现这一衡量标准的重要一步。如果您的团队正在构建多轮智能体的服务基础设施,请加入MLCommons以获取参考实现并提交结果。
参考文献
- MLPerf Endpoints 仓库
- MLPerf Endpoints 推理规则和帕累托集合方法论
- MLPerf Endpoints 智能体推理参考实现
- SWE-bench 验证基准
- Workato 智能体工作流和企业任务定义
- Datacurve 的 DeepSWE 数据集
分类
MLPerf Endpoints MLPerf Inference 新闻
作者
Harshil Vagadia(任务组主席,NVIDIA),Tianmu Li(任务组主席,Intel),Zhaozhuo Xu(Workato),Qi Yang Huang(Workato),Zhihan Jiang(NVIDIA),Stanley Phoong Cheong Kwan(NVIDIA),Poovaiah Palangappa(AMD),Rita Brugarolas Brufau(AMD),Miro Hodak(AMD),Tom St. John(Gimlet Labs)
分享
- 通过电子邮件分享
- 在Facebook上分享
- 在LinkedIn上分享
- 在X上分享
- 复制链接