面向 LLM 推理的 Agentic Benchmark：指标与方法

面向 LLM 推理的 Agentic Benchmark 衡量模型服务系统在 AI agent 流量下的表现。它不判断 agent 是否修复了 bug 或完成了工作流，而是测量承载每次模型调用的基础设施，包括延迟、吞吐量、cache 复用、并发能力与成本。

这一目标会改变 workload。传统推理基准测试可以发送 input 和 output 长度固定的独立 prompt；Agent Benchmark 则必须表示完整会话，其中上下文随轮次增长，请求共享长 prefix，tool 执行带来停顿，subagent 产生并行分支。后续请求通常要等前序请求完成后才能开始。

AgentX 是 InferenceX 面向这类 workload 的开放基准测试。它把自愿提供的编码 agent trace 转换为保护隐私的请求形状，再通过 AIPerf 进行确定性回放，用相同场景比较完整的软硬件推理配置。

什么是 Agentic Inference Benchmark？

Agentic Inference Benchmark 是面向多轮 agent 流量的系统基准测试。被测系统包括 accelerator、服务器拓扑、推理引擎、模型 checkpoint、精度、并行策略、cache 配置与请求调度器。

它回答以下问题：

• 一套部署能同时服务多少个 agent 会话？
• 每个 agent 需要等待多久才能收到首 token？
• 每个活跃 agent 接收 output token 的速度是多少？
• 在目标延迟下，每颗 Chip 能提供多少 output 吞吐量？
• 重复 prefix 会命中 HBM、host memory，还是触发重新计算？
• 在可用的响应速度下，每百万 token 的成本是多少？

“Benchmark”也常用于 agent 任务评估，因此必须说明测试范围。这两类测试回答不同问题：

AgentX 对应第二类。任务语义与完成质量需要单独评估。

为什么固定序列推理基准测试无法代表 Agent 流量？

固定序列测试仍然适合做受控比较。例如，8K input 和 1K output workload 能隔离常见请求形状，并让不同配置容易复现，但它无法表示持续运行的 agent 会话。

这些差异可能改变系统排序。更大的 HBM 能让长时间存活的 KV cache 保持驻留；更有效的 prefix caching 可以避免重新处理数十万 prompt token；对独立 prompt 影响较小的 scheduler 与 router 开销，也可能随活跃会话的数量和长度增长。

Agent Benchmark 是一张请求依赖图

Agent 会话不是扁平的 prompt 列表。主 agent 轮次形成依赖链；某一轮可以启动一个或多个 subagent，主链随后可能等待这些分支完成；辅助调用也可以独立运行而不汇入主链。

AgentX 通过闭环模式回放这张图。每个客户端只有在依赖的前序工作完成后才发送下一个可执行请求。服务器越快，会话越早推进并产生后续工作。当 subagent 扇出时，瞬时 HTTP 请求数可以高于客户端 concurrency；分支完成后，请求数会再次下降。

因此，AgentX concurrency 表示活跃 agent 客户端数量，并不是固定 request batch。若多个客户端同时存在活跃 subagent，concurrency 50 的运行可能拥有超过 50 个 in-flight 请求。

AgentX 如何构建可复现 Workload？

AgentX 通过四个阶段，把已记录的会话结构转换为不含原始内容的回放。

1. 采集请求形状与时间

自愿启用的 HTTP proxy 会记录请求到达与完成时间、input 和 output token 数、conversation ID 与 subagent ID。公开数据不包含 prompt、源代码、tool argument 或 tool result。

2. 保留 Prefix，而不保留内容

每段 input 会被转换为以 64-token block 为单位的会话内 hash 链。相同 block ID 会保留不同轮次间的 prefix 关系。回放前，AIPerf 使用确定性的合成编码与 tool-use token 替换这些 block。

3. 重建依赖关系

主 agent 请求形成线性链；subagent 请求形成带有 spawn 和 join 依赖的独立链；记录中的轮次间停顿会重现 tool 执行与等待其他工作的时间。回放保留客户端可见的顺序与重叠关系，但不会推断 provider 内部事件。

