BlockServe: 块粒度连续批处理实现高吞吐扩散大语言模型服务

# BlockServe：面向高吞吐量扩散大语言模型服务的块粒度连续批处理
来源：https://arxiv.org/html/2607.08930
###### 摘要

扩散大语言模型（dLLM）的高效服务受到收敛异质性的阻碍：在批处理多个请求时，不同序列以不同速率收敛，导致较快请求等待较慢的掉队者，引入计算气泡和尾延迟。我们提出BlockServe，一个集成块粒度调度（在块边界立即驱逐已完成请求）与混合状态执行（通过聚集-分散索引将双缓存和并行解码扩展到异质批处理）的连续批处理框架。此外，一个计算感知的接纳控制器通过令牌预算的重新填充扩展有效批处理容量。在Dream和LLaDA上，跨五个基准测试，BlockServe实现了相对于Fast-dLLM 1.9–10.6倍的吞吐量提升，且生成质量相当，确立了块粒度调度作为高吞吐量离线dLLM推理的基础。

## I 引言

大语言模型（LLM）的部署已从模型架构转向高效服务系统[10]。在自回归（AR）范式中，连续批处理[20, 11]已成为行业标准，以单个令牌的粒度进行调度以保持高GPU利用率。然而，扩散大语言模型（dLLM）[14, 19]的出现引入了根本性的范式转变。与顺序生成令牌的AR模型不同，dLLM采用并行去噪过程，迭代生成整个令牌块。虽然最近的工作如Fast-dLLM[17]已成功优化了dLLM以实现低延迟单请求推理，但当请求在块边界处以不同速率收敛时，这些模型的高效批处理服务仍然具有挑战性。

我们将此现象称为收敛异质性。在自回归服务中，输出长度变化是调度异质性的主要来源，令牌级别连续批处理通过在每一步生成时进行抢占来处理[2, 1]。然而，dLLM以离散块生成，即使在同一生成预算下，请求也会在不同块边界处达到完成。因此，某些请求可能提前完成而其他请求继续去噪，在单个批处理服务迭代中创建混合完成状态。在当前的dLLM批处理中，整个批次由最慢的请求（即"掉队者"）门控，迫使已完成的请求在占用活动批次资源的同时保持空闲。由此产生的"计算气泡"——GPU资源未被充分利用的空闲时间——导致严重的尾部延迟，迫切需要专门的块级批量调度框架。

为应对这些挑战，我们提出BlockServe，一个专门的推理服务框架，能够在不改变底层模型架构的情况下实现dLLM的高吞吐量连续批处理。BlockServe集成了块粒度调度器与混合状态内存管理器，防止掉队者阻塞批次，同时允许在不同块索引处的请求在统一稠密张量中执行。计算感知的接纳控制器在令牌预算下进一步根据工作负载几何特征调整并发度。这些组件构成了一个以块为中心的执行循环：在块边界处回收已完成的请求，异构的在途请求仍可在共享稠密批次中执行，回收的容量随后转化为额外的接纳。我们的贡献总结如下：

- ●我们引入了一个块粒度调度器，以块为单位操作，通过块级完成检查立即驱逐已完成的请求，减少批处理扩散推理中由掉队者引起的计算气泡。
- ●我们设计了一个混合状态内存管理器，通过显式位置对齐物化统一稠密张量，将双缓存和并行解码扩展到异质批次，无需自定义内核。
- ●我们提出一个计算感知的接纳控制器，以令牌预算取代固定批次大小，动态根据工作负载几何特征调整并发度，实现有效批处理容量增加2–4倍。
- ●在Dream和LLaDA上，跨五个基准测试，BlockServe相对于Fast-dLLM实现1.9–10.6倍吞吐量，且生成质量相当。

## II 方法

### II-A 问题定义

我们考虑处理一批用户请求的扩散大语言模型的并发服务。与自回归生成不同，dLLM通过迭代去噪过程生成序列。对于特定请求 $r_i$，提示长度为 $p_i$，目标生成长度为 $g_i$，生成工作负载被分解为 $K_i = \lceil g_i / L \rceil$ 个固定长度的执行块，每个块沿生成序列长度为 $L$。每个块通过 $S$ 个扩散步骤迭代去噪。请求 $r_i$ 的状态由其当前块索引 $b_i \in \{0, \dots, K_i - 1\}$ 表征。BlockServe的核心目标是通过维护一个混合状态请求的活动集合 $\mathcal{A}$（其中 $r_i, r_j \in \mathcal{A}$ 可能处于不同块索引 $b_i \neq b_j$），同时尊重硬件内存约束，最大化系统吞吐量。

