量化后还能继续训练？HQQ与EETQ技术深度解读-编程阁

量化后还能继续训练？HQQ与EETQ技术深度解读

在大模型落地如火如荼的今天，一个现实问题始终困扰着开发者：如何在有限算力下高效迭代部署后的模型？传统流程中，一旦模型被量化压缩用于推理，它就几乎“冻结”了——你想微调？对不起，得先恢复到FP16甚至FP32格式，重新加载完整权重。这个过程不仅耗时，还对硬件提出极高要求，尤其对于7B、13B乃至更大的模型，单卡训练都成奢望。

但有没有可能让量化模型“活”起来？让它既能享受低精度带来的显存和计算优势，又保留持续学习的能力？

答案是肯定的。近年来，可训练量化（Trainable Quantization）正悄然改变这一局面。其中，HQQ（Half-Quadratic Quantization）与EETQ（End-to-End Trainable Quantization）成为最具代表性的两种技术路径。它们打破了“量化即终点”的旧范式，使得“在Int8模型上跑DPO”、“用LoRA优化NF4权重”不再是天方夜谭。

以魔搭社区推出的ms-swift框架为例，其已原生支持 HQQ 与 EETQ 的全流程训练能力，覆盖超过600个主流大语言模型和300多个多模态架构，真正实现了从下载、量化、微调到部署的一体化闭环。这背后的技术逻辑究竟是什么？我们不妨深入拆解。

HQQ：用优化理论“绕开”不可导难题

HQQ 并非为深度学习而生。它的思想源自图像恢复中的半二次最小化（Half-Quadratic Minimization, HQM），通过引入辅助变量将非光滑问题分解为多个易解子问题。当这套方法被迁移到神经网络量化时，竟意外地解决了梯度无法穿越离散操作的核心痛点。

设想我们要最小化这样一个目标函数：

$$
\min_W \mathcal{L}(f(x; W)) + \lambda |W - Q(W)|_F^2
$$

这里的 $ Q(W) $ 是典型的四舍五入量化操作，本身不可导。直接反向传播会断掉梯度流。HQQ 的聪明之处在于：不硬刚这个问题，而是把它“转移”出去。

它引入一个辅助变量 $ V $，把原问题重写为：

$$
\min_{W,V} \mathcal{L}(f(x; W)) + \lambda |W - V|_F^2 + |V - Q(V)|_F^2
$$

现在，我们可以交替优化两个变量：
- 固定 $ V $，更新 $ W $：标准反向传播，梯度畅通无阻；
- 固定 $ W $，更新 $ V $：闭式求解或简单迭代即可逼近最优量化值。

这种分裂策略本质上是在浮点空间维护可训练的原始权重 $ W $，同时用 $ V $ 来承担低比特表示的角色。前向使用量化值，反向则基于浮点副本更新，巧妙规避了对 $ Q(\cdot) $ 求导的需求。

这也解释了为什么 HQQ 能在保持高重建质量的同时支持端到端训练。更重要的是，它的框架足够灵活——每层可以独立设置位宽（2~8 bit）、分组大小（group_size），甚至决定是否量化零点和缩放因子，非常适合异构硬件环境下的精细化控制。

from swift import SwiftModel from swift.quantization import HQQConfig hqq_config = HQQConfig( bits=4, group_size=64, quant_zero=True, quant_scale=True, ) model = SwiftModel.from_pretrained("qwen/Qwen-7B") model = SwiftModel.quantize(model, hqq_config)

这段代码看似简单，实则暗藏玄机。SwiftModel.quantize()返回的不是静态压缩模型，而是一个由HQQLinear构成的动态结构。每个线性层内部都隐式保存了一份浮点权重，并在反向传播中注入重建梯度。这意味着你后续接 LoRA、DoRA 或其他适配器时，整个系统仍能连贯训练，就像从未量化过一样。

当然，天下没有免费午餐。相比 GPTQ 这类纯推理量化方案，HQQ 实现复杂度更高，且需要框架层面的深度集成。但它换来了极为宝贵的特性：训练连续性。这对于资源受限场景下的快速实验尤为关键——你不必再为了微调一次DPO而申请A100集群。

EETQ：构建“全生命周期可用”的量化体系

如果说 HQQ 是一种精巧的数学技巧，那 EETQ 更像是一套完整的工程哲学。它由阿里云团队提出，目标明确：实现“一次量化，全程可用”。无论是预训练、指令微调、人类偏好对齐，还是最终部署，都可以在同一套量化架构下完成。

EETQ 不依赖单一算法，而是一个包含三阶段流程的系统设计：

