本地运行“李开复”的零一万物 34B 大模型

本地运行“李开复”的零一万物 34B 大模型
这篇文章，我们来聊聊如何本地运行最近争议颇多的，李开复带队的国产大模型：零一万物 34B。

写在前面

零一万物的模型争议有很多，不论是在海外的社交媒体平台，还是在国内的知乎和一种科技媒体上，不论是针对模型、代码、还是针对团队，甚至针对这家公司的一把手，李开复，都有非常多不同角度的唇枪舌剑之争。

相比较其他的争议，作为开发者和终端用户，我个人最好奇的一件事是：34B 干翻一众 70B 模型，打榜分数那么高，这模型到底行不行？

在很多负面的反馈中，印象中有一条很有趣的观点，34B 本地跑都跑不起来，更遑论了解这个模型真实水平。

实际上，如果我们使用流行的模型量化方案，在压的比较狠的情况下，模型尺寸从原本的接近 70GB 恰好能够控制到 24GB 内。但是，倘若不采用任何优化方案，你可能只需要一轮对话，模型应用就会 “out of memory” 报错退出。

那么，有没有靠谱的方案，可以让我们在本地的机器上将这个 34B 模型跑起来，一窥真相呢？

让 CPU 和 GPU 都忙活起来：llama.cpp 的另类使用

ggerganov/llama.cpp 是一款优秀的开源软件，它几乎是伴随着 llama 大模型的成长、爆火、出圈而一起出现在了全球开发者和领域爱好者面前。之前写过一些关于 llama 的 finetune、量化、容器把玩的内容，感兴趣可以自行翻阅：“llama 大模型的那些事儿”。

不过 llama.cpp 之前主打的玩法，是使用纯 CPU 来进行模型的推理，在《构建能够使用 CPU 运行的 MetaAI LLaMA2 中文大模型》中，我曾经介绍过这种玩法。很长一段时间里，能够在没有 GPU 的电脑里（尤其是 Mac）用这种方法跑大模型变成了一件有趣的娱乐项目。

考虑实际的用户体验，纯粹使用 CPU 进行推理，小尺寸的大模型的运行效率或许可能够接受。但是对于 34B 或更大尺寸的模型纯纯使用 CPU 推理，无疑是在挑战用户耐心，或许还有一些浪费电（长时间满功耗运行）。

好在随着 gguf 模型格式和 llama.cpp 对 offloading 模型 layers 到 GPU 的功能的日渐完善，用 CPU 推理模型，顺带把模型的一部分装到更高计算性能的 GPU 里，使用体验变的越来越好了。

不过可惜的是，因为一些“编译约束条件”，这种玩法并未像纯粹使用 CPU 来运行模型流传的那么广泛。

接下来，我们就聊聊这种玩法。

准备模型程序运行环境

想顺滑的完成实践，我推荐你安装 Docker，不论你的设备是否有显卡，都可以根据自己的操作系统喜好，参考这两篇来完成基础环境的配置《基于 Docker 的深度学习环境：Windows 篇》、《基于 Docker 的深度学习环境：入门篇》。当然，使用 Docker 之后，你还可以做很多事情，比如：之前几十篇有关 Docker 的实践，在此就不赘述啦。