### II-B 系统概述

BlockServe作为一个以块粒度调度和混合状态执行为中心的连续迭代循环运行。在每次迭代中，块粒度调度器（第II-C节）将所有活动请求恰好推进一个块周期，无论其各自的生存周期阶段如何，而混合状态内存管理器（第II-E节）将这些异构请求映射到统一的稠密张量布局中以进行向量化执行。为进一步扩展有效批处理容量，计算感知接纳控制器（第II-D节）在长度感知令牌预算下从待处理队列 $\mathcal{P}$ 中选择候选者填充活动集合 $\mathcal{A}$。

请参考图注
图1: BlockServe连续批处理框架概览。来自长度排序队列（左侧）的请求以块粒度进行批处理；虚线绿色单元格表示下一个待处理块。示例1（顶部）：请求完成时的驱逐和重新填充。示例2（底部）：通过边界框收缩实现动态批次扩展。
图1（第II-B节）展示了这些阶段如何交互。在示例1中，当请求3完成其最后一个块时，调度器在块边界处驱逐它，接纳控制器从排序队列中用请求4重新填充空出的槽位。示例2展示了批次如何扩展：请求1完成并被驱逐后，其宽行宽度不再约束边界框，因此先前所需的填充（紫色）被回收，释放出预算用于额外两个接纳，将批次从三个扩展到四个。

### II-C 块粒度调度

算法1 BlockServe调度循环
1: 输入：待处理队列 $\mathcal{P}$（按 $p_i$ 排序），每个请求 $r_i$ 的 $(K_i, b_i) = (\lceil g_i / L \rceil, 0)$；活动集合 $\mathcal{A} \leftarrow \emptyset$；块长度 $L$；令牌预算 $\beta_{\text{budget}}$
2: while $\mathcal{P} \neq \emptyset$ 或 $\mathcal{A} \neq \emptyset$ do
3: 从 $\mathcal{P}$ 中接纳请求到 $\mathcal{A}$，条件是 $\text{Cost}(\mathcal{A} \cup \{r_{\text{cand}}\}) \leq \beta_{\text{budget}}$（第II-D节）
4: $\mathbf{Y} \leftarrow \text{ExecBlockCycle}(\mathcal{A})$（第II-E节）
5: for each 请求 $r_i \in \mathcal{A}$ do
6: 用 $\mathbf{Y}[i]$ 更新 $r_i$ 输出，并设置 $b_i \leftarrow b_i + 1$
7: end for
8: 从 $\mathcal{A}$ 中移除任何满足 $b_i \geq K_i$ 或 $\text{CheckEOS}(r_i)$ 的请求
9: end while

BlockServe的核心创新在于从请求级锁定转向块级抢占。每个调度量子对应 $S$ 个去噪步骤的一个块周期。算法1概述了该协议。在每次迭代中，接纳控制器在令牌预算约束下从待处理队列 $\mathcal{P}$ 填充活动集合 $\mathcal{A}$（第II-D节）。然后调度器并行执行一个批次的块周期（第II-E节）；此执行与块无关，因为处于不同生成阶段的请求都在同一个块周期内推进。执行后，调度器执行块边界完成检查：任何已达到其块限制 $K_i$ 或已产生序列结束标记的请求立即从 $\mathcal{A}$ 中驱逐。这种细粒度抢占通过在每个块边界回收资源而非等待整个批次同步来减轻掉队者效应。

### II-D 计算感知接纳控制

为了在不引发内存溢出（OOM）错误的情况下最大化硬件利用率，我们放弃固定批次大小，转而采用令牌预算策略。由于标准GPU内核操作在规则稠密张量上，在相同批次内服务不等长请求需要填充，这会导致内存浪费。我们根据每次迭代必须物化的稠密张量的边界框来定义活动批次 $\mathcal{A}$ 的内存成本。由于BlockServe仅分配提示令牌和已完成或正在去噪的块的空间，请求 $r_i$ 在块索引 $b_i$ 处的有效行宽为 $p_i + (b_i + 1) \times L$。批次成本为：

