AI架构系列：vLLM, LMDeploy, MLC-LLM, TensorRT-LLM, and TGI的性能小实验 原创

训练大型语言模型以及微调的教程比比皆是，但关于在生产环境中部署它们并监控其活动的资料相对稀缺。上章节提到了未来云原生的AI是趋势，然而涉及到云原生会比较偏技术。而在此之前为了解决大模型部署量产的问题，社区也一直在探索，目前已有不少工具可用于这个领域。

另一方面，选择正确的推理后端为大型语言模型 （LLMs） 提供服务至关重要。不同的后端提供不同的服务LLMs方式，每种方式都有独特的功能和优化技术。它不仅确保了最佳的用户体验和最快的生成速度，而且还通过高Token生成率和资源利用率提高了成本效益。

在介绍往vLLM和TGI之后，恰好BentoML工程团队在BentoCloud上对Llama 3使用vLLM、LMDeploy、MLC-LLM、TensorRT-LLM和Hugging Face TGI的服务性能进行全面的基准测试。这里所有推理后端都遵循Apache 2.0 许可证。

1.实验背景

BentoML 工程团队在BentoCloud上对Llama 3使用vLLM、LMDeploy、MLC-LLM、TensorRT-LLM和Hugging Face TGI的服务性能进行全面的基准测试。这里使用两个关键指标进行评估：

• TTFT：测量从发送请求到生成第一个令牌的时间，以毫秒为单位记录。TTFT对于需要即时反馈的应用程序非常重要。更低的延迟可提高感知性能和用户满意度。<注意，这个过程为解码过程！>
• TGR：评估模型在解码过程中每秒生成的Token，以每秒令牌数为单位。Token生成率是模型处理高负载能力的指标。高的数值表明该模型可以有效地管理多个请求并快速生成响应，适用于高并发环境。

本次实验是在BentoCloud上单个A100 80GB GPU实例上使用Llama 3 8B和70B的4位量化<​​忘记量化的请查看链接！​​>模型进行了基准测试，涉及三个级别的推理负载（10、50 和 100 个并发用户）。

• vLLM: 0.4.2
• MLC-LLM: mlc-llm-nightly-cu121 0.1.dev1251 (No stable release yet)
• LMDeploy: 0.4.0
• TensorRT-LLM: 0.9.0 (with Triton v24.04)
• TGI: 2.0.4

2.指标解读

解读之前，小编温馨提醒，实验的结果仅供参考。毕竟这个实验是在特定的场景下实验。若配合其他的优化手段，结果可能大不一样，但是还是可以管中窥豹。先来看看Llama-3-8B的情况：

上面的指标TTFT数值是越低越好，而下面的指标TGR数值是越高越好

LMDeploy：在Token生成率方面提供最佳解码性能，100个用户每秒最多可处理4000 个Token。在10个用户中实现了一流的TTFT。尽管TTFT随着用户的增加而逐渐增加，但它的延时还是在可接受的范围。

MLC-LLM：解码性能略低，100个用户每秒约3500个令牌。然而随着时间的推进，TGR从运行基准测试5分钟后降低到每秒3100个Token。

vLLM：一流的 TTFT。但与LMDeploy和MLC-LLM相比，解码性能不太理想，每秒2300-2500个令牌类似于 TGI 和 TRT-LLM。

后面来看看Llama-3-70B 4位量化的情况：

LMDeploy：在为 100 个用户提供服务时，提供高达 700 个Token的生成率，同时在所有级别的并发用户中保持最低的TTFT。

TensorRT-LLM：在Token生成率方面表现出与LMDeploy相似的性能，并在低并发用户数量下保持低 TTFT。但是当并发用户数达到100 时，TTFT下滑厉害。

vLLM：始终表现出较低的TTFT，类似于在8B模型中观测到的。与 LMDeploy和TensorRT-LLM相比，Token生成率较低。

3.对比表格

下面对比表格从量化、模型和支持的硬件将物种大模型的服务端（运行大模型，对外提供服务）进行对比，其实也给读者提供决策的依据。在选择部署大模型的时候，可以先针对量化情况，基座模型支持度以及手头的硬件综合选择后端的服务，配合云原生进行产线部署。

当然除此之外还是要考虑这些服务是否有稳定版本，模型编译情况还有就是文档齐备性。

本文转载自 ​​鲁班模锤​​，作者： 庞德公