先把结论放在前面KV Cache 已经是大模型推理绕不开的成本中心。我见过不少服务并发一上来显存先爆掉爆掉的地方不是模型权重而是缓存区。TurboQuant 这个项目我按自己 2025 年 4 月这一轮迭代的代号记录一下思路很直接在不明显掉精度的前提下把 KV Cache 的显存占用砍下去同时把内存带宽压力降下来最终反映到吞吐和首 token 延迟的改善上。这个方向做的人不少但大多数方案停留在能用级别离好用还有距离。这篇文章我打算从原理、设计、工程实现、实测数据、踩坑记录五个部分展开重点聊聊 KV Cache 量化的关键取舍和实际操作中遇到的坑。适合正在做推理优化、长文本服务或者想搞清楚 KV Cache 底层逻辑的同学参考。1. KV Cache 的显存膨胀与带宽瓶颈先算账再动手1.1 一张公式看清缓存开销做推理优化的同学手上基本都有这么一张公式KV Cache 显存 2K 和 V 各一份 × 层数 × KV 头数 × 每个头的维度 × 序列长度 × batch 大小 × 每个元素的字节数以常见开源 8B 量级模型为例假设 32 层、8 个 KV 头、每个头 128 维batch 为 32序列长度 8192使用 bf16 存储。单个 token 在这套配置下占用的显存是2 × 32 × 8 × 128 65536 个元素 × 2 字节 128 KBbatch 32 × 序列 8192 262144 个 token乘下来就是约 32 GB。模型权重本身可能才 16 GBbf16缓存直接是权重的两倍。而且这个量级是随序列长度和 batch 数线性增长的你不可能无限制加长上下文也不可能无限制提升并发。所以 KV Cache 量化不是锦上添花是服务能不能撑住并发和长上下文的硬性需求。1.2 生成阶段真正的瓶颈是内存带宽很多人以为推理慢是因为算力不够实际 prefilling 阶段确实吃算力但 decode 阶段完全不是这个逻辑。decode 每生成一个 token都要扫描一遍完整的 KV Cache 去做注意力计算。这个过程中从 HBM 读数据的时间远大于计算时间属于典型的 memory-bound 场景。打个比方算力是厨房里的大厨KV Cache 是冰箱里的食材。大厨炒一道菜只需要一分钟但每次都得先去冰箱翻一遍所有食材。冰箱离灶台越远、食材越多翻找的时间就越长。decode 阶段就是这样计算单元大部分时间在等数据从内存里搬过来。KV Cache 量化把每元素字节数从 2 字节压到 1 字节甚至 0.5 字节意味着搬运的数据量直接减半甚至减到四分之一。这也是为什么量化对 decode 的 token 生成速度有明显帮助——你减少的恰恰是瓶颈项的开销。1.3 TurboQuant 的定位不做全能选手市面上 KV Cache 量化的方案不少有做均匀量化的有做 log-scale 的有混合精度的还有把量化参数训练进模型的。TurboQuant 的定位很务实不追求理论最优追求工程上可落地、服务部署后效果可预期。它的核心诉求有三条精度损失控制在可接受范围不出现明显的生成质量劣化存储和带宽同时降下来而不只是显存数字变好看实现复杂度可控能在现有推理框架里改造成本不要太高这就决定了它不会选择特别激进的方案也不会引入训练阶段的耦合。整条路线围绕在线量化 融合反量化展开让它在不改变模型权重的前提下仅对推理期的缓存区做手脚部署成本低很多。2. TurboQuant 的核心设计per-head 与 per-token 两级量化2.1 全局量化为什么不行离群值把精度打穿我最开始做实验时偷了个懒直接把整个 KV Cache 张量做全局 min/max 量化结果精度掉得一塌糊涂。原因不复杂KV Cache 里存在明显的离群值。某些维度上数值分布特别宽另一些维度上数值都挤在一个很小的范围内。全局统一用一个 scale 来量化时scale 会被离群值拉大导致大部分正常数值被压缩到很粗糙的精度区间信息丢失严重。这就好比你给全小区的人统一买鞋码按最高的那个人买其他人穿起来都晃荡。正确的做法是分区域量化。把 KV Cache 按一定粒度分组每组独立计算 scale 和 zero point。粒度越小精度保留越好但 scale 本身的存储和计算开销越大。TurboQuant 的选择是用 per-head 加 per-token 的组合把两种粒度的优势结合在一起。2.2 两级 scale 的设计逻辑与分组策略per-head 的含义是同一个注意力头内的所有元素共用一个 scale。它的物理意义来自 attention 的计算结构——QK^T 是在每个头内部独立做的头与头之间的数值分布互不影响所以每个头独立量化不会破坏注意力计算的结构。per-token 的含义是同一个 token 的 KV 值共用一个 scale。这个设计针对的是序列内 token 之间的分布差异。长文本里不同位置的 token 经过多层变换后数值大小可能差出一个量级如果在整个序列上统一量化短小的 token 信息会被淹没。具体分组策略上K 和 V 的处理还有些不同K 的量化per-head 为主K 的数值参与 QK^T 点积scale 可以直接融合进 Q V 的量化per-token per-head 兼顾V 的数值与注意力权重相乘 scale 融合到 attention output 上分组大小方面TurboQuant 默认按 128 个元素一组计算 scale和 GPTQ 常见的 group size 保持一致。这样在精度和元数据开销之间取了一个平衡点。比如上面的 8B 模型例子一个 KV head 维度是 128恰好一组不会出现跨组边界问题。2.3 两种反量化路径显式重建与 scale 融合量化之后的 KV Cache 在参与计算前必须恢复成高精度最常见的做法是显式反量化读低精度数据乘上 scale 再加 zero point得到近似浮点数再走标准 attention 计算。这种方式实现简单调试直观但有一个致命缺点——它绕了一圈最后还是把高精度的临时张量建出来了。内存带宽省下来了可是计算路径里多了一步张量重建如果实现不够精细收益会被明显稀释。TurboQuant 的处理方式是把 scale 融合进计算过程。以 K 为例看它的思路原始计算score Q K^T K 量化存储K_dequant ≈ K_raw * scale_k 等价变形score ≈ Q (K_raw * scale_k)^T (Q * scale_k) K_raw^T这个变形看着简单但它把逐元素的乘 scale 操作从遍历整个 K 张量变成了只操作 Q 张量并且可以直接在 QK^T 的 GEMM 里融合。同样的道理V 的 scale 可以在 attention 输出和 V 相乘的时候融合。最终代码里呈现出来的形态是在注意力算子的 epilogue 阶段用 scale 修正结果而不是先重建完整的高精度 KV 张量再算注意力。这一步对性能影响非常大。3. 工程落地的关键细节从 PyTorch 原型到推理内核3.1 前端验证用尽量少的代码复现精度大规模改造推理内核之前必须先在前端把方案验证一遍不然方向错了代价太大。TurboQuant 的前端原型直接基于 PyTorch 的 attention 算子改做最小化验证。基本流程是这样import torch import torch.nn.functional as F def quantize_per_head(x, n_bits8): # x: [batch, heads, seq_len, head_dim] shape x.shape x_flat x.view(shape[0] * shape[1], -1) min_vals x_flat.min(dim-1, keepdimTrue).values max_vals x_flat.max(dim-1, keepdimTrue).values scale (max_vals - min_vals) / (2 ** n_bits - 1) scale torch.clamp(scale, min1e-12) zero_point -min_vals / scale x_q torch.round(x_flat / scale zero_point).clamp(0, 2 ** n_bits - 1) return x_q.view(shape).to(torch.uint8), scale.view(shape[0], shape[1], -1), zero_point.view(shape[0], shape[1], -1) def dequantize_per_head(x_q, scale, zero_point): return (x_q.float() - zero_point) * scale前端验证时重点看的是三件事量化后的困惑度变化、长文本生成质量是否劣化、scale 计算本身占的比例有多大。第一版跑下来如果困惑度就崩了别急着调内核先回头检查分组粒度和离群值处理。我当时踩的坑是一开始对 K 和 V 用了完全相同的量化配置结果 V 的精度损失明显大于 K。原因是 V 的数值分布更集中离群值影响更突出。后来把 V 的量化从 per-channel 改成 per-token per-head 两级粒度后问题才缓解。前端原型的好处就是这类试错成本很低。3.2 把 scale 算进 attention融合算子设计前端验证通过后真正的硬骨头在内核融合。TurboQuant 的推理内核基于 FlashAttention 的思路做改造核心目标是避免任何形式的中间高精度张量重建。具体实现上需要改三个位置第一K/V 的写入阶段。当 KV Cache 写入缓存时不能直接存原始 bf16 数据而是要做一次在线量化。这个量化的计算量不可忽视如果为它单独启动一个 kernel性能会很难看。正确的做法是把量化过程融合到上一层的算子或者 KV Cache 写入的 kernel 里让数据从寄存器阶段就直接转成低精度写回显存。第二QK^T 阶段。传统 FlashAttention 从 HBM 读取 K参与计算。TurboQuant 读入的是量化后的 K但通过 scale 提前修正 Q不需要把 K 反量化出来。// 伪代码示意融合 scale 的 QK^T // q 已经是乘过 scale_k 的结果 float score 0.0f; for (int j 0; j head_dim; j) { uint8_t k_quant k_cache[offset j]; score q[j] * dequant(k_quant, scale_k); }注意这里的 dequant 是标量级别的操作的是单个 cache block不会产生临时张量。scale_k 是从 KV block 的元数据里读出来的。第三attention 输出和 V 相乘后的 scale 修正。这一层相对简单因为输出已经汇聚了注意力权重最后统一乘一次 scale_v 即可。融合算子改造完成后显存占用下降是立竿见影的但性能是否提升还要看 batch 和序列长度的具体情况这个等第四节展开。3.3 与 PagedAttention 的协调block 粒度的元数据管理KV Cache 在现代推理框架里基本都走分页管理PagedAttention 这套思路用 block table 管理系统里的物理块。TurboQuant 一开始没考虑这个直接给整个 KV tensor 分配量化空间结果发现和分页机制打架。关键问题在于scale 和 zero point 是随数据走的。同一个物理 block 可能在不同请求之间复用也可能被多个序列共享比如前缀复用场景那么量化元数据必须和 block 本身绑定存储而不是和张量位置绑定。TurboQuant 的处理方式是给每个 KV block 增加一小块元数据区域| 原始 block 数据低精度 | scale | zero_point |用于 attention 计算时先读取 block table 拿到物理地址再从这个地址读出量化数据的同时拿到对应的 scale。因为每 block 的 scale 是固定大小的元数据访问可以做到 O(1) 寻址不会影响原有分页机制的查找效率。这个设计还有个额外的好处当 block 被复用时scale 元数据跟着 block 走不需要额外同步逻辑天然适配 prefix caching。4. 实测数据精度、延迟与吞吐的完整账本4.1 评测方案不能只看困惑度很多 KV Cache 量化的文章只报困惑度但困惑度低不等于生成质量行。长文本里注意力分布对精度非常敏感某些位置出现微小误差可能被后续 token 放大。TurboQuant 的评测方案分三层第一层语言建模困惑度作为通用精度基线第二层长文本任务比如摘要、多轮对话、文档问答直接看生成内容的语义连贯性第三层服务指标包括 TTFT首 token 延迟、TPOT每 token 延迟、吞吐量实际测试下来W8A8 方案权重 8 位、KV Cache 8 位在困惑度上和 bf16 基线几乎无差异差异值通常在 0.02 以内。W4A8 方案KV Cache 4 位困惑度上升大概 0.1 出头如果不做长文本任务体感差异不大。但注意这只是困惑度数字。到了长文本摘要任务上W4 方案在 16K 以上长度的输入里偶尔会出现注意焦点漂移的问题。这也验证了一个经验长上下文场景里KV Cache 的精度敏感度比短文本高得多。4.2 W8A8 与 W4A8 方案的取舍表整理了一张对比表格方便对照指标bf16 基线W8A88 位W4A84 位KV Cache 显存占用33.5 GB16.8 GB8.4 GB困惑度变化00.01 ~ 0.020.08 ~ 0.15长文本质量劣化无基本无16K 以上轻微劣化实现复杂度无低中需要额外 kernel 改造无1-2 处3-4 处适用场景要求绝对精度的场景高并发服务超长上下文、大并发W8A8 基本是无痛方案显存砍一半带宽开销砍一半精度几乎无损改动量也小。W4A8 的收益更大但代价是复杂度上来了不是所有框架改造起来都顺手。TurboQuant 的默认配置是 KV Cache 用 W8A8 打底提供 W4A8 作为可选项。我自己的经验是如果没有特殊需求先上 W8A8它带来的收益已经足够解决大部分显存瓶颈问题。W4 更像是给极端场景准备的备选方案。4.3 阈值效应序列越长收益越明显这里有一个反直觉的发现量化 KV Cache 在短序列场景下可能看不出性能收益甚至略微变慢。原因在于量化本身有计算开销scale 计算、元数据读取、反量化修正都是额外成本。当序列很短、KV Cache 很小时省下的带宽不多但额外开销是实打实的收益容易被抵消。但一旦序列长度跨过某个阈值收益曲线会变得非常陡峭。测试下来8B 模型的这个阈值大约在 3K 到 4K 之间。也就是说序列 1K 以内量化和不量化差别不大序列 2K-4KKB 缓存省出的带宽开始超过量化开销序列 8K 以上量化版本的 decode 速度明显优于 bf16 版本序列 32K 以上量化版本的吞吐可能是 bf16 版本的两倍以上所以量化 KV Cache 有明确的适用场景如果你的服务主要是短问题、短回答收益有限。但如果是长文档阅读、代码仓库理解、长时间多轮对话这类场景这个方案是必选项而不是可选项。5. 踩坑记录KV Cache 量化最容易翻车的五个地方5.1 第 8 位的漂移量化边界上的数值稳定问题量化边界上的数值漂移是最隐蔽的问题。我一直到 GPTQ 的量化和 KV Cache 量化做对照时才发现它的后果。原因在于量化公式里的 round 操作。round-to-nearest 在理论上是最优的但当数值恰好落在两个量化档位的边界上时由于浮点误差round 可能偏向任意一边。单次偏差非常微弱但在 KV Cache 这种需要跨 32 层累加衰减的场景里边界漂移会被逐层传递。解决方式并不复杂反量化时不要使用 round 后的整数直接乘 scale而是采用带 zero point 修正的完整反量化公式尽量消除量化零点附近的系统偏置。这看起来是个小改动但对长文本生成的稳定性提升是实打实的。另一个隐藏问题是数据里的 NaN 或 Inf。推理时一旦某层产生 NaN量化器会直接把 scale 算成 NaN整个后续计算全部崩掉。KV Cache 量化器里必须对非有限值做防御不能只写正常情况下的量化逻辑就想当然。5.2 batch 变化带来的 scale 抖动我在做并发测试时发现一个诡异现象batch 从 1 升到 8生成质量明显下降降到 1 又恢复正常。排查了半天发现是 scale 计算的问题。原因是 KV Cache 量化时 scale 是动态计算的batch 越大缓存张量里出现的离群值概率越高某个异常 token 可能会把局部 scale 拉大导致同一头的其他 token 被过度压缩。这个概率问题在小 batch 时基本碰不到但其实风险一直存在。解决办法是对离群值做截断处理。计算 scale 时不直接采用 min/max 的绝对极值而是采用百分位数。比如取 99.99 百分位的值作为 max 上限个别极端离群值允许出现饱和截断。这个操作会引入极小误差但能显著提高量化后生成的稳定性尤其是动态 batch 场景下。5.3 GQA 下 KV 头索引错位GQAGrouped Query Attention结构下KV 头的数量远小于 Q 头。比如 Q 有 32 个头KV 可能只有 8 个一个 KV 头被 4 个 Q 头共享。做 per-head 量化时scale 数组按 KV 头数量存储即可但 kernel 里做索引时极容易下意识按 Q 头数量去算 offset。这个问题一旦出现不会报错也不会崩溃只会导致量化 scale 错配结果就是精度混乱、输出质量劣化而且这个问题在短序列测试时可能完全看不出来长序列才暴露。我是怎么排查的先在前端验证数据里把量化前后 K 张量的 shape 打出来对照然后检查 scale 数组的 shape 和索引映射关系。一旦确认是 GQA 索引问题修复其实很简单关键是舍得分心去查索引这个意识要到位。5.4 显存省了却更慢的反模式这是最容易被忽视的性能陷阱量化后显存确实省了但速度反而更慢。我见过几个团队在分享时也提到过同样的问题。根因不外乎三种scale 计算没有融合进写 cache 的 kernel每次额外启动一个 kernel启动开销吃掉了省下的带宽反量化是在计算前统一做一遍生成了临时高精度张量内存带宽的实际开销没有下降缓存块的读取路径变长每次读取要额外取 scale 元数据缓存命中率下降TurboQuant 第一版就是第二种情况的活例子——K 反量化后临时张量照建显存占用确实降了但速度瓶颈没缓解。后来改成 scale 融合进 Q、V 的乘加运算里问题才解决。判断自己的实现是否踩了这个坑有个简单方法对比量化前后kernel 的执行时间变化。如果 decode 的单 token 耗时反而上升了 10% 以上基本可以确定反量化路径没有做干净。5.5 前缀复用与投机采样被忽视的兼容性代价最后这个坑在常规测试中根本不会暴露但上线后就会出事。很多服务做了前缀复用多个请求共享相同的前缀 KV Cache。TurboQuant 在 block 元数据里存了 scale本身支持复用。但问题出在 scale 和 block 内数据的对应关系上如果某个 block 被量化后又被另一个请求以不同精度复用比如先 8 位量化后 4 位量化元数据就乱了。投机采样场景也有类似问题。投机模型和验证模型如果走不同的 KV Cache 精度切换时 scale 元数据需要同步匹配否则投机验证的分数会失真。实际处理时我给 KV Cache 的 block 元数据加了一个 量化配置 ID 字段任何读操作的请求必须确认配置 ID 一致才能复用。这算是一个防御性设计不复杂但能挡住大多数上线后才暴露的隐性 bug。回到项目本身量化 KV Cache 这件事做到底本质上是一个系统工程问题。它不是一个 kernel 改完就完事的独立功能而是和显存管理、调度策略、并发形态都耦合在一起。TurboQuant 这个版本沉淀下来的经验里最有价值的部分恰恰不是什么精妙算法而是一套哪些环节必须融合、哪些场景收益最大、哪些坑坚决不能踩的判断框架。如果你的服务已经有长上下文或者高并发的压力我的建议是先从 W8A8 入手用最小的改动成本去验证收益不要一上来就追求 4 位量化的极致压缩率。毕竟部署一个稳定可维护的推理服务比在benchmark上压榨最后几个百分点的显存更重要。