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

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

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

写在前面

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

HuggingFace 社区中的 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

我们将上面的内容保存为 Dockerfile,然后使用下面的命令来完成稍后使用的镜像的构建(项目中的相关文件保存在 soulteary/docker-yi-runtime/docker/Dockerfile):

docker build -t soulteary/yi-34b-runtime:20231126 .

构建完毕运行环境后,我们可以使用下面的命令进入容器环境,继续折腾:

docker run --rm -it -p 8080:8080 --gpus all --ipc=host --ulimit memlock=-1 -v `pwd`:/app soulteary/yi-34b-runtime:20231126 bash

进入容器后,我们可以使用熟悉的 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      |
|=============================================================================|
+-----------------------------------------------------------------------------+

因为我们选择的是 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

下载合适的模型文件

零一万物的官方模型发布页面是 01-ai/Yi-34B,里面包含了两种格式的模型,如果你想转换模型格式为我们可以运行的 ggml 或者 gguf 格式,可以参考前文中的文章。如果你懒得进行这个量化步骤,可以直接下载 HuggingFace 社区其他社区用户量化好的版本:

  • TheBloke/Capybara-Tess-Yi-34B-200K-DARE-Ties-GGUF
  • NousResearch/Nous-Capybara-34B
  • 等等

如果你想快速下载可靠的模型,可以使用下面的命令:

# 我们可以使用 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 ${模型存储路径}

这里偷个懒,我测试选择的是 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

下载模型参考上文中的说明,不难得到下载命令,如果你要下载其他的模型,可以参考并进行调整:

# 比如
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

模型保存目录结构如下:

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

完成了模型的下载之后,我们就可以进行最后一项准备工作了。

编译使用 GPU 的 llama.cpp

在解决完毕运行环境的问题后,我们需要手动下载 llama.cpp 的代码,并做一些目录准备:

# 下载代码
git clone https://github.com/ggerganov/llama.cpp.git
# 进入代码目录
cd llama.cpp/

我们使用 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.  ====

当看到 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

这里面有许多有趣的工具,不过网上关于它们的介绍其实不多,更多的都是关于主程序 main 的简单使用。后面的文章,有机会我们再来逐步展开这些工具中更有趣的玩法。

本篇文章,我们主要使用 server 程序,来跳过各种“分数”,一窥真实的模型能力。为了方便后面使用,我们可以将这个纯粹的二进制文件复制到我们容器中的 /app 目录中:

cp server /app/

开始测试前的完整目录结构如下:

├── 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

使用 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 

上面的命令中,我们在加载模型的时候,设置了上下文尺寸为 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}

通过访问 http://主机IP:8080 ,我们能够访问到一个简洁的 Web 界面。

llama.cpp 的 WebUI

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

我这里使用一篇前两天“机器之心”发布的关于 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 |
+-------------------------------+----------------------+----------------------+

当我们点击上面的 “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)

如果此时我们查看 CPU 使用状况,将能够看到多数 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)

这里能够看出模型的摘要总结能力还是很强的。

针对第一个问题,模型的回答

不过,第一轮对话执行之后,用来分摊 CPU 和内存压力的显存,使用量接近 15GB 显存啦。

|===============================+======================+======================|
|   0  NVIDIA GeForce ...  Off  | 00000000:01:00.0 Off |                  Off |
| 31%   38C    P8    28W / 450W |  15277MiB / 24564MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+

当然,就这么泛泛的测试一轮,未免有点儿戏。我们来进行对轮对话测试。这里为了考验模型的基础能力,所有的问题我都不会加“问号”,并且尽量用代词而非具体的内容来和它交流。

各种角度的“唠嗑”

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

当然,因为我们使用了“资源保守策略”,在启动程序的时候,只将模型的 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

程序启动过程中,我们可以知道这将会在初始化过程中,占据显卡的 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

程序实际运行完毕后,我们在 nvidia-smi 中得到的资源占用情况会更多一些:

|===============================+======================+======================|
|   0  NVIDIA GeForce ...  Off  | 00000000:01:00.0 Off |                  Off |
| 31%   35C    P8    27W / 450W |  21913MiB / 24564MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+

然后我们再次使用相同的机器之心发布的内容,来进行模型测试,你会发现模型的处理速度快了非常多,比之前大概快了接近 3 倍。

速度提升到了 9.x

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

多问几轮,速度和质量都有一些下降

速度比之前稍微慢了一些,变成了 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

同样,模型加载的时候,我们能够看到资源使用状况:

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

使用 nvidia-smi 查看资源,显存使用了 21GB

|===============================+======================+======================|
|   0  NVIDIA GeForce ...  Off  | 00000000:01:00.0 Off |                  Off |
| 31%   36C    P8    27W / 450W |  21123MiB / 24564MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+

我们还是用相同的文章内容进行测试,速度已经非常棒了。

速度来到了 33.x tokens / sec

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

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

知乎最经典的帖子之一,吃瓜技巧

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

转换为 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

今天的文章本地运行“李开复”的零一万物 34B 大模型分享到此就结束了,感谢您的阅读。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/85453.html

(0)
编程小号编程小号

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注