🤖 AI

Harmonia: End-to-End RAG Serving Optimization

Harmonia 是一个端到端的 RAG 服务框架，通过灵活的流水线接口、异构感知部署以及闭环运行时控制器，优化了跨异构组件的性能，与商业替代方案相比，实现了超过 2.04 倍的吞吐量提升，并减少了高达 78.4% 的 SLO 违规。

原作者： Saurabh Agarwal, Bodun Hu, Luis Pabon, Myungjin Lee, Jayanth Srinivasa, Aditya Akella

发布于 2026-06-09

📖 1 分钟阅读☕ 轻松阅读

原作者： Saurabh Agarwal, Bodun Hu, Luis Pabon, Myungjin Lee, Jayanth Srinivasa, Aditya Akella

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下你正在经营一家高端餐厅。在过去，厨师（AI）只需按照顾客的订单烹饪即可。但现在，顾客想要的是“复合型 AI”菜肴：他们要求厨师先查阅大量的食谱库（检索/Retrieval），也许让副厨重写配方（查询转换/Query Transformation），然后再进行烹饪（生成/Generation）。

这就是 RAG（检索增强生成）。它让 AI 变得更聪明、更准确，但也带来了极其复杂的运行管理难题。

这篇论文介绍了一个名为 Harmonia 的新系统，它被设计成这些复杂 AI 菜肴的终极“餐厅经理”。以下是它的工作原理，通过简单的概念进行拆解：

问题所在：为什么现有系统表现不佳

目前，大多数 AI 系统将复杂的订单视为一个巨大的、单一的工作块。它们试图同时扩大或缩小整个厨房的规模，这非常低效。

“僵化配方”问题： 现有的工具强迫开发者以一种非常特定且笨拙的方式编写代码（例如使用严格的领域特定语言 DSL）。如果他们想稍微修改一下配方——比如增加一个安全检查步骤——他们往往必须重建整个厨房框架。这就像被迫在每一次切割时都必须使用特定品牌的刀具；如果你想换一种工具，就必须买下一整套新厨房。
“一刀切”问题： 在 RAG 工作流中，有些步骤侧重于大脑（GPU），有些侧重于内存（CPU），有些则仅仅是查找信息（I/O）。
- 类比： 想象一个厨房，其中“寻找食材”这一步需要 10 秒钟，但“烹饪”这一步只需要 1 秒钟。如果你有 100 名厨师都在做同样的事情，你会发现 99 名厨师都在原地等待那一个正在找食材的人。现有系统会同时扩展整个群体，从而浪费资源。
“盲目经理”问题： 工作负载在不断变化。有时顾客问一个简单的问题；有时他们要求一个复杂的问题，需要厨师查阅资料库、重写问题、再次检查，然后再烹饪。现有系统无法预见这种情况。它们无法优先处理紧急订单或实时调整厨房人员，从而导致漫长的等待时间（违反服务水平目标，即 SLO）。

解决方案：Harmonia

Harmonia 是一个端到端的系统，负责管理从开始到结束的整个过程。它拥有三个主要的“超能力”：

1. 灵活的蓝图（规范层/Specification Layer）

Harmonia 让开发者可以使用普通的、日常的 Python 代码来编写他们的 AI 工作流。

类比： Harmonia 不会强迫你填写一份僵化的政府表格来设计你的厨房，而是让你直接在餐巾纸上画出你的厨房。然后，它会自动读取你的图纸，理解流程（例如：“先查阅资料库，然后烹饪”），并将其转化为机器可理解的地图。你不需要学习新语言，只需编写你想要的逻辑。

2. 智能用工计划（部署层/Deployment Layer）

一旦 Harmonia 理解了你的工作流，它就会计算出你具体需要多少名“厨师”和“图书管理员”。

类比： 如果你的配方显示“搜索”步骤是瓶颈，Harmonia 不会仅仅雇佣 100 名全能厨师。它会雇佣 100 名专业的图书管理员，而只雇佣 10 名厨师。它通过解决一个复杂的数学问题，确保流水线的每个部分都有足够的资源来保持运转，而不会在闲置员工上浪费钱。它将整个工作流视为一个连接的图（Graph），而不是一个单一的块。

3. 交通警察（运行时控制器/Runtime Controller）

这是在运行期间观察厨房的实时经理。

