gLLM: Global Balanced Pipeline Parallelism System for Distributed LLM Serving with Token Throttling

文章标题: gLLM: 具有令牌节流的分布式LLM服务的全局平衡流水线并行系统
作者/机构: Tianyu Guo, Xianwei Zhang, Jiangsu Du, Zhiguang Chen, Nong Xiao, Yutong Lu (中山大学)

A1 主要贡献

核心问题：
在分布式节点上部署大型语言模型（LLM）时，流水线并行因其通信开销较低而成为主流方法。然而，该方法常受流水线气泡（pipeline bubbles）的困扰，即GPU的空闲时段，这主要是由各批次之间不均衡的计算延迟引起的。现有的解决方案，如Sarathi-Serve，试图通过固定令牌预算（token budget）混合调度分块的prefill和decode令牌来解决此问题，但这会导致prefill令牌不足或decode令牌分布不均，从而产生显著的性能波动。此外，将prefill和decode阶段分离的架构虽然缓解了干扰，但仍存在批次间的计算不平衡问题，并且难以确定最优的GPU分配比例。

研究目标和创新点：
为了解决上述计算不平衡问题并最小化流水线气泡，本文提出了gLLM，一个采用“令牌节流”（Token Throttling）机制的全局平衡流水线并行系统。该系统的核心创新点如下：

  • 令牌节流机制（Token Throttling）：gLLM设计了一种细粒度的调度策略，该策略根据推理系统的全局实时信息，独立地调节prefill和decode阶段的令牌数量，以实现计算平衡。

    • 对于decode令牌：gLLM在各个处理批次（micro-batch）中维持近乎一致的令牌数量，确保负载均匀。
    • 对于prefill令牌：gLLM根据待处理的prefill令牌总数和键值缓存（KV cache）的内存利用率，动态调整批处理大小。

  • 优化的异步运行时：gLLM的运行时采用专为流水线并行特性优化的异步执行和消息传递架构，旨在减少数据依赖和CPU开销。

  • 系统性能提升：通过动态节流令牌数量，gLLM实现了更好的微批次间负载均衡，显著缓解了流水线气泡问题。实验证明，与现有的先进流水线或张量并行系统相比，gLLM的最大吞吐量提升了11%至398%，同时保持了更低的延迟。

本文的主要贡献可以总结为：
1. 指出了核心瓶颈：强调了由prefill和decode阶段计算不平衡引起的流水线气泡是显著降低推理系统性能的关键因素。
2. 提出了gLLM系统：设计了一个采用令牌节流机制的分布式服务系统，通过平衡各批次间的计算来有效减少流水线气泡。
3. 实现了动态平衡调度：令牌节流机制根据推理系统的实时反馈，分别动态调整prefill和decode阶段的批处理大小，以实现平衡调度。

下图展示了Sarathi-Serve与理想平衡系统在每次迭代中调度的prefill和decode令牌数量对比。可以看出，Sarathi-Serve的调度策略导致令牌数量的波动性远大于平衡系统。

图1：Sarathi-Serve与理想平衡系统每次迭代（横轴）中prefill和decode阶段调度令牌数的比较，两个系统的最大批处理令牌数（令牌预算）均设置为2048。
图1：Sarathi-Serve与理想平衡系统每次迭代（横轴）中prefill和decode阶段调度令牌数的比较，两个系统的最大批处理令牌数（令牌预算）均设置为2048。

A3 背景知识与动机

2.1 Transformer架构

现代LLM的主流架构。当代LLM主要采用仅解码器（decoder-only）的Transformer架构【索引39，Attention is all you need，2017，NeurIPS】。其处理流程始于一个嵌入层，该层将令牌ID转换为隐藏状态，并结合位置编码来保留序列顺序。这些隐藏状态随后会通过多个解码器层，每个解码器层包含一个自注意力机制（带有因果掩码以确保自回归特性）、层归一化和一个多层感知机（MLP）。其中，自注意力是Transformer的核心，它使LLM能够捕捉长距离的上下文依赖关系。在经过解码器层的处理后，一个线性投影层将最终的隐藏状态转换为logits，代表词汇表上的概率分布。最后，通过一种采样策略（如贪心采样、top-k采样或核心采样）来选择下一个生成的令牌。

2.2 LLM推理过程

自回归解码。LLM的推理过程是自回归的，每个令牌的生成都基于其所有前驱令牌，通过计算它们之间键（key）和值（value）的注意力分数来完成。为了避免重复计算键和值，它们被保留下来用于后续步骤【索引40，Orca: A distributed serving system for transformer-based generative models，2022，OSDI】、【索引41，Efficient memory management for large language model serving with pagedattention，2023，SOSP】。基于此，LLM推理可分为两个不同阶段：1. Prefill（预填充）：并行处理提示（prompt）中的所有令牌，以填充KV缓存并生成第一个输出令牌。由于高度并行性，此阶段能充分利用GPU的计算资源。2. Decode（解码）：通过关注最后一个令牌和已存储的KV缓存，顺序生成每个新令牌。此阶段通常无法充分利用GPU，因为它每步只处理一个令牌，并且因访问KV缓存而频繁遭遇内存带宽瓶颈。Prefill和decode阶段之间不平衡的计算特性可能导致LLM推理效率低下【索引36，Taming throughput-latency tradeoff in LLM inference with sarathi-serve，2024，OSDI】、【索引37，Splitwise: Efficient generative LLM inference using phase splitting，2024，ISCA】、【索引38，Distserve: Disaggregating prefill and decoding for goodput-optimized large language model serving，2024，OSDI】。

