Splitwise: Efficient Generative LLM Inference Using Phase Splitting

摘要——生成式大型语言模型（LLM）应用正在快速增长，导致大规模部署昂贵且耗电的GPU。我们对LLM推理的特性进行了研究，发现每个推理请求都会经历两个阶段：计算密集型的提示计算（prompt computation / profilling）阶段和内存密集型的生成（token generation / decoding）阶段。每个阶段在延迟、吞吐量、内存和功耗方面都有不同的特性。尽管有最先进的批处理和调度技术，生成阶段的计算资源利用率仍然较低。与提示计算不同，生成阶段并不需要最新GPU的计算能力，可以在更低的功耗和成本下运行。

基于这些洞察，我们提出了一种名为Splitwise的模型部署和调度技术，将LLM推理请求的两个阶段分配到不同的机器上。Splitwise使得可以针对每个阶段使用更适合的硬件进行资源管理。请求的状态通过优化的网络库在当今GPU集群中的快速背板互连上高效传输。使用Splitwise，我们设计了针对吞吐量、成本和功耗进行优化的同构和异构LLM推理集群。与当前设计相比，Splitwise集群在成本降低20%的情况下，实现了最多1.4倍的吞吐量提升。或者，在相同的功耗和成本预算下，能够提供2.35倍的吞吐量。

介绍

生成式大型语言模型（LLM）的最新进展显著提升了其响应质量和准确性[18], [71]。这些趋势促使LLM在各个领域得到了广泛应用[6], [21]。大多数现代LLM都是基于Transformer架构构建的[77], [78]，并展现出类似的特性[63]。Transformer模型的规模稳步增长，从早期拥有3.4亿参数的BERT模型[36]，到拥有惊人1750亿参数的GPT-3[28]，再到据传参数量更大的GPT-4。

LLM通常运行在昂贵且耗电的GPU上[16]。LLM的突然大规模部署导致了全球范围内的GPU产能紧缺[14]。LLM推理的计算需求远远超过了训练需求，因为大量应用正在利用LLM。此外，由于训练LLM需要昂贵且专用的超级计算机[56], [60]，因此需要大量的推理操作来摊销高昂的训练成本。尽管LLM推理任务的规模比训练任务小得多，但由于涉及的计算量，推理仍然相当昂贵。

生成式大型语言模型（LLM）的推理过程中，对于单个请求，需要通过模型进行多次前向传播，因为输出的token（标记）是一个接一个生成的。这本质上涉及两个对比鲜明的计算阶段。首先是提示计算阶段，在这一阶段，所有输入的提示token会并行通过模型的前向传播以生成第一个输出token。这个阶段通常计算密集，需要现代高性能GPU所提供的高FLOPs（每秒浮点运算次数）。其次是token生成阶段，在这一阶段，基于前一个token的前向传播结果以及先前token的所有缓存上下文，顺序生成后续的输出token。由于缺乏计算并行性，尽管有最先进的批处理技术，这一阶段仍然主要受限于内存带宽和容量。

将这两个阶段都运行在同一台机器上往往会导致端到端延迟的不一致性，这是由于提示阶段和token生成阶段的批处理随机性造成的。由于这些挑战，服务提供商需要为满足交互式应用严格的推理服务水平目标（SLOs）而过度配置昂贵的GPU。同时，云服务提供商（CSPs）为了满足GPU的需求，不得不建设大量新的数据中心，但也面临着功耗限制的问题[19]。

Note：如果两个阶段都在同一台机器上运行，系统可能会先处理一批提示计算任务，然后紧接着处理一批token生成任务。由于提示计算和token生成的资源需求不同，GPU可能会在提示计算阶段被充分利用，但在token生成阶段却无法充分利用

尽管业界不断推出新的计算能力更强的GPU，但每一代GPU的功耗和成本也比上一代更高。然而，如表I所示，尽管GPU的计算能力显著提升，但其高带宽内存（HBM）的容量和带宽的提升速度却没有相应增加。最新的NVIDIA H100 GPU与其前代A100 GPU相比，计算能力增加了3.43倍，功耗增加了1.75倍，但内存带宽仅增长了1.6倍，而内存容量没有增加。

