Source-linked AI summary

AgentPerfBench: A Benchmarking and Evaluation Suite for Inference Performance of Agentic LLMs

Cheuk Hang Lau, Zeyu Cao, Kevin Wong Cheuk Yin, Yao Lai, Haoran Wu, Nicholas D. Lane, Robert D. Mullins, Ilia Shumailov, Yiren Zhao

arXiv:2609.34683v1cs.LG

TL;DR

Existing inference benchmarks primarily target single-turn chatbot workloads, while agentic applications involve multi-turn requests and growing contexts. AgentPerfBench builds real-trace-derived profiles, measures serving at saturation, and profiles kernels with a multi-dimensional roofline model. Its evaluation characterizes agentic workloads as a distinct hardware regime from chat, with both prefill compute and KV-cache capacity pressures.

  • Problem

    Existing benchmarks primarily focus on single-turn chatbot workloads rather than multi-turn, tool-using agentic requests with growing context.

    Source: §1 · p. 1
  • Method

    AgentPerfBench derives trace-replay and synthetic workload profiles from agentic traces, measures serving through saturation sweeps, and uses NCU kernel profiles with a multi-dimensional roofline analysis.

    Source: §1 · p. 2, §3.3 · p. 4
  • Results

    Across the evaluated profiles, models, and GPU configurations, agentic serving exhibits a distinct dual pressure: coding-agent prefill can be compute-bound while KV-cache growth raises capacity pressure.

    Source: §5 · p. 9
  • Takeaways & Limitations

    The benchmark characterizes workload-dependent compute, bandwidth, and capacity limits that distinguish agentic serving from chat.

    Source: §5 · p. 9

    The evaluation is limited to single-node multi-GPU servers with tensor parallelism up to TP=8, and sessions exceeding the per-run context cap are truncated.

    Source: §4.4 · p. 8

Abstract

from arXiv · show

The optimization of LLM serving engines, such as vLLM and SGLang, is largely benchmark-driven: optimizations, scheduling policies, hardware and system designs are all selected based on representative workloads. However, a significant mismatch has emerged in the agentic era. Existing benchmarks primarily focus on simple single-turn chatbot workloads. LLM applications are increasingly agentic: coding agents, terminal execution systems, and tool-use agents issue multi-turn requests with growing context lengths. We introduce AgentPerfBench, a benchmark suite for agentic inference. It uses real traces from agentic benchmarks, such as SWE-Bench and TerminalBench, alongside standard chat baselines. This enables benchmarking of models on multi-turn tasks involving tool calling, skill utilization, and increasing context lengths. AgentPerfBench also samples from empirical distributions of input length, output length, and turn count derived from the real traces, generating representative synthetic profiles for cheap and accurate measurements on new hardware. In addition, we further find that several existing benchmarks fail to accurately reflect real hardware performance for two key reasons: 1) they do not account for realistic context-length growth, and 2) they measure inference performance without operating at hardware saturation. We discuss these issues in detail and provide rich kernel-level Nsight Compute (NCU) traces to construct a new multi-dimensional roofline model that captures hardware-system limitations in both memory bandwidth and memory capacity footprint. The benchmarking suite then includes automated scripts to identify potential bottleneck conditions on emerging hardware when evaluated with diverse agentic traces. Together, these contributions quantify the chat-to-agentic gap in current inference benchmarks and characterise per-kernel GPU resource utilisation via roofline analysis.

1 Introduction

Agentic inference workloads differ from the single-turn chatbot workloads represented by existing benchmarks. AgentPerfBench addresses this mismatch with real-trace-based profiles, saturation measurements, and kernel-level roofline analysis.

1 Introduction

  • Existing public benchmarks do not measure multi-turn, tool-using agentic workloads or derive input and output lengths from real traces.They also commonly report a single operating point rather than sweeping load to saturation.Source: §1 · pp. 1–2
  • AgentPerfBench samples per-turn input length, output length, and turn-count distributions from real agentic traces to create representative workload profiles.Its profiles cover coding, terminal, and computer-use agents, alongside standard chat baselines.Source: §1 · p. 2
  • Saturation-based evaluation measures performance at the maximum sustainable concurrency after hardware performance plateaus.The paper reports that single-operating-point methods can under-report hardware capacity.Source: §1 · p. 2
  • NCU kernel profiles and a multi-dimensional roofline model quantify performance limits from both memory bandwidth and memory-capacity footprint.The analysis is applied across diverse agentic workloads and representative kernels.Source: §1 · p. 2
  • The release includes 3,000+ benchmark results, 140,000+ kernel profiling records across four GPU platforms and 11 model architectures, and open-source tooling.The results and tooling are released under an open-source license.Source: §1 · p. 2

