2026-08-09 17:23:13 分类：科技
做模型推理那会儿，真是被延迟逼疯。几百兆的模型，跑一次几百毫秒，用户早就划走了。后来搞量化——嚯，发现新大陆！内存直接腰斩，速度快了三倍。但，别高兴太早。坑多得能填海。今天不整虚的，就聊聊这玩意儿到底怎么玩，怎么避开那些阴沟。
这玩意儿到底在干啥？
先拆底层。模型量化，说白了就是把高精度浮点（比如 FP32）映射到低精度整数（比如 INT8），在牺牲一点点精度的前提下，大幅降低计算和存储需求。听着简单，实操起来处处是雷。
核心映射就一条公式：q = round(s * x + z)，其中 x 是原始浮点数，s 是缩放因子，z 是零点。对称量化时 z=0，非对称时 z≠0。这玩意儿像压缩饼干——把一堆空气挤掉，保留关键营养。但挤过头了，精度就碎成渣。
模型量化对称非对称映射示意图
那怎么算 s 和 z？就两招：离线校准和训练时伪量化。前者拿一小撮数据跑一遍，统计每一层的数值范围，算缩放因子；后者在训练时就模拟量化误差，让模型主动适应。说实话，校准时数据的分布要是不对，后面全白搭。
权重和激活都能量化。不过激活的动态范围往往比权重大得多，所以处理激活时更易出问题。尤其是那些极端值——飞出的几个离群点能把整个范围拉偏，导致大部分数值被压缩到零附近，精度暴跌。工程上常用的 trick 是逐通道量化，针对每个通道单独算缩放因子，而不是粗暴地用同一个因子。
速度翻倍？内存砍半？实测数据见真章
别光听我吹。上真实压测数据。拿一个标准 BERT-large 模型，在 CPU 上跑文本分类：
– FP32：推理延迟 24.3ms，吞吐 102 QPS，内存占用 1.35GB。
– INT8（校准后）：推理延迟 7.6ms，吞吐 318 QPS，内存占用 370MB。
延迟砍到三分之一不到！吞吐直接翻三倍。内存更是从 1.35G 掉到 370M，手机上跑完全没压力。不过话说回来，精度掉了多少？Top-1 准确率从 91.2% 降到 90.7%，这种损失在很多场景下完全可接受。
INT8推理延迟对比FP32性能图表
再测一个大模型。ResNet-50 在 GPU 上：
– FP16：延迟 2.1ms，吞吐 6451 images/s。
– INT8：延迟 1.2ms，吞吐 11023 images/s。
吞吐提升近一倍。关键是功耗也降了，边缘设备更友好。
但——注意这里有个骚操作：并非所有层都适合量化。强制给敏感层挂 INT8，精度能掉到你怀疑人生。比如检测模型里的检测头，或者 Transformer 里的 LayerNorm，这些就得留在高精度。混合量化，懂吧？
三个大坑，踩过才懂
坑一：校准数据集随手抓一把训练数据，结果上线精度崩了。
校准数据的分布必须极度贴近生产环境。你拿 ImageNet 校准，结果线上全是室内安防图？完蛋。解决方案：用业务真实数据，最好覆盖长尾场景。数量不用多，几百张代表性样本足矣，但多样性要够。另外，建议做多次校准取平均，减小波动。
坑二：某些层一量化就废，你还找不着原因。
常见如 Softmax、LayerNorm，还有某些奇葩激活函数。根本原因：这些层的数值动态范围极大，INT8 表示能力不够。怎么办？混合精度是银弹。框架上，PyTorch 的 FX 量化或 ONNX Runtime 的混合模式都支持指定哪些层保持 FP16/FP32。记住一条原则：先全部量化，再逐层分析误差，将误差大的层回退精度。这个过程叫精度敏感性分析。
坑三：训练框架和推理框架的量化实现有差异，导致线上结果不一致。
这事儿气得我摔键盘。明明在 PyTorch 里量化后精度 OK，导出 ONNX 再用 TensorRT 一跑，贼烂。为啥？因为伪量化节点融合方式不同，或者校准算法实现不一。解决路子就一条：端到端验证。别相信任何中间格式的精度，必须在目标推理引擎上跑真实数据对比。建议固化一个后端，比如直接用 ONNX Runtime 的 INT8 推理，开发阶段就用它评估，避免来回倒腾。
有了这三个血泪教训，你至少能少走半年弯路。模型量化这东西，性价比高得离谱，但越底层越容易玩脱。工程美学在哪？就在那一组缩放因子里，在混合精度的精细处，在绕过每一个坑的直觉里。
免责声明：市场有风险，选择需谨慎！此文仅供参考，不作买卖依据。如有侵权请联系删除。
文章名称：模型量化：把LLM塞进手机，我踩过的坑和捡到的宝
文章链接：https://m.lfdjt.com/info_23_8070.html
