GPU为什么总在等最慢的请求？BlockServe 把扩散 LLM 吞吐拉高 10.6 倍

在大语言模型服务领域，高效推理是决定其能否大规模应用的关键。对于主流的自回归模型，业界已发展出成熟的连续批处理技术，通过词元级调度保持了高GPU利用率。然而，随着扩散大语言模型的兴起，这一范式遭遇了根本性挑战。扩散模型以并行的方式迭代去噪，生成整个文本块，这种执行模式上的差异，使得传统的连续批处理在应对多个并发请求时，效率大打折扣。问题的核心在于“收敛异质性”——批处理中的不同请求会在不同的块边界完成，导致先完成的请求被“拖后腿”的慢请求阻塞，造成GPU计算资源闲置和尾部延迟激增。

为了解决这一难题，来自伊利诺伊大学芝加哥分校的研究团队提出了一种全新的服务框架——BlockServe。它通过块粒度调度、混合状态内存管理和计算感知准入控制，实现了扩散大语言模型的高吞吐量连续批处理，在不改变底层模型架构的前提下，将推理吞吐量提升了最高10倍以上。

论文标题：BlockServe: Block-Grained Continuous Batching for High-Throughput Diffusion LLM Serving

论文链接：https://arxiv.org/pdf/2607.08930

研究背景：扩散模型服务的新瓶颈

大语言模型的部署重点正从模型架构创新转向高效的服务系统。自回归范式下，连续批处理已成为行业标准，它通过词元级别的细粒度调度，有效维持了高GPU利用率。然而，扩散大语言模型的涌现带来了根本性的范式转变。

与自回归模型逐词元顺序生成不同，扩散大语言模型采用并行的去噪过程，迭代生成整个文本块。这种差异导致了一个新的挑战：当多个请求被批量处理时，它们会在不同的块边界完成，即使设定了相同的生成预算，也会因为内容复杂度不同而产生速度差异。这种“收敛异质性”使得批处理中的快速请求不得不等待最慢的“拖后腿”请求，从而在批次内引入了“计算气泡”——GPU资源未被充分利用的空闲时间，并严重恶化了长尾延迟。

现有的扩散模型优化工作，如Fast-dLLM，主要专注于优化单请求推理的延迟，但高效的批量服务仍然是一个悬而未决的问题。这迫切需要一种专门针对块级执行特性设计的批处理调度框架。

核心创新：块粒度调度与混合状态执行

BlockServe 的设计围绕三个核心组件展开：块粒度调度器、混合状态内存管理器和计算感知准入控制器。它们共同构成了一个以块为中心的闭环执行流程。

块粒度调度 是BlockServe的核心创新。它摒弃了请求级别的锁定，转向块级别的抢占。每个调度量对应于一个包含S个去噪步骤的块周期。调度器在每次迭代中，为批次中的所有活跃请求并行执行一个块周期。执行完成后，调度器立即在块边界进行完成度检查：任何达到其块数量上限或已生成序列结束词元的请求，都会被立即从活跃集中驱逐。这种细粒度的抢占机制，通过在每一个块边界回收资源，而非等待整个批次同步，有效缓解了“拖后腿”效应。

混合状态内存管理 解决了如何在GPU内核所需的规整密集张量中，容纳处于不同生成阶段（即“混合状态”）的请求。BlockServe通过“逻辑位置对齐”和“向量化混合调度执行”两种机制来实现。逻辑位置对齐通过左填充和显式计算位置ID，确保每个请求在批处理张量中保持正确的相对位置语义，这对于旋转位置嵌入等机制至关重要。向量化混合调度执行则通过“聚集-散射”索引技术，从共享的批次张量中选择每个请求当前活跃的块区域进行处理，使得双缓存和并行解码等单请求优化技术能够无缝应用于混合状态的批次中。

计算感知准入控制 旨在最大化硬件利用率，同时避免内存溢出错误。BlockServe放弃了固定的批次大小限制，转而采用基于词元预算的策略。系统根据每次迭代必须实例化的密集张量的“边界框”来定义活跃批次的内存成本。当定义当前最大宽度的请求完成并被驱逐后，边界框会收缩，从而在不显式回收内存的情况下为新请求的加入释放预算。为了最小化填充浪费，系统维护一个按提示长度排序的待处理队列，并在填充阶段贪婪地选择那些初始行宽能适配当前边界框的候选请求。

