上交大陈海波团队联合阿里重做Agent请求调度，集群TPS提升16%！

智猩猩AI整理

编辑：BugMaker

Agent开始批量写代码、调用工具、修改文件之后，大模型服务系统面对的流量也变了。

普通用户会边生成边阅读，更关注第一个token多久出现。Agent通常要等完整回复生成完，才会决定下一步调用什么工具。对它来说，整个集群每秒能稳定处理多少token，直接影响任务完成速度和运行成本。

来自上海交通大学特聘教授、IPADS负责人、ACM Fellow和IEEE Fellow陈海波团队联合阿里巴巴分析两条真实Agent生产轨迹后发现，KV$复用覆盖了超过80%的Prefill token，这些token对应的K/V张量不必重新计算。

但传统调度器越追求缓存命中，越容易把请求挤到少数GPU，造成一边排队、一边闲置。

为此，团队提出SMETRIC，只重点调整每个Agent会话的第一轮请求，就同时兼顾负载均衡和本地缓存复用。

相比继续扩充缓存，SMETRIC选择从调度入口下手，只决定好一个Agent会话从哪张GPU开始，就能改善后续整个会话的负载分布。

SMETRIC在Prefill与Decode共置部署中将集群TPS（Tokens Per Second，即满足延迟要求下整个推理集群每秒可处理的Token数量）提高 10%—16%，在分离部署中将PrefillTPS最高提高 34%。

01

Agent请求为什么特别

依赖缓存

一次Agent任务通常包含多轮LLM请求。

用户先提出任务，模型给出推理结果或工具调用。Agent执行工具后，把运行结果追加到上下文，再发出下一轮请求。由于标准LLM API不会替用户保存会话状态，每轮请求都需要携带此前的完整对话历史。

这些重复出现的历史不必每次重新计算。

LLM处理token时，Attention会生成对应的Key和Value张量。相同前缀对应的K/V张量也相同，因此系统会把已经算出的结果保存下来，供后续请求直接复用。

论文把这些已经缓存、可以复用的K/V张量状态记作KV$。

KV$本质上是KV Cache中保存的数据内容。两者的细微区别是，KV Cache更常指缓存机制或存储空间，而KV$更强调其中已经保存的K/V状态。

论文分析的两条BAILIAN生产轨迹中，KV$复用率分别达到82%和81%。约67%的复用来自同一会话的历史轮次，18%—20%来自不同会话共享的system prompt。

而且这些缓存用得很快。约90%的KV$会在100秒左右再次被访问，两条轨迹中由Agent自动触发的请求分别占 92.9%和94.2%。工具刚执行结束，下一轮请求通常已经到来，此前的KV$大概率还留在GPU显存中。

02

缓存命中越高，GPU负载

反而越容易失衡

传统LLM调度器通常同时考虑两个问题。

一是哪个实例能够命中更多本地KV$，二是哪个实例当前负载更低。

Agent会话的第一轮请求往往共享相似的system prompt。缓存感知调度器会把这些请求不断送到已经保存该提示词的少数实例。

后续请求又会复用同一会话的历史，因此继续返回原来的实例。第一轮请求落到哪张GPU，后面的整个会话基本也会被固定在那里。

论文实验显示，在BAILIAN的缓存优先策略下，96.6%的后续请求会回到处理首轮请求的实例。仅使用负载均衡策略时，这一比例只有4%。

这就形成了一个矛盾。

只追求本地KV$命中，会让部分GPU持续过载。只追求负载均衡，又会频繁从全局存储读取KV$，带来额外的容量和RDMA带宽压力。

SMETRIC要解决的正是这道选择题：既让会话均匀分布，又尽量让后续请求继续命中本地缓存。

03

SMETRIC只重点调度会话的

SMETRIC的方法很直接。

对于每个会话的第一轮请求，它不强求命中本地KV$，而是优先选择负载较低的实例，把新会话分散到整个集群。

对于第二轮及之后的请求，它再采用cache-aware routing，也就是优先返回KV$命中最高的实例。这样既能保留会话内的本地缓存复用，也能避免大量会话从一开始就集中到少数GPU。

首轮请求仍然可以复用共享的system prompt。即使目标GPU没有本地副本，也能从CPU内存组成的全局KV$存储中取回。

SMETRIC还不要求路由器长期维护session-to-instance表。它可以根据当前请求携带的历史消息推断会话轮次，让路由器保持 stateless，不必记录每个会话去过哪台机器。

遇到某个实例突然过载，或者本地KV$已经被清除时，SMETRIC会放弃原来的粘性路由，把会话重新分配到负载更低的实例。

04

用两款Qwen模型回放

真实Agent流量

团队在4台服务器上完成实验，每台配备8张NVIDIA H20 GPU。系统基于 vLLM、Mooncake和LMCache，测试了Qwen3-Coder-30B-A3B 和 Qwen3-235B-A22B-FP8。

实验没有使用普通问答Benchmark，而是回放BAILIAN真实Agent服务集群记录下来的请求轨迹，并与BAILIAN线上调度策略、LMetric和仅负载均衡策略进行比较。

在Prefill和Decode由同一实例完成的共置部署中，只要配置全局KV$存储，SMETRIC满足延迟要求的集群TPS便比最佳基线高10%—16%。

这里的TPS不是简单统计生成了多少token，而是只计算同时达到首token延迟和后续token延迟要求的请求。换句话说，SMETRIC让集群在请求不超时的前提下，能够处理更多有效token。

在Prefill与Decode分别运行于不同集群的分离部署中，SMETRIC的Prefill TPS相比最佳基线提高2%—34%，中位首token延迟从BAILIAN的1.8秒降至1.1秒，下降 37%。

SMETRIC没有改变模型参数，也没有修改Agent、Skill或工具调用逻辑。它处理的是Agentic Infra中的集群请求调度：在请求抵达模型服务后，决定由哪一个GPU实例接手。

这项工作的关键并不是设计更大的缓存，而是重新安排每个会话从哪张GPU开始。只调好第一轮请求，就能让整个Agent会话更均匀地分布在集群中。

关注+星标，获取AI前沿进展与优质开源项目