如果你和我一样，使用 Docker 环境折腾、学习和用于生产。那么，我推荐你使用 Nvidia 家提供的深度学习环境 nvcr.io/nvidia/pytorch:23.10-py3 作为基础镜像，其中的 CUDA 版本经常效率比公开的开源社区版本要跑的更快一些：
```
FROM nvcr.io/nvidia/pytorch:23.10-py3
RUN pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple && \
    pip3 install --upgrade pip  # enable PEP 660 support
RUN sed -i 's/archive.ubuntu.com/mirrors.tuna.tsinghua.edu.cn/g' /etc/apt/sources.list && \
	sed -i 's/security.ubuntu.com/mirrors.tuna.tsinghua.edu.cn/g' /etc/apt/sources.list
WORKDIR /app
RUN pip3 install transformers==4.35.0 huggingface-hub==0.17.3 hf_transfer==0.1.4
RUN apt-get update && apt-get install cmake -y && apt-get autoremove -y
1
2
3
4
5
6
7
8
```
我们将上面的内容保存为 Dockerfile，然后使用下面的命令来完成稍后使用的镜像的构建（项目中的相关文件保存在 soulteary/docker-yi-runtime/docker/Dockerfile）：
```
docker build -t soulteary/yi-34b-runtime:20231126 .
1
```
构建完毕运行环境后，我们可以使用下面的命令进入容器环境，继续折腾：
```
docker run --rm -it -p 8080:8080 --gpus all --ipc=host --ulimit memlock=-1 -v `pwd`:/app soulteary/yi-34b-runtime:20231126 bash
1
```
进入容器后，我们可以使用熟悉的 nvidia-smi 查看“显卡”是否能够被正确使用和使用：
```
Sun Nov 26 08:41:52 2023       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 525.147.05   Driver Version: 525.147.05   CUDA Version: 12.0     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  NVIDIA GeForce ...  Off  | 00000000:01:00.0 Off |                  Off |
| 31%   33C    P8    27W / 450W |     93MiB / 24564MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
+-----------------------------------------------------------------------------+
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
```
因为我们选择的是 Nvidia 提供的环境，所以 nvcc 是就绪的。但是如果你是在 Bare Metal 中运行，记得解决 nvcc 的安装，保持和显卡驱动大版本一致，下文中编译 llama.cpp 需要 nvcc 是可用的：
```
# nvcc --version

nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2023 NVIDIA Corporation
Built on Tue_Aug_15_22:02:13_PDT_2023
Cuda compilation tools, release 12.2, V12.2.140
Build cuda_12.2.r12.2/compiler.33191640_0
1
2
3
4
5
6
7
```
下载合适的模型文件

零一万物的官方模型发布页面是 01-ai/Yi-34B，里面包含了两种格式的模型，如果你想转换模型格式为我们可以运行的 ggml 或者 gguf 格式，可以参考前文中的文章。如果你懒得进行这个量化步骤，可以直接下载 HuggingFace 社区其他社区用户量化好的版本：
如果你想快速下载可靠的模型，可以使用下面的命令：
```
# 我们可以使用 Huggingface Cli 来下载模型
huggingface-cli download --resume-download --local-dir-use-symlinks False ${模型在huggingface上的名字} ${模型文件名}.gguf --local-dir ${模型存储路径}

# 你也可以使用下面的命令，通过社区用户搭建的减速器来下载
HF_ENDPOINT=https://hf-mirror.com HF_HUB_ENABLE_HF_TRANSFER=1 huggingface-cli download --resume-download --local-dir-use-symlinks False ${模型在huggingface上的名字} ${模型文件名}.gguf --local-dir ${模型存储路径}
1
2
3
4
5
```
这里偷个懒，我测试选择的是 The Bloke 提供的开源模型，分别选择了 Q4 和 Q5 两个尺寸的量化模型，这两个模型有一个有趣的差异，一个恰好放的进 24G 显存的卡里，一个恰好放不进去：
```
# Capybara Tess Yi 34B 200K Dare Ties - GGUF
# https://huggingface.co/TheBloke/Capybara-Tess-Yi-34B-200K-DARE-Ties-GGUF
TheBloke/Capybara-Tess-Yi-34B-200K-DARE-Ties-GGUF capybara-tess-yi-34b-200k-dare-ties.Q4_K_M.gguf

# Nous Capybara 34B - GGUF
# https://huggingface.co/TheBloke/Nous-Capybara-34B-GGUF
TheBloke/Nous-Capybara-34B-GGUF nous-capybara-34b.Q5_K_M.gguf
1
2
3
4
5
6
7
```
下载模型参考上文中的说明，不难得到下载命令，如果你要下载其他的模型，可以参考并进行调整：
```
# 比如
huggingface-cli download --resume-download --local-dir-use-symlinks False TheBloke/Capybara-Tess-Yi-34B-200K-DARE-Ties-GGUF capybara-tess-yi-34b-200k-dare-ties.Q4_K_M.gguf --local-dir ./models/TheBloke/Capybara-Tess-Yi-34B-200K-DARE-Ties-GGUF
1
2
```
模型保存目录结构如下：
```
models
  └── TheBloke
      ├── Capybara-Tess-Yi-34B-200K-DARE-Ties-GGUF
      │   └── capybara-tess-yi-34b-200k-dare-ties.Q4_K_M.gguf
      └── Nous-Capybara-34B-GGUF
          └── nous-capybara-34b.Q5_K_M.gguf
1
2
3
4
5
6
```
完成了模型的下载之后，我们就可以进行最后一项准备工作了。

