昇腾 910B 上 KIVI 2-bit 量化 KV Cache 跑起来了，但长上下文输出开始“胡说”：Key 和 Value

在 910B 上用 KIVI（Tuning-Free Asymmetric 2bit Quantization for KV Cache）做长上下文推理的显存压缩，量化后的显存占用确实降下来了，短序列上的输出也正常。但上下文一过 8K，模型开始出现重复生成和逻辑断裂，人工评测的连贯性明显下降。排查了一圈，问题不在校准数据，也不在昇腾算子实现，而在 KIVI 的核心假设被“平均化”使用了：Key Cache 和 Value Cache 的量化敏感度完全不同，但在实际部署中很容易被同一套 per-tensor 或 per-channel 策略一把梭。

一、 KIVI 的非对称设计：Key 按 channel 量化，Value 按 token 量化

KIVI 的出发点很明确：在自回归解码中，Key 的某些通道会持续出现大幅值的离群点，而 Value 的分布则随 token 变化更剧烈。因此 KIVI 对 Key Cache 采用 per-channel 量化（沿通道维度分组，每组独立 scale/zero-point），对 Value Cache 采用 per-token 量化（沿 token 维度分组）。这个非对称设计是 KIVI 能在 2-bit 下保持精度的关键，也是它区别于“统一对称量化”的根本之处。如果部署时为了省事，把 Key 和 Value 塞进同一个量化组、共用一组量化参数，就等于放弃了 KIVI 的核心收益，长上下文下的误差会随 token 累积放大。

二、 昇腾上的落地：组大小和残留窗口是精度阀门

KIVI 在昇腾 910B 上的适配（如 KVmix 等工程实现）通常还需要两个关键参数配合：组大小（group size） 和近期 token 的全精度保留窗口（residual window） 。组大小决定了 per-channel / per-token 量化的粒度，组越小精度越高、但元数据开销越大；残留窗口则让最近 N 个 token 的 Key/Value 保持全精度，避免刚生成的上下文被立即量化带来的“近因效应”损失。在 910B 上，组大小和残留窗口没有 CUDA 生态那样成熟的“默认推荐值”，需要按模型的注意力结构和实际上下文长度做消融。我们的经验是：先固定残留窗口（比如 128 token），再逐步缩小 group size，观察长上下文评测指标，直到精度收益饱和，而不是一上来就把 group size 压到最小。

三、 一个容易被忽略的约束：Decode 阶段是访存密集型，量化收益要看带宽而不是算力

KV Cache 在 Decode 阶段的核心瓶颈是访存带宽，而不是矩阵乘算力。量化 KV Cache 降低的是每次解码需要从显存读取的数据量，收益应该体现在 Decode 的吞吐或延迟上。如果量化后只盯着 Prefill 的算力指标看，可能会得出“量化没什么用”的错误结论。正确的观测口径是：在长上下文、小 batch 的 Decode 场景下对比 TPOT（每 token 输出时间）或吞吐，这里才是 KIVI 的收益兑现的地方。

四、 版本与集成的现实约束

昇腾上的 KV Cache 量化生态仍在快速演进，不同工程项目的适配方式差异很大。有的通过 vLLM-ascend 的 monkeypatch 在运行时注册 scheme，有的依赖 Ascend C 自定义算子做量化/反量化融合。这意味着版本矩阵比 CUDA 生态更脆弱：vLLM-ascend 的版本、CANN 版本、以及量化项目的适配版本必须严格对齐，否则可能表现为精度异常而非直接报错。稳妥的起点是在官方镜像内先跑通 baseline，再逐项引入量化，每次只改一个变量（组大小、残留窗口、位宽），用长上下文评测集做回归。

五、 总结

KIVI 在昇腾 910B 上的精度问题，根因往往不是“2-bit 太低”，而是非对称量化策略没有被正确落地。排查顺序：确认 Key 走 per-channel、Value 走 per-token → 调 group size 和残留窗口并在长上下文评测集上做消融 → 用 Decode 阶段的 TPOT/吞吐而不是 Prefill 算力来衡量收益 → 严格对齐 vLLM-ascend / CANN / 量化项目的版本矩阵。KV Cache 量化的收益和风险都集中在长上下文，短序列上的“看起来正常”说明不了问题。