调度策略。传统的推理引擎如FasterTransformer【索引42，Faster Transformer，https://github.com/NVIDIA/FasterTransformer】采用批处理级调度，即选择一组请求并执行直至所有序列完成。这种方法未考虑Transformer架构的可变长度特性，会延迟提前完成和后来加入的请求。Orca【索引40 ，Orca: A distributed serving system for transformer-based generative models，2022，OSDI】通过提出迭代级调度解决了这个问题，允许请求在每次模型前向传播之前动态地加入或退出批处理。尽管Orca可以批处理来自prefill和decode阶段的请求，但由于prefill计算延迟较高，它会为正在进行的decode请求引入生成停顿。为解决此问题，SarathiServe【索引36，Taming throughput-latency tradeoff in LLM inference with sarathi-serve，2024，OSDI】允许在几次迭代中以小块（chunk）方式计算大型prefill，并通过混合调度分块的prefill和decode令牌来实现无停顿的批处理。具体来说，SarathiServe首先调度所有decode令牌，然后在固定的令牌预算内最大化分块的prefill令牌。然而，在实际情况中，decode令牌通常缺乏与足够多的prefill令牌混合的机会。

2.3 LLM推理的并行策略

基本的并行策略。LLM推理中的基本并行策略主要包括数据并行和模型并行（如图2所示）。数据并行将输入数据分成多个部分，每个部分发送到相应的GPU进行并行处理。模型并行则对模型本身进行分区，每个GPU负责模型的一部分。模型并行可以根据模型的分区方式进一步分为张量并行和流水线并行。张量并行采用层内并行，将单个操作分割到多个GPU上，并需要频繁通信以同步结果。流水线并行采用层间并行，将不同的层分配给不同的GPU，仅需在阶段之间传递中间激活值。此外，流水线并行使用多个微批次（micro-batch）来使不同流水线阶段的GPU饱和。流水线深度指的是流水线中顺序阶段的数量，每个阶段执行任务的特定部分。由于这些差异，张量并行可以降低前向延迟，但代价是比流水线并行更高的通信开销。在在线服务场景中，张量并行更适合低请求率的情况，而流水线并行则能更好地处理高吞吐量的需求。

图2：数据并行、张量并行和流水线并行的比较。
图2：数据并行、张量并行和流水线并行的比较。

2.4 流水线并行中的挑战

流水线气泡。流水线并行减少了对高带宽通信的需求，但可能引发负载不均衡问题和GPU利用率低。这些问题表现为流水线气泡，即GPU的空闲时间，其产生原因有两类依赖关系：(1) 阶段间依赖，即一个阶段必须等待前一个阶段完成才能开始计算；(2) 批次间依赖，即可同时处理的微批次数量受限于流水线深度。负载不平衡源于：(1) 阶段间不平衡，由流水线各阶段计算量分布不均造成；(2) 批次间不平衡，由不同微批次的计算需求变化引起。图3展示了这些不平衡如何产生流水线气泡。本文专注于解决批次间的流水线气泡，而阶段间的气泡留待未来工作解决。

图3：由两种不平衡（即阶段间和批次间）引起的流水线气泡。（数字表示微批次的序号）
图3：由两种不平衡（即阶段间和批次间）引起的流水线气泡。（数字表示微批次的序号）

GPU利用率不足。流水线并行长期以来一直受到GPU利用率低的困扰。尽管Sarathi-Serve试图缓解此问题，但在当前系统中，利用率不足的现象依然存在。如图4所示，在使用4个GPU服务一个32B模型时，其利用率呈现出两阶段模式：一个初始阶段波动较大，随后是一个稳定但次优的阶段。通过将这些观察结果与请求时间相关联，我们发现初始阶段与新请求的到来相吻合，迫使系统同时处理prefill和decode令牌。一旦没有新请求到来，系统便转向仅进行解码，导致利用率更稳定但仍然效率不高。值得注意的是，批处理的令牌数（图4b）在整个执行过程中都在波动，尤其是在请求到达或达到KV缓存限制时。这些不规则的批处理大小引入了严重的流水线气泡，直接导致了两个阶段的GPU利用率低下。

图4：由不平衡调度导致的GPU利用率不足。
图4：由不平衡调度导致的GPU利用率不足。

2.5 调度需求

