Chiphell - 分享与交流用户体验

标题: Zen4的AVX512有用么 [打印本页]

作者: 我輩樹である 时间: 2023-8-3 19:56
标题: Zen4的AVX512有用么
本帖最后由我輩樹である于 2023-8-3 19:59 编辑

llama.cpp是一种cpp写的可以在CPU上推理和微调的框架，最近非常流行。

我就分别在7840U、Z1 Extreme和13980HX上运行了下。结果有点出乎意料。

llama.cpp本身是支持AVX512的，它对三个CPU的检测如图：

(, 下载次数: 66)

左边是7840U，右边是Z1 Extreme，中间是13980HX。

首先是Z1E保留了AVX512指令集群，VNNI都保留了，阉割的貌似是FPGA那块。

最终的token生成速度，Z1E比7840U甚至要更快一点。

最慢的当然是不支持AVX512的13980HX，而且是32线程输给16线程，这。。。

生成对比可以看下面三个视频：

7840U
https://www.bilibili.com/video/BV168411d7zn/

Z1E（请忽略背景声）
https://www.bilibili.com/video/BV14j411r77j

13980HX
https://www.bilibili.com/video/BV1cN411a7gU

作者: zhuifeng88 时间: 2023-8-3 19:58
本帖最后由 zhuifeng88 于 2023-8-3 20:09 编辑

llama.cpp是毫无疑问的memory bandwidth bound啊, 你看imc性能计数或者profiling一下就能发现的

他的实现只能bs=1, 每生成一个token就需要从内存完整访问一遍所有权重

另外llama.cpp的avx512仅用在浮点计算部分, 量化模型虽然检测了avx512vnni的flag, 但完全没有相关实现, 用的只是avxvnni(当然在memory bandwidth bound下这个其实无关紧要), 数据load/store和scale都是用avx2完成的, 这和他的量化实现是以32B块为单位有关, 不进行大幅改动的前提下没办法用avx512进行相关操作(这在单路spr上结合load队列深度限制最终造成load bandwidth无法超过大约170GB/s, 可以通过修改量化块大小回避, 但会失去模型文件兼容性)

作者: 我輩樹である 时间: 2023-8-3 20:08

zhuifeng88 发表于 2023-8-3 19:58
llama.cpp是毫无疑问的memory bandwidth bound啊, 你看imc性能计数或者profiling一下就能发现的

另外llama ...

memory bandwidth之前测的好像amd的还慢一些。

作者: zhuifeng88 时间: 2023-8-3 20:15

我輩樹である发表于 2023-8-3 20:08
memory bandwidth之前测的好像amd的还慢一些。

而且视频可以看到你跑的是量化模型
量化的模型目前的实现实际上是几乎不会运行任何avx512的代码的

作者: 我輩樹である 时间: 2023-8-3 20:16

zhuifeng88 发表于 2023-8-3 20:15
而且视频可以看到你跑的是量化模型
量化的模型目前的实现实际上是几乎不会运行任何avx512的代码的 ...

模型是Q4

作者: zhuifeng88 时间: 2023-8-3 20:18

我輩樹である发表于 2023-8-3 20:16
模型是Q4

耗时95%以上的大头ggml_vec_dot_q4_0_q8_0里压根没有一丁点512宽度的代码
对于avx512vnni整个repo里甚至只是个检测有无的flag并且显示一下, 没有其他东西了

作者: 我輩樹である 时间: 2023-8-3 20:21

zhuifeng88 发表于 2023-8-3 20:18
耗时95%以上的大头ggml_vec_dot_q4_0_q8_0里压根没有一丁点512宽度的代码
对于avx512vnni整个repo里甚至 ...

那我不解为什么有这种情况。刚才又测了下，intel的memory各项指标都是领先的。

作者: zhuifeng88 时间: 2023-8-3 20:25

我輩樹である发表于 2023-8-3 20:21
那我不解为什么有这种情况。刚才又测了下，intel的memory各项指标都是领先的。 ...

因为intel的main cache现在是l2, l3整个都是victim cache, 在这种victim完全无效的场景下 intel的l3等效容量就是0

作者: 我輩樹である 时间: 2023-8-3 20:26

