LLM 推理量化评估:FP8、INT8 与 INT4 的全面对比

一、背景

本文简要介绍一篇关于 LLM 推理量化评估的文章。虽然文中某些结论可能与许多人的直觉不符,但在真实业务场景中,我们得出的结论却与这些发现非常相似。例如,在面试中与一些候选人讨论 LLM 推理量化时,尽管不少人使用了 H20/H800/4090 等 GPU 用于 LLM 推理,仍普遍坚持使用 INT8 量化,而极少尝试 FP8 推理;此外,也有不少人认为 NVIDIA 的高端 GPU(如 A100 和 H100)主要适用于训练场景,在推理中的成本过高,从而忽视了在推理中使用这些硬件的优势和潜力。

我们的一些实践经验是:针对 LLM 推理场景,FP8 往往比 INT8、AWQ-INT4 这些方案具有更小的损失,比如 FP8 往往在 1% 以内,而 AWQ-INT4 甚至可能达到 2%-3%,尤其是 INT8、AWQ-INT4 在不同的任务上差异会比较大;使用 H100/H800 进行 LLM 推理,往往可以获得比 A30/A100/H20 更低的推理成本;最后,在公司中关注精度指标(算法研究员、业务)与负责性能/成本指标的往往是不同的团队,此时 FP8 可能是个权衡之下不错的选择。

PS:其实有些时候使用模型量化甚至不如直接选择一个同系列小模型,比较典型的例子是 LLaMA-2 7B 和 LLaMA-2 13B。如下图 Table 3 所示,LLaMA-2 13B 量化后的精度可能和 LLaMA-2 7B 差不多,如果量化带不来相应倍数(13B/7B)的加速,反而不如直接使用小模型。

二、论文摘要

尽管 LLM 量化在推理加速方面非常流行,但各种量化格式的准确性-性能之间的权衡仍然存在很大的不确定性。本文中,作者对量化准确度进行了全面的研究,评估了整个 LLaMA-3.1 系列模型在学术基准和现实任务中的常见量化格式(FP8、INT8、INT4)。此外,作者还研究考察了量化模型与未量化模型生成的文本之间的差异。除了基准之外,作者还提出了一些量化改进,使得能够获得最先进的准确度结果。

作者的实验涵盖了 500,000 多次单独评估,并得出了几个关键发现:

  1. FP8 权重和激活量化(W8A8-FP)在所有模型上基本都是无损的。

  2. INT8 权重和激活量化(W8A8-INT)在适当调整后,准确度下降幅度很低,仅为 1%-3%。

  3. INT4 权重量化(W4A16-INT4)与 W8A8-INT 不相上下。

为了解决在给定环境的“最佳”格式问题,作者使用流行的开源 vLLM 框架在各种 GPU 上进行推理分析,发现 W4A16 适合 Latency 敏感场景(Synchronous Inference)以及中端 GPU 上的 Throughout 敏感场景(Asynchronous Inference)。同时,W8A8 很适合高端 GPU 上的 Throughout 敏感场景。

三、实验环境

3.1 评估基准

主要包含 3 类评估:

  • 学术基准:主要是 Open LLM Leaderboard V1 和 Open LLM Leaderboard V2,包括 MMLU、MMLU-Pro、GSM、GPQA、ARC-Challenge 等。

  • 现实世界基准:主要是 Arena-Hard-Auto-v0.1、HumanEval、HumanEval+、LMSYS Chatbot Arena 等。

  • 文本相似性分析:主要是 ROUGE 和 BERTScore 等。其中,ROUGE-1 衡量量化与非量化模型输出之间的 Token 级重叠,而 ROUGE-L 则通过关注最长公共子序列来捕捉结构相似性。BERTScore 评估基于 RoBERTa-large 模型上下文嵌入计算的 Token 级上下文相似度。

3.2 评测模型

