无需量化，在树莓派上运行 LLaMA2 70B 模型

[lwch]

想必大家对 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

推理提速:

1. 可通过分布式集群来实现矩阵运算达到 tensor 并行
2. 可通过量化手段减少模型大小并提高计算速度

[modestdeveloper]

stars 一下

[graetdk]

速度会慢多少呢？ 10 倍左右？

[lwch]

@graetdk 我在 i7-10710U 的 NUC 上用 8 个核心跑 7B 模型不缓存参数大概 1 分多才能出一个 token ，缓存后 16~17s 左右一个 token

[skinfiter]

在家用 nas 上试了一下，20 分钟还没返回，估计树莓派也不行 大佬加油啊 争取把配置要求降下来

[nomagick]

说一句话得花一年

[lwch]

@skinfiter 哈哈，看来这些嵌入式设备上面还得做量化，不过未来可以搞一个树莓派集群来做分布式计算

[bt7vip]

@lwch 16s 一个 token ，前景无限啊，现在板 u 内存 2k 一套 12 代 i5 就能上线，1 万就是 5 台集群啊，那不起飞

[lwch]

@bt7vip 不能这么算，网络传输需要耗时，实际做集群计算有可能会比单机更慢，这个需要测试了才知道

[duojiao]

@lwch #6 外行人想问下，量化后，树莓派上能提升到什么样的一个程度

[lwch]

@duojiao 哈哈，不要关心速度，做了参数延迟加载后可在低内存设备上运行可大大降低运行成本，速度只能靠堆集群和做各种各样的缓存来提升

[GeekGao]

速度那么慢 就没啥使用价值了

[lwch]

@GeekGao 你可以这么计算，载入 70B 模型需要 130G 显存，按 4090 的 24G 显存计算，载入整个模型需要至少 7 张卡，换算成成本就是 14W+，这些钱总共可以买 200 多个树莓派，每个 8G 内存总共 1.6T 以上，如果组起集群的话计算效率并不会比 4090 慢多少

[lwch]

@GeekGao 用这 1.6T 内存在高并发情况下，可以并行处理更多的 batch

[GeekGao]

@lwch 这只是理论吧，实际上组成树莓派集群后还有很多性能问题，例如总线速度

[lwch]

@GeekGao 树莓派只是打个比方，你当然可以在云上申请几台机器来加快推理速度，这个项目的主要目标还是为了降低大模型的使用成本，使普通人也可以跑上 70B 模型

[kneo]

核心代码用 go 写的？这不慢个十倍八倍对不起用户吧。

[lwch]

@kneo 再慢也能超过 python 不是吗

[kneo]

@lwch 没人用纯 Python 写这东西啊……

[lwch]

@kneo 那再举个例子谷歌搜索核心代码也是 go 的，你觉得以他的体量计算量会很小吗，速度不是一样不慢的

[kneo]

@lwch

第一，关于 Google 搜索核心代码也是 Go ，是否有信息来源？ Google 内部代码量巨大，模块众多，连所谓的核心代码指的是哪一部分都很难确定。

第二，Google 的数据量巨大，集群性能远比单机单核性能重要。和你的应用场景截然相反。

第三，作为通用语言，Go 并不慢。但是 AI 相关代码的性能大量依赖 CPU （就不提 GPU 了）指令优化。需要大量的经验和技巧。性能想赶上业界 c/cpp 版本，甚至 Python 的混合版本，我觉得需要相当的经验和技巧。我简单搜了一下你的项目，没发现有 SIMD 之类的代码，我对性能不是很乐观。

第四，没有实测而谈性能实属嘴炮。我不应该因为开发语言否认你的劳动。我本人这几年也是用 Go 开发比较多，提 Go 和性能纯粹是路过多了一嘴。用 Go 做 AI 并非完全不靠谱，只是需要想当的工作量。如果 OP 能努力把这件事做好对圈子也是一件幸事。不过性能比对十分重要，建议有时间考虑在主页加上与各版本的实测对比。