← 返回 AgentX

Field guide / AI infrastructure

AgentX 方法论

AgentX 将自愿采集的 Claude Code 代理 trace 转换为确定性的 AIPerf 工作负载。本页说明采集元数据如何生成回放,以及有效基准测试结果所遵循的控制规则。

个公开会话
393
每个 hash block 的 token 数
64
profiling 窗口
1 小时
固定 seed 起点范围
25–75%

数据采集

参与者主动启用 HTTP 代理后,代理会记录请求到达与完成时间、input 和 output token 数、conversation ID 与 subagent ID。公开语料不包含 prompt、源代码、tool argument 或 tool result。

代理以 64-token block 为单位,将每段 input 表示为会话内串联 hash。同一会话中相同的 block ID 会保留共享 prefix。回放前,AIPerf 会使用确定性的合成编码与 tool-use token 替换这些 block。

客户端无法看到服务端 chat template、专有 tokenizer、服务端 tool、加密的 reasoning 内容,也无法精确得知图片和文档最终展开成多少 token。AgentX 使用针对模型校准的 padding 和确定性 placeholder 处理这些字段;其中不包含原始 prompt、代码或 tool payload。

语料仪表板显示 8,271 个会话、341 万个请求、6132.7 亿 token、99% cache-hit rate 及 token 来源占比。
筛选数据集时使用的语料快照。图中的费用按该快照和公开 API 标价估算,并非基准测试输出指标。查看原始分辨率图片
按序列长度展示重建 hash token 与服务商 token 数的中位比值,并分别给出整体和各模型结果。
393 个会话的 135,282 个请求中,重建 token 数与服务商 token 数之比的中位数为 1.004。阴影表示 p25–p75 区间,不代表每个请求都有固定误差上限。查看原始分辨率图片

v1.0 数据集

v1.0 于 2026 年 6 月 21 日构建,共包含 393 个会话。每个入选会话至少有 20 个请求,Claude Code 版本不低于 2.1.139,并且同时运行的 subagent 不超过 10 个。处理流程会移除完全重复的请求、用于安全监控或标题生成的短 classifier 调用,以及重建后 input 超过 990k token 的请求。

full 变体保留最高 1M token 的上下文。256k 变体会移除超过上限的请求,同时保留其余请求的相对时间与 subagent 重叠关系。两者均采用 AIPerf 可读取的 WEKA trace 格式。

带注释的 AgentX trace JSON,包含 session ID、64-token hash block、请求时间、input 和 output 数量及一个 subagent group。
一条删节后的 WEKA 记录。Block ID 只在单个会话内有效;重复 ID 表示后续请求共享的 prompt prefix。查看原始分辨率图片
v1.0 数据集中轮次间延迟、input sequence length 与 output sequence length 的对数分布。
v1.0 公开语料的请求分布。单请求 input token 中位数为 142,016,output token 中位数为 444。查看原始分辨率图片
AgentX 256k 数据集变体中轮次间延迟、input 长度与 output 长度的对数分布。
移除超过 256k input 上限的请求后,该变体保留 68,266 个请求。input token 中位数为 88,768,output token 中位数为 376。查看原始分辨率图片
Subagent wall-clock duration 以及每个会话中 subagent group 数量的分布。
175 个包含 subagent 的会话共有 1,697 个 group。Group 时长中位数为 2.27 分钟;这些会话的 group 数中位数为 4。查看原始分辨率图片
AgentX 256k 数据集变体中的 subagent group 时长与每会话 group 数分布。
256k 变体保留 1,697 个 subagent group。时长中位数为 2.27 分钟,p95 为 18.5 分钟。查看原始分辨率图片

从 trace 到回放图

AIPerf 将每条 trace 转换为有向无环图(DAG)。主 agent 请求形成线性链;subagent 请求形成独立链,在符合条件的父请求完成后启动,并在下一个依赖它的主 agent 请求前汇合。一次性辅助请求可以在没有 join edge 的情况下运行。

Trace 记录请求时间戳和可观测的分支 ID,但不记录触发分支的 tool 级事件。回放会保留请求顺序、分支重叠与轮次间延迟,但不会推断服务端内部因果关系。

