TOPAS: Workflow-Aware Prefix-State Scheduling for Multi-Agent LLM Serving

TL;DR

TOPAS通过联合调度前缀缓存与请求,优化多智能体LLM服务中的任务完成时间,提升性能达39.8%。

cs.CL 🔴 高级 2026-08-26 37 次浏览
Hongqiu Ni Han Tian Chi Zhang Guopeng Li Haisheng Tan
多智能体调度 大语言模型 前缀缓存 工作流优化 GPU资源管理

核心发现

方法论

TOPAS采用层次化搜索策略,结合任务导向的前缀感知调度框架,利用基于最长剩余路径的预估和未来重用潜力的启发式评分,动态决策缓存中的前缀保留与请求调度。核心算法包括基于后置状态的评分机制,考虑前缀迁移、抢占成本和任务老化机制,确保任务公平性。通过在SGLang框架中实现,结合合成DAG和MetaGPT工作流进行评估,验证其在多阶段、多智能体环境中的优越性。

关键结果

  • 在三种合成DAG和两种MetaGPT工作流中,TOPAS平均/第99百分位JCT分别比最优基线提升39.8%/49.4%,在MetaGPT-SOP中平均JCT降低9.8%,在MetaGPT-TL中平均/第99百分位JCT分别降低22.0%/26.6%。
  • 实验显示,TOPAS显著改善请求批处理效率,减少前缀迁移和抢占开销,优化GPU资源利用率,整体提升多任务调度性能。
  • 消融实验表明,未来重用和任务老化机制是性能提升的关键因素,缺失其中任何一项均导致性能下降。

研究意义

该研究突破了多智能体LLM服务中前缀缓存与请求调度的耦合瓶颈,提出的TOPAS实现了在有限GPU内存预算下的任务级最优调度策略,显著缩短任务完成时间,推动大规模多智能体系统的高效部署。其创新调度框架为未来多任务、多智能体协作提供了理论基础和工程方案,有望在AI推理、软件开发等场景中广泛应用。

技术贡献

TOPAS引入任务导向的前缀感知调度思想,首次将前缀驻留作为显式调度决策,结合层次化搜索和启发式评分,优化请求调度与缓存管理的联合策略。算法中采用基于最长剩余路径的预估模型,结合未来重用潜力和任务老化机制,有效平衡前缀局部性与工作流整体进展。其在SGLang平台上的实现验证了其在复杂多阶段、多智能体环境中的实用性和优越性,推动了多智能体LLM调度研究的理论与实践发展。

新颖性

本研究首次提出将前缀驻留作为显式调度变量,联合优化请求调度与缓存状态,突破了传统请求级调度的局限。相较于现有的工作流优化和缓存管理方法,TOPAS通过层次化搜索和多目标评分实现全局最优,创新性地解决了多智能体环境中前缀迁移与任务进展的冲突问题,为多智能体LLM调度提供了全新的解决方案。

局限性

  • 模型假设请求和任务的依赖关系已知且静态,实际应用中动态变化和不确定性可能影响调度效果。
  • 算法在大规模智能体池中搜索复杂状态空间时,存在计算开销较高的问题,需进一步优化搜索策略。
  • 当前评估主要集中在合成DAG和MetaGPT工作流,实际工业场景中的多样性和复杂性尚待验证。

未来方向

未来将探索动态任务依赖和不确定性建模,提升调度的鲁棒性;同时结合深度强化学习优化状态搜索策略,降低计算复杂度;还将扩展到多GPU环境和异构资源管理,推动多智能体LLM系统的实际部署和应用。

AI 总览摘要

随着大规模多智能体大语言模型(LLM)在复杂任务中的广泛应用,如何高效利用有限GPU资源成为关键挑战。传统调度策略多关注请求级别优化,忽视了前缀缓存与请求调度的深度耦合,导致资源利用率低和任务延迟高。本文提出TOPAS,一种面向任务的前缀感知调度框架,通过联合决策缓存中的前缀保留和请求调度,有效平衡了前缀局部性和工作流整体进度。

TOPAS采用层次化搜索策略,结合最长剩余路径预估和未来重用潜力的启发式评分,动态选择最优状态,显著缩短任务完成时间。在合成DAG和MetaGPT工作流中的实验证明,TOPAS平均JCT提升39.8%,第99百分位提升49.4%,在实际软件开发场景中也表现出优越性能。