我们的工作：鉴于提示计算阶段和token生成阶段的不同特性，我们提出将推理请求拆分，并在不同的机器上运行这两个阶段。通过这种方式，我们可以分别管理每个阶段的硬件资源，从而提高GPU的利用率和系统的整体效率。这样还可以为每个阶段使用不同且更适合的硬件。为了实现这种设置，需要将提示计算阶段的缓存上下文以低延迟传输到token生成阶段的机器上。我们通过在数据中心中使用现有的后端Infiniband互连技术，以优化的方式实现这些传输，从而提高效率而不影响性能。

利用Splitwise，我们设计了针对成本、吞吐量和功耗优化的集群，并使用LLM推理请求的生产追踪数据进行测试[4]。鉴于不同GPU代际之间内存和计算能力的增长速率差异，我们还评估了不同GPU和功耗限制在不同推理阶段的表现。这使我们能够为用户提供更好的每美元性能（Perf/$），以及为云服务提供商（CSPs）提供更好的每瓦性能（Perf/W）。此外，用户可以选择使用旧款GPU，这些GPU可能更容易获得。

我们展示了基于Splitwise的LLM推理集群可以在成本降低20%的情况下，实现1.4倍的吞吐量提升。或者，在相同的成本和功耗预算下，提供2.35倍的吞吐量。

总结：我们做出了以下贡献：

• 详细刻画了在NVIDIA A100和H100 GPU上，使用生产追踪数据分析LLM推理过程中提示计算阶段和token生成阶段在执行和资源利用模式上的差异。
• 提出了一种名为Splitwise的技术，通过将提示计算阶段和token生成阶段拆分到不同的机器上，从而优化现有硬件的利用率。
• 探索了使用Splitwise进行同质和异质集群部署的设计，以优化整体成本、请求吞吐量和预配置功耗。
• 基于生产追踪数据，评估了使用Splitwise设计的系统。

背景

A. 大型语言模型

现代LLM（大型语言模型）基于Transformer架构。Transformer模型使用注意力机制[77]和多层感知器层分别来理解输入和生成输出。基于Transformer的LLM包括仅编码器模型[36]、[54]，仅解码器模型[67]、[69]、[71]，以及编码器-解码器模型[70]。本文重点讨论的生成型LLM通常是仅解码器或编码器-解码器模型。

B. 生成型LLM的推理阶段

图1展示了生成型LLM推理的一个示例。当接收到提示查询时，所有输入token会在一次迭代中并行计算，以生成第一个token。我们将此称为提示处理阶段。在提示计算期间通过注意力层生成的上下文会被保存到键值（KV）缓存中，因为未来的所有token生成迭代都需要这些上下文。在第一个token生成之后，随后的token生成仅使用最后生成的token和KV缓存作为模型前向传递的输入。这使得后续的token生成比计算密集的提示阶段更依赖于内存带宽和容量。

C. LLM的性能指标

以往的研究提出了LLM推理的三项主要指标：端到端（E2E）延迟、首个token生成时间（TTFT），以及吞吐量。我们在此基础上增加了另一个延迟指标：token之间的时间（TBT），用于跟踪token按顺序生成时的在线流式吞吐量。表II总结了本文中考虑的关键性能指标。

生成型LLM可能用于各种任务，并具有不同的服务水平协议（SLO）。对于批处理任务（例如摘要生成），TTFT或TBT延迟指标不如吞吐量重要。而对于延迟敏感的任务（例如对话API），TTFT和TBT则是更为重要的指标，并且要求更严格的SLO。

D. 请求的批处理

推理请求可以进行批处理以提高吞吐量。先前的几项研究已经探讨了批处理的机制[23], [81]。图2展示了三种常见批处理机制的推理时间线。默认机制仅在请求级别进行批处理（图2(a)）。在这种情况下，准备好的请求会被批量处理，但这些请求的所有前向传递在其他请求运行之前必须全部完成。由于请求可能有较长的token生成阶段，这可能会导致在此期间到达的请求长时间等待，从而造成较高的首个token生成时间（TTFT）和较高的端到端（E2E）延迟。一个优化方案是连续批处理[81]（图2(b)）。在这种情况下，调度决策在模型的每次前向传递之前就已完成。然而，任何给定的批处理要么仅包含处于提示阶段的请求，要么仅包含处于token阶段的请求。由于提示阶段影响TTFT，因此被认为更重要。因此，等待中的提示请求可以抢占token阶段。虽然这减少了TTFT，但可能会显著增加token之间的时间（TBT）的尾部延迟，从而增加E2E延迟。最后是混合批处理[23]（图2©）。通过这种批处理，调度决策在每次前向传递时做出，提示阶段和token阶段可以同时运行。这减少了对TBT的影响，但并未完全消除，因为与提示阶段一起调度的token阶段将经历较长的运行时间。在本文的其余部分，除非另有说明，我们使用混合批处理。

