分离量化：1-bit精度暴涨32.5个点，推理加速1.78倍

1. 从"跑得动"到"跑得快"：分离量化到底在解决什么问题

大模型推理部署这件事，做过的人都知道一个残酷的现实：模型参数量的增长速度，远远快过显存带宽和算力的增长速度。你手里有一张消费级显卡，想跑一个70B级别的模型，全精度权重光是加载就要吃掉一百多GB显存，根本放不下。于是量化就成了绕不开的路——把FP16的权重压到INT8、INT4甚至更低，用精度换空间和速度。

但量化这条路走到4-bit以下，问题就开始集中爆发了。传统的整数量化方案，比如把权重统一映射到INT4的16个离散值上，对于大多数权重来说还能接受，可总有一小撮"刺头"权重——它们的数值特别大或者特别关键，一旦被粗暴地塞进低比特的格子里，模型的输出质量就会断崖式下跌。你可能会看到模型开始胡言乱语、逻辑断裂、重复输出，甚至完全答非所问。

NVIDIA这次提出的分离量化技术，核心思路就是不再"一刀切"地对待所有参数。它把权重拆成两部分来处理：一部分走低比特的量化路径，另一部分——也就是那些对精度影响最大的关键权重——单独拎出来用更高精度保留。这个思路听起来简单，但真正落地时要解决三个硬骨头：怎么判断哪些权重该被"分离"出来、分离后的两部分怎么协同计算、以及怎么保证推理时的访存效率不被打回原形。

我最初看到"1-bit精度暴涨32.5个点"这个说法时，第一反应是怀疑。因为1-bit量化意味着每个权重只有正负两个取值，信息量被压缩到了极致，理论上精度损失应该非常严重才对。但仔细拆解后发现，这里的"1-bit"并不是说整个模型都用1-bit跑，而是分离量化框架下，主体部分用极低比特承载，关键部分用高精度补偿，最终在特定基准上相比朴素1-bit方案提升了32.5个百分点。这个数字的意义在于：它证明了"分离"这个策略在极低比特区间是有效的，而不是说1-bit本身能打。

这篇文章我会从工程落地的角度，把分离量化的原理、实现路径、实测数据解读、以及部署时容易踩的坑，一层层拆开讲清楚。适合正在做模型压缩、推理加速的工程师，也适合想理解低比特量化前沿思路的技术爱好者。读完之后，你应该能判断自己的场景适不适合上这套方案，以及如果上，第一步该从哪里动手。

2. 分离量化的底层逻辑：为什么"区别对待"比"一视同仁"更聪明

2.1 权重分布的长尾特性：少数参数决定多数质量

要理解分离量化为什么有效，得先看权重本身的分布长尾。在一个训练好的Transformer模型里，绝大多数权重值都集中在零附近，形成一个尖锐的峰。但与此同时，总有少量权重的绝对值明显偏大，它们分布在长尾区域。这些长尾权重数量占比可能不到1%，但对模型输出的影响却远超其数量占比。

打个比方，这就像一个班级里，大部分学生的成绩都在70到90分之间，但有那么两三个学生要么考满分要么考零分。如果你用统一的标准去评估所有人，那几个极端值就会把整体统计量拉偏。量化也是一样：当你用INT4的尺度因子去覆盖整个权重范围时，为了让那些大权重不被截断，尺度因子会被迫放大，导致大量小权重被压缩到很少的几个量化级别上，精度损失严重。

分离量化的做法是：先用一个阈值把权重分成"主体"和"离群"两组。主体部分数值集中，用低比特量化绰绰有余；离群部分数量少但数值大，单独用高精度（比如FP16或INT8）保留。这样主体部分的量化尺度可以设得很精细，离群部分也不会因为被强行压缩而丢失信息。

2.2 分离阈值的选取：太松没效果，太紧伤性能

阈值怎么定，是分离量化的第一个关键决策。如果阈值设得太宽松，被分离出来的权重太多，那低比特量化的收益就被稀释了——你本来想省显存，结果高精度部分占了一大块，得不偿失。反过来，阈值太紧，该被保护的关键权重没被保护到，精度照样崩。

实践中常用的做法是基于权重的标准差来定阈值。比如把超过均值加三倍标准差的权重视为离群点。这个三倍标准差不是拍脑袋来的，它对应正态分布下约0.3%的尾部概率，正好符合大多数Transformer权重的长尾特征。当然，不同层、不同模型的最优阈值会有差异，需要做小规模的校准实验。

我自己的经验是，可以先在一个小校准集上跑一遍，统计每层被分离的权重比例。如果某层分离比例超过5%，说明这层的权重分布特别分散，可能需要单独调整阈值，或者考虑对这层整体用更高比特。这个校准过程通常只需要几百条样本，耗时几分钟，但能避免后面大规模部署时的精度翻车。

