模型量化实战指南：PTQ与QAT选型、误差控制与硬件适配

1. 项目概述：为什么模型越“轻”，越要懂量化这门手艺？

在工业界部署一个视觉检测模型时，我遇到过最扎心的场景不是精度掉点，而是——模型在边缘设备上根本跑不动。客户拿的是某款国产低功耗SoC，内存带宽只有2.4GB/s，而我们交付的FP32 ResNet-50推理一次要耗时860ms，功耗直接飙到3.2W，散热片烫得能煎蛋。最后不是靠调参，而是靠把模型从FP32压成INT8，推理时间砍到112ms，功耗降到0.7W，才让整套产线质检系统真正落地。这件事让我彻底明白：量化不是学术圈的玩具，是模型从实验室走向产线的必经闸口。它解决的从来不是“能不能算”，而是“能不能实时、稳定、低功耗地算”。你不需要是算法研究员，但只要参与过模型部署、端侧优化或嵌入式AI开发，就一定会和Post Training Quantization（PTQ）、Quantization Error（量化误差）、Quantization Aware Training（QAT）这三个词反复打交道。它们不是并列的三种技术，而是一条渐进式的技术路径：PTQ是“零代码改造”的急救包，适合快速验证；QAT是“提前打补丁”的手术刀，为精度兜底；而量化误差，则是贯穿全程的隐形裁判——它不声不响，却决定着你的模型到底是“轻装上阵”还是“带病上岗”。这篇内容专为一线工程师、部署工程师和想搞懂模型压缩底层逻辑的算法同学准备，不讲抽象公式推导，只拆解真实项目里怎么选、怎么调、怎么避坑。接下来我会用实测数据告诉你：为什么同一个PTQ方案，在ResNet和ViT上误差能差出3倍；为什么QAT训练时加个fake quant op，反而让收敛更稳；以及最关键的——如何一眼识别出你的模型到底该走PTQ还是QAT这条道。

2. 核心技术路径拆解：PTQ、QAT与误差的本质关系

2.1 PTQ：不碰训练代码的“外科手术”，但有严格适应症

Post Training Quantization（PTQ）的核心逻辑非常朴素：模型已经训好了，权重和激活值都是FP32，我直接按规则把它“翻译”成INT8，不重新训练，不改结构，不碰loss函数。听起来像魔法？其实它依赖三个关键假设：第一，权重分布接近高斯或均匀分布；第二，激活值动态范围相对稳定；第三，模型对数值扰动有一定鲁棒性。一旦这三个条件崩一个，PTQ就会翻车。比如我去年优化一个语音唤醒模型，用TensorRT的默认PTQ策略，准确率从98.2%暴跌到89.7%。查下来发现，它的最后一层全连接层权重标准差只有0.012，而常规ResNet是0.15左右——太“瘦”的分布导致INT8量化后大量权重被挤到0或±1，信息直接丢失。后来换用Adaptive Rounding（AdaRound），它把量化过程建模成一个可学习的舍入问题，用少量校准数据微调舍入方式，准确率立刻回到97.5%。这说明PTQ不是“一键量化”，而是“带约束的参数映射”。它的价值在于快：从拿到模型到生成INT8引擎，最快20分钟内完成。但代价是不确定性——你永远不知道下一个模型会不会突然“水土不服”。

2.2 QAT：把量化“种进”训练过程的主动防御

Quantization Aware Training（QAT）的思路截然不同：既然量化会引入误差，那干脆在训练时就模拟这个误差，让模型边学边适应。具体怎么做？在前向传播时，QAT会在权重和激活后插入fake quantization操作（比如PyTorch里的torch.quantization.FakeQuantize），它不真把数值转成INT8，而是用FP32模拟INT8的舍入和截断效果；反向传播时，梯度照常流过，但数值更新是在模拟后的“伪量化域”里发生的。这就相当于给模型开了个“量化特训班”：它看到的永远是带噪声的数据，学到的特征天然抗扰动。我做过一组对比实验：同一个MobileNetV3-small，在ImageNet上，纯PTQ掉点1.8%，而QAT只掉0.3%。更关键的是稳定性——QAT训练完的模型，换到不同硬件平台（NPU、DSP、GPU）上，精度波动小于0.1%，而PTQ方案在不同后端可能差出0.7%。这是因为QAT让模型学到了“量化不变性”，而PTQ只是做了静态适配。但QAT的硬伤也很明显：训练周期拉长30%-50%，需要额外准备校准数据集（通常500-1000张图），且对训练框架支持要求高。TensorFlow Lite的QAT流程要手动插fake quant节点，而PyTorch 1.13+的FX Graph Mode QAT已经能自动追踪，但对自定义OP支持仍弱。所以QAT不是万能药，它是为精度敏感型任务（如医疗影像分割、自动驾驶BEV感知）准备的“高定西装”，而PTQ是给通用CV任务穿的“快干T恤”。

