深度对比丨探索LLM（大模型）部署服务的七大框架差异
发布时间：2024年06月06日
本文旨在比较用于 LLM 推理和服务的不同开源库。我们将通过实际部署示例探讨它们的核心特性和优缺点。研究 vLLM、文本生成推理、OpenLLM、Ray Serve 等框架。
尽管LLM推理框架有很多，但每个框架都有其特定的目的。以下是需要考虑的一些关键点：
1.
当需要批处理和最大速度时，请使用vLLM 。
2.
3.
如果需要本机 HuggingFace 支持并且不打算为核心模型使用多个适配器，选择文本生成推理。
4.
5.
如果速度是优先考虑且计划在 CPU 上运行推理，可以考虑CTranslate2 。
6.
7.
如果要将适配器连接到核心模型并利用 HuggingFace 代理，可以选择OpenLLM ，特别是不仅仅依赖 PyTorch。
8.
9.
考虑使用Ray Serve来实现稳定的管道和灵活的部署。最适合更成熟的项目。
10.
11.
如果想在客户端（边缘计算）（例如 Android 或 iPhone 平台）本地部署 LLM，可以使用MLC LLM 。
12.
13.
如果已经拥有DeepSpeed库的经验并希望继续使用它来部署 LLM，可以使用DeepSpeed-MII 。
14.
1. vLLM
快速且易于使用的 LLM 推理和服务库。它的吞吐量比HuggingFace Transformers (HF)高 14 倍至 24 倍，比HuggingFace 文本生成推理 (TGI)高 2.2 倍 - 2.5 倍。
用法
o
离线批量推理
o
o
API服务器调用
o
核心特性
·
连续批处理- 迭代级调度，其中批大小由每次迭代确定。由于批处理，vLLM 可以在繁重的查询负载下正常工作。
·
·
PagedAttention— 注意力算法的灵感来自于操作系统中虚拟内存和分页的经典思想。这是模型加速的秘诀。
·
优点
·
文本生成的速度——到目前为止，使用 vLLM 进行推理是最快的可用选项。
·
·
高吞吐量服务——各种解码算法，包括并行采样、beam搜索等。
·
·
OpenAI 兼容的 API 服务器 — 如果使用 OpenAI API，则只需替换端点的 URL。
·
局限性
虽然该库提供了用户友好的特性和广泛的功能，但也存在一定的限制：
·
添加自定义模型：虽然可以合并自己的模型，但如果模型不使用与 vLLM 中现有模型类似的架构，则过程会变得更加复杂。例如，遇到了添加 Falcon 支持的Pull 请求，这个过程非常具有挑战性。
·
·
缺乏对适配器（LoRA、QLoRA 等）的支持：开源 LLM 在针对特定任务进行微调时具有重要价值。然而，在当前的实现中，没有单独使用模型和适配器权重的选项，这限制了有效利用此类模型的灵活性。
·
·
缺乏权重量化：有时LLM 可能不适合可用的 GPU 内存，因此减少内存消耗至关重要。
·
这是 LLM 推理最快的库。由于其内部优化，它的性能显着优于竞争对手。然而，它确实存在支持有限型号的弱点。
2. Text generation inference
用于文本生成推理的 Rust、Python 和 gRPC 服务器。在HuggingFace的生产中用于为LLM API 推理小部件提供支持。
用法
o
使用 docker 运行 Web 服务器
o
o
进行查询
o
核心特性
·
内置 Prometheus 指标 - 可以监控服务器负载并深入了解其性能。
·
·
使用flash-attention（和v2）和Paged Attention优化 Transformer 代码进行推理。值得一提的是，并非所有模型都内置对这些优化的支持。如果使用不太常见的架构可能是不支持的。
·
优点
·
所有依赖项都安装在 Docker 中 - 可以立即获得一个肯定可以在计算机上运行的现成环境。
·
·
对 HuggingFace 模型的本机支持 — 轻松运行自己的模型或使用任何 HuggingFace 模型中心。
·
·
控制模型推理：该框架提供了多种选项来管理模型推理，包括精度调整、量化、张量并行、重复惩罚等。
·
局限性
·
缺乏适配器支持 — 需要注意的是，尽管可以使用适配器部署 LLM，但目前还没有官方支持或文档。
·
·
从源代码编译的必要性（Rust + CUDA 内核）——对自定义的支持非常有挑战性。
·
·
文档不完整：所有信息都可以在项目的自述文件中找到。尽管它涵盖了基础知识，但遇到了必须在问题或源代码中搜索其他细节的情况。
·
3. CTranslate2
CTranslate2 是一个 C++ 和 Python 库，使用 Transformer 模型进行高效推理。
用法
o
首先，转换模型
o
进行查询
o
核心特性
·
在 CPU 和 GPU 上快速高效地执行— 得益于一系列内置优化：层融合、填充去除、批量重新排序、就地操作、缓存机制等。推理 LLM 速度更快，需要的内存更少。
·
·
动态内存使用情况——内存使用情况根据请求大小动态变化，同时由于 CPU 和 GPU 上的缓存分配器仍然满足性能要求。
·
·
多CPU架构支持——该项目支持x86-64和AArch64/ARM64处理器，并集成了针对这些平台优化的多个后端：Intel MKL、oneDNN、OpenBLAS、Ruy和Apple Accelerate。
·
优点
·
并行和异步执行——可以使用多个 GPU 或 CPU 核心并行和异步处理多个批次。
·
·
提示缓存- 模型在静态提示下运行一次，模型状态将被缓存并重用于将来使用相同静态提示的调用。
·
·
磁盘上的轻量级 — 量化可以使磁盘上的模型缩小 4 倍，同时将精度损失降至最低。
·
局限性
·
没有内置的 REST 服务器——尽管仍然可以运行 REST 服务器，但缺乏日志记录和监控功能等。
·
·
缺乏对适配器（LoRA、QLoRA 等）的支持。
·
对该库有丰富的博客文章，该库的众多优化令人印象深刻，其主要亮点是能够在 CPU 上执行 LLM 推理。
4. DeepSpeed-MII
在DeepSpeed的支持下，MII 使低延迟和高吞吐量推理成为可能。
用法
o
运行网络服务器
o
o
进行查询
o
核心特性
·
多个节点负载平衡 - 用于处理批量请求非常有效。负载均衡器在各个之间有节点之间有效分配传入请求，从而缩短应用程序响应时间。
·
·
非持久部署 - 一种更新不会永久应用于目标环境的方法。在资源效率、安全性、一致性和易于管理性至关重要的场景中，这是一个有价值的选择。它实现了更加受控和标准化的环境，同时减少了运营开销。
·
优点
·
不同的模型存储库——可通过多个开源模型存储库使用，例如 Hugging Face、FairSeq、EluetherAI 等。
·
·
量化延迟和成本降低——MII 可以显着降低非常昂贵的语言模型的推理成本。
·
·
本机和 Azure 集成 — Microsoft 开发的 MII 框架提供了与其云系统的出色集成。
·
局限性
·
缺乏官方版本——我花了几个小时才找到功能应用程序的正确提交。文档的某些部分已过时并且不再相关。
·
·
模型数量有限——不支持 Falcon、LLaMA 2 和其他语言模型。可以运行的模型数量有限。
·
·
缺乏对适配器（LoRA、QLoRA 等）的支持
·
该项目基于可靠的DeepSpeed库，该库在社区中赢得了声誉。如果寻求稳定性和久经考验的解决方案，MII 将是一个绝佳的选择。根据我的实验，该库表现出处理单个提示的最佳速度。尽管如此，我建议在将框架实施到系统中之前，先针对特定任务测试该框架在决定。
5. OpenLLM
用于在生产中操作大型语言模型 (LLM) 的开放平台。
用法
o
运行网络服务器
o
o
进行查询
o
核心特性
·
适配器支持 — 将多个适配器连接到仅一个已部署的 LLM。试想一下，可以仅使用一种模型来完成多项专门任务。
·
·
运行时实现 - 使用不同的实现：Pytorch ( pt)、Tensorflow ( tf) 或 Flax ( flax)。
·
·
HuggingFace 代理— 连接 HuggingFace 上的不同模型并使用 LLM 和自然语言对其进行管理。
·
优点
·
良好的社区支持——该库正在不断开发和添加新功能。
·
·
集成新模型 - 开发人员提供了有关如何添加自己的模型的指南。
·
·
量化 — OpenLLM 支持使用位和字节以及GPTQ进行量化。
·
·
LangChain 集成 — 可以使用 LangChian 与远程 OpenLLM 服务器交互。
·
局限性
·
缺乏批处理支持 - 对于大量消息流，这很可能成为应用程序性能的瓶颈。
·
·
缺乏内置的分布式推理 - 如果想在多个 GPU 设备上运行大型模型，需要额外安装 OpenLLM 的服务组件Yatai。
·
这是一个很好的框架，具有广泛的功能。它能够以最少的费用创建灵活的应用程序。虽然文档中可能未完全涵盖某些方面，但当深入研究此库时，可能会发现其附加功能中的惊喜。
6. Ray Serve
Ray Serve 是一个可扩展的模型服务库，用于构建在线推理 API。Serve 与框架无关，因此可以使用单个工具包来服务深度学习模型中的所有内容。
用法
o
运行网络服务器
o
o
进行查询
o
核心特性
·
监控仪表板和 Prometheus 指标— 可以使用 Ray 仪表板来获取 Ray 集群和 Ray Serve 应用程序状态的高级概述。
·
·
跨多个副本自动缩放- Ray 通过观察队列大小并做出缩放决策来添加或删除副本来适应流量峰值。
·
·
动态请求批处理——当模型使用成本昂贵并且希望最大限度地利用硬件时，这是必要的。
·
优点
·
广泛的文档——开发人员在这方面投入了时间并努力地进行文档创建。可以找到几乎每个用例的大量示例，这非常有帮助。
·
·
生产就绪——这是此列表中所有框架中最成熟的框架。
·
·
原生 LangChain 集成— 可以使用 LangChian 与远程 OpenLLM 服务器交互。
·
局限性
·
缺乏内置模型优化——Ray Serve 并不专注于 LLM，它是一个用于部署任何 ML 模型的更广泛的框架。必须自己进行优化。
·
·
进入门槛高——该库有时会出现过多的附加功能，这提高了进入门槛，使新来者难以浏览和理解。
·
如果需要最适合生产的解决方案，而不仅仅是深度学习，那么 Ray Serve 是一个不错的选择。它最适合可用性、可扩展性和可观察性非常重要的企业。此外，可以使用其庞大的生态系统进行数据处理、培训、微调和服务。最后，OpenAI、Shopify 和 Instacart 等公司都在使用它。
7. MLC LLM
LLM 机器学习编译 (MLC LLM) 是一种通用部署解决方案，使 LLM 能够利用本机硬件加速在消费设备上高效运行。
MLC LLM 的高级项目概念
用法
o
运行网络服务器
o
进行查询
o
核心特性
·
平台本机运行时——部署在用户设备的本机环境上，可能没有现成的 Python 或其他必要的依赖项。应用程序开发人员只需熟悉平台原生运行时即可将 MLC 编译的 LLM 集成到他们的项目中。
·
·
内存优化——可以使用不同的技术编译、压缩和优化模型，从而将它们部署在不同的设备上。
·
优点
·
JSON 配置中的所有设置 - 允许在单个配置文件中定义每个编译模型的运行时配置。
·
·
预构建的应用程序 - 可以为不同的平台编译模型：用于命令行的 C++、用于 Web 的 JavaScript、用于 iOS 的 Swift 和用于 Android 的 Java/Kotlin。
·
局限性
·
使用LLM模型的功能有限：不支持适配器、不能改变精度、没有令牌流等。该库主要专注于为不同设备编译模型。
·
·
仅支持分组量化——尽管这种方法已经显示出良好的结果，但其他量化方法（bitsandbytes和GPTQ）在社区中更受欢迎。社区很可能会更好地开发它们。
·
·
安装复杂——我花了几个小时才正确安装该库。它很可能不适合初学者开发人员。
·
如果需要在 iOS 或 Android 设备上部署应用程序，这个库正是所需要的。它允许快速、本地地编译模型并将其部署到设备。但是，如果需要高负载的服务器，不建议选择这个框架。
上述大模型部署框架有其各自的特点，在实际部署选择过程中，需要结合自身的业务场景选择，没有万法通的框架。
出自：https://mp.weixin.qq.com/s/VksqSGmz5_sxaQH_0wBojg
如果你想要了解关于智能工具类的内容，可以查看 智汇宝库，这是一个提供智能工具的网站。
在这你可以找到各种智能工具的相关信息，了解智能工具的用法以及最新动态。
一键生成营销文案 电商场景悉数覆盖