极市导读
本文探讨了在动态序列长度场景下，vLLM和TensorRT-LLM两种大型语言模型（LLM）推理系统的性能对比。 >>加入极市CV技术交流群，走在计算机视觉的最前沿
翻译 from https://medium.com/squeezebits-team-blog/vllm-vs-tensorrt-llm-5-dynamic-sequence-lengths-731c26ee0039
前言
近年来，越来越多的服务基于 LLM（Large Language Model，大型语言模型）推理系统持续涌现。在实际应用中，请求的长度差异显著，每种请求都需在不同的约束条件下运行。[上一篇文章]( [vLLM vs TensorRT-LLM] #4 系统调度schedule比较)中，我们探讨了 vLLM 和 TensorRT-LLM 中的调度器如何影响推理性能。为了明确评估特定推理参数的影响，我们故意采用固定长度的数据集进行控制实验。在该实验中，输入和输出的长度固定，并忽略终止序列标记（EOS token），使得生成可以按照请求的最大输出长度进行预测，从而为评估基本性能因素提供了清晰的基准。
现在，我们转向动态长度数据集，研究调度器在复杂工作负载下的表现。在这种情况下，输入长度会变化，生成过程通常在达到最大输出长度之前停止。这种动态性会影响性能指标（如吞吐量和 TPOT），因为动态输入请求会导致资源利用率波动。本文旨在揭示动态序列长度如何影响调度器在应对波动需求时的有效性，并优化 LLM 推理。
Dynamic-Sonnet 数据集
虽然现有的测试 LLM 的数据集众多，但我们希望选用能够准确评估推理框架性能影响的合适数据集。因此，我们设计了一个新的数据集——Dynamic-Sonnet，用于更好地评估动态性带来的影响。
传统的固定长度数据集便于实验控制和分析，但无法反映可变序列长度带来的影响。而动态长度数据集虽然表现出显著的多样性，却因其结果分析难度较高而增加挑战。我们的目标是结合两者的优势，创建一个动态但分布受控的数据集。为更好地模拟输入和输出的动态行为，我们参考了 ray-project/llmval 的基准测试方法，创建了 Dynamic-Sonnet 数据集。
Dynamic-Sonnet 包含四个子集：1K、2K、4K 和 8K。每个子集设计了不同的 token 长度，以真实反映实际使用场景。每个提示要求从一系列莎士比亚十四行诗中随机选择尽可能多的诗句。每次请求包含的诗句数量是随机的，其目标是达到每个子集的设定均值，遵循正态分布。
示例数据
Example data
Pick as many lines as you can from these poem lines:n
FROM fairest creatures we desire increase,n
That thereby beauty’s rose might never die,n
But as the riper should by time decease,n
His tender heir might bear his memory:n …
图 1 和表 1 展示了 Dynamic-Sonnet 数据集中各子集的 token 长度分布。每个 NK 子集设计的最大提示长度不超过 NK tokens。例如，1K 子集的平均提示长度约为 512 tokens，最大长度为 773 tokens；而 8K 子集的平均提示长度为 7,153 tokens，最大长度为 7,709 tokens。这样的设计能够深入测试 LLM 推理系统，挑战每个框架（或调度器）在动态工作负载中的处理能力，因为 token 长度的不可预测性会带来更大的挑战。
实验设置
我们保持了与之前文章大部分实验一致的设置，但在此基础上将 TensorRT-LLM 中使用的 C++ API 替换为 Triton Server。服务器-客户端的配置遵循 vLLM 和 TensorRT-LLM 的 OpenAI API 接口。
框架版本、模型和硬件
• vLLM: 0.6.3.post1
• TensorRT-LLM: v0.13.0 版本 / Triton Server: v2.50.0
• 模型: Llama-3.1–8B-Instruct（BF16）
• 硬件: NVIDIA A100-PCIe 80G GPU，AMD EPYC 7643 48 核处理器，128 GB RAM
数据集
• 动态: *dynamic_sonnet_llama3*[1] 1K、2K、4K、8K
• 固定: 随机 token，输入和输出长度固定，与动态数据集的 1K、2K、4K、8K 子集的平均长度对应
需要注意的是，固定数据集的输入长度并不严格等于 1K、2K、4K 和 8K，而是设定为与动态数据集的平均长度相匹配。这种方法在两种数据集间平衡了计算负载，确保了公平的对比。
配置
• 最大批量大小：256
• 最大 token 数量：16384
• 请求速率：无限
实验结果
实验 #1：动态序列长度的影响
我们在相同环境下比较了固定和动态数据集（例如 Dynamic-Sonnet 1K 和 Fixed 1K 数据集）对性能的影响。固定数据集的输出长度被设为动态数据集的平均输出长度，因此生成的总 token 数几乎相同。
固定数据集为调度器提供了稳定的环境，变动性较小，便于预测资源分配并实现一致的性能。而动态数据集需要调度器持续调整批量大小和 token 数量，显著影响硬件利用率。此实验突出了调度器在面对 token 长度变化时保持一致性能的重要性——这是优化 LLM 推理的一大挑战。
图 2 展示了 vLLM 和 TensorRT-LLM 在固定和动态数据集上的吞吐量比较。对于较短的序列（如 1K 或 2K），固定数据集的吞吐量显著高于动态数据集。这种差异源于 vLLM 和 TensorRT-LLM 中不同的调度机制。
在 TensorRT-LLM 中，默认使用的 GUARANTEED_NO_EVICT 策略会根据最大输出长度为每个请求预分配 KV 缓存的内存。动态数据集中，KV 缓存基于可能的最大长度进行分配，这通常会导致内存浪费，因为实际所需的内存远小于分配的内存量。
而固定数据集的输出长度是可预测的，可以精确分配所需的 KV 缓存内存。在本实验中，固定数据集的输出长度被设定为动态数据集的平均输出长度，因此 KV 缓存内存需求较低，支持更大的运行批量大小。这一趋势在图 3 中进一步得到体现。
对于较长的序列（如 4K 和 8K），固定和动态数据集之间的吞吐量差异变得微乎其微。这是因为在这些场景下，提示长度开始对性能产生主导作用。虽然 GUARANTEED_NO_EVICT 策略基于最大输出长度分配 KV 缓存，但提示的 KV 缓存大小在固定和动态数据集之间是相似的，因此浪费的内存开销变得可以忽略不计。结果是固定和动态基准测试的活动批量大小趋于一致，从而实现相似的吞吐量。
图 3 展示了固定和动态数据集中不同框架的平均运行批量大小。对于 vLLM，填充的柱状条代表解码迭代的平均运行批量大小，图案化的柱状条代表包括预填充迭代在内的所有迭代的平均运行批量大小。
vLLM 的调度策略类似于 TensorRT-LLM 的 MAX_UTILIZATION 策略（将在下一部分讨论）。因此，性能提升来自不同的因素。与 TensorRT-LLM 不同，vLLM 默认不支持混合批处理（除非使用 Chunked prefill），因此预填充和解码请求分别批处理。
在固定长度生成中，解码批量大小通常保持最大化，因为所有请求的迭代次数相同。然而，在动态数据集中，生成终止标记（EOS token）的请求会提前结束，导致剩余请求的解码批量大小减少。
同样，在动态数据集中，预填充批量大小（或针对被抢占请求的重新计算批量）会有所变化，相较于固定数据集，在更多的迭代中预填充批量较小。如图 3 所示，当考虑所有迭代的平均批量大小（包括预填充迭代）时，这种批量大小的减少更加明显。总体而言，TensorRT-LLM 在动态场景中的表现比 vLLM 更具弹性，因为它原生支持混合批处理。
Figure 4. TPOT comparison of Fixed and Dynamic benchmarks in each framework
图 4 展示了 TPOT 的趋势，揭示了一些值得注意的现象。正如之前的文章所讨论的，TPOT 通常与平均批量大小相关，因此可以预期随着序列长度的增长，TPOT 会下降，因为平均批量大小通常会缩小。
然而我们观察到 TPOT 随着输入序列长度的增长反而增加。这是因为较长的输入序列导致更大的 KV 缓存大小，从而增加了内存开销和注意力计算。减少的批量大小和增加的序列长度共同作用，导致了上述趋势。
另一个有趣的现象是，固定数据集的 TPOT 低于动态数据集。这可以归因于 vLLM 不支持混合批处理。在固定数据集中，所有请求的长度相同，使得预填充和解码迭代之间分离明确。然而，在动态数据集中，一些请求在同一解码批量中比其他请求更早结束生成。这为预填充调度提供了额外的时间预算，从而增加了其他等待批次的预填充迭代可能性。这种额外的预填充可能会降低动态数据集的平均 TPOT。
实验 #2：调度策略的影响
在第二个实验中，我们使用动态数据集评估了 TensorRT-LLM 的两种调度器策略（GUARANTEED_NO_EVICT 和 MAX_UTILIZATION）的性能。GUARANTEED_NO_EVICT 策略会为每个请求预分配 KV 缓存内存，确保已调度的请求在内存约束下不会被抢占。而 MAX_UTILIZATION 策略在输出生成期间按需分配 KV 缓存内存，每次迭代尽可能打包更多的请求，但在内存不足时可能会抢占部分请求。这种差异在动态输入中尤为显著，因为实际输出长度通常短于最大输出长度。
为了展示这一点，我们使用了 Dynamic-Sonnet 的 4K 子集，将最大输出长度从 1K 调整到 4K。此外，我们将 token ID 13（句号“.”的 token ID）设置为 EOS token，以尽早终止生成，从而进一步扩大最大输出长度与实际输出长度之间的差距。
图 5 展示了不同策略的吞吐量和平均运行批量大小。当最大输出长度为 1K 时，GUARANTEED_NO_EVICT 的吞吐量略高。此时，两种策略的平均批量大小相似，因为 GUARANTEED_NO_EVICT 分配的 KV 缓存能够支持请求直到生成提前终止。此外，MAX_UTILIZATION 可能因其复杂的调度功能（如非连续的 KV 缓存分配）带来额外的延迟开销，因此吞吐量略低于更简单的 GUARANTEED_NO_EVICT 策略。
然而，随着最大输出长度的增加，MAX_UTILIZATION 的吞吐量超过了 GUARANTEED_NO_EVICT，且性能差距不断扩大。这个趋势同样反映在平均运行批量大小上，MAX_UTILIZATION 在所有情况下的批量大小都更大。通过减少 KV 缓存内存使用，MAX_UTILIZATION 为更多请求批量处理释放了空间。总体而言，MAX_UTILIZATION 在动态场景中提供了更高的吞吐量，但需要谨慎应用，因为过度抢占可能在某些情况下降低吞吐量。
最终总结
本文比较了动态场景下的性能指标，并将其与固定场景的结果进行了对比。总体而言，我们观察到动态环境中性能下降，其中非确定性输出对性能的影响大于输入的动态性。这表明，要正确反映真实世界的推理环境，需要通过动态请求衡量性能。
| 对比框架 | TensorRT-LLM | vLLM |
|---|---|---|
| 调度策略 | - GUARANTEED_NO_EVICT：内存预分配，简单稳定，在短输出长度场景中效率更高。- MAX_UTILIZATION：按需分配内存，批量利用率更高，在长输出长度场景中表现优越，但抢占可能增加延迟。- 总体而言，MAX_UTILIZATION 在动态环境下吞吐量更高，但需平衡抢占开销。 | 默认不支持混合批处理，预填充和解码请求分开处理。动态场景中批量大小减少，性能表现较差，尤其是在请求间存在长度差异时。 |
| 动态场景下的表现 | 支持动态混合批处理，在动态请求中表现更为稳定。 | 不支持混合批处理，动态场景中需要分别处理预填充和解码批量，导致批量大小减少，整体吞吐量低于 TensorRT-LLM。 |
| TPOT（每个 token 处理时间） | - TPOT 随输入序列长度增加而上升，因较长序列带来更大的 KV 缓存和注意力计算开销。- 动态数据集的 TPOT 高于固定数据集，因为调度器能够更高效地插入预填充迭代，提高预填充时间利用率。 | - TPOT 受限于分批策略，在动态场景中可能进一步增加延迟。- 因无法动态优化预填充和解码的时间安排，动态场景中 TPOT 表现不如 TensorRT-LLM 高效。 |
| 优化建议 | 调度策略（如 MAX_UTILIZATION）需进一步优化，以减少抢占带来的延迟，同时提升动态环境下的吞吐量。 | 支持混合批处理是关键优化方向；需提升对动态请求的适配能力，以在实际应用场景中更高效地利用硬件资源。 |
| 现实场景考虑 | - 动态长度数据集更接近真实 LLM 使用场景，框架需优化以更好地应对动态工作负载。- 在动态环境下，MAX_UTILIZATION 调度策略能更好地适配实际需求，但需权衡内存抢占和性能的关系。 | 动态长度数据集对 vLLM 的挑战尤为显著，尤其是在需要平衡多请求的长度差异时。未来需要通过支持混合批处理等优化策略来提高其在动态环境中的表现。 |
参考资料
[1]dynamic_sonnet_llama3: https://huggingface.co/datasets/squeezebits/dynamic_sonnet_llama3
公众号后台回复“数据集”获取100+深度学习各方向资源整理
极市干货
点击阅读原文进入CV社区
收获更多技术干货