E. 模型并行性

模型并行性可以将模型划分到多个GPU，甚至多台机器上，以提高效率和内存容量。LLM推理通常使用流水线并行性和张量并行性。流水线并行性（PP）将模型的层划分给不同的GPU，同时将同一层内的所有操作符和张量保留在同一GPU上。张量并行性（TP）将张量划分到不同的GPU上，同时在每个GPU上复制所有层。流水线并行性要求参与GPU之间的通信较少，而张量并行性则要求每层进行高带宽通信。通常，张量并行性在同一台机器内连接有高带宽互连（如NVLink [15]）的GPU之间表现更佳。在本文的其余部分，我们使用8个GPU进行张量并行性以获得最佳延迟。

F. GPU集群和互连

随着LLM用例的不断增加，许多云服务提供商扩大了基于GPU的服务，导致了大规模的GPU集群部署[5], [56], [57]。这些AI集群中的每台机器通常由8个旗舰级NVIDIA GPU（A100或H100）组成。每个GPU通过高带宽Mellanox InfiniBand互连[10], [13]与集群中的其他所有GPU连接，形成了高带宽的数据平面网络。如今云中提供的InfiniBand带宽在每对GPU之间的范围为25到50GBps[7], [10]。

特征

这部分内容探讨了大型语言模型（LLM）推理的性能和利用率特征，并提出了一些关键见解，以指导Splitwise的设计。

生产跟踪数据
我们使用了2023年11月11日从两个Azure LLM推理服务中获取的生产跟踪数据。我们的跟踪数据代表了当前LLM推理中最常见的场景：编码和对话。我们已经在https://github.com/Azure/AzurePublicDataset发布了我们的一部分跟踪数据。用于特征化的跟踪数据长度为20分钟，包括到达时间、输入大小（提示令牌的数量）和输出大小（生成的令牌数量）。由于客户隐私要求（例如GDPR），我们无法查看提示内容。我们利用生产跟踪数据来指导输入和输出的大小，其中我们发送具有所需令牌数量的输入提示，并强制模型生成相应数量的输出令牌。请注意，输入提示的文本不会影响我们基准测试的性能指标，因为这些指标仅取决于输入和输出的大小。为了进行这种特征化，我们不会在请求之间重用KV缓存，以模拟具有安全保障的云服务。

模型

表III显示了我们评估的模型。BLOOM和Llama2都是最先进的开源LLM。这两种模型都是解码器-only的、基于变换器的模型。我们使用每种模型中参数最多的版本，因为这些版本在生产级准确度方面最具代表性。除非另有说明，否则我们在8个H100 GPU的机器上运行BLOOM-176B和Llama-70B。

A. 提示和生成令牌的数量

为了更好地理解我们的跟踪数据，我们检查了提示输入和生成输出令牌数量的分布。图3a展示了提示令牌数量的分布。由于编码LLM推理服务通常用于在用户编写代码时生成补全，其输入提示可能包括到目前为止编写的代码的大块内容。因此，它的提示大小的中位数较大，为1500个令牌。另一方面，对话服务的输入提示令牌数量范围更广，因为它依赖于用户。此跟踪数据的提示令牌数量的中位数为1020个令牌。图3b展示了生成令牌数量的分布。由于编码服务通常仅在用户键入时生成程序中的下几个单词，因此输出令牌的中位数为13个令牌。另一方面，对话服务则有一个几乎双峰的分布，生成的令牌数量的中位数为129个。

见解I：不同的推理服务可能会有非常不同的提示和令牌分布。

B. 批处理利用率
为了理解这些请求可以被批处理到什么程度，我们测量了机器在不同批处理大小下运行的频率。我们使用了如图2所示的混合连续批处理（mixed continuous batching）。为了适应单台机器，我们运行了缩小版的编码和对话数据跟踪，每秒处理2个请求。

图4展示了机器在运行不同数量的活跃令牌的批处理时所花费的时间分布。请注意，如果一个100个令牌的提示正在其提示阶段运行，我们将活跃令牌计为100个。然而，一旦请求进入生成令牌阶段，我们将其计为一个活跃令牌，因为令牌是一次一个生成的（假设beam search大小为1 [51]）。我们发现，对话服务大部分时间（60-70%）仅运行20个或更少的令牌。由于编码服务的输出令牌非常少，它在生成阶段的批处理效果更差，有超过20%的时间仅运行一个令牌。两个LLM都表现出非常相似的趋势。

