为了账号安全,请及时绑定邮箱和手机立即绑定

在本地服务器上私密运行大型语言模型

框架、模型和成本的对比

首席罗伯特·科温,奥斯汀AI公司

大卫·达瓦洛斯,ML工程师,来自奥斯汀AI公司

10月24日,2024年

大型语言模型(LLM)已经迅速改变了技术格局,但安全问题仍然存在,尤其是向外部第三方发送私人数据时。在这篇博客文章中,我们将探讨在本地和私密地部署Llama模型的选项,也就是说,在自己的电脑上。我们让Llama 3.1在本地运行,并研究关键方面,如速度、功耗以及不同版本和框架的整体性能。无论您是技术专家还是仅仅对本地部署LLM感兴趣,您都会发现有关本地部署LLM的见解。非技术读者可以跳到我们的摘要表获取快速概览,而具有技术背景的读者可能会欣赏我们对特定工具及其性能的深入探讨。

所有图片均为作者提供,除非另有注明。作者及其雇主Austin AI(Austin Artificial Intelligence的简称)与本文中提到或使用的所有工具均无关联。

要点:

运行大型语言模型 (LLMs): 可以使用在社区中广泛提供的工具和框架,在私人服务器上下载并运行LLM模型。虽然运行最强大的模型需要昂贵的硬件,但较小的模型则可以在笔记本电脑或台式机上运行。

隐私和自定义: 在私有服务器上运行LLM可以提供更强的隐私保障,并且可以更好地控制模型设置和使用政策。

模型大小: 开源的Llama模型有多种大小。比如,Llama 3.1 有80亿、70亿和4050亿参数的版本。一个“参数”大致可以理解为网络中一个节点的权重值。更多的参数会提升模型性能,但也会增加模型在内存和磁盘上的占用。

量化: 量化通过将权重“舍入”到较少的有效数字来压缩内存和磁盘空间——这一点以牺牲精度为代价。鉴于大型语言模型拥有大量的参数,量化在减少内存使用和提高运行速度方面非常有价值。

成本: 本地实施参考GPU的能耗,显示出比基于云的解决方案更省钱。

隐私和可靠性作为动力

在我们之前的一篇文章中,尽管我们探讨了大型语言模型(LLM)背后的关键概念,以及如何利用框架如Langchain(见图1)来创建定制化的聊天机器人或工具,但在这些方案中,虽然可以通过使用合成的数据或数据混淆来保护数据,但我们仍然需要将数据发送给第三方,无法控制模型、政策或其可用性的任何变动。一个解决方案是在私有服务器上运行一个LLM(见图2)。这种方法确保完全的隐私,并减少了对外部服务提供商的依赖。

关于私部署LLMs的担忧主要集中在成本、能耗和速度。在这个练习中,运行LLama 3.1,同时调整1. 框架(工具)和2. 量化的级别,并比较这些框架的易用性、运行速度和能耗。理解这些取舍对于希望在保持对数据和资源控制的同时充分利用AI潜力的任何人来说都至关重要。

图1 图示一个典型的聊天机器人或工具的后端设置,其中比如ChatGPT这样的模型充当自然语言处理模块。这个设置依赖于通过设计提示来定制回复。

图2:完全私有后端配置图,所有组件,包括大型语言模型,都在安全服务器上托管,确保完全的控制和隐私保障。

官方量化和GGUF文件

在详细介绍我们探索的工具之前谈一谈,让我们先讨论一下量化和_GGUF_格式。

量化是一种通过将权重和偏差从高精度的浮点数转换为低精度表示,来减小模型大小的技术。由于LLMs具有庞大的参数数量,这种方法对它们尤其有益。例如,Llama 3.1的最大版本包含惊人的4050亿个参数(约4050亿,具体数字可能略有不同)。量化可以显著减少内存使用和执行时间,使这些模型更高效地在各种设备上运行。有关量化的详细解释和术语,请参阅此优秀介绍。您还可以在此处找到概念性概述

_GGUF_格式用来存储大型语言模型(LLM),并且最近因为分发和运行量化模型而变得流行。它被优化为快速加载、读取和保存。与仅支持张量的格式不同的是,GGUF还以标准化方式存储模型元数据,使得框架更容易支持这种格式,甚至将其作为标准。

