翻译自 https://medium.com/squeezebits-team-blog/vllm-vs-tensorrt-llm-2-towards-optimal-batching-for-llm-serving-2a174d45ee3a 该文章测试了最新版（9.24）trt-llm和vllm的性能，不过文中没有提到是否使用vllm在0.6.2版本更新的Multi-step Scheduling。

在之前的文章中，我们在默认配置和特定限制下对vLLM和TensorRT-LLM进行了比较，提供了它们基准性能的一些看法。然而，依赖默认设置或仅调整单个参数并不足以充分发挥这些框架的能力，特别是在复杂的实际环境中。在本系列的这篇文章中，我们通过调整关键参数如最大批量大小（maximum batch size）和最大token数来进行更深入的探索。我们将逐步调整这些参数，调查它们如何影响每个框架的性能。这将帮助我们找出最佳的批量配置，以实现vLLM和TensorRT-LLM的最佳性能，展示它们在更广泛场景中的优势和劣势。

两阶段文本生成 Two-phased Text Generation

在深入探讨关键参数之前，让我们先分解文本生成的两个阶段：Prefill阶段和Decode阶段。在预填充阶段，模型处理所有输入token以创建上下文（context），并生成第一个输出token，然后使用该输出token生成后续的输出token。接下来是解码阶段，模型自回归地生成输出，使用预填充阶段创建的上下文以及先前的输出。在预填充阶段，所有输入token会同时被送入模型。这使得预填充阶段计算密集。另一方面，在解码阶段，只有最近生成的token会被送入模型。之前的上下文会从KV缓存中加载，以减少重复计算。加载KV缓存会导致显著的内存传输开销，使解码阶段成为内存受限。因此，由于这两个阶段的特性不同，关键参数对每个阶段的影响也不同。

批量配置的关键参数

最大批量大小

最大批量大小，在vLLM中称为max_num_seqs，在TensorRT-LLM中称为max_batch_size，定义了可以同时处理的请求的最大数量。较大的批量大小允许更多的token并行生成，增加吞吐量。然而，增加批量大小可能会降低TPOT并需要更多的KV缓存和激活内存。

最大token数

最大token数，在vLLM中称为max_num_batched_tokens，在TensorRT-LLM中称为max_num_tokens，限制了每次迭代处理的token数量。增加此值通常可以通过容纳更长的序列和更大的批量来提高吞吐量。增加激活张量的大小有助于更好地利用硬件的计算资源。然而，增加此值可能会导致更长的TTFT。因此，找到最优值非常重要。

为什么需要这两个参数

当多个请求到来时，调度器根据这两个参数进行批量处理。请注意，调度器如何工作的详细信息将在本系列的下一篇文章中介绍。

在预填充阶段，批量大小通常受到_最大token数_的限制，因为每个请求的输入token数量较大。另一方面，_最大token数_在解码阶段通常不会起决定性作用，因为输入token的数量较少，很难达到_最大token数_。相反，_最大批量大小_在解码阶段起着关键作用，限制了解码阶段的批量大小，并在TPOT和吞吐量之间取得平衡。

理论上，在吞吐量饱和范围内具有最低TPOT的批量大小是_最大批量大小_的最佳值。因此，这两个参数对于优化整个生成过程的性能至关重要。在本文中，_最大批量大小_和_最大token数_用于每个参数以保持一致性。

实验设置

在本文中，我们重点关注两个关键参数，_max batch size_和_max number of tokens_。

最大批量大小

• vLLM默认值：256

• TensorRT-LLM默认值：256

• 变化范围：4, 8, 16, 32, 64, 128, 256, 和512

最大token数

• vLLM默认值：2048

• TensorRT-LLM默认值：8192

• 变化范围：1024, 2048, 4096, 8192, 和16384

通过调整这些参数，我们评估了它们对不同场景下两种框架的吞吐量、TTFT和TPOT的影响。

基准数据集 Benchmark Dataset

为了确保公平比较 vLLM和TensorRT-LLM，我们使用了具有固定输入和输出长度的数据集，以保持处理token数量的一致性。此外，鉴于预填充和解码阶段的不同特性，我们为每个阶段设计了两个定制数据集：