2.3 两部分权重的协同计算：不是简单相加

分离之后，推理时怎么算？最直觉的想法是分别算完再相加，但这样会带来额外的访存开销。假设主体部分用INT4，离群部分用FP16，你需要同时加载两套权重、做两次矩阵乘、再合并结果。如果实现不当，访存带宽反而成了瓶颈，速度提升就被吃掉了。

NVIDIA的方案在这一点上做了优化：它把离群权重的计算融合进了主体计算流程里，利用GPU的并行能力，在同一个kernel里完成两部分的加载和计算。具体来说，主体权重走标准的低比特矩阵乘路径，离群权重则以稀疏形式参与计算，只对它们对应的输出通道产生贡献。这样既避免了额外的kernel启动开销，也减少了中间结果的写回次数。

这里有个容易忽略的细节：离群权重的索引也需要存储。如果索引用32位整数存，那索引本身的开销可能就抵消了权重压缩的收益。所以实际实现中，索引通常用位图或者压缩编码来存，把额外开销控制在可接受范围内。

3. 1-bit场景下的实测表现：32.5个点到底意味着什么

3.1 基准测试的解读：别被单一数字带偏

"1-bit精度暴涨32.5个点"这个说法，需要放在具体语境里理解。首先，这里的1-bit指的是主体权重的量化比特数，不是整个模型。其次，32.5个点的提升是相对于什么基线？如果是相对于朴素1-bit量化方案，那这个提升幅度确实惊人，因为朴素1-bit在大多数任务上基本不可用，精度可能只有随机猜测的水平。从接近随机提升到勉强可用，32.5个点并不夸张。

但如果你把它理解为"1-bit模型能达到FP16模型的精度"，那就完全错了。分离量化在1-bit主体下的表现，通常还是明显低于4-bit或8-bit方案的。它的价值在于：在极端压缩场景下（比如显存极度受限、必须把模型塞进极小空间），它提供了一个比朴素方案好得多的选择，而不是说它能替代常规量化。

我在一个文本生成任务上做过对比测试，用同一个7B模型，分别跑FP16、INT8、INT4、分离量化1-bit主体四个配置。结果FP16的生成质量最好，INT8几乎无损，INT4有轻微退化但可接受，分离量化1-bit主体则出现了明显的重复和逻辑跳跃，但至少能生成通顺的句子，不像朴素1-bit那样直接输出乱码。这个结果符合预期：分离量化是在极端条件下的兜底方案，不是日常首选。

3.2 速度提升1.78倍的来源拆解

1.78倍的推理加速，这个数字也需要拆开看。加速主要来自两个层面：一是权重体积缩小带来的访存减少，二是低比特矩阵乘本身的算力效率提升。

访存方面，如果主体权重从FP16压到1-bit，理论上的体积缩小是16倍。但实际中因为要存离群权重和索引，净压缩比可能只有8到10倍。即便如此，对于访存瓶颈明显的大模型推理来说，这已经能带来显著的延迟下降。

算力方面，低比特矩阵乘在支持相应指令的硬件上，吞吐量远高于FP16。比如某些架构对INT4矩阵乘有专门的加速单元，理论算力是FP16的数倍。但实际加速比会被其他环节拖累——比如注意力计算、层归一化、激活函数这些部分通常还是FP16，它们不随权重量化而加速，所以整体加速比会低于纯矩阵乘的加速比。

1.78倍这个数字，大概率是在特定模型、特定硬件、特定batch size下测出来的。换一个模型或者换一个batch size，数字会变。我建议你在自己的场景下实测，而不是直接套用这个数字做容量规划。

3.3 精度与速度的权衡曲线：找到你的甜点

分离量化给了你一个可调的旋钮：主体比特数和离群比例。主体比特数越低，速度越快但精度越差；离群比例越高，精度越好但压缩收益越小。这两者之间存在一条权衡曲线，你需要根据自己的精度容忍度和速度要求，找到曲线上的甜点。

我的做法是：先定一个可接受的最低精度（比如在某个评测集上不低于FP16的95%），然后在这个约束下，尽量压低主体比特数和离群比例。通常主体用2-bit或3-bit，离群比例控制在1%到3%之间，能在精度和速度之间取得不错的平衡。1-bit主体只在极端场景下考虑，比如显存实在不够，或者对生成质量要求不高。

4. 落地部署的完整路径：从模型检查到推理服务

4.1 环境准备与工具链选择

要跑分离量化，你需要一套支持低比特矩阵乘的推理框架。目前主流的选择包括TensorRT、以及一些支持自定义量化方案的开源推理引擎。TensorRT对NVIDIA自家硬件的支持最完善，低比特kernel的优化也最到位，如果你用的是NVIDIA显卡，优先考虑它。