2 Background

The background contrasts existing inference benchmarks with agentic workloads and introduces roofline concepts for interpreting their hardware demands. It also describes how context growth across turns changes workload characteristics.

Inference benchmarks

  • Existing systems and benchmarks leave agentic workloads, multi-turn sessions, NCU profiling, open-source traces, and saturation-based measures unsupported or absent.Although MLPerf includes standardized scenarios and long-context tasks, its LLM suite remains single-turn without multi-step tool use; common vLLM and SGLang recipes use fixed-length traces and do not sweep to saturation.Source: §2 · pp. 2–3

Benchmarking assumptions

  • The paper assumes random tokens at distribution-matched lengths produce the same serving behavior as real tokens at those lengths.It states that sequence length and batch scheduling determine TTFT and TPOT, rather than token content.Source: §2 · p. 2

Prefill-decode separation and the roofline model

  • Operational intensity measures FLOPs per byte to distinguish compute-bound from memory-bound execution, while capacity footprint estimates DRAM bytes per concurrent request.The roofline framing compares operational intensity with the compute-versus-bandwidth boundary.Source: §2 · p. 3

Workload-dependent OI and the snowballing effect

  • As context accumulates across turns, input length and prefill operational intensity grow; the paper calls this the snowballing effect.When capacity footprint exceeds a single accelerator's DRAM capacity, serving requires tensor parallelism or KV-cache paging.Source: §2 · p. 3

3 Methodology

AgentPerfBench builds workload profiles from agentic benchmark traces, validates synthetic profiles against trace replay, and measures serving through closed-loop concurrency sweeps. It also collects kernel profiles to interpret compute, memory-bandwidth, and capacity limits.

3 Methodology

  • The methodology combines trace-based workload construction, closed-loop serving measurements across models and GPU platforms, and NCU profiling of the same workloads.The profiling connects end-to-end serving behavior to per-kernel compute, bandwidth, and capacity limits.Source: §3 · p. 3

3.1 Workload Surface

  • Canonical profiles span chat, coding-agent, terminal-agent, and computer-use workloads, with trace-replay and synthetic distributional forms.Synthetic profiles sample per-turn input and output lengths and turn counts fitted to traces, enabling reissuance across models, hardware, backends, and concurrency settings without full replay cost.Source: §3.1 · p. 4, Table 2 · p. 4

3.2 Synthetic Trace Validation

  • Synthetic profiles are validated against trace replay, and coding-agent validation requires matching code-like token structure and serving-visible prefix structure as well as token counts.The paper uses the resulting prefix-aware configuration for its synthetic distributional profiles.Source: §3.2 · p. 4

3.3 Benchmarking Framework

  • The closed-loop harness records latency, token, cache, and scheduling measures while advancing multi-turn sessions in turn order to preserve context growth.Request throughput is the headline capacity metric, and concurrency is swept to locate where requests per second cease rising.Source: §3.3 · p. 4

3.4 Kernel-level Profiling

  • Kernel profiling computes component operational intensity and roofline throughput ceilings, then aggregates component costs into a layer-level roofline bound.The analysis uses GPU peak compute and bandwidth and compares operational intensity with the ridge point; NCU-backed artifacts provide representative and broader kernel records.Source: §3.4 · p. 5

4 Results

The evaluation sweeps concurrency to saturation across models, GPU platforms, and chat and agentic sessions. Results distinguish agentic workloads through their latency, operational-intensity, and capacity behavior.

4.1 Experimental Setup

  • The sweep covers dense LLaMA/Qwen and MoE Mixtral/gpt-oss models across four GPU platforms, using closed-loop concurrency sweeps to saturation.Serving runs use vLLM and SGLang with the GPU subset assigned to each model’s tensor-parallel configuration.Source: §4 · p. 5, §4.1 · p. 5

