MLPerf Inference迈向智能体时代：新增多轮Agentic Inference基准

引言：推理基准需要跟上智能体应用

MLPerf Inference基准套件正在随AI部署形态的变化而演进。早期推理基准主要覆盖图像分类、目标检测、语音识别、推荐系统以及单轮语言生成等任务。这些负载依然重要，但已经不足以代表大语言模型在生产环境中增长最快的一类用法：multi-turn agentic inference，也就是多轮智能体推理。

以coding assistant为例，它远不只是回答一次查询。一个代码智能体通常会先阅读issue，检查文件，执行命令，观察失败结果，修改代码，然后反复迭代。类似地，workflow agent会收集客户信息、调用工具、解释返回结果、追问补充问题，并持续推进直到任务完成。两类任务的共同点是：负载不再是互相独立的请求，而是一条trajectory，即由多个相互依赖的turn组成的序列，每次请求都会包含截至当前的完整对话历史。

这种变化给模型服务带来了四个具体挑战：

• 上下文持续增长：随着trajectory推进，prefill开销和KV-cache压力会不断上升。
• KV-cache reuse成为关键优化：缓存复用直接影响性能和能效。
• 输出长度高度不稳定：有时只是简短的工具调用，有时则是很长的推理轨迹。
• turn之间存在依赖：吞吐量不再只是独立请求速率，而是闭环任务推进能力。

图1：多轮agentic inference场景示意，一个任务会经历多个相互依赖的turn。

为覆盖这类新负载，Agentic Inference benchmark被加入MLPerf Endpoints框架。它保留MLPerf一贯的测量原则，同时定义了面向该工作负载的关键组成部分，包括模型选择、数据集构成、多轮负载生成、输出验证，以及对prefix caching、speculative decoding等优化手段的约束。

术语说明

• Turn：一次由客户端发起的用户请求或工具请求，以及模型针对该请求生成的响应。
• Trajectory：一个任务或模拟用户对应的有序turn序列；后续turn会包含此前累积的对话历史。

模型选择：覆盖不同架构与服务行为

该基准需要能够处理长上下文、具备thinking能力的LLM，用来压测智能体应用中的典型服务行为：不断增长的上下文、KV-cache复用、可变输出长度，以及严格的多轮依赖。MLCommons为本基准选择了Kimi K2.6和Qwen3.6-35B-A3B。

Kimi K2.6具备领先的代码能力，模型规模也更接近主流前沿agentic system；Qwen3.6-35B-A3B则更加紧凑，引入新的Gated DeltaNet（GDN）架构，并在其规模下展现出突出的编码性能。两者共同覆盖了不同的服务行为、架构选择和speculative decoding路径。需要注意的是，两个模型使用相同方法和数据集分别评测，但不会混合运行，也不会合并为单一分数。

表1：模型元数据与基准设置。

数据集与任务选择：编码与工作流双场景

Agentic Inference benchmark的数据集组合了两个智能体领域，用于触发不同的基础设施瓶颈。整体包含613条multi-turn trajectories，其中包括113条agentic coding trajectories和500条agentic workflow trajectories。在参考数据集中，这些trajectory共包含30,335个客户端发起的turn和30,328个assistant turn。

MLCommons强调，使用真实采集轨迹进行基准测试，可以更贴近生产环境中的服务栈行为，包括speculative decoding在真实多轮流量下的表现，以及expert-rank balancing在实际负载中的效果。

图2：Agentic Inference benchmark覆盖编码智能体与工作流智能体两类多轮轨迹。

表2：数据集构成与主要压力点。

Agentic Coding：来自DeepSWE的代码工程轨迹

agentic coding traces来自DataCurve（datacurve.ai）的DeepSWE dataset。该数据集围绕仓库级bug和功能需求构建软件工程任务。典型轨迹从用户描述问题开始，随后assistant会通过一系列bash commands检查代码仓库：搜索文件、阅读源码、运行测试、观察错误、修改实现，并不断迭代。

这类轨迹的特点是深度很大：median trajectory通常包含数十个turn。随着命令输出、文件内容和测试日志不断累积，对话历史会持续增长，因此非常适合考察长上下文调度和KV-cache容量压力。

Agentic Workflow：面向企业客服与编排场景

Workato agentic workflow traces来自企业客户支持和业务编排场景。它们模拟客户请求帮助，agent通过工具检索订单、追踪物流、检查政策、升级工单或解决账户问题。

与编码轨迹相比，这类workflow trajectory通常更浅，但包含更大的shared system prompt，其中包括大量工具定义和业务规则。相关轨迹由Workato提供。Workato是面向企业的agentic control and execution plane，这些数据为合成轨迹，建模自Workato在为企业客户编排客服agent过程中的生产经验。

为什么要混合两类负载？

• Coding traces会在大量turn中快速拉长上下文。
• Workflow traces从较大的公共prefix开始，随后增长相对较慢。
• Coding主要压测KV-cache capacity和long-context scheduling。
• Workflow主要压测shared-prefix reuse和routing locality。
• Combined workload可以防止系统只针对某一种agentic traffic shape进行优化，并进一步考察context-aware routing能力。

客户端设计：让MLPerf Endpoints支持多轮闭环负载

为运行完整端到端智能体负载，MLCommons在MLPerf Endpoints中引入了多轮支持。提交者只需要使用vLLM、SGLang、TensorRT-LLM或其他服务框架启动一个OpenAI-compatible endpoint，然后将客户端指向该endpoint，即可完成端到端基准测试。

客户端负责处理多轮行为，核心机制包括：

• Closed-loop replay：一个活跃对话每次只发起一个turn，并等待模型完整响应后才进入下一turn。
• Target concurrency：负载生成器控制活跃用户或对话数量，同时不破坏turn之间的依赖关系。
• Inter-turn delay：使用数据集中提供的工具或用户turn等待时间，以保持真实节奏；这部分延迟不会计入模型服务延迟。
• Conversation-aware routing：每条trajectory都会发送稳定的X-Session-ID请求头，便于路由器保持KV-cache locality。
• Cache salting：在system prompt周围加入确定性salt marker，允许同一trajectory内部合法复用，同时阻止跨trajectory的无效复用，确保基准更接近生产负载。
• Deterministic prompt reconstruction：未来prompt由预录制数据集构建，而不是依赖模型实时输出，从而保证性能运行可复现，同时仍然测量生成输出。
• Generated token cache clearing：为公平比较不同平台，基准通过引入空白字符清除KV cache中的已生成token，确保性能结果不依赖生成这些轨迹时使用的系统。

核心意义：从单次请求吞吐转向任务推进效率

Agentic Inference benchmark的价值在于，它把评测重点从传统的独立请求处理能力，扩展到真实agent应用中更关键的闭环执行效率。对于服务系统而言，能否在长上下文、多轮依赖、缓存复用、工具调用节奏和可变输出长度之间取得平衡，将直接决定智能体应用的可用性和成本效率。

随着coding assistant、企业workflow agent和自动化执行系统进入生产环境，类似Agentic Inference这样的基准将成为衡量推理平台能力的重要补充。它不仅测试模型本身，也测试vLLM、SGLang、TensorRT-LLM等推理服务栈在真实多轮流量中的调度、缓存和路由能力。