编译使用 GPU 的 llama.cpp

在解决完毕运行环境的问题后，我们需要手动下载 llama.cpp 的代码，并做一些目录准备：
```
# 下载代码
git clone https://github.com/ggerganov/llama.cpp.git
# 进入代码目录
cd llama.cpp/
1
2
3
4
```
我们使用 make -j LLAMA_CUBLAS=1 对 llama.cpp 进行构建，启用 CUDA 功能，以便让程序支持使用显卡资源，耐心等待构建完毕：
```
# make -j LLAMA_CUBLAS=1
I llama.cpp build info: 
I UNAME_S:   Linux
I UNAME_P:   x86_64
I UNAME_M:   x86_64
I CFLAGS:    -I. -Icommon -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -DNDEBUG -DGGML_USE_CUBLAS -I/usr/local/cuda/include -I/opt/cuda/include -I/targets/x86_64-linux/include  -std=c11   -fPIC -O3 -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wshadow -Wstrict-prototypes -Wpointer-arith -Wmissing-prototypes -Werror=implicit-int -Werror=implicit-function-declaration -Wdouble-promotion -pthread -march=native -mtune=native 
...
g++ -I. -Icommon -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -DNDEBUG -DGGML_USE_CUBLAS -I/usr/local/cuda/include -I/opt/cuda/include -I/targets/x86_64-linux/include  -std=c++11 -fPIC -O3 -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wmissing-declarations -Wmissing-noreturn -pthread  -Wno-array-bounds -Wno-format-truncation -Wextra-semi -march=native -mtune=native  examples/export-lora/export-lora.cpp ggml.o llama.o common.o sampling.o grammar-parser.o build-info.o ggml-cuda.o ggml-alloc.o ggml-backend.o ggml-quants.o -o export-lora -lcublas -lculibos -lcudart -lcublasLt -lpthread -ldl -lrt -L/usr/local/cuda/lib64 -L/opt/cuda/lib64 -L/targets/x86_64-linux/lib 

====  Run ./main -h for help.  ====
1
2
3
4
5
6
7
8
9
10
```
当看到 Run ./main -h for help 这条日志的时候，我们可以看到当前目录多出了很多文件和新的可执行文件：
```
baby-llama     benchmark                finetune     main        quantize         simple       test-grammar-parser  test-rope                test-tokenizer-1-bpe     vdot
batched        convert-llama2c-to-ggml  infill       parallel    quantize-stats   speculative  test-llama-grammar   test-sampling            test-tokenizer-1-llama
batched-bench  embedding                llama-bench  perplexity  save-load-state  test-c       test-quantize-fns    test-tokenizer-0-falcon  tokenize
beam-search    export-lora              llava-cli    q8dot       server           test-grad0   test-quantize-perf   test-tokenizer-0-llama   train-text-from-scratch
1
2
3
4
```
这里面有许多有趣的工具，不过网上关于它们的介绍其实不多，更多的都是关于主程序 main 的简单使用。后面的文章，有机会我们再来逐步展开这些工具中更有趣的玩法。