4. 在不同系统上回放同一场景

固定 seed 控制会话采样、回放起点与合成 payload。每套软硬件配置都接收相同场景定义，因此曲线差异来自推理系统，而不是人工编写的 prompt batch。

AgentX v1.0 从自愿提供的 Claude Code trace 中筛选出 393 个公开会话。每个会话至少包含 20 个请求，并且同时运行的 subagent 不超过 10 个。

Full 变体保留最高 1M token 的上下文。256K 变体会移除超过上限的请求，同时保留其余请求的时间关系与 subagent 重叠。AgentX 方法论公开了数据集规则、图表与来源链接。

保证比较有效的 Benchmark 控制

长时间运行的 agent workload 对初始状态、cache 内容、speculative decoding 与 host memory 十分敏感。AgentX 通过明确规则锁定这些变量。

Cache Warmup 与测量窗口

固定 seed 会在每段会话 25% 至 75% 的位置选择起点。max_tokens=1 的 primer 会建立活跃主 agent 与 subagent 的 prefix，随后每条回放 lane 再完成 10 个 warmup 请求，之后才开始测量。

对外结果只统计随后一小时的 profiling 窗口。每次循环回放都会加入唯一 cache-bust 标记，避免无关会话逐步形成共享 prefix。

合成 Payload 与 Speculative Decoding

合成 token 会保留长度和 prefix 结构，却无法自然复现 draft token acceptance。AgentX 因此针对每组模型、speculative 方法、draft length 与 thinking mode，使用 SPEED-Bench 编码类别测得的 acceptance length。该数值记录在带版本的 golden 文件中，并通过推理引擎控制项应用。

这样可以把推理服务性能与合成文本偶然造成的 speculator acceptance 差异分开。

DRAM 与 KV Cache Offload

Host memory 容量会影响长 prefix 应该重新加载还是重新计算。没有标准化 DRAM 配置的服务器上限为 3 TB；GB200 NVL72、GB300 NVL72 与 TPUv7 等标准系统可以使用实际装机容量。每种基准测试配置只能按 GPU 占比使用对应的 host memory。

回放格式与依赖规则记录在 AIPerf WEKA trace 指南中。

Agentic Benchmark 应该测量哪些指标？

单个数字无法描述 agent 服务。应该在完整 concurrency sweep 中同时报告吞吐量、延迟与交互性。

百分位数不能省略。如果部分 agent 分支需要在长 prefill 后排队，较低的平均 TTFT 可能与很差的 p90 或 p99 同时出现。总 output 吞吐量上升时，单个客户端接收 token 的速度也可能下降。

应该读取完整的吞吐量与交互性曲线

AgentX 扫描不同的并发 agent 客户端数量，并绘制相应运行点。低并发通常有利于单客户端响应速度；提高并发可以改善 batching 与总吞吐量，直到排队、内存压力或其他瓶颈开始降低交互性。

有效结果是 Pareto frontier，而不是唯一的最大吞吐量点。硬件 A 可能在低交互性下给出最高 tok/s/chip，硬件 B 却可能在交互式编码产品所需的响应速度下领先。

闭环回放还意味着更快的配置能在相同 profiling 小时内推进到采样会话的更后位置，因此实际请求组合可能略有变化，低并发时尤其明显。结果应包含完整曲线，并使用足够并发降低采样噪声。

Agent 流量会考验推理栈的哪些部分？

Agentic 推理会暴露固定 prompt batch 容易低估的瓶颈。

• **KV-cache 容量：**长上下文与大量活跃会话会让大型 cache 驻留更久。
• **Prefix-cache 正确性：**错误命中会产生错误状态，漏掉命中则会重复昂贵的 prefill。
• **Offload 带宽：**从 host memory 移动长 prefix 可能比重新计算更快，但传输粒度与 descriptor 开销会影响结果。
• **Scheduler 公平性：**并行 subagent 可以提高总吞吐量，同时让某条分支等待过久。
• **Router 与 frontend CPU：**Prefix matching、过期项清理、序列化与 streamed response 处理都会随活跃会话状态增长。
• **长上下文 kernel：**Attention、sparse attention、normalization 与 graph capture 路径可能随 sequence length 变化而表现不同。
• **Speculative decoding：**Acceptance 控制与 scheduler 生命周期会同时影响吞吐量和交互性。

