持续运行的开源智能体推理基准测试,受到万亿美元级、吉瓦规模 Token 工厂运营方的信赖
全球迈向 AGI 的进程呈指数级加速,软件开发和模型发布也日新月异。静态基准测试很快就会过时;参与者提交的软件镜像往往是为基准测试专门构建的,无法反映真实应用场景中的性能。
InferenceX™(原名 InferenceMAX)是我们建立的独立、厂商中立且可复现的基准测试平台。它覆盖 ML 社区实际可用的各类 AI 加速器和服务栈,测试固定序列推理服务以及 AgentX 长上下文、多轮智能体编码工作负载。
我们的开放数据与洞察已被 ML 社区广泛采用,用户包括万亿美元级 Token 工厂和 AI 实验室中负责容量规划与战略的团队,以及多家价值数十亿美元的 NeoCloud。更多详情请参阅以下文章: InferenceX v1、 InferenceX v2。
AgentX:基准测试的工作原理
AgentX 按照编码智能体实际使用模型的方式衡量推理性能。这类会话持续时间长、轮次多,会共享前缀并在轮次之间停顿;多个子智能体还可能并行运行,KV cache 也会被反复复用。AgentX 是 AIPerf 中的一种测试场景:它按照固定配置回放公开的智能体编码轨迹,使不同服务栈能够在同一工作负载下进行比较。
本 FAQ 介绍该基准测试的运行方式、确保结果可比的配置,以及最容易影响测试结果的部署细节。
AgentX 衡量什么?
传统负载测试通常以固定请求速率发送互不相关的单轮 prompt。AgentX 则维持指定数量的完整会话树。根编码会话可以创建子会话、等待子会话结束,再继续执行。每一轮都会携带累计的消息历史,从而重现真实智能体系统中的长共享前缀与突发式 fan-out。
prompt 文本是合成的,但工作负载形态来自真实会话记录:输入与输出长度、前缀共享关系、子智能体拓扑以及轮次间时间间隔。这样既不会回放用户的私密内容,又保留了对调度器、路由器和 prefix cache 真正重要的特征。
工作负载来自哪里?
该场景使用 SemiAnalysis 公开的 Weka 格式智能体编码轨迹语料。需要进行可复现比较时,应选择带日期的固定语料,而不是滚动更新的别名。_256k 变体会移除超过 256K token 范围的单个请求,更适合上下文窗口约为 256K 的服务器。
简短名称 semianalysis_cc_traces_weka 指向不含子智能体的旧版语料。若要测试 AgentX 的 fan-out 行为,请使用带日期的语料或 with_subagents 别名。
场景锁定了哪些配置?
传入 --scenario inferencex-agentx-mvp 会选择智能体回放模式,并强制执行决定结果可比性的配置:
- 开启 streaming,以便测量首 token 延迟(TTFT)和 token 间延迟(ITL)。
- ignore_eos:true 要求服务器生成指定长度的输出,而不是提前停止。
- 保留原始轮次间延迟;仅将整个系统的全局空闲时间限制在 10 秒以内。
- first_turn_prefix cache busting 为每次回放的会话加入唯一首轮标记,避免虚假的跨会话 cache hit,同时保留会话内部的 cache 复用。
- 有效测试至少运行 900 秒,默认运行 1,800 秒。
- 正式测量前通过 warmup 建立深层 prefix。
- 每次运行都会使用 seed,并将其记录在产物中。
最简运行命令是什么?
请根据部署情况替换 URL、模型、语料和 --concurrency 的值。AIPerf 会补齐场景默认值,并将结果写入 ./artifacts/。固定 --random-seed 可精确复现采样并复用重建后的数据集 cache;当模型名称无法解析为 Hugging Face tokenizer 时,请额外传入 --tokenizer。
aiperf profile \
--scenario inferencex-agentx-mvp \
--url http://localhost:8000 \
--model YOUR_MODEL \
--endpoint-type chat \
--public-dataset semianalysis_cc_traces_weka_062126 \
--concurrency 256为什么 AgentX 使用 streaming chat completions?
记录的工作负载由多轮消息数组表示,与 OpenAI 兼容的 chat-completions endpoint 自然匹配。Streaming 可以观测首 token 和 token 间时序;非 streaming 响应无法提供这些核心延迟指标。
--use-server-token-count 只改变指标统计方式。当本地 tokenizer 因版本差异或客户端不可见的 chat template 开销而与服务器不一致时,该 flag 会采用服务器返回的 usage 字段,不会改变 prompt 构造。
并发数表示什么?
并发数表示同时存活的会话树数量,而不是正在处理的 HTTP 请求数。一个会话可能 fan-out 为多个子会话,因此瞬时请求并发数可以高于配置值。
该场景有意不提供请求速率控制。负载由活跃会话数、记录的思考时间和 fan-out 模式共同决定,因此 --concurrency 是主要的负载调节参数。
为什么第一次运行可能很久?
发送流量前,AIPerf 会下载语料,并将其重建为完成 token 化且带有 cache 结构的会话树。结果会存入采用内存映射的磁盘 cache。只要语料、tokenizer、重建配置、条目数量和 seed 相同,后续测试通常可以在数秒内恢复准备好的数据集。
冷启动时应同时提高两个配置阶段的超时时间。随后依次执行数据集配置、warmup、定时 profiling 和 drain/export。基准测试时长只涵盖 profiling 阶段,因此总耗时会更长。
export AIPERF_DATASET_CONFIGURATION_TIMEOUT=1800
export AIPERF_SERVICE_PROFILE_CONFIGURE_TIMEOUT=1800可以先运行一次简短的冒烟测试(smoke test)吗?
有效测试不能短于 900 秒。低成本有效检查可以降低并发数,但仍需保留 900 秒下限。--num-dataset-entries 能减少重建工作量,但会改变工作负载,不应将这种结果用于正式比较或提交。
如需在几分钟内检查连通性,可使用 --unsafe-override 并缩短测试时长,同时接受 invalid 标记。保留完整语料并固定 seed,可让后续有效测试复用重建后的数据集 cache。
如何确认负载生成器(load generator)不是瓶颈?
AIPerf 会将工作分配到多个 worker 进程,并每两秒上报 worker 健康状态。应将高 CPU 警告视为客户端饱和信号;在信任结果前,需要增加客户端 CPU 核心数或负载生成器主机。
--show-trace-timing 可以区分等待连接池中空闲连接的时间与等待服务器返回首字节的时间。worker 的 CPU 使用率正常且连接池阻塞很少,才有充分依据认为瓶颈位于服务器端。
为什么运行过程中会出现连接重置(connection reset)?
客户端与服务器的 keep-alive 配置可能不一致。如果 AIPerf 保留空闲连接的时间比服务器更长,客户端可能复用已经关闭的 socket。应将客户端 keep-alive 设置为低于服务器值。该问题通常出现在 profiling 阶段,因为 warmup 连接的空闲时间较短。
export AIPERF_HTTP_KEEPALIVE_TIMEOUT=4多副本应如何路由?
当路由器连接多个副本时,必须使用会话感知路由。如果同一会话的各轮落在不同 worker 上,prefix cache 复用会大幅下降,基准测试最终衡量的是路由分散程度,而不是服务栈的 cache 能力。
AIPerf 会为每个会话分配稳定的 correlation ID;子智能体则拥有各自的稳定 ID。这些配置改变请求落点而非请求内容,因此不会被场景锁定。
- 前缀感知路由根据消息历史匹配已缓存的前缀。SGLang Model Gateway 提供 cache_aware,Dynamo 通过 --router-mode kv 提供 KV-aware routing。
- Sticky routing 将 AIPerf correlation ID 映射到路由器 session header,可对接 SGLang 的 X-SMG-Routing-Key、Dynamo session header 和通用 X-Session-ID。
应重点查看哪些指标?
AgentX 会报告 TTFT、ITL、端到端延迟、输出吞吐量和错误率,同时提供 prefix cache 行为、上下文溢出、会话与子智能体执行、worker 饱和状态以及场景合规性。
比较测试前必须检查 submission_valid。上下文溢出率过高、测试被取消、使用 unsafe override 或其他场景违规,都可能使一个已经生成完整产物的测试失效。
实用原则
- 让语料与服务器上下文窗口匹配;约 256K 的服务器优先使用 _256k 语料。
- 正式比较使用带日期的固定语料和固定 seed。
- 保持 cache busting 开启;关闭后,循环使用轨迹会夸大 cache-hit 结果。
- 保留记录的时序;压缩单条轨迹的延迟会改变 cache TTL 行为和会话重叠程度。
- 在判断结果受服务器限制前,先监控客户端 CPU 和连接池等待时间。
- 所有多副本部署都应使用会话感知路由。
- 不要解读合成 prompt 的语义;基准测试保留的是 token 与 cache 结构,而非文本含义。
致谢与延伸阅读
本文改编自 AIPerf AgentX 文档。上游源文件由 NVIDIA 维护,并采用 Apache-2.0 许可证。
AgentX 是使用 AIPerf 实现的 SemiAnalysis InferenceX 基准测试。关于当前 CLI、场景锁定规则、环境变量和产物 schema,请以 AIPerf 的文档与实现为准。
- SemiAnalysis AgentX:基准测试的工作原理(FAQ)— NVIDIA AIPerf 文档
- AgentX MVP 教程源文件 — ai-dynamo/aiperf
- NVIDIA AIPerf 代码仓库
感谢 AIPerf 团队实现并记录这一场景,也感谢 Callan Fox 与 Weka 为底层智能体编码轨迹所做的工作。
可复现性
仪表板上的每个数据点都由公开的 GitHub Actions 工作流生成。测试配置、日志、产物及其对应的数据库记录彼此关联,任何人都可以核查结果来源、重新运行测试,或基于现有配置创建新的基准测试。
- 1测试配置已提交到仓库。 每组硬件、框架、模型和精度组合都对应一个提交到公开仓库的 shell 脚本。脚本中固定了所用镜像、命令行参数和并行度。
- 2在真实硬件上运行。 GitHub Actions 将工作流调度到实际的目标加速器(NVIDIA、AMD 等)上,并在运行过程中公开流式输出完整的任务日志。
- 3上传产物。 请求延迟、token 计数、芯片 功耗遥测数据和评估样本均附加到运行页面。GitHub Actions 保留这些产物 90 天,同时每周发布完整基准测试数据库的快照作为公开的 GitHub Release,以实现更长期的可审计性。
- 4将结果导入仪表板。 运行成功后,结果将写入数据库并在仪表板中展示。每个图表的提示框都提供对应的 GitHub Actions 运行记录链接。点击任意数据点即可核查其来源。
常见问题
- 什么是 InferenceX?
InferenceX(原名 InferenceMAX)持续衡量各类芯片和软件栈的智能体推理与固定序列推理性能。AgentX 是其长上下文多轮编码场景。配置发生变化时,基准测试会重新运行。
- InferenceX 由谁开发?
InferenceX 由独立半导体与 AI 研究机构 SemiAnalysis 构建,受到 Anyscale、MiniMax、Moonshot Kimi、Alibaba Qwen、Zhipu GLM、OpenAI、AMD Lisa Su、NVIDIA Jensen、Microsoft、Meta、Oracle、vLLM、GPU Mode、PyTorch、CoreWeave、SGLang、WEKA、Stanford、Hugging Face、Lambda、Red Hat、SambaNova、TileRT、Mooncake 的支持与信赖。基准测试代码、数据和仪表板均在 GitHub 上开源。
- InferenceX 测试了哪些芯片?
新加速器可用后,我们会持续将其纳入基准测试。
- NVIDIA: VR200, H100, H200, B200, B300, GB200, GB300, RTX6000PRO
- AMD: MI300X, MI325X, MI355X
- OpenAI: JALAPENO
- Google: TPUV7
- 测试了哪些 AI 模型?
各模型会在其支持的固定序列配置(1k/1k、1k/8k 和 8k/1k token)和多个并发级别下进行测试。对于支持 AgentX 且有相应数据的模型,现有结果还涵盖 AgentX 长上下文、多轮智能体编程测试。
- DeepSeek-R1-0528
- gpt-oss-120b
- Llama-3.3-70B-Instruct-FP8
- Qwen-3.5-397B-A17B
- Qwen3.8-Flash-Next
- Qwen3.8-27B
- Qwen3.8-27B-Eager
- Kimi-K2.5
- Kimi-K2.6
- Kimi-K2.7-Code
- Kimi-K3
- MiniMax-M2.5
- MiniMax-M2.7
- MiniMax-M3
- GLM-5
- GLM-5.1
- GLM-5.2
- GLM-5.2
- DeepSeek-V4-Pro
- DeepSeek-V4.1-Flash
- 测试了哪些推理框架和配置?
- 框架:ATOM、Vera Rubin、Dynamo SGLang、Dynamo TRTLLM、Dynamo vLLM、llm-d vLLM、Mooncake ATOMesh、MoRI SGLang、July、SGLang、TileRT、Teacup、TRTLLM、vLLM、MTP、AIPerf
- 精度:FP4、FP8、BF16、INT4
- 运行时:CUDA、ROCm
- 分离式推理(独立的 prefill/decode 芯片池)
- 多 token 预测(MTP)
- 面向 MoE 模型的宽专家并行(Wide Expert Parallelism)
- InferenceX 测量哪些指标?
- 交互性(tok/s/user)
- 每芯片 token 吞吐量(tok/s/chip)
- 每芯片输入和输出吞吐量
- 每兆瓦 token 吞吐量(tok/s/MW)
- P99 首 token 延迟(TTFT)
- AgentX 场景的端到端延迟、token 间延迟(ITL)、输出吞吐量、prefix cache 行为以及会话与子智能体执行情况
- 每百万 token 成本(总计、输入、输出)——涵盖超大规模云大批量自有和租赁定价
- 每 token 能耗(焦耳,总计、输入、输出)
- 用户自定义成本和功耗计算
- 端到端归一化交互性与交互性有何区别?
交互性衡量生成开始后 token 的流式输出速度,近似为 token 间延迟(ITL)的倒数。端到端归一化交互性衡量整个请求期间的有效 token 速率,其中包含首 token 延迟(TTFT):输出 token 数 / 端到端延迟,近似为 1 /(ITL + TTFT / 输出 token 数)。两者的单位均为 tok/s/user。TTFT 越长,归一化指标越低,短回答受到的影响尤其明显。这里的“归一化”是指按输出长度归一,并非 0–1 分数,也不是相对于其他系统的比较值。
- 基准测试多久运行一次?
基准测试最初按每日计划运行,但随着硬件/框架/模型组合数量的增长,这种方式已不再可行。现在,当配置发生变化(例如新软件发布、驱动更新或模型添加)时重新运行。仪表板中保留了历史数据。
- InferenceX 是开源的吗?
是的。代码、数据和仪表板均为开源。 SemiAnalysisAI/InferenceX
- InferenceX 与其他 AI 基准测试有何不同?
InferenceX 在真实硬件上运行固定序列工作负载和 AgentX 长上下文多轮编码场景。测试配置保存在代码仓库中,每项结果都链接到对应的 GitHub Actions 运行记录。
- 如何保证结果可复现?
仪表板上的每个数据点都由公开的 GitHub Actions 工作流生成。测试配置(模型、框架、精度、并行度、序列长度和并发数)保存在代码仓库中,并在对应的目标硬件上运行。日志、指标和芯片追踪数据等产物会上传到运行记录页面。每个图表的提示框都提供链接,可直接打开生成该数据点的 GitHub Actions 运行记录。
- 在哪里可以查看原始基准测试日志?
点击图表中的任意数据点即可打开提示框。其中的“GitHub Actions 运行记录”链接会直接跳转到生成该数据点的工作流运行。您可以在那里查看完整的任务日志、框架和驱动版本、命令行参数,并下载原始产物,包括请求延迟、token 计数和芯片功耗遥测数据。
- 我可以自己重新运行基准测试吗?
可以。基准测试配置以可独立运行的 shell 脚本形式保存在代码仓库的 /benchmarks 目录中。如果您拥有相同的硬件,可以 fork 仓库并直接运行脚本,也可以触发相同的 GitHub Actions 工作流来复现结果。
- 历史运行记录是否保留?
是的。GitHub Actions 保留工作流运行日志和产物 90 天。为了更长期的可审计性,我们还会每周发布完整基准测试数据库的快照作为公开的 GitHub Release,任何人都可以下载历史数据集并复现或重新分析仪表板中的任何图表。
- 我可以使用 InferenceX 数据自行分析吗?
可以。所有数据均可自由获取。仪表板支持按芯片、模型、框架和日期范围筛选,您也可以直接从任何图表导出原始 CSV 数据。