2.3 量化误差：不是bug，是模型与硬件的“语言翻译损耗”

很多人把量化误差当成要消灭的敌人，这是根本性误解。量化误差的本质，是浮点数到整数的“语义失真”。举个生活化例子：FP32像一本百万字的百科全书，INT8像一张A4纸的摘要。摘要不可能包含所有细节，但好的摘要会保留核心事实和逻辑关系。量化误差就是摘要过程中丢失的那些“非关键细节”。问题在于，模型里哪些是关键，哪些是非关键？这取决于网络结构。卷积层对权重误差更敏感，因为小权重扰动会通过大感受野放大；而BN层对激活误差更敏感，因为它的归一化参数（mean/var）是用FP32统计的，一旦激活被粗暴截断，统计量就偏了。我实测过一个现象：把ResNet-50的BN层参数也量化成INT8，top-1精度直接掉4.2%；但只量化卷积权重和激活，BN参数保持FP32，精度只掉0.9%。这说明误差不是均匀分布的，而是有“热点区域”。更隐蔽的是误差累积效应：单层误差可能只有0.001，但经过50层传递，最终输出可能偏移0.5以上。这就是为什么PTQ必须做per-channel量化（每通道独立算scale/zero_point），而不是per-tensor——它把误差“摊薄”到各个通道，避免某一层成为瓶颈。所以谈量化误差，不能只看全局MSE，而要看它在关键层、关键路径上的分布。这才是工程落地时真正要盯死的地方。

3. 实操核心环节：从校准、配置到精度验证的完整链路

3.1 校准（Calibration）：不是“喂数据”，而是找模型的“数值性格”

校准是PTQ的起点，但绝不是随便挑100张图扔进去。它的本质是让模型在量化前“热身”，暴露其权重和激活的真实动态范围。我见过太多人栽在校准这一步：用ImageNet validation set直接校准，结果部署后在产线图像上精度崩盘。原因很简单——validation set是干净裁剪图，而产线图有大量模糊、低光照、运动拖影。校准数据必须和真实推理场景同分布。去年优化一个钢铁表面缺陷检测模型，我专门从产线抓取了2000张带油污、反光、局部遮挡的原始图，用这些图校准后，INT8模型在产线测试集上mAP只降0.6%，而用公开数据集校准降了2.3%。校准方法也有讲究。Min-Max校准最简单，取激活值的最大最小值算scale；但遇到离群值（outlier）就灾难性失效——比如某帧图像因强光过曝，某个通道激活值飙到1000，scale就被拉大，其他正常值全被压缩到低位。这时要用Percentile校准（如99.9%分位数），它主动忽略0.1%的极端值。TensorRT默认用EMA（指数移动平均），每批数据更新一次统计量，对动态范围变化大的视频流更友好。实操中我固定用三组校准数据对比：第一组用500张典型场景图做Min-Max；第二组用相同图做99.9% Percentile；第三组用1000张图做EMA。最后选精度最高的那组——这比死磕理论更有效。

3.2 量化配置：Scale/Zero-point不是超参，是硬件契约

Scale和zero-point是量化的核心参数，但很多人把它们当超参调，这是危险的。Scale = (max - min) / (2^bits - 1)，zero-point = round(0 - min / scale)，它们不是可学习的，而是由硬件约束决定的“契约”。比如某国产NPU只支持对称量化（zero-point强制为0），那你用非对称量化（zero-point≠0）生成的模型根本跑不了。再比如，有些DSP要求scale必须是2的幂次方（便于用位移代替除法），你填个1.37就编译报错。我在适配一款车规级MCU时，发现它的INT8乘法单元只支持输入范围[-127,127]，但模型某层激活最大值是132，直接溢出。解决方案不是调scale，而是加clip操作——在fake quant里把激活硬截断到[-127,127]，再算scale。这看起来是妥协，实则是尊重硬件物理限制。另一个关键是per-channel vs per-tensor。卷积权重强烈推荐per-channel量化：每个输出通道独立算scale，因为不同通道响应强度差异极大。我统计过ResNet-50 conv1层，各通道权重标准差从0.02到0.35不等，用per-tensor会把小标准差通道的细节全抹掉。但激活值用per-channel成本太高（要存N个scale），通常用per-tensor就够了。PyTorch的torch.quantization.get_default_qconfig('fbgemm')默认就是权重per-channel、激活per-tensor，这是经过Facebook大规模验证的平衡点。