4.2 Benchmark Results

  • Coding agents are prefill-dominated (ISL/OSL ≈355:1), reach OI 2,366 versus chat’s 51, and long-context profiles exceed two-H100 160 GB HBM as concurrency rises.The controlled single-turn comparisons cover 40 released trace_replay groups.Source: §4.2 · pp. 5–6, Figure 1 · p. 6
  • Across 63 matched chat groups, median request throughput rises +11% from C=200 to C=320, while most agentic groups plateau or degrade.At C=320, 15 of 66 agentic groups lose more than 10% throughput.Source: §4.2 · p. 6, Table 5 · p. 7
  • At C=80, LLaMA-3.1-8B coding-agent median TTFT is 11,719 ms versus chat’s 343 ms, with request throughput 2.4 versus 13.5 req/s.The multi-turn trace-replay measurements use H100-SXM5-80GB with vLLM v0.19.0 and prefix caching enabled.Source: §4.2 · p. 6, Table 4 · p. 7

4.3 Roofline Bottleneck Diagnosis

  • On H100, coding, terminal, and computer-use OIeff reach 2,409, 1,809, and 886, respectively, while chat peaks at 181 and remains bandwidth-bound.The 295 FLOP/byte ridge separates compute-bound from memory-bandwidth-bound execution; accumulated context grows ISL and shifts prefill toward large GEMMs.Source: §4.3 · p. 7
  • Kernel decomposition shows an 8–28× prefill/decode OI gap; prefill projection GEMMs are compute-bound, while attention and elementwise operations remain bandwidth-bound.At C=80, the prefill projection aggregate accounts for 81.8% of modeled layer latency; decode projections remain bandwidth-bound.Source: §4.3 · pp. 7–8
  • At 32K context, the 80 GB capacity wall arrives at C≈14; at C=80, coding-agent and terminal capacity footprints reach 155 GB and 126 GB.Coding-agent capacity exceeds the single-H100 wall by C=40; long agentic workloads therefore face both compute and KV-capacity pressure.Source: §4.3 · pp. 7–8, Figure 2 · p. 8

4.4 Discussion

  • The evaluation is limited to single-node tensor parallelism up to TP=8, context-capped sessions, and logical cache estimates; the authors identify workloads as candidates for prefill-decode disaggregation.The authors note that sessions exceeding the per-run cap are truncated and that server-side KV eviction, compaction, and cold-cache recomputation are not directly measured.Source: §4.4 · pp. 8–9

5 Conclusion

Across 22 workload profiles, AgentPerfBench finds agentic serving faces compute-bound prefill and KV-capacity pressure, unlike chat; the conclusion identifies prefill–decode disaggregation as a natural candidate and outlines evaluation boundaries.

5 Conclusion

  • Coding-agent OI reaches 2,409 versus 181 for chat on a single H100, a 13× separation that places agentic prefill above the ridge while chat remains bandwidth-bound.Across 22 workload profiles, 9 models, and 14 GPU configurations, the study reports 3,197 sweep rows and 148,077 NCU records.Source: §5 · p. 9
  • Projection GEMMs become compute-bound in prefill, while attention, elementwise operations, and all decode components remain bandwidth-bound.Projection GEMM OI reaches 2,956 at C=80; the prefill-to-decode OI gap spans 8–28× across workloads.Source: §5 · p. 9
  • KV-cache growth creates capacity pressure: coding-agent sessions exceed the 80 GB HBM wall by C=40, and agentic profiles lose 43–76% throughput from C=200 to C=320 while chat continues scaling.The resulting compute-bound prefill and capacity-constrained decode make agentic workloads natural candidates for prefill–decode disaggregation.Source: §5 · p. 9
  • The roofline analysis extends to accelerators not yet deployed because it requires only model architecture and published hardware specifications.Further evaluation directions include multi-node pipeline-parallel serving, explicit KV eviction, compaction and recomputation measurements, and 128K+ context windows; the reported snowballing effect is a lower bound.Source: §5 · p. 9

6 Dataset and Reproducibility

The release provides five dataset configurations spanning serving summaries, layer validation, kernel profiles, replay validation, and benchmarking tools, with open-source licensing and machine-readable metadata.

6 Dataset and Reproducibility

  • The released configurations cover serving summaries, layer validation, kernel profiles, replay validation, and an open-source benchmark tool.Serving summaries include 3,197 sweep rows; kernel profiles include 148,077 per-kernel NCU records across four GPU platforms.Source: §6 · p. 9
  • The benchmark tool runs closed-loop concurrency sweeps against OpenAI-compatible endpoints and collects latency, throughput, and run metadata.The recorded metrics include TTFT, TPOT, ITL, and E2EL.Source: §6 · p. 9
  • All artifacts are released under an open-source license with a Croissant metadata record for machine-readable discovery.Source: §6 · p. 9

