使用 Ayo 框架优化大语言模型应用

1 大语言模型应用背景与面临的挑战

大语言模型（LLM）及其多模态变体在理解用户查询和生成内容方面带来了革命性的进展，催生了如集成大模型的搜索引擎、具有情感陪伴能力的 AI 智能体等新兴应用。然而，大语言模型本身往往无法独立满足多样化且复杂的用户需求，例如在知识时效性、长上下文理解等方面存在固有缺陷，容易导致“幻觉”现象。

为了缓解这些问题，业界广泛采用诸如检索增强生成（RAG）、外部函数调用以及多智能体交互等技术。流行的应用框架支持将各类功能模块集成在一起，构建端到端的应用流水线。通常，大模型推理过程可分为两个主要阶段：

• 预填充（Prefilling）：处理所有输入标记（如指令、上下文等）并生成首个输出标记。该阶段属于计算密集型任务。
• 解码（Decoding）：基于键值缓存（KV Cache）迭代生成剩余的输出标记。该阶段由于每次迭代只需处理前一次生成的新标记，属于内存密集型任务。

尽管业界在优化大模型本身推理性能方面投入了巨大努力，但由多种异构模块组成的端到端应用整体性能却常常被忽视。在诸多应用场景（如带有 RAG 的文档问答系统）中，非大模型模块（搜索、索引、API调用等）的执行时间往往占据了端到端总延迟的极高比例，甚至有时会超过 50%。

现有主流编排框架大多采用基于模块的粗粒度链式结构，这极大限制了端到端优化的潜力：

• 优化空间受限：各模块相互解耦，框架通常将每个模块视为独立的黑盒，从而错失了模块间的联合优化机会（如跨模块的细粒度并行与流水线操作）。
• 调度缺乏应用全局视野：前端工作流编排与后端计算执行的解耦，导致请求调度仅能关注单个请求引擎层面的吞吐量或延迟，而无法兼顾请求间依赖关系以优化应用的整体端到端性能。

2 细粒度端到端编排机制

为了突破现有框架的局限性，采用基于图元（Primitive）的细粒度数据流图来替代粗粒度的模块化链式结构成为了全新的解决方案。

2.1 图元级数据流图（p-Graph）

在新的编排机制中，任务图元作为工作流的最小基本计算单元，代表特定的基础操作（如部分预填充、解码、向量查询等）。每个图元在数据流图中作为一个符号节点存在，并包含一个详尽的元数据配置文件，用于存储其输入、输出、父节点、子节点等关键网络拓扑属性。此外，该配置还涵盖目标执行引擎信息以及运行参数（如神经网络的批处理大小、大模型提示词等）。

将原始开发者定义的工作流模板与用户特定的查询输入相结合后，系统能够将其转换为更细粒度的图元级数据流图。例如，在 RAG 的整合阶段，处理多块文档上下文的模块可以被解构为多个显式链接的预填充与解码图元。这种表示方式不仅保留了原有的业务依赖关系，更清晰地揭示了工作流的底层内部执行逻辑，为后续通过算法挖掘并行化机会提供了可能。

3 核心系统架构：Ayo 框架设计

Ayo 是一款专为服务复杂大模型应用而设计的细粒度编排框架，其架构主要包含“图优化器”与“运行时调度器”两大核心组件。

3.1 图优化器（Graph Optimizer）

图优化器负责对用户查询转换而来的图元数据流图进行一系列针对性的图转换与优化（Passes），进而生成在运行时更为高效的执行图（e-Graph）：

• 节点并行化（Node Parallelization）：系统会深入扫描数据流图，识别并提取没有严格先后数据依赖关系的图元，安排它们并行执行以最大化并发度。
• 阶段拆分与流水线化（Stage Decomposition）：针对一次性需处理庞大数据量（超出底层计算引擎最大高效批处理上限）的计算图元，系统将其拆分为多个处理子微批次（sub-micro-batch）的阶段，并与下游同样支持批处理的图元形成流水线操作。这种拆分策略极好地平衡了系统资源利用率与执行效率，既掩盖了延迟，又避免了过度细分导致搜索空间的指数级爆炸。
• 因果预填充并行化（Causal Prefilling）：巧妙利用大模型自回归预填充阶段具备可分割属性这一特点，将长上下文的预填充任务拆分为存在前后依赖的多个计算块。这样一来，部分预填充任务就可以与其前置数据准备图元并行执行，从而进一步压缩整体时间线。
• 大模型解码流水线（LLM Decoding Pipelining）：鉴于大模型解码是逐级渐进生成的，一旦模型输出了具备完整语义结构的片段（如一个独立的句子或完整的查询语句），系统便无需等待剩余全段解码结束，可立即将该片段作为有效输入传递给下游图元。这一过程通过特定的解析器持续监控结构化输出从而无缝加速数据流转。

3.2 运行时调度器与拓扑感知批处理（Topology-aware Batching）

Ayo 的运行时系统采用双层调度机制：上层负责管理和派发各个查询对应的优化执行图，下层则由各个独立的底层计算引擎调度器接管。

在底层引擎的请求队列调度中，传统的请求分发系统往往采用“盲目批处理”策略——即单纯基于请求到达的时间顺序（先入先出），只要积压请求数量达到阈值便打包送入引擎。这种做法完全忽略了同一个业务查询图内，不同图元对于推动全图执行完毕的贡献度存在巨大差异。这容易导致一种低效的困境：某些被优先调度的计算节点虽然完成了执行，但因为其强依赖的前置节点尚未被调度，致使其下游的所有相关子节点依然处于干等阻塞状态。

为解决这一问题，Ayo 引入了拓扑感知批处理调度算法：

• 在生成每条查询的优化执行图之后，系统通过反向拓扑排序算法预先计算并标记每个图元节点在工作流中的深度属性（输出节点的深度最小）。
• 在引擎执行调度周期内，系统将同一队列中待处理的图元请求按其所属查询分组，并在组内严格按深度优先级进行排序。
• 调度器在构建批处理时，会优先抓取深度数值更高（即更接近业务执行起始端、阻碍整体进度最严重的节点）的图元请求。以此确保分配的计算资源能够如同“推倒多米诺骨牌”一般，最高效地解锁后续图元的依赖约束，从而顺畅推进整个端到端应用工作流的流转。

4 实验效果与结论验证

Ayo 框架的原型开发主要基于 Ray 分布式计算框架以实现集群化的调度与执行，并融合了多类底层引擎库。论文通过涵盖多类目前行业前沿应用场景的详尽评估验证了该方案，这些应用场景包括：基于轻量和高级 RAG 架构的专业文档问答系统、搜索引擎增强生成应用，以及上下文数据检索流水线等。

实验数据证明，基于细粒度图元工作流表述以及拓扑感知的协同批处理技术，Ayo 相比于现有主流的粗粒度编排框架显著缩减了复杂应用的端到端时间延迟，在各项评测基准中最高可取得多达 2.09 倍的绝对速度提升。这种深入应用本质执行逻辑的设计哲学，为未来进一步构建具备极高效率的大规模生产级 AI Agent 及多模型协同流水线确立了前瞻性的基础。