HeraSys：通过细粒度端到端优化实现多LLM工作流的协同服务

# HeraSys：通过细粒度端到端优化实现多LLM工作流的协同服务

来源：https://arxiv.org/html/2607.22578

Zhiqing Tang✉\{\}^\{\\textrm\{\{\\char 0\\relax\}\}\} Hongrui Liang Jianxiong Guo Jiong Lou Tian Wang Weijia Jia

###### 摘要

大型语言模型（LLMs）的普及使得服务系统从处理孤立请求转向编排高并发、多租户的智能体工作流。然而，现有解决方案通常优先考虑工作流内部优化，在很大程度上忽略了工作流间优化的巨大潜力。本文提出了HeraSys，一个旨在优化并发工作流端到端性能的LLM服务系统。通过细粒度编排，HeraSys通过结构节点合并和重用消除了跨工作流的计算冗余。此外，HeraSys引入了一种负载感知的联合调度策略，通过评估查询间和查询内的优先级来动态管理执行顺序。通过将资源倾斜机制与自适应批处理和流水线分解相结合，HeraSys在保持低平均延迟的同时有效减少了尾延迟，从而大幅提高了系统吞吐量。大量实验表明，在严格的延迟保证下，HeraSys将P99延迟降低了最高2.17倍，并将服务吞吐量提高了最高1.85倍。

LLM服务，智能体工作流，调度，性能优化

## 1 引言

大型语言模型（LLMs）的快速发展已将现代应用开发从简单的单轮对话界面转变为由多次LLM调用和外部工具组成的复杂智能体工作流。为了执行这些任务，应用程序通常被表示为包含相互依赖步骤的有向无环图（DAG）。目前，服务系统主要在单一维度上优化性能：要么关注LLM推理任务之间的依赖关系（Kwon等，2023（https://arxiv.org/html/2607.22578#bib.bib16）；Lin等，2024（https://arxiv.org/html/2607.22578#bib.bib10）；Zhong等，2024（https://arxiv.org/html/2607.22578#bib.bib23）；Shen等，2026（https://arxiv.org/html/2607.22578#bib.bib32）），要么关注单个工作流内的编排逻辑（Chase and LangChain Team, 2024（https://arxiv.org/html/2607.22578#bib.bib43），2025（https://arxiv.org/html/2607.22578#bib.bib44）；Wu等，2024b（https://arxiv.org/html/2607.22578#bib.bib13））。这些方法有效地优化了单个请求，但没有解决系统级执行的更广泛上下文。然而，在多租户设置中，服务系统通常将并发工作流视为独立实例。这种方法忽略了跨请求共享的关键应用层信息。尽管一些近期工作试图缓解这个问题，但它们通常缺乏全局上下文的整体视图，未能有效应对并发执行中的固有冗余和资源争用（Mei等，2025（https://arxiv.org/html/2607.22578#bib.bib14）；Liu等，2025a（https://arxiv.org/html/2607.22578#bib.bib31）；Lin等，2024（https://arxiv.org/html/2607.22578#bib.bib10）；Luo等，2025（https://arxiv.org/html/2607.22578#bib.bib27）；Shen等，2025（https://arxiv.org/html/2607.22578#bib.bib26））。我们观察到，通过打破这种请求级隔离，联合优化跨工作流计算冗余和全局协调调度，可以在端到端性能上实现显著的改进。

参见说明(a) 模块化编排中的数据隔离和冗余。
参见说明(b) 细粒度编排暴露出的融合机会。
参见说明(c) 融合逻辑扩展到带有函数调用的智能体工作流。
图1：计算冗余和融合机会。

第一个挑战是如何减轻因孤立处理工作流而导致的巨大开销，这掩盖了关键的任务冗余（Shen等，2025（https://arxiv.org/html/2607.22578#bib.bib26）；Gim等，2024（https://arxiv.org/html/2607.22578#bib.bib24））。例如，在生产LLM应用中，多个并发查询通常涉及对同一批公共文档块进行嵌入和检索，如图1(b)（https://arxiv.org/html/2607.22578#S1.F1.sf2）所示。这种细粒度的数据冗余允许进行融合和去重。类似地，在智能体工作流中，图1(c)（https://arxiv.org/html/2607.22578#S1.F1.sf3）说明不同的智能体可能需要调用相同的工具或处理相似的前缀上下文（Abhyankar等，2024（https://arxiv.org/html/2607.22578#bib.bib18））。然而，如图1(a)（https://arxiv.org/html/2607.22578#S1.F1.sf1）所示，现有的模块化设计缺乏全局视图，无法检测这些重叠，迫使系统执行冗余任务。这不仅增加了系统负载，也限制了系统吞吐量。因此，通过跨工作流融合利用这些细粒度的结构共性，为消除计算浪费提供了一条有希望的途径。

参见说明(a) FCFS：队头阻塞。
参见说明(b) SJF/SRTF：长任务饥饿。
参见说明(c) 我们的方法：资源预留。
图2：通过资源倾斜缓解阻塞和饥饿。

