Agent 智能体负载下的推理调度：2026 的新挑战

聊天负载的调度问题，本质是「怎么把请求填满批」。到了 2026 年，智能体负载把这个问题的性质改变了：同一会话的连续请求共享长前缀，缓存复用率从聊天场景的 54% 到 62% 直接跃升到超过 80%。调度器如果还按过去那套逻辑做决策，会系统性地做错事。

智能体负载的三个反常之处

先看生产轨迹给出的硬数字。据 Bailian 生产环境轨迹的分析，智能体服务的 KV 复用率超过 80%；另一份 PackServe 的生产轨迹显示，缓存 token 约占输入 token 的 80%，同时 decode 阶段占了请求总耗时的 78.4%。这两个数字组合起来意味着：绝大多数的注意力计算被跳过，而绝大多数的时间消耗在自回归解码上——优化目标已经不是 prefill 效率。

第二个反常是请求的触发方式。CacheWise 对真实编码助手轨迹的分析显示，工具完成触发的请求比用户输入触发的多出一个数量级以上。会话时长中位数约 36 分钟，长尾超过 2.6 小时。请求间隔由外部工具延迟决定，波动极大。

第三个反常是并发密度很低。PackServe 轨迹中，五分钟采样窗口内每实例运行并发在 0.39 到 1.69 之间，而平均 TPOT 仅小幅上升、远低于 SLO 目标。这意味着存在明显的延迟余量可用于请求打包，可以在满足 SLO 的前提下用更少的活跃 GPU 承载同样的需求。

缓存感知路由的过度优化

问题的核心在于：现有调度器的问题不是「没有复用 KV」，而是「过度追求复用」。

SMetric 论文的表述是，缓存感知的调度器把每个请求路由到持有其缓存 KV 的实例，用负载均衡换复用率。后果是：第一，同一智能体框架的不同会话首轮请求共享相似的系统提示，都被路由到少数几个缓存了这些提示的实例；第二，由于后续请求基本都命中本会话早先轮次的 KV，会话就被钉在首轮落地的那个实例上。结果是少数实例吸收了整份会话并过载，其余集群闲置，而闲置实例的算力直接封顶了整体吞吐。

更关键的是，这种牺牲是不必要的。SMetric 提出了一个看起来违反直觉的方案：首轮请求纯按负载均衡调度，把会话摊到全集群；后续请求才走传统的缓存感知路由，优先本地级复用。

它能成立，靠的是两级 KV 存储这个前提——每实例 GPU 显存上的本地层，加上集群级 CPU 内存上的全局层。即使被调度到的实例本地没有这份 KV，它仍然能从全局层取回。只要全局层能及时供给，TPS 不受影响，代价只是 TTFT 小幅上升，而智能体负载恰恰对 TTFT 的容忍度更高。

这种分层架构本身也带来了新问题。Unison 论文（复旦大学，2026 年 9 月）指出一个被所有缓存策略忽视的盲区：智能体调用工具期间，GPU 完全空闲，但会话没有结束，工具返回后要从完整 KV 前缀恢复。按 DeepSeek V3 MLA 的结构估算，每 token 每层 576 个潜元素、共 61 层、bf16 存储，约 68.6 KiB 每 token；一个 10 万上下文的会话约 7.03 GB，一百个停在工具等待中的智能体就是约 703 GB 的纯 KV 驻留——约等于九张 80GB 级 GPU，而这些会话不产生任何输出、不消耗任何注意力计算。

LRU 和 TTL 在这个状态上都会失效，而且是结构性失效。LRU 按最后访问排序，工具等待的智能体看起来比两秒前还在对话的用户更旧。TTL 同样会把慢工具的会话在返回前淘汰掉。Unison 的判断是：区分「等待工具、即将返回」和「会话已结束」所需的信息存在于作业结构里，而不在访问日志里，因此没有任何 recency 或 idle 阈值能解决问题。

工程上的四个可操作结论

