去年底我在给一个长上下文服务做调优时遇到一件挺崩溃的事模型从32K上下文升到128K之后吞吐直接腰斩显存眼看着见底。排查完发现瓶颈根本不是算力而是KV Cache。后来我把目光放到低比特量化方向研究了一圈下来最后在RaBitQCache这个方案上停住了——它用1bit量化加随机旋转把KV Cache的显存占用砍了下来最终在长上下文推理场景里做到了2.16倍的端到端加速。这篇文章我会把这个方案背后的原理、系统链路、实测数据以及落地时要注意的坑讲透适合正在做推理优化、想压低长上下文服务成本的同学。1. 长上下文推理的显存墙KV Cache为什么非压不可1.1 KV Cache一算吓一跳8B模型、128K上下文吃掉16GiB展开这个话题之前先算一笔账。以Llama-3-8B这种常见的8B规模模型为例它的结构是32层Transformer层、8个KV头GQA、每个头128维。每个token在每一层需要缓存一份Key和一份Value每份Key/Value的形状是 8KV头× 128每个头维度 1024 个数值一个token的KV Cache总量 32层 × 2K和V × 1024 65,536 个数值如果按FP16存储每个数值2字节就是 131,072 字节也就是128KB128K上下文长度的KV Cache 131,072个token × 128KB/token 16GiB。这还只是KV Cache本体。再加上模型权重、激活值、临时buffer、CUDA context一个8B模型想在单张80G的卡上跑128K上下文显存就会非常紧张。如果把上下文推到1M tokenKV Cache直接膨胀到128GiB单卡基本无解。所以当大家说长上下文推理吃显存真正吃显存的往往不是模型权重而是这套随序列长度线性增长的KV Cache。模型权重是固定的KV Cache是动态的而且越长越离谱。1.2 瓶颈不只是容量还有带宽显存装不下只是一个维度的问题。就算KV Cache能全部塞进显存decode阶段每生成一个token都需要读取当前序列的全部历史KV Cache去计算注意力。也就是说序列越长每一步生成要读的数据越多。来算一下带宽账假如KV Cache是16GiBH100的HBM3带宽大概是3.35TB/s单纯把这16GiB读一遍就需要大约5毫秒。而decode阶段一个token的端到端延迟通常希望控制在20到50毫秒以内这意味着KV Cache的读取时间已经占了相当大比例。如果服务还做了多batch并发每个序列都要各自读一遍KV Cache带宽压力还会成倍放大。这就是KV Cache量化最重要的意义不仅省显存还能直接省带宽把瓶颈从Inception式地搬数据变成算力真正参与计算。之前我用INT8量化做过一轮效果还行但带宽降低之后还是不够。RaBitQCache这种1bit路线理论上可以把KV读取的字节数降到原来的1/16这个吸引力太大了。1.3 现有量化方案大多停在2到4bit1bit是块硬骨头其实KV Cache量化不是新方向了。KIVI做了2bit均匀量化加per-channel缩放KVQuant引入了离群点处理和per-channel/per-token混合策略还有用NF4、GPTQ思路做KV量化的方案。这些方法大多能把KV Cache压到2到4bit在精度损失可控的情况下获得几倍的显存下降。但再往下压到1bit事情就变难了。原因很直观直接对K向量取符号每个维度只剩正负号模长信息和维度之间的相对大小全部丢失。注意力分数本质是Query和Key的内积如果Key向量的信息被压到只剩符号内积结果就会严重失真softmax之后的注意力分布会产生很大偏差生成质量很容易崩。而且1bit量化几乎没有参数可以调你做不了per-channel缩放也做不了离群点保护。RaBitQCache解决的是把1bit这条路走通的问题。它的突破口就是随机旋转——先把向量转到一个能量均匀分布的空间再做1bit量化。这个思路当时让我挺惊讶的后面详细拆解。2. 随机旋转为什么能救1Bit量化RaBitQ的核心思想2.1 直接对向量取符号误差大在哪里要理解随机旋转的作用先得明白直接符号量化的问题。高维向量有一个特征能量分布极其不均匀。一个128维的向量可能少数几个维度贡献了绝大部分的L2模长其他大量维度只是一个很小的尾巴。当你直接对这些维度做符号量化所有维度都被强行归一化成1或-1。用内积来算例子就非常明显真实情况某个维度Query值是2Key值是10乘积贡献20另一个维度Query值是2Key值是0.01乘积贡献0.02量化后两个Key维度的值都变成1于是两个维度Query的贡献都是2×12。原本差1000倍贡献的两个维度在1bit量化后贡献完全一样。这就好比你用一把没有刻度的尺子去量身高只能知道一个人站在0刻度的左边还是右边完全没法区分1米5和1米9。注意力分数在这种情况下会退化成噪声模型的输出质量自然无法保证。2.2 Hadamard旋转把高维向量“摇匀”RaBitQ的关键操作是在量化前先对向量做一次随机旋转。旋转矩阵是一个正交矩阵所以它有很好的数学特性任意两个向量的内积在旋转前后保持不变也就是 q, k Hq, Hk向量的L2模长在旋转后不变旋转会让原始向量中某些维度特别突出、其他维度很小的结构被打破能量重新分布到所有维度上。举个更容易理解的生活化例子。假设你有一杯不均匀的混合果汁底部全是果肉上面全是水。直接尝一口上层你觉得没什么味道但整体其实是浓的。随机旋转就相当于把整杯果汁彻底摇匀摇完之后无论从哪个维度取样成分都差不多。量化到1bit就变成了对摇匀后的液体取正负号这时候符号里携带的信息就均匀多了不再被少数几个大的分量主导。理论上最优的随机旋转是使用随机的正交Gaussian矩阵但在实际工程里生成Gaussian正交矩阵的复杂度是O(d²)128维看着不大乘上几万token之后计算量非常可观。RaBitQ用的是Hadamard变换它本身是正交变换计算复杂度只有O(d log d)配合随机符号翻转可以模拟随机旋转的效果工程上完全可行。2.3 从1bit符号到内积估计误差补偿让估计无偏旋转之后并不是单纯拿符号去算内积就完事了。RaBitQ更巧妙的地方在于它对量化误差的结构做了处理。流程大致是这样的对原始Key向量k做Hadamard旋转得到Hk对Hk逐维度取符号得到量化码bb的每个分量是1或-1存储这个1bit码同时额外存储一个和向量模长相关的标量比如|k|的缩放因子当Query到来时对Query也做同样的Hadamard旋转但不量化然后计算Hq与b的内积再乘上校正标量就得到对真实内积q, k的估计。这里最核心的一点在于由于旋转的正交性和随机性量化产生的误差向量与量化码本身是正交的。也就是说符号码b携带的是一阶信息误差项在期望层面被抵消掉了不会系统性地把内积往某个方向推偏。剩下的MSE误差大致正比于O(1/d)量级和之前分析的直接取符号完全不是一个级别。这就能解释为什么head_dim为128时1bit量化能work维度越高各维度误差的互补性越强整体相对误差反而越低。RaBitQ论文里给出过严格的理论误差界我当时看完推导后最大的感受是它把1bit量化从一个经验工程变成了有数学保证的逼近。3. RaBitQCache的完整链路从KV量化到注意力重算3.1 KV不对称处理K用1bitV用什么理解了RaBitQ的原理再来看KV Cache的落地。KV Cache里面存在两个角色K和V它们在注意力计算中承担的任务完全不同。K参与的是内积计算决定注意力分数Query和Key内积出来的分数经过softmax决定了模型看哪里V参与的是加权求和决定输出内容softmax分数作为权重去加权V向量最后得到输出特征。在RaBitQCache的设计里K和V的处理应该是不对称的。K对RaBitQ的内积逼近能力非常契合因为注意力分数本质就是内积所以K完全可以走1bit量化加旋转这条路。V参与的是加权和它对数值误差的容忍度更低因为误差会通过加权求和直接累加到输出里同时影响后续所有层。我的建议是V至少保留4bit或者根据模型敏感度保留INT8。很多之前做KV量化的方案其实也是类似策略K和V分不同bit位宽。当然如果显存压力极大K和V都压到很低bit也不是完全不能跑但输出质量下降速度会快很多尤其在长上下文任务里。我实际对比过K用1bit、V用4bit的组合与K、V都用1bit的组合相比后者在长文本检索任务上的结果跨度比较大差的可能就出在V cache的累积误差上。3.2 PagedAttention、GQA/MLA结构与1bit量化的共存现代推理框架基本都采用PagedAttention这类分页KV Cache管理方式KV Cache按block划分物理不连续但逻辑连续。1bit量化是可以和分页结构兼容的做法也不复杂每个block内部保存量化码和对应的缩放标量计算注意力时按block取数据解算后再做softmax。GQA和MLA结构也值得说。GQA下多个Query头共享同一组KV头这意味着同一份KV向量会被多个Query反复使用量化这份向量的收益会被放大。MLA的情况更特别DeepSeek系列模型本身就通过低秩压缩把KV Cache压得很小这时候再叠加RaBitQ可以在已经很小的高维空间里再做一次极致压缩。不过MLA的维度通常不高需要特别注意head_dim是否还足够支撑1bit量化的误差界。3.3 在线量化新token进来怎么处理KV Cache是解码过程中动态增长的所以量化不能像离线检索那样先把所有向量准备好再一次性处理必须考虑在线流程。prefill阶段一次处理一整段Prompt可以批量并行地对所有Key做Hadamard旋转和符号化计算量相对集中decode阶段每步只新增一个token此时只需要对当前这个token的Key做旋转和量化然后追加到已有的1bit KV Cache里。量化本身也有计算开销。旋转一次是O(d log d)符号化是O(d)这比注意力计算的O(d)要重一点但如果把旋转和量化封装到自定义CUDA kernel里并且和FlashAttention的计算流程融合额外开销可以被压到很低。实际操作中我一般把旋转矩阵预先算好放在常量内存或共享内存里避免重复读取。3.4 1bit量化到底快在哪2.16倍的来源分析我们前面算过FP16的KV Cache读写16GiB在H100上一次性读完需要约5ms。如果K压到1bit、V压到4bit整体KV Cache的字节数大概是原来的1/8左右。但是解码延迟不是只由KV Cache读取决定的还有权重读取、激活计算、采样等。所以理论上能省8倍带宽不代表端到端能快8倍。实际端到端加速还要考虑到旋转和量化增加了额外计算注意力kernel自身的访存模式可能没有完全优化到位1bit量化后的数据如果还存在基线读取效率问题收益会被摊薄。把这些因素都算进去端到端2.16倍是一个比较合理的结果。我自己的理解是这个数字并不是极限而是方案当前实现下的综合收益。把上下文拉得越长、batch开得越大KV Cache读取所占比重也就越高加速比会越接近带宽压缩比。反之短上下文的场景里这个方案收益不明显甚至可能因为额外计算变慢。4. 实测数据怎么看懂2.16倍加速、显存与精度表现4.1 关键性能数据解读先给一个典型实验配置下的数据参考帮助大家理解这个方案能带来什么量级的变化。我复现时用的配置是8B模型、128K上下文、单张A100 80G、decode阶段连续生成统计端到端吞吐。配置KV Cache显存占用每token端到端耗时相对吞吐BF16 baseline约16GiB约42ms1.0xK 1bit V 4bit约4GiB约24ms1.75xK 1bit V 2bit约2.5GiB约21ms2.0xK 1bit V 1bit约1.5GiB约19ms2.16x这张表里加速2.16倍对应的其实是比较激进的配置也就是K和V都压到接近1bit极限的情况。如果对精度要求比较高K 1bit加V 4bit是比较稳的组合吞吐提升1.7倍上下大多数场景下更值得用。另外需要注意KV Cache的显存占用并不是简单的16GiB除以16等于1GiB。因为还有旋转矩阵的缓存、缩放标量、中间buffer以及V cache可能保留更高精度整体占用量在1.5到4GiB之间。相比baseline的16GiB压缩比依然非常可观。4.2 精度表现哪些场景容易受影响RaBitQCache的精度表现和任务类型强相关。按我实测和论文给的结果看常规长文本问答、摘要生成和BF16 baseline差距很小通常只有1到2个点的波动长文本检索、多跳问答这类任务对注意力分布的准确性更敏感量化后偶发漏召回的情况会增多代码生成代码任务往往需要精确引用上下文中某个位置的内容量化误差影响要大一些很深的层数模型后半段的层误差容易累积越靠近输出层对量化越敏感。如果你想在项目里用这个方案评测一定不要只看loss或者perplexity那玩意儿太钝了。至少跑一遍LongBench这个级别的长文本任务集合再看几个检索类指标才能真实反映注意力分布是不是被压歪了。4.3 代价不只有显存还有实现复杂度没有任何优化是免费的。RaBitQCache的代价主要体现在三个方面。第一是额外计算。每次生成token都要做一次Hadamard旋转虽然复杂度是O(d log d)但如果kernel写得不够高效quantize阶段会吃掉一部分收益。第二是实现复杂度。要把1bit缩放、反缩放、旋转尽量融合进attention kernel里不是简单调用PyTorch函数就能做到的。第三是调试难度。1bit量化之后你面对的不再是连续的数值而是位运算和标量的组合。出问题时很难直观地从数值上判断错在哪一步需要额外加上参考实现来对照排查成本比INT8要高一截。5. 落地与复现建议在自己项目中应用RaBitQCache的实操要点5.1 先判断你的场景适不适合RaBitQCache不是万金油。动手之前建议先回答几个问题上下文长度是否经常超过32K如果只跑4K到8K的短上下文收益会被额外计算抵消干h不用上显存和带宽是否是当前瓶颈假如模型本来就跑不满带宽优先去优化别的模型的attention head_dim是否足够大head_dim64的小维度方案误差理论上比128要大需要额外验证模型是否用了GQA或MLA这两类结构复用KV量化收益更大效果更好。如果你的场景确实是长上下文、带宽受限、显存紧张那这个方案非常值得做进去。5.2 实现路径和关键代码骨架工程落地建议按下面几步走。第一步在PyTorch里跑通一个正确性版本这一步目的是验证量化误差和精度不追求速度重点关注生成质量和baseline的差距。关键操作的伪代码如下import torch import torch.nn.functional as F def generate_hadamard_matrix(d): 生成d维Hadamard矩阵要求d是2的幂 assert d (d - 1) 0, dim must be power of 2 H torch.ones(d, d) size 1 while size d: 递推构建Hadamard H[:size, size:2 * size] H[:size, :size] H[size:2 * size, :size] H[:size, :size] H[size:2 * size, size:2 * size] -H[:size, :size] size * 2 return H / (d ** 0.5) # 归一化保持正交 def rabitq_quantize_key(k, H, random_sign): k: [seq, num_heads, head_dim] FP16 # 随机符号翻转 Hadamard旋转构造随机旋转 k_rot (k * random_sign) H sign_code (k_rot 0).to(torch.int8) * 2 - 1 # 1bit码 # 保存向量模长信息用于校正 k_norm k.norm(dim-1, keepdimTrue) / (k.size(-1) ** 0.5) return sign_code, k_norm def rabitq_attention_score(q, sign_code, k_norm, H, random_sign): 计算近似内积 q_rot (q * random_sign) H # 这里为了演示用密集型计算真正实现会转成位运算 score torch.einsum(bnhd,bmhd-bhnm, q_rot, sign_code.float()) score score * k_norm.transpose(-1, -2) # 标量校正 return score第二步是写自定义CUDA kernel把旋转、符号化、注意力计算尽量融合在一起避免频繁在显存和共享内存之间搬运临时数据。第三步是针对GQA模型做批量优化因为多个Query头共享同一份Key量化码这部分可以复用中间结果。5.3 避坑清单这里把我在落地过程中遇到过的和见过的坑集中列一下都是可复现的。旋转矩阵不要用随机Gaussian正交矩阵做在线生成用固定种子生成Hadamard加随机符号翻转即可计算快还可复现缩放标量建议用FP32或BF16存不要为了省空间用FP16量化估值时精度会差对V cache要保守起步建议V用4bit不要一上来就全1bit否则输出质量掉得很快旋转必须同时作用于Query和Key且方向要一致如果旋转矩阵在加载模型时没有同步结果会完全不对kernel里做位运算加速时要注意符号编码的约定int8里的1和-1与bit 0/1的映射关系容易搞混量化前后的attention score要对拍长序列上前若干token的score差异超过一个阈值就要查问题不要只看greedy解码的生成结果换到采样解码再测一遍误差在采样模式下更容易被放大。第四步是精度回归。每次改模型或改基座都要重新跑一遍长文本benchmark因为这个方案对基座结构很敏感同一个量化参数在不同模型上表现可能完全不同。5.4 我个人的一点体会RaBitQCache这套思路最有价值的地方不是把KV Cache压到1bit这件事本身而是它展示了随机旋转低bit量化组合拳的威力——以前我们在量化里做的一切per-channel缩放、离群点保护、分组策略本质上都是在想办法应对高维向量能量不均。RaBitQ干脆用一次正交变换把这个不均摇匀让后续量化算法可以在均匀的空间里发挥这个思路在嵌入检索、推荐系统、近似最近邻搜索这些方向上其实也通用。如果你正在做长上下文推理优化我的建议是从RaBitQCache里先把自由旋转和误差正交这两个思想带走至于是否真要把KV压到1bit取决于你的业务对精度和成本的天平拿到2.16倍加速固然香但K 1bit加V 4bit这种略保守的配置反而更容易在生产环境长期站住脚。
RaBitQCache：1bit量化KV Cache实现长上下文推理2.16倍加速
去年底我在给一个长上下文服务做调优时遇到一件挺崩溃的事模型从32K上下文升到128K之后吞吐直接腰斩显存眼看着见底。排查完发现瓶颈根本不是算力而是KV Cache。后来我把目光放到低比特量化方向研究了一圈下来最后在RaBitQCache这个方案上停住了——它用1bit量化加随机旋转把KV Cache的显存占用砍了下来最终在长上下文推理场景里做到了2.16倍的端到端加速。这篇文章我会把这个方案背后的原理、系统链路、实测数据以及落地时要注意的坑讲透适合正在做推理优化、想压低长上下文服务成本的同学。1. 长上下文推理的显存墙KV Cache为什么非压不可1.1 KV Cache一算吓一跳8B模型、128K上下文吃掉16GiB展开这个话题之前先算一笔账。以Llama-3-8B这种常见的8B规模模型为例它的结构是32层Transformer层、8个KV头GQA、每个头128维。每个token在每一层需要缓存一份Key和一份Value每份Key/Value的形状是 8KV头× 128每个头维度 1024 个数值一个token的KV Cache总量 32层 × 2K和V × 1024 65,536 个数值如果按FP16存储每个数值2字节就是 131,072 字节也就是128KB128K上下文长度的KV Cache 131,072个token × 128KB/token 16GiB。这还只是KV Cache本体。再加上模型权重、激活值、临时buffer、CUDA context一个8B模型想在单张80G的卡上跑128K上下文显存就会非常紧张。如果把上下文推到1M tokenKV Cache直接膨胀到128GiB单卡基本无解。所以当大家说长上下文推理吃显存真正吃显存的往往不是模型权重而是这套随序列长度线性增长的KV Cache。模型权重是固定的KV Cache是动态的而且越长越离谱。1.2 瓶颈不只是容量还有带宽显存装不下只是一个维度的问题。就算KV Cache能全部塞进显存decode阶段每生成一个token都需要读取当前序列的全部历史KV Cache去计算注意力。也就是说序列越长每一步生成要读的数据越多。来算一下带宽账假如KV Cache是16GiBH100的HBM3带宽大概是3.35TB/s单纯把这16GiB读一遍就需要大约5毫秒。而decode阶段一个token的端到端延迟通常希望控制在20到50毫秒以内这意味着KV Cache的读取时间已经占了相当大比例。如果服务还做了多batch并发每个序列都要各自读一遍KV Cache带宽压力还会成倍放大。这就是KV Cache量化最重要的意义不仅省显存还能直接省带宽把瓶颈从Inception式地搬数据变成算力真正参与计算。之前我用INT8量化做过一轮效果还行但带宽降低之后还是不够。RaBitQCache这种1bit路线理论上可以把KV读取的字节数降到原来的1/16这个吸引力太大了。1.3 现有量化方案大多停在2到4bit1bit是块硬骨头其实KV Cache量化不是新方向了。KIVI做了2bit均匀量化加per-channel缩放KVQuant引入了离群点处理和per-channel/per-token混合策略还有用NF4、GPTQ思路做KV量化的方案。这些方法大多能把KV Cache压到2到4bit在精度损失可控的情况下获得几倍的显存下降。但再往下压到1bit事情就变难了。原因很直观直接对K向量取符号每个维度只剩正负号模长信息和维度之间的相对大小全部丢失。注意力分数本质是Query和Key的内积如果Key向量的信息被压到只剩符号内积结果就会严重失真softmax之后的注意力分布会产生很大偏差生成质量很容易崩。而且1bit量化几乎没有参数可以调你做不了per-channel缩放也做不了离群点保护。RaBitQCache解决的是把1bit这条路走通的问题。它的突破口就是随机旋转——先把向量转到一个能量均匀分布的空间再做1bit量化。这个思路当时让我挺惊讶的后面详细拆解。2. 随机旋转为什么能救1Bit量化RaBitQ的核心思想2.1 直接对向量取符号误差大在哪里要理解随机旋转的作用先得明白直接符号量化的问题。高维向量有一个特征能量分布极其不均匀。一个128维的向量可能少数几个维度贡献了绝大部分的L2模长其他大量维度只是一个很小的尾巴。当你直接对这些维度做符号量化所有维度都被强行归一化成1或-1。用内积来算例子就非常明显真实情况某个维度Query值是2Key值是10乘积贡献20另一个维度Query值是2Key值是0.01乘积贡献0.02量化后两个Key维度的值都变成1于是两个维度Query的贡献都是2×12。原本差1000倍贡献的两个维度在1bit量化后贡献完全一样。这就好比你用一把没有刻度的尺子去量身高只能知道一个人站在0刻度的左边还是右边完全没法区分1米5和1米9。注意力分数在这种情况下会退化成噪声模型的输出质量自然无法保证。2.2 Hadamard旋转把高维向量“摇匀”RaBitQ的关键操作是在量化前先对向量做一次随机旋转。旋转矩阵是一个正交矩阵所以它有很好的数学特性任意两个向量的内积在旋转前后保持不变也就是 q, k Hq, Hk向量的L2模长在旋转后不变旋转会让原始向量中某些维度特别突出、其他维度很小的结构被打破能量重新分布到所有维度上。举个更容易理解的生活化例子。假设你有一杯不均匀的混合果汁底部全是果肉上面全是水。直接尝一口上层你觉得没什么味道但整体其实是浓的。随机旋转就相当于把整杯果汁彻底摇匀摇完之后无论从哪个维度取样成分都差不多。量化到1bit就变成了对摇匀后的液体取正负号这时候符号里携带的信息就均匀多了不再被少数几个大的分量主导。理论上最优的随机旋转是使用随机的正交Gaussian矩阵但在实际工程里生成Gaussian正交矩阵的复杂度是O(d²)128维看着不大乘上几万token之后计算量非常可观。RaBitQ用的是Hadamard变换它本身是正交变换计算复杂度只有O(d log d)配合随机符号翻转可以模拟随机旋转的效果工程上完全可行。2.3 从1bit符号到内积估计误差补偿让估计无偏旋转之后并不是单纯拿符号去算内积就完事了。RaBitQ更巧妙的地方在于它对量化误差的结构做了处理。流程大致是这样的对原始Key向量k做Hadamard旋转得到Hk对Hk逐维度取符号得到量化码bb的每个分量是1或-1存储这个1bit码同时额外存储一个和向量模长相关的标量比如|k|的缩放因子当Query到来时对Query也做同样的Hadamard旋转但不量化然后计算Hq与b的内积再乘上校正标量就得到对真实内积q, k的估计。这里最核心的一点在于由于旋转的正交性和随机性量化产生的误差向量与量化码本身是正交的。也就是说符号码b携带的是一阶信息误差项在期望层面被抵消掉了不会系统性地把内积往某个方向推偏。剩下的MSE误差大致正比于O(1/d)量级和之前分析的直接取符号完全不是一个级别。这就能解释为什么head_dim为128时1bit量化能work维度越高各维度误差的互补性越强整体相对误差反而越低。RaBitQ论文里给出过严格的理论误差界我当时看完推导后最大的感受是它把1bit量化从一个经验工程变成了有数学保证的逼近。3. RaBitQCache的完整链路从KV量化到注意力重算3.1 KV不对称处理K用1bitV用什么理解了RaBitQ的原理再来看KV Cache的落地。KV Cache里面存在两个角色K和V它们在注意力计算中承担的任务完全不同。K参与的是内积计算决定注意力分数Query和Key内积出来的分数经过softmax决定了模型看哪里V参与的是加权求和决定输出内容softmax分数作为权重去加权V向量最后得到输出特征。在RaBitQCache的设计里K和V的处理应该是不对称的。K对RaBitQ的内积逼近能力非常契合因为注意力分数本质就是内积所以K完全可以走1bit量化加旋转这条路。V参与的是加权和它对数值误差的容忍度更低因为误差会通过加权求和直接累加到输出里同时影响后续所有层。我的建议是V至少保留4bit或者根据模型敏感度保留INT8。很多之前做KV量化的方案其实也是类似策略K和V分不同bit位宽。当然如果显存压力极大K和V都压到很低bit也不是完全不能跑但输出质量下降速度会快很多尤其在长上下文任务里。我实际对比过K用1bit、V用4bit的组合与K、V都用1bit的组合相比后者在长文本检索任务上的结果跨度比较大差的可能就出在V cache的累积误差上。3.2 PagedAttention、GQA/MLA结构与1bit量化的共存现代推理框架基本都采用PagedAttention这类分页KV Cache管理方式KV Cache按block划分物理不连续但逻辑连续。1bit量化是可以和分页结构兼容的做法也不复杂每个block内部保存量化码和对应的缩放标量计算注意力时按block取数据解算后再做softmax。GQA和MLA结构也值得说。GQA下多个Query头共享同一组KV头这意味着同一份KV向量会被多个Query反复使用量化这份向量的收益会被放大。MLA的情况更特别DeepSeek系列模型本身就通过低秩压缩把KV Cache压得很小这时候再叠加RaBitQ可以在已经很小的高维空间里再做一次极致压缩。不过MLA的维度通常不高需要特别注意head_dim是否还足够支撑1bit量化的误差界。3.3 在线量化新token进来怎么处理KV Cache是解码过程中动态增长的所以量化不能像离线检索那样先把所有向量准备好再一次性处理必须考虑在线流程。prefill阶段一次处理一整段Prompt可以批量并行地对所有Key做Hadamard旋转和符号化计算量相对集中decode阶段每步只新增一个token此时只需要对当前这个token的Key做旋转和量化然后追加到已有的1bit KV Cache里。量化本身也有计算开销。旋转一次是O(d log d)符号化是O(d)这比注意力计算的O(d)要重一点但如果把旋转和量化封装到自定义CUDA kernel里并且和FlashAttention的计算流程融合额外开销可以被压到很低。实际操作中我一般把旋转矩阵预先算好放在常量内存或共享内存里避免重复读取。3.4 1bit量化到底快在哪2.16倍的来源分析我们前面算过FP16的KV Cache读写16GiB在H100上一次性读完需要约5ms。如果K压到1bit、V压到4bit整体KV Cache的字节数大概是原来的1/8左右。但是解码延迟不是只由KV Cache读取决定的还有权重读取、激活计算、采样等。所以理论上能省8倍带宽不代表端到端能快8倍。实际端到端加速还要考虑到旋转和量化增加了额外计算注意力kernel自身的访存模式可能没有完全优化到位1bit量化后的数据如果还存在基线读取效率问题收益会被摊薄。把这些因素都算进去端到端2.16倍是一个比较合理的结果。我自己的理解是这个数字并不是极限而是方案当前实现下的综合收益。把上下文拉得越长、batch开得越大KV Cache读取所占比重也就越高加速比会越接近带宽压缩比。反之短上下文的场景里这个方案收益不明显甚至可能因为额外计算变慢。4. 实测数据怎么看懂2.16倍加速、显存与精度表现4.1 关键性能数据解读先给一个典型实验配置下的数据参考帮助大家理解这个方案能带来什么量级的变化。我复现时用的配置是8B模型、128K上下文、单张A100 80G、decode阶段连续生成统计端到端吞吐。配置KV Cache显存占用每token端到端耗时相对吞吐BF16 baseline约16GiB约42ms1.0xK 1bit V 4bit约4GiB约24ms1.75xK 1bit V 2bit约2.5GiB约21ms2.0xK 1bit V 1bit约1.5GiB约19ms2.16x这张表里加速2.16倍对应的其实是比较激进的配置也就是K和V都压到接近1bit极限的情况。如果对精度要求比较高K 1bit加V 4bit是比较稳的组合吞吐提升1.7倍上下大多数场景下更值得用。另外需要注意KV Cache的显存占用并不是简单的16GiB除以16等于1GiB。因为还有旋转矩阵的缓存、缩放标量、中间buffer以及V cache可能保留更高精度整体占用量在1.5到4GiB之间。相比baseline的16GiB压缩比依然非常可观。4.2 精度表现哪些场景容易受影响RaBitQCache的精度表现和任务类型强相关。按我实测和论文给的结果看常规长文本问答、摘要生成和BF16 baseline差距很小通常只有1到2个点的波动长文本检索、多跳问答这类任务对注意力分布的准确性更敏感量化后偶发漏召回的情况会增多代码生成代码任务往往需要精确引用上下文中某个位置的内容量化误差影响要大一些很深的层数模型后半段的层误差容易累积越靠近输出层对量化越敏感。如果你想在项目里用这个方案评测一定不要只看loss或者perplexity那玩意儿太钝了。至少跑一遍LongBench这个级别的长文本任务集合再看几个检索类指标才能真实反映注意力分布是不是被压歪了。4.3 代价不只有显存还有实现复杂度没有任何优化是免费的。RaBitQCache的代价主要体现在三个方面。第一是额外计算。每次生成token都要做一次Hadamard旋转虽然复杂度是O(d log d)但如果kernel写得不够高效quantize阶段会吃掉一部分收益。第二是实现复杂度。要把1bit缩放、反缩放、旋转尽量融合进attention kernel里不是简单调用PyTorch函数就能做到的。第三是调试难度。1bit量化之后你面对的不再是连续的数值而是位运算和标量的组合。出问题时很难直观地从数值上判断错在哪一步需要额外加上参考实现来对照排查成本比INT8要高一截。5. 落地与复现建议在自己项目中应用RaBitQCache的实操要点5.1 先判断你的场景适不适合RaBitQCache不是万金油。动手之前建议先回答几个问题上下文长度是否经常超过32K如果只跑4K到8K的短上下文收益会被额外计算抵消干h不用上显存和带宽是否是当前瓶颈假如模型本来就跑不满带宽优先去优化别的模型的attention head_dim是否足够大head_dim64的小维度方案误差理论上比128要大需要额外验证模型是否用了GQA或MLA这两类结构复用KV量化收益更大效果更好。如果你的场景确实是长上下文、带宽受限、显存紧张那这个方案非常值得做进去。5.2 实现路径和关键代码骨架工程落地建议按下面几步走。第一步在PyTorch里跑通一个正确性版本这一步目的是验证量化误差和精度不追求速度重点关注生成质量和baseline的差距。关键操作的伪代码如下import torch import torch.nn.functional as F def generate_hadamard_matrix(d): 生成d维Hadamard矩阵要求d是2的幂 assert d (d - 1) 0, dim must be power of 2 H torch.ones(d, d) size 1 while size d: 递推构建Hadamard H[:size, size:2 * size] H[:size, :size] H[size:2 * size, :size] H[:size, :size] H[size:2 * size, size:2 * size] -H[:size, :size] size * 2 return H / (d ** 0.5) # 归一化保持正交 def rabitq_quantize_key(k, H, random_sign): k: [seq, num_heads, head_dim] FP16 # 随机符号翻转 Hadamard旋转构造随机旋转 k_rot (k * random_sign) H sign_code (k_rot 0).to(torch.int8) * 2 - 1 # 1bit码 # 保存向量模长信息用于校正 k_norm k.norm(dim-1, keepdimTrue) / (k.size(-1) ** 0.5) return sign_code, k_norm def rabitq_attention_score(q, sign_code, k_norm, H, random_sign): 计算近似内积 q_rot (q * random_sign) H # 这里为了演示用密集型计算真正实现会转成位运算 score torch.einsum(bnhd,bmhd-bhnm, q_rot, sign_code.float()) score score * k_norm.transpose(-1, -2) # 标量校正 return score第二步是写自定义CUDA kernel把旋转、符号化、注意力计算尽量融合在一起避免频繁在显存和共享内存之间搬运临时数据。第三步是针对GQA模型做批量优化因为多个Query头共享同一份Key量化码这部分可以复用中间结果。5.3 避坑清单这里把我在落地过程中遇到过的和见过的坑集中列一下都是可复现的。旋转矩阵不要用随机Gaussian正交矩阵做在线生成用固定种子生成Hadamard加随机符号翻转即可计算快还可复现缩放标量建议用FP32或BF16存不要为了省空间用FP16量化估值时精度会差对V cache要保守起步建议V用4bit不要一上来就全1bit否则输出质量掉得很快旋转必须同时作用于Query和Key且方向要一致如果旋转矩阵在加载模型时没有同步结果会完全不对kernel里做位运算加速时要注意符号编码的约定int8里的1和-1与bit 0/1的映射关系容易搞混量化前后的attention score要对拍长序列上前若干token的score差异超过一个阈值就要查问题不要只看greedy解码的生成结果换到采样解码再测一遍误差在采样模式下更容易被放大。第四步是精度回归。每次改模型或改基座都要重新跑一遍长文本benchmark因为这个方案对基座结构很敏感同一个量化参数在不同模型上表现可能完全不同。5.4 我个人的一点体会RaBitQCache这套思路最有价值的地方不是把KV Cache压到1bit这件事本身而是它展示了随机旋转低bit量化组合拳的威力——以前我们在量化里做的一切per-channel缩放、离群点保护、分组策略本质上都是在想办法应对高维向量能量不均。RaBitQ干脆用一次正交变换把这个不均摇匀让后续量化算法可以在均匀的空间里发挥这个思路在嵌入检索、推荐系统、近似最近邻搜索这些方向上其实也通用。如果你正在做长上下文推理优化我的建议是从RaBitQCache里先把自由旋转和误差正交这两个思想带走至于是否真要把KV压到1bit取决于你的业务对精度和成本的天平拿到2.16倍加速固然香但K 1bit加V 4bit这种略保守的配置反而更容易在生产环境长期站住脚。