简介面向需要在资源受限环境部署视觉Transformer的开发者这份资源提供了一套针对ViT、DeiT与SwinT的PTQ量化加速完整方案。包内共15个文件以14个Python脚本和1个Markdown说明为主涵盖模型定义、量化流程、性能评估等核心模块整体压缩包仅41KB便于快速下载与二次开发。内容包含量化后的模型、循序渐进的流程教程及可直接运行的项目源码既解释了PTQ量化原理也展示了如何将浮点模型压缩为低精度整数表示并保持性能。目录结构清晰可帮助开发者快速定位量化层实现、校准数据集与测试脚本降低落地门槛。已有196人学习下载对于想降低Transformer推理延迟、节省计算资源的中高级机器学习开发者是兼具理论讲解与实战参考的优质资源。1. 先别急着量化VisionTransformer的PTQ为什么一上来就会掉点VisionTransformerViT做PTQ量化加速是我调过最玄学的一件事。同样是套用PyTorch的FX量化流程ResNet50量化后top-1只掉0.3%ViT-B/16在ImageNet上却可能从82%掉到76%——这还只是PTQ没碰QAT。很多人拿到“支持ViTDeiTSwinT”的项目源码后第一件事就是打开量化开关然后对着掉点发呆。这个方向真正要解决的其实是两层问题先让PTQ流程在ViT系列上跑通涉及算子支持和导出再让精度保得住涉及校准集、敏感层和混合量化。本文按这个顺序讲新手能跟着复现熟手可以直接看第4章的坑和第6章的精度修复。2. 量化敏感点拆解LayerNorm、GELU、Softmax 谁在拖后腿ViT和CNN在量化这件事上的差距根源不在“模型更大”而在结构。CNN的骨干是卷积BNReLUBN在推理时可以被折叠进卷积ReLU把负半轴全部截断成0激活值天然集中在一个偏正的区间MinMax的量化范围定出来就很稳。而ViT的Transformer块里是三个对数值分布不友好的算子LayerNorm做了逐元素归一化输出范围随输入动态变化GELU不像ReLU那样干脆截断负半轴有一截平滑的非零输出Softmax把注意力矩阵压到0和1之间且极度偏向两端。这三个算子叠加起来激活分布就会呈现明显的长尾和多峰直接套CNN那套per-tensor MinMax校准量化步长很容易被少数离群点拿捏。2.1 结构差异为什么CNN的量化经验搬不过去卷积网络里信息是局部共享的每个通道的输出在空间上比较均匀所以per-channel量化权重复用性很好。而ViT的token把整张图的信息都揉在了一起每个token的激活值都不一样并且embedding层、QKV投影、MLP这些线性层都在同一份数据上反复计算任何一层的轻微偏移都会顺着残差连接往下游放大。另一个差异是残差连接的频率。CNN的残差块通常是两层加一个shortcutTransformer是每一层Attention加一个shortcut、每一层MLP再加一个shortcut。量化误差是逐层累加的FP32下残差把梯度保住了但INT8下残差路径上的量化噪声也被保住了模型层数一深误差就往一个方向叠。这也是为什么同样做PTQViT-L的掉点通常比ViT-B更难看。提示判断一个模型适不适合PTQ最简单的方法是把激活值和权重的分布打出来看。分布越接近正态、越没有长尾量化损失越小分布多峰且跨度几十倍以上的直接掉点很正常。2.2 三大敏感算子从数值分布看掉点的真正原因先说LayerNorm。它内部是x减去均值再除以标准差最后乘gamma加beta。问题是这个“再缩放”后的输出在通道维度上的范围很大比如某些通道的输出稳定在-3到3之间另一些通道在0到0.1之间用一个per-tensor的scale去描述所有通道小数值通道就基本被量化噪声覆盖了。PTQ里一般的做法是让LN在FP32下运行但一旦上了TensorRT或某些推理引擎LN会被强制合并这时就要求你对整个block做量化而不只是逐层看。GELU是第二个坑。它的负半轴在x-2以下基本趋近于0在0附近又有一个平滑过渡带这意味着激活分布会出现一段“拖尾”。CNN的ReLU截断让负区间完全消失量化范围只覆盖正区间GELU的负半轴必须有量化步长去表示不然几个可以忽略的大负值就会把正区间的分辨率全部抢走。用Erf近似实现和用Tanh近似实现的GELU在线性层合并时还会产生额外的数值差这个放到第4章展开。Softmax的敏感更微妙。初始几个block的注意力矩阵接近均匀分布后期逐渐朝one-hot发展。同一个timestep里softmax的输入跨度可能有20以上输出却集中在0和1附近。INT8本来有256个等级可以覆盖0到1区间但在0.9到1.0这一段只能分到几十个等级注意力权重稍微偏移最终预测就变了。常见做法是让注意力矩阵保留FP32或者把QK^T的缩放因子单独设置这在很多推理引擎里叫“attention in FP32”也是第6章混合量化的重点对象。再看QKV投影。Attention中的三个线性层把每个token映射到query、key、value三个空间这三个空间的数值分布形态完全不同query和key的乘积决定注意力权重对数值精度极敏感value本身代表内容信息。per-tensor量化把三者捆绑在一个scale下等于要求一套步长同时满足三个分布。更稳妥的方案是把QKV三个线性层分开量化或者让Q和K的投影保持FP32只量化V和后面的输出投影。很多推理引擎把自注意力当作一个融合算子来处理如果不支持拆分QKV就在PyTorch侧把Q、K、V拆成三个独立Linear再接回原结构这是可以落地的。MLP里的第一个Linear通常把维度从D升到4D第二个Linear再降回D。升维之后激活值的动态范围显著扩大降维层则把高维信息压缩回D后者对量化误差的容忍度更低。所以混合量化的回退顺序有一句口诀先保分类头其次MLP第二个Linear再次QKV投影里的Q和K最后才考虑第一个升维Linear。回退的层越少越好因为每个FP32节点都会让INT8内核的融合度下降加速比就往下掉。2.3 用10行代码把激活分布打出来让问题不再靠猜不要凭感觉判断“敏感”直接把每一层的激活值存下来看。我一般用hook在校准集上跑几十个batch把LayerNorm前的输入和GELU后的输出都收集一遍画max/min/分位数。import torch def hook_fn(name, stats): def hook(module, input, output): x output.detach().float() stats[name][min] min(stats[name][min], x.min().item()) stats[name][max] max(stats[name][max], x.max().item()) stats[name][p99] torch.quantile(x, 0.99).item() return hook stats {fln_{i}: {min: float(inf), max: float(-inf), p99: 0.0} for i in range(12)} for name, module in model.named_modules(): if layernorm in name or gelu in name: module.register_forward_hook(hook_fn(name, stats)) with torch.no_grad(): for images, _ in calib_loader: model(images)这段代码会统计每个LN和GELU层在整个校准集上的最小、最大和99分位值。如果某个层max是200而p99只有3.2说明这个层有一批极端大的离群值量化范围会被这些值撑爆这个层后面必须考虑混合精度。普通的MinMax observer看不到这种“被离群点带偏”的情况先打分布再决定策略比反复试scale要快得多。这里的关键判断标准是p99和max的差距差距在一个数量级以内说明分布收敛超过一个数量级长尾明显该层回退。如果所有层都在一个数量级以内仍然掉点那就去查校准集本身看是不是分布和部署场景不匹配。3. 用PyTorch FX跑通ViT的PTQ量化校准集、QConfig与关键参数很多人拿到项目源码包之后会先翻模型定义其实正确顺序是先跑通FP32基线再做量化。FP32基线告诉你“模型本身最好能到多少”后面量化掉点的容错空间就有了参照。以ViT-B/16在ImageNet-1K上为例FP32 top-1通常在81%左右PTQ能做到80.2%就属于非常理想了。如果是DeiT-SFP32基线79.8%量化到79.0%左右是比较正常的水平——这个前置认知能帮你判断后面是模型问题还是量化流程问题。3.1 拿到模型和校准集后的第一步先打FP32基线常见做法是用timm加载预训练权重熟悉的名字是vit_base_patch16_224、deit_small_patch16_224、swin_tiny_patch4_window7_224。校准集不需要用完整训练集一般从训练集中抽出200到500张覆盖不同类别的图片就够了关键是要覆盖各种亮度、角度和背景。import torch import timm model timm.create_model(vit_base_patch16_224, pretrainedTrue) model.eval() def evaluate(model, loader): model.eval() correct total 0 with torch.no_grad(): for images, labels in loader: out model(images) pred out.argmax(dim-1) correct (pred labels).sum().item() total labels.size(0) return correct / total fp32_acc evaluate(model, val_loader) print(fFP32 baseline: {fp32_acc:.4f})这里评估时用argmax(dim-1)是因为ViT的输出形状是[batch, num_classes]。训练时如果用了混合精度或自定义的forward要先确认eval模式下没有dropout和stochastic depth被关闭否则基线虚高后面量化对比没有意义。校验模型结构时还有一个细节DeiT的forward里有两个分类头cls和distill评估和量化时要确认用的是哪一个输出。如果直接对distill输出做分类精度会和标准结果差很多。timm里通常用model.forward的输出作为主分类结果个别自定义实现需要你在源码里加一行断言确认输出shape。3.2 PTQ核心代码prepare_fx、校准循环、convert_fxPyTorch 2.x对Transformer结构的FX量化支持已经比较成熟但仍然建议固定输入尺寸再trace。下面这段代码是完整的PTQ流程import torch from torch.ao.quantization import QConfig, QConfigMapping, HistogramObserver, PerChannelMinMaxObserver from torch.ao.quantization.quantize_fx import prepare_fx, convert_fx from torch.ao.quantization.backend_config import get_native_backend_config qconfig QConfig( activationHistogramObserver.with_args( dtypetorch.quint8, qschemetorch.per_tensor_affine, bins2048 ), weightPerChannelMinMaxObserver.with_args( dtypetorch.qint8, qschemetorch.per_channel_symmetric ), ) qconfig_mapping QConfigMapping().set_global(qconfig) example_inputs torch.randn(1, 3, 224, 224) model_prepared prepare_fx( model, qconfig_mapping, example_inputs, backend_configget_native_backend_config() ) model_prepared.eval() with torch.no_grad(): for batch_idx, (images, _) in enumerate(calib_loader): model_prepared(images) if batch_idx 31: break model_int8 convert_fx(model_prepared, backend_configget_native_backend_config()) acc_int8 evaluate(model_int8, val_loader) print(fPTQ INT8: {acc_int8:.4f})这里有几个参数需要解释。activation部分用HistogramObserver并设置2048个bin比MinMaxObserver更能捕捉多峰分布默认的MinMax容易被离群点拿捏。weight部分用per_channel_symmetric是每个输出通道一个尺度和卷积的per-channel一致线性层在推理引擎里能直接映射。校准循环跑32个batch也就是256张到512张图如果校准集更大可以相应增加但校准步数过多也会让observer过于拟合校准集一般控制在50个batch以内。对ViT来说bins设2048是因为ViT的激活动态范围比CNN更大bins太少分位数估计会失真太密了校准速度慢且意义不大。embedding层和分类头建议单独用更保守的observer可以用QConfigMapping的set_module_name单独覆盖等第6章混合量化时再展开。注意convert_fx之后得到的是一个带QuantizeLinear/DequantizeLinear节点的模型不要直接把它的输出精度当成最终硬件精度。它只代表“这个量化方案在数值上是否可接受”真实加速要等模型导出到ONNX或TensorRT之后再看。3.3 参数选择observer、qscheme、校准批次设多少才够先回答最常被问的“校准集要多少张”。我的经验是面对类别数1000个的数据集200到500张足够但前提是这些图片要尽量均匀覆盖各个类别和光照条件。只拿前100张训练图连续做校准大概率翻车。可以按类别做分层抽样每个类别抽1到2张确保observer看到的分布是“平均场景”而不是“前几个batch的场景”。再说observer的选择。MinMaxObserver简单快适合分布稳定的CNN对ViT来说HistogramObserver配合percentile比如0.999的截断往往比纯MinMax好。PyTorch里可以这样指定percentilefrom torch.ao.quantization.observer import PercentileObserver qconfig_percentile QConfig( activationPercentileObserver.with_args( dtypetorch.quint8, qschemetorch.per_tensor_affine, percentile0.999 ), weightPerChannelMinMaxObserver.with_args( dtypetorch.qint8, qschemetorch.per_channel_symmetric ), )percentile设为0.999意味着让0.1%的极端值溢出换来剩下99.9%的数值更高的分辨率。这个策略在ViT上比纯MinMax普遍好使原因是ViT确实存在一批离群token它们对结果影响很小但会把scale撑得很大。percentile太小比如0.95会让长尾里的有效信息也一起溢出掉点反而更狠。校准确认之后加一步验证对比FP32和INT8模型在同一个输入上的输出差异。def compare_outputs(model_fp32, model_int8, sample): with torch.no_grad(): out_fp32 model_fp32(sample) out_int8 model_int8(sample) err (out_fp32 - out_int8).abs().max().item() print(fmax abs diff: {err:.4f}) return err这个值如果超过1.0说明量化方案问题很大先看第4章的坑如果在0.01到0.1之间精度大概率能接受。不要拿loss曲线来验证量化直接比logits。4. PTQ必踩的五个坑DeiT与SwinT的算子兼容性和精度陷阱这一章是从实际踩坑里总结出来的现象、原因、解法一条条说清楚。4.1 SwinT的窗口变换让FX量化直接报错现象按第3章的流程跑SwinTprepare_fx阶段正常convert_fx直接报WindowReverse相关的算子不支持或者在推理到某个block时报tensor维度对不上。原因SwinT的window_partition和window_reverse是通过reshape和transpose实现的在FX trace里被展开成一串view/permute节点。老版本PyTorch的native backend config里没有给这些算子配置量化映射系统不知道该给它们插QDQ还是跳过。解决升级到PyTorch 2.1以上并在backend_config里手动补充torch.permute等算子的支持。另一个更省事的做法是让窗口变换留在FP32只量化linear层from torch.ao.quantization import QConfigMapping qconfig_mapping QConfigMapping().set_global(qconfig) qconfig_mapping qconfig_mapping.set_object_type(torch.permute, None)set_object_type(torch.permute, None)意味着permute不量化保持FP32。视觉Transformer的reshape/permute本来就没有计算量把它们留在FP32不影响加速但能解决90%的算子兼容性问题。4.2 DeiT把LayerNorm也量化精度直接掉5个点现象同一个DeiT-S量化全部算子之后top-1从79.8%掉到74.5%把LN改成不回退后精度回到79.1%。原因第2章说过LN的输出动态范围大per-tensor的scale根本描述不了通道间差异。LayerNorm在校准集上的分布是典型的“每分钟变一次”的分布observer统计到的只是它所有形态的均值实际推理时任意一个batch都可能偏离这个均值。解决全局配置里把LayerNorm排除在量化之外。qconfig_mapping qconfig_mapping.set_module_name_regex( .*layernorm.*, None )这个正则匹配了所有名字带layernorm的模块。在ONNX Runtime里LN会作为FP32算子运行速度和精度都说得过去。如果你用的推理引擎强制要求LN量化就需要改成per-channel的activation量化但这个方案在多数CPU后端上得不偿失。4.3 校准集只用一个batchobserver被离群点带偏现象一个同事用验证集第一个batch32张图当校准集量化后精度从80.1%掉到75.2%换成均匀抽样的320张后精度回到79.6%。原因第一个batch恰好有一半是极暗或极亮场景LN输出出现一批极端值MinMax的scale被撑大整个INT8区间的分辨率全被糟蹋了。解决校准集做类别分层抽样至少覆盖所有类别的一半。或者用MovingAverageMinMaxObserver替代MinMaxObserver它会对历史分布做指数滑动平均单批离群点的冲击会被摊薄from torch.ao.quantization.observer import MovingAverageMinMaxObserver qconfig QConfig( activationMovingAverageMinMaxObserver.with_args( dtypetorch.quint8, qschemetorch.per_tensor_affine, averaging_constant0.01 ), weightPerChannelMinMaxObserver.with_args( dtypetorch.qint8, qschemetorch.per_channel_symmetric ), )averaging_constant越小历史分布的影响越大observer越稳定但对分布变化的响应也越慢。训练集与部署场景分布差异偏大的时候这个参数的作用尤其明显。4.4 GELU近似不一致INT8中间层输出对不上现象PyTorch里导出ONNX后再用ONNX Runtime推理中间层输出和PyTorch里的FP32模型对不上但精度降得不算多个别场景下最后分类结果错得离谱。原因训练时用的是GELU的tanh近似而ONNX导出时算子库用的是精确erf实现两边的数值在x0附近有微小差异。这个差异在FP32下无所谓但被INT8量化放大后下游Linear层对噪声敏感结果就会漂。解决在导出ONNX前把模型中的GELU统一替换为精确实现或者在量化时让GELU保持FP32。更彻底的做法是先用torch.onnx.export指定GELU近似形式再重新校准一遍确保observer看到的分布来自部署时真实看到的算子。不要只在PyTorch里验证精度导出后一定要用ONNX Runtime跑一遍同样的评估脚本。4.5 导出ONNX时attention mask被当成常量动态长度推理出错现象ViT在导出ONNX时指定固定尺寸224×224静态batch下一切正常换成动态batch或动态输入尺寸时推理结果错乱或报维度错误。原因FX trace会把attention mask当成常量冻结进图里。如果你在forward里用了mask且mask是None或固定shape导出后它会变成一个固定的张量运行时新输入的序列长度一旦变化mask广播就出问题。解决导出时把mask作为显式的动态输入或者在准备阶段就删除mask分支。视觉Transformer大多不带mask但在做DeiT和部分带mask的ViT变体时会遇到。建议导出前先打印一遍input_names/out_names确认再写个单测用随机shape跑一遍验证。5. 量化不是目的加速才是从INT8模型到ONNX Runtime与TensorRT拿到一个INT8模型文件不代表它在任何设备上都变快加速的前提是运行时的算子实现了INT8的kernel并且数据搬运的开销小于计算节省的开销。这一章说清楚在哪跑、怎么跑、参数怎么调。5.1 加速从哪来先区分计算瓶颈和内存瓶颈ViT这种结构里Linear层是绝对的计算主体一块INT8的矩阵乘和FP32的矩阵乘相比计算量减半、访存量是1/4理论加速上限来自这两个因素。但有两个前提一是模型尺寸足够大kernel启动和调度开销被摊薄二是推理引擎确实把QDQ节点折叠进kernel。在CPU上ONNX Runtime的MLAS后端对INT8 Linear支持得很好典型的ViT-B/16可以做到FP32的1.8到2.8倍。GPU上TensorRT的INT8 kernel对线性层和卷积层加速更明显但注意力算子Softmax、QKV合并在INT8下的kernel覆盖不全很多情况下会被回退到FP16或FP32。所以不要指望一个开关解决所有加速关键看你的算子落在哪个kernel上。5.2 ONNX Runtime部署CPU上的后端选择与参数先导出ONNX再加载。PyTorch导出QDQ模型torch.onnx.export( model_int8, example_inputs, vit_int8.onnx, opset_version17, input_names[images], output_names[output], dynamic_axes{images: {0: batch}, output: {0: batch}}, )这里opset_version选17及以上QDQ的表示更标准dynamic_axes把batch维设为动态图片分辨率保持固定避免SwinT的窗口变换在动态shape下出错。加载和推理import onnxruntime as ort import numpy as np sess_options ort.SessionOptions() sess_options.graph_optimization_level ort.GraphOptimizationLevel.ORT_ENABLE_ALL sess_options.intra_op_num_threads 4 sess ort.InferenceSession( vit_int8.onnx, sess_options, providers[CPUExecutionProvider] ) input_tensor np.random.randn(1, 3, 224, 224).astype(np.float32) outputs sess.run([output], {images: input_tensor})[0]ORT_ENABLE_ALL把可以合并的QDQ节点全部折叠进Linear kernel线程数取决于你的核心数不是越多越好。INT8算子内并行到4到8个线程后内存带宽会变成瓶颈继续加线程收益很小。5.3 上TensorRT时怎么处理FX量化留下的FP32节点TensorRT加载QDQ的ONNX模型时会把QDQ节点解析成INT8卷积或INT8矩阵乘。但LayerNorm和Softmax这些算子TensorRT默认不做INT8它们会被保留为FP32节点。这不是bug而是官方推荐的混合精度策略。如果你想让某一层强制保持FP32可以在导出ONNX之后用onnx_graphsurgeon把该层的QDQ节点删掉再重新推理更简单的做法是在PyTorch侧把该层加入到不量化的名单里上一章说的set_module_name_regex在这里就是同一套逻辑。性能对比用trtexec直接测trtexec --onnxvit_int8.onnx --saveEnginevit_int8.trt --int8 --fp16 --buildOnly trtexec --loadEnginevit_int8.trt --shapesimages:1x3x224x224 --verbose--int8打开INT8精度--fp16允许回退到FP16推理引擎在构建阶段会做层融合。实测中Softmax、LayerNorm、Reshape这几种算子在INT8和FP16之间的选择对端到端延迟的影响经常能到20%以上。后端加速方式线性层LN/Softmax典型加速比ViT-BONNX Runtime CPUMLAS INT8 kernelINT8FP321.82.5xTensorRT GPUINT8 TensorCore 层融合INT8FP16/FP3223.5xPyTorch FX参考模型无真实kernelQDQ仿真QDQ仿真0.81.0x这个表格是给读者做预期管理的第3章里convert_fx得到的参考模型跑起来可能比FP32还慢因为它只是数值仿真。看到慢不要慌导出到真后端再看。6. 精度修复三板斧校准集增强、混合量化与短时QAT回血把掉点从“不可接受”拉回“可接受”我的习惯顺序是这三板斧按性价比从高到低排。6.1 第一斧校准集增强200张图刷出稳定分布校准集不是越大越好而是越接近“部署时真实遇到的分布”越好。我之前一个项目训练集是普通街景部署场景是夜间红外按默认方式抽校准集PTQ之后精度掉4个点。后来把夜间红外图按1:1混进校准集校准集总张数反而少了精度只掉0.8。手段就是每张图抽中心裁剪和随机裁剪两个版本再对亮度抖动做一次归一化。校准集和部署场景分布对齐这个动作在所有调优手段里成本最低收益最直接。6.2 第二斧定位敏感层把它们留在FP32用第2章的hook把每层p99和max打出来凡是max超过p99十倍以上的层先回退。回退的顺序有讲究先回退分类头再回退QKV投影最后回退MLP的第二个Linear。每次只回退一组重新校准、评估直到精度达标。这比一次回退十个层要可解释得多你还能顺带知道到底是谁在拖后腿。分类头对量化误差最敏感因为它的输入是CLS token经过整个网络后的特征动态范围在整个网络里常常最大回退它往往能拿回一半掉点。6.3 第三斧1个epoch的QAT微调把精度拉回0.5个点以内当混合量化已经把敏感层全部留在FP32精度还差1个点左右时强烈建议先做短时QAT而不是换更大的模型。做法很粗把convert_fx得到的模型转成QAT可训练版本用1/100的学习率微调1个epoch。这一招能把多数模型的精度差压缩到0.3到0.5个点。注意训练时要把dropout重新打开不然微调会过拟合在训练集上。我现在的习惯是每次拿到一个Transformer模型第一个动作永远是打分布、建基线、固定校准集然后才谈量化。这个顺序帮我省掉了至少十次“量化后翻车然后找不到原因”的排查。量化加速这个方向对VisionTransformer来说已经是工程落地必选项但前提是流程本身要走稳。希望帮到你。本文还有配套的精品资源点击获取 ViT模型PTQ量化实战：解析掉点原因与精度修复策略
简介面向需要在资源受限环境部署视觉Transformer的开发者这份资源提供了一套针对ViT、DeiT与SwinT的PTQ量化加速完整方案。包内共15个文件以14个Python脚本和1个Markdown说明为主涵盖模型定义、量化流程、性能评估等核心模块整体压缩包仅41KB便于快速下载与二次开发。内容包含量化后的模型、循序渐进的流程教程及可直接运行的项目源码既解释了PTQ量化原理也展示了如何将浮点模型压缩为低精度整数表示并保持性能。目录结构清晰可帮助开发者快速定位量化层实现、校准数据集与测试脚本降低落地门槛。已有196人学习下载对于想降低Transformer推理延迟、节省计算资源的中高级机器学习开发者是兼具理论讲解与实战参考的优质资源。1. 先别急着量化VisionTransformer的PTQ为什么一上来就会掉点VisionTransformerViT做PTQ量化加速是我调过最玄学的一件事。同样是套用PyTorch的FX量化流程ResNet50量化后top-1只掉0.3%ViT-B/16在ImageNet上却可能从82%掉到76%——这还只是PTQ没碰QAT。很多人拿到“支持ViTDeiTSwinT”的项目源码后第一件事就是打开量化开关然后对着掉点发呆。这个方向真正要解决的其实是两层问题先让PTQ流程在ViT系列上跑通涉及算子支持和导出再让精度保得住涉及校准集、敏感层和混合量化。本文按这个顺序讲新手能跟着复现熟手可以直接看第4章的坑和第6章的精度修复。2. 量化敏感点拆解LayerNorm、GELU、Softmax 谁在拖后腿ViT和CNN在量化这件事上的差距根源不在“模型更大”而在结构。CNN的骨干是卷积BNReLUBN在推理时可以被折叠进卷积ReLU把负半轴全部截断成0激活值天然集中在一个偏正的区间MinMax的量化范围定出来就很稳。而ViT的Transformer块里是三个对数值分布不友好的算子LayerNorm做了逐元素归一化输出范围随输入动态变化GELU不像ReLU那样干脆截断负半轴有一截平滑的非零输出Softmax把注意力矩阵压到0和1之间且极度偏向两端。这三个算子叠加起来激活分布就会呈现明显的长尾和多峰直接套CNN那套per-tensor MinMax校准量化步长很容易被少数离群点拿捏。2.1 结构差异为什么CNN的量化经验搬不过去卷积网络里信息是局部共享的每个通道的输出在空间上比较均匀所以per-channel量化权重复用性很好。而ViT的token把整张图的信息都揉在了一起每个token的激活值都不一样并且embedding层、QKV投影、MLP这些线性层都在同一份数据上反复计算任何一层的轻微偏移都会顺着残差连接往下游放大。另一个差异是残差连接的频率。CNN的残差块通常是两层加一个shortcutTransformer是每一层Attention加一个shortcut、每一层MLP再加一个shortcut。量化误差是逐层累加的FP32下残差把梯度保住了但INT8下残差路径上的量化噪声也被保住了模型层数一深误差就往一个方向叠。这也是为什么同样做PTQViT-L的掉点通常比ViT-B更难看。提示判断一个模型适不适合PTQ最简单的方法是把激活值和权重的分布打出来看。分布越接近正态、越没有长尾量化损失越小分布多峰且跨度几十倍以上的直接掉点很正常。2.2 三大敏感算子从数值分布看掉点的真正原因先说LayerNorm。它内部是x减去均值再除以标准差最后乘gamma加beta。问题是这个“再缩放”后的输出在通道维度上的范围很大比如某些通道的输出稳定在-3到3之间另一些通道在0到0.1之间用一个per-tensor的scale去描述所有通道小数值通道就基本被量化噪声覆盖了。PTQ里一般的做法是让LN在FP32下运行但一旦上了TensorRT或某些推理引擎LN会被强制合并这时就要求你对整个block做量化而不只是逐层看。GELU是第二个坑。它的负半轴在x-2以下基本趋近于0在0附近又有一个平滑过渡带这意味着激活分布会出现一段“拖尾”。CNN的ReLU截断让负区间完全消失量化范围只覆盖正区间GELU的负半轴必须有量化步长去表示不然几个可以忽略的大负值就会把正区间的分辨率全部抢走。用Erf近似实现和用Tanh近似实现的GELU在线性层合并时还会产生额外的数值差这个放到第4章展开。Softmax的敏感更微妙。初始几个block的注意力矩阵接近均匀分布后期逐渐朝one-hot发展。同一个timestep里softmax的输入跨度可能有20以上输出却集中在0和1附近。INT8本来有256个等级可以覆盖0到1区间但在0.9到1.0这一段只能分到几十个等级注意力权重稍微偏移最终预测就变了。常见做法是让注意力矩阵保留FP32或者把QK^T的缩放因子单独设置这在很多推理引擎里叫“attention in FP32”也是第6章混合量化的重点对象。再看QKV投影。Attention中的三个线性层把每个token映射到query、key、value三个空间这三个空间的数值分布形态完全不同query和key的乘积决定注意力权重对数值精度极敏感value本身代表内容信息。per-tensor量化把三者捆绑在一个scale下等于要求一套步长同时满足三个分布。更稳妥的方案是把QKV三个线性层分开量化或者让Q和K的投影保持FP32只量化V和后面的输出投影。很多推理引擎把自注意力当作一个融合算子来处理如果不支持拆分QKV就在PyTorch侧把Q、K、V拆成三个独立Linear再接回原结构这是可以落地的。MLP里的第一个Linear通常把维度从D升到4D第二个Linear再降回D。升维之后激活值的动态范围显著扩大降维层则把高维信息压缩回D后者对量化误差的容忍度更低。所以混合量化的回退顺序有一句口诀先保分类头其次MLP第二个Linear再次QKV投影里的Q和K最后才考虑第一个升维Linear。回退的层越少越好因为每个FP32节点都会让INT8内核的融合度下降加速比就往下掉。2.3 用10行代码把激活分布打出来让问题不再靠猜不要凭感觉判断“敏感”直接把每一层的激活值存下来看。我一般用hook在校准集上跑几十个batch把LayerNorm前的输入和GELU后的输出都收集一遍画max/min/分位数。import torch def hook_fn(name, stats): def hook(module, input, output): x output.detach().float() stats[name][min] min(stats[name][min], x.min().item()) stats[name][max] max(stats[name][max], x.max().item()) stats[name][p99] torch.quantile(x, 0.99).item() return hook stats {fln_{i}: {min: float(inf), max: float(-inf), p99: 0.0} for i in range(12)} for name, module in model.named_modules(): if layernorm in name or gelu in name: module.register_forward_hook(hook_fn(name, stats)) with torch.no_grad(): for images, _ in calib_loader: model(images)这段代码会统计每个LN和GELU层在整个校准集上的最小、最大和99分位值。如果某个层max是200而p99只有3.2说明这个层有一批极端大的离群值量化范围会被这些值撑爆这个层后面必须考虑混合精度。普通的MinMax observer看不到这种“被离群点带偏”的情况先打分布再决定策略比反复试scale要快得多。这里的关键判断标准是p99和max的差距差距在一个数量级以内说明分布收敛超过一个数量级长尾明显该层回退。如果所有层都在一个数量级以内仍然掉点那就去查校准集本身看是不是分布和部署场景不匹配。3. 用PyTorch FX跑通ViT的PTQ量化校准集、QConfig与关键参数很多人拿到项目源码包之后会先翻模型定义其实正确顺序是先跑通FP32基线再做量化。FP32基线告诉你“模型本身最好能到多少”后面量化掉点的容错空间就有了参照。以ViT-B/16在ImageNet-1K上为例FP32 top-1通常在81%左右PTQ能做到80.2%就属于非常理想了。如果是DeiT-SFP32基线79.8%量化到79.0%左右是比较正常的水平——这个前置认知能帮你判断后面是模型问题还是量化流程问题。3.1 拿到模型和校准集后的第一步先打FP32基线常见做法是用timm加载预训练权重熟悉的名字是vit_base_patch16_224、deit_small_patch16_224、swin_tiny_patch4_window7_224。校准集不需要用完整训练集一般从训练集中抽出200到500张覆盖不同类别的图片就够了关键是要覆盖各种亮度、角度和背景。import torch import timm model timm.create_model(vit_base_patch16_224, pretrainedTrue) model.eval() def evaluate(model, loader): model.eval() correct total 0 with torch.no_grad(): for images, labels in loader: out model(images) pred out.argmax(dim-1) correct (pred labels).sum().item() total labels.size(0) return correct / total fp32_acc evaluate(model, val_loader) print(fFP32 baseline: {fp32_acc:.4f})这里评估时用argmax(dim-1)是因为ViT的输出形状是[batch, num_classes]。训练时如果用了混合精度或自定义的forward要先确认eval模式下没有dropout和stochastic depth被关闭否则基线虚高后面量化对比没有意义。校验模型结构时还有一个细节DeiT的forward里有两个分类头cls和distill评估和量化时要确认用的是哪一个输出。如果直接对distill输出做分类精度会和标准结果差很多。timm里通常用model.forward的输出作为主分类结果个别自定义实现需要你在源码里加一行断言确认输出shape。3.2 PTQ核心代码prepare_fx、校准循环、convert_fxPyTorch 2.x对Transformer结构的FX量化支持已经比较成熟但仍然建议固定输入尺寸再trace。下面这段代码是完整的PTQ流程import torch from torch.ao.quantization import QConfig, QConfigMapping, HistogramObserver, PerChannelMinMaxObserver from torch.ao.quantization.quantize_fx import prepare_fx, convert_fx from torch.ao.quantization.backend_config import get_native_backend_config qconfig QConfig( activationHistogramObserver.with_args( dtypetorch.quint8, qschemetorch.per_tensor_affine, bins2048 ), weightPerChannelMinMaxObserver.with_args( dtypetorch.qint8, qschemetorch.per_channel_symmetric ), ) qconfig_mapping QConfigMapping().set_global(qconfig) example_inputs torch.randn(1, 3, 224, 224) model_prepared prepare_fx( model, qconfig_mapping, example_inputs, backend_configget_native_backend_config() ) model_prepared.eval() with torch.no_grad(): for batch_idx, (images, _) in enumerate(calib_loader): model_prepared(images) if batch_idx 31: break model_int8 convert_fx(model_prepared, backend_configget_native_backend_config()) acc_int8 evaluate(model_int8, val_loader) print(fPTQ INT8: {acc_int8:.4f})这里有几个参数需要解释。activation部分用HistogramObserver并设置2048个bin比MinMaxObserver更能捕捉多峰分布默认的MinMax容易被离群点拿捏。weight部分用per_channel_symmetric是每个输出通道一个尺度和卷积的per-channel一致线性层在推理引擎里能直接映射。校准循环跑32个batch也就是256张到512张图如果校准集更大可以相应增加但校准步数过多也会让observer过于拟合校准集一般控制在50个batch以内。对ViT来说bins设2048是因为ViT的激活动态范围比CNN更大bins太少分位数估计会失真太密了校准速度慢且意义不大。embedding层和分类头建议单独用更保守的observer可以用QConfigMapping的set_module_name单独覆盖等第6章混合量化时再展开。注意convert_fx之后得到的是一个带QuantizeLinear/DequantizeLinear节点的模型不要直接把它的输出精度当成最终硬件精度。它只代表“这个量化方案在数值上是否可接受”真实加速要等模型导出到ONNX或TensorRT之后再看。3.3 参数选择observer、qscheme、校准批次设多少才够先回答最常被问的“校准集要多少张”。我的经验是面对类别数1000个的数据集200到500张足够但前提是这些图片要尽量均匀覆盖各个类别和光照条件。只拿前100张训练图连续做校准大概率翻车。可以按类别做分层抽样每个类别抽1到2张确保observer看到的分布是“平均场景”而不是“前几个batch的场景”。再说observer的选择。MinMaxObserver简单快适合分布稳定的CNN对ViT来说HistogramObserver配合percentile比如0.999的截断往往比纯MinMax好。PyTorch里可以这样指定percentilefrom torch.ao.quantization.observer import PercentileObserver qconfig_percentile QConfig( activationPercentileObserver.with_args( dtypetorch.quint8, qschemetorch.per_tensor_affine, percentile0.999 ), weightPerChannelMinMaxObserver.with_args( dtypetorch.qint8, qschemetorch.per_channel_symmetric ), )percentile设为0.999意味着让0.1%的极端值溢出换来剩下99.9%的数值更高的分辨率。这个策略在ViT上比纯MinMax普遍好使原因是ViT确实存在一批离群token它们对结果影响很小但会把scale撑得很大。percentile太小比如0.95会让长尾里的有效信息也一起溢出掉点反而更狠。校准确认之后加一步验证对比FP32和INT8模型在同一个输入上的输出差异。def compare_outputs(model_fp32, model_int8, sample): with torch.no_grad(): out_fp32 model_fp32(sample) out_int8 model_int8(sample) err (out_fp32 - out_int8).abs().max().item() print(fmax abs diff: {err:.4f}) return err这个值如果超过1.0说明量化方案问题很大先看第4章的坑如果在0.01到0.1之间精度大概率能接受。不要拿loss曲线来验证量化直接比logits。4. PTQ必踩的五个坑DeiT与SwinT的算子兼容性和精度陷阱这一章是从实际踩坑里总结出来的现象、原因、解法一条条说清楚。4.1 SwinT的窗口变换让FX量化直接报错现象按第3章的流程跑SwinTprepare_fx阶段正常convert_fx直接报WindowReverse相关的算子不支持或者在推理到某个block时报tensor维度对不上。原因SwinT的window_partition和window_reverse是通过reshape和transpose实现的在FX trace里被展开成一串view/permute节点。老版本PyTorch的native backend config里没有给这些算子配置量化映射系统不知道该给它们插QDQ还是跳过。解决升级到PyTorch 2.1以上并在backend_config里手动补充torch.permute等算子的支持。另一个更省事的做法是让窗口变换留在FP32只量化linear层from torch.ao.quantization import QConfigMapping qconfig_mapping QConfigMapping().set_global(qconfig) qconfig_mapping qconfig_mapping.set_object_type(torch.permute, None)set_object_type(torch.permute, None)意味着permute不量化保持FP32。视觉Transformer的reshape/permute本来就没有计算量把它们留在FP32不影响加速但能解决90%的算子兼容性问题。4.2 DeiT把LayerNorm也量化精度直接掉5个点现象同一个DeiT-S量化全部算子之后top-1从79.8%掉到74.5%把LN改成不回退后精度回到79.1%。原因第2章说过LN的输出动态范围大per-tensor的scale根本描述不了通道间差异。LayerNorm在校准集上的分布是典型的“每分钟变一次”的分布observer统计到的只是它所有形态的均值实际推理时任意一个batch都可能偏离这个均值。解决全局配置里把LayerNorm排除在量化之外。qconfig_mapping qconfig_mapping.set_module_name_regex( .*layernorm.*, None )这个正则匹配了所有名字带layernorm的模块。在ONNX Runtime里LN会作为FP32算子运行速度和精度都说得过去。如果你用的推理引擎强制要求LN量化就需要改成per-channel的activation量化但这个方案在多数CPU后端上得不偿失。4.3 校准集只用一个batchobserver被离群点带偏现象一个同事用验证集第一个batch32张图当校准集量化后精度从80.1%掉到75.2%换成均匀抽样的320张后精度回到79.6%。原因第一个batch恰好有一半是极暗或极亮场景LN输出出现一批极端值MinMax的scale被撑大整个INT8区间的分辨率全被糟蹋了。解决校准集做类别分层抽样至少覆盖所有类别的一半。或者用MovingAverageMinMaxObserver替代MinMaxObserver它会对历史分布做指数滑动平均单批离群点的冲击会被摊薄from torch.ao.quantization.observer import MovingAverageMinMaxObserver qconfig QConfig( activationMovingAverageMinMaxObserver.with_args( dtypetorch.quint8, qschemetorch.per_tensor_affine, averaging_constant0.01 ), weightPerChannelMinMaxObserver.with_args( dtypetorch.qint8, qschemetorch.per_channel_symmetric ), )averaging_constant越小历史分布的影响越大observer越稳定但对分布变化的响应也越慢。训练集与部署场景分布差异偏大的时候这个参数的作用尤其明显。4.4 GELU近似不一致INT8中间层输出对不上现象PyTorch里导出ONNX后再用ONNX Runtime推理中间层输出和PyTorch里的FP32模型对不上但精度降得不算多个别场景下最后分类结果错得离谱。原因训练时用的是GELU的tanh近似而ONNX导出时算子库用的是精确erf实现两边的数值在x0附近有微小差异。这个差异在FP32下无所谓但被INT8量化放大后下游Linear层对噪声敏感结果就会漂。解决在导出ONNX前把模型中的GELU统一替换为精确实现或者在量化时让GELU保持FP32。更彻底的做法是先用torch.onnx.export指定GELU近似形式再重新校准一遍确保observer看到的分布来自部署时真实看到的算子。不要只在PyTorch里验证精度导出后一定要用ONNX Runtime跑一遍同样的评估脚本。4.5 导出ONNX时attention mask被当成常量动态长度推理出错现象ViT在导出ONNX时指定固定尺寸224×224静态batch下一切正常换成动态batch或动态输入尺寸时推理结果错乱或报维度错误。原因FX trace会把attention mask当成常量冻结进图里。如果你在forward里用了mask且mask是None或固定shape导出后它会变成一个固定的张量运行时新输入的序列长度一旦变化mask广播就出问题。解决导出时把mask作为显式的动态输入或者在准备阶段就删除mask分支。视觉Transformer大多不带mask但在做DeiT和部分带mask的ViT变体时会遇到。建议导出前先打印一遍input_names/out_names确认再写个单测用随机shape跑一遍验证。5. 量化不是目的加速才是从INT8模型到ONNX Runtime与TensorRT拿到一个INT8模型文件不代表它在任何设备上都变快加速的前提是运行时的算子实现了INT8的kernel并且数据搬运的开销小于计算节省的开销。这一章说清楚在哪跑、怎么跑、参数怎么调。5.1 加速从哪来先区分计算瓶颈和内存瓶颈ViT这种结构里Linear层是绝对的计算主体一块INT8的矩阵乘和FP32的矩阵乘相比计算量减半、访存量是1/4理论加速上限来自这两个因素。但有两个前提一是模型尺寸足够大kernel启动和调度开销被摊薄二是推理引擎确实把QDQ节点折叠进kernel。在CPU上ONNX Runtime的MLAS后端对INT8 Linear支持得很好典型的ViT-B/16可以做到FP32的1.8到2.8倍。GPU上TensorRT的INT8 kernel对线性层和卷积层加速更明显但注意力算子Softmax、QKV合并在INT8下的kernel覆盖不全很多情况下会被回退到FP16或FP32。所以不要指望一个开关解决所有加速关键看你的算子落在哪个kernel上。5.2 ONNX Runtime部署CPU上的后端选择与参数先导出ONNX再加载。PyTorch导出QDQ模型torch.onnx.export( model_int8, example_inputs, vit_int8.onnx, opset_version17, input_names[images], output_names[output], dynamic_axes{images: {0: batch}, output: {0: batch}}, )这里opset_version选17及以上QDQ的表示更标准dynamic_axes把batch维设为动态图片分辨率保持固定避免SwinT的窗口变换在动态shape下出错。加载和推理import onnxruntime as ort import numpy as np sess_options ort.SessionOptions() sess_options.graph_optimization_level ort.GraphOptimizationLevel.ORT_ENABLE_ALL sess_options.intra_op_num_threads 4 sess ort.InferenceSession( vit_int8.onnx, sess_options, providers[CPUExecutionProvider] ) input_tensor np.random.randn(1, 3, 224, 224).astype(np.float32) outputs sess.run([output], {images: input_tensor})[0]ORT_ENABLE_ALL把可以合并的QDQ节点全部折叠进Linear kernel线程数取决于你的核心数不是越多越好。INT8算子内并行到4到8个线程后内存带宽会变成瓶颈继续加线程收益很小。5.3 上TensorRT时怎么处理FX量化留下的FP32节点TensorRT加载QDQ的ONNX模型时会把QDQ节点解析成INT8卷积或INT8矩阵乘。但LayerNorm和Softmax这些算子TensorRT默认不做INT8它们会被保留为FP32节点。这不是bug而是官方推荐的混合精度策略。如果你想让某一层强制保持FP32可以在导出ONNX之后用onnx_graphsurgeon把该层的QDQ节点删掉再重新推理更简单的做法是在PyTorch侧把该层加入到不量化的名单里上一章说的set_module_name_regex在这里就是同一套逻辑。性能对比用trtexec直接测trtexec --onnxvit_int8.onnx --saveEnginevit_int8.trt --int8 --fp16 --buildOnly trtexec --loadEnginevit_int8.trt --shapesimages:1x3x224x224 --verbose--int8打开INT8精度--fp16允许回退到FP16推理引擎在构建阶段会做层融合。实测中Softmax、LayerNorm、Reshape这几种算子在INT8和FP16之间的选择对端到端延迟的影响经常能到20%以上。后端加速方式线性层LN/Softmax典型加速比ViT-BONNX Runtime CPUMLAS INT8 kernelINT8FP321.82.5xTensorRT GPUINT8 TensorCore 层融合INT8FP16/FP3223.5xPyTorch FX参考模型无真实kernelQDQ仿真QDQ仿真0.81.0x这个表格是给读者做预期管理的第3章里convert_fx得到的参考模型跑起来可能比FP32还慢因为它只是数值仿真。看到慢不要慌导出到真后端再看。6. 精度修复三板斧校准集增强、混合量化与短时QAT回血把掉点从“不可接受”拉回“可接受”我的习惯顺序是这三板斧按性价比从高到低排。6.1 第一斧校准集增强200张图刷出稳定分布校准集不是越大越好而是越接近“部署时真实遇到的分布”越好。我之前一个项目训练集是普通街景部署场景是夜间红外按默认方式抽校准集PTQ之后精度掉4个点。后来把夜间红外图按1:1混进校准集校准集总张数反而少了精度只掉0.8。手段就是每张图抽中心裁剪和随机裁剪两个版本再对亮度抖动做一次归一化。校准集和部署场景分布对齐这个动作在所有调优手段里成本最低收益最直接。6.2 第二斧定位敏感层把它们留在FP32用第2章的hook把每层p99和max打出来凡是max超过p99十倍以上的层先回退。回退的顺序有讲究先回退分类头再回退QKV投影最后回退MLP的第二个Linear。每次只回退一组重新校准、评估直到精度达标。这比一次回退十个层要可解释得多你还能顺带知道到底是谁在拖后腿。分类头对量化误差最敏感因为它的输入是CLS token经过整个网络后的特征动态范围在整个网络里常常最大回退它往往能拿回一半掉点。6.3 第三斧1个epoch的QAT微调把精度拉回0.5个点以内当混合量化已经把敏感层全部留在FP32精度还差1个点左右时强烈建议先做短时QAT而不是换更大的模型。做法很粗把convert_fx得到的模型转成QAT可训练版本用1/100的学习率微调1个epoch。这一招能把多数模型的精度差压缩到0.3到0.5个点。注意训练时要把dropout重新打开不然微调会过拟合在训练集上。我现在的习惯是每次拿到一个Transformer模型第一个动作永远是打分布、建基线、固定校准集然后才谈量化。这个顺序帮我省掉了至少十次“量化后翻车然后找不到原因”的排查。量化加速这个方向对VisionTransformer来说已经是工程落地必选项但前提是流程本身要走稳。希望帮到你。本文还有配套的精品资源点击获取