3.3 精度验证：别信“校准集精度”，要测“产线流水线精度”

精度验证是量化项目最容易被忽悠的环节。很多工具报告“校准集top-1=76.2%”，你一高兴就交付，结果现场跑起来只有72.1%。为什么？因为校准集和真实数据分布不一致，更因为精度验证必须覆盖全流程。我建立了一套四层验证体系：第一层，用校准数据集跑INT8和FP32，看相对误差（<1%算合格）；第二层，用真实产线采集的1000张未见过图，跑端到端推理，记录mAP或accuracy；第三层，做长时间压力测试——连续跑24小时，看精度是否随温度升高而漂移（某款芯片在85℃时INT8乘法误差会增大）；第四层，也是最关键的，做误差溯源：用TensorBoard可视化每一层的激活直方图，看是否有层出现严重截断（histogram尖峰撞到边界）。有一次发现某层BN后的ReLU6，INT8下60%的值都堆在6.0对应的位置，说明量化后大量信息被“削顶”。解决方案不是调参数，而是把ReLU6换成ReLU——去掉上限，让量化空间更宽松。这提醒我们：精度验证不是交差，而是找模型的“脆弱点”，然后针对性加固。

4. 工具链实战与避坑指南：TensorRT、ONNX Runtime与PyTorch的差异战场

4.1 TensorRT：NVIDIA生态的“量化黑盒”，但可控性最强

TensorRT是当前部署端事实标准，它的PTQ流程看似简单：builder.int8_calibrator设校准器，network.mark_output标输出，builder.build_engine生成engine。但“简单”背后全是坑。第一个坑是校准器类型选择：IInt8EntropyCalibrator2是默认推荐，但它对小batch size（<8）不友好，容易统计不准；IInt8MinMaxCalibrator在数据干净时更稳，但怕离群值。我现在的标准动作是：先用MinMax跑一轮，再用Entropy2跑一轮，选精度高的。第二个坑是层融合策略：TensorRT会自动把Conv+BN+ReLU融合成一个kernel，这本是好事，但BN参数如果没在FP32下充分finetune，融合后INT8误差会放大。我的做法是：在PyTorch里先用torch.quantization.fuse_modules手动融合，再导出ONNX，最后进TRT——这样能确保融合逻辑可控。第三个致命坑是dynamic shape支持：TRT 8.5+才支持INT8 dynamic batch，但要求校准时必须用range-based calibration（指定min/max range），不能用data-driven。这意味着你要预估最大batch size下的激活范围，否则runtime报错。我吃过亏：产线要求batch=1~16动态切换，结果TRT engine在batch=16时直接crash。解决方案是：在校准时用最大batch size跑几轮，用get_tensor_dynamic_range提取各tensor的max/min，再写死到calibrator里。这很麻烦，但比现场debug强十倍。

4.2 ONNX Runtime：跨平台“翻译官”，但量化细节藏得深

ONNX Runtime（ORT）的优势是跨平台，一套模型跑Windows/Linux/ARM，但它的量化文档堪称“考古现场”。ORT的PTQ流程分三步：先用quantize_static做权重量化，再用quantize_dynamic做动态量化（适合RNN），最后用QuantizationDataReader喂校准数据。但问题来了：quantize_static默认用Min-Max，而quantize_dynamic用PowerOfTwo，两者scale计算逻辑不一致，混用会出错。我现在的标准流程是：全部用quantize_static，校准器统一用CalibrationDataReader，并显式指定quant_format=QuantFormat.QDQ（QuantizeDequantize模式），这样生成的ONNX模型里每个量化点都清晰可见，方便调试。另一个大坑是opset版本兼容性：ORT 1.15只支持opset 17以下的QDQ模型，而PyTorch 2.0导出默认opset 18。解决方案不是降PyTorch，而是导出时加opset_version=17。还有个隐藏技巧：ORT的InferenceSession可以加载FP32和INT8两个session，用同一份输入数据跑，直接对比输出tensor的L2距离——这比看top-k accuracy更能定位误差源头。我常用这招发现某层GELU激活在INT8下近似误差过大，于是手动替换成SiLU，精度立刻回升。