本篇文章，我们主要使用 server 程序，来跳过各种“分数”，一窥真实的模型能力。为了方便后面使用，我们可以将这个纯粹的二进制文件复制到我们容器中的 /app 目录中：
```
cp server /app/
1
```
开始测试前的完整目录结构如下：
```
├── models
│   └── TheBloke
│       ├── Capybara-Tess-Yi-34B-200K-DARE-Ties-GGUF
│       │   └── capybara-tess-yi-34b-200k-dare-ties.Q4_K_M.gguf
│       └── Nous-Capybara-34B-GGUF
│           └── nous-capybara-34b.Q5_K_M.gguf
└── server
1
2
3
4
5
6
7
```
使用 llama.cpp 运行 34B 大模型

我们先来使用比较保守的策略来运行模型：
```
./server --ctx-size 2048 --host 0.0.0.0  --n-gpu-layers 32 --model ./models/TheBloke/Nous-Capybara-34B-GGUF/nous-capybara-34b.Q5_K_M.gguf 
1
```
上面的命令中，我们在加载模型的时候，设置了上下文尺寸为 2k，将模型中的 32 层发送到 GPU 中，启动一个能够被容器外部访问的服务。

稍等片刻，当我们看到类似下面的内容的时候，服务就可以正常使用啦：
```
llama_new_context_with_model: VRAM scratch buffer: 270.00 MiB
llama_new_context_with_model: total VRAM used: 270.00 MiB (model: 0.00 MiB, context: 270.00 MiB)
Available slots:
 -> Slot 0 - max context: 2048

llama server listening at http://0.0.0.0:8080

{"timestamp":1700997080,"level":"INFO","function":"main","line":2917,"message":"HTTP server listening","hostname":"0.0.0.0","port":8080}
1
2
3
4
5
6
7
8
```
通过访问 http://主机IP:8080 ，我们能够访问到一个简洁的 Web 界面。

调用模型时，不同的参数将会带来不同的结果。为了保持简单，我们可以先暂时使用默认参数，并在在最下面的对话框中输入我们要模型处理的内容。

我这里使用一篇前两天“机器之心”发布的关于 OpenAI 的文章“OpenAI内斗时，Karpathy在录视频：《大型语言模型入门》上线”为例子，来做接下来的模型测试内容。将要求写在第一行，然后将机器之心的内容贴在后面。

虽然在过往经验中，我们一般会对内容进行处理，得到更好的效果，但其实大模型有很强的“容错性”，我们也可以偷懒，不对模型要处理的内容进行“提纯”，我提交的内容中就包含了很多 HTML 占位符：许多 “图片” 字符串。

因为使用 “保守策略”，程序刚刚启动的时候，被灌进显卡内的模型并不大，只有 13 GB。(当前，你也可以调整的更多或者更少)
```
|===============================+======================+======================|
|   0  NVIDIA GeForce ...  Off  | 00000000:01:00.0 Off |                  Off |
| 31%   38C    P2    64W / 450W |  13149MiB / 24564MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
1
2
3
4
5
```
当我们点击上面的 “Send” 按钮后，模型会开始处理任务，不过毕竟是用 “Hybird” 方式处理 340 亿参数量的模型，等待时间会久一些。

在程序日志中，我们能够看到模型程序到底接收了多少内容：
```
slot 0 is processing [task id: 0]
slot 0 : in cache: 0 tokens | to process: 1416 tokens
slot 0 : kv cache rm - [0, end)
1
2
3
```
如果此时我们查看 CPU 使用状况，将能够看到多数 CPU 核心都在“卖力干活”：

稍等片刻，就能够看到模型开始持续的输出内容啦：

