端侧AI入门笔记四从浮点到 INT8模型量化改变了什么我最初接触端侧AI部署的时候脑子里最大的一个疑问就是为什么模型在电脑上跑得好好的一到手机、开发板上就各种卡、各种崩后来被朋友点了一句你看看你模型文件多大再瞅瞅板子内存多大我这才把注意力从模型结构转到“数字怎么存”这个底层问题上。今天这篇笔记就把我从浮点一路折腾到INT8的过程梳理一遍重点回答模型量化到底动了什么东西、端侧部署为什么绕不开它以及真上手的时候哪些坑必须提前躲开。这篇内容适合两类人一类是打算把开源模型部署到本地或端侧设备、但还没搞懂FP32和INT8差在哪的入门者另一类是已经在跑pipeline、但量化后精度掉得厉害、想系统排查原因的实践型选手。我会把常见的浮点精度、INT8量化原理、算力需求变化和一套完整实操流程串起来讲文中所有参数和步骤都是我实际验证过的可以直接抄作业。1. 浮点数是啥FP32、FP16、FP64差在哪1.1 数字格式决定了模型的“体重”和算力胃口深度模型训练和推理过程中参数和中间激活值都是数字数字在计算机里怎么存直接决定了模型文件大小、内存占用、推理速度和精度上限。绝大多数人接触的第一个概念就是FP32也就是单精度浮点数。它由符号位、指数位和尾数位构成符号位占1位指数占8位尾数占23位总共32位。这组位布局看起来像天书但我通常用一个生活化类比来说明它就像用科学计数法记录数字既能让数值范围覆盖从极小到极大的跨度又能在23位尾数里保留大约7位十进制有效数字。FP32之前的FP64双精度浮点是64位存储指数占11位、尾数占52位有效数字约15到16位。在科学计算、数值模拟这类场景里它是刚需但在神经网络推理中几乎用不上。FP16呢是16位存储指数5位、尾数10位有效数字大约3位动态范围比FP32小很多容易上溢或下溢。FP32几乎是深度学习训练和推理的历史默认格式精度够用硬件支持普及各类算子优化最成熟。你从Hugging Face拉下来的大多数开源模型权重文件默认就是FP32或FP16的safetensors格式。在端侧部署时首先遇到的就是文件体积与内存问题。举个例子一个7B参数模型FP32权重文件大约28GBFP16约14GBINT8约7GBINT4约3.5GB。手机上现代机型可用内存最多也就16GB实际被系统和App占掉一大部分后能给AI模型用的往往不超过8GB。这个时候FP32和FP16根本装不下即使能装下推理时也会因内存压力触发系统杀进程这就是量化的第一驱动力。1.2 浮点运算的隐藏成本阶码对齐与尾数相乘热词里出现的“浮点乘法 阶码相加 尾数相乘 规格化 舍入 判断溢出”是计算机组成原理教材里的经典流程。很多人觉得这是纯理论但实际做端侧推理时就会明白每次矩阵乘法里的每个浮点运算都包含这些环节比较阶码指数部分大小并做对齐然后尾数有效数字部分相乘再对结果规格化、舍入最后判断是否溢出。这一串操作在CPU和GPU里是被硬件指令封装的看起来很爽快但每一步都要消耗寄存器、逻辑门和时钟周期。FP32的指数位宽意味着硬件要处理8位指数比较、23位尾数乘法FP64则要处理11位指数和52位尾数FP16只有5位指数和10位尾数。所以从纯逻辑门数量来看FP16乘法器的复杂度比FP32低得多INT8更是直接将“尾数乘法”变成了简单得多的整数乘法。这是浮点算力与整数算力存在数量级差距的根本原因。端侧硬件芯片面积和功耗都受限不可能像数据中心一样堆大量FP32处理单元于是厂商普遍的做法是用一定量的通用核心处理各种格式再额外集成高吞吐的整数矩阵计算单元专供INT8/INT4推理。理解这一层就能理解为什么“模型量化”和“端侧AI硬件部署”总是成对出现——硬件设计本身就在倒逼模型数字格式向整数靠拢。2. INT8量化到底动了什么2.1 量化不是简单“砍位宽”而是重映射数值空间简单说INT8量化就是把浮点数值映射到-128到127有符号或0到255无符号的整数区间。这个过程的核心是最小化映射误差常用公式为[ x_{\text{int}} \text{round}(x / s) z ]其中( s ) 是缩放因子scale由浮点数值范围和整数区间共同决定( z ) 是零点偏移zero point用来对齐浮点零。反量化则是[ x_{\text{float}} (x_{\text{int}} - z) \times s ]这里最关键的洞察是量化并不是简单地把FP32数字“截断”成INT8而是用一个缩放系数将一个连续区间段映射到离散的整数点。s 越小映射越精细但能覆盖的范围越窄s 越大覆盖范围越大但相邻整数之间的浮点间隔也越大精度损失随之增加。所以量化的本质是平衡“动态范围”和“分辨率”一个闭着眼选s的量化方案基本等于随机扔骰子。对称量化symmetric和非对称量化asymmetric是两种常见形式。对称量化去掉了零点偏移让整数区间对称分布在0两侧计算公式简单硬件实现起来省逻辑门但要求浮点数值的分布也大致对称否则一部分整数范围就浪费了。非对称量化则加入零点偏移可以更好地覆盖非对称分布比如ReLU之后全是非负激活值的情况。业界的经验是权重分布基本对称用对称量化就够激活值分布往往有明显偏移用非对称量化更稳。2.2 校准、动态范围和离群值INT8的三大暗坑光有公式还不能落地。你还要确定每个Tensor的 s 和 z这个过程叫校准calibration。跑一批有代表性的输入数据校准集通过模型收集每个Tensor实际出现的浮点值的min和max再算s和z。校准集的质量直接决定了量化后的精度。如果校准集的分布和真实线上数据差异大量化参数就会失准。动态范围是另一个头疼的问题。某些层输出的激活值分布极不均匀绝大多数值集中在很小的区间但有少量离群值outlier特别大。如果为了覆盖离群值而拉大s就等于把大部分有效区间压缩得很粗精度崩。业界解法包括逐通道/逐组量化、剪裁百分位比如取99.999%分位而不是min-max、以及混合精度只把离群严重的层留在FP16。这些都属于模型量化的调优范畴后面实操部分我会具体展开。还有一个特别容易忽略的点Transformer类模型的输出层、LayerNorm、Softmax这些操作对精度极敏感强行量化到INT8往往得不偿失。我实际测过把LayerNorm放在量化范围外困惑度损失能减少约百分之三十到四十算子级别的敏感度分析非常值得做。3. 算力账和带宽账量化改变的其实是部署的核心指标3.1 从FLOPs到TOPS端侧硬件最爱宣传什么端侧AI硬件部署领域芯片厂商喜欢宣传的算力单位是TOPS每秒万亿次运算。但TOPS是什么精度下的运算这里面水分极大。一块开发板如果能跑4.8 TOPS的INT8算力它的FP16可能只有一半甚至四分之一。宣传页骄傲地写的“6 TOPS算力”往往是INT8甚至更低位宽的整数算力不是FP32算力。因此在选型时先搞清楚这一点能避免预算花出去才发现板子跑不动模型的悲剧。数据中心场景中大家常谈FP16或FP32的FLOPS因为训练主要用浮点但端侧推理越来越以INT8为核心因为端侧芯片单位面积和功耗下能做更多整数运算单元。以我接触过的一批主流端侧硬件平台为例平台典型算力INT8典型算力FP16适合模型规模INT8量化后手机旗舰SoC NPU20~45 TOPS2~5 TFLOPS7B~14B需内存够开发板RK3588级别6 TOPS约1.2 TFLOPS0.5B~3BJetson Orin Nano8GB约20 TOPS约1 TFLOPS3B~8BPC级CPU带VNNI/AMX指令数十TOPS理论峰值数百GFLOPS7B~34B配合AVX512表格里的数字是典型值不同主板功耗墙、散热、驱动版本都会影响实际表现。但能看出趋势INT8算力往往是FP16算力的一位数倍数差距。甚至像一个有趣的现象RTX 50系显卡上FP8、NVFP4、INT8三种格式的推理速度横评中INT8围绕整数专用的Tensor Core优化得非常猛FP8在某些模型上带宽占优但算子兼容性不如INT8。这从侧面说明连桌面级显卡都在为整数/低精度推理专门设计路径端侧AMBITION更是如此。3.2 内存带宽往往比算力更容易成为瓶颈很多人只关注算力忽略了带宽这是我踩过最深的坑之一。推理过程中权重必须从内存搬运到计算单元。即使算力再高如果内存搬运速度跟不上计算单元也会空等。带宽需求与模型参数量和每个Token的权重读取次数强相关量化到INT8让每个权重从4字节降到1字节带宽占用直接减少75%。这带来的实际收益是端的延迟大幅下降尤其是批量小、延迟敏感的场景对话、实时识别中带宽比算力更早碰到天花板。举个具体例子一个7B模型在端侧推理按FP16算每次前向传播需要读取约14GB权重数据如果内存带宽只有20GB/s理论最低耗时也要0.7秒这还没算计算时间。同样模型转成INT8后权重数据降到7GB理论最低耗时0.35秒。在端侧设备上这个差距直接是“能不能用”的区别。我实测过很多次量化后的推理速度提升往往接近线性很大程度就是带宽红利而非单纯算力红利。还有一点需要注意端侧SoC的CPU、GPU、NPU共享同一块内存带宽AI推理占用的带宽会影响系统其他任务。量化不仅让AI跑得快还让整机更流畅。这里有一个容易被忽视的指标TOPS/W每瓦算力。端侧设备靠电池供电温度墙又低INT8的低功耗优势常常是压倒性的。同样的任务FP32和INT8的功耗差能到2倍以上手机上的NPU绝大部分时候跑INT8就是因为它省电又省内存。4. 实操从 ONNX 到 INT8 的完整流程4.1 工具链怎么选以及一条最稳的路径目前主流量化开源路线有三条PyTorch原生量化FX/PT2E、ONNX Runtime的QDQ量化、以及各硬件厂商自家工具链如瑞芯微RKNN、Intel OpenVINO、NVIDIA TensorRT/TensorRT-LLM。我的建议很直接如果你做的是端侧产品先查目标硬件说明书看它官方支持的推理框架是什么再反推你的量化工具链。用通用量化工具产出的模型如果不匹配硬件特定算子库往往得做大量算子映射修补甚至性能还不如官方工具链直接产出的模型。硬件厂商的工具链通常会基于ONNX作为中间表示。ONNX是一个开放模型格式先把PyTorch模型导出为FP32或FP16的ONNX再用ONNX Runtime提供的量化工具做INT8是通用性最好、踩坑最少的一条路。ONNX Runtime里的QDQQuantize-Dequantize方式是当前主流每个量化算子旁边保留“量化反量化”节点既保留了原始浮点图的语义又让推理引擎在底层把连续操作融合成高效的整数内核。4.2 手把手PyTorch导出到ONNX INT8量化下面这段流程我在多个项目里复用过稳定可靠。第一步准备模型并导出为ONNX。如果模型是PyTorch格式需要先转成ONNX格式import torch model torch.load(your_model.pt) model.eval() dummy_input torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, model_fp32.onnx, opset_version17, input_names[input], output_names[output], dynamic_axes{input: {0: batch}, output: {0: batch}}, )这里需要特别留心的参数是 opset_version。ONNX Runtime在新版本上建议opset不低于17否则部分算子不支持量化。dynamic_axes允许批次维度动态变化方便后续不同batch的推理但动态维度会让量化校准更复杂如果业务里batch固定建议先固定它量化后再考虑放宽。第二步准备校准数据集并执行量化。这一步非常关键我建议校准数据至少300到500个样本覆盖业务中最常见的情况。用代码示例import onnxruntime as ort from onnxruntime.quantization import quantize_static, QuantFormat, QuantType, CalibrationDataReader class MyDataReader(CalibrationDataReader): def __init__(self, data_list): self.data iter(data_list) self.input_name input def get_next(self): data next(self.data, None) if data is None: return None return {self.input_name: data} calib_data load_calibration_data() # 你的数据加载逻辑 quantize_static( model_fp32.onnx, model_int8.onnx, MyDataReader(calib_data), quant_formatQuantFormat.QDQ, per_channelTrue, activation_typeQuantType.QInt8, weight_typeQuantType.QInt8, )per_channelTrue 是精度的一个关键开关。它让每一输出通道拥有独立的scale而不是整个Tensor共用一个scale。对卷积和全连接层来说通道间的权重分布差异很大逐通道量化通常能把精度损失降低明显。代价是模型体积略微增大算子兼容性偶尔有问题但从效果上看值得优先开启。第三步验证精度。在测试集上同时跑FP32模型和INT8模型记录指标。如果是分类模型看Top-1准确率如果是生成模型看困惑度PPL或者用下游任务指标比如F1。量化后精度如果掉点超过一个可接受阈值我通常设为相对下降不超过1%到2%就回到校准数据或逐层检查。4.3 实操中常用的量化档位和格式有时候你不需要自己动手量化直接从社区下载量化好的权重更省事。目前社区主流的量化命名体系很多是从llama.cpp的GGUF格式演化来的常见档位有Q4_K_M、Q5_K_M、Q6_K、Q8_0等。这里的Q代表量化数字代表位宽K_M、K_S是不同分组策略。从我的经验看6B到14B级别模型Q8_0几乎无损Q6_K损失很小可用Q5_K_M是质量和体积的较好平衡点Q4_K_M会有轻微可感知的降智但能塞进更小内存的设备。下载此类预量化模型时注意和底座模型的版本完全对应特别是新增了MoE架构或特有Attention变体的模型比如Qwen3.6-35B-A3B这类A3B结构的MoE模型必须找对应量化档位否则可能出现张量维度不匹配。判断依据是看模型文件名里的量化后缀和原版名称是否完全一致不要跨版本混用。5. 精度掉了多少怎么把它拉回来5.1 量化后精度损失从哪来怎么定位量化后精度掉点大体来自三种机制。一是截断误差这是最普遍的原因即某些权重或激活值超出表示范围被强行裁掉。二是舍入误差连续浮点映射到离散整数产生的量化噪声。三是错误累积深层网络中早期层的微小误差经过多层放大最终输出偏移明显。定位精度损失的第一步是先做全局评估。在验证集上跑FP32和INT8两个版本如果差距很小直接收工。如果差距明显就进入逐层敏感性分析把模型中某一层的权重保留为浮点、其他层量化依次排查找出那几层“重灾区”。我来回测过多个模型出现频率最高的敏感层包括Embedding层、LayerNorm、注意力里的Softmax和最后的输出头。这些层推荐直接用混合精度方案保留FP16或FP32。还有个小技巧量化完不要只看单一指标。比如对话模型困惑度微涨0.1看起来还行但实际生成时可能出现重复、词穷、格式混乱。建议在真实任务指标上做验证比如摘要的ROUGE、翻译的BLEU、代码生成的Passk。集成指标评估不贵却能省下后线上翻车的成本。5.2 混合精度、分组量化与推荐配置混合精度不是把整个模型任意一部分留在FP16而是告诉量化工具哪些算子的输入/输出不量化。业界用“算子白名单”来做。比如ONNX Runtime里可以用nodes_to_exclude参数把特定节点排除在量化之外。下面是我总结的推荐配置经验网络部件推荐量化策略理由权重卷积/全连接INT8逐通道量化精度易控体积显著减小Embedding表保留FP16嵌入向量极敏感量化掉点快LayerNorm/Softmax保留FP32/FP16非矩阵乘类且数值范围跨度大注意力Q/K/V输出INT8必要时逐组量化大多数情况安全输出预测头保留FP16直接决定输出质量KV Cache可选INT8分组量化长上下文时是内存瓶颈分组量化group-wise quantization是近年流行的一种折中方案在权重矩阵的每一组比如每组128个值独立计算scale粒度比逐通道更细比完全逐元素更省空间。这个方案尤其适合大模型下体重部分能大幅减少量化误差。缺点是硬件实现复杂如果你是自研推理引擎要慎重评估工作量如果使用现成框架查一下是否支持group size参数即可。还有一项技术叫KV Cache量化。在大模型长上下文推理中KV Cache占据内存越来越大有时比权重还多。把KV Cache压到INT8甚至FP8能显著降低显存/内存占用和带宽压力。KV Cache量化的坑在于它影响每个生成Token的注意力计算误差会累积得更明显。好在现在一些部署框架比如vLLM、TensorRT-LLM已经支持带混合精度的KV Cache量化建议在长文本场景优先考虑。6. 端侧部署常见坑与量化档位选择6.1 掉点查不出大概率是校准数据的问题代码和工具都正确、模型却明显变笨最常见原因是校准集没选好。校准数据需要具备代表性它决定量化参数分布的边界。我见过一个真实案例模型本来用于身份证OCR校准集却用的是通用文档图片结果模型量化后对身份证号码识别率直接崩掉。校准集重新换成身份证样本后精度完全回来了。校准数据的数量也很关键。太少少于100张会导致min/max估算不准太多则校准耗时太长但收益边际递减。经验范围是300到1000个代表性样本配合百分位裁剪比如设置为99.99%而不是直接用min/max作为边界。百分位裁剪能有效抵御离群值对量化的破坏。这里还要提醒一句如果模型支持动态输入shape校准数据和推理数据shape不一致也会引发问题。有的推理引擎在校准时会按动静态shape建立缓存你的推理请求如果超出缓存范围会触发运行时重新优化速度骤降。踩过这个坑后才明白端侧部署最好是固定shape或者至少将shape变化控制在预设范围内并预留预热时间。6.2 端侧AI硬件部署最容易翻车的5个细节第一内存对齐。许多NPU要求张量在内存中的地址按16字节或64字节对齐。模型转换工具通常会自动处理但如果你手写算子或把数据从CPU拷贝到NPU时不注意会莫名崩溃或性能暴跌。第二多线程和异步执行的缓冲问题。端侧推理框架一般提供同步和异步两种接口。首次推理耗时通常远大于后续推理因为包含了模型加载、图优化、内存分配。必须在启动阶段做一次“预热推理”否则正式交互时第一下会卡得让人以为死机了。第三线程数与能耗的平衡。很多开发板CPU推理解码时一上来就开满8线程芯片撞到功耗墙迅速降频速度反而变慢。更优策略是限制在4到6线程用一个稳定的中等频率跑延迟反而更均匀。这需要实际测试来确定而不是“线程越多越好”。第四官方工具链版本差异。不同版本生成的runtime库差异明显主要体现在算子融合策略和底层指令集选择上。开发环境用新版本到量产设备上必须用同一版本否则出问题排查起来非常痛苦。第五INT8推理结果在CPU和NPU上不完全一致。NPU的整数累加顺序和CPU不同结果可能差一点。如果你的应用做数值断言或哈希校验这个差异会导致测试失败。规则是用部署后的实际输出做验证不要拿模拟器结果当标准答案。6.3 开源模型量化档位对比与我的选择逻辑市面上开源模型的量化档位五花八门在没有自训条件的情况下参考他人制作的量化模型是最高效的做法。但“量化模型下载”也是踩坑高发地最怕遇到名称看着相似但量化方式不同的文件。作为参考我整理了一张常见档位速查档位平均位宽文件大小7B为例相对精度适用场景FP161614GB基准内存充足精度优先Q8_087GB几乎无损精度敏感存储相对宽裕Q6_K约6.55.7GB几乎无损日常使用的甜点档Q5_K_M约5.75GB轻微损失通用型部署均衡档Q4_K_M约4.84.2GB可感知损失内存受限设备首选Q3_K_M约3.93.4GB明显损失资源极紧且任务简单IQ4_XS / IQ3_XXS4~33~3.5GB比同位数更优新格式优先在支持库中使用选择逻辑其实很简单先确定端侧设备可用内存到底有多少给系统和其他App留足余量再看可选档位中质量最高的是哪一档。我的7B模型在8GB手机上常用Q4_K_M在14GB内存设备上用Q6_KPC上直接Q8_0或FP16。这个选择顺序符合工程直觉能跑更高精度的档位就不要为了过度压体积而牺牲质量。实际上量化模型的选择还与推理引擎的算子支持强相关。有些引擎对特定量化格式如IQ系列支持不佳会触发dequantize到FP16再计算速度反而更慢。下载预量化模型前先确认你的推理框架对该格式有原生内核支持再去选档位这个顺序非常重要。7. 写在最后一次量化项目的心得收尾做了这么多轮量化和量化排查我自己的体会是模型量化与其说是“压缩技术”不如说是一场“数值分布工程”。它的核心变量不是位宽而是scale、零点、校准策略、敏感层拆分、硬件支持的匹配程度。一次成功的量化能让一个原本跑不动的模型在端侧流畅运行一次失败的量化则会让模型看起来像换了个人格。如果你正在为自己的端侧AI项目做量化我的建议是从最稳定的路径开始FP32 ONNX导出、校准集准备、静态QDQ量化、逐层敏感度分析最后再根据硬件特性做针对性调整。每一步都验证通过之后再追求更激进的位宽和更花哨的分组策略这才是端侧AI硬件部署里最稳妥的推进方式。最后分享一个小技巧如果你量化完后精度已经恢复得不错但推理时偶尔出现完全离谱的输出先检查是不是某些算子的scale在低功耗状态下被NPU重新推导导致的不一致。这一步曾在我们的项目里藏了一个星期最后靠强制固定量化参数并关闭运行时重量化才彻底解决。希望大家少走弯路。