🤖 machine learning

BlendServe: Optimizing Offline Inference for Auto-regressive Large Models with Resource-aware Batching

BlendServe 是一个通过引入资源感知的前缀树来有效结合资源重叠与前缀共享，从而优化离线自回归大模型推理的系统，其吞吐量较 vLLM 和 SGLang 等行业标准提升了高达 1.44 倍。

原作者： Yilong Zhao, Shuo Yang, Kan Zhu, Lianmin Zheng, Baris Kasikci, Yang Zhou, Jiarong Xing, Ion Stoica

发布于 2026-06-09

📖 1 分钟阅读☕ 轻松阅读

原作者： Yilong Zhao, Shuo Yang, Kan Zhu, Lianmin Zheng, Baris Kasikci, Yang Zhou, Jiarong Xing, Ion Stoica

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

想象一下，你经营着一家规模宏大、高速运转的工厂，专门制造定制机器人（这些就是 AI 模型）。你的工作是处理成千上万个订单（请求）来制造这些机器人。

在过去，如果你想快速制造机器人，你必须在两种类型的订单之间做出选择：

“重体力活”订单： 这些需要大量的肌肉（计算能力），但几乎不需要存储空间。想象一下，这些订单是要求制造一个拥有超强手臂但没有储物隔间的机器人。
“重存储”订单： 这些需要极少的肌肉，但需要海量的存储空间。想象一下，这些订单是要求制造一个手臂很小但内部有一个巨大仓库的机器人。

问题：工厂车间的瓶颈

你的工厂拥有两种主要资源：

肌肉机器（计算能力）： 它们很快，但如果一直在等待，就会感到疲劳。
存储货架（内存）： 它们很大，但如果使用效率不高，就会被堵塞。

旧的方法（朴素批处理）：
以前，工厂只是按订单到达的顺序来处理订单。如果你有一排 10 个“重体力活”订单，你的肌肉机器会加班加点地工作，但你的存储货架却空置着，毫无用处。接着，如果接下来的 10 个是“重存储”订单，你的存储货架会被塞满，但你的肌肉机器却在闲着没事干，无所事事。

这就像试图一辆车只装砖头，然后再只装羽毛。如果你把它们混合在一起，你才能装载更多东西。否则，你的卡车（你的芯片）有一半的时间都是半空的。

新的问题：
工厂还用过另一种技巧，叫做**“前缀共享”（Prefix Sharing）**。想象一下，许多订单都有完全相同的初始步骤（比如“把机器人涂成蓝色”）。如果你把这些订单放在一起执行，你只需要涂一次蓝色并重复使用那个结果。这节省了大量时间。

然而，为了实现这种共享而进行的“最佳”排序方式（即把所有“涂蓝”的订单放在一起做），往往意味着要把所有的“重体力活”订单归为一类，并将所有的“重存储”订单归为另一类。这破坏了“混合”策略，让你的机器再次处于半空闲状态。

解决方案：BlendServe

这篇论文的作者创建了一个名为 BlendServe 的系统。你可以把它想象成一个超级聪明的工厂经理，他可以通过重新排列工作的顺序，来获得两全其美的效果。

1. “资源感知型”树状结构：
BlendServe 没有使用简单的线性结构，而是将所有订单组织成一棵巨大的家族树。

分支（Branches）： 将具有相同起始步骤的订单进行分组（前缀共享）。
标签（Labels）： 每个分支都会标注它需要多少“肌肉”与“存储”。

2. “双向扫描器”算法：
这是其中的魔力所在。经理不只是沿着线走。他同时站在树的两端：

他从左侧抓取一个“重体力活”订单。
他从右侧抓取一个“重存储”订单。
他将它们放在同一个批次中。

结果：
现在，当工厂运行时，你的肌肉机器在努力工作的同时，存储货架也在被填充。它们正在互相配合。卡车被完美地装满了砖头和羽毛的混合物。

为什么这很重要

