vllm chunked-prefill性能评估

MachineCYL

已于 2024-12-26 09:20:47 修改

阅读量1.9k

点赞数 8

文章标签：人工智能 python 语言模型 nlp

于 2024-12-25 18:56:06 首次发布

本文链接：https://blog.csdn.net/u011590738/article/details/144725900

版权

一、问题说明

在使用vllm的过程中，我们发现大语言模型输出token过程中，偶尔会出现有较长时间的等待才吐出下一个token的问题。
通过查阅文档资料，发现这是由于vllm服务是会在一个服务实例中，即做prefill又做decode。但同一时间只能执行prefill、decode其中一个，并且执行prefill的优先级高于decode。所以在多并发情况下，会优先处理prefill而导致停滞decode，造成部分token会等待较长时间才输出的情况。以下面的例子说明一下：

假设最开始有A、B两个序列，他们都处在decode阶段。在A和B完成1次decode之后，来了C和D的两个请求。由于vllm是prefill优先的，所以它会先处理C和D的prefill，这就使得decode暂停了。等C和D的prefill完成了，A、B、C、D再同时做decode。
可以看到，这种情况下，A和B的第1次decode的第2次decode间隔的时间变长了，导致了A和B用户的等待。

chunked-prefill特性

chunked-prefill，是修改了传统的推理服务里，非prefill即decode的方法。让prefill和decode能同时放在一个batch里做推理。对于比较长的请求序列，它的prefill无法再一个batch里执行完，它会做chunk切割，分在多个batch里完成。所以叫做chunked-prefill。其实也可以看出来，原来一条序列不切分直接进行prefill，和现在把它拆成了多个chunk，那么每个chunk去计算时，肯定要去读前一个chunk的KV cache，会额外多出一些开销。所以会稍微影响到TTFT，但是考虑到它对TPOT/TBT的更多提升，这样的开销还是可以接受的。

近期vllm官方又更新了chunked-prefill的相关内容，所以我们打算测试评估一下。

二、chunked-prefill测试

测试环境

测试模型：Qwen2.5-32B-GPTQ-int4模型
机器资源：2张A800（80GB），设置--tensor-parallel-size=2。
vllm版本：0.6.5

评估指标

1、TTFT (Time To First Token)
TTFT 指的是从开始处理一个推理请求到生成第一个输出 token 所需的时间。这个指标衡量的是模型开始响应的速度，对于需要快速响应的应用场景非常重要，比如聊天机器人或实时翻译服务。
2、TPOT (Time Per Output Token)
TPOT 指的是生成每个输出 token 所需的平均时间。这个指标反映了模型在解码阶段的效率，即模型在生成序列中每个 token 时的速度。TPOT 可以反映模型在处理整个输出序列时的一致性。
3、TBT (Time Between Tokens)/ITL (Inference Token Latency)
TBT （vllm中称作ITL）指的是连续两个输出 token 生成之间的时间间隔。这个指标与 TPOT 类似，但更侧重于衡量 token 之间的生成速度，可以更细致地反映模型在生成序列时的流畅度。而上文提到的用户偶尔感觉较长时间的等待，主要就是反应在这个指标上。

测试说明

测试的代码是基于vllm 的benchmarks里的测试代码进行改造的。原本主要是输出具体计算指标，我们把具体数据也保存下来了。

本次测试主要是验证开启和关闭chunked-prefill对服务性能的影响，其他测试条件均保持一致。
通过设置不同的输入长度和输出长度、不同的请求速率、可以验证不同场景，推理服务的性能差异。并记录了相关的指标，统计成直方图，方便查看TBT、TPOT、TTFT的耗时分布和长尾情况。

具体的测试截图如下，先进行一些说明：每个截图包含2张图片，表示同一个指标（TBT/TTFT/TPOT等），在开启和关闭chunked-prefill特性的差异（左边是关闭chunked-prefill、右边是开启chunked-prefill）。同一张图片中，同一行有4列，分别表示不同请求速率的测试情况。

截图中每一行表示一个测试场景，例如：第二行的prefill-heavy的场景，每个请求的实际input_token=1017，实际output_token=16。
另外为了进行压测，又加入了第四行的prefill-heavy-Long场景（input_token=4090，output_token=32）、第五行的prefill-Decode-heavy场景（input_token=4090，output_token=512）。可以重点关注这两个场景的指标。

1、TBT/ITL指标

测试结果说明：
对比2张图片中，第四行、第四列的场景（input_token=4090，output_token=32，req_rate=2req/s），
● 在不开启chunked-prefill情况下，可以看到有84个token的输出耗时大于4s；而大于60s耗时的token也有12个。虽然比例不多，但这非常影响用户的体验。
● 在开启chunked-prefill情况下，基本上全部的token都在500ms以内返回。但是，我们也能看到，在350ms到450ms返回的token比例很高（接近90%），这也是因为它是prefill-heavy的场景，output_token较少，而且大多数是和prefill一起执行的，所以间隔比较长的这部分占比较高。我们可以对比右图的第五行、第四列的场景（开启chunked-prefill，input_token=4090，output_token=512，req_rate=2req/s），两个场景的差异主要是output_token，那么就可以看出来，在output_token较多的情况下。在50-100ms返回的token其实是占了70%，而350-650ms返回的token其实只占了20%。

2、TPOT指标