查看原文
其他

NeurIPS 2023 | 英特尔提出全新部署方法,在CPU上进行高效LLM推理

岳廷 PaperWeekly
2024-08-22
©PaperWeekly 原创 · 作者 | 岳廷
研究方向 | 大语言模型
论文链接 : 
https://arxiv.org/pdf/2311.00502.pdf

代码链接 : 

https://github.com/intel/intel-extension-for-transformers

要解决的问题:随着 GPT 4-turbo 的爆火,可以预见,大语言模型(LLM)将逐渐在个人电脑上普及(微软甚至已在最新 Windows 11 上有类似功能)。考虑到显卡价格高昂,不是每个人都能负担得起。因此,用 PC 上的 CPU 对 LLM 进行高效推理将成为一种理想选择。同时,对用户来说,LLM 更快的响应速度,更少的内存占用,将带来更好的用户体验。因此提升 LLM 在 CPU 上推理性能,将持续成为研究热点。
解决方案:来自英特尔的研究人员提出了一种有效的方法,可以使 LLMs 的部署更加高效。该方法支持 LLM INT4 自动权重量化流程,并设计了一个特殊的 LLM runtime,使用高度优化的内核来加速 LLM 在 CPU 上的推理。

结果:结果显示,在第四代 Intel® Xeon® 可扩展处理器上,6B 到 20B 参数的 LLM 平均单个 Token 生成延迟为从 20ms 到 80ms,显著快于人类阅读速度(人类大约每 200ms 阅读一个 Token),同时准确性损失仅为 1%,接近 FP32 基线。



方案
大语言模型(LLM)参数数量惊人,需要大容量内存,并会产生高的推理延迟,这使得模型推理成本高昂。
而量化技术常用来降低推理成本。在业界,对权重参数采用低 bit 量化(如 4bit),激活函数采用更高 bit 量化(如 16bit)逐渐成为趋势。不少优秀的工作已经证明,对权重参数进行 4 bit 量化能够降低 LLM 推理成本。开源社区也正在接受这种方案,并基于 ggml 库提供 CPP 实现,如 llama.cpp 和 starcoder.cpp。但这些优化通常针对英伟达 CUDA 库,而与 CPU 不兼容导致无法工作。
为在 CPU 上进行高效 LLM 推理,提出由以下 2 部分组成的优化方案,如图 1 所示:
  • 自动 INT4 量化流程:利用 Intel Neural Compressor 提供 INT4 量化支持,并自动生成 INT4 模型;
  • 推出高效的 LLM runtime:为 CPU 设计专门的张量库,并支持所有主流指令集,如 AVX2、AVX512、AVX512_VNNI 和 AMX(Advanced Matrix Extensions)。结果显示,在第四代 Intel® Xeon® 可扩展处理器上,6B 到 20B 参数量 LLM 的平均 Token 生成延迟为从 20ms 到 80ms,显著快于人类阅读速度(人类大约每 200ms 阅读一个 Token),同时准确性损失仅为 1%,接近 FP32 基线。

1.2 自动 INT4 量化流程

自动 INT4 量化流程在整个过程中起到关键作用,流程支持对权重自动化 INT4 量化,量化算法基于英特尔神经压缩器(Intel Neural Compressor)开发,该工具支持主流 INT4 量化配置,如 GPTQ、SignRound、AWQ、TEQ 和 RTN(round-to-nearest),自动量化流程允许在不同的量化配置、不同的粒度(按通道或按组)、不同的组大小(32、64、128 ... 1024)上进行配置调整。每个配置生成用于评估的 INT4 模型。当 INT4 模型达到精度目标后,该模型将被送到到 LLM runtime以进行性能评估。

1.2 高效的LLM runtime

LLM runtime 用于推理自动 INT4 量化生成模型,实现在 CPU 进行高效推理。图2描述了 LLM runtime 中的关键组件:
  • 绿色组件(CPU Tensor 和 LLM  Optimizations)为针对 LLM 推理专门设计
  • 蓝色组件(memory management, thread scheduler, operator optimization and fusion)为 runtime 中的通用组件

