聊天负载的调度问题，本质是「怎么把请求填满批」。到了 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 提示。这个方向一旦成熟，调度器就不再需要从访问历史里猜测意图——而这正是今天所有缓存策略失效的根本原因。