线性四请求 trace 根据记录时间转换为回放依赖链。
不含 subagent 的会话会转换为线性依赖链,并保留记录中的轮次间延迟。查看原始分辨率图片
一个包含双请求 subagent 的主 agent trace 被转换为带 join gate 的依赖图。
Subagent 分支在第一个主请求后启动,并在下一个依赖它的主请求前通过 join gate 汇合。查看原始分辨率图片
两条 subagent 链从主 agent 分支,并在同一个依赖 gate 汇合。
两条 subagent 链在同一个主请求完成后启动,并在主链继续前共用一个 join gate。查看原始分辨率图片
两个并行 subagent 汇合到主 agent,另有一个不会汇合的一次性辅助请求。
并行 subagent 共享 join gate;辅助请求独立运行,不带 join edge。查看原始分辨率图片
两条 subagent 链与一个辅助请求并行运行,随后通过三路 join 汇合。
Flat-spawn group 并行运行两条 subagent 链和一个辅助请求,三者汇合后主链才继续执行。查看原始分辨率图片
两条 subagent 链与两个普通 sidecar 请求并行运行,随后汇合到同一个 join gate。
两个不带 duration 元数据的普通 sidecar 请求与两条 subagent 链并行运行;回放会在同一个 join 等待四者完成。查看原始分辨率图片
四个并行 subagent 按两个 join point 分组,并带有辅助请求的回放依赖图。
多个 subagent group 保留各自的 join point,辅助分支仍保持独立。查看原始分辨率图片

Concurrency 与结果指标

Concurrency 表示同时运行的 agent 客户端数量,不是固定的 HTTP request batch。一个客户端可能展开为多个 subagent 请求,因此服务器上的瞬时请求数可以高于配置的客户端 concurrency。

AgentX 采用 closed-loop 模式:依赖满足后,客户端才提交下一个可执行请求。更快的系统会在同一小时内推进到采样会话的更后位置,因此实际请求组合可能略有不同,低并发时尤为明显。报告结果时应同时给出吞吐量、首 token 延迟(TTFT)和 interactivity;单一 latency 值无法描述完整运行。

约一小时内的请求队列深度,分别显示并发 AgentX 回放中的 running、waiting 与 total request。
在 50 个客户端的回放中,会话图持续展开和汇合,running 与 waiting HTTP 请求数也随之变化。查看原始分辨率图片
B200 vLLM MiniMax-M3 在不同客户端 concurrency 下的单 Chip 吞吐量与 p90 interactivity 曲线。
每个标记点对应一种客户端 concurrency。提高 concurrency 会增加吞吐量,同时降低每个客户端的 interactivity。查看原始分辨率图片

Warmup、计时与确定性

固定 seed 会在每段会话记录时长的 25% 至 75% 区间内均匀选择回放起点。随后使用 max_tokens=1 的 primer 建立当前主 agent 与 subagent 的 prefix,再让每条回放 lane 完成 10 个额外 warmup 请求,最后才开启测量 barrier。

对外指标只统计随后一小时的 profiling 窗口。Seed 会固定会话采样、起点和合成 payload。每次循环使用唯一的 cache-bust 标记,避免无关回放逐步形成共享 prefix。

四条回放轨迹,显示固定 seed 的 25–75% warmup 起点,以及主 agent 和 subagent 活跃流的 primer 请求。
固定 seed 在阴影所示的 25–75% 区间选择 t*;primer 会在 profiling 前建立活跃 prefix 状态。查看原始分辨率图片

合成 payload 与 speculative decoding

合成 token 会保留 input 长度和 prefix 结构,但其 draft token 接受情况与自然模型输出不同。因此,AgentX 会针对每组模型、speculative 方法、draft length 与 thinking mode,使用 SPEED-Bench 编码类别测得的 acceptance length。

推理引擎提供强制 acceptance 控制,InferenceX 则把选定值记录在带版本的 golden acceptance-length 文件中。这样可以把推理系统性能与合成 payload 引起的 acceptance 波动分开。AgentX 不评估模型回答质量。

SGLang、TensorRT-LLM、vLLM 与 ATOM 中加入强制 speculative-decoding acceptance 控制的已合并 PR。
这些已合并的推理引擎变更提供所需控制,使不同 serving stack 可以采用相同的 acceptance 假设。查看原始分辨率图片

DRAM offload 规则

KV cache offload 会改变长会话可用的容量。没有标准化 DRAM 配置的服务器上限为 3 TB;GB200 NVL72、GB300 NVL72 和 TPUv7 等标准化系统可使用实际装机容量。

每种基准测试配置只能按其 GPU 占比使用对应的 host DRAM,避免较小的 GPU 分区占用整台服务器的内存预算。

适用范围与复现

回放会保留客户端可见的请求长度、时间关系、分支结构和 KV prefix 复用,但无法复现服务端隐藏转换或原始会话的语义内容。比较不同系统时,应使用公开语料和锁定的场景配置。

主要来源