• Prefill-Heavy Dataset：包含1024个样本，每个样本的输入长度为768个token，输出长度为128个token。此数据集侧重于预填充阶段，强调输入长度比输出长度更长。

• Decode-Heavy Dataset：包含1024个样本，每个样本的输入长度为128个token，输出长度为768个token。它专注于解码阶段，模型生成更多的输出token。

序列长度的选择允许灵活地调整_最大token数_，从1024开始，因为_最大token数_的值必须超过输入长度，以便在不超过最大token容量的情况下容纳所有样本。

框架版本

我们选择了最近的版本，这些版本成功完成了基准测试：

• vLLM: v0.6.2

• TensorRT-LLM: 0.14.0.dev2024092401，使用C++ API

模型和硬件

• 模型: Llama-3–8B (BF16)

• 硬件: NVIDIA A100-SXM 80G GPU, 32 vCPU 125 GB RAM

结果

为了全面评估关键参数的影响，我们在不同的请求率条件下，分别调整了_最大批量大小_和_最大token数_，并在两个数据集中进行了测试。每个实验使用三个关键LLM指标进行评估：吞吐量、首个token响应时间（TTFT） 和 每个输出token时间（TPOT）。每个指标的定义在之前的文章中有详细说明。通过在不同请求率条件下的结果，我们将突出每个指标的特定请求率，以更好地聚焦关键参数的趋势。我们使用无限请求率来衡量吞吐量和TPOT，而使用请求率4来测量TTFT，因为在无限请求率下的TTFT远超出实际场景的范围。

场景#1：预填充偏重

我们首先评估了_最大批量大小_和_最大token数_在预填充偏重场景下的影响。在这一部分中，我们重点探讨它们对预填充阶段的具体影响。

吞吐量结果

首先，如图2所示，随着_最大批量大小_的增大，两个框架的吞吐量都在增加。这种趋势是预期的，因为较大的批量大小允许更多的token同时生成。然而，超过某个阈值后，由于计算限制，它达到了饱和点，甚至可能略有下降。这表明简单地增加_最大批量大小_并不总是最佳解决方案。

在自回归生成输出token时，有时KV缓存的插槽可能不足。在这种情况下，LLM引擎可以抢占低优先级的请求，并在生成稍后恢复时继续这些被抢占的请求。处理抢占有两种策略：_重新计算_和_交换_（_recomputation_ and _swap_）。在_重新计算_方法中，抢占请求的KV缓存会被丢弃，并在生成恢复时重新计算。而在_交换_策略中，KV缓存会被交换到主机内存中，并在可能的情况下交换回来。这两种方法都会导致整体性能的下降，因此监控抢占的发生并调整参数以避免它非常重要。

随着_最大token数_的增加，吞吐量也有所提高。这种提升主要来自预填充阶段，因为较大的_最大token数_值使得预填充批量大小变得更大。从这两个结果可以看出，框架的吞吐量表现因配置不同而有所变化。总体来说，TensorRT-LLM在较大批量大小下的吞吐量更高，而vLLM在较小批量大小下更快。

TTFT结果

TTFT与_请求率_高度相关，正如之前的文章中所讨论的那样。在本文中，我们将更关注通过调整_最大批量大小_和_最大token数_对批量处理效果的影响。如上所述，此实验使用了请求率4。

TTFT在几个较小的_最大批量大小_值后达到饱和。在较小_最大批量大小_时，巨大的TTFT是由于有限的吞吐量导致后续请求的排队时间造成的。排队时间的解释也在我们之前的文章中有详细说明。由于较小_最大批量大小_下的吞吐量非常低，当先前的请求处于解码阶段时，后续请求在其预填充阶段开始之前会遭遇长时间的延迟。

如图5所示，_最大token数_对TTFT的影响并不显著。然而，考虑到_最大token数_决定了预填充批量大小，这可能出乎意料。这种现象同样是由于排队时间所致。随着_最大token数_的增大，预填充批量大小也会增加，因此每次预填充迭代的延迟变长。然而，预填充吞吐量提高，减少了后续请求的排队时间。在两个框架的比较中，TensorRT-LLM在不同_最大token数_值下表现出了一致的较快的TTFT。

TPOT结果