等待程序执行完毕，我们将得到模型的处理性能和详细细节。
```
print_timings: prompt eval time =   12049.71 ms /  1416 tokens (    8.51 ms per token,   117.51 tokens per second)
print_timings:        eval time =  115381.73 ms /   400 runs   (  288.45 ms per token,     3.47 tokens per second)
print_timings:       total time =  127431.44 ms
slot 0 released (1817 tokens in cache)
1
2
3
4
```
这里能够看出模型的摘要总结能力还是很强的。

不过，第一轮对话执行之后，用来分摊 CPU 和内存压力的显存，使用量接近 15GB 显存啦。
```
|===============================+======================+======================|
|   0  NVIDIA GeForce ...  Off  | 00000000:01:00.0 Off |                  Off |
| 31%   38C    P8    28W / 450W |  15277MiB / 24564MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
1
2
3
4
5
```
当然，就这么泛泛的测试一轮，未免有点儿戏。我们来进行对轮对话测试。这里为了考验模型的基础能力，所有的问题我都不会加“问号”，并且尽量用代词而非具体的内容来和它交流。

除了最后一个问题，因为没有和“李开复”交流过，不确定这个口吻像不像，只能够看出来模型突然画风变的高冷，以大佬姿态说出了一段话外。其他的回答，我个人还是比较满意的。

当然，因为我们使用了“资源保守策略”，在启动程序的时候，只将模型的 32 层放在了显卡里，所以模型输出内容的速度只有 3.4 tokens/sec 左右。

如果我们选择完全使用 CPU，速度则只剩下了 1.8 tokens/sec 左右。

为了提升模型吞吐速度，我们来做个简单的性能优化。

性能提升技巧：调整 llama.cpp 加载模型层数

在目前的普通硬件环境中，一般来说显卡的带宽和数据交换性能远远高于内存，所以我们可以将模型更多的往显卡里塞，来减少程序在几十 GB 模型程序和数据中寻找我们需要的答案的时间。

当然，完全将模型放在显存里是有些困难的（除非进行性能损失比较大的量化）。在上面的测试中，我们选择的是将模型的一半放在显卡里，通过观察我们可以得出模型在运行之后，至少会额外占据 1GB 的显存，所以我们可以增大 --n-gpu-layers 到合理的程度。

我这里的选择是设置为 55 层：
```
./server --ctx-size 2048 --host 0.0.0.0 --n-gpu-layers 55 --model ./models/TheBloke/Nous-Capybara-34B-GGUF/nous-capybara-34b.Q5_K_M.gguf
1
```
程序启动过程中，我们可以知道这将会在初始化过程中，占据显卡的 20GB 显存。
```
llm_load_tensors: using CUDA for GPU acceleration
llm_load_tensors: mem required  = 2586.53 MiB
llm_load_tensors: offloading 55 repeating layers to GPU
llm_load_tensors: offloaded 55/63 layers to GPU
llm_load_tensors: VRAM used: 20607.34 MiB
1
2
3
4
5
```
程序实际运行完毕后，我们在 nvidia-smi 中得到的资源占用情况会更多一些：
```
|===============================+======================+======================|
|   0  NVIDIA GeForce ...  Off  | 00000000:01:00.0 Off |                  Off |
| 31%   35C    P8    27W / 450W |  21913MiB / 24564MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
1
2
3
4
5
```
然后我们再次使用相同的机器之心发布的内容，来进行模型测试，你会发现模型的处理速度快了非常多，比之前大概快了接近 3 倍。

当然，我们还是多问几轮，看看情况。

速度比之前稍微慢了一些，变成了 8.x token/sec，整体回答我都比较满意。除了最后一条，列举实体的时候，把 meta 也列了进去，虽然没有把 meta 看做人，回答也可圈可点，但是文本的并列关系里，其他三项都是人名呐。

性能提升技巧：选择更小巧的模型