当前大部分量化方法都会采用 LLaMA 系列模型来进行量化评估,比如 [2404.14047] An Empirical Study of LLaMA3 Quantization: From LLMs to MLLMs 2 [2] 中专门针对 LLaMA 3 系列模型进行了评估。最新的一些量化方法 [2410.05265] PrefixQuant: Static Quantization Beats Dynamic through Prefixed Outliers in LLMs [3] 和 [2410.12168] COMET: Towards Partical W4A4KV4 LLMs Serving [4] 等也都聚集在 LLaMA 3 系列模型。因此本文中作者也以 LLaMA 3 Instruct 模型作为主要评估模型。

3.3 量化方法

本文主要评估了 3 种量化类型:

  • W8A8-FP:所有线性层的权重和激活都是 FP8 格式。

  • W8A8-INT8:Transformer Block 中所有线性层的权重和激活都使用 INT8 格式。

  • 对于权重:采用对称式 Per Channel 的 GPTQ 量化方法。

  • 对于激活:采用 Per Token 的动态量化技术。

  • W4A16-INT4:Transformer Block 中所有线性层权重被量化为 INT4,而激活值则保持在16 位精度。权重通过 GPTQ 量化进行压缩,应用于每组 128 个连续元素,并采用均方误差(MSE)最优的裁剪因子。

其实对于 W4A16-INT4 量化有很多方案,不过作者这里主要专注于在当前 vLLM 推理框架中已经支持的高效方案。如下图 Table 1 所示,作者对比了常见的 GPTQ 和 AWQ 方案,总体来说,作者观察到:

  • 在学术基准中,两种方法的结果基本持平。AWQ 的优势只有 0.23 和 0.35(100分)。

  • 在现实基准中,GPTQ 始终以 2.9 和 0.8 的较大差异优于 AWQ,因此作者选择 GPTQ 作为权重量化的主要方法。

3.4 机器成本

如下图 Table 9 所示为作者选择评估的 GPU 服务器以及其价格(综合考虑购买成本、运维成本等各方面的因素),其中 8xH100 价格大概为 8xA100 价格的两倍,也符合预期。这也就是说,如果在 H100 上推理性能可以超过 A100 的两倍,那么使用 H100 推理就会更有性价比。

如下图是 Pricing | Lepton AI [5] 上的服务器价格,其 H100 与上述 Lambda Labs 的基本一致,但是其 8xA100 和 1xA6000 的价格却将近是 Lambda Labs 的两倍,甚至 8xA100 比 8xH100 还贵,有点离谱:

四、精度评估

4.1 学术基准&现实世界基准

如下图 Table 2 所示为其在 Open LLM Leaderboard V1 上的评估结果,几种方法都获得了很不错的精度恢复,只有 W4A16-INT 在 8B 模型上损失稍大,这也与我们的经验相符(模型越小、量化 Bit 数越少越容易出现比较大的损失)。

由于很多模型在 HellaSwag、MMLU 和 ARC 等基准上已经达到人类基线,此外部分新模型出现了数据污染现象,导致 Open LLM Leaderboard V1 已经不太好评估各种模型、方案的差异。因此相应作者进一步升级提出了 Open LLM Leaderboard V2(Open-LLM performances are plateauing, let’s make the leaderboard steep again [6])。如下图 Table 3 所示为本文作者在 Open LLM Leaderboard V2 上的评估结果,可以看出,各种评分也确实有了明显下降,而各种量化方案的差异也进一步突出出来。

  • W4A16-INT 在 3 个模型上的精度差距都进一步扩大,尤其是 LLaMA 3 8B 上下降了 4% 左右。

  • 奇怪的是,W8A8-INT 在 70B 和 405B 上的量化损失也达到了 2% 左右,反而在 8B 模型上没有什么损失。

如上图 Table 3 右侧同样包含了现实世界基准的评估,现实基准与学术基准类似。

需要关注的是:W8A8-FP 在所有的评估中都基本上没有损失,而 W8A8-INT 和 W4A16-INT 则在不同的任务上有不同的表现。

4.3 文本相似性评估

