使用模型量化提高 CPU 上的大语言模型推理速度

使用模型量化提高 CPU 上的大语言模型推理速度

在AI领域，为基于LLM的大规模生产级应用提供所需的计算资源是一项重要挑战。本文将介绍如何使用Intel的IPEX工具在CPU上优化大语言模型推理速度，通过bf16、int8和int4精度的量化技术，显著改善CPU的推理时延。

应用开发中的推理时延

推理时延是AI应用生产环境中最关键的参数之一，其重要性仅次于应用安全性。基于LLM的应用的时延或吞吐量通常用每秒词元(token)数来衡量。如下方的推理处理序列简图所示，语言模型首先处理词元，然后将其重新组合为自然语言。

以这种方式来解释推理有时会让人产生误解，因为我们通过对传统生产软件范式加以抽象化来分析AI应用的这个组成部分。没错，AI应用有细微的差别，但是归根结底，我们讨论的仍是单位时间内的事务。从应用设计的角度来看，如果我们把推理也视作事务的话，那么问题就变简单了。比如，某个聊天应用有如下要求：

• 平均每小时300个用户会话
• 每个用户每个会话平均5个事务(LLM推理请求)
• 每个事务平均生成100个词元
• 每个会话平均产生10,000毫秒(10秒)的开销，用于用户身份验证、防护、网络时延和预处理/后处理。
• 当用户与聊天机器人主动交互时，平均花费30,000毫秒(30秒)时间进行响应。
• 平均总活动会话时间目标是3分钟及以内。

经过简单的计算，我们很快就可以估算出LLM推理引擎所需的大致时延，如下图所示。

在生产环境中实现所需的时延阈值具有一定挑战，如果您需要在不增加计算基础设施成本的情况下实现该阈值，难度更大。我们将在后文探索如何通过模型压缩显著改善推理时延。

模型压缩

模型压缩有着广泛的含义，包含各种技术，例如模型量化、蒸馏、剪枝等。从本质上来说，这些技术的主要目标是降低神经网络的计算复杂度。

我们今天重点介绍的方法是模型量化，包括降低权重(有时还包括激活)的字节精度，降低矩阵运算的计算负载以及移动较大、较高精度值所带来的内存负担。下图展示了将fp32权重量化为int8的过程。

值得一提的是，在推理过程中，从fp32(全精度)量化为int8(四分之一精度)，模型复杂度降低了4倍，但是时延不会降低4倍，因为推理时延受多种因素的影响，不只涉及与模型相关的属性。

在许多领域，不存在放之四海皆准的万能方法，模型压缩亦是如此。接下来，我将介绍我非常喜欢的3种使用IPEX量化模型的技术：

bf16或fp32精度推理

这项技术将神经网络中的权重量化为用户定义的精度。它非常适合较小的模型，例如具有不到10亿参数的LLM。

它非常容易实现：使用huggingface transformer，将模型加载至内存，并使用特定的IPEX llm优化函数ipex.llm.optimize(model, dtype=dtype)，通过设置dtype=torch.bfloat16进行优化。我们可以激活半精度推理功能，相比全精度(fp32)和原始方法，推理时延显著下降。

在我们即将探讨的3种压缩技术中，这是最容易实现的一种(按照独有的代码行数来衡量)，它的净优化效果最不明显(以未经量化的模型为基准)。

SmoothQuant(int8)

这项技术解决了LLM量化的核心挑战，包括跨所有层和词元处理激活通道中的大规模异常值，这是传统量化技术难以有效解决的一个常见问题。这项技术对模型中的权重和激活应用了一个联合数学变换。该变换极大降低了激活中异常值和非异常值之间的差异，代价是提高了权重中的这一比例。这一调整使Transformer层更“易于量化”，确保在成功应用int8量化的同时不会降低模型质量。

下方是一个简单的SmoothQuant实施——省略了用于创建DataLoader的代码，DataLoader是一个常用的PyTorch组件，您可以找到关于它的详细资料。SmoothQuant是一个精度感知训练后量化方法，您可以通过提供校准数据集和模型，制定基准，并限制语言建模的精度下降。校准模型首先生成一个量化配置，稍后将它连同SmoothQuant映射一起传输至ipex.llm.optimize()。在执行时应用SmoothQuant，您可以使用.generate()方法对模型进行测试。

SmoothQuant是一项强大的模型压缩技术，相比全精度模型，它能够帮助显著降低推理时延。尽管如此，您需要做一些前期工作，以准备校准数据集和模型。

仅限权重的量化(int8和int4)

相比应用于激活和权重的传统int8量化方法，仅限权重的量化(WOQ)能够更好地平衡性能和精度。需要注意的是，int4 WOQ需要在计算之前反量化为bf16/fp16(图4)，这将带来一定的计算开销。张量级非对称就近舍入(RTN)量化是一种基本的WOQ技术，它会带来一些挑战并造成精度下降(来源)。文献(Zhewei Yao, 2022)表明，对模型权重进行分组量化有助于保持精度。由于我们仅在计算步骤进行权重反量化，因此尽管存在这个额外的计算步骤，内存优势仍旧非常明显。

下方的WOQ实施展示了利用这项技术，只需编写几行代码，即可对来自Hugging Face的模型进行量化。和前面的实施一样，首先加载从Hugging Face下载的模型和分词器。我们可以使用get_weight_only_quant_qconfig_mapping()方法配置WOQ方案。然后将该方案连同待优化和量化的模型一起传输至ipex.llm.optimize()函数。随后使用.generate()方法，将量化模型用于推理。

如您所见，WOQ是一项强大的技术，可以将模型压缩到原始大小的几分之一，并且对语言建模功能的影响非常有限。

结论和讨论

作为一名英特尔工程师，我始终与英特尔IPEX工程团队保持密切合作。因此，对于IPEX优势和开发路线图，我有自己的独到见解，并且会优先选择IPEX工具。然而，对于那些不想管理额外关联组件，追求极简开发的开发者，PyTorch提供了3种量化方案：Eager模式、FX Graph模式(维护中)以及PyTorch 2导出量化。这些替代选项可能不如IPEX专业，但是同样强大。

无论选择哪种技术，模型压缩都会导致不同程度的语言建模性能下降，一般在1%以内。为此，您必须在量化前评估应用的容错能力，并建立全精度(FP32)和/或半精度(BF16/FP16)模型性能的基准。

对于检索增强生成(RAG)等利用上下文学习的应用，模型压缩也许是理想之选。在这些场景中，关键任务知识在推理时被直接输入到模型中，从而显著降低风险，即使运行低容错应用也不担心。

量化是解决LLM推理时延问题的一种出色方法，无需升级或扩展计算基础设施。无论您面临什么样的使用场景，IPEX都值得一试。只需编写几行代码，即可使用它。

您还可以尝试这样做：

• 选择一个正在加速器上以全精度运行的现有模型，并在CPU上以int4/int8精度对其进行测试
• 探索这3种技术，并确定哪种技术最适合您的使用场景。请记得比较语言建模性能的下降，而不仅仅是时延。
• 将您的量化模型上传至Hugging Face Model Hub！上传后，请告知我，我很想去看一看！