论文声称，通过这种既能保持“共享步骤”在一起，又能进行巧妙混合的策略，BlendServe 可以：

与目前的顶尖系统（如 vLLM 和 SGLang）相比，将工厂速度提升高达 44%。
达到理论“完美”速度的 90%。想象一下完美的理想速度是 100 英里/小时；BlendServe 能让你达到 90 英里/小时，而其他系统可能只能达到 60 或 70 英里/小时。

难点（以及他们如何解决它）

论文承认，预测一个“重存储”订单究竟需要多长时间是很困难的，因为 AI 是逐字生成文本的。为了解决这个问题，BlendServe 会对订单进行一次微小的样本“试运行”来预估时长，然后利用这些猜测来构建完美的混合方案。即使猜测稍有偏差，该系统也足够健壮，能够进行实时调整。

简而言之，BlendServe 是一个聪明的调度器，它让你的计算机不再闲置。它将不同类型的 AI 任务混合在一起，使得你的计算机大脑和内存能够完美协作，让离线 AI 处理变得更快、更便宜。

技术摘要：BlendServe

问题陈述

离线批处理推理已成为延迟不敏感型大语言模型（LLM）任务（如模型评估和数据清洗）的一种具有成本效益的解决方案。与优先考虑低延迟的在线推理不同，离线推理旨在在放宽的时间窗口内最大化吞吐量（每秒 Token 数）。

现有的吞吐量优化技术，如分块预填充（Sarathi-Serve）和算子级重叠（NanoFlow, Orion），侧重于在单个批次内平衡计算和内存资源。然而，随着应用多样性的增加，这些方法面临收益递减的问题。现代 LLM 工作负载表现出截然不同的资源需求：

计算密集型： 具有长输入序列但短输出的任务（例如文档摘要、MMLU 等基准测试）会使 GPU 计算单元饱和，同时使内存带宽利用不足。
内存密集型： 具有长输出序列的任务（例如视频生成、推理）在自回归解码阶段会使内存带宽饱和，同时使计算单元利用不足。

当一个批次主要由一种请求类型组成时，硬件资源会保持失衡，从而限制了吞吐量。此外，简单地通过重新排序请求来最大化资源重叠，往往会与**前缀共享（prefix sharing）**技术相冲突，该技术通过将具有共同前缀的请求分组来避免冗余计算。一个旨在最大化前缀共享的请求顺序（通常是对前缀树进行深度优先搜索 DFS）可能会导致批次被单一资源类型主导；而一个旨在最大化资源重叠的顺序则可能会破坏前缀局部性。

方法论：BlendServe

BlendServe 是一个旨在通过协调资源感知批处理和前缀共享来最大化离线推理吞吐量的服务系统。其核心设计包含三个主要组件：

1. 性能建模与计算密度

BlendServe 引入了一个名为计算密度（ $\rho$ ）的指标，定义为请求中计算受限算子时间与内存受限算子时间的比例。

请求级： $\rho(r) = \frac{\text{Comp}(r)}{\text{Mem}(r)}$ 。高 $\rho$ 表示计算密集型工作负载；低 $\rho$ 表示内存密集型工作负载。
批次级： 系统将总执行时间 $T$ 建模为计算时间（ $T_{comp}$ ）、内存时间（ $T_{mem}$ ）和前缀共享比例（ $s$ ）的函数。目标是通过最大化计算与内存操作的重叠并最小化冗余计算来最小化 $T$ 。
输出估计： 由于自回归生成中的输出长度是未知的，BlendServe 在预热阶段采用了采样策略。它根据提示词语义和任务类型推断输出长度分布，利用采样请求来估计同一前缀子树内未采样请求的密度。

2. 资源感知前缀树

为了管理前缀共享与资源重叠之间的权衡，BlendServe 构建了一个资源感知前缀树：

