KV 压缩与量化¶
算法维度（横向）之三：保留所有 K/V 条目，但降低每个条目的位宽或秩，让 KVCache 在字节数上变小。
与 稀疏化 的差别：稀疏是"丢掉一些 K/V"，本章是"K/V 都还在，但每个变小了"。两者经常组合使用。
A. 压缩¶
1. 低秩分解 / SVD 类¶
策略：把 KVCache 张量沿 head 或 channel 维度做 SVD，只保留 top-\(r\) 个奇异值与对应向量。
- 离线 SVD：用校准集决定分解矩阵，推理时缓存的是低秩因子
- 在线 SVD：随生成动态调整，质量更稳但计算开销大
工程上更常用的是 MLA（Attention 变体 §2）——它把低秩思想直接做进了模型架构里训练，避免了"事后压缩"的精度损失。事后 SVD 压缩在公开工业系统里部署较少。
2. 学习型压缩 / 摘要式压缩¶
策略：用一个轻量"压缩头"把一段 KV 压成更短的 KV（信息聚合）。
代表方向：
- Compressed Context Memory 类工作——把超出窗口的历史 K/V 压成几个 summary token
- Recurrent KV——KV 不再是 token 级，而是"段级"摘要
适用：多轮对话、长 Agent 链路等"历史 token 多但单 token 重要性低"的场景。 代价：质量损失需要任务级评估，不是"通用免费午餐"。
3. CacheGen / Streaming 类¶
不是缩 KV 本身，而是在跨节点传输 KV 时做压缩+流式传输。 - 把 KV 量化 + 编码成 bitstream - 接收端边收边解码，与计算 overlap
代表论文：CacheGen (2024)。
B. 量化¶
量化是工业上最广泛部署的 KVCache 优化路径，原因：兼容性好、硬件友好、收益直接。
1. 数据类型谱¶
| 精度 | KV 体积（相对 BF16） | 工业部署成熟度 |
|---|---|---|
| FP16 / BF16 | 1.0× | 默认 |
| FP8（E4M3 / E5M2） | 0.5× | H100/H200 一线方案 |
| INT8 | 0.5× | 成熟，质量略劣于 FP8 |
| INT4 | 0.25× | 研究阶段，部分场景可用 |
| 1-bit / KIVI 极致量化 | < 0.1× | 论文阶段 |
2. 量化粒度¶
| 粒度 | 描述 | 精度/速度权衡 |
|---|---|---|
| Per-tensor | 整个张量一个 scale | 最快，最不准 |
| Per-channel | 每个 channel（head_dim 维度）一个 scale | 中等 |
| Per-token | 每个 token 一个 scale | 较准，scale 表大 |
| Per-group | 每 g 个连续元素一组 | 主流折中（如 g=64） |
paged attention 下，per-block 也是常见粒度——每个 KV block 共享一组 scale。
3. 静态 vs 动态、对称 vs 非对称¶
- 静态量化：scale 提前用校准集确定。简单、推理零额外开销，但 outlier 敏感。
- 动态量化：scale 在写入时基于当前张量统计计算。适应性好，但 prefill / decode 路径都要插入计算。
- 对称量化：零点固定为 0。硬件对乘加更友好。
- 非对称量化：保留 zero point，对正负不对称分布更准（Key 张量常见这种分布）。
经验：K 比 V 更难量化——K 的分布更不均匀（attention sink 等极端值），常见做法是 K 用更细粒度、V 用更粗粒度。
4. 代表方法¶
| 方法 | 核心 idea | 备注 |
|---|---|---|
| KIVI | K per-channel quant + V per-token quant，2-bit 也能保精度 | arXiv:2402.02750 |
| KVQuant | 4-bit per-channel + outlier 处理 + RoPE 对齐 | arXiv:2401.18079 |
| Atom | 推理全栈低比特（含 KV） | arXiv:2310.19102 |
| QServe | W4A8KV4 + Lookahead Search 等 | arXiv:2405.04532 |
| TurboQuant | 3.5-bit 近似无损，WHT 旋转 + QJL 1-bit 残差，零训练开销 | arXiv:2504.19874 |
| HACK | 同态 INT2 量化，KV 压缩后不还原直接在 attention 内计算 | arXiv:2502.03589 |
5. TurboQuant：极致低比特 + 零训练开销¶
TurboQuant 实现了在 LongBench / Needle-in-a-Haystack 上近无损的 ~3.5 bit KV 量化：
- 核心技术：随机旋转（WHT）+ 标量量化 + QJL 1-bit 残差纠偏
- 注意力度：H100 上 4-bit 注意力 logits 比 32-bit 快 8×
- 框架集成路线：
- SGLang PR #23135：3.88× 压缩，93–105% decode 吞吐（uniform mode 比 codebook mode 快 ~15%）
- vLLM PR #40396：v2 添加 FLUTE-style grouped Q heads + vectorized LUT，受 CUDA Graph grid size 约束
- TRT-LLM：使用 NVFP4 原生格式（非 TurboQuant），MLA FP4 模型配 BF16 fallback pool
来源：主站 reading TurboQuant 详解、框架集成路线图
6. HACK：同态 KV 压缩¶
HACK 的核心创新是压缩后的 KV 直接驻留在注意力计算路径上，不进行逐步解压：
- 同态量化：KV 保持 2-bit INT2 格式进入 attention kernel，避免 per-step dequantization
- JCT 降低：38.6–61.6% vs 基线（disaggregated serving 场景）
- Dequant 成本替换：CacheGen/KVQuant 的 17–38% JCT dequant 开销被 HACK 的 1.5–3.2% 近似开销替代
- 分区策略：Partition size Π=64 平衡精度与 JCT；求和消除 + V tail block FP16 buffer 关键优化
来源：主站 reading HACK 同态 KV 压缩
7. NVFP4 / FP4：Blackwell 时代的 4-bit 路线¶
NVFP4 KV Cache 的核心价值是让 4-bit 浮点进入硬件友好的生产路径：在 Blackwell 上实现 KV 内存减半，长上下文高并发场景 TTFT 最高改善约 3×，公开 benchmark 上精度损失小于 1%。但它不是"所有 workload 免费降到 4-bit"：
| 风险点 | 工程含义 |
|---|---|
| benchmark 分布有限 | LiveCodeBench、MMLU-PRO、MBPP、Ruler 64K 不等于生产 reasoning / agent trace |
| backend 兼容性 | SGLang 的 FP4/FP8 KV dtype 需要 attention backend 支持，否则会降级到慢路径 |
| scale buffer 开销 | FP4 通常仍需 block scale，实际容量收益不是严格 4× |
在 SGLang 实操中，BF16 → FP4 可支持约 3.56× 更长上下文或更多并发（含 scale buffer），DeepSeek-R1-0528 FP4 KV 在 gsm8k 上 0.9124 vs BF16 0.9157；Qwen3-235B-A22B FP4 KV 甚至略高于 FP8（0.9186 vs 0.9181）。这些数字说明 FP4 已具备评估价值，但仍需要逐模型、逐 workload 验证。
来源：主站 reading NVFP4 KV Cache，主站 field-note SGLang 部署方式、KV Cache 调参与最佳实践
8. TriAxialKV：Agent 负载的结构化低比特分配¶
Agent KV 不再是均质文本：system prompt、tool schema、CoT、tool call JSON、截图观测和 delimiter token 的敏感度不同。TriAxialKV 用模态、时间、语义三轴标签决定每类 token 使用 2-bit 还是 4-bit，65–75% token 被路由到 INT2，平均 bitwidth 约 2.6–2.7 bit，比 uniform INT4 低 35% 存储开销。
| 结果 | 数字 |
|---|---|
| KV 容量 | BF16 基线的 4.5× |
| 端到端吞吐 | B200 1.32×，H100 1.52× |
| 并发请求数 | H100 3.4×，B200 4.0× |
| 精度 | OSWorld 高于 BF16 0.6–1.8 个百分点；BFCL Memory 在 BF16 ±1.1% 内 |
关键启示是：aggressive quantization 未必比保守 uniform quantization 更危险，前提是比特预算按 Agent 结构分配。uniform FP4 / INT2 容易把 tool schema 这类高敏感 inst token 也压低，导致函数名、参数名错误。
来源：主站 reading TriAxialKV：为什么 Agent 推理需要多轴 KV Cache 量化
C. 系统层面的协同¶
量化 KV 与 paged 管理¶
- block_size 与量化 group_size 的对齐：例如 16 token/block × per-token quant，scale 表是 16 个 fp16 值，与 block metadata 一起存
- copy-on-write 时要不要重新量化？通常不要，直接拷贝量化后的字节
量化 KV 与 offload / 跨节点传输¶
- 在 PCIe / RDMA 上传输的就是量化后的字节，带宽收益正比于压缩比
- 接收端要么直接用量化 KV 算 attention（kernel 支持），要么 dequantize 回来（计算开销）
详见 维度交叉 §3.1。
量化 KV 与 prefix cache¶
哈希以量化后的字节为输入还是原始 token id 为输入？工业实践基本都是后者（token id）——量化是引擎内部细节，缓存语义应稳定于 token 级。但要注意：换一个量化方案后，老的物理 KV block 字节内容变了但 token id 哈希不变，导致命中后读到的是错的字节——这要求量化方案版本号纳入 cache key 或在切换时清空缓存。
D. 算法维度小结：三类操作的统一视角¶
把 Attention 变体、稀疏化 和本章合在一起看：
| 类别 | 操作 | 代表 |
|---|---|---|
| 改形状 | 改变 KV 张量的维度 | MQA/GQA/MLA、SWA |
| 减条目 | 在 token/head/layer 维度上去掉 K/V | StreamingLLM、H2O、SnapKV、YOCO |
| 减位宽/秩 | K/V 都在但每个变小 | KIVI、KVQuant、SVD |
它们共同效应是减少 KV 的"有效字节数"，但作用通道、精度风险、kernel 友好度各不相同。在生产部署里这三类经常叠加使用：GQA 模型 + FP8 KV + SnapKV 剪枝是当前一线推理引擎的常见组合。
关联章节¶
版本历史¶
| 版本 | 日期 | 说明 |
|---|---|---|
| v0.3 | 2026-06-02 | 新增 NVFP4/FP4 Blackwell 路线与 TriAxialKV agent 结构化 2/4-bit 量化 |
| v0.2 | 2026-05-14 | 新增 TurboQuant（3.5-bit 近无损、三框架集成路线）和 HACK（同态 INT2 量化、JCT 38.6–61.6% 降低）代表方法及技术细节 |