平衡调度。流水线并行依赖于微批次间的计算平衡，但当前的调度策略未能满足此要求：(1) Prefill不平衡。当前调度策略中批处理prefill令牌数的波动主要源于两个关键因素。首先，prefill令牌依赖于等待中的请求。当没有可供prefill的请求时，批处理的令牌数就会波动。其次，prefill操作受到KV缓存利用率的限制。如果存储计算出的KV缓存空间不足，系统会停止调度prefill令牌。然而，当前的调度方法未能考虑这些因素，导致prefill调度不平衡。(2) Decode不平衡。为在解码阶段实现平衡处理，我们的目标是将总的解码请求尽可能均匀地分配到所有可用的微批次中。而当前的调度策略缺乏明确的平衡考虑，可能导致微批次间的工作负载分布不均。

解耦调度。如图5所示，当前方法首先调度所有decode令牌➊，然后在固定的令牌预算内最大化分块的prefill令牌➋。然而，我们应该分别调度平衡数量的prefill和decode令牌➀，而不是将其总数限制在一个固定值。这是因为调度的令牌数可能达不到最大预算，并且常常导致不平衡的调度。此外，最优的批处理令牌数往往是动态变化的。更重要的是，prefill和decode调度之间的紧密耦合常常导致这两个阶段之间的干扰。例如，当大量decode请求正在进行时，可用于prefill的令牌容量变得有限。然而，要最大化推理吞吐量，又需要处理大批量的prefill令牌。这种根本性冲突表明，在固定的总令牌预算下将prefill和decode调度紧密耦合，无法有效满足它们各自的需求。因此，迫切需要开发解耦的调度机制。

图5：耦合调度与解耦调度的比较。
图5：耦合调度与解耦调度的比较。

动态调度。每个批次的prefill令牌数应根据推理系统的状态动态调整。例如，在KV缓存利用率较低时（即很少有请求处于解码阶段），我们应提高prefill速度以最大化GPU利用率。相反，在KV缓存利用率较高时，我们应降低prefill速率，以防止因KV缓存不足而抢占序列。另一个考虑是，如果待prefill的令牌很少，我们应平稳地进行prefill，以避免批处理令牌数的突然波动。相反，如果待prefill的令牌充足，我们则希望保持较高的prefill速率。然而，当前的prefill批处理受限于固定的令牌预算和活跃的decode请求数量，而不是根据实际需求进行调整。这种不灵活性导致了次优的调度策略，凸显了对更具适应性调度方法的需求。

A2 方法细节

本节介绍gLLM，一个带有令牌节流（Token Throttling）的全局平衡流水线并行系统。如图6所示，gLLM根据实时推理系统状态，通过节流批处理令牌数来分别动态调度prefill和decode令牌。调度后，gLLM将调度的prefill和decode令牌合并成一个批次。此外，gLLM运行时采用异步架构，以隐藏CPU操作的开销。

图6：gLLM系统概览。gLLM中的推理过程包括令牌流经其各个组件。
图6：gLLM系统概览。gLLM中的推理过程包括令牌流经其各个组件。

3.1 Prefill令牌节流

基于系统状态的prefill调度。prefill操作是LLM推理的第一步，在此过程中计算提示（prompt）的KV缓存并生成第一个输出令牌。因此，prefill调度主要取决于两个因素：等待prefill的令牌数量和系统的KV缓存利用率。首先，如果没有待处理的prefill请求，则无法调度该操作。其次，如果KV缓存接近满载，由于内存不足，prefill也无法进行。除了这些约束外，这些因素的规模也影响调度决策。当等待的请求很少或KV缓存使用率很高时，系统应降低prefill速率以避免流水线气泡或请求抢占。相反，当有大量请求排队或KV缓存可用性很高时，系统应提高prefill速率以最大化吞吐量。为了平衡这些因素，我们根据待处理令牌的数量和当前的KV缓存压力来节流prefill令牌数。

3.1.1 按待prefill令牌数（WT）节流

基于待处理令牌的平滑调度。在每次调度期间，gLLM会收集等待prefill的令牌数量（#WP）来确定批处理的prefill令牌数（#P）。这个决策依赖于三个超参数：prefill的最小/最大批处理令牌数（#MinP/#MaxP）以及处理所有等待prefill的令牌所需的迭代次数（#T）。批处理的prefill令牌数计算如下：

$$ \#P = min(max(\frac{\#WP}{\#T}, \#MinP), \#MaxP) $$
3.1.2 按KV缓存利用率（UT）节流

基于可用KV缓存的比例调度。在每次调度开始时，gLLM还会收集KV缓存的空闲率（$KV_{free}$ ∈ [0, 1]）来确定批处理的令牌数（#P）。这个决策取决于两个超参数，即prefill中批处理的最小/最大令牌数（#MinP/#MaxP）。批处理的令牌数计算如下：

$$ \#P = max(\#MaxP \times KV_{free}, \#MinP) $$
3.1.3 阈值