$$\text{Cost}(\mathcal{A}) = |\mathcal{A}| \times \max_{r_i \in \mathcal{A}} \bigl(p_i + (b_i + 1) \times L\bigr) \tag{1}$$

提示长度和块进度决定了边界框。当定义当前最大值的请求完成并被驱逐时，边界框收缩——释放出预算用于新请求的接纳，无需显式内存回收。最小化填充浪费需要缩小每个请求的行宽与批次最大宽度之间的差距。

为近似实现这一点，我们采用一种长度感知的贪婪批处理策略。待处理队列 $\mathcal{P}$ 按提示长度排序维护。在重新填充阶段，调度器搜索候选者 $r_{\text{cand}}$，其初始行宽 $p_{\text{cand}} + L$（从块0开始）适合当前边界框而不扩展它（"沙填充"）。仅当 $\text{Cost}(\mathcal{A} \cup \{r_{\text{cand}}\}) \leq \beta_{\text{budget}}$ 时才接纳候选者，其中 $\beta_{\text{budget}}$ 通过离线分析峰值GPU内存利用率确定。这使得BlockServe能够安全地超越静态批次大小限制，根据工作负载几何特征调整并发度。

### II-E 混合状态内存管理

高效的混合状态执行需要协调请求的参差性与GPU内核所需的物理稠密性。BlockServe通过两种协同机制实现：逻辑位置对齐和向量化混合调度执行。

##### 逻辑位置对齐

我们将边界框（式1）物化为一个 $|\mathcal{A}|$ 行的稠密张量，每行长度为 $\max_{r_i \in \mathcal{A}} (p_i + (b_i + 1) \times L)$。为保持位置语义，我们应用左侧填充，使每个提示的令牌占据连续位置，紧接在其生成区域之前。然后通过注意力掩码上的累积索引计算显式位置ID，确保第一个非填充令牌始终从逻辑位置零开始。这保留了旋转嵌入（RoPE）[16]所需的逻辑相对距离，同时保持位置编码、注意力掩码和前缀缓存对齐，使得每个请求在批处理执行中保持一致。

##### 向量化混合调度执行

虽然现有的dLLM引擎通过双缓存和并行解码[17]优化单请求延迟，但将这些应用于混合状态连续批处理并非易事，因为批次中的请求可能在处理不同序列位置的块。BlockServe通过聚集-分散索引来解决这个问题，该索引在共享批次张量中选择每个请求的活动块区域。

标准的双缓存机制依赖静态物理位置，这在连续批处理的动态重对齐下会失效。我们引入一种聚集-分散更新机制，将逻辑令牌位置与物理内存地址解耦。通过计算活动块区域的稀疏掩码，BlockServe仅在对应于每个请求当前执行块的物理偏移处执行原地KV更新，从而在批次重新配置中保持冻结前缀缓存的完整性。标准的并行解码要求所有请求在同一个块索引处同步。BlockServe通过解耦每个请求的生成轨迹来移除这一限制。在每个块周期开始时，步间转移配额通过将块的掩码令牌均匀分布在 $S$ 个扩散步骤中计算得出；由于每个块开始时完全被掩码，此计算与块无关。相同的基于聚集的索引使得统一的块周期能够推进所有活动请求，无论其个体块进度如何。

聚集-分散索引是使混合状态批处理变得实用的实现基元：聚集将每个请求的活动块区域提取到一个紧凑张量中进行去噪，分散将结果写回对应位置。该机制不是独立的算法贡献，而是使得在异构请求状态上进行块粒度调度成为可能的执行基础。

## III 实验

我们通过回答以下研究问题来评估BlockServe：

1. **RQ1**: BlockServe与最先进的基线相比，在端到端吞吐量、总壁钟时间和生成质量方面表现如何？
2. **RQ2**: 在批处理下，每个样本的延迟与输出长度有何关系？
3. **RQ3**: 系统如何随批次大小增加而扩展？
4. **RQ4**: 令牌预算接纳控制对批处理容量有何影响？
5. **RQ5**: 块长度和提示长度排序如何影响性能？

### III-A 实验设置

我们在单个 NVIDIA H200 GPU 上使用 LLaDA-8B-Instruct 和 Dream-v0-Instruct-7B 模型以 bfloat16 精度实现 BlockServe 和所有基线。默认块长度为 $L=32$ 个令牌，每个块有 $S=32$ 个去噪步骤。

我们与以下两个基线进行比较：