如下图 Figure 6 所示,在文本相似性的几个评估中,FP8 也基本都获得了最优的结果,而 INT8 和 INT4 各有优劣。

五、性能评估

5.1 Latency 敏感场景

作者将这种场景称为 Synchronous Deployment,具体来说是指用户对 Latency 很敏感,期望延迟越低越好。Continuous Batching 会增加吞吐,但同时也会导致 Latency 的增加,因此这种场景通常会使用很小的 Batch Size,这里使用的 Batch Size 为 1,也就是同时只有一个用户请求。

如下图 Table 5 所示,作者对比了不同模型规模、GPU 类型以及量化方案及应用场景下同步部署的推理性能。其中黑体为成本最低的方案,可以看出:

  • W4A16-INT 相比 BF16 可以将成本降低 2x-3x,Latency 降低 1.5x-2x。

  • 对于 405B 模型,W4A16-INT 可以大幅降低显存开销,使用更少的 GPU 即可以实现相应的推理,这也有效地降低了通信带来的延迟,最终甚至可以实现 6x-7x 的成本降低。

需要说明的的是:当 Batch Size 很小时,LLM Inference 存在明显的 Memory Bound,W4A16-INT 可以明显降低访存,这也是为什么 W4A16-INT 往往在比较小的 Batch Size 能实现比较明显加速的主要原因。

5.2 Throughput 敏感场景

作者将这种场景称为 Asynchronous Deployment,具体来说是指用户对吞吐很敏感,期望吞吐越高越好。LLM Inference 场景要想实现比较高的吞吐,需要尽可能大的 Batch Size,因此这里同时会有多个用户请求。

如下图 Table 6 所示,作者同样进行了全面的测试,可以看出:

  • 在高端 GPU(A100、H100)上,W8A8 比 W4A16-INT 更具性价比,当然 H100 上使用 FP8 比 INT8 也是更优的选择。

  • 在同样的量化方案下:H100 比 A100 更具性价比(Query/$ 更高),更是明显优于 A6000。

如何学习大模型 AI ?

由于新岗位的生产效率,要优于被取代岗位的生产效率,所以实际上整个社会的生产效率是提升的。

但是具体到个人,只能说是:

“最先掌握AI的人,将会比较晚掌握AI的人有竞争优势”。

这句话,放在计算机、互联网、移动互联网的开局时期,都是一样的道理。

我在一线互联网企业工作十余年里,指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家,也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑,所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限,很多互联网行业朋友无法获得正确的资料得到学习提升,故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述

第一阶段(10天):初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识,对大模型 AI 的理解超过 95% 的人,可以在相关讨论时发表高级、不跟风、又接地气的见解,别人只会和 AI 聊天,而你能调教 AI,并能用代码将大模型和业务衔接。

  • 大模型 AI 能干什么?
  • 大模型是怎样获得「智能」的?
  • 用好 AI 的核心心法
  • 大模型应用业务架构
  • 大模型应用技术架构
  • 代码示例:向 GPT-3.5 灌入新知识
  • 提示工程的意义和核心思想
  • Prompt 典型构成
  • 指令调优方法论
  • 思维链和思维树
  • Prompt 攻击和防范

第二阶段(30天):高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习,学会构造私有知识库,扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架,抓住最新的技术进展,适合 Python 和 JavaScript 程序员。

  • 为什么要做 RAG
  • 搭建一个简单的 ChatPDF
  • 检索的基础概念
  • 什么是向量表示(Embeddings)
  • 向量数据库与向量检索
  • 基于向量检索的 RAG
  • 搭建 RAG 系统的扩展知识
  • 混合检索与 RAG-Fusion 简介
  • 向量模型本地部署

第三阶段(30天):模型训练

恭喜你,如果学到这里,你基本可以找到一份大模型 AI相关的工作,自己也能训练 GPT 了!通过微调,训练自己的垂直大模型,能独立训练开源多模态大模型,掌握更多技术方案。

