无锡网站建设mkdns,centos 下载wordpress,房地产设计图与规划图,广告做网站对于任何想要尝试人工智能或本地LLM#xff0c;又不想因为意外的云账单或 API 费用而感到震惊的人#xff0c;我可以告诉你我自己的旅程是如何的#xff0c;以及如何开始使用廉价的消费级硬件执行Llama2 推理 。
这个项目一直在以非常活跃的速度发展#xff0c;这使得它非…对于任何想要尝试人工智能或本地LLM又不想因为意外的云账单或 API 费用而感到震惊的人我可以告诉你我自己的旅程是如何的以及如何开始使用廉价的消费级硬件执行Llama2 推理 。
这个项目一直在以非常活跃的速度发展这使得它非常令人兴奋。 这也意味着你在这里阅读的任何内容都可能会发生变化就像我使用的有缺陷的模型转换一样它产生了上面Llama喝醉似的响应。 推荐用 NSDT编辑器 快速搭建可编程3D场景 1、简介
虽然没有得到很好的宣传但在过去的十年里Meta 已经悄悄地为世界做出了至少四个最具革命性的开源项目。 首先是 Zstd 压缩。 这种更快、更优越的压缩算法已经使 2015 年以来保存的任何 ZIP 文件变得过时。第二和第三个是通过开放媒体联盟的合作即媒体压缩编解码器 Opus 和 AV1没有它们现代全球 4K 流媒体将无法实现。 几乎不可能。 我喜欢的第四个也是最近的贡献是超便携的 Llama LLM 及其相关的训练模型。 模型训练是迄今为止LLM中最棘手和资源最密集的过程这就是为什么提供原始模型如此有用。
谷歌几年前发布了他们的开源 TensorFlow 项目但大多数人只能训练自己的模型这并不容易。 通过推理使用公开可用的生态系统模型实际上更容易并且可以在商品计算资源或 GPU 上执行。 理论上任何与 OpenCL CLBLAST 库兼容的东西都可以做到这一点。 此版本的 llama.cpp 统一支持 CPU 和 GPU 硬件。 请注意我们将使用主分支的构建该分支被视为测试版因此可能会出现问题。
将这些公开并可供任何人使用使得通过LLM推理来建立自己的人工智能实验室以获取本地帮助变得非常简单。 甚至不需要市场上很难找到的最新 GPU 或资源你可以使用廉价的二手技术来运行这些。 其中很大一部分灵感来自于 Chandler Lofland 的精彩文章“How to Run Llama 2 on Anything”但我将尝试通过为 Fedora Linux 预先打包高性能 llama.cpp 存储库来进一步简化事情。
Fedora 仍然是大多数基于 RPM 的发行版的上游包括 Red Hat Enterprise Linux 以及 Amazon Linux、Oracle Linux、Rocky、前 CentOS、Scientific Linux 和 Fermi Linux 等衍生产品。 这意味着 Fedora 中的 RPM 打包会渗透到这些发行版中这是一个如何为未来环境准备版本的旅程。 由于这个项目进展如此之快很难跟上而且大多数用户不想每次发生变化时都自己编译东西。 我的专长之一一直是上游项目的包自动化。 这是从提交到生产服务器的前沿比特之旅如果你确实计划在生产中使用它我建议你使用强化的 Enterprise Linux而不是我在上游使用的前沿 Fedora。
虽然上一篇文章提到在 MacBook 上为单个用户运行 Llama但我将从服务器级工作站上的服务器角度来解决这个问题。 目的是构建一个可重复的环境团队中的客户可以在云或本地连接和共享。 你还可以尝试公共沙箱根据我的经验它的性能非常好。
值得注意的是Llama2 有两个组件应用程序和数据。 运行 Llama2 的官方方式是通过 Python 应用程序但 C 版本显然更快、更高效因为 RAM 是你在尝试使用 CPU 或 GPU 运行 Llama2 服务时会发现的最关键组件。
就我而言工作站在 2 插槽 HP Z840 上以一半容量运行配备 512GB DDR4 LRDIMM。 仅使用 CPU 可以访问更多 RAM但 CPU 推理速度较慢尤其是当 RAM 需要在插槽之间交换时。 此外LRDIMM 的速度比常规 RDIMM 稍慢但代价是容量更高。 通常我建议禁用 NUMA因为通过内存给予 CPU 插槽优先权通常会导致一个 CPU 过热直到它减慢到不切实际的速度。 在这种情况下LLM 是一种 CPU 工作负载可以从某些 NUMA 调整中受益Llama.cpp 确实支持 NUMA 标志但大多数人无论如何都希望使用 GPU。
在编写本文时常见的 GGML 模型文件格式已被弃用并被 GGUF 取代这有点延迟了。 GGUF格式是优越的也是未来的但有些模型需要重新转换或重新下载。 这是一个不断变化的目标甚至转换器也无法处理我的大部分 GGML 文件。 好消息是 GGUF 文件要小得多并且在磁盘上压缩得更少因此它们肯定比较大的 GGML 文件更高效。 坏消息是 CodeLlama 恰好在同一时间发布这一变化的引入让我的速度慢了很多。 在复杂模型格式的斗争中我意识到轻松识别哪些文件是什么格式以及哪个版本将很有帮助。 为了在测试过程中保持一切正常我制作了一个临时魔术文件来识别模型。 然后通过 PR 我发现这个项目的社区非常活跃而且非常友好。 我们还一起正式提交了正确的 MIME 提交。
jboeroxps ~/Downloads file *llama*
codellama-7b.Q8_0.gguf: GGUF LLM model version1
llama-2-7b.ggmlv3.q8_0.bin: GGML/GGJT LLM model version3
llama-cpp.srpm.spec: ASCII textCodeLlama 主要作为三种不同的模型发布范围包括 7B、13B 和 34B 参数数量的训练。 即使是 7B 型号也非常强大可以在小型笔记本电脑上轻松运行。
2、性能表现
GPU 实际上是可选的但我已经更换了旧的 Nvidia 卡因此我运行的是 16GB 的工作站级 A4000 和 12GB 的消费级 4070ti。
任何生产 AI 部署都应使用带有 ECC RAM 的服务器或工作站级 GPU例如 A4000。 如果没有检查 RAM 的 ECC请勿在旧的挖矿或游戏 CPU 或 GPU 上运行重要的 LLM。 服务器级 GPU 的速度更快的 HBM2/HBM3 RAM 将比商用硬件中的 DDR/GDDR 提供更快的体验因为模型的下一个权重或张量的访问延迟始终对性能至关重要。
除了 CPU 之外GPU 可以自由选择自己的 RAM 速度和总线这是它们制造如此重要的协处理器的原因之一。 如果你不熟悉通用或 GPGPU 的历史请参阅我之前的系列 All Things GPU 了解背景知识。
我们有足够的 GPU 内存来以全性能加载大部分 13B Llama2 模型CPU 内存足以测试大型 70B 模型。 那么让我们来试驾一下吧。
首先如果没有快速连接下载模型可能会令人畏惧。 它们很大如果你把它们全部拿走目前未压缩的话大约有 200GB 以上。 如果你需要在格式之间进行转换还需要额外的空间。 对于这种类型的存储你可能需要固态硬件但在生产中只需要启动该服务。
我发现 Fedora 38 的 btrfs 文件系统及其 zstd 压缩选项有很大的好处。 根据我的经验默认的 compresszstd:1 是不够的内核决定不压缩太多这是愚蠢的因为大多数内容实际上是高度可压缩的具体取决于你需要的转换格式。 用 force-compresszstd:1替换mount选项要好得多需要磁盘上46%的实际空间几乎没有CPU开销。 由于这是只读数据因此非常完美如 70B 聊天模型的副本所示
sudo compsize llama-2-70b-chat/
Processed 3 files, 2105004 regular extents (2105004 refs), 2 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 46% 120G 256G 256G
zstd 46% 120G 256G 256G3、对 CodeLlama 的初步想法
我对 Llama2 的主要兴趣是通过 Llama 插件添加对我的 AI Shell 项目的支持因此我将通过简单的 bash 测试来试用它。 我喜欢面向代码的 LLM 只向我显示城市的当前时间所以让我们尝试使用 CPU 服务器上的基本 34B CodeLlama 模型。
启动服务器非常简单指定 host :: 来侦听任何 IPv4 或 IPv6 地址请注意尚不支持 TLS。 我的模型通过强制 zstd 压缩保存到备份磁盘。 一旦加载到磁盘缓存中然后加载到服务或 GPU 内存中读取速度就不再重要了。
llamaserver --host :: -m /mnt/backup/llama/codellama-34b.gguf这为远程连接提供了方便的 Web 界面可以快速轻松地测试驱动 CodeLlama。 注意 Llama.cpp 不是这些模型的唯一运行时。 出现了一个完整的项目生态系统为 Llama 推理提供 UI 或 REST API 服务。 Llama.cpp 中的简单 UI 使用自己的 API非常简单且未经身份验证。 使用 TLS 客户端证书或外部身份验证方法进行代理包装非常简单但我预计很快就会添加一些内容。
我会要求它编写一个 bash 脚本或函数来告诉我迪拜的当前时间。 这往往与 Google 的 Bison 编码模型配合得非常好。 此时我的首选litmus测试揭示了转换后的模型中的错误。 这些错误已在上游项目中修复。
好吧这还不是我所说的生产级 Llama。 这是由于与 GGUF 格式发布同时发生的模型转换错误引起的我在尝试排除故障时浪费了一天的时间。 有一个参数应该惩罚这样的重复但它没有任何效果使 Codellama 模型有效地表现为手机键盘上的美化文本预测。
首先我需要使用修补的转换脚本将原始 GGML 格式的模型重新转换为 GGUF。 然后调整一些参数和提示看看能不能做得更好。 服务器控制台中的默认设置肯定不是我们需要的。 最重要的是这个模型的温度似乎特别敏感所以让我们尝试一下它。
接下来我将温度降低到 0.5但这显然还不够。 这里仍然有太多的创作自由以至于 Llama 出于某种原因称我为“buddykins”。 进一步降低温度 0.1 并使用公共沙箱环境中的设置给出了我想要看到的结果。 看来 CodeLlama 模型不会影响温度这是有道理的。 代码编写是一种相当严格的语法没有留下太多随机性或创造力的空间。
这个示例更能满足我自己的需求。 这正是 aish 可以用来将简单请求直接透明地转换为环境中的本地操作的输出类型。 请注意我绝对不建议这样做 - 这样做需要你自担风险或冒险。 有时Llama需要一些哄骗。 对于个人用户来说仅 CPU 的性能实际上并不可怕。 在纯 CPU 系统上长时间运行的 AI 推理确实会通过单个查询来最大化插槽因此热问题可能会在规模上令人望而却步。
在这里我使用默认线程数即每个物理核心一个线程。 在我的双 14 核超线程盒子中这意味着 28 个线程几乎保持本地化在一个插槽或 NUMA 节点上直到 CPU 变得太热然后操作系统切换到另一个插槽。 在这里你可以看到这种情况发生绿色条变成蓝色。
如果我手动将线程数设置为 56CPU 负载就会达到最大并且实际性能会变慢 — 即使使用 Llama.cpp 的 NUMA 标志也是如此。 当一个线程需要跨总线访问另一个NUMA节点中的内存时它会减慢整个进程的速度。 如果你计划使用 CPU 来处理部分或全部工作负载我建议你使用冷却良好的单插槽服务器。 在这里可以看到冗长的推理对 GPU 进行加热并且当活动的 CPU 插槽温度过高时CPU 插槽之间也会发生跳动。 热 NUMA 平衡显示推理何时在套接字之间迁移。 温度为摄氏度。
4、添加 CUDA 和 OpenCL GPU 支持
现在我们已经在 CPU 上为标准 Llama.cpp 设置了构建自动化和打包是时候为 Fedora 和未来衍生品如 RHEL Amazon Linux的打包添加 GPU 支持了。
事实证明 OpenCL 对此非常简单。 所有库都是纯开源的因此它们与免费的 COPR 构建系统兼容。 此外所有依赖项都包含在标准存储库中。 添加一些用于构建的 BuildRequires 依赖项和用于安装的 Requires 依赖项就可以解决问题。 用户需要为其设备安装正确的 OpenCL 库和驱动程序。 请注意这也支持 Nvidia 的实现根据我的经验这实际上是最稳定的 OpenCL 实现之一。
由于多种原因打包 CUDA 构建非常棘手。 CUDA 工具包尚未为当前的 Fedora 38 及其较新的 gcc v13 做好准备而 Fedora 37 的动态构建将需要较旧的 F37 库作为依赖项。 CUDA 也不容易静态编译这需要将 GPU 驱动程序静态链接到二进制文件中。 那么我们将面临以下挑战
免费的公共构建系统不允许专有许可。nVidia 尚未赶上最新的 GCC 编译器版本 13。nVidia CUDA 工具包存储库当前仅适用于 x86_64。
目前最好坚持使用 Fedora 37 或使用 Fedora 37 的容器进行构建。 过去CUDA 经常落后于稳定的 GCC 版本这不是 nVidia 的错。 事实上主要 GCC 版本之间的重大转变导致了涉及许多主要组件的依赖关系转变。
Fedora 通常都是这样在上游领先需要时间才能赶上但 Fedora 38 转向了 GCC v13这给不少项目带来了麻烦。 这种斗争是生态系统的正常进展并不是什么新鲜事。 Fedora 历来并不能让安装多个版本的 GCC 变得容易而 Ubuntu 和 Debian 的衍生版本往往会让安装变得相当简单。
不建议经常混合使用它们因为这可能会导致支持混乱。 很多人最终在论坛上询问如何构建他们自己的以前的 GCC 编译器版本。 别打扰。 它已经被编译了数千次并且仍然存在于遗留存储库中。 只需从 Fedora 37 存储库获取 gcc 和 g v12 的副本并将它们复制到本地 bin 目录即可完成此任务。 接下来你的架构需要 g 层在本例中为 x86_64。 幸运的是这在 Fedora 38 存储库中仍然是可选的。
sudo dnf --releasever37 --installroot/tmp/f37 install gcc-c
cp /tmp/f37/bin/{gcc,g} ~/YOURPATHBIN/
sudo dnf install gcc-c-x86_64-linux-gnu-12.2.1-5.fc38.x86_64现在启用 Nvidia CUDA 存储库并安装所有正确的开发包包括 cuBLAS 库。 他们支持的最新版本是 F37因为他们还没有完全准备好使用 GCC 13 的 F38。同时由于我们已将 GCC 12 添加到本地环境因此可以在 F38 上启用 F37 存储库。
最后可以在我们的系统上使用 CUDA 进行启用 cuBLAS 的构建。 如果你的系统 GCC 13那么应该能够使用我在此处添加到项目中的规范来简单地构建自己的 RPM
不要忘记即使 Nvidia 设备也应该能够使用 CLBlast 的 OpenCL 实现。 现在提供了三个不同的软件包每个软件包都带有重命名的二进制文件。 你可以安装所有这三个版本并使用合适的版本或者只选择适合你的硬件的版本。 OpenCL 版本可以使用大多数当前的 CPU 和 GPU包括理论上的移动设备这很好因此它是我的首选安装。
5、API使用
请记住服务器包含其自己的简单的未经身份验证的 API。 现在用 Curl 和 JQ 进行测试就足够简单了。 这意味着使用 libCurl 和 libJsonCPP 直接将 Llama 支持添加到我的 AI Shell 项目中。
PROMPTThis is a conversation between User and Llama, a friendly codebot. Llama only writes code. Please write a hello world in C.
curl --request POST \--url http://localhost:8080/completion \--header Content-Type: application/json \--data {prompt: $PROMPT,n_predict: 128} | jq .content
\n\n#include iostream\n\nint main() {\n std::cout \Hello world!\ std::endl;\n}\n虽然修复了一些错误但这个领域确实正在腾飞我发现 Llama2 比早期的 Llama 版本得到了更多的关注。 虽然这还不完美但这是 Meta 对开源社区的惊人捐赠我怀疑用户群会让它变得更好。 接下来我将使用 OpenAI Whisper 或 Julius 为 AI Shell 添加语音识别支持。
6、结束语
确实结果不言而喻。 今天任何人都可以开始使用它。 你应该能够使用我们在本文中整理的包装和一些适中的硬件轻松评估 Llama。 我仍然警告在生产中使用人工智能推理结果需要自担风险但环境本身应该为任何想要开始的团队做好生产准备。 原文链接生产级Llama实战 — BimAnt
