Zen4的AVX512有用么
本帖最后由 我輩樹である 于 2023-8-3 19:59 编辑llama.cpp是一种cpp写的可以在CPU上推理和微调的框架，最近非常流行。
我就分别在7840U、Z1 Extreme和13980HX上运行了下。结果有点出乎意料。
llama.cpp本身是支持AVX512的，它对三个CPU的检测如图：
左边是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 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, 可以通过修改量化块大小回避, 但会失去模型文件兼容性) zhuifeng88 发表于 2023-8-3 19:58
llama.cpp是毫无疑问的memory bandwidth bound啊, 你看imc性能计数或者profiling一下就能发现的
另外llama ...
memory bandwidth之前测的好像amd的还慢一些。 我輩樹である 发表于 2023-8-3 20:08
memory bandwidth之前测的好像amd的还慢一些。
而且视频可以看到你跑的是量化模型
量化的模型目前的实现实际上是几乎不会运行任何avx512的代码的 zhuifeng88 发表于 2023-8-3 20:15
而且视频可以看到你跑的是量化模型
量化的模型目前的实现实际上是几乎不会运行任何avx512的代码的 ...
模型是Q4 我輩樹である 发表于 2023-8-3 20:16
模型是Q4
耗时95%以上的大头ggml_vec_dot_q4_0_q8_0里压根没有一丁点512宽度的代码
对于avx512vnni整个repo里甚至只是个检测有无的flag并且显示一下, 没有其他东西了 zhuifeng88 发表于 2023-8-3 20:18
耗时95%以上的大头ggml_vec_dot_q4_0_q8_0里压根没有一丁点512宽度的代码
对于avx512vnni整个repo里甚至 ...
那我不解为什么有这种情况。刚才又测了下，intel的memory各项指标都是领先的。 我輩樹である 发表于 2023-8-3 20:21
那我不解为什么有这种情况。刚才又测了下，intel的memory各项指标都是领先的。 ...
因为intel的main cache现在是l2, l3整个都是victim cache, 在这种victim完全无效的场景下 intel的l3等效容量就是0 zhuifeng88 发表于 2023-8-3 20:25
因为intel的main cache现在是l2, l3整个都是victim cache, 在这种victim完全无效的场景下 intel的l3等效 ...
我去跑个profiling看看。 所以到底有没有用啊[傻笑] 玩ps3模拟器有用 llama这种大模型推理几乎纯吃带宽不吃算力，上多强的AVX都不如超内存有用。13980HX是4800内存吧？ llama.cpp 让我这种老年 Mac Pro 垃圾桶也体验了一下 AI 的快乐 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速度了
ghgfhghj 发表于 2023-8-3 20:51
玩ps3模拟器有用
+1[偷笑] 本帖最后由 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秒而已
目前主要是PS3模拟器有用[流汗] 前几年很有用，现在没卵用了。至少没人提了！ a6057c 发表于 2023-8-3 21:04
llama这种大模型推理几乎纯吃带宽不吃算力，上多强的AVX都不如超内存有用。13980HX是4800内存吧？ ...
是的。是ddr5 4800 vs. lpddr5 7500，理论带宽我没算错的话，是76.8 vs. 60，和测试的也差不多。毕竟一个界面宽度64，一个32。 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上的影响嘛，那就只有这个项目好看了
你要找的是否是： https://www.phoronix.com/review/amd-epyc-avx512/9 ？ 学习了，感谢分享~ Intel大小核把avx512一砍, 就没人提avx512有用了[偷笑]
页:
[1]