4.3 PyTorch原生量化：从“玩具”到“生产级”的艰难进化

PyTorch的量化能力这几年突飞猛进，但路线混乱也让很多人迷路。1.8时代是Eager Mode，要手动model.eval()+torch.quantization.prepare+torch.quantization.convert，代码像裹脚布；2.0+转向FX Graph Mode，用prepare_qat_fx和convert_fx，自动图追踪，干净利落。但FX模式有个硬伤：不支持控制流（if/for）和动态shape。我优化一个带attention mask的NLP模型时，FX直接报错“cannot trace through control flow”。解决方案是：把mask逻辑抽成独立module，用@torch.jit.script装饰，再进FX流程。另一个痛点是QAT训练不稳定。PyTorch默认的FakeQuantize在训练初期梯度爆炸，loss直接nan。我的fix是：在QAT训练前，先用PTQ生成一个INT8 baseline，然后用这个baseline的scale/zero-point初始化fake quant的参数，再开QAT——相当于给模型一个“量化锚点”，收敛速度提升2倍。最后是部署导出陷阱：torch.jit.trace导出的模型，fake quant节点会被优化掉，变成纯INT8；而torch.jit.script会保留fake quant，导致runtime报错。必须用torch.jit.trace，且trace时输入要带batch dimension（如torch.randn(1,3,224,224)），否则graph不完整。这些细节，官方文档一笔带过，但线上故障90%出在这里。

5. 常见问题与排查技巧实录：从精度崩盘到硬件报错的全链路诊断

5.1 精度掉点超预期：先查“谁在捣鬼”，再调“怎么修”

精度掉点是量化项目最常遇到的问题，但盲目调参只会让问题更糟。我的标准排查流程分三步：第一步，隔离问题层。用PyTorch的register_forward_hook，在每一层后hook输出tensor，分别保存FP32和INT8的输出，计算cosine similarity。如果某层similarity < 0.95，就是嫌疑层。去年一个YOLOv5模型掉点严重，hook发现neck部分的Concat层输出similarity只有0.42——原来它的输入来自不同尺度特征图，动态范围差异太大，INT8下小尺度特征被淹没。解决方案不是换量化方式，而是给Concat前加个nn.AdaptiveAvgPool2d统一尺寸，再量化。第二步，检查数值分布。用torch.histc画嫌疑层激活直方图，看是否出现“双峰”（如大量值集中在0和最大值）或“断崖”（某段区间完全无值）。双峰说明分布不均，要用Percentile校准；断崖说明有异常值，要加clip。第三步，验证硬件实现。有时精度问题不在模型，而在驱动。比如某款NPU的INT8乘法单元有已知bug：当输入含大量负数时，结果偏移0.3。我的验证方法是：用纯随机tensor构造一个最小case（如torch.randint(-128,127,(1,64,3,3))），在NPU上跑乘法，和CPU FP32结果对比。确认是硬件问题后，就绕过——把该层权重转成FP16，其他层保持INT8。这听着不优雅，但产线要的是稳定，不是教科书完美。

5.2 推理崩溃与报错：硬件报错码是“求救信号”，不是“死刑判决”

推理时出现segmentation fault或CUDA illegal memory access，90%是量化配置越界。第一个高频错误是scale为零或无穷。这通常发生在某层权重全为零（比如dropout后），或校准数据全黑（min=max=0）。TRT报错[E] [TRT] Parameter check failed at: ../builder/Network.cpp::addScale::412, condition: shift->getType() == DataType::kFLOAT，就是scale非法。我的预防措施是：在校准前，对每层权重做torch.std检查，std<1e-6的层跳过量化，保持FP32；对校准数据，加torch.clamp(min=1e-5)防零除。第二个错误是zero-point溢出。INT8 zero-point范围是[-128,127]，但某些极端分布下计算值会超限。ORT报错ValueError: zero_point must be in [-128, 127]。解决方案是：在计算zero-point后，强制torch.clamp(zero_point, -128, 127)。第三个最诡异的错误是tensor shape mismatch。TRT报错[E] [TRT] Network has dynamic or undefined shapes, but no optimization profile has been defined，表面是shape问题，实则是校准时没喂够不同shape的样本。比如模型支持[1,3,H,W]，H/W可变，但校准只用了H=224,W=224，TRT就不知道其他shape的range。对策是：校准数据里必须包含至少3种典型H/W组合（如128x128, 256x256, 416x416），并用set_shape_inputs显式声明。

