本地CPU上运行LLM，1毛钱都不想多花

如果你和我一样，最近一直在做Agent试探，就会对第三方大模型非常纠结，随着调用次数的增加，银子也是白花花的流淌，有没有省钱的办法呢？当然有，就是在CPU上跑大模型。

一般的GPU服务器，一个月下来起码也要2000左右，算下来，不如调第三方服务的API划算，但是调第三方服务存在着数据泄露风险，而且随着用户增长，按tokens计价的方式，也会消耗如流水，内心滴血。一群大佬找到了省钱的办法，就是让大模型在AMD的GPU，甚至在CPU上跑。如果在CPU上跑，我们只需要租一台核心过得去内存比较大的服务器即可，每个月的价格瞬间降到几百块，甚至打折时期，花千把来块就可以租一年。本文主要来聊一聊，如何让LLM运行在CPU上，以极限姿势压榨服务器，达到省钱目的。不是GPU不够好，而是CPU性价比更高。

想要让LLM在CPU上运行，核心要做到两个点：

• 高效的CPU运算架构
• 对大模型的性能压榨

只要做到这两点，再配合一台硬件上还不错的普通CPU服务器，就可以让我们获得一个性价比最大化的本地大模型服务。

针对第一点，社区大佬Georgi Gerganov想到了用c/c++重新实现模型框架，在想到这个点子后，经过一个晚上的奋战之后，他推出了llama.cpp项目。

Georgi Gerganov

该项目主要用于运行大模型，完成推理过程。使用c/c++的优势在于：

• 无需任何额外依赖，相比 Python 代码对 PyTorch 等库的要求，C/C++ 直接编译出可执行文件，跳过不同硬件的繁杂准备；
• 支持 Apple Silicon 芯片的 ARM NEON 加速，x86 平台则以 AVX2 替代；
• 具有 F16 和 F32 的混合精度；
• 支持 4-bit 量化；
• 无需 GPU，可只用 CPU 运行；
• …

由于纯 C/C++ 实现，无其他依赖，运行效率很高，除 MacBook Pro 外，甚至可以在 Android 上运行。

针对第二点，如何将动则上100B的大模型进行压缩，以可以让普通的CPU机器也可以带得动呢？答案是通过“量化”。所谓量化，学术的说是“将连续取值的浮点型模型权重进行裁剪和取舍的技术”，简单讲就是压缩，丢失部分精度，换取空间和性能。Georgi Gerganov提出了自己的量化方案ggml，并在该量化方案被广泛认可后，ggml成为一种量化模型的文件格式。但是，大模型领域发展的太快了，ggml很快跟不上步伐，于是在2023年8月他又推出了改进方案gguf，该方案替代ggml成为最新的量化模型文件格式。而且，目前HuggingFace也大力支持了该格式。当然，除了gguf方案外，还有其他量化方案，例如知名的GPTQ等。总之，经过量化后的模型，可以提升性能，降低对硬件资源的要求。

现在，我们有了llama.cpp和gguf，我们就可以在CPU机器上跑大模型了。

不过先不要着急，我们还有杀手锏。虽然llama.cpp是可以直接运行，可是它的运行方式有点不那么感冒。毕竟现在很少有人在用c++写业务系统了，所以，我们最好还是能跟我们的应用结合起来便是最好。这里有两种方案：

• 独立服务，通过RPC或http进行调用
• 编译为业务系统开发语言支持的模块，直接在代码中调用

第一种方案，可以使用llama.cpp项目中提供的轻量http服务，或者第三方的docker来起服务，起来之后，就可以通过http api来调用大模型；第二种方案，社区非常多的牛人提供了不同语言的模块，可以在llama.cpp项目首页看到这些项目，你只要找到自己业务系统编程语言对应的模块，安装到自己的系统中，就可以像调用一个第三方库一样调用大模型。另外，如果想快速体验，还可以通过一个知名的项目ollama，一键安装和启动大模型。

独立服务模式

模块封装模式

作为前端开发，我也在前人的肩膀上封装了一个库node-llm，你可以使用 npm install node-llm 来安装它。它简化了接口，理解成本极低，可以让前端开发的同学，以最快的速度在nodejs上启动一个大模型项目。有了它，再配合langchain的js版本，就可以轻松搭建自己的知识库等Agent应用。而且我还融合了之前做的chatglmjs项目，在llama之外，支持chatglm系列模型，chatglm的6b模型要求的性能在同级别中最低，非常值得一试。通过这种模块化设计，我们甚至可以把一些体积小的大模型直接作为软件的一部分，在软件安装时就作为软件本身的内置功能。如果你使用electron来开发桌面应用，你甚至可以在应用中使用 node-llm 并下载好gguf后，打包成一个软件提供给你的客户。当然，如果你是做MacOS的应用开发，也可以直接使用c++代码进行调整后内置到软件中。总之，llama.cpp这个项目，给我们带来了更大的想象空间。

量化后的模型对硬件的要求降低，但是并不意味着随便一台垃圾机器也可以跑起来，如果我们有一台8G内存的大模型，我们可以尝试6B的量化模型。当然，如果我们有需要，可以升级机器到32G，此时，我们就可以把量化的精度提高一些，以获得效果更好的输出。如果我们只有2G内存，还是建议调第三方接口来的实在。

最后，有人会问，失去精度后，大模型准确性降低，不就失去了意义吗？对于这个问题，我想说的是，我们应该根据自己的需求来选择，不然为什么所有厂商都会提供不同参数量级的模型呢？说明这些厂商们明白，我们在面对不同需求时，所需要的精度是不同的。对于我们做应用开发而言，我们要学会用架构拆分来合理降低成本。当我们一股脑的把所有LLM处理都丢给一个大模型去处理，意味着该模型要承受巨大的服务压力，同时，你的成本也是固定的。但当我们把不同的处理进行拆分，精度必须高的，分发给智能程度高精度高的大模型去处理，精度要求低的，分发给我们今天搭起来的CPU上跑的大模型去处理，如此合理分配，就可以让我们的成本降低。

对于我们学习、调试期间而言，本着能省则省的性价比观念，自己搭一个本地大模型服务，调通整个Agent之后，再把部分调用切换到付费大模型去，如此，岂不省了很多？