到此为止,大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗?

  • 为什么要做 RAG
  • 什么是模型
  • 什么是模型训练
  • 求解器 & 损失函数简介
  • 小实验2:手写一个简单的神经网络并训练它
  • 什么是训练/预训练/微调/轻量化微调
  • Transformer结构简介
  • 轻量化微调
  • 实验数据集的构建

第四阶段(20天):商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知,可以在云端和本地等多种环境下部署大模型,找到适合自己的项目/创业方向,做一名被 AI 武装的产品经理。

  • 硬件选型
  • 带你了解全球大模型
  • 使用国产大模型服务
  • 搭建 OpenAI 代理
  • 热身:基于阿里云 PAI 部署 Stable Diffusion
  • 在本地计算机运行大模型
  • 大模型的私有化部署
  • 基于 vLLM 部署大模型
  • 案例:如何优雅地在阿里云私有部署开源大模型
  • 部署一套开源 LLM 项目
  • 内容安全
  • 互联网信息服务算法备案

学习是一个过程,只要学习就会有挑战。天道酬勤,你越努力,就会成为越优秀的自己。

如果你能在15天内完成所有的任务,那你堪称天才。然而,如果你能完成 60-70% 的内容,你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传CSDN,朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费

在这里插入图片描述

<think>好的,我现在需要回答用户关于在NVIDIA RTX 4090上使用Ollama运行DeepSeek R1 14B模型的q8量化版本时,输出tokens的大概数量。首先,我需要了解用户的问题核心。用户可能想知道在这样的配置下,生成tokens的速度如何,每秒能生成多少个,或者总共有多少tokens可以生成。 首先,我应该回顾之前用户的问题历史。之前用户询问了如何改善Ollama的eval rate,也就是生成速率。现在用户可能是在特定硬件模型配置下,想要了解具体的性能表现。因此,我需要结合之前的建议,比如模型量化、GPU加速、参数调整等,来估计当前的输出速度。 接下来,我需要确定几个关键因素:RTX 4090的性能参数、DeepSeek R1 14B模型的特点、q8量化的影响,以及Ollama在这些条件下的表现。 RTX 4090拥有24GB显存,足够处理较大的模型。对于14B参数的模型,尤其是量化到8位(q8),显存占用应该比原版更低,因此4090应该能轻松加载整个模型到显存中,避免内存显存之间的数据传输延迟,这有利于提高生成速度。 DeepSeek R1 14B模型的结构也会影响生成速度。模型层数、注意力头数等参数决定了每次推理的计算量。量化到8位会减少每个权重的数据大小,从而降低内存带宽需求计算量,理论上应该提升推理速度。不过,8位量化相对于更低的量化(如4位)可能速度提升不如后者明显,但精度保留更好。 Ollama的优化措施也很重要,比如是否启用了GPU加速,是否正确配置了层数分配到GPU。在之前的回答中,提到过使用--num_gpu参数来指定在GPU上运行的层数,这可以减少CPUGPU之间的数据传输,提高速度。对于14B模型,可能需要将大部分或全部层分配到GPU上,以最大化性能。 然后,我需要查找类似配置下的性能数据。例如,Llama 2 13B在RTX 3090上使用量化后的推理速度大约是多少。不过RTX 4090的性能比3090更强,尤其是在FP16INT8计算上。根据一些公开的基准测试,RTX 4090在LLM推理上的速度可能比3090快约50-100%。假设DeepSeek R1 14B q84090上的推理速度可能在每秒20-40 tokens之间,具体取决于模型的优化程度Ollama的配置。 另外,用户提到的是q8量化,即8位整数量化。更高的量化如4位相比,8位量化的模型精度更高,但速度提升可能不如4位明显。因此,速度可能介于原版4位量化之间。例如,原版14B模型可能在4090上达到每秒10-20 tokens,而4位量化可能达到30-60 tokens,所以q8可能在20-40之间。 同时,生成参数如--num_predict(生成的最大tokens数)--temperature也会影响速度。如果用户设置生成长度较长,整体生成时间会增加,但每秒生成的tokens数可能保持相对稳定。此外,温度设置较低时,模型可能更快收敛,减少生成时间。 还需要考虑Ollama的版本配置是否正确启用了GPU加速。如果用户没有正确配置GPU层数,或者显存不足以完全加载模型,可能会导致部分计算在CPU上进行,从而降低速度。因此,确保使用--num_gpu参数将所有层分配到GPU是关键。 总结来说,结合硬件性能、量化影响、模型大小配置参数,预计在RTX 4090上使用Ollama运行DeepSeek R1 14B q8时,输出速度大约在每秒20-40 tokens。但实际数值可能因具体设置优化而有所不同,建议用户进行实际测试以获得准确数据。在</think> NVIDIA RTX 4090 上使用 Ollama 运行 **DeepSeek R1 14B 模型的 q88-bit 量化)版本**时,生成的 **Tokens 速率(eval rate)** 受硬件性能、量化策略模型架构共同影响。以下是具体分析预估: --- ### **1. 硬件量化对速度的影响** - **RTX 4090 性能优势**: - 显存:24GB GDDR6X,足以容纳 14B 模型的 q8 量化版本(约占用 **10~14GB 显存**,具体取决于量化细节)。 - 计算能力:支持 FP16/INT8 加速,大幅提升矩阵运算效率。 - **q8 量化的特点**: - 8-bit 量化相比原模型(16/32 位浮点)显著降低显存占用,但速度提升可能不如 4-bit 量化明显(需权衡精度速度)。 - 预计 q8推理速度介于 **原模型 q4 量化模型之间**。 --- ### **2. 速度预估** 根据类似模型(如 LLaMA 13B)在 RTX 4090 上的实测数据: - **原模型(16-bit)**:约 **15~25 tokens/s**。 - **q4 量化模型**:约 **30~50 tokens/s**。 - **q8 量化模型**:由于保留更高精度,速度略低于 q4,预计 **20~40 tokens/s**。 对于 **DeepSeek R1 14B q8**: - **保守估计**:约 **18~30 tokens/s**(受模型结构优化差异影响)。 - **理想情况**:若模型优化良好且完全加载到 GPU,可能接近 **30~35 tokens/s**。 --- ### **3. 关键优化建议** - **最大化 GPU 利用率**: - 使用 `--num_gpu` 参数将全部模型层加载到 GPU: ```bash ollama run deepseek-r1-14b-q8 --num_gpu 40 # 假设模型总层数为 40 ``` - 确保 Ollama 启用 CUDA/Metal 加速(通过 `ollama serve` 日志确认)。 - **调整生成参数**: - 限制生成长度(`--num_predict 512`)或降低随机性(`--temperature 0.7`)以加速生成。 - **关闭后台任务**:释放显存内存带宽。 --- ### **4. 实测对比** 建议通过以下步骤自行测试实际速度: 1. **运行模型并记录时间**: ```bash ollama run deepseek-r1-14b-q8 --num_gpu 40 --num_predict 512 ``` 2. **计算 tokens/s**: - 输出 512 tokens 耗时约 15 秒 → **~34 tokens/s**。 - 耗时 25 秒 → **~20 tokens/s**。 --- ### **5. 影响因素总结** | 因素 | 对速度的影响 | |-------|---------------------------------------| | **量化程度(q8)** | 比原模型快 1.5~2 倍,比 q4 慢 20%~30% | | **GPU 层分配** | 全加载到 GPU 可避免 CPU 瓶颈 | | **生成长度** | 生成长 token 时总时间增加,但速率稳定 | | **模型优化** | 深度优化的模型(如 FlashAttention)更快 | --- ### **结论** 在 RTX 4090 上运行 **DeepSeek R1 14B q8**,**预期输出速率约为 20~35 tokens/s**。若追求更高速度,可尝试以下方案: 1. 使用 **q4 量化版本**(如有),速度可能提升至 40+ tokens/s。 2. 换用更小模型(如 DeepSeek 7B)。 3. 结合 `--num_predict` `--temperature` 进一步优化生成效率。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值