第二个挑战是如何在调度中平衡延迟和公平性，这一目标因工作负载的异构性而变得复杂。真实工作负载通常混合了短任务（如简单问答）和长任务（如长文档分析、多轮迭代推理）。在这种设置下，简单的先来先服务（FCFS）或轮询调度通常会导致队头（HOL）阻塞：如图2(a)（https://arxiv.org/html/2607.22578#S1.F2.sf1）所示，一个长时间运行的任务可能会长时间占用资源，延迟许多后续的短任务。相反，如图2(b)（https://arxiv.org/html/2607.22578#S1.F2.sf2）所示，严格优先处理短任务（SJF/SRTF）可能导致长任务资源饥饿，造成不公平（Luo等，2025（https://arxiv.org/html/2607.22578#bib.bib27）；Wu等，2024a（https://arxiv.org/html/2607.22578#bib.bib28））。为解决这个问题，我们发现将长任务的资源预留与短任务的优先级相结合，可以防止饥饿并在性能与服务质量（QoS）之间取得平衡，如图2(c)（https://arxiv.org/html/2607.22578#S1.F2.sf3）所示。

本文提出了HeraSys，一个针对多工作流场景的细粒度端到端服务系统（§2.1（https://arxiv.org/html/2607.22578#S2.SS1））。HeraSys采用两层优化架构：（I）执行前图融合器在执行前识别并融合跨查询的冗余子图，生成更高效的图。（II）运行时负载感知联合调度器动态优先处理传入的查询任务，将资源分配偏向潜在瓶颈，并根据系统负载调整批大小和流水线分解粒度。这确保系统在动态负载变化下保持高效并满足服务要求。我们在配备NVIDIA RTX 4090 GPU的服务器节点上实现了HeraSys，使用vLLM作为推理后端。我们使用包括LangGraph（Chase and LangChain Team, 2025（https://arxiv.org/html/2607.22578#bib.bib44））、LlamaIndex（Liu and LlamaIndex Team, 2025（https://arxiv.org/html/2607.22578#bib.bib45））和最新系统Ayo（Tan等，2025（https://arxiv.org/html/2607.22578#bib.bib15））在内的代表性基线，使用RAG、Web搜索和混合场景等多种工作负载对HeraSys进行了评估。大量实验验证了我们设计的有效性，表明与最新基线相比，HeraSys在端到端延迟和系统吞吐量方面均取得了显著的性能提升。本文的主要贡献如下：

1. 我们设计了一种双层优化架构，以解决现有服务系统在多工作流场景中的瓶颈。该架构克服了传统的请求级隔离，通过执行前图融合和运行时动态调度的结合，实现了资源利用率和调度效率的联合优化。
2. 我们提出了一种跨查询图节点重用机制，能够识别并消除工作流间的冗余计算子图，显著降低计算开销（§3.3（https://arxiv.org/html/2607.22578#S3.SS3））。
3. 我们提出了一种负载感知的联合调度策略。通过将动态长/短查询分类、偏置资源分配和自适应批处理相结合，该策略有效降低了查询处理的端到端延迟（§3.4（https://arxiv.org/html/2607.22578#S3.SS4））。
4. 我们实现了HeraSys，并通过与最新系统的大量实验比较证明了我们方法的有效性。

##### 利益冲突披露。作者声明与这项工作没有相关的经济利益冲突。

参见说明(a) 传统工作流编排。
参见说明(b) 细粒度工作流编排。
图3：编排范式的结构比较。细粒度编排将模块化架构分解为细粒度的原始节点，例如将索引（Indexing）拆分为嵌入（Embedding）和摄取（Ingestion），并将LLM预填充（Prefilling）拆分为部分和完整阶段，从而暴露出更大的并行性和优化空间。此外，HeraSys将LLM解码（Decoding）分解为顺序子节点，并动态调节流水线分解粒度。

## 2 相关工作

### 2.1 细粒度工作流编排

早期的LLM框架使用模块化抽象（图3(a)（https://arxiv.org/html/2607.22578#S1.F3.sf1））来简化编排，但对服务系统隐藏了上层控制流和数据依赖关系。这限制了端到端优化（Liu and LlamaIndex Team, 2025（https://arxiv.org/html/2607.22578#bib.bib45）；Chase and LangChain Team, 2024（https://arxiv.org/html/2607.22578#bib.bib43），2025（https://arxiv.org/html/2607.22578#bib.bib44）；Wu等，2024b（https://arxiv.org/html/2607.22578#bib.bib13））。为解决模块化封装的瓶颈，最近的研究转向了细粒度编排。如图3(b)（https://arxiv.org/html/2607.22578#S1.F3.sf2）所示，Ayo（Tan等，2025（https://arxiv.org/html/2607.22578#bib.bib15））提出了一种基于任务原语的方法，将模块化任务解耦为通用计算节点，以实现更好的并行性。类似地，其他工作专注于优化数据流水线（Lin等，2024（https://arxiv.org/html/2607.22578#bib.bib10）；Shen等，2025（https://arxiv.org/html/2607.22578#bib.bib26）；Hong等，2024（https://arxiv.org/html/2607.22578#bib.bib34）；Qian等，2024（https://arxiv.org/html/2607.22578#bib.bib9）；Khattab等，2024（https://arxiv.org/html/2607.22578#bib.bib8））。尽管这些系统通过调整编排粒度提高了工作流内部效率，但它们往往错过了跨工作流的全局优化机会。