防止KV缓存溢出的保护机制。除了动态调整prefill令牌数，我们还引入了一个KV缓存空闲阈值（$KV_{thresh}$ ∈ [0, 1]）来调节调度决策。当当前KV缓存空闲率低于$KV_{thresh}$时，系统会自动暂停处理prefill令牌，以防止KV缓存溢出。这种保护机制解决了在无限制prefill操作中观察到的关键问题：对正在进行的decode请求的过早抢占会导致昂贵的重计算时间。通过阈值机制保持缓冲空间，我们确保为活跃的decode请求分配足够的资源，同时维持系统稳定。

综合调度公式。结合上述因素（WT、UT和阈值），我们计算批处理的令牌数如下：

$$ \#P = max(min(\frac{\#WP}{\#T}, \#MaxP \times \frac{KV_{free} - KV_{thresh}}{1 - KV_{thresh}}), \#MinP) \quad (3) $$
3.1.4 案例研究

调度策略对比。图7比较了Sarathi-Serve和gLLM的prefill调度策略。在第一个场景中，初始状态下没有等待prefill的令牌，#T设置为3。当请求到达时，Sarathi-Serve会急切地处理prefill令牌。这导致下一批次中没有prefill令牌可批处理，从而造成计算上的巨大波动。严重的流水线气泡也使得Sarathi-Serve无法及时处理下一批请求。相反，gLLM将新请求均匀地分配到后续批次中，实现了更好的负载均衡。

KV缓存利用率对调度的影响。在第二种情况下，开始时有足够的令牌等待prefill。Sarathi-Serve在调度prefill令牌时未考虑KV缓存利用率。这导致在为prefill令牌分配空间后，剩余的KV缓存空间不足以支持后续的prefill计算。因此，下一批次只能处理decode令牌，直到一些请求完成。相比之下，gLLM根据KV缓存占用率动态调整prefill调度，确保了更均衡的计算。此外，gLLM能实现更高效的KV缓存周转，从而能够及时处理decode请求，防止其KV缓存长时间占用空间。

图7：prefill令牌节流的案例研究（流水线深度为2）。数字表示微批次的序号。对于第二种情况，在每个微批次执行前（第一阶段开始时），为prefill令牌分配KV缓存。处理完一个微批次后（最后阶段结束时），KV缓存使用量可能会增加、减少或大致保持不变，这取决于有多少请求满足终止条件。由于所有GPU共享统一的页表，它们的KV缓存使用情况是一致的。
图7：prefill令牌节流的案例研究（流水线深度为2）。数字表示微批次的序号。对于第二种情况，在每个微批次执行前（第一阶段开始时），为prefill令牌分配KV缓存。处理完一个微批次后（最后阶段结束时），KV缓存使用量可能会增加、减少或大致保持不变，这取决于有多少请求满足终止条件。由于所有GPU共享统一的页表，它们的KV缓存使用情况是一致的。

3.2 Decode令牌节流

3.2.1 按解码中的令牌数节流

均匀分配解码令牌。Decode令牌节流的调度相对直接，因为decode操作需要多次迭代（等于输出序列长度），而prefill操作通常在单次迭代中完成。decode请求的变化相对较小，因为这些请求要么来自已完成的prefill阶段，要么已达到其终止条件。因此，我们的目标是将总的decode令牌均匀地分配到所有可用的微批次中。鉴于最大活跃微批次数等于流水线深度（#$PP_{depth}$），我们可以计算批处理的decode令牌数（#D）如下：

$$ \#D = \frac{\#RD}{\#PP_{depth}} $$

其中#RD是解码中运行的总令牌数。如果剩余的decode令牌少于#D，我们就调度所有剩余的令牌；否则，我们精确调度#D个令牌。

3.2.2 案例研究

解码调度策略对比。图8比较了Sarathi-Serve和gLLM的decode调度策略。Sarathi-Serve未能将工作负载均匀地分配到各个微批次中，导致了严重的流水线气泡。对于阶段间依赖，第二/第六个微批次必须等待前一阶段的完成。对于批次间依赖，第五/第六个微批次必须等待第一/第二个微批次的完成。这些依赖关系引发了显著的流水线气泡。相比之下，gLLM通过根据解码中的总令牌数动态调整令牌数量来优化调度，确保了均衡的工作负载分布，并减少了流水线效率低下的问题。

图8：decode令牌节流的案例研究（流水线深度为4）。数字表示微批次的序号。
图8：decode令牌节流的案例研究（流水线深度为4）。数字表示微批次的序号。

3.3 gLLM运行时

流水线并行的控制流。与张量并行相比，流水线并行涉及更复杂的控制流来协调不同流水线阶段的微批次。为了支持令牌节流，我们设计了一个异步运行时，其架构如图9所示。

多进程架构。为了支持多阶段的并发执行，gLLM运行时采用多进程架构，其中每个流水线阶段都分配有一个专用的工作进程（worker process），还有一个独立的前端进程（frontend process）用于用户交互。工作进程分为两种角色：一个驱动工作进程（driver worker）和多个普通工作进程（ordinary workers）。驱动工作进程负责监督其他普通工作进程，处理诸如从前端接收新请求、调度微批次、为每次调度广播元数据以及将输出流式传回前端等任务。同时，所有工作进程都专注于模型执行，从前一阶段接收激活值，执行前向计算，并将激活值发送到下一阶段。驱动工作进程负责KV缓存管理，所有工作进程共享页表，类似于vLLM。