调度手段	解决的问题	代价	适用规模
缓存感知副本路由	避免重复 prefill，跳过热副本	需要一致性分词与模板	4 至 16 卡起
分片调度（prefill 与 decode 分离）	让两个阶段各自跑满各自资源	双池运维 + KV 传输链路	数十卡以上
两级 KV 存储	允许牺牲 TTFT 换取复用率	全局层的容量与带宽是有限资源	集群级
工具元数据驱动的预测式驱逐	按下次重用时间排序而非 LRU	需要依赖调用侧元数据	编码类智能体为主
准入控制与提前拒绝	避免接纳注定违反 SLO 的请求	需要预测输出长度分布	全规模

准入控制是一切的前提。一台推理服务器不应该因为收到 HTTP 请求就接受它。被接受的工作消耗 KV、增加排队延迟、可能触发抢占、可能伤害其他租户。准入需要看的量是：未缓存的 prompt token 数、当前 KV 压力、空闲块水位、租户 token 预算与 KV 预算、排队截止期、期望输出长度区间、缓存命中概率。输出长度本身未知，控制器需要为运行中序列的增长留出余量——留多了浪费算力，留少了产生抢占抖动。频繁抢占本身就是策略已经病了的信号。

路由。看热的那个副本不一定是对的。最热的副本有最好的前缀命中，但队列可能已经很高、流式延迟接近上限；缓存命中省下的 prefill，可能被排队时间吃掉。实用的做法是联合打分：前缀重叠度、队列延迟、空闲 KV 块数、活跃 KV token 数、租户压力、副本健康度。

驱逐。CacheWise 的做法值得注意：不按 recency，而是用工具元数据（工具类型、参数）训练一个轻量预测器，估算每个会话的下一次重用时间，工具耗时最长的会话最先被驱逐。它在 vLLM 上实现，把 KV 驱逐降低 2 到 2.6 倍，会话总完成时间改善约 3.5 倍，token goodput 翻倍。

公平性。请求速率层面的公平在这里不管用——一个租户用少量超大请求就能压垮引擎，另一个租户发海量小请求却占用很少容量。公平应当基于加权的 token 服务量与 KV 占用，而不是请求数。智能体流量还需要扇出控制，因为一次用户操作可以产生大量模型调用。

架构层的两个选项

解决智能体负载有两条路。一是分片调度：把 prefill 和 decode 拆到独立的 GPU 池，通过 KV 传输层搬移缓存。NVIDIA Dynamo 1.0 在 2026 年 3 月发布，其 Planner 在运行时决定聚合还是分离，KV Block Manager 提供 HBM 到 DRAM 到 SSD 到对象存储的四级层次；LLM-d 于 2026 年 3 月进入 CNCF 沙盒，贡献了把缓存感知路由变成 Kubernetes 一等公民的 Gateway API Inference Extension。二是简单得多的方案：KV 感知的副本路由，不拆池、不传 KV、不改拓扑。

需要诚实标注的是：Dynamo 公布的 30 倍吞吐是 DeepSeek-R1 671B 在 GB200 NVL72 机架上的复合结果，包含 NVLink 域内宽专家并行等多项因素；更接近纯分离收益的口径是 Llama 70B 在 3K/50 序列长度、普通 Hopper 上的约 2 倍。官方文档也明确指出，输入输出长度比在 2:1 到 10:1 之间时，聚合服务往往更好。

对大多数 4 到 16 卡规模的团队，先做缓存感知的数据并行副本通常比直接上分离池更划算。

展望

2026 年的调度问题已经从「怎么批」变成「KV 放在哪里、谁能拿到它、什么时候该放弃它」。这带来的直接后果是硬件需求的重心变化：decode 阶段主导耗时、缓存驻留成为主要资源占用，意味着大 HBM 容量与高带宽的价值在推理集群中的权重继续上升，而推理专用芯片的竞争维度也从峰值 FLOPS 转向了 KV 密度与缓存层级的支持能力。

真正值得关注的方向是把「意图」显式传给调度层。Dynamo 1.0 已经开始接受每请求的优先级、期望输出长度和投机 prefill 提示。这个方向一旦成熟，调度器就不再需要从访问历史里猜测意图——而这正是今天所有缓存策略失效的根本原因。