← Home

A Year of LLM Serving Traces: Workload Evolution at Scale

By James Trappett · 18 August 2026

4 min read

Most benchmarks for LLM serving systems are built on traces that are either short-lived, sampled, or synthetically generated. This creates a significant gap between the conditions under which systems are evaluated and the conditions they actually face in production. A new paper from Nixon et al., A Year in LLM Serving: Workload Evolution, Caching and Load-Balancing, attempts to close that gap by releasing and analysing a full one-year production trace from Chutes, a real-world LLM serving platform.

The timing matters. As LLM inference has shifted from a research curiosity to a critical cloud workload, the systems community has struggled with a reproducibility problem: you cannot design good serving infrastructure without understanding real traffic patterns, but real traffic patterns are rarely shared. This paper directly addresses that bottleneck.

What the Paper Contributes

The core contribution is both empirical and infrastructural. The authors provide:

The decision to release the full trace rather than a sample is significant. Sampled traces can obscure the long-tail behaviour that often drives worst-case system performance. If the trace is as complete as described, it should become a standard reference dataset for the serving systems community.

Methodology and Scope

The study draws on production data from Chutes, analysed across four analytical lenses. Aggregate characterisation establishes baseline statistics on request volumes, prompt and completion lengths, and inter-arrival times. Temporal analysis examines how these statistics shift across the year, capturing seasonal patterns, growth trends, and the emergence or retirement of specific models. Model-level analysis disaggregates traffic by model, which is important because serving behaviour differs substantially between a high-throughput popular model and a rarely-queried specialised one. User-level analysis examines how individual users interact with models over time, including patterns of model switching, query frequency, and session structure.

This four-axis decomposition is methodologically sound. Aggregate views of serving workloads are well understood to be misleading: they smooth over heterogeneity that directly affects decisions about batching strategies, KV cache sizing, and replica placement. By explicitly separating model-level and user-level views, the authors can surface structure that aggregate statistics would hide.

The focus on caching and load-balancing as downstream applications of the trace analysis is well chosen. KV cache reuse is one of the more practically impactful optimisations in LLM serving, and its effectiveness depends heavily on the prefix-sharing structure of real queries. Similarly, load-balancing decisions depend on understanding request heterogeneity across models and time. Both problems are poorly served by synthetic workloads.

Key Findings and Implications

Based on the paper's framing, several findings stand out as particularly consequential for the systems community:

Limitations and Open Questions

The paper's primary limitation is one it shares with all single-platform trace studies: generalisability. Chutes is one serving environment with a particular user base, model selection, and business context. Traffic patterns on a consumer-facing chatbot platform, an enterprise API gateway, or a research cluster would likely differ substantially. The authors should be commended for releasing the trace, but the community will need multiple traces from diverse deployment contexts before strong generalisations can be drawn.

There is also a question of what the trace captures and what it does not. Production traces typically record request-level metadata but not the content of prompts and completions, for obvious privacy reasons. This limits the ability to study semantic patterns in queries, which are relevant for understanding prefix-sharing opportunities and model selection behaviour. The authors appear to be working within these constraints, but it is worth being explicit about what analyses are foreclosed.

The focus on caching and load-balancing, while well motivated, leaves other important serving problems underexplored. Autoscaling, disaggregated prefill-decode architectures, and speculative decoding all have workload dependencies that this trace could potentially inform. Releasing the full trace is the right move here; it allows the community to apply the data to problems the original authors did not anticipate.

Finally, the paper was submitted in mid-2026, meaning the trace covers a period of rapid change in the LLM ecosystem. Model sizes, serving frameworks, and user expectations all shifted considerably during this window. Interpreting the longitudinal findings requires some care about which changes reflect fundamental workload dynamics versus artefacts of a particularly turbulent period in the technology's development.

Overall, this is a valuable contribution. The field has needed realistic, long-horizon production traces for some time, and the combination of rigorous analysis with a full data release makes this paper worth close attention for anyone working on LLM serving infrastructure. The full paper is available at arXiv:2608.13573.

LLM ServingSystems ResearchProduction AICloud ComputingWorkload Analysis

Related Articles

SELR: Self-Explainable Latent Reasoning Without Extra ModelsBCMT: Efficient Long-Context Transformers via Block MemoryMicrosoft's 398-Vulnerability Patch Tuesday: AI's Double-Edged Sword