类比： 想象一个站在繁忙路口的交通警察。
- 优先级排序： 如果一位顾客已经等待了很长时间，或者他们的订单很复杂，警察会让他们插队。
- 动态扩缩容： 如果“搜索”步骤突然变得非常拥挤，警察会立即叫来更多的图书管理员。
- 智能流式传输： 有时，以微小的块（Streaming）发送数据很快；但有时，这会堵塞管道。警察会根据当前厨房的繁忙程度来决定最佳的数据块大小。

结果：它究竟好在哪里？

作者使用四种不同类型的复杂 AI 工作流，将 Harmonia 与两种流行的商业系统（LangChain 和 Haystack）进行了对比测试。

速度： Harmonia 处理请求的速度平均比竞争对手快 2.04 倍。
可靠性： 它将系统未能达到速度承诺（SLO 违规）的情况减少了高达 78.4%。

核心总结

Harmonia 是一个不再将复杂的 AI 工作流视为单一、僵化机器的系统。相反，它将其视为一个动态的、有生命的生态系统。它让开发者能够轻松构建灵活的工作流，自动为每一步计算出完美的资源组合，并充当智能交通控制器，确保即使在工作负载变得混乱时，一切也能顺利运行。

论文声称，这是第一个将所有这三种能力（灵活编码、智能资源分配和实时控制）整合进一个包中的系统，使其比目前市面上可用的系统更快、更可靠。

技术摘要：Harmonia – 端到端 RAG 服务优化

1. 问题陈述

检索增强生成（RAG）已成为通过集成外部知识来提高大语言模型（LLM）可靠性的关键范式。然而，在大规模场景下高效地提供 RAG 工作流服务面临着重大挑战，现有框架未能解决这些问题。本文识别了三个主要瓶颈：

僵化的编程模型： 现有的框架（如 LangChain、Haystack）通常依赖于僵化的、声明式的领域特定语言（DSL）或特定的图算子。这阻碍了快速实验以及集成不断演进的新组件（例如，多样化的检索结构、安全门控或自适应控制流），而无需修改框架本身。
单体资源视图： RAG 流水线表现出极高的异构性，混合了 CPU/内存/I/O 密集型阶段（检索、后处理）与 GPU 密集型阶段（生成）。当前系统通常将这些工作流视为单体 Python 进程，迫使所有阶段共享单一资源池。这导致了粗粒度的复制，即扩展整个工作流是低效的，因为瓶颈会根据工作流拓扑和查询复杂度发生动态转移。
缺乏运行时可见性与控制： RAG 工作负载具有高度的随机性。控制流可以根据中间结果进行分支、递归或提前退出。此外，像流式传输（streaming）这样的通信机制是依赖于负载的；虽然在低负载时有益，但管理不当的流式传输会在高负载时导致流水线停顿和吞度下降。现有框架缺乏实现自适应路由、优先级排序和实时资源分配所需的全局遥测和闭环控制。

2. 方法论：Harmonia 框架

Harmonia 是一个端到端的 RAG 服务引擎，旨在通过三层架构解决上述挑战：规范层（Specification Layer）、部署层（Deployment Layer）和运行时控制层（Runtime Control Layer）。

2.1 规范层：意图驱动的 Python 接口

Harmonia 允许开发者使用地道的 Python 编写 RAG 流水线，避免了自定义 DSL 带来的摩擦。

库无关集成： 开发者可以使用任何外部库作为组件。
受管分布式 Actor： 与将 Actor 视为长期运行的脱离进程的通用框架（如 Ray）不同，Harmonia 将被装饰的类视为完全受管的分布式 Actor。它自动处理生命周期、状态管理和资源分配。
流式对象（Streaming Objects）： 一种受管的 Streaming Object 抽象将开发者逻辑与底层通信细节解耦，允许异步写入，同时由运行时控制通信粒度。
工作流约束： 开发者可以声明式地指定约束，例如状态性（确保递归工作流的一致性路由）、资源需求（CPU/GPU/内存）以及最小实例数量。

2.2 部署层：异构感知优化

部署层通过对抽象语法树（AST）进行静态分析，从 Python 代码中捕获可执行的流水线图。它将工作流建模为一个带有基于剖析（profile-driven）条件路径的有向无环图（DAG）。