我们分析的工具和模型

我们尝试了四种工具来本地运行Llama模型。

我们主要关注的是 llama.cpp 和 Ollama 这两个工具,因为这些工具使我们能够快速且高效地直接部署模型,无需额外配置。具体来说,我们研究了它们的速度、能耗以及综合性能。对于模型,我们主要分析了 8B 和 70B 量化版本的 Llama 3.1,因为它们能够在合理的时间内运行。

初次印象和安装
HuggingFace

HuggingFace的transformers库和Hub在社区中广为人知且被广泛使用。它们提供了一系列模型和工具,因此成为许多开发者的首选工具。一旦用Python设置了合适的环境,其安装通常不会遇到大的问题。最终,HuggingFace的最大优势在于其在线Hub,它允许从许多不同的提供商轻松访问量化模型。另一方面,直接使用transformers库加载模型,尤其是量化模型,则相当棘手。开箱即用时,该库似乎直接对模型进行去量化,需要大量的RAM,这使得在本地服务器上运行变得不可行。

尽管 Hugging Face 支持 4 位和 8 位 量化和反量化的功能,并且可以通过 bitsandbytes 实现,但我们最初的印象是,可能还需要进一步优化。高效推理似乎并不是它的主要目标。不过,Hugging Face 提供了出色的文档支持,拥有庞大的社区,并且为模型训练提供了强大的框架支持。

vLLM

与 Hugging Face 类似,vLLM 在配置良好的 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的C++文件)

在这次分析中,llama.cpp 成为了我们最喜欢的工具。如其仓库所述,它是为了以最小的设置和尖端性能运行大语言模型而设计的。和 Ollama 一样,它支持在 CPU 和 GPU 之间卸载模型,但这项功能需要手动启用。要使用 GPU 支持,您需要在编译时设置 GGML_CUDA=on 标志。我们建议使用最新版本的 CUDA 工具包,以确保兼容性。

该工具可以通过从仓库拉取并编译来作为独立工具安装,这提供了一个方便的命令行界面来运行模型。例如,可以使用命令 llama-cli -p '你是一个有用的助手' -m Meta-Llama-3-8B-Instruct.Q8_0.gguf -cnv。在这里,最后一个标志直接通过命令行开启对话模式。llama-cli 提供了多种自定义选项,例如调整上下文大小、重复惩罚和温度,还支持 GPU 卸载功能。

类似于Ollama,llama.cpp也有一个可以使用pip install llama-cpp-python来安装的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数)、生成的总token数、温度、加载到GPU上的层数量以及响应的质量评估等指标。此外,我们还测量了GPU在模型运行期间的功耗。我们使用脚本监控GPU功耗(通过nvidia-smi),每次生成标记后立即记录。在推理结束后,我们根据这些读数计算平均功耗。因为我们专注于能完全放入GPU内存的模型,所以我们只测量了GPU的功耗。

此外,实验采用了多种提示,以确保不同的输出规模,因此,数据涵盖了各种各样的场景。

硬件和软件安装:

我们用了一个还不错的服务器,特点是以下这些:

  • CPU: AMD Ryzen Threadripper PRO 7965WX 24核心 @ 48x 5.362GHz。
  • GPU: 2个 NVIDIA GeForce RTX 4090。
  • 内存: 515276 MiB
  • 操作系统: Pop 22.04 jammy。
  • 内核: x86_64 Linux 6.9.3–76060903-generic。

这套设备的零售价格大约是15,000美元(USD)。我们选择这套设备是因为它是一款性能不错的服务器,虽然没有配备8个或更多GPU的高端专用AI服务器那么强大,但依然相当实用,并且更符合许多客户可能的选择。我们发现许多客户一开始不愿意投资高端服务器,所以这种设备在成本和性能之间成为一个很好的平衡点。

基于速度

让我们先来关注速度。下面展示的是几个箱线图来表示不同量化级别的速度数据。每个模型的名字前面都会加上它的量化级别;例如,‘Q4’表示的是4位量化。同样地,较低的量化级别表示更多的数值被舍入,这样会减小模型大小,降低质量,但同时提高处理速度。