图9：gLLM运行时架构。
图9：gLLM运行时架构。

异步设计原则。gLLM运行时的异步性是通过三个协调的设计原则实现的：
1. 非阻塞流水线操作。所有工作进程对核心操作（包括请求接收、元数据交换和激活值传输）均采用非阻塞机制，形成一个连续的处理流水线，消除了计算阶段之间的空闲等待。
2. 解耦的前后端处理。我们设计了一个专用的前端进程来处理面向用户的操作（请求接收和响应流式传输），从而实现了与后端模型在工作进程上执行的完全并行。这种分离允许在保持模型计算不间断的同时，进行连续的用户交互。
3. 抢占式元数据调度。运行时采用双阶段数据传输策略：(a) 驱动工作进程向所有工作进程广播元数据包；(b) 工作进程接收相应的中间数据流。这种解耦使工作进程能够利用提前到达的元数据执行关键路径的准备工作（如输入或注意力元数据张量的创建），从而有效地将数据准备延迟与活动计算周期重叠。这种主动调度机制确保了计算资源在整个执行时间线内保持充分利用。

3.4 实现

vLLM的局限性与gLLM的实现。在实现过程中，我们发现vLLM的流水线并行架构存在一个关键的设计局限：它将中间激活值的传输与输入调度元数据紧密耦合。这种集成在为模型前向传播准备输入时引入了显著的CPU开销，约占总执行时间的17%，从而大大削弱了流水线并行的潜在优势。

gLLM的技术栈。为了克服这一限制，我们在CUDA生态系统之上用4000行Python代码实现了gLLM的核心部分。该系统具有RESTful API前端，并提供与OpenAI兼容的核心API。它集成了vLLM为关键操作（包括激活函数、层归一化、位置编码和KV缓存管理）手动优化的CUDA内核，同时还采用了flash attention【索引43，Flashattention: Fast and memoryefficient exact attention with io-awareness，2022，NeurIPS】、【索引44，Flashattention-2: Faster attention with better parallelism and work partitioning，2024，ICLR】、【索引45，Flashattention-3: Fast and accurate attention with asynchrony and low-precision，2024，NeurIPS】。我们还整合了多项近期的先进LLM优化技术，包括迭代级调度【索引40，Orca: A distributed serving system for transformer-based generative models，2022，OSDI】、PagedAttention【索引41，Efficient memory management for large language model serving with pagedattention，2023，SOSP】、分块prefill【索引36，Taming throughput-latency tradeoff in LLM inference with sarathi-serve，2024，OSDI】和前缀缓存【索引46，Sglang: Efficient execution of structured language model programs，2024，NeurIPS】。该系统支持主流的开源LLM，如Llama【索引17，The llama 3 herd of models，2024，CoRR】、Qwen【索引47，Qwen2.5 technical report，2024，CoRR】和ChatGLM【索引48，Chatglm: A family of large language models from GLM-130B to GLM-4 all tools，2024，CoRR】，并支持不同规模。为了验证其输出质量，我们在MMLU-pro基准【索引49，Mmlupro: A more robust and challenging multi-task language understanding benchmark，2024，NeurIPS】上评估了gLLM，详细结果见第4.7节。

A4 实验环境

  • 模型：

    • Qwen2.5系列（14B和32B参数变体）【索引47，Qwen2.5 technical report，2024，CoRR】
    • Llama-3.1-100B【索引17，The llama 3 herd of models，2024，CoRR】
    • 所有模型均使用bfloat16数据类型。

  • 硬件配置：

    • 配置1（节点内）：4块NVIDIA L20-48GB GPU。
    • 配置2（跨节点模拟）：4块NVIDIA A100-40GB GPU。
    • 配置3（跨节点模拟）：4块NVIDIA A800-80GB GPU。
    • 所有配置中的GPU均通过PCIe连接。
    • 跨节点模拟：通过设置环境变量NV_P2P_DISABLED=1和NV_GPU2GPU_DISABLED=1来禁用P2P通信（基于PCIe）和共享内存访问，强制所有GPU间通信通过网络栈。模拟的网络通信带宽为73.28 Gbps，而PCIe通信带宽为20.79 GB/s。

  • 软件配置与对比系统：

    • 对比系统：

      • vLLM (v0.8.1)【索引41，Efficient memory management for large language model serving with pagedattention，2023，SOSP】：作为最快的流水线并行推理引擎基准。
      • SGLang (v0.4.3.post2)【索引46，Sglang: Efficient execution of structured language model programs，2024，NeurIPS】：作为最高效的张量并行推理引擎基准。
      • gLLM：本文提出的系统。
      • gLLM变体（消融实验用）：gLLM w/o WT（无WT）、gLLM w/o UT（无UT）、gLLM w/CK（使用Sarathi-Serve的调度策略）。

    • 实验设置：为保证公平，所有系统均禁用了请求间的KV缓存重用和CUDA Graph。vLLM和SGLang均遵循Sarathi-Serve的调度策略（令牌预算设为2048）。各系统的GPU内存利用率均设置为不发生OOM错误的最大值。

    • gLLM超参数：#T = 8, #MaxP = 2048, #MinP = 32, $KV_{thresh}$ = 0.05。

  • 工作负载（数据集）：

    • ShareGPT【索引50，ShareGPT，https://sharegpt.com/】：用户分享的与ChatGPT的对话集合 。
    • Azure【索引37，Splitwise: Efficient generative LLM inference using phase splitting，2024，ISCA】：来自Azure LLM推理服务的生产环境轨迹，包含到达时间、输入大小和输出大小。
    • 数据特征：Azure数据集的平均输入长度（1161）是ShareGPT（223）的5.21倍，平均输出长度（258）是ShareGPT（155）的1.66倍（见图11）。
    • 请求生成：使用泊松分布模拟云服务场景中的请求到达时间。