如图6所示，_最大批量大小_对TPOT的影响非常大。随着_最大批量大小_的增加，TPOT也在增加。尽管TPOT变差，但较大的批量大小会增加吞吐量，正如吞吐量结果中所示。vLLM在一定程度上表现出更好的TPOT，直到TPOT达到TensorRT-LLM的饱和点。TensorRT-LLM在吞吐量结果中显示出的饱和点与TPOT的饱和点相似。

为了进一步解释TPOT的饱和现象，我们评估了TensorRT-LLM基准测试中的平均_运行批量大小_。_运行批量大小_指的是抢占后的输入张量的实际批量大小，直接影响TPOT。从图中可以看出，饱和点的_运行批量大小_几乎是相同的。

相比之下，vLLM的TPOT并未达到其饱和点，因为其平均_运行批量大小_仍在增加。虽然批量大小继续增长，但在_最大批量大小_为256时，吞吐量已经达到饱和，因为它已经受到计算限制。vLLM和TensorRT-LLM之间的_运行批量大小_趋势差异源于它们不同的调度方法。我们将在vLLM vs TensorRT-LLM系列的后续文章中讨论这一点。

在两个框架中，随着_最大token数_的增大，TPOT略有下降。当_最大批量大小_为256且_最大token数_为1024时，由于较小的平均运行批量大小，TensorRT-LLM显示出异常低的TPOT（参见图7）。

TPOT的下降趋势是出乎意料的，因为_最大token数_是预填充阶段的主导因素。这种现象是由于某些请求的第一个和后续输出token之间的延迟所致。在大多数情况下，解码批量大小大于预填充批量大小，需要多次预填充迭代才能填充后续的解码批量。如果第一个预填充批量的结果立即返回，这些请求在生成下一个token之前会因为剩余的预填充迭代而遭遇延迟。这会导致某些请求的TPOT很高，使得最大TPOT比最小TPOT大得多，如表1所示。随着_最大token数_的增加，预填充吞吐量加快，减少了延迟效应，最终导致TPOT下降。

场景#2：解码偏重

在解码偏重场景中，每个参数的总体趋势与预填充偏重结果大致相似，因此在本节中，我们将更多地关注这两个场景结果不同的情况。

在预填充偏重场景中，我们观察到较大的_最大token数_会带来更高的吞吐量。然而，在解码偏重场景中，最大token数的影响被较长的解码迭代所掩盖。

相反，我们可以看到_最大批量大小_值在解码偏重场景中更具影响力，如图10所示。当_最大批量大小_从4增加到512时，预填充偏重基准测试的吞吐量增加了约10倍，而在相同情况下，解码偏重基准测试的吞吐量增加了约30~40倍。

在预填充偏重场景中，最大批量大小为16已经足以达到TTFT饱和。这一饱和点标志着由于高吞吐量消除了排队时间的临界值。相比之下，在解码偏重场景中，最大批量大小为128才达到饱和（图11），因为更长的输出长度要求更高的吞吐量来抵消排队时间的延迟。

最终想法

在本文中，我们回顾了与vLLM和TensorRT-LLM上请求批量处理密切相关的关键参数，最大批量大小和最大token数的影响。结果表明，调整这些参数会显著影响两种框架的性能。

每个服务都有自己的优先级。如果服务优先考虑吞吐量，通常可以通过增加最大批量大小和最大token数直到饱和来提高性能。然而，必须找到防止抢占的最优值，并考虑内存容量和其他配置（如序列长度）等因素。如果服务优先考虑TTFT，则应通过设置最大批量大小来消除排队延迟，确保足够的吞吐量。在优先考虑TPOT的情况下，必须调整两个参数以在TPOT和吞吐量之间取得平衡。

在准备本文时，我们进行了大量实验，如图12所示，以全面了解每个参数和环境变量之间的相互作用。然而，还有更多领域需要探索：任何服务场景或模型的变化都需要额外的实验。这也是我们开发Fits on Chips的原因，以简化这一过程。此工具包能够进行高效分析和性能调整，确保持续实验变得可管理且有效。

请继续关注vLLM vs TensorRT-LLM系列的更多见解！

公众号后台回复“数据集”获取100+深度学习各方向资源整理