A Year in LLM Serving: Workload Evolution, Caching and Load-Balancing
William Nixon, Jon Durbin, Florian Standhartinger, Haryadi S. Gunawi, Juncheng Yang
cs.AI
2026-07-04
一年61.2亿条、9174个模型的完整LLM生产迹：输出中位数从数百掉到不足100，前缀命中双峰，99%复用在15分钟内。FIFO不输复杂驱逐，缓存亲和与负载均衡互相拉扯。
评估 LLM 推理系统，缺的往往是能回放的生产迹。现有公开材料窗口短、模型少，或者做了采样、去掉了用户标识，甚至只给生成器不给原始请求。ServeGen 四个月 35.4 亿条、12 个模型已经是大体量，仍看不到一年尺度上模型轮换、用户切模型，以及前缀缓存和负载均衡怎么互相拉扯。
这篇放出并分析了 serverless 推理平台 CompanyX（作者单位含 Chutes）一整年的未采样请求级生产迹：2025-04-11 到 2026-04-12，61.22 亿条请求，314970 名用户，9174 个模型（3922 公有、5252 私有），875921 个 serving instance。输入约 3.58×10¹³ token，输出约 2.52×10¹² token。字段包括匿名 userid、instanceid、输入/输出长度、TTFT、cachedtokens。论文声明迹会随文公开。
分析按聚合、用户/模型、纵向演化、前缀缓存、路由仿真五层展开。全文默认覆盖一年的文本 API，含流式和非流式的 chat/completion。三个高流量样本模型用来对照画像：DeepSeek-V3.2 偏聊天和角色扮演，DeepSeek-R1 偏长推理输出，MiniMax-M2.5 偏编程和 agent。
缓存仿真没有 prompt 原文，也没有会话 ID。做法是在同一用户内、最近 K=10 条里找满足「同模型同 endpoint、父请求的输入加输出能严格嵌进子请求输入」且残差最小的唯一候选，重建多轮会话。重建故意不看生产路由和 cachedtokens，估的是工作负载内在的可复用性。驱逐算法用 libCacheSim 回放；路由仿真再把会话打到 N 个实例的本地 LRU 上，比较 round-robin、load-first、sticky、cache-first。
负载非平稳，而且请求数和 token 数不同步。日请求量年中升高、夏秋见顶后回落，日 token 量回落更陡；活跃模型从早期不足 100 个涨到峰值超过 400 个。Chat 占比上升，completion 和流式下降。UTC 下午到晚上、工作日更高。请求整体偏 prompt 重：输入大约 10²–10⁵ token，输出大多 10¹–10³，多数输出短于输入。端到端时延由 decode 主导，输出长度驱动总时长，输入长度驱动 TTFT；长输入上更高的 token 命中能明显砍 TTFT。
用户和模型的请求量相近，负担可以差一个数量级。多数模型的流量来自少数用户；多数用户只用很少几个模型，尾部有跨很多模型的高量用户。多数模型到达过程 CV>1，且 lag-1 IAT 自相关为正，忙段和闲段会持续。主导模型一年内更替：早期 DeepSeek-V3-0324、R1 占比高，后期 Qwen3-32B、DeepSeek-V3.2 起来，「Others」变宽。全局输入中位数全年停在数千 token，输出中位数从早期数百掉到期末不足 100。更晚加入的用户队列输入更长、个体差异更大。
前缀缓存只在迹的最后两个月有 logged cachedtokens。请求级命中率双峰：要么接近 0，要么接近整段前缀，中间很少。短输入偏向高复用，长输入偏向低复用。MiniMax-M2.5 中间到高命中更多，两个 DeepSeek 零命中请求更多。同一 (user, model) 的到达里，大约一半间隔小于 0.1 秒，约 80% 在 10 秒内，99% 在 15 分钟内。单缓存回放里，FIFO 和 LRU 的 token 命中经常打平或超过 ARC、Sieve、GDSF、LRB 这类存储/Web 缓存里的强算法；DeepSeek-V3.2 离 size-aware Belady 仍有缺口，MiniMax 在中等容量就接近 oracle。
生产路由在低负载时把同一用户粘在少数实例上，高负载时打散，KV 被复制。100K token 的 MiniMax 上下文大约 27GB KV，按 10GB/s 单向传要约 2.7 秒。仿真里 cache-first 把更大的实例缓存变成更高命中，round-robin 和 load-first 把会话打散，缓存加大也救不回命中。cache-first 的 max/mean token/s 失衡大约 5%–7%；sticky 的失衡高几个数量级，图里直接去掉了。
用 ShareGPT 加合成到达来评调度器，会漏掉模型轮换、输出变短、用户切模型，以及「命中要么全有要么全无」这种结构。前缀缓存这边，把 CDN/存储的复杂驱逐直接搬过来，在这条迹上经常还不如 FIFO。扩缩容如果只盯 QPS，会和实际算力（token 工作量）脱节。路由不能把均衡和缓存当两件独立的事：打散求均衡会复制 KV，粘住求命中会失衡。5%–7% 这个数字是在大量单轮请求还能拿去填空闲实例的前提下得到的，会话更黏的工作负载，代价会更高。
迹本身比任何单条结论都更有用。带匿名用户和实例、带 TTFT 和 cachedtokens 的一年未采样请求，让别人可以重放到达、复用和路由，不必再靠合成流量。
这是单一 serverless 平台，私有用户部署模型过半，和封闭大厂 API 的流量结构不必相同。缓存日志只有最后两个月。会话重建是启发式，K=10、靠 token 嵌套，没有 prompt 可核对。仿真假设重建出的会话和本地 LRU，不是线上 A/B。Belady 仍留缺口，说明「最优驱逐」在这条前缀工作负载上还没被现有算法吃满，但论文没有给出替代策略。跨用户 KV 命中被当作稀有事件直接忽略，没有在本迹上再测一遍。论文写的是「将随文发布」，解读时公开地址尚未出现在稿件里。