TAO：面向LLM Agent服务的工具感知联合调度框架
🧭 Agent 服务调度优化
Shanghai Jiao Tong University · Stanford University
提出工具感知联合调度框架TAO，融合工具就绪度、缓存信用与token占用进行动态规划调度，显著降低延迟和TTFT
📌 工作参考价值（4 点）
- 在 LLM Agent 服务中，工具调用（如商品检索、数据库查询、API 调用）会使 GPU 推理可中断，调度时需将「工具返回就绪时间」纳入准入/放置决策，避免 GPU 空转和资源浪费。
- 借鉴 TAO 的 value interface：组合「近期工具就绪度 + 节点级缓存信用（时间衰减）+ token footprint」来评估一个 session 的调度价值，而不是只看队列长度或显存。
- 动态规划联合选择等待中的 sessions 并放置到 GPU 节点，在容量约束下最大化整体收益，比启发式 admission/placement 更优；可实现在线调度器，在 GPU 空闲或工具返回事件时触发。
- 如果推荐/搜索 Agent 涉及多步工具调用（如商品召回、属性查询、库存检查），可以对工具返回时间做预测或标记，并结合 prefix cache 命中（例如共享 system prompt 或工具 schema）优先调度相似 session 以提高 decode throughput。
工具调用进度自报：Agent 服务系统应读取而非猜测
🧭 Agent 工具调用 · KV cache 调度
Tsinghua University · Alibaba Cloud Computing · Zhejiang University
让工具调用上报剩余进度，比预估算更准，可将 p90 TTFT 降低约 20%
📌 工作参考价值（4 点）
- 在电商/搜索 Agent 中，对长耗时工具（SQL 查询、库存 API、商品爬虫、订单处理）增加 progress 上报字段，如剩余比例或“即将完成”信号，服务层可用它做 KV cache 驱逐/恢复决策，而不是靠工具名或历史均值猜时长。
- 工程实现上，progress 信号通过 harness 旁路采集，不改变 Agent 可见的输入输出，对 benchmark 分数无损耗；这可以直接迁移到现有多 Agent 编排框架，无需修改模型 prompt。
- 在推理引擎侧，把工具 progress 作为轻量 hint 接入 KV cache 管理，作者在 LRU 上仅做小改动就接近 oracle，说明该信号比复杂预估器更有投产价值；如果业务受 TTFT p90 波动困扰，可优先采工具真实进度而非加预测模型。
- 进度信号在环境变化时仍然准确，适合电商大促、突发流量等场景；对多租户 GPU 资源调度，长工具调用按真实剩余时间释放/保留缓存，能提升 HBM 利用率。
py-kvcache：vLLM 外部 KV 缓存的 NVMe 性能表征
🧭 LLM 推理 · KV cache 卸载优化
Vrije Universiteit Amsterdam · IBM Research Zurich
刻画外部 KV 缓存加载与重算的权衡，提出异步直接 I/O、有界 staging、调度感知预取，80k tokens 磁盘加载比 LMCache 快 2 倍
📌 工作参考价值（3 点）
- 在长上下文 LLM 服务（如 Agent 多步推理、长 prompt 推荐解释）中开启外部 KV cache 前，先用生产 trace 做 break-even 分析：H100 等强 GPU 上短前缀重算可能比磁盘加载更快，外部缓存应作为按场景开启的准入策略，而非全局默认。
- 缓存层设计要关注传输粒度与调度时序，而非只盯 NVMe 带宽：连续块传输 + 异步直接 I/O 绕过页缓存，并限制共享 staging buffer，避免挤占 GPU/CPU 内存；请求排队时就启动预读，让磁盘 I/O 与 prefill 计算重叠，可显著降低 TTFT。
- 对多轮对话和前缀链不规则场景，py-kvcache 的调度感知预加载有明确收益；若业务里 prompt 前缀复用度高（如推荐 agent 的固定 system prompt、RAG 检索后的公共上下文），可以在 CPU/NVMe 层缓存 KV，但需评估前缀长度分布和 GPU 算力后决定。