工具链方面，你需要一个能导出模型权重、做量化校准、并生成推理引擎的流程。典型步骤是：先把训练好的模型导出成ONNX或类似格式，然后用校准集统计权重分布、确定分离阈值，接着做量化转换，最后编译成推理引擎。每一步都有坑，下面会细说。

硬件方面，分离量化的加速效果依赖于显卡是否支持低比特矩阵乘指令。较新的架构通常支持INT4甚至更低比特的矩阵乘，老架构可能只支持到INT8。如果你用的是老卡，分离量化的速度收益会打折扣，但精度收益仍然存在。

4.2 校准集的选择与阈值调优

校准集的选择直接影响分离阈值的质量。校准集应该尽可能贴近你的实际推理数据分布。如果你做的是对话模型，校准集就用真实对话样本；如果是代码生成，就用代码片段。用错校准集，阈值就会偏，该保护的权重没保护到，精度就会掉。

校准集的大小也有讲究。太小了统计不稳定，太大了耗时。我的经验是几百到一千条样本足够，关键是覆盖足够的多样性。如果任务本身比较单一，样本数可以再少一些。

阈值调优可以做成一个自动化流程：设定几个候选阈值，分别跑校准，看哪个阈值下精度损失最小、同时分离比例最低。这个搜索过程通常几轮就能收敛，不需要太复杂的调参。

4.3 推理引擎的编译与性能验证

编译推理引擎时，有几个参数需要特别注意。首先是最大batch size，它决定了显存预分配的大小。设太大了浪费显存，设太小了限制吞吐。建议根据实际服务的并发量来定，留一点余量。

其次是低比特kernel的启用开关。有些框架默认不启用低比特路径，需要显式打开。打开之后，还要确认你的显卡架构确实支持，否则可能回退到FP16路径，速度没提升还多了量化误差。

编译完成后，一定要做性能验证。验证分两部分：精度验证和速度验证。精度验证用你关心的评测集，对比量化前后的指标差异；速度验证用真实请求压测，看延迟和吞吐是否达到预期。我见过不少案例，量化后精度没问题，但速度反而慢了，原因通常是访存模式变了，或者kernel没被正确调用。

4.4 服务化部署的注意事项

把量化模型部署成在线服务时，有几个坑要提前避开。第一是显存碎片问题：低比特权重和FP16激活值混在一起，显存分配器可能产生碎片，长时间运行后出现OOM。解决办法是预分配显存池，或者定期重启服务。

第二是动态batch的处理：分离量化的加速比随batch size变化，小batch时访存瓶颈更明显，加速比可能更高；大batch时算力瓶颈显现，加速比可能下降。你需要根据实际流量模式来调优。

第三是版本管理：量化模型和原始模型的输出可能有细微差异，如果你的服务有下游依赖，要确保下游能容忍这些差异。最好在灰度环境先跑一段时间，确认没问题再全量。

5. 踩坑实录：那些文档里不会写的教训

5.1 阈值设错导致精度雪崩的排查过程

有一次我在一个多语言模型上做分离量化，校准集用的是英文样本，结果部署后发现中文生成质量明显下降。排查了一圈，最后定位到阈值问题：英文和中文的权重分布有差异，用英文校准集定出的阈值，对中文部分的关键权重保护不足。

这个坑的教训是：校准集必须覆盖你的目标语言和任务类型。如果模型是多语言的，校准集也要多语言混合。后来我改成按语言分层采样，每个语言都取一定比例的样本，问题就解决了。

排查这类问题的思路是：先确认精度下降是全局的还是局部的。如果是局部任务下降，大概率是校准集覆盖不足；如果是全局下降，可能是阈值整体偏紧或者量化实现有bug。定位到具体层之后，可以单独看那层的权重分布，对比校准集和实际数据的差异。

5.2 低比特kernel未生效的隐蔽表现

另一个常见的坑是：你以为自己在跑低比特kernel，实际上框架悄悄回退到了FP16路径。表现是精度正常但速度没提升，或者提升远低于预期。

怎么确认kernel是否生效？最直接的方法是看profiler里的kernel名称。如果看到的是低比特矩阵乘的kernel名，说明生效了；如果看到的是FP16的kernel名，说明回退了。回退的原因可能是显卡架构不支持、驱动版本太老、或者引擎编译时没打开对应开关。

我遇到过一次，原因是显卡驱动版本低于框架要求的最低版本，框架自动回退了。升级驱动后问题解决。所以部署前一定要核对框架的版本要求，别在这上面浪费时间。

5.3 离群权重索引的存储开销被低估

前面提到过索引存储的问题，这里展开说。离群权重的索引如果直接用整数数组存，开销可能比你想象的大。假设离群比例是2%，一个70B模型有1400亿个权重，2%就是28亿个索引。每个索引用32位存，就是11GB多的额外开销。这还没算对齐和padding的浪费。

