OpenVINO™ 2026.2 新功能：Intel GPU 上 LLM 推理的 INT4 KV Cache 压缩

作者Mingyu Kim、Byungil Min翻译武卓在长上下文场景下运行大语言模型是一项非常消耗内存的工作。即使模型权重已经被压缩到 INT4KV Cache 仍然会随着每一个新生成的 token以及每一次输入到模型中的 prompt 不断增长。OpenVINO™ 2026.2 为 GPU 插件引入了 INT4 KV Cache 压缩。与 INT8 KV Cache 相比它可以将相关内存开销大约再减少一半与 FP16 相比则可以减少约三分之二。本文将介绍 INT4 KV Cache 压缩是什么、如何开启以及在实际使用中可以期待怎样的效果。什么是 KV Cache为什么需要压缩每个 Transformer 模型在生成过程中都会维护一个 Key-Value Cache也就是 KV Cache。对于每一层 attention模型会把之前已经处理过的所有 token 对应的 key 和 value 保存下来这样在下一步生成时就不需要重复计算。这是自回归推理能够高效运行的关键机制但它也带来了额外的内存成本。KV Cache 的大小主要与以下因素有关上下文长度也就是 prompt 加上已经生成的 token 数量模型层数和 attention head 数量KV Cache 中张量的存储精度。以 Llama-3-8B 为例当上下文长度达到 17k token并且 KV Cache 使用 FP16 精度时仅 KV Cache 本身就会消耗超过 2GB 的设备内存。对于显存有限的独立 GPU或者使用系统 DDR 共享内存带宽的集成 GPU 来说这会直接限制实际可用的上下文长度。将 KV Cache 从 FP16 压缩到 INT8可以大约将内存占用减半。进一步压缩到 INT4则可以把内存占用降低到 FP16 基线的大约三分之一。OpenVINO 此前已经默认支持 INT8 KV Cache而在 2026.2 版本中INT4 KV Cache 也正式可用。默认行为OpenVINO™ GPU 插件默认会启用 INT8 KV Cache 压缩。也就是说如果你已经在 GPU 上使用 OpenVINO™ 进行 LLM 推理并且没有显式修改相关配置那么你的 KV Cache 很可能已经是 INT8 精度。INT4 KV Cache 需要手动开启。INT4 KV Cache 压缩意味着什么开启 INT4 KV Cache 后key 和 value 在写入内存之前会从 FP16 量化为 4-bit 整数。在 attention 计算过程中它们会被即时反量化。在内部实现中i4 和 u4 会被等价处理。GPU 插件会在编译阶段将 i4 归一化为 u4。类似地u8 会被归一化为 i8。因此在设置属性时你可以使用这两种写法中的任意一种实际行为是相同的。具体的量化方案取决于 attention 后端。Paged Attention 后端推荐使用在 Paged Attention 后端中key 使用 per-channel scale 进行量化也就是 BY_CHANNEL 模式group size 为 16value 使用 per-token scale 进行量化也就是 BY_TOKEN 模式。这种不对称设计是有意为之。对于 key 来说按通道量化通常可以更好地保持 attention 精度而对于 value 来说按 token 量化对于 decode 阶段的 kernel 更高效。SDPA 后端非 Paged Attention在 SDPA 后端中key 和 value 都使用 per-token scale 进行量化也就是 BY_TOKEN 模式。由于 SDPA 路径中的 key 不支持 per-channel 量化因此相比 Paged Attention 路径它更有可能带来一定的精度影响。如何开启 INT4 KV Cache下面是在 GenAI benchmark.py 工具中开启 INT4 KV Cache 的示例python tools/llm_bench/benchmark.py \-m /path/to/model \-d GPU \-lc {KV_CACHE_PRECISION: u4}如何切回更高精度如果你希望完全关闭 KV Cache 压缩例如为了获得最高精度或进行调试可以将 KV Cache 精度设置为 FP16python tools/llm_bench/benchmark.py \-m /path/to/model \-d GPU \-lc {KV_CACHE_PRECISION: f16}对内存占用的影响下面的数据使用 Llama-3-8B-Instruct 在 Intel® Arc™ B580 独立 GPU、Linux 系统上测得。不同模型权重精度下KV Cache 大小保持一致。注意实际效果可能会因系统配置、模型和使用方式不同而有所变化。8k-token prompt17k-token prompt可以看到在不同上下文长度下INT4 KV Cache 的节省比例基本一致相比 INT8 大约减少 44%相比 FP16 大约减少 68%。这里的节省比例并不是相对 INT8 精确减少 50%原因在于 group-wise 量化除了压缩后的数值本身还需要额外存储每个 group 对应的 scale 和 zero-point。它的实际意义是某些在 INT8 KV Cache 下会耗尽可用 DDR 或显存的上下文长度在 INT4 KV Cache 下可能就可以正常运行。对性能的影响在 IO 受限场景中内存节省也会转化为性能收益因为每生成一个 token 需要访问的数据量更少。以下结果使用 Llama-3.1-8B-Instruct在 Intel® Arc™ B390 集成 GPU 上测得系统 DDR 速率为 9600 MT/s。测试指标为每个输出 token 的 decode 延迟不包含 prefill 阶段。注意实际效果可能会因系统配置、模型和使用方式不同而有所变化。16k-token prompt34k-token prompt对精度的影响对 KV Cache 进行量化会在 attention 计算中引入更多量化误差。基于内部验证结果可以得到以下观察对于 INT4 权重模型例如使用 NNCF 4-bit 权重量化压缩后的模型INT4 KV Cache 压缩与 INT8 KV Cache 相比表现出相当的精度。原因是模型本身已经经过优化能够容忍一定程度的量化噪声而 KV Cache 引入的误差仍然处在可接受范围内。对于 INT8 权重或 FP16 权重模型INT4 KV Cache 可能会带来精度偏差具体程度取决于模型和任务。因此在生产环境中部署 INT4 KV Cache 之前建议先在目标任务上验证精度。一个简单的检查方式是选取具有代表性的 prompt 样本分别在 INT8 KV Cache 和 INT4 KV Cache 设置下运行模型并比较输出结果。已知限制不支持 cache rotation。将 KV Cache block eviction 与 RoPE 位置修正也就是 cache rotation 结合使用的 serving 配置与 INT4 KV Cache 不兼容。不过这不会影响典型的单会话推理或标准 prefix caching。仅支持 GPU 插件。INT4 KV Cache 压缩目前不适用于 CPU 插件。Key 的 by-channel 量化需要 Paged Attention 支持。能够带来更好精度的 key BY_CHANNEL 量化模式仅在使用 Paged Attention 后端时可用。当使用 SDPA 后端也就是非 Paged Attention 时key 会回退到 BY_TOKEN 量化这更可能引入精度偏差。因此使用 INT4 KV Cache 压缩时推荐优先采用 Paged Attention 推理流程。小结当你的应用受到内存限制同时又希望支持更长上下文时INT4 KV Cache 压缩会非常有价值。你可以通过设置 KV_CACHE_PRECISION: u4 来启用它并根据自己的实际 workload 验证性能和精度。为了获得更好的精度表现建议使用 Paged Attention 后端因为它支持 key 的 by-channel 量化。如果你使用的是 SDPA 后端需要注意 key 也会采用 per-token 量化因此更有可能带来精度影响。在正式部署之前请务必进行充分验证。