Observation, Not Prediction: Conversation-Level Disaggregated Scheduling for Agentic Serving
该论文介绍了 ConServe，这是一个将调度单位从单次轮次转向整个对话的调度框架，旨在通过利用计算密集型预填充（prefill）和内存密集型解码（decoding）这一稳定的两阶段结构，消除预测未知未来成本的需求，从而降低延迟并提高能效。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下你经营着一家繁忙的餐厅厨房。在过去，每一份订单都很简单：顾客走进来，你做完菜，他们离开。你可以轻松管理厨房，因为每份订单所需的时间和精力大致相同。
但现在，想象一下你的顾客是“AI智能体（AI Agents）”。他们不仅仅是点一份餐，而是发起一个复杂的项目。
- 第一回合（宏大的简报）： 顾客坐下，递给你一份长达50页的说明手册。阅读并理解这份手册需要很长时间（即“预填充/Prefill”阶段）。
- 中间回合（工具调用）： 厨师开始烹饪，然后停下来给供应商打电话，等待回复，检查食谱，然后再打回去。这些步骤很短，但会反复发生。
- 最后一回合（结果）： 终于，菜肴准备好上桌了。
问题所在：旧有的调度方式
目前的厨房管理者（AI系统）将每一个细小的步骤都视为一个独立的订单。每当厨师停止动作去给供应商打电话时，管理者都要做出决定：“我是让厨师就在主厨房完成这一步，还是把这个特定的步骤发送到另一个专门的工作站？”
问题在于，管理者必须在步骤发生之前，就去猜测这一步需要多长时间或需要多少内存。如果猜错了，他们就会把步骤发到错误的工作站，导致交通拥堵。这就像一名交警试图在司机还没出发前，就精准预测每辆车的行驶速度一样。
解决方案：ConServe（对话级方法）
这项研究引入了一个名为 ConServe 的新系统。ConServe 不再单独管理每一个细小的步骤，而是将整个对话视为一个单一的整体进行管理。
ConServe 通过一个简单的两阶段计划改变了规则：
阶段 1：重体力活（预填充/Prefill）
当顾客带着那份50页的手册初次到达时，ConServe 会立即将他们送往一个超快速、高功率的工作站（高性能 GPU）。这个工作站专为快速阅读大型文档而设计。它阅读手册，理解上下文，并创建一个“记忆地图”（称为 KV cache）。
阶段 2：长尾阶段（对话的剩余部分）
一旦完成了最初的地图构建，ConServe 会说：“好了，重体力活已经完成了。现在，这整个对话都属于一个特定的、更小型的、更节能的工作站。”
- 这个“记忆地图”会仅此一次被移动到这个新的工作站。
- 从那一刻起，每一个后续步骤（工具调用、简短更新）都会直接在该工作站在同一处进行。
- 系统不再进行任何猜测。无论接下来的步骤是长是短，对话都会固定在同一个工作站上，直到任务结束。
为什么这更好（类比）
可以把它想象成一辆货运卡车：
- 旧方式： 你试图预测下一个包裹是重还是轻。如果你猜错了，你可能会派一辆小卡车去拉重物，或者派一辆大卡车去拉轻物。这会浪费燃油和时间。
- ConServe： 你在开始时装载一次卡车。你把卡车开到目的地并停在那里。对于该特定客户的所有后续包裹，都会装载到这同一辆卡车上。你不需要预测下一个包裹的重量，你只需要保持卡车高效运转即可。
结果
研究人员在真实的 AI 智能体工作负载上测试了该系统，发现：
- 速度： 它减少了用户看到第一个真实结果（不仅仅是工具调用）所需的时间 51%。这就像因为厨房不再纠结于把食材放在哪里，所以你能快 50% 地吃到食物。
- 效率： 它节省了 7.5% 的能量。通过仅在处理大型初始阅读时使用强力工作站，并在其余时间使用更便宜、更节能的工作站，它减少了电力的浪费。
- 可靠性： 因为系统不需要进行预测，它永远不会犯“走错路”的错误。旧系统如果预测失误就会崩溃或变慢；而 ConServe 则能持续运行，因为它依赖的是它目前所能看到的实际情况。
简而言之： ConServe 不再试图预测 AI 对话中每一个微小步骤的未来。相反，它将整个对话视为一项任务，用强力引擎处理繁重的开场，然后让稳定的、高效的引擎完成剩下的工作。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。