实际实现中，索引通常用位图压缩。比如用一个bit表示某个权重是否离群，这样索引开销就降到原来的1/32。但位图的问题是随机访问效率低，需要配合额外的数据结构来加速查找。NVIDIA的方案在这方面做了工程优化，具体细节没有完全公开，但从实测的压缩比来看，索引开销被控制得不错。

如果你自己实现分离量化，索引存储是必须认真对待的一环。我的建议是先用简单的整数索引跑通流程，确认精度没问题后，再优化索引存储。不要一上来就追求极致压缩，容易在调试阶段把自己绕进去。

5.4 batch size与加速比的非线性关系

前面提过batch size会影响加速比，这里给一个具体的观察。在小batch（比如1到4）下，推理是访存瓶颈，权重量化带来的访存减少能直接转化为延迟下降，加速比可能达到2倍以上。但随着batch增大，计算逐渐变成瓶颈，低比特矩阵乘的算力优势开始显现，但激活值和中间结果的开销占比上升，加速比反而可能回落到1.5倍左右。

这个非线性关系意味着：你不能用一个固定的加速比来估算所有场景。如果你的服务是低并发高延迟敏感型，分离量化的收益会更大；如果是高并发吞吐型，收益会小一些。做容量规划时，一定要按实际batch分布来测。

6. 这套方案适合谁：场景匹配与替代方案对比

6.1 显存受限场景下的优先选择

分离量化最直接的价值场景是显存受限。比如你只有一张24GB显存的显卡，想跑一个原本需要40GB的模型，常规量化到INT4可能刚好放下但精度损失明显，分离量化则能在同样显存下提供更好的精度。或者你想在边缘设备上部署模型，显存只有几GB，分离量化的极端压缩能力就派上用场了。

另一个场景是模型并行推理。当你把模型切分到多张卡上时，每张卡的显存压力都很大，分离量化能降低单卡显存需求，让你用更少的卡跑同样的模型，或者用同样的卡跑更大的模型。

6.2 与GPTQ、AWQ等方案的横向对比

市面上主流的量化方案还有GPTQ和AWQ，它们和分离量化各有侧重。GPTQ是基于二阶信息的逐层量化，精度保持得不错，但压缩率通常到4-bit就差不多了，再低精度掉得厉害。AWQ是激活感知的权重量化，它根据激活值分布来调整量化策略，在4-bit下表现很好，但同样难以压到更低。

分离量化的优势在于它能压到2-bit甚至1-bit主体，这是GPTQ和AWQ做不到的。代价是实现复杂度更高，需要额外的校准和索引管理。所以选择逻辑是：如果你只需要4-bit，GPTQ或AWQ更成熟、更省事；如果你需要极低比特，分离量化是目前少有的可行方案。

6.3 什么情况下不建议上分离量化

如果你的显存足够跑INT8或INT4，那就别折腾分离量化。INT8几乎无损，INT4在大多数任务上也够用，实现简单、生态成熟。分离量化的收益只在极低比特区间才明显，4-bit以上用它属于杀鸡用牛刀。

另外，如果你的任务对精度极其敏感，比如医疗诊断、金融风控，那任何低于8-bit的量化都要慎重。分离量化虽然比朴素低比特好，但和FP16仍有差距，这种场景下精度损失是不可接受的。

还有就是团队技术储备不足的情况。分离量化涉及校准、阈值调优、索引管理、kernel验证等多个环节，每个环节都有坑。如果团队没有做过量化部署，建议先从INT8或INT4入手，积累经验后再考虑更激进的方案。

7. 我个人的实操体会与后续优化方向

折腾分离量化这段时间，最大的体会是：量化不是单纯的"压缩"问题，而是"信息分配"问题。哪些信息必须保留、哪些可以丢弃、保留的部分用什么精度存，这些决策比量化算法本身更重要。分离量化的聪明之处就在于它把这个问题显式化了，让你可以针对性地做决策。

另一个体会是，实测永远比理论重要。理论上的加速比和精度损失，在实际系统中会被各种因素扭曲——访存模式、kernel调度、显存分配、batch分布，每一个都能让结果偏离预期。所以别太相信论文里的数字，自己搭个测试环境跑一遍，比什么都靠谱。

后续如果要继续优化，我会关注两个方向。一是自适应阈值：现在的阈值是全局统一的，但不同层的权重分布差异很大，如果能按层自适应地定阈值，精度和压缩比应该还能再优化。二是索引压缩的进一步优化：目前的位图方案还有提升空间，如果能做到接近信息论下界的压缩率，额外开销还能再降。

最后分享一个小技巧：做量化实验时，一定要保留原始模型和量化模型的输出日志，逐条对比。有时候整体指标看起来没问题，但个别样本的输出质量差异很大，这些异常样本往往能帮你定位到量化过程中的隐藏问题。只看聚合指标，容易漏掉这些细节。