OctoAI使用vLLM作为基准，展示它们的速度。
| 单用户吞吐量 | 多用户吞吐量 | 令牌间延迟 |
|---|---|---|
|
|
|
它们的主要优化包括：
- 对模型进行FP8量化(目前我们只支持KV缓存)
- Nvidia TRT LLM的
CustomAllReduce内核 - CUDA图形
- 推测解码(感谢@cadedaniel提供！)
- 动态分割融合(A.K.A. 分块预填充，感谢@rkooo567提供！)
我的问题是，要达到性能相当，我们需要做些什么？
一些明确的事情包括：
- 使所有这些功能相互兼容
- 从TRT LLM
CustomAllReduce中学习什么 - 支持在FP8中执行模型
值得注意的问题包括：
7条答案
按热度按时间q8l4jmvw1#
@KuntaiDu正在创建我们自己的基准测试，用于真实世界模型和高端GPU。首先，我们需要了解当前vLLM的速度。公司可能使用旧版本的vLLM,或者不知道如何在vLLM中设置一些高级标志，导致其基准测试性能较差(他们有动力这样做 :) )。
pod7payv2#
这是一个很好的观点，我也在其他比较中注意到了这一点。
这些基准数据是否将在https://github.com/vllm-project/vllm/tree/main/benchmarks中提供？我希望该目录能稍微整理一下并进行泛化，以便它们既可以离线使用(就像今天大多数情况下一样),也可以在线使用(这将更有用)。
zlwx9yxi3#
你可以通过#5073追踪它。
ou6hu8tu4#
+1。这种基准测试很容易被欺骗，但这是我们以公平的方式自己进行比较的最佳方式。
mbzjlibv5#
ICYMI -他们在这个基准测试中使用了vLLM 0.3.3。
0ejtzxu16#
将所有这些功能相互兼容
有道理。目前，vLLM最大的问题是许多功能不能同时使用。例如，当基线(原始fp16)+ 自动前缀缓存 + 分块预填充 + int8 kv缓存 + awq + 推测解码 都被启用时，与仅使用**基线(原始fp16)**相比，将会有显著的优势。参考 #2614 (评论)
这里的主要问题是，在添加每个功能时，从设计和实现到审查，兼容性没有得到足够的关注。参考 InternLM/lmdeploy#1450 (评论)
与此同时，vLLM的优点也非常明显，更像是性能更高的 transformers 。在模型支持、不同的硬件后端支持和社区活动方面，它非常出色。
7vhp5slm7#
实际上，我们的团队在去年年初开始使用vLLM,大约是2023年7月。当时，我们还在2023年9月为W8A8和KV Cache Int8提交了PR #1112 。后来，为了便于审查，PR被分成了两部分 #1507#1508 。今年，我们还为W4A8提交了一个PR #5218 。
TensorRT LLM有一些闭源组件，如批处理管理器和注意力核，其可用性一般。LMDeploy TurboMind性能优秀，但支持的模型较少，例如，它缺乏对MOE模型的支持。可以说每个框架都有其优缺点。当时，我们结合了自己的业务需求。例如，我们在短期内没有使用MOE模型，因为我们的算法同事发现，在将SFT应用于模型后，短期内MOE的效果不如Dense模型(这是另一个主题)。
目前，许多初创公司撰写博客来展示他们的LLM推理框架更好，比如你提到的上述FireWorks AI 、FriendliAI 和OctoAI 。此时，他们会自然地选择社区中最受欢迎的vLLM,然后在测试环境和软件版本中构建有利于自己的场景。我认为这些性能比较博客意义不大，更多的是公关。