### 2.2 多层次冗余消除

消除冗余是提升系统吞吐量的关键。在推理层面，vLLM（Kwon等，2023（https://arxiv.org/html/2607.22578#bib.bib16））和SGLang（Zheng等，2024（https://arxiv.org/html/2607.22578#bib.bib12））使用基于块的内存和基于前缀树的缓存来实现KV缓存重用。像GPTCache（Bang, 2023（https://arxiv.org/html/2607.22578#bib.bib25））和Prompt Cache（Gim等，2024（https://arxiv.org/html/2607.22578#bib.bib24））这样的方法探索了基于语义相似性或模式模块化的重用。其他研究针对跨实例的分布式去重，通过分布式缓存池或编码技术实现低延迟共享（Qin等，2025（https://arxiv.org/html/2607.22578#bib.bib17）；Yao等，2025（https://arxiv.org/html/2607.22578#bib.bib33）；Shen等，2025（https://arxiv.org/html/2607.22578#bib.bib26）；Liu等，2024（https://arxiv.org/html/2607.22578#bib.bib7），2025b（https://arxiv.org/html/2607.22578#bib.bib6））。尽管这些工作在多个层面减少了冗余，但它们无法检测工作流中复杂的全局图拓扑，也无法在执行前识别结构冗余。

### 2.3 异构工作流调度

LLM工作流具有高度异构性。虽然早期的推理调度器引入了如迭代级调度等技术来减少批处理引起的阻塞（Yu等，2022（https://arxiv.org/html/2607.22578#bib.bib11）；Wu等，2024a（https://arxiv.org/html/2607.22578#bib.bib28）；Leviathan等，2023（https://arxiv.org/html/2607.22578#bib.bib3）），但它们难以处理复杂工作流。为了解决这个问题，DistServe（Zhong等，2024（https://arxiv.org/html/2607.22578#bib.bib23））、Sarathi-Serve（Agrawal等，2024（https://arxiv.org/html/2607.22578#bib.bib4））和Splitwise（Patel等，2024（https://arxiv.org/html/2607.22578#bib.bib5））将推理阶段解耦以提高资源利用率。Autellix（Luo等，2025（https://arxiv.org/html/2607.22578#bib.bib27））分析了HOL阻塞，并提出了基于已获得服务时间的调度。Hermes（Liu等，2025a（https://arxiv.org/html/2607.22578#bib.bib31））使用概率需求图处理波动性，而Helix（Mei等，2025（https://arxiv.org/html/2607.22578#bib.bib14））通过最大流公式优化集群调度。然而，在动态工作负载下，这些方法往往受限于建模开销或偏差，并且缺乏对长尾任务的公平性。因此，需要一种轻量级、反馈驱动的机制来减少尾延迟并确保公平性。

## 3 方法

### 3.1 问题形式化

我们将多租户查询调度和资源分配问题形式化为一个在线优化任务。在任何时间\(t\)，系统接收并处理一组到达的查询\(\mathcal{Q}_{t}\)。

工作负载模型。每个查询\(q \in \mathcal{Q}_{t}\)被建模为一个DAG \(G_{q} = (\mathcal{V}_{q}, \mathcal{E}_{q})\)，其中\(\mathcal{V}_{q}\)是任务节点集合，\(\mathcal{E}_{q}\)表示它们的顺序依赖关系。对于每个节点\(v \in \mathcal{V}_{q}\)，我们定义以下属性：\(w_{v}\)表示工作负载估计（具体来说，对于非LLM节点是输入文本大小或FLOPs，对于LLM节点是预期的令牌数）；\(p_{v}\)指定可执行的设备类型集合，例如嵌入或LLM实例；\(d_{v}\)表示反向拓扑深度，定义为该节点到汇点的距离；\(s_{v}\)表示可拆分上限，允许将该节点并行拆分成\(k\)个子节点。

资源模型和决策变量。令\(\mathcal{R}\)表示可用的系统资源集合。每个资源\(r \in \mathcal{R}\)由其类型\(\tau(r)\)、并行容量\(cap_{r}\)和批处理限制\(B_{r}\)来表征。在每个决策步骤，系统确定四个变量：\(x_{v,r} \in \{0,1\}\)表示是否将节点\(v\)调度到资源\(r\)上；\(b_{v,r} \in \mathbb{N}^{+}\)表示批大小；\(a_{v,r}\)表示资源份额分配；\(k_{v} \in [1, s_{v}]\)是流水线分解数量。如图3(b)（https://arxiv.org/html/2607.22578#S1.F3.sf2）所示，\(k_{v}\)允许系统将线性任务链（例如，嵌入→搜索→重排序）分解成\(k\)个并行子流水线。