箱线图小贴士:箱线图展示了中位数、第一和第三四分位数,以及最小值和最大值数据点。触须延伸至未被认定为异常值的最极端数据点,异常值则会单独标出。异常值定义为超出 Q1 − 1.5 × IQR 和 Q3 + 1.5 × IQR 范围的数据点,其中 Q1 和 Q3 分别代表第一和第三四分位数。四分位距(IQR)就是 Q3 和 Q1 的差值.

llama.cpp (llama.cpp 文件)

以下是 llama.cpp 的图表。图 3 显示了所有在 QuantFactory 中可用的 Llama 3.1 的 700 亿参数模型的结果,而 图 4 展示了在 此处 可获得的 80 亿参数模型中的部分。70B 模型可以将多达 81 层卸载到 GPU 上,而 8B 模型最多可以卸载 33 层。对于 70B 模型,对于 Q5 及更精细的量化,卸载所有层不可行。每种量化类型括号内均列出了卸载到 GPU 的层数。不出所料,较粗的量化提供了最佳的速度性能表现。由于行分割模式表现相似,我们在这里主要关注层分割模式。

图3 在llama.cpp中使用_split模式_layer_运行的Llama 3.1模型,其参数量为700亿。如预期的那样,较粗的量化确实提供了最佳的速度。每种量化类型旁边(括号内)显示了卸载到GPU的层数。Q5及更精细的量化模型无法完全装入VRAM。

图4 在使用分层模式 layer 下,Llama 3.1 模型(80亿参数)在llama.cpp中运行。在这种情况下,所有量化类型都能在GPU内存中运行,且更粗略的量化能带来更快的速度。需要注意的是,虽然高速度是异常情况,但整体趋势通常保持在每秒20个token左右的Q2_K量化速度。

重要观察
  • 在推理过程中,我们观察到一些高速的事件(特别是在8B Q2_K中),这说明收集数据并理解其分布至关重要,因为事实证明这些事件相当罕见。
  • 如预期的那样,更粗略的量化类型获得了最佳的速度性能。这是因为模型的大小减小,从而允许更快的执行。
  • 关于那些无法完全放入VRAM中的70B模型的结果需要谨慎对待,因为过多使用CPU可能导致性能瓶颈。因此,在这些情况下报告的速度可能不是模型性能的最佳反映。
奥拉玛

我们对Ollama也进行了同样的分析。图5显示了Ollama自动下载的默认Llama 3.1和Llama 3.2模型的结果。除了405B模型以外,其他所有模型都能在GPU内存中运行。

图5 显示了 Llama 3.1 和 3.2 模型在 Ollama 下运行。这些都是在使用 Ollama 时的默认模型。所有 3.1 版本的模型——具体来说是 405B、70B 和标记为“最新”的 8B——都使用 Q4_0 量化,而 3.2 版本的模型使用 Q8_0(1B)量化和 Q4_K_M(3B)量化。

关键观察点
  • 我们可以在Ollama和llama.cpp之间对比70B Q4_0模型,Ollama的速度稍微慢一点。同样,8B Q4_0模型在Ollama中的速度明显更慢,llama.cpp每秒处理的token更多,大约多5个。
分析框架概览

在讨论能源消耗和盈利情况之前,让我们来回顾一下我们迄今为止分析过的架构。

瑞典电力消耗与盈利

此分析特别适用于所有层都放入GPU内存的模型,因为我们只测量了两张RTX 4090显卡的功耗。然而,值得注意的是,测试中使用的CPU的热设计功率(TDP)为350瓦,这可以估算其在最大负载下的功耗。如果整个模型都被加载到GPU上,CPU的功耗可能会接近于空闲状态。

为了估算每令牌的能量消耗,我们使用以下参数:每秒令牌数(NT)和两块GPU的功耗(P),单位为瓦特。通过计算P/NT,我们得到每令牌的能量消耗,单位为瓦特-秒。再除以3600即可得到每令牌的能量消耗,单位为瓦时(Wh),这更常被引用。

llama.cpp

以下是 llama.cpp 的结果展示。图 6,展示了 70B 模型的能耗,图 7,则关注 8B 模型的能耗。这些图展示了每种量化方式下的能耗数据,图例中还显示了平均能耗。

图 6 在llama.cpp下,对于具有70B参数的Llama 3.1模型的各种量化版本,展示了行分割和层分割模式的每个token的能量。这些结果仅适用于所有81层都能在GPU内存中加载的模型。