zhuifeng88 发表于 2023-8-3 20:25
因为intel的main cache现在是l2, l3整个都是victim cache, 在这种victim完全无效的场景下 intel的l3等效 ...

我去跑个profiling看看。

作者: 灵乌路空 时间: 2023-8-3 20:48
所以到底有没有用啊

作者: ghgfhghj 时间: 2023-8-3 20:51
玩ps3模拟器有用

作者: a6057c 时间: 2023-8-3 21:04
llama这种大模型推理几乎纯吃带宽不吃算力，上多强的AVX都不如超内存有用。13980HX是4800内存吧？

作者: lh0ngfu 时间: 2023-8-3 21:46
llama.cpp 让我这种老年 Mac Pro 垃圾桶也体验了一下 AI 的快乐

作者: lshzh 时间: 2023-8-3 22:04

zhuifeng88 发表于 2023-8-3 19:58
llama.cpp是毫无疑问的memory bandwidth bound啊, 你看imc性能计数或者profiling一下就能发现的

他的实现 ...

llama.cpp不全是memory bound，在一个一个往外跳tok时确实是卡内存带宽，因为这个时候内部全在算矩阵向量乘法。
在你输入一大段文字几十上百toks等模型理解时是卡计算的，这个时候batch size默认512，内部是在算矩阵矩阵乘法的。如果说想对比计算能力，应该看耗时中prompt eval这一项

不过话说回来，这一步llama.cpp好像是直接调blas库的，所以不如直接看各自cpu最优blas库的gemm速度了

作者: wangzhiqiang 时间: 2023-8-3 22:14

ghgfhghj 发表于 2023-8-3 20:51
玩ps3模拟器有用

作者: zhuifeng88 时间: 2023-8-3 22:49
本帖最后由 zhuifeng88 于 2023-8-3 23:29 编辑

lshzh 发表于 2023-8-3 22:04
llama.cpp不全是memory bound，在一个一个往外跳tok时确实是卡内存带宽，因为这个时候内部全在算矩阵向量 ...

cpu侧ggml的量化推理是他自己实现的, 并没用blas库, (而且常见blas库也没针对分块量化数据的实现), 至于你说prompt的compute bound, 这部分差不多是忽略不计的耗时, 至少几百以内都是忽略不计, 不是什么需要关心的部分
65B模型双路genoa跑q4_1, 427 prompt token总共3秒而已
(, 下载次数: 57)

作者: pdvc 时间: 2023-8-3 22:58
目前主要是PS3模拟器有用

作者: ioko 时间: 2023-8-3 23:04
前几年很有用，现在没卵用了。至少没人提了！

作者: 我輩樹である 时间: 2023-8-3 23:25

a6057c 发表于 2023-8-3 21:04
llama这种大模型推理几乎纯吃带宽不吃算力，上多强的AVX都不如超内存有用。13980HX是4800内存吧？ ...

是的。是ddr5 4800 vs. lpddr5 7500，理论带宽我没算错的话，是76.8 vs. 60，和测试的也差不多。毕竟一个界面宽度64，一个32。

作者: lshzh 时间: 2023-8-4 00:20

zhuifeng88 发表于 2023-8-3 22:49
cpu侧ggml的量化推理是他自己实现的, 并没用blas库, (而且常见blas库也没针对分块量化数据的实现), 至于 ...

可选的，你编译时链接了blas它就会用

blas库当然没有量化实现，所以llama.cpp这时候会先解压缩量化的权重到内存里再算乘法

大部分时候prompt eval是不用太多时间，两个例外一是ctx装满的时候，这时llama.cpp会把ctx/2的内容从新过一遍，8192ctx就要重新算一下4096个tok，另一个是你想让模型给你总结文章时当然也是prompt eval占主导

最主要不是楼主想看avx512在llama.cpp上的影响嘛，那就只有这个项目好看了

作者: OstCollector 时间: 2023-8-4 00:47
你要找的是否是： https://www.phoronix.com/review/amd-epyc-avx512/9 ？

作者: liu3yang3715 时间: 2023-8-4 08:23
学习了，感谢分享~

作者: litel 时间: 2023-8-4 08:48
Intel大小核把avx512一砍, 就没人提avx512有用了

欢迎光临 Chiphell - 分享与交流用户体验 (https://www.chiphell.com/)