该方法突破了传统请求调度的局限,将前缀驻留作为显式调度变量,有效减少前缀迁移和抢占开销,提升GPU利用率。未来,结合强化学习和多GPU环境,将推动多智能体LLM系统的高效部署,为AI推理和软件开发等应用提供强有力的技术支撑。

深度分析

研究背景

多智能体大语言模型(LLM)在复杂任务中的应用不断扩大,早期工作如FastChat、SGLang等主要关注请求批处理和缓存管理。随着模型规模增长,前缀缓存成为提升推理效率的关键技术,但有限的GPU内存使得前缀驻留与请求调度之间存在资源冲突。现有调度策略多偏重请求级优化,忽视了工作流依赖和前缀重用的全局影响,导致资源利用率低和延迟增加。近年来,研究开始关注工作流感知调度,但多智能体环境中前缀迁移和请求调度的联合优化仍未充分解决。

核心问题

在多智能体LLM服务中,有限GPU内存限制了前缀缓存的规模,导致请求调度必须在前缀局部性和整体工作流进展之间权衡。传统调度策略如最长前缀匹配(LPM)和最短剩余时间(SRPT)各有优劣,但都未能同时兼顾前缀重用和任务完成时间。如何在共享缓存预算下,动态决策哪些前缀应驻留、哪些请求应调度,成为提升系统性能的核心难题。

核心创新

本研究提出TOPAS,首次将前缀驻留作为显式调度变量,通过层次化搜索与启发式评分,联合优化请求调度与缓存状态。其核心创新包括:1)引入基于最长剩余路径的预估模型,动态评估请求对任务剩余路径的影响;2)结合未来重用潜力,提前调度可能支持后续工作;3)引入任务老化机制,避免任务饥饿。该框架突破了传统请求优先级单一的限制,实现全局最优调度,显著提升多阶段、多智能体环境中的任务完成效率。

方法详解

  • �� 采用层次化状态空间搜索,构建后置GPU状态,结合前缀集和请求集。
  • �� 利用最长剩余路径(LP)模型,评估每个请求对任务剩余路径的预期减少量。
  • �� 设计基于未来重用潜力的启发式评分,结合前缀迁移和抢占成本,动态选择最优状态。
  • �� 引入任务老化机制,确保任务公平性,避免饥饿。
  • �� 通过在SGLang平台实现,结合合成DAG和MetaGPT工作流进行大规模评估,验证调度策略的有效性。

实验设计

在三种合成DAG(Chain-3、DAG-4、DAG-10-Wide)和两种MetaGPT软件开发工作流中,评估TOPAS的性能。对比基线包括FCFS、LPM、Parrot-FCFS、Autellix-LAS和SPF。指标涵盖平均和第99百分位JCT、请求吞吐量。采用Poisson请求到达模型,调度决策平均耗时在2ms以内。实验结果显示,TOPAS在所有场景中均优于基线,平均JCT提升最高达39.8%,第99百分位提升49.4%。

结果分析

TOPAS在合成DAG中显著缩短任务完成时间,平均/第99百分位JCT分别比最优基线提升39.8%/49.4%,在MetaGPT场景中也表现优异。消融实验表明,未来重用和任务老化机制是性能提升的关键。整体来看,TOPAS有效平衡了前缀局部性与工作流进展,减少了前缀迁移和抢占开销,提升GPU资源利用率,验证了其在复杂多阶段、多智能体环境中的优越性。

应用场景

该调度框架适用于大规模多智能体LLM推理系统,特别是在软件开发、AI推理和多任务协作场景中。通过优化前缀驻留和请求调度,显著缩短任务延迟,提高系统吞吐量。未来可结合多GPU和异构资源管理,推动工业级AI系统的高效部署,满足复杂应用对实时性和效率的双重需求。

局限与展望

当前模型假设任务依赖关系已知且静态,实际场景中任务动态变化和不确定性可能影响调度效果。搜索策略在大规模状态空间中存在计算瓶颈,需进一步优化。评估主要集中在合成和特定工作流,工业应用中的多样性和复杂性仍待验证。未来需增强模型的鲁棒性和扩展性,降低计算成本。

通俗解读 非专业人士也能看懂

