服务掩码扩散大语言模型：基于真实硬件的特性分析与设计原则

# 掩码扩散LLM的服务：来自真实硬件的特性分析与设计原则  
来源：https://arxiv.org/html/2608.23807  
Farhana Amin Sabiha Afroz  
附属机构：美国弗吉尼亚州布莱克斯堡弗吉尼亚理工大学计算机科学系  
[email protected]  
Mona Moghadampanah  
附属机构：美国弗吉尼亚州布莱克斯堡弗吉尼亚理工大学计算机科学系  
[email protected]  
Dimitrios S. Nikolopoulos  
附属机构：美国弗吉尼亚州布莱克斯堡弗吉尼亚理工大学计算机科学系  
[email protected]  

###### 摘要  
掩码扩散语言模型（dLLMs）在原则上可以比自回归（AR）模型更快地生成文本，因为它们能同时去噪多个token。近期系统已开始为dLLMs构建服务基础设施，但均未首先测量这些模型在真实并发服务负载下的行为表现。缺乏此基础而构建的服务系统，可能沿用AR服务中未必适用于dLLMs的假设。本文通过在单块NVIDIA H200 GPU上使用带D2F（离散扩散强迫）LoRA适配器的LLaDA-8B-Instruct模型，基于GSM8K（分层结构、可预测性、批处理、调度）和HumanEval（块大小不变性与方差结构）对dLLM服务进行特性分析，以弥合这一差距。我们报告三项发现：首先，请求难度（请求所需去噪步数）是离散而非连续的——请求可分为11个固定步数等级（178±29k），且我们测试的任何信号均无法在生成开始前预测等级（最佳R²=0.150，远低于我们视为调度可用性的0.50阈值）。其次，短生成预算（<320 token）的基准测试会低估服务方差，因为请求在延迟差异显现前即被截断。第三，仅24%的单请求挂钟时间用于GPU计算，其余均为CPU端调度开销。批处理主要通过分摊此开销发挥作用：每个去噪步共享单次前向传播可使批大小为16时的吞吐量比逐请求调度基线提升16.0倍。我们还从结构上论证输出质量不应随批大小下降，并阐明其依赖的三项假设；我们在单请求规模下测得74–76%的GSM8K准确率。最后，我们基于泊松到达的固定填充同步批处理推导出批量超时规则。这些结果共同表明：扩散语言模型的服务需要在每个去噪步层级实现并行，其与AR服务的区别不在于是否共享前向传播，而在于准入与淘汰机制如何与已共享的前向传播交互。  

###### 索引术语：掩码扩散语言模型、LLM服务、批处理、GPU特性分析、推理系统  

