AQLM与HQQ对比：超低位宽量化的未来方向
在大模型从实验室走向真实业务场景的过程中，一个根本性矛盾日益凸显：模型规模的指数级增长与部署资源的线性甚至停滞发展之间的冲突。千亿参数模型动辄占用数十GB显存，使得单卡推理成为奢望，训练更是被锁定在少数巨头手中。这不仅抬高了技术门槛，也限制了AI在边缘设备、中小企业和长尾应用中的落地可能。
正是在这样的背景下，超低位宽量化不再仅仅是“锦上添花”的压缩技巧，而演变为决定模型能否走出数据中心的关键瓶颈突破点。FP16、INT8这些传统手段已逼近极限，而像AQLM（Additive Quantization for Language Models）与HQQ（Half-Quadratic Quantization）这类新兴方法，则代表了新一代智能压缩范式的崛起——它们不再简单地“舍弃精度换体积”，而是通过更精细的结构建模与优化机制，在2~4bit的极低比特下依然维持可用甚至接近原模型的性能。
这两项技术并非孤立存在，而是已被整合进ms-swift等主流框架，支撑着600+文本模型与300+多模态模型的实际部署。它们的区别也不只是数学形式上的差异，更体现在工程实践中的权衡取舍：是追求极致压缩率？还是强调后续可训练性？是在边缘端跑得动？还是为私有数据对齐留出空间？
我们不妨先看一组典型场景：
某初创团队希望将LLaMA-3-8B部署到RTX 3090（24GB显存）上提供API服务。原始FP16版本约需15GB显存，看似可行，但一旦开启vLLM或处理较长上下文，很快就会OOM。若采用GPTQ 4-bit方案，可降至7.5GB左右，勉强可用；但如果使用AQLM将其压缩至2.6bit，显存占用进一步下降到不足5GB，不仅释放出更多内存用于批处理，还能在同张卡上并行运行多个实例。
再换一个例子：一家企业拿到Qwen-7B后，想用内部对话数据做DPO对齐训练。直接在FP16上训练成本过高，而普通PTQ量化后的模型往往难以稳定微调。此时，HQQ的价值就显现出来——它允许冻结量化权重的同时插入LoRA适配器，实现“一次量化、多次迭代”的闭环流程。实测表明，这种组合能在仅增加少量延迟的前提下，使RM评分提升超过18%。
这两个案例揭示了一个事实：今天的量化技术早已超越单纯的推理加速工具，正在成为连接压缩—训练—部署全链路的核心枢纽。
那么，AQLM和HQQ是如何做到这一点的？
AQLM的核心思想源于向量量化领域的经典方法——加性量化（Additive Quantization），但它针对语言模型的权重分布特性做了深度重构。传统标量量化对每个权重独立编码，容易丢失局部相关性；而AQLM则认为，神经网络权重具有高度的结构冗余性和局部相似性，因此可以将其划分为若干组（group-wise），每组由多个小型码本线性叠加重建：
$$
\hat{W} = C_1 + C_2 + \dots + C_k
$$
其中每个 $ C_i $ 是从一个仅含 $ 2^b $ 个基向量的小型码本中选出的结果。例如设置codebook_value_num=4（即2bit），三个码本叠加即可表达远超单一码本容量的组合空间。这种方法本质上是一种低秩分解的非线性推广，能够在极小位宽下捕捉复杂的权重模式。
更重要的是，AQLM的设计天然支持码本共享。不同层或通道可以复用相同的码本结构，大幅降低额外存储开销。这也解释了为何它能在LLaMA-7B上以平均2.56bits/weight实现C-Eval准确率下降小于3%，优于许多4-bit方案。
相比之下，HQQ走的是另一条路径——它不依赖预定义的离散码本，而是将量化建模为一个带正则项的优化问题：
$$
\min_{Z \in \mathcal{Q}} | W - Z |^2 + \lambda R(Z)
$$
这里的 $ Z $ 是代理变量，代表最终的量化权重，$ \mathcal{Q} $ 是允许的离散值集合（如4-bit定点数），而 $ R(Z) $ 是平滑性或其他先验约束。通过ADMM或增广拉格朗日法交替求解，HQQ能动态调整误差分布，确保关键部分（如Attention中的QKV投影）受到更强保护。
这种基于优化的方法赋予了HQQ极强的可控性。比如通过调节lambda_error参数，开发者可以在压缩率与敏感层保真度之间灵活权衡。同时，由于整个过程可微分，梯度可以反传回原始浮点空间，为后续的量化感知训练（QAT）或LoRA微调提供了通路。
这也意味着两种技术在实际使用中呈现出不同的“性格”：
- AQLM更像是“瘦身专家”：它的目标是尽可能轻，适合那些一经部署就不需要频繁更新的场景，比如嵌入式设备上的固定功能模块、长期运行的推理服务。
- HQQ则更像“架构师”：它不追求极限压缩，但注重系统的延展性与稳定性，特别适用于需要持续迭代、进行人类反馈对齐（DPO/KTO）的任务，尤其是在多模态模型中表现稳健。
从代码层面也能看出这种差异。使用ms-swift加载AQLM模型时，你需要明确指定码本维度与数量：
quant_config = { "quant_method": "aqlm", "codebook_dim": 3, "codebook_value_num": 4, # 每个码本4个值 (2bit) "group_size": 64 }这套配置决定了重建精度与计算开销的平衡点。而在HQQ中，你面对的是更贴近优化控制的参数体系：
hqq_config = SwiftConfig.quant_hqq( bits=4, group_size=128, axis=0, round_zero=True, lambda_error=0.8 )这里lambda_error就像是一个“误差调节旋钮”，直接影响量化过程中对原始分布的忠实程度。
在系统架构层面，两者都位于现代大模型工具链的中间环节——介于训练完成之后、服务上线之前。典型的流程如下：
[原始FP16模型] ↓ [量化引擎] → AQLM / HQQ 编码器 ↓ [量化模型包]（含索引 + 码本 / 定点权重） ↓ [推理运行时] ← vLLM / SGLang / LmDeploy ↓ [OpenAI API 兼容接口]这个链条已经高度自动化。用户只需选择模型、设定量化方式与参数，系统就能自动下载预量化版本或执行本地PTQ，并完成部署。像/root/yichuidingyin.sh这样的脚本封装了全流程操作，极大降低了使用门槛。
但在具体选型时，仍有一些经验法则值得参考：
| 考量因素 | 推荐做法 |
|---|---|
| 模型类型 | AQLM更适合纯文本自回归模型；HQQ在视觉-语言对齐等多模态任务中更具鲁棒性 |
| 目标硬件 | 若需部署到Ascend NPU或Apple MPS，优先验证HQQ兼容性，因其生成的是标准定点格式 |
| 是否需要再训练 | 需要DPO/KTO等对齐训练时，推荐HQQ + LoRA组合，避免量化噪声干扰微调过程 |
| 延迟敏感度 | AQLM因需实时查表重建权重，首次推理稍慢，适合长文本生成；短响应场景可选HQQ |
| 开发效率 | 使用ms-swift内置模板免去手动调参，快速验证效果 |
值得一提的是，尽管AQLM目前主要面向PTQ（训练后量化），但已有研究尝试将其与微调结合。不过由于其非连续重建机制，梯度传播不如HQQ稳定。反过来，HQQ虽然支持QAT，但在极端低位宽（<3bit）下的压缩效率仍略逊于AQLM。
这其实反映了当前超低位宽量化的一个深层趋势：未来的最优解或许不在单一方法中，而在两者的融合之中。我们已经开始看到一些工作尝试用HQQ的思想来优化AQLM的码本学习过程，或者利用AQLM的结构先验改进HQQ的初始化策略。这类混合范式有望在保持高重建精度的同时，兼顾训练友好性与硬件适配能力。
随着新一代GPU（如H100）对INT4 Tensor Core的原生支持不断增强，低位宽运算的效率天花板正在被打破。这意味着像AQLM和HQQ这样的技术不再是“妥协之选”，而将成为大模型普惠化的基础设施。它们让中小企业也能负担得起百亿级模型的部署，让移动端真正具备本地化推理能力，也让持续迭代的个性化AI成为可能。
站在这个节点回望，量化已不再是边缘技术，而是推动AI民主化进程的关键杠杆。AQLM与HQQ分别代表了两个方向：一个是极致压缩的艺术，另一个是精准控制的科学。如何选择，取决于你的战场在哪里——是要走得更轻，还是要行得更稳。
