1. 先解决一个现实问题为什么我要冒着精度风险去量化1.1 显存是表象内存带宽才是隐藏瓶颈先说清楚大模型量化里的“量化”跟股票量化交易、资金量化指标完全是两个东西。这里说的量化是把模型权重从FP16这种高精度浮点数压成INT8、INT4这类低比特数值的技术手段。如果你是第一次被“CUDA out of memory”逼到这个领域这篇文章能帮你把原理和选型一次理清。很多教程喜欢把量化包装成数学魔法实际上它就是一笔显存账加一笔带宽账。拿一块24GB显存的消费级显卡举例想跑70B模型光是FP16权重就有140GB显存连零头都装不下。就算换成7B模型FP16权重也要14GB再算上KV Cache和激活值长上下文一开24GB照样紧张。我最初接触大模型量化就是被这种“放不下、跑不动”的处境逼着去试的后来发现事情远不止省显存这么简单。生成每个token时GPU原则上要把模型权重从显存里完整读一遍这个读取成本直接受内存带宽约束。RTX 4090显存带宽约1008GB/s一个7B的4bit量化模型权重约4GB理论上每个token延迟下限是4GB除以1008GB/s大概4毫秒换算成速度能到250token/s左右。换成FP16的7B模型权重14GB延迟下限变成14毫秒速度上限直接掉到70token/s上下。所以在显存和带宽双受限的场景里量化不单是“塞得下”的问题它直接决定了输出能跑多快。CPU上的差异更夸张。普通双通道DDR5内存带宽只有90GB/s上下FP16的7B模型读一遍要150毫秒以上跑起来就是著名的“老牛拉车”换成4bit模型体积变小四倍同样条件下能快三倍。这也是llama.cpp这类本地推理工具默认就推GGUF量化文件的原因——省显存是真的变快也是真的。1.2 量化不是简单“砍精度”而是一个信息压缩问题有人把量化理解为“把浮点数四舍五入成几个整数”这个说法不算错但漏了一个关键步骤换算。一个1.23456的小数直接塞进int8会丢掉大量信息正确的做法是先定一个缩放因子scale把浮点数的分布范围映射到整数刻度上取整后用的时候再按比例还原。这个“映射、取整、还原”的过程才是量化的本质。从这个角度讲量化本质是一个信息压缩问题我要用更少的比特去表达原来数值的分布关心的不是每个数还原得对不对而是整层输出经过量化后误差够不够小。后面你会见到的GPTQ、AWQ、SmoothQuant、GGUF的K量化不管名字多花哨本质上都在回答同一个问题这个映射怎么设计才能让信息损失最小。2. 量化原理的核心scale、zero_point和反量化2.1 浮点转整数就是“归一化后取整”量化最基础的形式很简单一个浮点数组r量化到整数q公式是q clamp(round(r / scale) zero_point, q_min, q_max)反量化则把它还原回来r_approx (q - zero_point) * scalescale负责缩放zero_point负责对齐零点clamp负责把越界整数剪回合法范围。听起来简单但scale怎么取直接决定了量化误差长什么样。我写一段最朴素的示例代码方便对照理解import numpy as np def quantize_asymmetric(r, bits8): q_min, q_max 0, 2 ** bits - 1 scale (r.max() - r.min()) / (q_max - q_min) zero q_min - np.round(r.min() / scale) q np.round(r / scale zero).clip(q_min, q_max) return q, scale, zero def dequantize(q, scale, zero): return (q - zero) * scale实际推理时可以先把整数反量化回浮点再计算也可以直接用整数算子计算。这两条路线在工程上差别很大前者主要为了省存储和带宽后者为了启用硬件加速计算。很多4bit方案属于前者服务端常见的W8A8全整形推理属于后者。2.2 对称与非对称zero_point到底什么时候需要权重分布通常以0为中心两边大致对称这时候用对称量化强制zero_point等于0公式能简化成q clamp(round(r / scale), q_min, q_max)scale直接用整个数组的最大绝对值除以整数上限。对称量化的好处是计算内核简单很多硬件整数单元没有偏置加法对称结构更友好。但激活值分布不一定对称。经过ReLU之后大量激活值是非负的最小可能是0最大可能是10这时候硬套对称量化等于拿[-127, 127]的刻度去表达[0, 10]的区间一半整数空间被浪费精度白白损失。所以一旦要量化激活、KV Cache或者做全整形推理非对称量化搭配逐通道、逐组的scale和zero_point就变得非常重要。权重量化方案里对称量化很常见因为权重天生近似对称激活量化必须考虑非对称这是理解整篇内容的关键线索。2.3 从INT8压到INT4损失到底从哪来INT8有256个整数刻度INT4只有16个表达能力强弱一眼可见。打个比方FP32是把无限细分的游标卡尺INT8是一把256格子的卷尺INT4是一把只有16格子的粗尺读数精度完全不同。量化误差近似等于scale的一半scale等于数值区间除以刻度数。区间越大刻度越少误差越大。到INT4这个位宽时极端权重和长尾分布很难被16个格子覆盖于是“模型变笨”的现象就出来了。其实不是模型变笨是少数关键参数的表达精度跟不上。这也是为什么后续所有高级量化方案都在避重就轻把有限的刻度资源优先分给影响更大的权重提前补偿掉那些可以预判的误差。理解了这一点后面看任何量化论文都会轻松很多。3. 主流量化方案的原理与取舍从PTQ到GGUF3.1 朴素舍入不够用GPTQ用二阶信息补偿误差最早期权重量化就是对浮点数直接四舍五入行业叫RTNRound To Nearest。对大模型来说RTN压到INT8基本能扛很多7B模型变成INT8后几乎无感但压到INT4就开始崩因为单纯四舍五入的误差被矩阵乘法逐层放大某些层会集体跑偏。GPTQ是目前服务端最主流的4bit方案思路是拿少量校准数据跑一遍模型找到每层权重变化对输出误差的影响再逐个权重做最优补偿。它把量化后的输出误差写成目标函数用Hessian矩阵二阶梯度信息近似误差曲面然后贪心地调整剩余权重的舍入方向让一部分权重的舍入误差去抵消另一部分误差。我当时看GPTQ论文也觉得绕后来总结成一句话它不让每个权重单独硬舍入而是站在整层输出的高度做全局补偿谁对最终结果影响大就优先保谁。实测下来GPTQ 4bit在7B以上模型的困惑度损失往往只有零点几这也是AutoGPTQ、vLLM这些框架把GPTQ作为默认选项的原因。不过要注意GPTQ是权重量化推理时大多数实现还是要把权重反量化回高精度计算它省的是显存和带宽省不了算力。3.2 AWQ和SmoothQuant除了权重激活也在闹情绪权重分布再对称激活值也在不断捣乱。激活张量里存在大量离群值某些维度数值特别大一旦把激活也量成INT8一个离群值就会把scale拉大剩下普通数值全部丢精度。AWQ的核心观察是大模型里大约1%的权重通道比其余通道重要得多。它不靠梯度而是通过激活值统计识别出这些显著通道然后对权重做通道级缩放让量化在次要位置上多损失一点在关键位置上少损失一点。AWQ不需要重训校准开销比GPTQ还小精度却非常扎实这是它在vLLM、TensorRT-LLM里站稳脚跟的原因。SmoothQuant走的是另一条路。它观察到激活离群值往往集中在固定通道于是将激活除以一个平滑系数、权重乘以同系数数学上完全等价但激活分布被压均匀了权重也能一起用INT8张量核跑。这是服务端全整数量化推理的关键路径TensorRT-LLM里的W8A8方案基本绕不开这个思路。一句话总结只做权重量化时GPTQ和AWQ已经够好想榨干硬件算力就要让激活和权重一起量化这时SmoothQuant这类方案才是核心。3.3 QAT把量化误差塞回训练流程里PTQ是模型训练完后用少量校准数据完成量化成本低是大模型量化的首选QAT则是训练阶段就把量化误差加进去让模型学会“带伤作战”。QAT的实现叫fake quantization前向传播时把模拟量化和反量化后的结果喂给网络反向传播时通过直通估计STE让梯度近似穿过量化算子。模型在训练过程中会自动调整权重分布去适应16个或256个粗糙刻度。因为量化误差是在训练中内生出来的模型有机会针对性地“长出”抗压能力所以QAT的效果通常比PTQ好尤其在小模型和超低比特场景下差距明显。它的代价也明确需要训练数据、训练算力和完整训练流程。对市面上的开放大模型来说绝大多数部署场景不值得为4bit重跑一遍QAT训练几十亿参数的成本早就超过买一块更大显存显卡了。所以QAT更多出现在对精度极度敏感、或模型本身需要长期维护的生产项目中。3.4 GGUF的K量化本地玩家绕不开的选择聊大模型量化绕不开llama.cpp和GGUF格式GGUF里的Q4_K_M、Q5_K_S就是量化实践中出现频率最高的文件名。K-quants和GPTQ思路完全不同。它按超块组织权重一个super-block装256个权重然后根据权重重要性在块内混合使用不同比特位宽一部分权重用2bit、一部分用6bit、平均等效4bit。这种混合方式把有限的bit预算分配给了更关键的位置压缩率和质量兼顾。Q4_K_M、Q5_K_S里的S、M、L分别对应更小、中等、更大的体积与精度取向。本地玩家喜欢GGUF首先是格式封装完整分词器、模型配置、metadata全打包进单文件下载即用Ollama、LM Studio这些工具都直接认。其次是可以CPU和GPU之间灵活offload显存不够就把一部分层丢回内存跑。最后是K量化的校准成本极低文件体积直接决定显存占用部署体验极其友好。我自己的习惯是本地能上Q4_K_M先上Q4_K_M质量敏感任务升Q5_K_M或Q6_K极少情况回到FP16。这套组合基本覆盖了我从7B到70B的日常使用。3.5 别忘了微调场景NF4与QLoRA的关系量化不只在推理侧发光微调侧同样重要。QLoRA就是用4bit量化加载基础模型权重然后插入LoRA低秩适配器进行微调的技术让一张24GB显卡微调70B模型成为可能。QLoRA用的格式叫NF4全称4bit NormalFloat。它基于信息论设计针对权重近似正态分布的特性做了最优映射普通INT4是均匀分布刻度NF4则把更密集的刻度放在权重出现概率高的区域所以同等bit下精度更好。训练时基础模型权重冻结在NF4梯度通过反量化后的权重反向传播真正更新的是LoRA那几十万参数。这也是量化的一道隐藏分水岭如果你只想部署选GPTQ、AWQ、GGUF这类成熟方案如果你要微调得认准NF4/QLoRA这条技术路线两者不能混着用。4. 硬件视角下的量化真相算力、带宽与指令集4.1 为什么说推理瓶颈是“内存墙”而不是“计算墙”很多文章介绍量化时喜欢列FLOPS却不讲带宽。其实自回归生成场景里每个token都要把所有权重读一遍才能算下一个token这个读取成本远大于纯粹的计算成本。算一笔账。RTX 4090的FP16算力约82TFLOPS显存带宽约1TB/s跑7B Q4模型时每生成一个token要读取4GB权重耗时约4毫秒。在这4毫秒里实际需要的浮点运算量远没有喂饱和GPU算力真正的天花板是带宽而不是FLOPS。这叫“内存墙”权重大小和读取速度决定生成速度算力再高也填不满。这带来一个有趣现象量化模型在GPU上有时加速不明显因为显存够用、权重又小计算反而顶上来了同样的量化模型在CPU上速度提升立竿见影因为CPU和内存之间的带宽更稀缺。量化省下的每一个字节最终都流向了系统最痛的瓶颈。4.2 不同位宽在不同硬件上的真实支持情况量化要和硬件绑定看不是bit越少越好。INT8是几乎所有平台都支持的一档NVIDIA的张量核、Intel的AMX、各种NPU里都能跑整数矩阵乘。服务端全整数量化推理INT8是最成熟的选择。FP8是数据中心的新宠H100这一代起有原生FP8张量核它不是整数而是低比特浮点分为e4m3和e5m2两种格式。e4m3动态范围约正负448精度接近FP16的六七成适合大多数模型权重和激活e5m2动态范围更大但精度低适合梯度这类跨度大的数值。如果你的显卡比较老FP8权重也未必被硬件加速很多时候只是省了显存计算仍会被打回FP16完成。INT4是目前讨论最热烈、但硬件原生支持最弱的一档。GPU上很少有针对4bit的高性能矩阵乘内核。大家常说的“4bit模型跑得快”本质是因为权重文件小了、带宽需求低了、能塞进显存了而不是硬件把4bit算得飞快。CPU端llama.cpp通过精巧的算子和打包方式确实能受益但原理依然是围绕带宽做文章。4.3 显存不够时CPU offload怎么搭配实际操作里24GB显存跑70B的Q4模型其实也悬权重就有40GB左右。这时要么多卡要么做CPU offload。用llama.cpp举例你可以通过-ngl参数把一部分层放到GPU剩下的放内存。GPU层数多速度快但显存压力大全部丢CPU速度可能只剩每秒一两token。我自己的做法是先保证模型能加载再把耗时占比高的前若干层尽量放GPU其余层随它去。自回归生成中每层都会被访问任何一层落在CPU都会拖慢整体所以这本质是速度与容量的取舍。如果是服务端多用户部署就别考虑CPU offload了vLLM、TensorRT-LLM这类框架在KV Cache管理、连续批处理和调度上专业得多。这时应当选择AWQ或GPTQ 4bit模型再配合张量并行才能真正把服务吞吐做起来。5. 量化效果的评估与避坑5.1 用perplexity做体检损失多少算合格判断量化有没有把模型“搞笨”最直接的方法是用困惑度perplexity在固定测试集上对比。llama.cpp自带的perplexity工具就能做transformers社区也有现成脚本跑法不复杂./build/bin/llama-perplexity \ -m ./models/qwen-7b-q4_k_m.gguf \ -f ./data/wikitext-2-raw/wiki.test.raw \ -ngl 999同一个模型FP16版和量化版在同一个测试集上的perplexity差值比任何“我觉得好像变笨了”都靠谱。按我的经验7B级别模型从FP16换到Q4_K_Mperplexity上升通常在0.1到0.3之间要是涨了0.5以上先别急着骂量化检查一下校准集和实际任务是否同分布。还有一点别只看全局指标。代码类模型用新闻语料做校准金融对话模型用通用文本做量化测试集上可能很漂亮一上真实业务就露馅。校准数据集的任务相关性远比数量重要。5.2 越小越脆为什么小模型怕量化大模型反而抗造有个反直觉的规律模型越大量化后的相对损失越小模型越小量化越容易翻车。原因是大型模型的参数冗余度高分布更稳定同一层里大量连接可以分担误差小模型本来就没有多少余量每个参数都承担着较重职责一压缩能力就塌方。社区里“2B模型用INT4基本没法看70B模型用INT4照样聪明”的现象就是这么来的。不是量化算法偏心是冗余度差着数量级。所以小模型建议保守一点上Q6_K甚至直接用FP16大模型反而可以放心压到4bit。这条经验对选型的影响非常大。5.3 KV Cache量化与RoPE位置编码的兼容问题聊到长上下文躲不开KV Cache量化。KV Cache是推理中持续增长的显存大户几千token时还好几十万token长上下文下KV Cache体积会反超权重。所以不少推理框架提供了KV量化选项比如llama.cpp的cache_type_k/q8_0。但KV Cache和权重不一样里面存的是Key和Value。Key在RoPE旋转位置编码之后参与注意力计算对数值精度极其敏感。RoPE会把高维向量旋转成不同相位很小的量化误差经过旋转就可能被放大成错位。实践上要压KV位宽要么选用带补偿的方案要么先用q8_0这类接近无损的档位。别为了省显存直接压KV到4bit长上下文的输出质量会肉眼可见地崩。5.4 实战中容易忽略的几个坑分组粒度、文件单位、框架偏好量化配置里有个参数叫group size例如group size 128表示每128个权重共用一组scale和zero_point。分组越小scale越贴合局部数值分布精度越好但计算开销越大。很多人只看bit数不看group size同样标称Int4group size 32和group size 256的模型实际效果差得不止一点半点。还要小心单位陷阱。模型参数量说的GB通常指二进制GiB约1.07GB而量化文件标注的GB往往是十进制。下载前看一眼文件的实际字节数差0.5GB可能就决定你的显存还够不够塞。这个细节我吃过亏下载了号称“刚好能装下”的模型加载时又差一口气。最后是框架偏好。服务端vLLM对GGUF的支持并不完善优先选GPTQ或AWQ格式配合PagedAttention本地单机用户就老老实实用GGUFOllama和LM Studio都会帮你处理好细节。跨框架迁移之前先确认目标框架的算子表否则模型是能加载速度却可能慢到没法用。6. 选型不同场景下到底选哪种量化6.1 一张表捋清主流格式格式/方案7B权重体积近似精度推荐硬件主要场景FP16/BF16约14GB基准显存充足微调、精度敏感Q8_0GGUF约7.7GB几乎无损CPU/GPU通用本地高质量Q4_K_MGGUF约4.1GB很小损失CPU/GPU、可offload本地均衡首选Q2_KGGUF约3GB明显损失显存极紧应急跑大模型GPTQ Int4约4GB很小损失NVIDIA GPUvLLM/服务端AWQ Int4约4GB很小损失NVIDIA GPU服务端质量敏感场景FP8W8A8约7GB极小损失H100等新卡数据中心高吞吐这个表只适合当起点。实际选型永远要追着推理框架的算子支持走追着硬件指令集走追着校准数据的任务分布走。6.2 不同部署形态的推荐组合个人本地笔记本或台式机GPU 8到24GB首选GGUF Q4_K_M综合速度和体积最均衡。显存紧张降到Q4_K_S质量敏感升Q5_K_M跑3B以下的小模型就别折腾量化FP16最省心。服务端GPUA100、H100这类数据中心卡老架构选AWQ或GPTQ Int4新架构能上FP8就FP8。在线服务并发量大时FP8的硬件张量核支持能在延迟和吞吐上同时占优。现在不少团队在H100上直接用FP8跑7B到13B模型这也是数据中心里比4bit更值得关注的方案。边缘设备RK3588、Jetson等这里不是大模型的主场但量化原理相通。NPU算子支持天差地别比如RK3588上用RKNN-Toolkit做YOLOv5 Int8量化时很多层需要混合精度或逐层优化不能直接搬GPU的量化结果。核心策略永远是先让工具链默认量化跑通再根据精度报告逐层调。6.3 最后聊聊我这几年的切身经验量化技术这几年演进非常快今天好用的方案过一年可能就让位给新思路。但底层的scale、zero_point、信息压缩、带宽瓶颈这套原理并没有变过。我自己踩坑踩到最多的就是不看硬件就选位宽、不看框架就下格式、不看任务就挑校准集。这三件事可以说是量化实践里最大的翻车点。所以我的建议一直是预算允许就不极端追低bit卡确实不够再量化量化之后永远用指标说话别靠“感觉”判断模型变没变笨先求工程上能落地再谈精度优化。如果你能做到这三点大模型量化对你来说就不再是玄学而是一笔清清楚楚的性价比账。