这是一个创建于 403 天前的主题，其中的信息可能已经有所发展或是发生改变。
想必大家对 transformer 模型的认识已经非常深刻了，这里就不多做介绍了。今天我用纯 go 语言实现了一个项目来做 LLaMA2 模型的推理，其实要在小内存设备上运行大语言模型方法很简单，只需要在运行到某一层时将该层的参数加载到内存中进行计算即可。
项目地址: https://github.com/lwch/llama2.go
各规格模型所需内存大小：
| Model | Precision | Memory | Memory(Cached Params) |
|---|---|---|---|
| 7B | bf16 | 600M+ | 25G+ |
| 13B | bf16 | 1G+ | 43G+ |
| 70B | bf16 | 3G+ | untest |
模型推理方式:
cat << EOF | ./llama2 text-completion -m 7B.model [--cache]
Translate English to French:
sea otter => loutre de mer
peppermint => menthe poivrée
plush girafe => girafe peluche
cheese =>
EOF
.... 此处省略一堆中间过程
Translate English to French:
sea otter => loutre de mer
peppermint => menthe poivrée
plush girafe => girafe peluche
cheese => fromage
Traanslate French to English:
lait => milk
推理提速:
- 可通过分布式集群来实现矩阵运算达到 tensor 并行
- 可通过量化手段减少模型大小并提高计算速度
第 1 条附言 · 2023-10-18 14:38:59 +08:00
通过一系列的优化，目前 7B 模型可达到 13~14s/token ，速度提升 18%
第 2 条附言 · 2023-10-19 11:32:24 +08:00
通过优化，去除矩阵转置计算后，7B 模型目前可达到 5~6s/token
第 3 条附言 · 2023-10-19 14:56:39 +08:00
通过缓存 fp32 参数，目前 7B 模型已可以达到 1.2~1.6s/token ，相比于最初版本速度提升 10 倍以上
第 4 条附言 · 2023-10-19 16:37:13 +08:00
将矩阵乘法替换至 gonum 库中的 blas 方法，目前 7B 模型已可以达到 800ms~1.2s/token
 |
1
modestdeveloper 2023-10-17 15:48:20 +08:00
stars 一下
|
 |
2
graetdk 2023-10-17 15:58:04 +08:00
速度会慢多少呢？ 10 倍左右？
|
 |
3
lwch OP @graetdk 我在 i7-10710U 的 NUC 上用 8 个核心跑 7B 模型不缓存参数大概 1 分多才能出一个 token ，缓存后 16~17s 左右一个 token
|
 |
4
skinfiter 2023-10-17 16:57:18 +08:00
在家用 nas 上试了一下，20 分钟还没返回，估计树莓派也不行 大佬加油啊 争取把配置要求降下来
|
 |
5
nomagick 2023-10-17 17:02:11 +08:00
说一句话得花一年
|
 |
7
bt7vip 2023-10-17 18:31:03 +08:00 via Android
@lwch 16s 一个 token ，前景无限啊，现在板 u 内存 2k 一套 12 代 i5 就能上线，1 万就是 5 台集群啊，那不起飞
|
|
10
lwch OP @duojiao 哈哈，不要关心速度，做了参数延迟加载后可在低内存设备上运行可大大降低运行成本，速度只能靠堆集群和做各种各样的缓存来提升
|
 |
11
GeekGao 2023-10-18 11:45:53 +08:00
速度那么慢 就没啥使用价值了
|
|
12
lwch OP @GeekGao 你可以这么计算，载入 70B 模型需要 130G 显存，按 4090 的 24G 显存计算，载入整个模型需要至少 7 张卡，换算成成本就是 14W+，这些钱总共可以买 200 多个树莓派，每个 8G 内存总共 1.6T 以上，如果组起集群的话计算效率并不会比 4090 慢多少
|
|
15
lwch OP @GeekGao 树莓派只是打个比方，你当然可以在云上申请几台机器来加快推理速度，这个项目的主要目标还是为了降低大模型的使用成本，使普通人也可以跑上 70B 模型
|
 |
16
kneo 2023-10-18 19:08:54 +08:00 via Android
核心代码用 go 写的？这不慢个十倍八倍对不起用户吧。
|
|
19
lwch OP @kneo 那再举个例子谷歌搜索核心代码也是 go 的，你觉得以他的体量计算量会很小吗，速度不是一样不慢的
|
|
20
kneo 2023-10-19 10:00:52 +08:00 via Android  1
@lwch
第一，关于 Google 搜索核心代码也是 Go ，是否有信息来源？ Google 内部代码量巨大，模块众多，连所谓的核心代码指的是哪一部分都很难确定。 第二，Google 的数据量巨大，集群性能远比单机单核性能重要。和你的应用场景截然相反。 第三，作为通用语言，Go 并不慢。但是 AI 相关代码的性能大量依赖 CPU （就不提 GPU 了）指令优化。需要大量的经验和技巧。性能想赶上业界 c/cpp 版本，甚至 Python 的混合版本，我觉得需要相当的经验和技巧。我简单搜了一下你的项目，没发现有 SIMD 之类的代码，我对性能不是很乐观。 第四，没有实测而谈性能实属嘴炮。我不应该因为开发语言否认你的劳动。我本人这几年也是用 Go 开发比较多，提 Go 和性能纯粹是路过多了一嘴。用 Go 做 AI 并非完全不靠谱，只是需要想当的工作量。如果 OP 能努力把这件事做好对圈子也是一件幸事。不过性能比对十分重要，建议有时间考虑在主页加上与各版本的实测对比。 |
|
21
lwch OP @kneo 所以我上面也说了，单机的性能是有限的，想要提升整体性能只能靠堆集群来实现，目前为止这个项目还处于单机运行状态，至于说具体以哪种方式来做并行计算这个是需要实际测试的。我认为 go 语言天生就是高并发高吞吐量的代名词，因此我一开始就选用了 go 语言而不是其他的语言来进行开发，就 go 语言本身而言从单机版到集群版也更容易一些。
另如果 10 台机器的集群计算性能可以达到 GPU 的一半，我觉得大部分的资本家也是可以接受的，毕竟总体成本下降了好几个数量级。 |
|
22
kneo 2023-10-19 11:57:27 +08:00
@lwch 最后提醒一下，你的直接竞争对手是 C/C++/Rust （比如 llama.cpp ，llama2.c ）版本。而不是 GPU 版本。
不管怎么说，祝有成。 |
|
23
lwch OP @kneo 今天做了不少优化，目前 7B 模型单机运行已经可降低到 1.2~1.6s/token ，但 CPU 并未全部跑满可能还有一定的优化空间
|
 |
24
lost7 2023-10-19 16:19:33 +08:00
真的是好思路，特地过来回复一下。这可以出篇不错的 paper 了
|
 |
25
rekulas 2023-10-20 21:43:45 +08:00
太 cool 了,想问一下为何单人工作量就可以实现一个大模型推理库呢,按我之前的理解至少得一个团队👍
|
|
26
lwch OP @rekulas 只实现模型推理的话其实并不复杂，要实现整个深度学习框架就非常麻烦。每个 tensor 的正向传播、反向传播、梯度计算等，我实现了一个 https://github.com/lwch/gotorch 库包装了 libtorch 库里面已经实现了上百个算子，这还只是 pytorch 中的一部分，想要实现一个完整的框架一个人难以完成。
|
Select Language