CPU 张量库:受 cutlass 的模板设计启发,开发了用于线性代数子程序的 CPU 张量库。张量库为 x 86 CPU 提供了 INT4 内核的全面支持,如表 1 所示,其中 AMX 在最新的 Intel Xeon 可扩展处理器中可用,VNNI 在 Intel 和 AMD CPU 中都可用。

LLM 优化:大多数 LLM 通常是 Decoder-Only 的 Transformer模型。鉴于生成 next Token 的独特特性,KV 缓存的优化对 LLM 推理性能至关重要。图 3 展示了 KV 缓存的优化。左图(a)显示的是默认的 KV 缓存,新 Token 的生成需要为所有 Token(示例中为 5)重新分配内存;右图(b)显示的是带有预分配 KV 内存的优化 KV 缓存,每次只需更新新 Token 即可。



结果

2.1 实验设置

实验选择参数规模从 7B 到 20B 的流行 LLM 架构。使用开源数据集 lm-evaluation-harness 评估 FP32 和 INT4 模型准确性,数据集包括 lambada、hellaswag、winogrande、piqa 和 wikitext。性能评价指标为,在第四代 Intel® Xeon® 可扩展处理器上测量 LLM 生成下一个 Token 的延迟。

2.2 准确性

在上述数据集上评估准确性,并在表 2 中显示平均准确率。从表中可以看出,INT4 模型的准确率与 FP32 模型的准确率几乎相当,相对于 FP32 基线仅损失不到 1%。

2.3 性能

使用 LLM runtime 和流行的开源 ggml 方案测量 LLM 生成下一个 Token 的延迟。表 3 列出了在输入和输出 Token 均为 32 的代理配置下的延迟。可以看到组大小为 32 时,提升 1.3 倍。而组大小为 128 时,提升 1.6 倍。需注意的是,ggml 解决方案只支持组大小 32。

尽管 LLM runtime 展示了比 ggml 方案更好的性能优势,但通过额外的性能调优 LLM runtime 仍有可能进一步提高性能,提升方向如 LLM runtime 中的线程调度器、CPU 张量库中的阻塞策略等。



总结

文章提出的方案不论是量化模型的准确性,还是推理速度,都实现了 SOTA,对于期望在 PC 端部署 LLM 的研究者,该方案具有很强的工程实用性。毕竟 Intel 对自家的 CPU 更了解!



更多阅读



#投 稿 通 道#

 让你的文字被更多人看到 



如何才能让更多的优质内容以更短路径到达读者群体,缩短读者寻找优质内容的成本呢?答案就是:你不认识的人。


总有一些你不认识的人,知道你想知道的东西。PaperWeekly 或许可以成为一座桥梁,促使不同背景、不同方向的学者和学术灵感相互碰撞,迸发出更多的可能性。 


PaperWeekly 鼓励高校实验室或个人,在我们的平台上分享各类优质内容,可以是最新论文解读,也可以是学术热点剖析科研心得竞赛经验讲解等。我们的目的只有一个,让知识真正流动起来。


📝 稿件基本要求:

• 文章确系个人原创作品,未曾在公开渠道发表,如为其他平台已发表或待发表的文章,请明确标注 

• 稿件建议以 markdown 格式撰写,文中配图以附件形式发送,要求图片清晰,无版权问题

• PaperWeekly 尊重原作者署名权,并将为每篇被采纳的原创首发稿件,提供业内具有竞争力稿酬,具体依据文章阅读量和文章质量阶梯制结算


📬 投稿通道:

• 投稿邮箱:hr@paperweekly.site 

• 来稿请备注即时联系方式(微信),以便我们在稿件选用的第一时间联系作者

• 您也可以直接添加小编微信(pwbot02)快速投稿,备注:姓名-投稿


△长按添加PaperWeekly小编



🔍


现在,在「知乎」也能找到我们了

进入知乎首页搜索「PaperWeekly」

点击「关注」订阅我们的专栏吧


·
·

继续滑动看下一个
PaperWeekly
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存