初始量化建模
利用 BNB 或 GPTQ 对模型进行初步压缩，生成 Int8/NF4 权重。不同于传统做法的是，EETQ 会主动缓存敏感层（如 Attention 输出、MLP 输入）的激活统计信息，为后续补偿提供依据。
误差感知重构
在每一层插入轻量级的误差补偿模块（Error Compensation Module, ECM），形式如下：

$$
y = Q(W)x + \delta(x)
$$

其中 $\delta(x)$ 是一个小 MLP 学习得到的残差项，专门用来拟合量化带来的前向偏差。由于只作用于输出端，ECM 增加的参数不到1%，却能显著提升低精度下的表达能力。

端到端微调优化
进入训练阶段后，可以选择冻结主干权重仅训 ECM 和 LoRA，也可以联合优化全部参数。整个过程中，伪量化节点（FakeQuant Node）始终模拟真实量化行为，在反向传播中保留梯度通路。

正是这套机制，让 EETQ 实现了真正的“端到端可训练性”。你在 Int8 模型上运行 DPO，其实是在优化两个部分：一是 LoRA 适配器，二是各层的误差补偿器。前者捕捉任务特定知识，后者修正底层精度损失，二者协同工作，使整体性能逼近 FP16 微调结果。

eetq_config = EETQConfig( bits=8, enable_ecm=True, ecm_hiddens=[64, 32], calib_batches=16, calib_seq_len=2048, ) model = SwiftModel.quantize(model, eetq_config) dpo_trainer = DPOTrainer(model=model, ...) dpo_trainer.train()

注意这里的关键配置enable_ecm=True。一旦开启，框架便会自动为每个线性层注入可学习的修正分支。更进一步，DPOTrainer已做好兼容处理，无需额外转换即可直接作用于量化模型。这种“开箱即用”的体验，极大降低了部署后微调的技术门槛。

根据 ms-swift 的 benchmark 数据，在 A100 上对 Baichuan2-13B 应用 EETQ 后：
- 显存占用降低 50%~70%
- 微调延迟增加 <15%（batch > 8）
- 支持 LoRA、QLoRA、DoRA、DPO、KTO 等全部主流对齐方法
- 导出模型兼容 vLLM、SGLang、LmDeploy 等主流推理引擎

这意味着你可以用一张 A10 完成原本需要双卡 A100 才能跑动的任务。更重要的是，这套流程完全插件式接入 Hugging Face Transformers，无需修改任何模型结构，真正做到了低侵入、高可用。

场景落地：从“部署即终结”到“持续进化”

在ms-swift的统一架构下，HQQ 与 EETQ 共同支撑起一条全新的开发流水线：

[预训练模型] ↓ (下载) [量化处理 HQQ/EETQ] → [量化模型] ↓ ↘ [LoRA/DoRA/DPO 微调] ←——— [支持继续训练] ↓ [评测 EvalScope] ↓ [部署 vLLM/SGLang/LmDeploy]

这条链路最革命性的意义在于：模型上线不再是终点，而是新周期的起点。

想象这样一个典型场景：你在边缘设备上部署了一个 Int8 版本的 Qwen-7B，用于客服问答。一段时间后发现模型在某些专业术语上的回答不够准确。过去的做法是收集反馈数据，回传至中心服务器，重新加载 FP16 模型做一轮微调，再重新量化打包下发——整个过程可能耗时数小时。

而现在，借助 EETQ 的端到端可训练性，你可以直接在终端侧执行轻量级 KTO 或 CPO 微调。只需几百条样本、几分钟时间，模型就能完成局部修正并立即生效。这就是所谓的“热更新”能力，也是迈向“自我优化系统”的第一步。

类似逻辑也适用于低成本对齐实验。以往尝试不同的 RLHF 策略，往往意味着反复切换精度格式、重启训练进程。而现在，你可以在同一个 Int8 模型上快速试错多种方法（DPO vs ORPO vs KTO），大幅缩短探索周期。

当然，实际应用中也有不少细节需要注意：

量化粒度要因地制宜：注意力层建议使用较小的 group_size（如64），以保留更多精细特征；FFN 层则可放宽至128甚至256，换取更高压缩效率。
校准数据必须有代表性：EETQ 的误差补偿依赖校准阶段的统计信息。如果用通用语料校准，却在医疗领域微调，很可能出现补偿失效的情况。
极低位宽慎用联合训练：当 bits < 4 时，主权重稳定性下降明显。此时建议冻结量化层，仅训练 LoRA 或 ECM，避免梯度扰动引发性能崩溃。
监控量化漂移现象：长期训练可能导致某些层的输出分布发生偏移。定期检查 KL 散度或均值方差变化，有助于及时发现问题。