图11：采样数据集的输入和输出长度分布。
图11：采样数据集的输入和输出长度分布。

A4 实验结果

4.2 延迟与吞吐量评估

实验内容：在节点内（4×L20）和跨节点（4×A100/A800）环境下，使用ShareGPT和Azure数据集，对vLLM、SGLang和gLLM在不同请求率下的延迟（TTFT、TPOT、E2EL）和吞吐量进行了评估。

实验结果与分析（见图10和图13）：

  1. 通用趋势：随着请求率增加，所有系统的延迟均上升，吞吐量逐渐达到饱和，该饱和点代表系统的最大处理能力。
  2. TTFT转折点：在大多数情况下，gLLM的TTFT因请求排队而显著上升的转折点，其请求率比其他系统高2-6倍。
  3. E2EL增长斜率：在大多数情况下，gLLM的端到端延迟（E2EL）增长斜率比其他两个系统低0.14-0.92倍，表现出更平缓的增长趋势。
  4. gLLM vs vLLM：得益于更高效的调度策略和运行时，gLLM在绝大多数测试场景中，无论延迟还是吞吐量都显著优于vLLM，处理能力提升了0.29-1.50倍。一个例外是在Azure数据集上以4 reqs/s速率服务Llama3.1-100B时，vLLM略优，原因是此时有充足的prefill令牌和内存，使得Sarathi-Serve的调度波动较小。
  5. gLLM vs SGLang（张量并行）：在节点内（高带宽）且请求率较低时，SGLang的延迟更低。但随着请求率增加，SGLang的优势减弱，甚至不如gLLM。在跨节点（带宽受限）实验中，由于SGLang的高通信开销，gLLM的性能显著优于SGLang。
  6. 数据集影响：gLLM在处理ShareGPT数据集时表现更优，因为其平衡调度能更好地利用多个短输入请求间的并行性。而Azure数据集的长输入序列削弱了请求间的并行性。
图10：vLLM、SGLang和gLLM的延迟与吞吐量比较（1节点，4×L20）。
图10：vLLM、SGLang和gLLM的延迟与吞吐量比较（1节点，4×L20）。
图13：vLLM、SGLang和gLLM的延迟与吞吐量比较（4节点）。
图13：vLLM、SGLang和gLLM的延迟与吞吐量比较（4节点）。

4.3 可扩展性研究

实验内容：通过不断增加请求率直至系统吞吐量稳定，测试了gLLM、vLLM和SGLang在增加GPU/节点数量时的最大吞吐量扩展性。

实验结果与分析（见图12）：
1. gLLM：在单GPU配置下吞吐量略低于其他系统（因优化不完整），但随着GPU数量增加，表现出近乎线性的扩展效率。
2. vLLM：在14B模型上表现出次线性扩展，但在32B模型上保持了线性扩展。
3. SGLang：在单节点内表现为次线性扩展，但在跨节点部署时，由于高昂的GPU间通信开销，性能出现下降。
4. 结论：gLLM的性能优势随GPU数量增多而愈发明显，表明其架构具有更优的可扩展性。

图12：最大吞吐量随GPU/节点数（横轴）增加的变化。条形图上的数字(×)表示与单/双卡/节点性能的倍数关系。
图12：最大吞吐量随GPU/节点数（横轴）增加的变化。条形图上的数字(×)表示与单/双卡/节点性能的倍数关系。

4.4 SLO达成率

实验内容：在跨节点部署Llama3.1-100B的场景下，比较了gLLM和vLLM在不同请求率下的服务等级目标（SLO）达成率。