想象你在管理一个大型厨房,里面有许多厨师(智能体)同时准备不同的菜肴(任务)。每个厨师有自己的食谱(前缀),需要用到一些公共的食材(缓存中的前缀)。厨房的空间有限,不能让所有食材都存放在一起,所以你必须决定哪些食材留在厨房,哪些厨师可以使用这些食材。合理安排厨师使用食材,不仅能让菜肴更快做好,还能减少不断搬动食材的时间。这个调度就像TOPAS,它帮助你在有限空间里,既让厨师用到常用食材,又保证菜肴按时完成。

简单解释 像给14岁少年讲一样

想象你在学校的食堂里,有很多学生(请求)同时想吃饭。每个学生有自己的菜单(任务),而厨房里存放的食材(前缀缓存)有限。为了让所有学生都能快点吃到饭,你需要决定哪些食材放在厨房,哪些学生可以用到这些食材。比如,有的学生经常点同样的菜(同一前缀),把这些菜的食材放在厨房里可以节省时间,但如果放太多不同的菜,厨房就会变得拥挤,不能同时服务太多学生。TOPAS就像一个聪明的食堂管理员,他会根据每个学生的点餐习惯,合理安排食材和学生的顺序,让每个人都能尽快吃到饭,又不让厨房太拥挤。

术语表

Prefix Cache (前缀缓存)

存储静态前缀的KV对,用于重复请求的快速响应。技术上为请求共享的静态KV集合,减少重复计算。

论文中用于描述多智能体LLM请求中静态前缀的存储与重用机制。

Longest Remaining Path (最长剩余路径)

估算任务中剩余服务路径的最长长度,用于衡量任务的剩余工作量。算法通过反向拓扑排序计算。

作为调度中衡量任务优先级和优化目标的核心指标。

Task-Oriented Prefix-Aware Scheduler (任务导向前缀感知调度器)

一种结合任务进展和前缀重用的调度策略,动态决策缓存状态和请求调度以最小化任务完成时间。

论文提出的TOPAS调度框架的核心思想。

GPU KV Cache (GPU键值缓存)

存放模型静态前缀KV对的有限存储,用于加速推理请求。资源有限,需合理调度。

调度决策的重要资源限制因素。

Workflow DAG (工作流有向无环图)

描述任务依赖关系的有向无环图,定义任务的执行顺序和依赖关系。

用于建模多阶段、多智能体任务的结构。

开放问题 这项研究留下的未解疑问

  • 1 如何在动态变化的任务依赖和不确定请求到达时间下,进一步优化前缀调度策略?
  • 2 多GPU环境中,调度策略如何扩展以实现全局资源最优?
  • 3 在实际工业场景中,如何应对模型和任务的高动态性与复杂性?

应用场景

近期应用

AI推理加速平台

利用TOPAS优化多智能体LLM请求调度,提升推理速度和资源利用率,适用于企业AI服务和云端推理平台。

软件开发自动化

在软件开发中,结合多任务调度和前缀缓存管理,缩短开发流程中的模型推理时间,提高开发效率。

远期愿景

智能多任务协作系统

推动多智能体系统在自动驾驶、机器人协作等领域的应用,通过高效调度实现实时响应和大规模部署。

原文摘要

Prefix caching introduces a fundamental tradeoff in multi-agent large language model (LLM) serving: retaining a long system-prompt key-value (KV) cache for an agent accelerates future calls, yet it reduces the GPU memory available for batching concurrent requests. In multi-stage workflows, existing schedulers tend to prioritize either immediate prefix locality or overall workflow progress. However, under a shared KV cache budget, optimizing either objective in isolation can prolong tasklevel job completion time (JCT) through downstream delays or frequent prefix replacement. To strike a balance, we here propose TOPAS, a Task-Oriented Prefix-Aware Scheduler that jointly decides which agent prefixes to keep in the cache and which requests to schedule for execution. TOPAS scores candidate post-decision states by trading off the expected reduction in each task's longest remaining service path against the near-term benefit of downstream prefix reuse, accounting for the costs of prefix movement and preemption. A task-level aging mechanism is also incorporated to prevent starvation. We implement TOPAS within the SGLang framework and assess its performance on three synthetic DAGs and two MetaGPT software-development workflows. Compared with the best performing baseline for each workload and metric, TOPAS reduces the mean/p99 JCT by up to 39.8%/49.4% on the synthetic workloads, while lowering mean JCT by 9.8% on MetaGPT-SOP and mean/p99 JCT by 22.0%/26.6% on MetaGPT-TL.

cs.CL