5.3 性能不达标：不是“量化不够狠”，而是“没摸清硬件脉搏”

量化后延迟没降多少，甚至更高？别急着骂框架，先看硬件特性。我优化一个目标检测模型时，INT8比FP32还慢15%，查下来发现：该NPU的INT8 MAC单元频率比FP16低20%，而模型里大量1x1卷积，MAC密集，自然拖慢。解决方案是：把1x1卷积层保持FP16，其他层INT8——混合精度。实测延迟降35%。另一个常见问题是内存带宽瓶颈。INT8模型体积小，但若访问模式不友好（如channel-last layout），DDR带宽利用率不足，速度上不去。TRT的set_tactic_sources可以强制用特定kernel，我试过1 << TacticSource.CUBLAS_LT，让TRT优先选cublasLt的INT8 kernel，带宽利用率达92%，比默认高18%。还有个反直觉现象：量化后功耗反而升高。某次测试发现INT8功耗比FP32高0.3W，用热成像仪一看，是某层量化后激活稀疏性下降（更多值非零），导致计算单元持续满载。解决方案是：在QAT训练时加稀疏正则项（如torch.nn.L1Losson activation），引导模型学出更稀疏的INT8激活。这需要改训练代码，但换来的是实打实的能效比提升。

提示：所有量化操作必须在模型eval()模式下进行，train()模式会启用dropout/bn training，导致校准统计失真。我见过最惨的案例：开发者忘了model.eval()，校准时bn统计的是training batch的mean/var，生成的INT8模型在推理时bn参数错乱，精度归零。

注意：不要迷信“全模型INT8”。实践证明，embedding层、softmax层、某些特殊激活（如Swish）保持FP16，整体精度和性能更优。量化不是二进制选择，而是精细的“手术分级”。

6. 进阶实战：ViT、Transformer与多模态模型的量化破局点

6.1 ViT类模型：Patch Embedding是“量化雷区”，Attention是“误差放大器”

ViT的量化难度远超CNN，核心难点在两处：Patch Embedding层和Attention机制。Patch Embedding本质是大kernel卷积（如16x16），权重数量巨大，且分布极不均匀——大部分patch相似，权重接近，但少数边缘patch权重突变。用Min-Max校准，突变patch会拉大scale，让多数patch细节丢失。我的解法是：对Patch Embedding层单独用K-Means聚类校准——把权重按channel聚成4类，每类独立算scale/zero-point。实测在ViT-B/16上，top-1精度从PTQ的72.1%升到75.6%。Attention机制更棘手：QKV矩阵乘法结果范围极大，Softmax后又极度稀疏（90%值趋近0）。直接量化QKV，误差会通过Softmax指数级放大。业界主流方案是Separate Quantization：Q、K、V三矩阵分别量化，且Softmax前用FP16计算，输出再量化。Hugging Face的optimum库已内置此方案。另一个关键是Position Embedding：它的权重是固定的，但不同位置值差异小，INT8下极易全归零。我的做法是：Position Embedding层禁用量化，保持FP32，只量化patch embedding和transformer block。这增加不到0.5%模型体积，但精度保住了1.2个百分点。

6.2 多模态模型：文本与视觉的“量化节奏”必须同步

CLIP、Flamingo这类多模态模型，量化时最大的坑是文本和视觉分支“不同步”。视觉分支用ImageNet数据校准，文本分支用WikiText校准，但二者动态范围天差地别：视觉激活常在[0,255]，文本embedding在[-2,2]。强行统一量化，必然有一方失真。我的方案是：分支独立量化，但对齐输出尺度。具体操作：先分别校准视觉和文本分支，得到各自的scale_v、scale_t；再计算一个global scale = sqrt(scale_v * scale_t)，用它重缩放两个分支的输出，使二者L2 norm接近。这样在cross-attention时，query和key的数值尺度匹配，点积结果稳定。实测在CLIP-ViT/B-32上，独立量化+尺度对齐，zero-shot accuracy只降0.4%，而统一量化降2.1%。还有一个隐藏问题：tokenizer的量化。多模态模型前端tokenizer（如BERT tokenizer）输出是int32 token id，但某些NPU不支持int32索引，必须转int8。这时不能简单token_id % 256，会导致语义混淆。正确做法是：用vocab embedding矩阵的L2 norm排序，把高频token（前256个）映射到[0,255]，低频token全映射到0（UNK）。这牺牲了少量长尾词，但保证了主干语义不崩。

