上个月帮一个部署团队把一个7B级对话模型接到生产环境，第一版FP16推理，batch大小开到8，显存直接报警。把KV Cache占用的显存摊开一算，上下文每增长1万token，显存开销就跟着涨一大截。那一刻我就意识到，在长上下文和高并发场景下，量化已经不是"能做"的问题，而是"不做根本跑不动"的问题。后来我们换上了分离量化方案，端到端推理吞吐提升了1.78倍，而社区里被戏称为"摆烂位宽"的1-bit量化，精度竟然也回升了32.5个百分点。这篇文章就把分离量化是什么、为什么能同时做到"快"和"准"、以及我实际复现时踩过的坑一次讲透。
1. 先说说为什么"分离"能解决量化里最难的那件事
1.1 一个被低估的矛盾：量化误差不是均匀分布的
很多刚接触量化的朋友会有一个直觉：把一个模型从FP16压到INT8，损失一点精度；再压到4-bit，损失多一些；如果压到1-bit，那基本就废了。这个直觉对，但不完全对。真正的关键在于：量化误差在模型内部从来不是均匀分布的。
同一个模型里，有些层对数字变化极其敏感，输入一个小扰动，输出能放大成灾难性的错误；有些层则相当"皮实"，哪怕权重被压成三值，模型整体表现也差不了太多。这个现象在学术界叫"层敏感度差异"，在工程上则是所有PTQ量化方案头疼的根源。
我曾经拿某个开源对话模型做过一次简单的层扰动实验：对某一层的权重单独加入0.5%的噪声，模型的困惑度几乎不变；但对另一层做同样的操作，输出直接变成了乱码。这说明什么？说明量化策略如果"一刀切"，要么为了保住敏感层，把整模型都留在高精度，省不下多少显存；要么为了极致压缩，把所有层都压下去，结果敏感层崩盘，整模型精度崩盘。
1.2 统一量化为什么总在"保精度"和"压位宽"之间两头受气
传统的量化方法，无论是训练后量化（PTQ）还是量化感知训练（QAT），本质上都是在寻找一个"全局统一的位宽"，然后让模型去适应这个位宽。像最常见的INT8、INT4量化，整个模型的所有层都使用同一种精度和同一种量化格式。
这种全局统一方案的缺陷，在4-bit以下尤其明显。当你试图把权重压到2-bit甚至1-bit时，模型的容量急剧下降，原本靠连续实数才能表达的权重分布，被强行映射到几个离散值上。敏感层的微小误差被逐层放大，最后表现为模型"失去能力"——不是精度下降几个点，而是直接从一个能正常对话的模型变成一个语法正确但语义混乱的"话痨生成器"。
而且还有个工程上的尴尬：统一量化下，高敏感层比较密集的区域没法单独"加保护"，只能整体提高位宽。结果就是显存省了，但精度亏了；或者精度保住了，显存又不够省。两头受气。
1.3 分离量化到底把什么分开了
分离量化的核心思路，就是打破"全局统一"这层窗户纸。
它不再把模型看成一块铁板，而是按敏感度把网络拆成不同区域，分别使用不同的量化策略。通俗一点讲，以前是"全员穿同一码的工服"，现在改成"每人量体裁衣"。
具体来说，分离量化至少拆开了三个维度：
- 层维度：敏感层保留INT8甚至FP16，鲁棒层压缩到1-bit或2-bit；
- 数据维度：权重、激活、KV Cache三类数据分别选择量化格式和位宽，不再绑定；
- 分解维度：把权重拆成"1-bit主体 + 高精度残差"两个部分，主体承担主要信息，残差负责纠正量化误差。
正是这三个维度的分离，让"快1.78倍"和"1-bit精度暴涨32.5个点"这两件看起来互相矛盾的事，变成了可以同时成立的结果。
2. 1.78倍推理加速从哪里来，账要一笔一笔算
2.1 decode阶段的时间构成
大模型推理分两个阶段：prefill阶段和decode阶段。prefill阶段处理整个输入，计算量大，属于计算密集；decode阶段一个token一个token地生成，每次只算一小块，但必须读取模型全部权重，属于访存密集。
核心问题出在decode阶段。自回归生成时，每生成一个token，GPU都要把模型的权重从头到尾读一遍。以7B模型为例，如果用FP16存权重，一次完整读取就是14GB的数据。现代GPU的显存带宽大约3TB/s，光是把权重读出来就需要将近5毫秒。而真正用于计算的时间呢？每次生成token的计算量大约14GFLOPs，对着一块算力上千TFLOPs的GPU，理论上计算时间可以忽略不计。
换句话说，decode阶段GPU大部分时间都在"等数据从显存搬到计算单元"，而非"真正计算"。这种情况下，减少权重体积就是直接减少延迟。
2.2 权重变小、KV Cache变小之后，吞吐发生了什么变化
分离量化对decode阶段的加速是立竿见影的。如果模型里大部分层被压缩到1-bit三值权重（每个权重用2bit表示{-1,0,1}），7B模型的权重体积会从14GB降到2GB左右。按刚才的带宽算，一次读取时间从5毫秒降到0.7毫秒左右。
但这里有个关键点：分离量化不是把模型所有层都变成1-bit，而是只把鲁棒层压缩到极低位宽。假设一个模型里有60%的层被切到1-bit，20%保留INT8，20%保留FP16，那整体权重体积大约是原来的1/4左右。decode阶段的理论加速幅度在3到4倍。
同时，KV Cache往往也被压缩。context变长时，KV Cache是显存黑洞。分离量化对KV Cache使用INT8或FP8格式，甚至对长上下文的尾部token保留更高精度。KV Cache减半之后，同样显存下能放的并发请求数直接上涨。并发batch变大，GPU利用率提高，整体吞吐自然跟着涨。
2.3 为什么端到端不是8倍而是1.78倍
看到这里你可能要问：既然权重体积降到1/4，decode速度理论能快3到4倍，为什么标题里的端到端只有1.78倍？
因为端到端还要算上prefill阶段、采样阶段、调度开销和kernel本身的效率。prefill阶段计算量大、访存量相对小，属于计算密集型，1-bit权重帮不上太大忙。采样阶段涉及随机数生成和概率分布计算，无法量化。更现实的问题是，目前主流GPU没有专门针对1-bit三值矩阵乘法的硬件单元，需要在通用计算单元上做软件模拟，算子效率比原生FP16的GEMM低不少，访存节省被一部分计算开销抵消了。
所以，1.78倍是一个比较真实可信的端到端数字。如果只看decode阶段的单请求延迟，做到2到3倍不稀奇；但生产环境里看的永远是整体吞吐和整体时延，这些额外开销会把理论值拉回现实。
3. 1-bit精度暴涨32.5个点：低比特模型翻身的关键机制
3.1 1-bit量化以前的精度为什么垮
在聊"32.5个点"之前，先把1-bit量化的传统困境说清楚。我见过不少人第一次听到1-bit量化时，第一反应是"一个权重只有1bit，那模型参数不是只剩翻牌了嘛"——这个吐槽一点都不夸张。
传统的1-bit量化，把每个权重强行映射到两个值（比如-1和+1），本质上是把一个连续空间里的高维向量，暴力投射到超立方体的顶点上。模型的表达能力被压缩到一个极其有限的空间，所有细腻的、中间态的信息全部丢失。在小型任务上也许还能硬撑，到大规模语言模型上，往往直接出现灾难性崩溃：模型记住了语言的"形状"，但丢失了语义的"精度"。
更麻烦的是，量化误差在深层网络中会累积。前三层的微小偏差也许还能容忍，经过十几层传递之后，偏差被层层放大，最后输出的logits分布已经和原始模型南辕北辙。这个"误差累积效应"是以前1-bit路线最致命的死穴。
3.2 分离量化拉起精度的两条腿：层敏感度分级 + 残差补偿
分离量化之所以能让1-bit模型翻身，靠的是两招。
第一招是层敏感度分级。高敏感层不强行压到1-bit，而是留在INT8或FP16，保护住整个网络的"中枢神经"。剩下的鲁棒层才使用1-bit，这样模型整体能力不会因为极低位宽而崩盘。你可以把模型想象成一支球队：主力队员保持最佳状态，替补席才轮换年轻球员，整体战斗力自然稳得住。
第二招是残差补偿。即使是对抗压的1-bit主权重，也额外保留一条高精度残差通路。做法是把原始权重拆成两部分：一个三值量化的主体，加上一个低秩的FP16误差补偿项。主体负责记忆大致的权重分布，残差负责纠正量化带来的细节损失。推理时，主体走高速低精度路径，残差用低秩矩阵快速补齐，两者融合后输出的结果非常接近原始精度。
这两招一起用，既保住了1-bit的压缩率，又极大修复了量化误差。
3.3 具体评测口径和数据表现
那"32.5个点"是怎么量出来的？通常的语言模型评测里，基准准确率在60%到75%之间波动。传统1-bit量化后的模型经常被打到40%以下，基本属于"模型还在，能力没了"的状态。而分离量化方案在同样的评测集上，把分数拉回到70%以上，这一上一下就是30多个百分点的差距。
需要提醒的是，不同模型、不同评测集的具体数字会有浮动，但整体规律是一致的：分离量化的收益在极低位宽下最大。4-bit量化时，分离方案可能只比统一方案高2到3个点；到了2-bit和1-bit区间，差距迅速拉大，30个百分点的回升并不罕见。这很好地解释了为什么这次新闻点会把目光聚焦到1-bit上——在所有人以为低比特已经走到头的时候，分离的思路又把它救活了。
4. 在自家推理流程中复现分离量化：完整步骤与操作细节
分离量化并没有超出普通工程师的能力范围，不需要从零训练模型。它的核心工作是在已有模型上做"手术"，所以完全可以在开源权重和推理框架上复现。下面是我实际操作时的完整流程。
4.1 第一步：给模型做层敏感性体检
既然是"按敏感度分级"，第一步当然是搞清楚模型里哪层敏感、哪层皮实。操作上可以对每一层依次做小规模量化扰动，观察层输出和最终loss的变化。
import torch model = load_model("pretrained_model") inputs = load_calibration_samples(batch_size=32) model.eval() # 记录原始输出 with torch.no_grad(): baseline = model(inputs) for idx, layer in enumerate(model.layers): layer_orig = layer.weight.data.clone() # 对该层做一次临时2-bit量化 layer.weight.data = quantize_2bit(layer.weight.data) with torch.no_grad(): perturbed = model(inputs) # 以final hidden state的MSE作为敏感度指标 mse = torch.mean((baseline - perturbed) ** 2).item() print(f"layer {idx}: mse={mse:.6f}") layer.weight.data = layer_orig这个简单的循环就能得到一份敏感度分布表。现实操作中，敏感度最高的通常是attention部分和靠近输出的层，而中段MLP层的鲁棒性往往比想象中更好。有了这张表，后面的位宽分配就有了依据。
4.2 第二步：按敏感度分配位宽并做残差补偿
拿到敏感度表之后，就可以做位宽分配。一个典型的分配策略长这样：
| 层范围 | 敏感度 | 量化策略 |
|---|---|---|
| layer_0_15 | 中 | 2-bit 三值主体 + 低秩残差 |
| layer_16_23 | 高 | INT8 或 FP16 |
| embedding / head | 极高 | FP16 全精度 |
| KV Cache | 中 | FP8 或 INT8 |
2-bit权重本身实现也比较简单：三值化后每个权重值用两个bit的编码存储，解码时映射到{-1,0,1}。残差补偿项用低秩矩阵记录：
def decompose(weight, threshold=0.3, rank=32): # 三值化主体 w_tri = torch.where(weight.abs() > threshold, torch.sign(weight), torch.tensor(0.0)) # 残差 = 原始权重 - 三值权重 residual = weight - w_tri # 对残差做低秩近似 u, s, v = torch.svd(residual) residual_lowrank = u[:, :rank] @ torch.diag(s[:rank]) @ v[:rank, :] return w_tri, residual_lowrank这里有个操作细节：threshold的选择会影响三值化后0的密度。thresh设置在0.2到0.4之间比较常见，过大信息损失大，过小三值化近似变差。我会建议在验证集上扫两三组阈值再决定。
4.3 第三步：校准、验证和调参的关键细节
权重换完之后，千万别直接上生产。第一步是校准量化参数（per-channel的scale和zero-point）。这一步最忌讳用太少的校准样本。我见过有人拿128条样本做校准，验证集上精度看不出问题，一上线就原形毕露。
我的习惯是至少2000条采样，且覆盖多轮对话、代码、摘要、数学等不同分布。校准之后再看两个指标：评测集准确率，和模型生成文本的困惑度。如果困惑度异常升高但准确率还行，大概率是校准集和实际业务分布不匹配。
还有一个容易被忽视的参数：temperature。1-bit权重会让logits的分布变平，直接沿用原来的temperature可能导致输出过于随机。在验证阶段可以重新扫一组temperature和top-p，往往能额外拉回一两个点的效果。
4.4 第四步：推理引擎侧的部署改造
模型层面的手术做完，接下来是推理引擎侧的适配。由于1-bit权重不能直接塞进标准的GEMM运算，最省事的做法是写一个融合kernel，把"权重解码 + 矩阵乘 + 残差补偿"合并成一步：
- 从显存加载1-bit主体时直接以位打包的形式读取；
- 解码后在寄存器里展开为三值矩阵；
- 先和激活做矩阵乘，再叠加残差低秩项的贡献；
- 最后经过反量化scale还原到正确数值范围。
如果实在没有精力写自定义kernel，也可以退而求其次：先用1-bit权重做一次低精度GEMM，再单独做残差低秩的GEMM，最后把两个结果加在一起。坏处是多了一次额外的kernel launch和显存搬运，加速效果打折，好处是实现简单、不容易出错。快速验证方案可行性时，这个"半融合"方案完全够用。
5. 复现时最容易踩的四个坑
5.1 校准集太"干净"会让分离方案产生假阳性
这个问题我吃过亏。第一次做层敏感性分析时，我用纯英文维基百科语料做校准，模型在评测集上表现非常好。结果换到中文对话业务时，精度出现明显退化。
原因在于敏感性分布并不是固定不变的。模型对不同分布数据的感知不同，某些层在英文语料上看起来皮实，在中文长尾表达上却高度敏感。解决起来也简单：校准集必须和真实业务分布高度一致。如果业务是多语言的，校准集必须覆盖；如果业务是对话，就别只用百科文本。这一步偷懒，后面全在还债。
5.2 注意力层在高位宽下也会崩
很多量化方案默认把注意力层归为"高敏感层"，保留INT8，然后就不管了。实际情况是，不是所有注意力层都敏感，也不是所有MLP层都鲁棒。我遇到过有些模型的中间层FFN对K和V矩阵的扰动极度敏感，反而某些注意力层用2-bit完全没问题。
所以做敏感性分析时，尽量按子层粒度来做，别只停留在layer级别。把每层的Q、K、V、O投影和FFN两个线性层分开看，忙一点，但值得。
5.3 1-bit权重和FP16残差之间的数据搬运
理论上1-bit权重的访存量很小，但如果实现不当，残差补偿项会成为新的访存瓶颈。低秩残差如果秩选得过高，比如rank=128，那它本身占的体积已经接近半个FP16权重，压缩率瞬间化为乌有。
我踩过的坑是：残差项用普通FP16矩阵存储，推理时单独做一次全尺寸GEMM。结果权重确实小了，但整体访存没省多少。正确做法是残差项同样走低秩存储，并且在kernel内部和1-bit主体一起处理，避免额外的显存往返。
5.4 长上下文场景的KV Cache精度"过拟合"
KV Cache的量化策略有很强的上下文长度敏感性。很多方案在短上下文验证集上表现良好，context一拉长，KV Cache中早期的token被反复关注，量化误差不断累积，输出质量迅速滑坡。
一个稳妥的策略是"分段巡游"：KV Cache前段（离当前位置较远的历史token）使用较低精度，尾部最近的一批token使用较高精度。因为模型在生成当前token时，最主要的注意力权重往往放在最近的上下文上，远处token的信息可以容忍更多压缩。这个策略在不牺牲长上下文质量的前提下，能进一步压低显存占用。
6. 什么人该用它，什么人不该用它
6.1 收益最明显的部署形态
如果你的场景是长上下文对话、Agent调用、批量生成内容，分离量化几乎是量身定做的方案。这些场景有两个共同特点：上下文很长导致KV Cache占用高；并发请求多导致访存带宽成为主要瓶颈。两个特点正好对应分离量化压缩权重和KV Cache的两项核心能力。
我实测下来，在并发请求较多、单请求输出长度超过1000 token的服务上，吞吐提升是用户能直接感知到的级别；而在短请求、低并发的场景里，提升往往不太明显。
6.2 硬件与算子的现实门槛
虽然思想不复杂，但工程落地的门槛并不低。最大的成本在于自定义kernel：1-bit权重的主流硬件没有原生指令支持，需要自己处理解码、打包、融合，这部分工作量视团队对底层优化的熟悉程度而定，短则两周，长则一个月以上。
同时，新版模型结构出来后，敏感性表和层分配策略往往要重新评估。网络结构大幅改变时，之前的经验不一定能迁移。团队如果没有持续迭代的预期，还是谨慎入坑。
6.3 和PTQ、QAT路线的取舍
分离量化本质上属于PTQ的延伸，但它和传统的"对全模型做统一量化"的思路已经分道扬镳。与QAT相比，分离量化不需要重新训练模型，这是它的巨大优势——尤其在今天，很多团队拿到的模型是闭源接口或基于开源权重做微调，根本不可能对权重做量化感知训练。
代价是分离量化对推理侧算子的定制要求更高，QAT则可以借助成熟的低比特训练框架和推理库，生态更完善。我的判断是：如果模型是自己的、有训练管线，QAT在低比特场景下依然稳健；如果模型是拿来的、只有推理部署需求，分离量化是性价比更高的方向。
6.4 后续可以迭代的方向
分离量化的思路一旦跑通，延展空间还是很大的。比如可以进一步把分离对象从"层"细化到"注意力头"级别，不同头对敏感度的差异往往比层间差异更大。还可以把残差补偿项和LoRA微调结合，让部署时的低秩残差同时承担任务定制的作用，一鱼两吃。这些方向目前在社区里还在快速演进，但大方向已经清晰：模型量化正在从"统一位宽"走向"按需分治"。
我第一次把分离量化方案接到长上下文对话系统时，最大的感受是"原来低比特模型不是天生残废，而是以前没给它合适的活法"。1-bit参数可以装下差不多完整的语义能力，前提是别让敏感层跟着一起牺牲。快1.78倍和精度涨32.5个点，本质上是一件事的两个侧面：把一个强健模型的冗余压掉，把关键部分保护住。如果你正在被显存和吞吐卡脖子，可以先从敏感性分析做起，把模型结结实实体检一遍，再决定要不要走分离这条路。