实验验证：吞吐量大幅提升，延迟分布显著改善

研究团队在单张NVIDIA H200 GPU上，使用LLaDA-8B-Instruct和Dream-v0-Instruct-7B两个模型，在五个广泛使用的基准测试集上对BlockServe进行了全面评估，包括GSM8K、HumanEval、MBPP、MATH和TruthfulQA-Gen。

端到端性能表现 令人印象深刻。如表II所示，在LLaDA模型上，BlockServe在所有基准测试中都实现了比Fast-dLLM基线更高的吞吐量。例如，在HumanEval基准上，BlockServe将吞吐量从Fast-dLLM最佳配置的231.5词元/秒提升至597.8词元/秒，加速比达到2.6倍。在Dream模型上，加速比范围更是达到了1.9倍至10.6倍。更重要的是，这些吞吐量的提升并未以牺牲生成质量为代价，BlockServe在所有基准测试上都保持了与基线相当的生成准确率。

延迟与长度关系分析 揭示了BlockServe性能优势的来源。如图2所示，BlockServe在不同输出长度区间都保持了低方差、一致的延迟分布。相比之下，Fast-dLLM则表现出明显的“拖后腿”效应，延迟分布呈现重尾和多峰特征。即使是短生成请求，也会因为批次被最长请求阻塞而承受高延迟。

有效并发分析 进一步量化了方法间的差距。研究者通过“有效计算比率”来衡量每个调度步骤平均活跃的请求数。如图3所示，在TruthfulQA这类短生成任务上，Fast-dLLM在批次大小为16时，有效比率骤降至0.07，意味着绝大部分时间GPU都在等待。而BlockServe能将比率维持在接近1.0，甚至通过词元预算控制实现超过2.0的有效过载，表明其块粒度抢占显著减少了计算气泡。

批次大小扩展性 测试展示了BlockServe的关键优势。如图4所示，当批次大小较小时，Fast-dLLM与BlockServe的延迟差距不大。但随着批次大小增加到16，基线延迟不成比例地增长，因为批次内遇到长“拖后腿”请求的概率增加，导致极端尾部延迟。而BlockServe成功地将请求延迟与批次组成解耦，其延迟分布即使在批次大小为16时也保持紧凑，确保了在高并发下的可预测延迟。

准入控制与批次容量 方面，BlockServe的词元预算准入控制带来了显著提升。如表IV所示，在固定生成长度下，BlockServe相比Fast-dLLM，将最大安全批次容量提升了2.0倍到4.0倍。这意味着在相同的硬件约束下，系统能够并发处理更多的请求。

消融研究与设计权衡

为了理解不同设计选择的影响，研究团队进行了消融实验。

块生成长度 是控制抢占粒度的关键参数。实验评估了L ∈ {16, 32, 64} 的影响。结果表明，L=16时吞吐量普遍低于L=32，说明粒度过细会带来开销。增大到L=64有时会降低准确率，因为更大的块同时去噪更多词元，可能放大并行解码固有的近似效应。最终，BlockServe选择L=32，在调度开销和生成稳定性之间取得了平衡。

提示长度排序 是准入控制器减少填充浪费的策略。实验比较了排序队列与非排序队列的性能。如表VII所示，在批次大小为16时，长度感知排序能稳定地将吞吐量提升4.7%到9.2%。这印证了理论分析：将提示长度相近的请求分组，可以确保新加入的请求具有相似的行宽，从而产生填充浪费更少的紧致边界框。

总结与展望

BlockServe 的研究表明，块粒度调度能够显著缓解批处理扩散大语言模型服务中的“拖后腿”瓶颈。通过将每个执行块视为独立的调度量子，并结合块级驱逐与混合状态内存对齐，BlockServe 使得GPU资源即使在各个请求以不同速度完成时也能得到更充分的利用。计算感知的准入控制进一步在相同硬件约束下实现了2到4倍的批次容量提升。

该工作主要关注离线批量推理场景。研究团队指出，将BlockServe扩展到支持动态请求到达的在线服务，是未来的研究方向。这项工作为扩散大语言模型的高吞吐量服务奠定了新的基础，有望推动这类新型模型在更广泛的实际应用中落地。