上文中我们使用的是稍微大一些的模型，如果我们选择恰好放的进显卡的 Q4 版本的量化模型，可以在启动的时候，设置加载层数完全等于模型层数：
```
./server --ctx-size 2048 --host 0.0.0.0 --n-gpu-layers 63 --model ./models/TheBloke/Capybara-Tess-Yi-34B-200K-DARE-Ties-GGUF/capybara-tess-yi-34b-200k-dare-ties.Q4_K_M.gguf
1
```
同样，模型加载的时候，我们能够看到资源使用状况：
```
llm_load_tensors: ggml ctx size =    0.20 MiB
llm_load_tensors: using CUDA for GPU acceleration
llm_load_tensors: mem required  =  246.29 MiB
llm_load_tensors: offloading 60 repeating layers to GPU
llm_load_tensors: offloading non-repeating layers to GPU
llm_load_tensors: offloaded 63/63 layers to GPU
llm_load_tensors: VRAM used: 19454.15 MiB
1
2
3
4
5
6
7
```
使用 nvidia-smi 查看资源，显存使用了 21GB。
```
|===============================+======================+======================|
|   0  NVIDIA GeForce ...  Off  | 00000000:01:00.0 Off |                  Off |
| 31%   36C    P8    27W / 450W |  21123MiB / 24564MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
1
2
3
4
5
```
我们还是用相同的文章内容进行测试，速度已经非常棒了。

当然，这个模型的特点是支持 200K 文本。所以，如果你有多张卡或者大显存的资源，不妨调整 --ctx-size 到 200K 试试看。

我们再进行一个简单的测试，分别并要求模型输出两种不同的指定格式：

我们在尝试不给出提示的前提下，要求模型输出 JSON 格式：

看起来，似乎确实还不错？下次吃瓜可以用模型总结出的技巧试试看。

最后

关于零一万物 34B 模型的基础使用，先聊到这里。后面有机会，我们继续聊聊一些更实际的使用，包括 SFT、将这个模型接入到流行的开源应用中。

那么，就先写到这里吧。

–EOF

我们有一个小小的折腾群，里面聚集了一些喜欢折腾、彼此坦诚相待的小伙伴。

我们在里面会一起聊聊软硬件、HomeLab、编程上、生活里以及职场中的一些问题，偶尔也在群里不定期的分享一些技术资料。

关于交友的标准，请参考下面的文章：

致新朋友：为生活投票，不断寻找更好的朋友

当然，通过下面这篇文章添加好友时，请备注实名和公司或学校、注明来源和目的，珍惜彼此的时间 😄

关于折腾群入群的那些事

本文使用「署名 4.0 国际 (CC BY 4.0)」许可协议，欢迎转载、或重新修改使用，但需要注明来源。署名 4.0 国际 (CC BY 4.0)

本文作者: 苏洋

创建时间: 2023年11月26日
统计字数: 13966字
阅读时间: 28分钟阅读
本文链接: https://soulteary.com/2023/11/26/locally-run-the-yi-34b-large-model-of-kai-fu-lee.html
相关阅读:
c语言，c++,java和python这些语言有何区别？编译型编程语言编译语言,解释型编程语言解释型语言
 Python实现天文计算
 【0基础入门Python】你不得不看的Python学习方法
 C/C++面试题总结
 ROS下机器人系统仿真及部分SLAM建图
 操作系统线程死锁
 AI大模型引领未来智慧科研暨ChatGPT自然科学高级应用
 【深度学习】笔记2-模型在测试集的准确率大于训练集
 IDEA如何运行SpringBoot项目（超详细截图）
LeetCode 0938.二叉搜索树的范围和：深度优先搜索（可中序遍历）
原文地址：https://blog.csdn.net/soulteary/article/details/134634971

写在前面

让 CPU 和 GPU 都忙活起来：llama.cpp 的另类使用

准备模型程序运行环境

下载合适的模型文件

编译使用 GPU 的 llama.cpp

使用 llama.cpp 运行 34B 大模型

性能提升技巧：调整 llama.cpp 加载模型层数

性能提升技巧：选择更小巧的模型

最后