资源分配公式化： Harmonia 将资源分配表述为一个广义的网络流问题。它通过优化组件（例如，检索器数量与生成器的比例）的放置和容量，在预算约束下最大化端到端吞吐量。
关键参数： 优化过程考虑了源自离线剖析的吞吐系数 ( $\alpha$ )、请求放大因子 ( $\gamma$ ) 和路由概率 ( $p$ )。
分布式部署： 它会自动注入一个分布层，使用高性能 gRPC 进行节点间通信，并使用共享内存进行节点内执行，从而屏蔽了底层的部署细节。

2.3 运行时控制层：闭环自适应

为了处理运行时的随机性和变化的瓶颈，Harmonia 采用了一个中心化的控制平面，将控制决策与数据移动解耦。

全局遥测： 控制器监控图节点上的执行进度、队列情况和资源压力。
动态重新分配： 它定期（每 10 秒）使用更新后的运行时吞吐量和分支概率估计值重新求解优化模型，以重新配置资源。
负载与状态感知路由： 调度器通过跟踪待处理的状态化任务和预测的重入模式来预判未来负载，从而避免将请求分发给看似空闲但实际上为状态化迭代保留的实例。
通信粒度管理： 控制器根据实时负载动态调节流式传输的数据块大小，以防止因管理不当的资源竞争导致的流水线停顿。
SLO 管理： 利用在线线性回归模型，控制器估计正在进行的请求的“松弛度”（Slack，即距离 SLO 截止时间剩余的时间）。它实现了一种截止日期感知的调度器，优先处理松弛度最低的请求，并通过通信接口传播优先级。

3. 核心贡献

通用的 RAG 服务框架： Harmonia 是第一个共同解决 RAG 工作流规范、异构感知部署和闭环运行时控制的系统。
灵活的规范： 它支持使用标准 Python 表达复杂的、有条件的和递归的 RAG 工作流，在不强迫开发者使用脆弱 DSL 的情况下捕获执行图。
异构感知配置： 它超越了单体扩展，将 RAG 组件视为具有特定资源需求的独立实体，通过求解网络流问题来优化放置和容量。
闭环运行时控制： 它引入了动态资源重新分配、状态感知路由和自适应通信粒度等机制，以管理随机工作负载下的 SLO。
开源： 作者承诺开源 Harmonia 以支持研究社区。

4. 实验结果

作者在四个代表性的 RAG 架构（Vanilla-RAG, Corrective-RAG, Self-RAG, Adaptive-RAG）上评估了 Harmonia，并将其与商业基准（LangChain 和 Haystack）在包含 4 台服务器（每台配备 8 个 NVIDIA A100 GPU）的集群上进行了对比。

吞吐量： Harmonia 的吞吐量最高比基准提升了 2.04 倍（平均提升 1.6 倍）。在具有条件分支和递归的复杂流水线中（例如 Corrective-RAG 提升了 2.04 倍），增益最为显著。
SLO 违规： Harmonia 将 SLO 违规减少了高达 78.4%。这种减少在 Adaptive-RAG（78.4%）和 Self-RAG（41.3%）中最为明显，证明了系统基于执行异构性和松弛度预测进行优先级排序的能力是有效的。
开销： 与单节点 LangChain 执行相比，部署层的引入开销微乎其微（约 0.8%）。运行时控制器为每个请求增加了约 2ms 的延迟，即使在高负载（1024 req/s）下也保持稳定。
资源效率： 消融实验证实，没有任何单一机制可以独立发挥作用；必须结合资源管理、路由和通信粒度管理才能实现最优性能。例如，在 Corrective-RAG 中，系统正确识别出“Grader”是瓶颈，并为其分配了额外资源，而基准方案则未能做到这一点。

5. 重要性与主张

论文声称 Harmonia 代表了 RAG 系统设计与运营方式的根本转变。通过将 RAG 工作流作为高层可执行请求图暴露给控制平面，Harmonia 将慢时间尺度的规划与快时间尺度的自适应分离。

作者认为，这种架构之所以至关重要，是因为：

僵化的抽象在组件快速演进的时代成本高昂。
由于异构流水线中瓶颈的移动特性，静态配置是不够的。
狭窄的运行时接口无法捕捉复合 AI 应用中固有的跨阶段依赖关系和随机性。

Harmonia 证明，端到端协调——结合灵活的规范、智能的配置以及响应式的运行时控制——对于在生产级 RAG 系统中实现高吞吐量和低延迟是必不可少的。论文总结道，尽管它目前尚未支持具有即时 LLM 驱动控制流的完全动态 Agent 工作流，但其中心化控制平面架构为未来的智能体编排提供了基础性的方法。