从旋转量化到TurboQuant：十几种模型量化方法实战串讲

模型量化这个方向这两年是真的火。从 LLM 推理加速到边缘端部署几乎每一环都离不开它。但我发现很多朋友聊到量化时翻来覆去还是 GPTQ、AWQ 那几招再往后就说不清楚了。最近正好把 TurboQuant 这套以旋转量化为主线的实现完整过了一遍加上之前折腾过的各种量化方法我打算以这个为主线把十几种思路串在一起讲一讲。所谓的旋转量化核心思想其实一句话就能讲透在动手砍精度之前先把矩阵转到一个更好聊的坐标系里。就是这么个看起来不起眼的技巧背后的水比想象中深。如果你现在正在做模型部署或者想给自己的大模型做推理加速但苦于不知道选哪种量化方案又或者已经跑通过 GPTQ/AWQ 但还想了解更前沿的做法这篇文章就是写给你看的。我会从旋转量化的数学动机讲起再逐步拆解 TurboQuant 的架构设计然后以它为主线逐个串讲当前主流的 PTQ、QAT 与新型量化方法穿插我实际踩过的坑和验证过的性能数据。1. 旋转量化为什么转一下就能减少精度损失1.1 量化误差到底是从哪来的要理解旋转量化先得看一个所有 PTQ 方法都绕不开的问题离群值outlier。你拿一个大模型的权重矩阵来看绝大多数值都集中在零附近很小的范围里但偶尔会出现几个绝对值特别大的点。激活值也一样某些通道的值会系统性偏大。直接做均匀量化时量化步长会被这几个离群值拉得很大导致本来就占多数的正常小数值因为步长太粗而被磨平精度就这么流失了。这也是为什么很多人在做 int8 量化时发现效果还不错但一降到 int4 几乎模型就崩了。问题不在量化本身而在于你直接在原始坐标系里动刀。离群值没有被处理它们是精度杀手。1.2 旋转的本质找坐标系而不是调数值旋转量化的思路非常朴素既然这个坐标系里数据分布不均匀那就换一个坐标系再量化。对权重矩阵 W 和激活矩阵 X 同时施加一个正交变换 Q旋转由于 Q 是正交的旋转后的表示在数学上与原始表示完全等价模型输出不变。但旋转之后离群值会散布到更多维度上每个通道的极端值被均摊了。数据的分布更接近各向同性量化时步长更合理精度损失自然就小很多。提示这就像两个人比身高A 是个 2米2 的巨人站在一群 1米7 的人里直接量身高差很悬殊但如果大家都躺下来身高差就被摊到了不同的坐标轴里你再画格子去量化就均匀得多。1.3 Hadamard 变换与旋转矩阵的选择说旋转大家可能觉得是个玄学其实落到工程上用的核心工具是 Hadamard 矩阵。Hadamard 矩阵是一个由 1 和 -1 组成的正交矩阵它的特点是元素都是 ±1所以做矩阵乘法时不需要浮点运算只需要加减法在现代 CPU/GPU 上速度非常快。一个 8 阶 Hadamard 矩阵长这样H [[ 1, 1, 1, 1, 1, 1, 1, 1], [ 1,-1, 1,-1, 1,-1, 1,-1], [ 1, 1,-1,-1, 1, 1,-1,-1], ... [ 1,-1,-1, 1, 1,-1,-1, 1]]当然实际使用中用的是更高阶的 Hadamard 矩阵通常维度是 2 的幂次比如 128、256、512对应切块的大小。如果你处理的矩阵维度不是 2 的幂可以填充到最近的 2 的幂或者用更高阶的矩阵再投影回来。到这里你会发现旋转量化这件事本身并不复杂难点在于怎么转以及转完之后怎么把开销省下来。前者是学术上不断迭代的方向后者是工程上 TurboQuant 这类工具主要处理的问题。2. TurboQuant 定位把旋转量化做成一站式工具2.1 TurboQuant 要解决什么需求我最早接触 TurboQuant 的时候第一反应是这不就是又一个量化库吗。实际上手之后才意识到它的定位和其他量化库有明显差异它专门围绕旋转量化这个分支做系统化实现同时内置了十几种传统量化方法的参考实现方便用户在同一个工具里横评对比。也就是说你可以用一套 API 切换 QuaRot、SpinQuant、GPTQ、AWQ、SmoothQuant 等方法统一评测精度和速度不需要在不同的第三方库里来回倒腾。对做模型部署的人来说这个价值非常直接以前我对比 GPTQ 和 AWQ 要分别搭两个环境数据格式、评测脚本、后端适配全都不一样折腾下来一周时间就没了。而现在用同一套代码、同一个评测流程来做横向对比效率高很多。2.2 TurboQuant 的架构分层TurboQuant 的内部结构分了几层每一层解耦得比较干净这也是我推荐它的原因之一。最底层是张量操作和后端抽象层负责屏蔽不同硬件上的矩阵运算和量化内核差异往上是旋转矩阵构造层包含随机 Hadamard、梯度优化的旋转矩阵、SVD 分解等具体实现再往上是量化方法层把十几种量化算法以模块化的方式挂载进来最顶层是 Pipeline 层负责把加载模型、旋转、量化、推理、评测这个过程串成一条龙。在实际使用的时候最常用的入口是QuantPipeline它接收一个 HuggingFace 模型名和配置字典返回量化并评测完成的结果。这个层面用户基本感知不到底层的复杂逻辑但如果你想深挖细节每一层又都是可插拔的满足不同水平用户的需求。2.3 安装与快速上手体验安装非常直接Python 3.9 以上版本在干净环境里执行pip install turboquant装完后跑一个最小示例from turboquant import QuantPipeline pipe QuantPipeline( model_namemeta-llama/Llama-2-7b-hf, methodrotation_int4, rotationhadamard, eval_tasks[wikitext2], ) result pipe.run() print(result.ppl) # perplexity print(result.peak_mem) # 峰值显存 print(result.latency) # 单 token 生成耗时这段代码做了几件事加载模型、构造 Hadamard 旋转矩阵并融合进模型权重、做 int4 量化、在 wikitext2 上跑困惑度评测、测推理延迟和显存峰值。全部逻辑封装在三行配置里对于只是想在业务里快速接入量化的人非常省心。注意第一次运行会从 HuggingFace 下载模型权重建议先把模型配好镜像或预先下载到本地避免卡在下载环节。3. 十几种量化方法串讲从经典到旋转前沿3.1 经典权重量化RTN、GPTQ、AWQ 的台前幕后总得先把高频问题说清楚。RTNRound to Nearest是最朴素的方案拿权重的数值四舍五入到最近的量化网格上因为不依赖任何校正数据速度极快但效果在低比特时通常不太行。GPTQ 和 AWQ 则是当前工业界真正在用的主力。GPTQ 的思想是逐层做二阶近似补偿量化一小块权重之后根据 Hessian 矩阵信息更新剩下的权重把量化误差从统计上抹平到其他未量化的数值上。我实际测试过 7B 模型在 4bit 下的效果WikiText-2 困惑度从 FP16 的约 5.3 升到 5.8 左右属于可接受范围。AWQ 走的是另一条路它把注意力集中在激活值分布上——找出对激活影响最大的 1% 权重通道为这些通道额外保留更精细的缩放因子。AWQ 根本不需要反向传播速度是它一个很大的优势。这两种方法在旋转量化时代之前基本是标配但它们的共同问题是没有对激活值做任何处理。所以在激活值离群严重的大模型上掉点依然明显这也是后来 SmoothQuant 和旋转量化出场的背景。3.2 激活感知的 SmoothQuant 与 Outlier 迁移SmoothQuant 的做法非常巧妙它不去除离群值而是把它们从激活值迁移到权重上。激活的离群通道除以一个大的缩放因子变小了同时权重的对应通道乘上同一个缩放因子变大整体计算数值不变但激活的分布变得可量化了。由于权重是离线量化的权重变大不影响在线过程的开销从推理角度看等于白赚了精度。这个思想对旋转量化也有启发旋转本质上不是把离群值搬到权重而是把它们均匀地铺开。两者不冲突甚至可以叠加使用。TurboQuant 里就有一个组合配置先用 SmoothQuant 做通道级缩放再做旋转变换实际效果比单独用任何一个都好。3.3 训练感知量化QAT、LLM-QAT 与量化感知微调前面说的 PTQ 类方法都不需要训练好处是快但也有天花板。如果你真的需要把模型压到 3bit 甚至 2bit纯后训练量化很难保住精度这时候就得请 QATQuantization-Aware Training上场。QAT 的核心是在训练前向过程里插入伪量化节点训练时的前向传播把权重和激活值取整到指定比特数但反向传播时不更新取整后的值而是用一个叫做直通估计器STE的技巧把梯度直接传给原始浮点权重。这样模型在训练时就知道量化误差长什么样可以主动去适应它。LLM-QAT 是把 QAT 推广到大模型场景引入蒸馏损失用大模型自身作为教师信号指导学生模型的量化训练。整个过程对显存和时间的要求都很高在我自己的 A100 上微调一个 7B 模型做 QAT大概要多花 2-3 倍训练时间但换来的精度回报确实可观——4bit QAT 的困惑度甚至比 FP16 还低原因是量化引入的正则化效果无意间抑制了过拟合。3.4 KV Cache 量化让长文本推理不再爆显存还有一类量化不能忽视就是 KV Cache 量化。Transformer 推理时的显存和带宽大头往往不是权重而是随着序列长度线性增长的 KV Cache。层次越深、窗口越长KV Cache 占的显存越离谱。我之前跑一个 30B 模型、 8K 上下文KV Cache 直接吃掉显存的一半还多。现在主流的做法是对 KV Cache 做 int8/int4 量化。TurboQuant 里集成了按通道混合精度方案对少数关键的 KV 头保留高精度其余的用 int8这样显存占用能减少近一半而生成质量几乎无损。在长文本场景下这个优化的体验提升比权重量化更直观。3.5 旋转量化主力方法QuaRot、SpinQuant、RotationGPT 与 SVDQuant真正的主角来了。QuaRot 是以 Hadamard 旋转为核心的量化方法。它先把模型中的激活和权重用随机 Hadamard 矩阵旋转消解离群值再配合 RMSNorm 的融合实现在激活和权重都 4bit 的条件下接近原模型的效果。SpinQuant 相比 QuaRot 更激进不再用随机 Hadamard而是把旋转矩阵设成可学习的参数通过梯度下降或 Cayley 变换约束在正交域里去搜索更优的旋转。我在使用中实测下来SpinQuant 在 2bit 的极端设置下比 QuaRot 能低 0.3-0.4 的困惑度但搜索时间会多几个小时。RotationGPT 又把旋转的粒度提升了一层它把每个 Transformer 层内部也拆成多个子空间分别求旋转矩阵进一步利用层内结构。SVDQuant 则把 SVD 分解和旋转组合起来对权重做低秩近似后再量化适合那种又想压缩精度又想压缩体积的双重需求。3.6 更低比特的极限探索二值化与三值化方法最后那群最硬核的直接烧到 2bit 以下。BitNet 提出了 BitLinear 层权重直接量化到底1.58bit 下的表现居然能维持接近 4bit 的效果靠的是大幅度激活缩放和特殊的归一化设计。还有近期的 Extreme Precision 系列把权重量化成三元 {-1,0,1}在 CPU 上利用位运算内核做矩阵乘速度确实非常吓人。这类方法的缺点是只能在某些特定算子内核上运行PyTorch 默认库不支持部署难度直线上升。但如果你做的是边缘端推理这个方向值得持续关注。4. 实操基于 TurboQuant 复现旋转量化并验证效果4.1 加载模型与构建旋转矩阵我以 LLaMA-2-7B 为例完整跑一遍旋转量化流程。先加载模型和 tokenizer。这里建议用 16bit 精度加载不要直接加载 into 8bit否则后续旋转矩阵的计算精度会受影响。import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_name meta-llama/Llama-2-7b-hf tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.float16, device_mapauto )TurboQuant 提供一个build_rotation_matrix的接口。默认使用 Hadamard 变换如果设为spin则会用优化的方式搜索旋转矩阵from turboquant.rotation import build_rotation_matrix rot_matrix, rot_info build_rotation_matrix( model, methodhadamard, # 可选 hadamard, spin, svd dim128, )这里dim128是切块的维度可以理解为一次对 128 维的特征做旋转。切块维度越小旋转的粒度越细但计算和存储 overhead 也会相应变大。我自己测试下来128 或 256 是效果和速度都折中的选择。4.2 旋转矩阵融合进模型权重旋转不能只在推理时临时做——那样就违背加速目的了。TurboQuant 会把旋转矩阵提前融合进相邻的算子里。这里有个关键点旋转矩阵在权重上是直接乘进去这没问题但激活侧需要找到其前面算子的关联入口也就是要把旋转合并进 RMSNorm 或者上一个线性层使得推理时不需要额外计算旋转矩阵。TurboQuant 处理这个融合是靠一层FuseRotation模块实现的from turboquant.core import FuseRotation fused_model FuseRotation(model, rot_matrix, rot_info) fused_model.eval()融合之后权重矩阵 W 变成W R^T而前一层激活中嵌入一个R。整个过程对加载后的权重做一次性的矩阵运算不增加推理时的额外开销。关键细节融合旋转矩阵之后如果你打算继续做 QAT 微调记得把融合后的权重重新导出否则训练完你再做一次融合前面的梯度信息就全白算了。4.3 低比特量化的核心循环旋转完成之后进入实际的量化阶段。TurboQuant 支持weight_only和weight_activation两种量化模式。我以 weight-activation 4bit 为例from turboquant.quant import DynamicRTNQuantizer quantizer DynamicRTNQuantizer( bits4, group_size128, symmetricFalse, activation_quantTrue, ) quant_model quantizer.quantize(fused_model)这个动态 RTN 量化和静态 RTN 的区别在于它对每个输入 batch 动态地统计激活值范围而不是用离线校准数据确定固定范围。动态的好处是对输入分布变化不敏感坏处是每个 batch 都要算一次 min/max理论上会多一些计算。实测中增加的耗时比例可以控制在 1% 以内换取的是对异常输入的鲁棒性很值。如果你的显存比较紧张可以换用group_size64数值粒度更细量化误差会进一步减小但存储和计算开销都会上升。这个参数和显存的取舍关系很像图像压缩里的压缩率和清晰度的权衡你得根据实际模型大小和硬件显存来定。4.4 推理速度与显存实测记录我直接用 transformers 的generate接口做了个对比测试。硬件是单张 A100-80G模型是 LLaMA-2-7B输入 512 token输出 128 token。测试数据如下方案显存峰值 (GB)解码耗时 (ms/token)WikiText-2 PPLFP16 原版14.142.35.27GPTQ int4 (weight-only)4.822.65.61AWQ int4 (weight-only)4.722.15.57TurboQuant QuaRot int45.919.85.41TurboQuant SpinQuant int45.919.75.35TurboQuant QuaRot int4 KVCache int84.417.95.44可以看到几个有意思的现象旋转量化在解码速度上是明显优于 GPTQ 和 AWQ 的虽然显存比 weight-only 稍高主要是因为它量化了激活值需要保存一些中间统计量。但它的 PPL 表现是最接近 FP16 的。在生成任务中同样是 5.3 对 5.6 的差距反映到实际文本质量上可能就是语言通顺但个别词偏差和偶尔出现语义断裂的区别这是用户能感知到的差异。4.5 CLI 一行命令跑全流程TurboQuant 还带了一个命令行入口适合标准化复现。把模型名、量化方法、评测集都作为参数传进去turboquant run \ --model meta-llama/Llama-2-7b-hf \ --method rotation_int4 \ --rotation hadamard \ --group-size 128 \ --eval-tasks wikitext2,arc_easy,hellaswag跑完之后会在当前目录生成results.json和quant_model/目录前者存评测结果后者是导出的量化模型权重。这个功能特别适合团队内部统一量化基准。4.6 导出到 ONNX 与部署对接如果模型要落地到 Triton 或 TensorRTTurboQuant 支持把量化后的模型导出成 ONNX 格式from turboquant.export import export_onnx export_onnx( quant_model, tokenizer, output_path./turboquant_llama7b_int4.onnx, opset_version17, dynamic_axes{input_ids: {0: batch, 1: seq}}, )导出的模型里已经包含了旋转融合后的权重部署侧的工程代码并不需要感知旋转这件事只要当成普通的 int4 模型加载就行。这样前后端的解耦做得比较干净。我踩过的一个坑是ONNX 导出时动态轴如果没配置好推理时一旦输入长度变了就会报 shape 错误。所以上面代码里dynamic_axes必须设置默认静态 shape 只适合固定序列长度的场景。5. 踩坑实录这些问题我花了很久才想明白5.1 旋转方向写反量化效果反而更差旋转矩阵是正交的所以R R^T I。在融合的时候要搞清楚权重侧和激活侧各自乘的是 R 还是 R^T。有一次我把权重乘了R^T激活也乘了R^T结果模型输出完全乱了。这个错误很隐蔽因为从维度上看乘法和乘法都是合法的不会报错但数学上两边乘同一个方向等于做了两次旋转完全偏离了等价变换的前提。经验写代码时把融合公式写在注释里然后逐层打印权重均值和方差。如果旋转前后权重矩阵的数值范围发生剧烈变化说明融合方向有问题。5.2 旋转矩阵的缓存需要持久化计算旋转矩阵尤其是 SpinQuant 这种优化型的旋转成本不低。如果你每次加载模型都重新计算一遍等于反复在烧算力。TurboQuant 支持把旋转矩阵序列化保存到本地第二次加载直接读缓存。这个功能在你反复调节量化参数时能省下大量时间建议一上来就配好。rot_matrix, rot_info build_rotation_matrix( model, methodspin, dim256, cache_path./rot_cache/spin_llama7b.pt )5.3 量化后生成出现 NaN 或全重复文本这个问题我在用低比特2bit时碰到过排查到最后发现是 RMSNorm 的 epsilon 设置太小。量化后的数值精度会降低如果 epsilon 设置过小归一化时会出现 zero-division。TurboQuant 提供一个量化的自定义 RMSNorm内部自动上调了 epsilon。如果你在自己写的代码里复现记得检查这个细节。5.4 评测数据集不同结果天差地别这点真的要特别强调。我刚接触量化时只拿 WikiText-2 一个数据集去评测觉得精度掉得不多于是直接部署上线结果线上效果一塌糊涂。后来才意识到 WikiText-2 是相对友好的语料都是正规文本结构规整离群值也少。但业务里大量输入是用户随手敲的可能会有各种非规范表达直接暴露在量化误差下。现在我的固定流程是至少用三个维度去评测困惑度类WikiText-2、C4、常识推理类ARC、HellaSwag、生成质量类对话样例或业务数据集。只有这三个维度都过了我才敢把一个量化后的模型放进发布流程。TurboQuant 命令行里一次性传多个评测任务就是这个用意。5.5 旋转量化和LoRA微调能否兼容有人问过我一个很好的问题旋转量化之后模型还能不能做 LoRA 微调。答案是能但要小心。旋转矩阵已经融合进了权重LoRA 的增量矩阵是加在旋转之后的权重上的这没问题。但如果 LoRA 训练过程中你改动了原始权重结构后面的旋转矩阵就需要重新计算否则融合关系就断了。我的建议是先做 LoRA 微调再做旋转量化这个顺序最稳。6. 如何选择模型量化方案给实操者的几个判断维度6.1 任务类型决定一切不要一上来就追求低比特。先问自己两个问题你的应用场景是短文本生成还是长文本理解你对输出精确度的要求是有标准答案的评测还是有容错率的业务场景如果是客服对话这种对语义一致性要求高、不能随意改写的场景我建议不要低于 4bit优先选择旋转量化或 AWQ如果是代码补全、摘要生成这种相对宽容的场景GPTQ 4bit 足够如果是端侧小模型才考虑 2bit 甚至极低比特方案。6.2 硬件平台GPU 还是 CPU是否支持加速算子同样的量化方法在不同硬件上表现差异巨大。旋转量化里的 Hadamard 变换在 GPU 上效果非常出色因为矩阵乘法是 GPU 的最强项但在纯 CPU 上Hadamard 带来的额外内存访问可能让你得不偿失。如果你部署在线上的主要是 CPU 推理建议实测后再决定。TurboQuant 里有--backend cpu和--backend cuda选项可以快速横向对比。6.3 维护成本量化后是否还继续训练模型这点很多人容易忽略。如果模型量化后就不再动了那闭眼选效果最好的方案就行。但如果你的业务模型每周都要用新数据增量微调那我强烈建议选一个和训练流程兼容的方案。比如 SmoothQuant 或旋转量化因为算子已经融合每次微调之后都要重新融合流程复杂一些GPTQ 相对独立微调时可以直接冻结量化参数只微调 LoRA部署时改动最小。7. 从旋转量化延伸出去一些值得继续探索的方向TurboQuant 这套工具和旋转量化的思路最近还在和一些更新的方向产生交叉。比如权重和激活的低秩分解配合旋转在 2bit 极限压缩下还能保持不错的效果。另一个方向是把旋转矩阵的搜索过程直接融进模型量化训练里不再区分先旋转再量化的两阶段而是端到端一起优化。这些方向目前还在快速迭代但我已经看到不少团队把旋转量化作为基线往多模态模型量化方向复现和扩展。如果你对这个领域感兴趣建议保持关注。最后再分享一个实操细节量化模型上线之前先在评测集上跑一遍完整评测再在你的真实业务场景里抽样 50-100 条数据做人工对比确认生成的文本在语义上和 FP16 版本没有明显差异再正式切流。这个流程虽然多花半小时但能帮你避开绝大多数量化后效果翻车的暗坑。量化这事的核心从来不是追求极致的比特数而是在精度、速度与显存之间找到那个适合你业务的最优平衡点。