你的 Agent 工作流浪费了 56% 的算力：NUS 团队用数据库思维重构 LLM Serving

核心直觉：你以为 vLLM 的 PagedAttention 已经把 LLM 推理优化到极致了？但当多个 Agent 串起来执行一个任务时，vLLM 把每次 LLM 调用当作独立请求处理——同样的 prompt prefix 被重复计算几十次，中间结果在不同 Agent 之间来回传递却从不缓存。NUS 的 Helium 把 Agent 工作流当作数据库查询计划来优化，用 proactive caching 和 cache-aware scheduling 砍掉了这些隐藏的冗余，实现了 1.56 倍加速。

一、Agent 工作流的隐藏成本

你搭建了一个三 Agent 的股票分析工作流：

1. Reader Agent：读取 10 份财报，提取关键指标
2. Analyst Agent：分析指标，生成投资观点
3. Writer Agent：把观点整理成报告

你用 vLLM 部署了模型，启用了 PagedAttention 和 prefix caching。你觉得性能已经最优了。

但实际上，这个工作流中存在大量隐藏的冗余：

vLLM 的问题不是不够好，而是它的优化粒度错了——它优化的是"单个 LLM 调用"，但 Agent 工作流的核心挑战是"跨调用的全局优化"。

二、Helium 的核心洞察：把 LLM 调用当作数据库 Operator

2.1 三个被忽视的范式差异

论文指出，Agentic workflows 和传统的 SQL pipelines 有三个根本差异：

① Operator Abstraction

• 传统数据库：operator 是无状态的（select、filter、join），输出只取决于输入
• LLM Operator：是有状态的。模型内部有 KV cache，输出是 token-by-token 生成的。batching 机制也不是简单的"一批数据一起处理"，而是 continuous batching

② Inter-operator Sharing

• 传统数据库：operator 之间传递的是数据行，没有状态依赖
• Agent 工作流：Agent 2 的 prompt 可能包含 Agent 1 的输出，连带 KV cache 也可以复用。比如辩论场景中，多个 agent 共享同样的对话历史

③ Inter-workflow Sharing

• 传统数据库：不同查询之间通常是独立的
• Agent 工作流：batch 内的多个查询可能共享同样的数据源（比如"分析今天的天气"），prefix sharing 可以跨查询复用

2.2 现有系统的盲区

Helium 的解法：把 Agent 工作流建模为 DAG（有向无环图），LLM 调用是 first-class operators，然后应用数据库查询优化的经典原则——但重新设计了状态管理和调度机制以适应 LLM 的特性。

三、Helium 的三板斧

3.1 第一板斧：Proactive Caching（主动缓存）

现有系统的 prefix caching 是被动的——等请求来了，看看有没有匹配的 prefix，有就复用，没有就计算。

Helium 的 proactive caching 是主动的：

编译阶段：
  分析 workflow DAG，识别出所有静态 prompt prefixes
  （比如系统提示词、固定的上下文模板）
    ↓
预计算阶段（第一次执行）：
  把这些静态 prefix 的 KV cache 提前计算好
  钉在 GPU 内存里（pinning），不被 LRU 淘汰
    ↓
后续执行：
  直接复用预计算的 KV cache，跳过 prefill

这和被动缓存的区别：

• 被动缓存：请求来了才检查，prefix 可能被之前的请求挤出内存
• 主动缓存：提前知道哪些 prefix 会被用到，预计算并保护起来

全局 Prompt Cache：对于确定性 operator（如 zero temperature 的 LLM 调用、非 LLM 的数据转换），Helium 维护一个全局缓存。如果输入完全一样，直接返回缓存结果，整个 operator 都被 bypass。

3.2 第二板斧：Templated Radix Tree（模板化基数树）

Helium 需要一个数据结构来捕获 workflow 中的 prompt 结构和依赖关系——这就是 TRT（Templated Radix Tree）。

TRT 的核心思想：

• 把 prompt 拆成静态部分（固定文本）和动态部分（placeholder，由其他 operator 的输出填充）
• 用 radix tree 组织静态部分，共享 prefix 的 prompt 在树中共享路径
• 叶子节点是 LLM operator，依赖边表示数据流

例子：

Agent 1 的 prompt: "你是一个金融分析师。分析以下财报：[文档内容]"
Agent 2 的 prompt: "你是一个金融分析师。分析以下财报：[文档内容]。请给出投资建议。"
Agent 3 的 prompt: "你是一个金融分析师。分析以下财报：[文档内容]。请给出风险提示。"

TRT 结构：
                    根
                    |
        "你是一个金融分析师。分析以下财报："
                    |
              [文档内容 placeholder]
              /         \
    "请给出投资建议"    "请给出风险提示"
            |               |
        Agent 2         Agent 3

Agent 2 和 Agent 3 共享前半部分的 KV cache——这在 TRT 中通过共享树路径自动捕获。

3.3 第三板斧：Cache-Aware Scheduling（缓存感知调度）

有了 TRT，Helium 的调度器知道：

• 哪些 operator 共享哪些 prefix
• 什么执行顺序能最大化 cache reuse
• 如何在多个 GPU worker 之间分配任务

调度目标：最小化 makespan（总执行时间）

关键启发式：

1. 优先执行共享 prefix 的 operator 组：避免 cache 被不相关的请求挤出
2. 关键路径优先：优先调度在依赖图上深度最大的 operator（Kelley-Walker 启发式）
3. Nested sequence 结构：把共享静态 prefix 的 operator 分到 inner sequence，在内部 query-by-query 执行；跨 sequence 时 operator-by-operator 执行