洞察二：混合连续批处理大部分时间都只批处理了非常少量的活跃令牌。

C. 延迟

TTFT。图5a展示了提示令牌数量对TTFT的影响。提示大小的范围是根据编码和对话数据跟踪确定的。我们发现，对于两个模型来说，随着提示大小的增加，TTFT几乎呈线性增长。这种行为是由于提示阶段的GPU利用率高且受计算限制。

TBT。图5b展示了强制将不同请求的输出令牌一起批处理对TBT的影响。我们观察到，随着批处理大小的增加，对TBT的影响很小。即使批处理大小达到64，对TBT的影响也仅为2倍。

E2E。图5c展示了在没有批处理的情况下两个模型的E2E延迟的各个百分位。可以明显看出请求输入和输出大小之间的差异。此外，我们看到大部分E2E时间都花在了生成令牌阶段。这一点甚至在编码数据跟踪中也成立，尽管提示大小很大，而生成的令牌却很少。事实上，我们发现对于BLOOM-176B模型，一个包含1500个输入令牌的提示阶段所花费的时间与生成6个输出令牌的生成阶段花费的时间相同。

洞察三：对于大多数请求，E2E时间的大部分都花在了生成令牌阶段。

D. 吞吐量

图6展示了批处理对吞吐量（以每秒处理的令牌数衡量）的影响。对于提示阶段，我们将吞吐量定义为每秒处理的提示输入令牌的数量。我们发现，在提示令牌数量超过2048之后，吞吐量开始下降，这对应于跟踪数据中提示大小的中位数少于2的批处理大小。另一方面，图6b显示了在生成令牌阶段，随着批处理的增加，吞吐量不断增加，直到批处理大小达到64，此时机器内存耗尽。

洞察四：为了确保良好的性能，提示阶段的批处理大小应受到限制。相比之下，批处理生成令牌阶段可以在不影响性能的情况下实现高吞吐量。

E. 内存利用率

在LLM推理期间，GPU内存用于存储模型权重和激活，以及KV缓存（第II-B节）。随着批处理中令牌数量的增加，KV缓存所需的内存容量也随之增加。图7展示了在批处理中令牌数量增加时，每个阶段的内存容量利用率。在提示阶段，输入提示令牌会生成KV缓存。而在生成令牌阶段，每个正在处理的活跃生成令牌都会访问其整个上下文的KV缓存。

洞察五：提示阶段的批处理受计算限制，而生成令牌阶段受内存容量限制。

F. 电力利用
在托管机器时，云服务提供商需要考虑峰值功耗，这直接影响数据中心的成本。这一点在构建 GPU 集群时尤为重要，因为 GPU 的功耗远高于普通计算机器。以下是相关观察：

图8 显示了在运行提示阶段（Prompt Phase）和令牌生成阶段（Token Generation Phase）时，GPU 功耗相对于热设计功耗（TDP）的标准化情况。由于提示阶段是计算密集型的，其功耗随着批处理大小的增加而增加。而令牌生成阶段则是内存密集型的，其功耗在处理令牌数量增加时几乎不变。

图9 显示了当增加功率上限时对延迟的影响。提示阶段对功率上限非常敏感，当功率上限增加时，延迟显著增加。相比之下，令牌生成阶段在将功率上限降低 50%（例如，从 700W 降到 350W）的情况下，延迟几乎没有受到影响。

洞察 VI：提示阶段有效地利用了 GPU 的电力预算，而令牌生成阶段则没有。

G. GPU 硬件变异
由于提示阶段和令牌生成阶段的不同特性，我们测量了在不同硬件上运行的性能影响。以下是相关信息：

表 I 显示了 DGX-A100 和 DGX-H100 的规格。A100 的内存与计算比率优于 H100。

表 IV 显示了我们的发现。与提示阶段（TTFT）相比，令牌生成阶段（TBT）的性能影响较小。由于编码请求主要集中在提示阶段，生成的令牌很少，因此 A100 在编码任务中的 E2E 延迟影响比对话任务更差。此外，整体上 A100 的推理成本和能效与 H100 相比更好或相等。
洞察 VII：令牌生成可以在计算能力较低的硬件上运行，以获得更好的每瓦性能（Perf/W）和每美元性能（Perf/$）效率。

四级标题

五级标题

六级标题