原文towardsdatascience.com/running-large-language-models-privately-a-comparison-of-frameworks-models-and-costs-ac33cfe3a462?sourcecollection_archive---------0-----------------------#2024-10-30框架、模型与成本比较https://medium.com/robert.corwin?sourcepost_page---byline--ac33cfe3a462--------------------------------https://towardsdatascience.com/?sourcepost_page---byline--ac33cfe3a462-------------------------------- Robert Corwin·发布于Towards Data Science ·15 分钟阅读·2024 年 10 月 30 日–Robert Corwin首席执行官奥斯汀人工智能公司David Davalos机器学习工程师奥斯汀人工智能公司2024 年 10 月 24 日大型语言模型LLM迅速改变了技术格局但安全问题依然存在尤其是将私人数据发送给外部第三方。在这篇博客文章中我们深入探讨了将 Llama 模型本地和私人部署的选项也就是说在个人计算机上运行。我们成功在本地运行了 Llama 3.1并调查了不同版本和框架下的速度、功耗以及整体性能等关键方面。无论你是技术专家还是仅仅对相关内容感到好奇你都会从本地 LLM 部署中获得一些见解。对于快速概览不懂技术的读者可以跳过详细内容查看总结表格而具备技术背景的读者可能会更喜欢深入了解具体工具及其性能。除非另有说明否则所有图片均由作者提供。作者和奥斯汀人工智能公司其雇主与本文提到的任何工具或使用的工具没有任何关系。关键点运行 LLMLLM 模型可以通过社区中广泛使用的工具和框架下载并在私人服务器上运行。虽然运行最强大的模型需要相当昂贵的硬件但较小的模型可以在笔记本电脑或台式计算机上运行。隐私与可定制性在私人服务器上运行 LLM 可以提供更高的隐私保护并对模型设置和使用政策拥有更大的控制权。模型大小开源 Llama 模型有多种尺寸。例如Llama 3.1 提供 8 亿、70 亿和 405 亿参数版本。 “参数”大致定义为网络中某个节点上的权重。更多的参数会增加模型性能但也会增加内存和磁盘的占用。量化量化通过将权重“舍入”到更少的有效数字从而节省内存和磁盘空间——这以牺牲精度为代价。鉴于 LLM 中参数的庞大数量量化对于减少内存使用和加速执行非常有价值。成本本地实现通过参考 GPU 能耗展示了与基于云的解决方案相比的成本效益。隐私和可靠性作为动机在我们之前的文章中我们探讨了 LLM 背后的关键概念以及如何利用Langchain等框架创建定制化的聊天机器人或工具见图 1。在这样的方案中虽然可以通过使用合成数据或混淆来保护数据但我们仍然需要将数据发送给第三方而且无法控制模型的任何变化、政策或甚至可用性。一个解决方案是直接在私有服务器上运行 LLM见图 2。这种方式可以确保完全的隐私并减少对外部服务提供商的依赖。实现私有化 LLM 时的关注点包括成本、电力消耗和速度。在本次实验中我们通过改变 1.框架工具和 2.量化程度运行 LLama 3.1并比较框架的易用性、运行时的速度表现以及电力消耗。理解这些权衡对任何希望在保持数据和资源控制的同时充分发挥 AI 潜力的人来说都至关重要。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/4086a3837bbbe117393bc836e2bf9bb6.png图 1展示一个典型的后端设置示意图用于聊天机器人或工具其中 ChatGPT或类似模型作为自然语言处理引擎运行。此设置依赖于提示工程来自定义响应。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/b7f1e437550e19bfc9ca68a0e1549779.png图 2完全私有的后端配置示意图所有组件包括大型语言模型均托管在安全服务器上从而确保完全的控制和隐私。量化与 GGUF 文件在深入探讨我们所探索的工具之前首先让我们讨论一下量化和GGUF格式。量化是一种通过将权重和偏差从高精度浮动点值转换为低精度表示来减少模型大小的技术。考虑到 LLM 拥有庞大的参数量这种方法对它们特别有利。例如Llama 3.1 的最大版本包含惊人的 4050 亿个参数。量化可以显著减少内存使用和执行时间使这些模型在各种设备上运行时更高效。有关量化类型的深入解释和命名法请查看这个很好的介绍。概念性概述也可以在这里找到。GGUF格式用于存储 LLM 模型并且最近因分发和运行量化模型而受到广泛欢迎。它经过优化能够快速加载、读取和保存。与仅存储张量的格式不同GGUF 还以标准化方式存储模型元数据使得框架更容易支持此格式甚至将其作为标准格式采用。分析的工具和模型我们探索了四个工具来本地运行 Llama 模型HuggingFace 的 transformers 库和HubvLLMllama.cppOllama我们的主要关注点是 llama.cpp 和 Ollama因为这些工具允许我们直接、迅速且高效地部署模型。具体来说我们探索了它们的速度、能源成本和整体性能。对于模型我们主要分析了量化后的 8B 和 70B 版本的 Llama 3.1因为它们在合理的时间范围内运行。初步印象与安装HuggingFaceHuggingFace 的 transformers 库和 Hub 在社区中广为人知并被广泛使用。它们提供了多种模型和工具使其成为许多开发者的热门选择。一旦环境配置好并安装了 Python它的安装通常不会导致大问题。最终HuggingFace 的最大优势在于它的在线 Hub允许轻松访问来自许多不同提供者的量化模型。另一方面直接使用 transformers 库加载模型尤其是量化模型还是相当棘手的。默认情况下该库似乎会直接对模型进行反量化占用了大量的 RAM导致在本地服务器上运行时变得不可行。尽管 Hugging Face 支持 4 位和 8 位量化与去量化并且使用bitsandbytes我们的初步印象是仍然需要进一步优化。高效推理可能并不是它的主要重点。尽管如此Hugging Face 提供了出色的文档、庞大的社区以及强大的模型训练框架。vLLM类似于 Hugging FacevLLM 可以在正确配置的 Python 环境中轻松安装。然而对 GGUF 文件的支持仍然处于高度实验阶段。尽管我们能够快速设置运行 8B 模型但超出这个规模的扩展却证明是具有挑战性的尽管有着出色的文档支持。总体而言我们认为 vLLM 具有很大的潜力。然而我们最终选择了 llama.cpp 和 Ollama 框架因为它们在兼容性和效率上更为直接。公平地说这里本可以进行更深入的调查但考虑到我们在其他库中取得的即时成功我们选择专注于它们。Ollama我们认为 Ollama 非常棒。我们的初步印象是它是一个适合用户本地推理 Llama 模型的工具具有即插即用的易用性。为 Mac 和 Linux 用户安装它非常简单Windows 版本目前处于预览阶段。Ollama 会自动检测硬件并在 CPU 和 GPU 之间无缝管理模型卸载。它还具备自己的模型库自动下载模型并支持 GGUF 文件。尽管其速度略逊于 llama.cpp但即便在仅配有 CPU 的系统和笔记本电脑上也能良好运行。快速入门安装后运行ollama run llama3.1:latest将直接从命令行加载最新的 8B 模型进行对话模式。一个缺点是定制模型在某些情况下可能有些不切实际尤其是在高级开发中。例如即使是调整温度也需要创建一个新的聊天机器人实例而这个实例又需要加载一个已安装的模型。虽然这只是一个小小的不便但它确实有助于在一个文件中设置定制化的聊天机器人 —— 包括其他参数和角色。总体而言我们认为 Ollama 是一个有效的本地工具模仿了云服务的一些关键功能。值得注意的是Ollama 作为服务运行至少在 Linux 系统上它提供了方便且简单的命令来监控当前运行的模型以及它们被卸载到何处并且可以在需要时立即停止这些模型。社区面临的一个挑战是配置某些方面例如模型存储位置这需要具备一定的 Linux 系统技术知识。虽然这对最终用户可能不会构成问题但它可能会稍微影响该工具在高级开发中的实用性。llama.cpp在这次分析中llama.cpp 成为了我们最喜爱的工具。正如它的 仓库 中所述它旨在通过最小的配置运行大规模语言模型并提供领先的性能。像 Ollama 一样它支持在 CPU 和 GPU 之间卸载模型尽管这不是开箱即用的功能。要启用 GPU 支持您必须使用适当的标志进行编译——具体来说是GGML_CUDAon。我们建议使用最新版本的 CUDA 工具包因为旧版本可能不兼容。该工具可以通过从仓库拉取并编译作为独立工具安装这为运行模型提供了一个方便的命令行客户端。例如您可以执行llama-cli -p you are a useful assistant -m Meta-Llama-3-8B-Instruct.Q8_0.gguf -cnv。这里最后一个标志可以直接从命令行启用对话模式。llama-cli 提供了各种定制选项例如调整上下文大小、重复惩罚和温度它还支持 GPU 卸载选项。类似于 Ollamallama.cpp 也提供了 Python 绑定可以通过pip install llama-cpp-python安装。这个 Python 库允许进行显著的定制使得开发者可以轻松地根据特定客户需求调整模型。然而正如独立版本一样Python 绑定也需要使用适当的标志进行编译以启用 GPU 支持。一个小缺点是该工具尚不支持自动的 CPU-GPU 卸载。相反用户需要手动指定将多少层卸载到 GPU 上剩余的部分由 CPU 处理。虽然这需要一些微调但这一步骤直接且易于管理。对于拥有多个 GPU 的环境如我们所使用的llama.cpp 提供了两种分割模式行模式和层模式。在行模式下一个 GPU 处理小型张量和中间结果而在层模式下层被划分到多个 GPU 上。在我们的测试中这两种模式提供了相似的性能请参见下面的分析。我们的分析►从现在起结果仅涉及 llama.cpp 和 Ollama。我们使用 Ollama 和 llama.cpp 对 70B 和 8B Llama 3.1 模型的速度和功耗进行了分析。具体来说我们研究了在 Quant Factory 中提供的各种量化方式下每个模型每个 token 的速度和功耗。为了进行此分析我们开发了一个小型应用程序在选择工具后评估模型。在推理过程中我们记录了诸如速度每秒令牌数、生成的总令牌数、温度、GPU 上加载的层数以及响应的质量评分等指标。此外我们还测量了模型执行期间 GPU 的功耗。使用了一个脚本通过nvidia-smi在每生成一个令牌后立即监测 GPU 的功耗。推理结束后我们根据这些读数计算了平均功耗。由于我们专注于能够完全适应 GPU 内存的模型因此只测量了 GPU 的功耗。此外为了确保不同输出大小的情况实验使用了多种提示语因此数据涵盖了各种场景。硬件和软件配置我们使用了一台相当不错的服务器具备以下特点CPU: AMD Ryzen Threadripper PRO 7965WX 24 核心 48x 5.362GHz。GPU:2xNVIDIA GeForce RTX 4090。RAM: 515276MiB-操作系统Pop 22.04 jammy。内核x86_64 Linux 6.9.3–76060903-generic。这套配置的零售成本大约为 15,000 美元。我们选择了这样的配置因为它是一台不错的服务器虽然无法与配备 8 个以上 GPU 的专用高端 AI 服务器相比但它仍然非常实用并且能够代表我们许多客户可能选择的配置。我们发现许多客户在一开始不愿意投资高端服务器而这套配置在成本和性能之间达到了良好的折衷。速度首先让我们关注速度。下面我们展示了几个箱形图这些箱形图展示了不同量化方式下的速度数据。每个模型的名称以其量化级别开头例如“Q4”表示 4 位量化。再次强调较低的量化级别会更多地进行舍入减小模型的大小和质量但提高速度。►技术问题 1箱形图的提醒箱形图展示了中位数、第一个和第三个四分位数以及最小值和最大值。图中的胡须延伸到不被视为离群值的最极端数据点而离群值会单独绘制。离群值被定义为落在 Q1 − 1.5 × IQR 和 Q3 1.5 × IQR 之外的数据点其中 Q1 和 Q3 分别表示第一个和第三个四分位数。四分位距IQR计算公式为 IQR Q3 − Q1。llama.cpp以下是针对 llama.cpp 的图表。图 3显示了在QuantFactory中可用的所有 70B 参数的 Llama 3.1 模型的结果而图 4则展示了一些 8B 参数的模型您可以在这里找到这些模型。70B 模型可以将最多 81 层卸载到 GPU 上而 8B 模型最多可卸载 33 层。对于 70BQ5 量化及更细的量化方式无法完全卸载所有层。每种量化类型后面括号内包含了卸载到 GPU 上的层数。如预期粗量化类型提供了最佳的速度性能。由于行分割模式的表现相似这里我们专注于层分割模式。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/dbb2c0ec9178da55140f4e44e00d4d4f.png图 3在 llama.cpp 中使用层分割模式运行的 Llama 3.1 模型参数为 70B。如预期粗量化提供了最佳的速度。卸载到 GPU 上的层数在每种量化类型旁边的括号中显示。使用 Q5 及更细量化的模型无法完全适配 VRAM。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/ec621be986a8433692e2383f2b307f51.png图 4在 llama.cpp 中使用层分割模式运行的 Llama 3.1 模型参数为 8B。在这种情况下所有量化类型下模型均能适应 GPU 内存粗量化类型提供了最快的速度。请注意高速事件为离群值而总体趋势则在 Q2_K 的情况下约为每秒 20 个 token。关键观察在推理过程中我们观察到了一些高速事件尤其是在 8B Q2_K 情况下这时收集数据并理解其分布非常关键因为这些事件实际上是相当罕见的。如预期粗量化类型提供了最佳的速度性能。这是因为模型大小被缩减从而实现了更快的执行速度。关于 70B 模型未能完全适配 VRAM 的结果必须谨慎解读因为使用 CPU 可能会造成瓶颈。因此在这些情况下报告的速度可能不是模型性能的最佳表现。Ollama我们对 Ollama 进行了相同的分析。图 5显示了 Ollama 自动下载的默认 Llama 3.1 和 3.2 模型的结果。除了 405B 模型外所有模型都可以适配 GPU 内存。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/5cf70861d011baf06d6986701b776bdd.png图 5在 Ollama 下运行的 Llama 3.1 和 3.2 模型。这些是使用 Ollama 时的默认模型。所有 3.1 模型——特别是 405B、70B 和 8B标记为“latest”——使用 Q4_0 量化而 3.2 模型使用 Q8_01B和 Q4_K_M3B量化。关键观察我们可以比较 Ollama 和 llama.cpp 中的 70B Q4_0 模型Ollama 的速度略慢。同样8B Q4_0 模型在 Ollama 下的运行速度较其在 llama.cpp 中的对应模型慢且差异更加明显——llama.cpp 平均每秒处理多出约五个 token。已分析框架总结► 在讨论功耗和租用性之前让我们总结一下迄今为止分析的框架。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/4523dc3a8ecb6b331bbae7feb7ad5a9e.pnghttps://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/8cf1f9a4e23b4ddf59621e747fe2c680.png功耗与租用性该分析对于将所有层加载到 GPU 内存中的模型尤为相关因为我们只测量了两块 RTX 4090 显卡的功耗。然而需要注意的是测试中使用的 CPU 具有TDP 350 W这提供了其在最大负载下的功耗估计。如果整个模型被加载到 GPU 上CPU 的功耗可能接近空闲状态。为了估算每个 token 的能耗我们使用以下参数每秒 token 数NT和两块 GPU 的功率消耗P单位为瓦特。通过计算 P/NT我们得到每个 token 的能耗单位为瓦秒。将其除以 3600得到每个 token 的能耗单位为 Wh这通常是更常用的参考单位。llama.cpp以下是 llama.cpp 的结果。图 6展示了 70B 模型的能耗而图 7则侧重于 8B 模型。这些图表展示了每种量化方式的能耗数据图例中显示了平均值。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/47545ef2848a549f6011535a1d58f92d.png图 6在 llama.cpp 下针对 70B 参数的 Llama 3.1 模型的各种量化方式每个 token 的能耗。展示了行分割和层分割模式。结果仅适用于将所有 81 层加载到 GPU 内存中的模型。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/efa6856ace45a7e11318c546c90b8f7f.png图 7在 llama.cpp 下针对 8B 参数的 Llama 3.1 模型的各种量化方式每个 token 的能耗。展示了行分割和层分割模式。所有模型的平均能耗相似。Ollama我们还分析了 Ollama 的能耗。图 8展示了 Llama 3.1 8BQ4_0 量化和 Llama 3.2 1B 与 3B分别为 Q8_0 和 Q4_K_M 量化的结果。图 9展示了 70B 和 405B 模型的单独能耗二者均采用 Q4_0 量化。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/672d7536032b24286d90785d4affa630.png图 8在 Ollama 下Llama 3.1 8BQ4_0 量化和 Llama 3.2 1B 与 3B 模型分别为 Q8_0 和 Q4_K_M 量化的每个 token 能耗。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/056b3f9d748ce01c0acfc7af26168536.png图 9Llama 3.1 70B左和 Llama 3.1 405B右每个 token 的能耗二者均在 Ollama 下使用 Q4_0 量化。成本总结我们不会逐个讨论每个模型而是将重点放在 llama.cpp 和 Ollama 之间可比的模型以及 llama.cpp 下使用 Q2_K 量化的模型因为它是这里探索的最粗糙量化方式。为了更好地了解成本我们在下表中展示了每百万生成 token1M的能耗估算和美元成本。该成本是根据德克萨斯州的平均电价计算的电价为每千瓦时$0.14具体参考此来源。作为参考当前GPT-4o 的定价至少为每百万 token $5 USD而 GPT-o mini 则为每百万 token $0.3 USD。llama.cpphttps://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/dfbcafd4499fb5354d8e5832413108af.pngOllamahttps://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/6d75da0086d99efe5cb4edddfb50abba.png关键观察使用 Llama 3.1 70B 模型与 Q4_0 时llama.cpp 与 Ollama 之间的能耗差异不大。对于 8B 模型llama.cpp 的能耗高于 Ollama。请注意这里所展示的成本可以看作是运行模型的“基本成本”的下限。其他成本如操作、维护、设备成本和利润并未包含在此分析中。估算结果表明相较于云服务在私人服务器上运行 LLM大型语言模型可能更具成本效益。特别是Llama 8B 与 GPT-45o mini 以及 Llama 70B 与 GPT-4o 模型的比较在合适的情况下似乎是一个潜在的好选择。►技术问题 2成本估算对于大多数模型每百万个 token 的能耗估算及其变异性通过“中位数 ± 四分位距IQR”的方式给出其中 IQR 代表四分位距。只有对于 Llama 3.1 8B Q4_0 模型我们采用“均值 ± 标准差STD”的方式其中 STD 代表标准差。这些选择并非随意作出的除了 Llama 3.1 8B Q4_0 模型外所有模型都存在异常值使得中位数和 IQR 在这些情况下是更为稳健的估算器。此外这些选择还有助于防止成本出现负值。在大多数情况下当两种方法得出相同的中心趋势时它们提供的结果非常相似。最终结论https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/55c35bbe1cca9419622b9aa1539389d8.png图片来自 Meta AI对不同模型和工具的速度与功耗分析仅仅是更广泛图景的一部分。我们观察到轻量级或高度量化的模型通常在可靠性上表现不佳随着聊天历史的增加或任务变得重复幻觉现象变得更为频繁。这并不意外——较小的模型无法捕捉到较大模型的复杂性。为了解决这些限制像重复惩罚和温度调整等设置可以改善输出。另一方面像 70B 这样的大型模型始终保持强劲的性能并且幻觉现象极少。然而由于即便是最大的模型也不完全没有不准确性负责任和可信赖的使用往往需要将这些模型与额外的工具如 LangChain 和向量数据库结合使用。尽管我们在这里没有探索特定任务的表现但这些整合对于减少幻觉现象和增强模型可靠性至关重要。总之将大型语言模型LLMs部署在私有服务器上可以为大型语言模型作为服务LLMs as a service提供一个具有成本优势和定制化机会的竞争性替代方案。私有服务器和基于服务的选项各有其优点在Austin Ai我们专注于实现符合您需求的解决方案无论是利用私有服务器、云服务还是混合方案。