实验结果与分析（见图14）：
1. SLO覆盖范围：在各种请求率下，gLLM的SLO达成率覆盖范围比vLLM高64%。
2. 可支持的请求率：在80%的SLO达成率下，gLLM可支持的请求率比vLLM高79%。
3. 低请求率下的表现：在低请求率下，gLLM的SLO达成率略低，这是因为令牌节流偶尔会导致TTFT略微增加并超出时间限制。通过微调超参数#T可以平衡TTFT和TPOT性能来解决此问题。

图14：在A800上跨节点部署Llama3.1-100B的SLO达成率。
图14：在A800上跨节点部署Llama3.1-100B的SLO达成率。

4.5 消融研究

实验内容：对gLLM的设计进行了消融实验，评估了各个组件的有效性。

实验结果与分析（见图15）：
1. gLLM w/o WT：与完整的gLLM相比，TTFT降低了10%（因为WT的平衡调度牺牲了部分prefill速度），但代价是TPOT增加了44%，E2EL增加了20%。
2. gLLM w/o UT：性能下降更显著，TTFT增加22%，TPOT增加91%，E2EL增加38%，证明了UT在平衡计算中的关键作用。
3. gLLM w/CK：即使使用Sarathi-Serve的基础调度策略，其吞吐量仍比vLLM高10%，E2EL低8%。这表明gLLM的运行时本身比vLLM的更高效。

图15：gLLM设计选择的消融研究。虚线标记了每个指标下的最优值。
图15：gLLM设计选择的消融研究。虚线标记了每个指标下的最优值。

4.6 敏感性研究

实验内容：研究了gLLM中超参数（#T, #MaxP, #MinP, $KV_{thresh}$）对系统性能的影响。

实验结果与分析（见图16）：
1. #T的影响：增加#T（处理所有待处理prefill令牌的迭代次数）会减少每个微批次的prefill令牌数，通常导致TTFT增加。但从1增加到4时，TTFT保持稳定，因为计算并行性的提升抵消了批次变小的影响。同时，TPOT得到改善，吞吐量增加，E2EL降低，证明令牌节流通过更均匀的计算分配提高了整体效率。
2. #MaxP的影响：#MaxP（最大批处理prefill令牌数）对TTFT和TPOT有双重影响：较高的值加速了初始令牌生成（TTFT），但增大的批次也延长了每令牌的处理延迟（TPOT）。设置过小（如512）会因prefill速率不足而降低系统吞吐量。
3. $KV_{thresh}$的影响：将$KV_{thresh}$设为0会导致效率低下：TTFT、TPOT和E2EL轻微增加，吞吐量下降。这是因为零阈值使系统更频繁地接近KV缓存容量极限，迫使系统为容纳剩余的decode请求而抢占正在进行的请求，从而浪费计算资源。
4. #MinP的影响：#MinP（最小批处理prefill令牌数）在大多数配置下对系统整体性能影响有限（波动在2%以内）。

图16：在不同超参数#T, #MaxP, #MinP和KVthresh设置下的归一化指标。
图16：在不同超参数#T, #MaxP, #MinP和KVthresh设置下的归一化指标。

4.7 功能性研究

实验内容：比较了gLLM、SGLang和vLLM的代码行数及在MMLU-Pro基准上的输出质量。

实验结果与分析（见表1）：
1. 代码行数：gLLM（3874行）的代码量远少于SGLang（65097行）和vLLM（226874行）。
2. 输出质量：gLLM在MMLU-pro上的得分（68.86）与SGLang（68.85）和vLLM(V0)（69.17）相当，表明gLLM在保持卓越推理速度的同时，没有牺牲输出质量。

表1：gLLM、SGLang和vLLM在代码行数和MMLU-Pro得分（在Qwen2.5-32B-Instruct上评估）上的比较。
表1：gLLM、SGLang和vLLM在代码行数和MMLU-Pro得分（在Qwen2.5-32B-Instruct上评估）上的比较。

A7 补充细节

5 相关工作

LLM中的调度。传统的DNN推理框架主要采用批处理级调度【索引42，Faster Transformer，https://github.com/NVIDIA/FasterTransformer】，这种方式难以处理LLM固有的可变序列长度。为解决此局限，Orca【索引40 ，Orca: A distributed serving system for transformer-based generative models，2022，OSDI】引入了迭代级调度，允许在模型执行前动态接纳和提前退出请求。然而，该方法在处理长prefill请求时面临挑战，因为它们会延迟后续的decode请求。为了缓解这种不平衡，近期的工作提出了Sarathi-Serve【索引36，Taming throughput-latency tradeoff in LLM inference with sarathi-serve，2024，OSDI】，通过将长序列分割成小块，将prefill和decode操作一同运行。尽管取得了这些进展，但每个批次间的计算不平衡问题依然存在，严重降低了流水线并行的效率。