结构： 基于 SGLang 等系统使用的 Trie 树结构，其中节点代表共享的提示词段。
增强： 每个节点都标注了其子树中所有请求的计算密度。
排序与拆分： 系统根据计算密度对每一层的节点进行排序，将计算密集型节点放在左侧，将内存密集型节点放在右侧。为了处理破坏全局排序的离群值，系统使用了条件节点拆分技术。如果一个节点的密度与其相邻节点显著偏离，则对其进行拆分并重新定位。这会以重新计算一小段前缀为代价，来换取更好的资源平衡。

3. 双向扫描算法

为了生成最终的请求调度方案，BlendServe 采用了双向扫描算法：

机制： 该算法同时从排序后的前缀树的左端（计算密集型）和右端（内存密集型）扫描叶节点。
批次形成： 它动态计算所需的内存分区（ $M_L$ 和 $M_R$ ），以达到与树根匹配的目标全局计算密度（ $\rho_{target}$ ）。通过从两端选择请求来填充这些分区，确保每个批次都包含计算密集型和内存密集型请求的平衡混合。
结果： 这种方法保留了前缀树的层次结构（维持高前缀共享），同时通过交错请求来实现硬件资源重叠的最大化。

4. 分布式部署

BlendServe 支持数据并行（DP）和张量并行（TP）。

在 DP 中，中心化的前缀树被分解为分配给不同 rank 的子树，以确保负载均衡。
在 TP 中，系统与现有的流水线策略集成，以实现通信开销与计算的重叠，保持与大规模部署的兼容性。

主要贡献

工作负载多样性分析： 详细刻画了多样化的 LLM 应用（聊天、编程、视频生成）如何产生相互冲突的资源需求（计算 vs 内存），从而限制了现有的批处理策略。
资源感知前前缀树： 一种新型数据结构，在保留前缀结构的同时编码了资源需求（计算密度），使得系统能够同时对前缀共享和资源重叠进行推理。
双向扫描算法： 一种启发式调度算法，通过从排序后的前缀树两端进行扫描来构建批次，有效地融合不同类型的请求，以在不牺牲前缀共享的前提下最大化资源重叠。
原型与评估： 基于 NanoFlow 和 SGLang 构建的完整实现，并在多种模型（Llama-3-8B/70B, Qwen-2.5, DeepSeek）及多样化的合成工作负载上进行了评估。

实验结果

作者将 BlendServe 与行业标准基准（vLLM, SGLang）以及最先进的面向吞吐量的系统（NanoFlow）进行了对比评估。

吞吐量提升：
- 与 vLLM 和 SGLang 相比，BlendServe 实现了高达 1.44× 的吞吐量提升。
- 与当前吞吐量领域的领先水平 NanoFlow 相比，BlendServe 的吞吐量平均提高了 20.84%。
最优性差距： BlendServe 平均达到了理论最优吞吐量的 86.55%（在特定配置下高达 90%），证明其有效地接近了完美资源重叠与前缀共享所能达到的极限。
资源利用率： 计算与内存使用的可视化结果显示，BlendServe 在推理步骤中保持了稳定、平衡的资源利用，而像 NanoFlow-DFS 这样的基准模型则表现出显著的波动和资源利用不足的阶段。
前缀共享： 尽管为了资源平衡对请求进行了重排序，BlendServe 仍保持了标准 DFS 遍历所能实现的最高前缀共享比例的 97%。
可扩展性： 系统展示了随数据并行（DP）近乎线性的扩展能力，并在不同模型规模（7B 到 72B）和硬件配置下均保持有效。

意义与主张

论文声称 BlendServe 是首个专门针对离线批处理推理优化的服务系统，它成功地调和了两个传统上相互冲突的目标：资源重叠与前缀共享。

作者认为，随着 LLM 应用的多样化，批次内资源需求均匀分布的假设已不再成立。通过利用离线推理对延迟的宽松约束来重新排列请求，BlendServe 解锁了以往基于批次内优化的方法无法实现的显著吞吐量增益。该系统证明，可以在不牺牲前缀缓存效率的前提下，逼近最优吞吐量（90%），为高吞吐量的成本效益型 LLM 推理提供了稳健的解决方案。