这解决了传统调度的一个陷阱：如果简单按 operator 交替调度不同 query，会导致 cache thrashing（反复加载不同 query 的 prefix）。Helium 的 nested sequence 保证了 cache-friendly 的执行顺序。

四、实验结果：1.56x 加速从何而来

4.1 微基准测试（Primitive Workflows）

论文测试了 5 种典型的 Agent 交互模式：

对比基线：

• vLLM：100.92× 更慢（naive sequential 执行）
• OpWise：operator-by-operator 批处理，类似 Spark
• LangGraph：图编排框架
• AgentScope：分布式多 Agent 平台
• Parrot：Semantic Variables + dataflow 分析
• KVFlow：KV cache 管理框架

Helium 在所有 workflow 上都显著优于所有基线。

4.2 端到端复杂工作流

论文还测试了一个金融分析工作流（Trading Workflow），结合了 Parallel、Debate 和 Map-Reduce 三种模式：

• Helium：1.34× 加速 vs 最强基线
• 主要来自：
  • Proactive KV caching：避免系统提示词的重复 prefill
  • Prompt cache：重复查询直接 bypass
  • Cache-aware scheduling：最大化 prefix reuse

4.3 Ablation Study（消融实验）

结论：每个组件都有独立贡献，但 proactive caching 是最关键的（28% 性能来自它）。

五、对开发者的启示

1. 优化粒度：从"单调用"到"全局"

如果你只是部署一个聊天机器人，vLLM 足够了。但如果你构建的是多 Agent 工作流，必须考虑跨调用的全局优化。

关键问题：

• 你的 Agent 之间共享多少 prompt prefix？
• 有多少中间结果可以被缓存？
• 你的 workflow 结构是否允许 prefix sharing？

2. 识别"可缓存性"

不是所有 Agent 工作流都能从 Helium 中受益。收益最大的是：

3. 温度设置很重要

Helium 的 prompt cache 只适用于确定性 operator（如 greedy sampling / zero temperature）。如果你的 Agent 用了高 temperature，同样的输入可能产生不同输出，缓存就失效了。

实用建议：

• 系统提示词、上下文提取等步骤用 zero temperature（可缓存）
• 创意生成、头脑风暴等步骤用高 temperature（不可缓存，但这类步骤通常也不需要缓存）

4. 这不是替代 vLLM，而是叠加

Helium 构建在 vLLM 之上（论文使用 vLLM v0.16.0）。它不是在重写 serving engine，而是在 orchestration 层做全局优化。

架构层次：

应用层：Agent Workflow (LangGraph, AutoGen, etc.)
  ↓
优化层：Helium (query optimizer + cache-aware scheduler)
  ↓
引擎层：vLLM (continuous batching, PagedAttention)
  ↓
硬件层：GPU (H100, A100, etc.)

六、局限与未来方向

6.1 当前局限

1. 只支持 on-premise 部署：需要直接控制 GPU 内存和 KV cache，不支持云 API（如 OpenAI API）
2. 相同模型假设：当前版本假设 workflow 中所有 Agent 使用同一个 base LLM
3. Profiling 开销：需要离线 profiling 来获取 operator 的统计信息（如平均输出 token 数）
4. 确定性约束：prompt cache 只适用于确定性 operator

6.2 未来方向

1. 异构模型支持：不同 Agent 使用不同模型（如小模型做提取，大模型做推理）
2. 动态 workload 适应：在线学习 workload 模式，动态调整缓存策略
3. 与云端 API 集成：通过代理层把 proactive caching 应用到云 API 调用
4. Approximate caching：允许近似的缓存匹配（semantic caching），扩大缓存命中率

七、一个类比：从"逐单处理"到"供应链优化"

把 Agent 工作流比作制造业：

• vLLM 的优化：把每台机器（GPU）的效率提到最高——但不管工序之间的物流
• Helium 的优化：重新设计整个工厂的工序排布和物料流转——减少搬运、共享夹具、提前准备原料

在制造业中，后者的收益通常远大于前者。LLM serving 也一样。

当你有 10 个 Agent 串起来执行一个任务时，跨 Agent 的协调成本（重复计算、cache miss、等待依赖）往往超过单个 LLM 调用的成本。Helium 做的就是识别并消除这些协调成本。

结语：Agent 时代的系统架构 rethink

Helium 的意义不仅仅是 1.56x 的加速。它提出了一种新的思考方式：

Agent 工作流不是一串独立的 API 调用，而是一个需要全局优化的计算图。

当 AI 从"单轮对话"进化到"多 Agent 协作"，serving 层也需要从"请求级优化"进化到"工作流级优化"。这是数据库社区几十年积累的 query optimization 智慧在 AI 时代的复兴。

对于构建 Agent 系统的开发者来说，Helium 的核心启示是：在优化单个 LLM 调用之前，先看看整个工作流有没有结构性冗余。 很多时候，最大的性能提升不是来自更快的推理引擎，而是来自更聪明的执行计划。

参考来源：

• Wadlom, N., Shen, J., & Lu, Y. (2026). "Efficient LLM Serving for Agentic Workflows: A Data Systems Perspective (Extended)." arXiv:2603.16104. SIGMOD 2026.
• 开源代码：https://github.com/mlsys-io/helium_demo
• 对比系统：vLLM, SGLang, LangGraph, AgentScope, Parrot, KVFlow

#论文解读 #费曼风格 #AI #LLM #Agent #Serving #Helium #SIGMOD2026 #缓存优化 #小凯