6.3 混合精度量化：不是“能省则省”，而是“该省才省”的艺术

混合精度不是偷懒，而是基于硬件特性的精准投资。我的混合精度策略有三条铁律：第一，计算密集层优先INT8：卷积、线性层MAC多，INT8收益最大；第二，访存密集层谨慎INT8：Embedding、LSTM hidden state，INT8虽小但频繁读写，DDR带宽可能成瓶颈，此时FP16更优；第三，数值敏感层保FP16：Softmax、LayerNorm、任何含除法/指数运算的层，INT8近似误差不可控。在部署一个语音合成Tacotron2模型时，我把encoder的Conv1D全INT8，decoder的LSTM cell保持FP16，postnet的Conv1D用INT8，结果MOS评分从3.2（纯INT8）升到3.8（混合），接近FP32的3.9。关键参数是bit-width分配表，我按层类型固化：

这张表不是真理，而是我踩过27个模型坑后总结的“安全基线”。你可以从它出发，用消融实验微调——比如把某层从FP16改成INT8，看精度/延迟变化，再决定是否采纳。

7. 经验沉淀：从100+模型量化实战中提炼的7条硬核法则

做完第100个量化项目时，我整理出这7条不写在任何论文里，但每天都在救火的法则。它们不是理论，是血汗换来的条件反射：

第一条：永远先做PTQ baseline，再决定是否上QAT。QAT训练成本高，但PTQ失败率也高。我的标准动作是：用50张校准图跑PTQ，如果精度损失<1%，直接交付；>2%再启动QAT。这节省了70%项目的QAT开销。

第二条：校准数据质量 > 校准算法复杂度。花三天调Percentile分位数，不如花一天去产线拍500张真实图。我所有成功项目，校准数据都来自真实场景，哪怕只有200张，也比10000张公开数据强。

第三条：硬件spec是量化配置的圣经，不是参考书。某次为某款车规MCU量化，手册写“支持INT8”，但没写“仅支持对称量化”。我按非对称做，编译通过，runtime报错。从此我量化前必做三件事：查芯片手册量化章节、跑官方SDK demo、用最小case验证基础运算。

第四条：误差可视化比精度数字更重要。每次量化后，我必用matplotlib画三层图：1）各层激活直方图叠在一起；2）FP32与INT8输出的scatter plot；3）逐层cosine similarity热力图。图比数字诚实——某次scatter plot显示所有点都沿y=x线密集，但热力图发现最后一层similarity只有0.6，立刻定位到head层问题。

第五条：不要试图量化“一切”。Dropout层、某些custom OP、动态shape控制流，强行量化只会制造新bug。我的原则是：能INT8的层，用INT8；不能的，用FP16；实在不行，FP32。混合精度不是妥协，是务实。

第六条：QAT不是训练终点，而是新起点。QAT训完的模型，必须再做一轮PTQ-style校准（用QAT模型的FP32输出做校准数据），因为QAT改变了激活分布。我见过太多人QAT训完直接导出，结果在TRT里精度掉点，就是因为少了这步“二次校准”。

第七条：量化是部署环节，不是算法环节。算法同学设计模型时，就要考虑量化友好性：少用GELU多用SiLU，BN后接ReLU不接ReLU6，避免大kernel卷积。我在团队推行“量化设计checklist”，从模型诞生第一天就埋下可量化基因。

最后分享一个小技巧：当所有方法都失效，精度卡在临界点，试试量化感知微调（QAT-finetune）——用PTQ生成的INT8模型，加载权重，只开最后2个block的QAT，冻结其他层，用10%数据微调1个epoch。这招在我优化一个医疗分割模型时，把Dice系数从0.821拉到0.839，没增加部署负担，却跨过了临床验收线。量化没有银弹，但有无数把小锤子，关键是你手里握着哪一把，和敢不敢砸下去。