## I 引言  
掩码扩散语言模型（dLLMs）[1 (https://arxiv.org/html/2608.23807#bib.bib3), 2 (https://arxiv.org/html/2608.23807#bib.bib4)]的文本生成方式与标准自回归（AR）模型[3 (https://arxiv.org/html/2608.23807#bib.bib23)]不同。它们并非从左至右逐个token生成，而是从完全掩码的序列开始，通过多个步骤逐步去噪。由于单次前向传播可同时更新整个token块，dLLMs有望比AR解码实现更高吞吐量。近期D2F（离散扩散强迫）[4 (https://arxiv.org/html/2608.23807#bib.bib1)]等工作部分兑现了这一承诺，通过结合分块KV缓存与自适应调度实现了显著加速。但这些收益目前仅在单个请求独立运行时得到验证。  

LLM推理作为共享基础设施的转变已在高性能计算（HPC）设施中推进。美国能源部（DOE）及学术中心正日益将LLM推理作为配额服务而非商业云服务运行。例如，阿贡领导力计算设施（ALCF）的推理服务为整个DOE实验室生态的研究人员提供类似云的接口，使其能直接在HPC系统上访问LLM[5 (https://arxiv.org/html/2608.23807#bib.bib20)]。本文研究的工作负载特性直接关系到这些设施运营者关注的重点。具体到dLLMs，其单请求计算成本无法在准入时预测（§III-A (https://arxiv.org/html/2608.23807#S3.SS1)）：与AR推理不同（其成本大致与可提前已知或估算的提示和输出长度成比例），dLLM请求的去噪步数在生成进行前不可观测。这种不可预测性使得依赖合理运行时估计以填充调度间隙的回填调度[6 (https://arxiv.org/html/2608.23807#bib.bib22)]难以应用于dLLM工作负载，并增加了共享配额管理硬件上服务级别协议（SLA）承诺的复杂性。我们发现的延迟最优工作点ρ≈0.70（§V (https://arxiv.org/html/2608.23807#S5)）为运营者运行dLLM端点提供了具体的利用率目标。  

因此，我们将本工作视为dLLM作为设施工作负载的服务特性分析，而非云服务基准测试。然而，现有大多数加速dLLMs的工作仅关注单请求场景。dKV-Cache[7 (https://arxiv.org/html/2608.23807#bib.bib8)]、Fast-dLLM[8 (https://arxiv.org/html/2608.23807#bib.bib10)]、dLLM-Cache[9 (https://arxiv.org/html/2608.23807#bib.bib11)]、FlashDLM[10 (https://arxiv.org/html/2608.23807#bib.bib9)]、Sparse-dLLM[11 (https://arxiv.org/html/2608.23807#bib.bib12)]和Spiffy[12 (https://arxiv.org/html/2608.23807#bib.bib13)]等方法均通过缓存、稀疏性或推测在去噪步骤间复用计算，并各自报告了单请求延迟的大幅降低。但关键问题仍是：这些模型在真实服务条件下（多个请求共享单块GPU且各需不同去噪步数）表现如何？  

现代AR服务系统如vLLM[13 (https://arxiv.org/html/2608.23807#bib.bib5)]和Orca[14 (https://arxiv.org/html/2608.23807#bib.bib6)]依赖于AR解码的关键特性：每个请求每步前进一个token，主要独立进行，不依赖批处理中的其他请求。这种独立性正是连续批处理在AR系统中简单高效的原因。我们证明掩码扩散服务不具备此特性。直接应用AR式连续批处理可能使吞吐量下降而非提升。原因如下：若将连续批处理器直接应用于掩码扩散解码，每个活跃请求仍需在每个去噪步进行独立前向传播——因为dLLM请求不共享AR next-token解码的简单统一更新机制。此外，请求所需去噪步数各异（§III-A (https://arxiv.org/html/2608.23807#S3.SS1)）。这意味着每个活跃请求每步会产生更多GPU调度调用，而非掩码扩散服务实际允许的共享单次前向传播（§IV (https://arxiv.org/html/2608.23807#S4)）。  

本文使用两个术语，并在此明确定义以确保§IV (https://arxiv.org/html/2608.23807#S4)前的清晰度：  
*连续批处理*是vLLM[13 (https://arxiv.org/html/2608.23807#bib.bib5)]和Orca[14 (https://arxiv.org/html/2608.23807#bib.bib6)]采用的标准AR服务方法：活跃请求共享每次迭代的单次前向传播，完成的请求被换出并替换新到达请求。  
*同步批处理*则不同：批处理中所有请求同步前进，每个去噪步通过一次共享前向传播完成。这并非我们提出的服务策略，而是分块并行掩码扩散解码计算每步的自然结果（§II (https://arxiv.org/html/2608.23807#S2)），也是现有dLLM推理代码（包括我们构建的D2F实现）在批处理同时调度时的执行模式。我们采用此术语以精确命名并对比连续批处理，并非声称优先权。  

少数近期系统已开始直接解决dLLM服务问题。dInfer[15 (https://arxiv.org/html/2608.23807#bib.bib15)]提供了面向批吞吐量的模块化推理框架。DiLaServe[16 (https://arxiv.org/html/2608.23807#bib.bib18)]、Sangam[17 (https://arxiv.org/html/2608.23807#bib.bib17)]和dLLM-Serve[18 (https://arxiv.org/html/2608.23807#bib.bib14)]分别关注调度、预填充/解码分区和内存管理。我们的目标不同且互补：我们不构建服务系统，而是提供基于测量的实证特性分析，揭示*dLLM服务为何如此运作*。具体而言，此特性分析确立了四项此前未报告的结论：dLLM难度是离散而非连续的，且无法在准入时预测（§III (https://arxiv.org/html/2608.23807#S3)）；单请求调度开销与批大小紧密相关，在较小批大小时占20-27%，且在B=8时几乎完全匹配（§IV (https://arxiv.org/html/2608.23807#S4)）；76%的单请求延迟源于主机端调度而非设备计算（§IV-C (https://arxiv.org/html/2608.23807#S4.SS3)）；短生成长度基准测试系统性地低估了真实服务方差（§III (https://arxiv.org/html/2608.23807#S3)）。  

这些是机制性解释，我们用其推导出具体可测试的原则：批量超时稳定性规则（§V (https://arxiv.org/html/2608.23807#S5)）和反对对此类工作负载采用朴素连续批处理的步级并行论证（§IV (https://arxiv.org/html/2608.23807#S4)）。现有及未来的dLLM服务系统（包括上述引用系统）可将这些原则作为基于测量的设计输入，而非沿用AR服务的假设。  

我们的测量来自单块GPU。两类发现推广到共享多租户HPC设施的方式不同：  
第一，我们表征的工作负载级特性——离散、准入时不可预测的难度等级（去噪步数聚类为11个离散值，生成开始前无法推断，§III (https://arxiv.org/html/2608.23807#S3)）、高服务时间方差和步级调度成本结构（§IV (https://arxiv.org/html/2608.23807#S4)）——是模型计算本身的属性，而非单GPU测量设置的属性。集群调度器为dLLM作业分配GPU时，无论GPU是专用还是共享，都会面临相同不可预测、高方差、离散分层的服务时间。这些特性是多租户调度器需考虑的输入，而单GPU测量是将其从集群级混杂效应中隔离的正确方法。  
第二，特定于共享的效应——共置作业间的内存带宽或流多处理器（SM）资源争用、调度器抢占以及服务更大模型的多GPU并行策略——未在本次测量中涵盖，且不直接源于我们的结果。我们建议将此特性分析作为未来工作。  

我们推导的批量超时稳定性规则（§V (https://arxiv.org/html/2608.23807#S5)）应在此背景下理解：它是单GPU、单租户服务模型，而非完整的多租户调度策略。对于运行Slurm[19 (https://arxiv.org/html/2608.23807#bib.bib21)]等集群调度器的设施，其作用是构建模块——多租户调度器可在准入和分配决策时采纳的单作业服务时间特性，而非现有集群调度逻辑的替代品。若调度器假设AR式、可预测的每token服务成本，则无论租约模型如何，都会错误分配dLLM作业的GPU时间——这是我们的单GPU结果支持的更普遍观点。在真实多租户争用下验证稳定性规则本身是自然的下一步。  

具体而言，我们进行三项基于测量的观察，并用其激励与AR实践分道扬镳的服务设计。每项发现将测量结果与其产生机制及激发的设计含义配对：  
1. **dLLM请求难度是离散而非连续的**（§III-A (https://arxiv.org/html/2608.23807#S3.SS1)）  
   机制：块添加规则——新块仅在固定完成检查点开始。  
   含义：准入时信号无法预测难度；调度必须视成本为单请求不可预测。  
2. **短预算低估方差**（§III-D (https://arxiv.org/html/2608.23807#S3.SS4)）  
   机制：自然完成长度前的截断隐藏了真实延迟分布。  
   含义：基准测试必须运行至自然完成长度（此处约320 token）以报告代表性方差。  
3. **CPU调度而非GPU计算主导延迟**（§IV-C (https://arxiv.org/html/2608.23807#S4.SS3)）  
   机制：每块控制循环（掩码、阈值、同步）每步运行一次，独立于批大小。  
   含义：并行性应在步级实现，每步共享单次前向传播可分摊固定调度成本。  

基于发现（3），我们证明独立单请求批处理需每请求每步支付一次调度开销，而步级共享仅需每步为整个批处理支付一次（§IV (https://arxiv.org/html/2608.23807#S4)）。我们还基于测量的服务时间统计推导出闭式批量超时规则（§V (https://arxiv.org/html/2608.23807#S5)）。  

## II 背景  
### II-A 服务特性分析的要求  
服务特性分析需回答三个问题：请求成本的变异幅度、驱动变异的因素，以及变异是否具有调度器可用的结构。本文中，请求成本指端到端挂钟延迟（从分词至解词，§II-B (https://arxiv.org/html/2608.23807#S2.SS2)）。此延迟包含两部分：CPU端调度和GPU计算，§IV-C (https://arxiv.org/html/2608.23807#S4.SS3)显示对掩码扩散服务而言这两者不可互换。除直接查看单步调度开销（§IV-C (https://arxiv.org/html/2608.23807#S4.SS3)）外，我们报告完整请求层级的成本。  

对于自回归（AR）服务，这三个问题易于回答。解码逐token进行，且每token工作量在请求间大致相同。对于掩码扩散服务，默认情况下这些均不成立。去噪路径可能因请求而异，请求所需工作量取决于其token何时及如何变得足够自信以解除掩码。为妥善研究此问题，我们需要一个能实际观察解码内部机制并将其与测量延迟关联的系统。我们使用D2F[4 (https://arxiv.org/html/2608.23807#bib.bib1)]实现此目的。  

D2F将生成分解为固定大小块（本设置为32 token），并通过两个阈值推进块：控制新块何时开始的完成阈值τadd=0.5，以及控制单个token何时解除掩码的解码阈值τdecode=0.9。图1 (https://arxiv.org/html/2608.23807#S2.F1)展示了此机制。我们选择D2F是因为它使变异性来源可见而非隐藏：新块仅能在固定检查点被跨越后开始，因此请求所需去噪步数无法平滑变化——必须落在离散值上。