A Experimental Details

The experimental details identify the GPU platforms used in released runs and describe sweep launch settings recorded for serving engines.

A Experimental Details

  • Table 6 identifies the GPU platforms used in the released runs.Source: Table 6 · p. 11
  • Sweep scripts start one backend server per row, run requested profiles and concurrencies, then tear down the server.The manifest records backend, tensor-parallel degree, context limit, and memory fraction for each cell.Source: A Experimental Details · p. 11
  • Table 7 summarizes launch settings that affect scheduling, memory, context length, or model loading, omitting fixed host, port, API-key, and model-path flags.vLLM-only scheduling and CUDA-graph flags are not treated as SGLang settings.Source: Table 7 · p. 11, A Experimental Details · p. 11

B.1 Distributional Replay Validation Ablation

The SWE-Bench ablation shows that synthetic replay requires prefix-aware configuration to closely match trace-replay serving behavior.

B.1 Distributional Replay Validation Ablation

  • A source-locked SWE-Bench ablation compares synthetic replay configurations to select the distributional replay setup.Source: §B.1 · p. 11
  • 31.1% deep-turn E2EL MAPE with independent prefixes falls to 11.7% when APC is disabled.The result shows prefix caching amplifies the mismatch for the code-like synthetic filler.Source: §B.1 · p. 11
  • Adding a shared 1024-token synthetic prefix brings deep-turn E2EL MAPE to 3.2% and aggregate E2EL MAPE to 2.4%, within the observed noise scale.The paper uses this prefix-aware configuration for synthetic distributional profiles.Source: §B.1 · p. 11

B.2 Released Splits and Roofline Values

The released serving summaries distinguish trace replay from distributional synthetic profiles, while accompanying tables and figures specify workload profiles, evaluated configurations, and roofline diagnostics. The roofline materials contrast operational intensity with capacity footprint and show how KV-cache growth constrains concurrency.

Released splits

  • The two released serving-summary splits are trace_replay, which replays source traces and stress profiles, and synthetic_distributional, which samples fitted or empirical workload statistics.Table 10 identifies profiles for synthetic multi-turn workloads, single-turn baselines, archived session and ShareGPT replays, and synthetic stress profiles.Source: §B.2 · p. 11, Table 10 · p. 13

Released configurations

  • The evaluated model configurations include dense models with GQA and MoE models with top-k routing, while serving summaries record the tensor-parallel configurations actually run.Models marked † are included only in the NCU kernel-profiling dataset, not the serving benchmark; gpt-oss uses MXFP4 weights and other models use bfloat16.Source: Table 8 · p. 12, Table 9 · p. 12

Released splits

  • Table 10 reports each profile’s source basis, turn count, and source-median ISL and OSL, distinguishing synthetic multi-turn medians from trace-replay turn-count ranges.Single-turn rows report one turn; synthetic multi-turn rows report medians, while trace-replay multi-turn rows report turn-count ranges.Source: Table 10 · p. 13

Roofline values

  • Figure 4 shows agentic workloads crossing the H100 ridge of 295 FLOP/byte and the 80 GB HBM capacity wall across serving operational-intensity and capacity-footprint views.The figure is for LLaMA-3.1-8B on H100 at TP=1 with vLLM v0.19, bf16, and concurrency from 1–80.Source: Figure 4 · p. 14
  • The roofline tables distinguish per-component operational intensity and analytical prefill latency share from the capacity override, which applies when KV cache exceeds the 80 GB HBM budget.The per-component Compute/BW labels apply only to the ideal in-memory case; the distributional replay validation table reports MAPE between synthetic profiles and real trace replay, including a turn 10–19 deep-context bin.Source: Table 11 · p. 13, Table 14 · p. 14
  • KV-cache capacity limits concurrency more sharply at longer contexts: 0.075 GB per sequence fits at C≈850 for 512 tokens, versus 17.7 GB and C≈3 at 128K tokens.The listed intermediate contexts are 8K at 1.14 GB and C≈56, and 32K at 4.43 GB and C≈14.Source: §B.2 · p. 14, Table 14 · p. 14
Loading 2609.34683v1…