AgentX 优化追踪页记录了 vLLM、SGLang、TensorRT-LLM、ATOM、Dynamo 与 KV-cache 系统中由该 workload 暴露的具体改进。

如何比较 AgentX 结果？

比较双方应使用同一套场景约束：

1. 对齐模型、checkpoint、精度与 thinking mode。
2. 对齐 AgentX 数据集变体与上下文上限。
3. 记录推理引擎、container image、并行策略与 speculative decoding 方法。
4. 应用相同的 golden acceptance-length 规则。
5. 对齐 DRAM 容量、KV-cache offload policy 与按比例分配内存的规则。
6. 使用相同 seed、warmup 流程、profiling 时长与客户端 concurrency sweep。
7. 当系统规模不同时，同时比较每颗 Chip 与整套系统结果。
8. 在相同 p90 interactivity 或延迟目标下比较。
9. 保留失败与不稳定配置，而不是只报告成功运行点。

相同交互性下的比较通常比峰值吞吐量更有用。它直接回答部署问题：在用户需要的响应速度下，哪套系统每颗 Chip 或每美元能够服务更多 agent 工作？

这项 Agent Benchmark 能回答什么，不能回答什么？

AgentX 可以测量 trace 衍生 agent workload 下的推理容量、响应速度、cache 复用、内存压力、吞吐量与成本。它可以显示软件更新是否改善了相同硬件上的长上下文多轮服务，也可以比较不同硬件拓扑如何改变有效 frontier。

AgentX 无法判断模型是否写出了正确代码、选择了正确工具、遵守了业务规则，或完成了原始任务。合成 payload 会有意移除这些语义。Agent 质量应使用任务评估，推理性能则使用 AgentX。两类分数描述不同的系统问题，不应混为一个总分。

常见问题

什么是面向 LLM 推理的 Agentic Benchmark？

它是一项系统基准测试，用于衡量推理栈如何服务多轮 agent 流量。测试会回放不断增长的上下文、共享 prefix、tool 等待与 subagent 分支，并报告延迟、吞吐量、交互性、cache 行为、容量与成本。

Agentic Benchmark 与固定序列推理基准测试有何区别？

固定序列测试会发送 input 和 output 长度明确的独立请求。Agentic Benchmark 回放的是相互依赖的会话，其中请求长度、时间、prefix 复用与并行分支会持续变化，因此更接近真实 agent 产生的服务条件。

AgentX Benchmark 测量什么？

AgentX 使用从编码 agent trace 衍生的流量，测量完整推理配置。它扫描并发 agent 客户端数量，并报告每颗 Chip 的 output 吞吐量、p90 interactivity、TTFT、ITL、cache 行为与推理服务成本。

AgentX 为什么使用闭环并发？

Agent 无法提前发出所有轮次，因为后续动作依赖前序结果。在闭环回放中，每个客户端会在依赖完成后发送下一个可执行请求，从而保留服务器速度与会话产生后续工作的时间关系。

Agent 推理最重要的指标有哪些？

应结合 output 吞吐量、p90 interactivity、TTFT、ITL、cache 来源分布、queue depth 与成本，并在相同延迟或交互性目标下比较完整 concurrency 曲线。单个最大吞吐量点无法描述交互式部署。

Agent Benchmark 会衡量模型或 Agent 质量吗？

部分 Benchmark 会，但 AgentX 不会。AgentX 使用保留 workload 形状的合成 payload 来测量推理系统性能。任务正确性、工具选择与 policy 合规性需要单独的 agent 评估。

本文由英文原文翻译而来，如有歧义以英文版为准。所有文章版权归 © SemiAnalysis 所有，保留所有权利。覆盖应用源代码的 AGPL-3.0 许可证不适用于文章内容。