vllm [性能]:当SamplingParams.logprobs增加时,生成吞吐量大幅下降,

doinxwow  于 3个月前  发布在  其他
关注(0)|答案(1)|浏览(28)

建议改进性能

  • 无回复*

性能回归报告
模型:meta-llama/Meta-Llama-3-8B-Instruct
GPU:1x A6000
| SamplingParams.logprobs | vLLM==0.4.2的生成吞吐量(tokens/s) | vLLM==0.3.0的生成吞吐量(tokens/s) |
| ------------ | ------------ | ------------ |
| 100 | 37.76435 | 39.47888 |
| 1000 | 27.62177 | 38.71567 |
| 10000 | 9.62248 | 36.21264 |
| 20000 | 5.36203 | 35.83716 |
| len(tokenizer.vocab.keys()) | 1.00312 | 22.60807 |
| len(tokenizer.vocab.keys()) + fix post-processing | 6.03333 | N.A. |

关于性能的杂项讨论
在我的项目中,我有一个vLLM服务器,在推理过程中,我需要获取每个生成标记的所有对数概率,因为我需要进行进一步的后处理/采样。获取所有对数概率并没有导致明显的生成吞吐量下降,但自从迁移到vLLM==0.4.1以来变得尤为明显。
在vllm==0.4.1和0.4.2中,当 SamplingParams.logprobs 增加时,生成吞吐量会大幅降低。在a6000上使用 meta-llama/Meta-Llama-3-8B-Instruct 和 engine_args.max_logprobs == sampling_params.logprobs == len(tokenizer.vocab.keys()) (llama-3的128256)时,吞吐量可以降至1 token/s。而在项目中的前固定版本v0.3.0(之前的版本)中,这种速率下降没有那么大。
经过调查,推理过程中似乎有两个主要的瓶颈:

  • 在后处理阶段,这个方法中解码速度奇慢。当 sampling_params.logprobs == len(tokenizer.vocab.keys()) 时,平均每个标记需要0.7秒。在我的实验中,我将解码限制在基于logprobs的前20个标记上,类似于OpenAI的Chat Completion Request,其中 top_logprobs 有上限为20,这将吞吐量提高到了6.03333 tokens/s。你认为我们应该实现仅针对前n个的解码逻辑吗?如果这是你想要的,我可以为此发起一个PR。
  • sampling_params.logprobs 较大时,模型执行变得缓慢且不稳定。我测量了完成此函数所需的时间,它在某些标记上不稳定,有时会花费0.3-0.5秒而不是正常的“正常”时间(约0.11秒)。我不知道这是什么原因。你们有人遇到过这种情况吗?
self.model_executor.execute_model_async: 0.2736055850982666
self.model_executor.execute_model_async: 0.2578315734863281
self.model_executor.execute_model_async: 0.2712900638580322
self.model_executor.execute_model_async: 0.11722660064697266
self.model_executor.execute_model_async: 0.28998589515686035
self.model_executor.execute_model_async: 0.11808204650878906
self.model_executor.execute_model_async: 0.30967116355895996
self.model_executor.execute_model_async: 0.11808013916015625
self.model_executor.execute_model_async: 0.34619808197021484
self.model_executor.execute_model_async: 0.11945867538452148
self.model_executor.execute_model_async: 0.11967015266418457
self.model_executor.execute_model_async: 0.4465758800506592
self.model_executor.execute_model_async: 0.12009191513061523
self.model_executor.execute_model_async: 0.11814165115356445
self.model_executor.execute_model_async: 0.11848926544189453
self.model_executor.execute_model_async: 0.43151330947875977
self.model_executor.execute_model_async: 0.12377119064331055
self.model_executor.execute_model_async: 0.11845278739929199
self.model_executor.execute_model_async: 0.11834073066711426
self.model_executor.execute_model_async: 0.5058283805847168
self.model_executor.execute_model_async: 0.11896276473999023
self.model_executor.execute_model_async: 0.11865472793579102

您当前的环境(如果您认为有必要)

The output of `python collect_env.py`
vaqhlq81

vaqhlq811#

我刚刚意识到在SamplingParams类中有一个detokenize属性,目前仅在引擎级别暴露。这可以帮助我解决我的用例的第一个瓶颈。然而,我仍在努力调查瓶颈2的原因。如果你知道问题的原因或发现了它,请告诉我!

相关问题