我想表达对此（vLLM）的惊叹。我刚刚安装它来测试，因为我想运行多个代理，而使用LMStudio时我一次只能运行1个请求。所以我希望能至少运行2个，一个用于协调代理，一个用于任务运行器。我使用的是RTX3090。我最终想使用Qwen2.5 32B Q4，但测试时我使用的是[Qwen2.5 - 7B - Instruct - abliterated - v2 - GGUF](https://huggingface.co/MaziyarPanahi/Qwen2.5 - 7B - Instruct - abliterated - v2 - GGUF/tree/main)（Q5_K_M，5.5gb）。是的，vLLM实验性地支持gguf。我启动AnythingLLM将其作为OpenAI API连接。我有3个请求以大约100t/s的速度运行，所以我想看看它能达到什么程度。我发现AnythingLLM只能有6个并发连接。但我也发现当你点击请求的“停止”按钮时，它会断开连接，但不会停止，服务器仍在处理。所以如果我刷新浏览器并点击重新生成，它会开始另一个请求。所以我一直这样做，然后我有了30个并发请求！我被震撼到了。它们的速度在250t/s - 350t/s。现在，30个并发请求远远超出我的需求，而且即使是300t/s，每个对话10t/s也有点慢。但我只需要2 - 3个，这可能是32B模型的极限。为了使每秒的令牌数达到最大，7B模型需要大约6 - 8个并发请求。我使用了特定的docker运行命令来运行vLLM和相关模型。然后我尝试使用KV Cache Q8，但它出问题了，模型变得非常愚蠢，甚至不如GPT - 1的水平。它还给出了FlashAttention - 2与Q8不兼容的错误，并提示添加环境变量来使用FLASHINFER，但使用后还是很糟糕，甚至更糟，只是一直重复“the”。所以我尝试了--kv - cache - dtype fp8_e4m3，它能输出大概1个句子然后就变得语无伦次。虽然启用缓存时有相关的性能数据。之后我尝试了llama.cpp，它与vLLM不同，需要指定GPU的层数和并发批处理数量。运行8个并发任务时速度约为230t/s。llama.cpp只给出单个请求的平均令牌数，而不是总平均数，所以我把单个请求的平均数加起来，虽然不太准确，但似乎在预期范围内。llama.cpp更好的地方在于KV缓存量化有效，使用时模型不会完全崩溃，看起来还可以。我只尝试了Q8，有相关的KV自我大小数据。最后我在llama.cpp中尝试了Qwen2.5 32B Q3_K_M，15gb，选择最大批处理为3，60K上下文长度（每个20K），使用KV Cache Q8占用8gb显存，差不多用完了我的VRAM。3个聊天同时进行时速度为30t/s，所以每个约10t/s。相比之下，在LMStudio中使用小得多的上下文长度单独运行时，单个聊天可以达到27t/s。
讨论总结
原帖作者分享了vLLM的测试情况，包括安装目的、测试环境、遇到的问题等。评论者们围绕这一话题展开了多方面的技术讨论，如vLLM与llama.cpp在各种性能指标、参数设置上的对比，不同量化格式对模型性能的影响，不同模型在处理缓存量化时的表现，还有关于特定模型的应用场景及性能等内容，整体讨论氛围较为理性、专注于技术交流。
主要观点
- 👍 提醒原帖作者在模型设置上要确保选择正确的参数
- 支持理由：确保模型正常运行的基本要求。
- 反对声音：原帖作者表示只有两个参数选择且效果不佳。
- 🔥 在llama.cpp中指定过多层数会导致内存不足崩溃，可通过多种方式调整来避免
- 正方观点：避免内存不足崩溃是优化性能的关键。
- 反方观点：无明显反对观点。
- 💡 exllamav2（tabbyapi）与exl配合使用会更快、更智能
- 解释：由评论者提出且有一定的使用经验支撑。
- 🌟 Kv缓存对qwen模型影响大
- 解释：基于对qwen模型的测试和使用观察。
- 🤔 批处理时vLLM及相关项目表现突出，但处理非常见模型时漏洞多
- 解释：根据评论者自身使用不同模型时的体验得出。
金句与有趣评论
- “😂 Make sure you’re picking the right one for the model you’re using.”
- 亮点：这是一个对原帖作者的善意提醒，也是模型设置中的基本要点。
- “🤔 if you specify too many layers, llama.cpp crashes with an out of CUDA memory error.”
- 亮点：明确指出llama.cpp在特定情况下会出现的问题，对使用者有警示作用。
- “👀 You can try exllamav2 (tabbyapi for example) with exl and it will be faster (including concurrent connections) and smarter.”
- 亮点：提供了一种可能提高性能的解决方案。
- “😎 Kv cache pretty much destroys qwen.”
- 亮点：简洁地表达了Kv缓存对qwen模型的重大影响。
- “💥 In my experience, llama.cpp is a little bit faster/lower latency for single requests. But vLLM is more total tps when you’re batching.”
- 亮点：清晰对比了llama.cpp和vLLM在不同请求模式下的性能差异。
情感分析
总体情感倾向为中性。主要分歧点在于不同模型或技术在不同场景下的性能表现，例如vLLM和llama.cpp在处理各种任务时的优劣比较。可能的原因是大家基于各自不同的使用场景、硬件条件以及对不同技术的理解和期望存在差异。
趋势与预测
- 新兴话题：可能会有更多关于如何优化不同模型在特定硬件上的性能，以及新的量化格式或技术的讨论。
- 潜在影响：对人工智能模型在实际应用中的性能优化有积极的推动作用，有助于开发者和使用者更好地选择适合自己需求的模型和技术。
详细内容：
标题：关于 vLLM 等模型的热门讨论引发关注
在 Reddit 上，一则关于 vLLM 的帖子引起了众多用户的热烈讨论。该帖子主要分享了作者在测试 vLLM 模型时的一系列经历，包括尝试不同的量化设置、对比不同模型和框架的性能等，获得了大量的关注，点赞数和评论数众多。
讨论的焦点主要集中在 vLLM 以及其他相关模型如 llama.cpp、exllamav2 等的性能表现、量化设置的效果以及在不同硬件条件下的运行情况。
有人表示：“Make sure you’re picking the right one for the model you’re using. I mean, you probably are but that’s the obvious thing that trips people up with that setting.” 强调了选择适合模型的设置的重要性。
还有用户分享道：“Corporate_Drone31 提到，如果指定的 GPU 层数过多，llama.cpp 会因 CUDA 内存不足而崩溃。如果指定的层数过少，则会损失一些性能。并且提到了一个有助于实验不同参数的优秀的 HuggingFace 工具。”
对于 vLLM 的量化设置，有人指出其存在一些问题，比如：“I suspect vLLM cache quantization is broken, but I haven’t tested it.” 但也有人表示 llama.cpp 的 kv 缓存量化效果较好。
同时，关于不同模型之间的差异，有观点认为：“MP3 是一种非常特定、标准化的编解码器。GGUF 不像编解码器，它更类似于一个容器格式，LLMs 并非标准化的。不同的模型架构会影响内存使用等方面。”
讨论中也存在一些共识，比如大家普遍认为在不同模型和设置的尝试中，需要不断调整和优化以达到最佳效果。
总之，这次关于 vLLM 等模型的讨论十分深入和丰富，为相关技术的探索和应用提供了有价值的参考和思考。
感谢您的耐心阅读！来选个表情，或者留个评论吧！