LLM服务系统。为高效服务LLM，研究人员开发了多种系统。例如，Orca【索引40，Orca: A distributed serving system for transformer-based generative models，2022，OSDI】引入了一个具有迭代级调度的分布式服务系统以提高吞吐量。在内存优化方面，vLLM【索引41，Efficient memory management for large language model serving with pagedattention，2023，SOSP】采用分页注意力（paged attention），模仿虚拟内存机制以减少碎片化，而SGLang【索引46，Sglang: Efficient execution of structured language model programs，2024，NeurIPS】则利用基数注意力（radix attention）来消除请求间冗余的KV缓存计算。为解决prefill和decode阶段迥异的计算需求，Splitwise【索引37，Splitwise: Efficient generative LLM inference using phase splitting，2024，ISCA】和DistServe【索引38，Distserve: Disaggregating prefill and decoding for goodput-optimized large language model serving，2024，OSDI】采用了分离式架构，为每个阶段分配专门的硬件配置。此外，像FlexGen【索引51，Flexgen: High-throughput generative inference of large language models with a single GPU，2023，ICML】和InfiniGen【索引52，Infinigen: Efficient generative inference of large language models with dynamic KV cache management，2024，OSDI】这样的框架通过内存压缩和智能卸载等自适应技术来应对GPU内存限制，确保在资源受限下的可扩展性能。然而，这些系统未能实现各批次间的平衡调度，导致了显著的性能瓶颈。

用于LLM训练和服务的模型并行。随着LLM规模的增大，模型并行已成为分布式训练和服务的关键。张量并行需要设备间频繁通信，主要用于具有高带宽互连的环境。近期的进展【索引53，Breaking the computation and communication abstraction barrier in distributed machine learning workloads，2022，ASPLOS】、【索引54，Overlap communication with dependent computation via decomposition in large deep learning models，2023，ASPLOS】、【索引55，Centauri: Enabling efficient scheduling for communication-computation overlap in large model training via communication partitioning，2024，ASPLOS】、【索引56，Liger: Interleaving intra- and inter-operator parallelism for distributed large model inference，2024，PPoPP】通过策略性地将通信操作与计算重叠来解决通信空闲问题。对于流水线并行，研究重点在于解决不均衡的内存消耗【索引29，Adapipe: Optimizing pipeline parallelism with adaptive recomputation and partitioning，2024，ASPLOS】、【索引30，Hanayo: Harnessing wave-like pipeline parallelism for enhanced large model training efficiency，2023，SC】、【索引34，Bpipe: Memory-balanced pipeline parallelism for training large language models，2023，ICML】、流水线气泡【索引30，Hanayo: Harnessing wave-like pipeline parallelism for enhanced large model training efficiency，2023，SC】、【索引33，Zero bubble (almost) pipeline parallelism，2024，ICLR】、通信优化【索引31，Weipipe: Weight pipeline parallelism for communication-effective long-context large model training，2025，PPoPP】和激活检查点【索引29，Adapipe: Optimizing pipeline parallelism with adaptive recomputation and partitioning，2024，ASPLOS】、【索引32，Mario: Near zero-cost activation checkpointing in pipeline parallelism，2025，PPoPP】。结合张量并行和流水线并行的混合策略利用自动搜索算法【索引57，Alpa: Automating inter- and intraoperator parallelism for distributed deep learning，2022，OSDI】、【索引58，HAP: SPMD DNN training on heterogeneous GPU clusters with automated program synthesis，2024，EuroSys】、【索引59，Metis: Fast automatic distributed training on heterogeneous gpus，2024，USENIX ATC】或利用异构特性【索引58，HAP: SPMD DNN training on heterogeneous GPU clusters with automated program synthesis，2024，EuroSys】、【索引59，Metis: Fast automatic distributed training on heterogeneous gpus，2024，USENIX ATC】、【索引60，Whale: Efficient giant model training over heterogeneous gpus，2022，USENIX ATC】、【索引61，SWARM parallelism: Training large models can be surprisingly communication-efficient，2023，ICML】，而像Megatron-LM【索引35，Efficient large-scale language model training on GPU clusters using megatron-lm，2021，SC】这样的框架则展示了经过经验验证的大规模部署配置。然而，这些方法主要关注训练过程中的优化。在LLM服务中，专门的优化通过GPU感知的分配来针对硬件异构性【索引22，Dynamollm: Designing LLM inference clusters for performance and energy efficiency，2024，CoRR】、【索引23，Helix: Distributed serving of large language models via max-flow on heterogeneous gpus，2024，CoRR】，并使用分块prefill机制来减少流水线气泡【索引36，Taming throughput-latency tradeoff in LLM inference with sarathi-serve，2024，OSDI】。尽管如此，流水线气泡问题并未被分块prefill有效解决，并成为高效部署的瓶颈。

A5 结论

本文介绍了gLLM，一个用于分布式LLM服务的全局平衡流水线并行系统，该系统集成了令牌节流（Token Throttling）方法。令牌节流机制通过动态地分别调整prefill和decode阶段的令牌数量，确保了各批次间的计算平衡，从而最小化了流水线气泡。为了实现令牌节流，我们设计了一个专为流水线并行量身定制的异步运行时。对主流LLM的实验表明，与最先进的流水线或张量并行系统相比，gLLM的最大吞吐量提高了11%至398%，同时保持了更低的延迟。