图7 在使用llama.cpp时,对于具有80亿个参数的Llama 3.1模型的不同量化方式,每个token所消耗的能量。展示了行分割和层分割模式。所有模型的平均能耗都差不多。

奥拉玛 (#Ollama)

(注:Ollama为专有名词或名称,在中文中没有直接翻译,除非有特定的中文对应或上下文说明。)

我们也分析了Ollama的能耗。图8展示了Llama 3.1 8B(Q4_0量化)和Llama 3.2 1B和3B(分别使用Q8_0和Q4_K_M量化)的结果。图9则分别展示了70B和405B模型(两者均采用Q4_0量化)的能耗。

**图8 如图所示,Llama 3.1 8B(Q4_0 量化)、Llama 3.2 1B 和 3B 模型(分别使用 Q8_0 和 Q4_K_M 量化)每 token 的能量。

图9 左图为Llama 3.1 70B,右图为Llama 3.1 405B,在Ollama中采用Q4_0量化时每token的能量。

费用概览

与其分别讨论每个模型,我们将重点介绍那些在 llama.cpp 和 Ollama 之间可以比较的模型,以及在 llama.cpp 下使用 Q2_K 量化(这是这里探讨的最粗略的量化方式)的模型。为了让大家清晰地了解成本,下表展示了每生成一百万个 token(1M)的能耗估计和美元成本。成本是基于德克萨斯的平均电价计算的,根据这个 来源,电价为每千瓦时 $0.14。作为参考,当前 GPT-4o 的定价 至少为每 1M tokens $5 美元,而 GPT-o mini 的定价为每 1M tokens $0.3 美元。

llama.cpp

Ollama

关键点
  • 使用 Llama 3.1 70B 模型和 Q4_0 配置,llama.cpp 和 Ollama 在能耗上没有明显差异。
  • 在 8B 模型上,llama.cpp 的能耗高于 Ollama。
  • 这里展示的成本可以被视为运行这些模型的“最低成本”。其他成本,如运营、维护、设备成本和利润等未包含在本次分析中。
  • 估算表明,将 LLM 在私有服务器上运行可能比使用云服务更具成本效益。特别是,将 Llama 8B 与 GPT-45o mini 模型和 Llama 70B 与 GPT-4o 模型进行比较,在特定条件下,可能是一个潜在的好选择。

技术问题2(成本估算): 对于大多数模型,每1M token 的能耗估计(及其变化性)通常采用“中位数 ± 四分位间距”,其中IQR表示四分位间距。但对于Llama 3.1 8B Q4_0 模型,我们则采用“均值 ± 标准偏差”方法,其中STD代表标准偏差。这些选择并不是随意的;除了Llama 3.1 8B Q4_0 模型外,所有模型都存在异常值,因此在这些情况下使用中位数和四分位间距作为估计方法更为稳健。此外,这些选择有助于避免出现负成本。在大多数情况下,当两种方法给出相同的中心趋势时,它们的结果非常接近。

最后的话

图片来自Meta AI

速度和功耗在不同模型和工具之间的分析只是整体情况的一部分。我们观察到,轻量级或高度量化模型的可靠性往往较差;随着对话历史的增长或任务变得重复,幻觉现象变得更加频繁。这并不令人意外——较小的模型无法捕捉到大型模型所包含的复杂性和细节。为了克服这些限制,可以调整重复惩罚和温度等设置以改进输出。另一方面,像70B这样的大型模型则始终表现出色,很少出现幻觉现象。然而,即使是最大的模型也无法完全免于不准确性,负责任和可信的使用通常需要将这些模型与诸如LangChain和向量数据库之类的其他工具集成。尽管我们在此未具体探讨特定任务的性能,这些集成对于减少幻觉和增强模型的可靠性非常关键。

总之,在私人服务器上运行大型语言模型可以提供一种具有成本效益及定制可能性的竞争性选择。无论是私有部署还是服务模式,两者各有优势。在 Austin Ai我们专门为您打造符合您需求的解决方案,无论是私有服务器、云服务还是两者结合的方式。

点击查看更多内容
TA 点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
  • 推荐
  • 评论
  • 收藏
  • 共同学习,写下你的评论
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消