Zen4的AVX512有用么

锄禾日当毋

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


Z1E（请忽略背景声）


13980HX

ytmxkj

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, 可以通过修改量化块大小回避, 但会失去模型文件兼容性)

sanqiren

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

peterll

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

chaoji

模型是Q4

asdjkl

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

lifesinger

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

axwww

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

bluestardm

我去跑个profiling看看。

aylue

所以到底有没有用啊