华为云开源 KVarN：vLLM 原生 KV 缓存量化后端

模型上新

华为云在 GitHub 开源 KVarN，作为 vLLM 的原生 KV 缓存量化后端，支持 int2/int4/int8/fp8 多种精度，配合 Ascend NPU 可将推理吞吐提升 40% 以上，内存占用降低 60%。

华为云开源 KVarN：vLLM 原生 KV 缓存量化后端

华为云今天在 GitHub 开源了 KVarN（KV Cache Quantization for vLLM on Ascend NPU），这是一个专为 vLLM 打造的 KV 缓存量化后端。项目刚上线就拿到 600+ Stars，主要原因是它解决了一个实打实的痛点：大模型推理时 KV 缓存吃掉一半以上显存，而现有的量化方案要么精度掉得厉害，要么只支持特定硬件。

KVarN 的特别之处在于它是 vLLM 的原生后端，不是外挂的补丁方案。支持 int2、int4、int8、fp8 四种量化精度，开发者可以根据场景在精度和性能之间自由权衡。在华为 Ascend 910B NPU 上，int4 量化能让推理吞吐提升 40% 以上，显存占用直接砍掉 60%。

KVarN 架构图展示量化流程和性能对比

为什么 KV 缓存量化这么重要

大模型推理分两个阶段：prefill（预填充，处理完整输入）和 decode（解码，逐 token 生成输出）。Decode 阶段每生成一个 token，都要把它的 Key 和 Value 向量存到缓存里，后续生成时再拿出来做 Attention 计算。问题在于，随着生成长度增加，KV 缓存会线性增长。

举个例子：Llama-3-70B 模型，处理 32K 上下文时，模型权重占 140GB，KV 缓存就要吃掉 80GB。如果跑长对话或者 RAG 任务，KV 缓存很容易成为瓶颈。要么显存不够用导致 OOM（Out of Memory），要么只能减小 batch size，吞吐直接腰斩。

现有的量化方案主要有两类：一类是 quanto、HQQ 这种通用后端，支持多种硬件但性能一般；另一类是 NVIDIA 的 FP8 KV Cache，性能很好但只能在 Hopper 架构（H100/H200）上跑。国产算力芯片要接入 vLLM 生态，要么自己从零写量化逻辑，要么用社区方案凑合。

KVarN 填补了这个空白。它作为 vLLM 的官方后端接口实现，开发者只需要在启动 vLLM 时加一个 --kv-cache-dtype 参数就能用上，不需要改模型代码或者重新编译。

技术细节：如何在不掉精度的前提下压缩

KV 缓存量化的核心挑战是：Attention 计算对数值精度非常敏感，量化不当会直接导致生成质量下降。KVarN 采用了几个关键设计来平衡精度和性能：

动态缩放因子（Per-Token Scaling）：不是给整个 KV 缓存用一个固定的量化范围，而是每个 token 的 K/V 向量单独计算缩放因子。这样可以适应不同 token 的数值分布，减少量化误差。

混合精度支持：允许 Key 和 Value 使用不同的量化精度。比如在某些任务中，Value 对精度更敏感，可以用 int8，而 Key 用 int4 就够了。这样既能省显存，又不会明显影响效果。

硬件原生算子：KVarN 的量化和反量化操作都是调用 Ascend NPU 的原生 CANN 算子，没有额外的 CPU-GPU 数据搬运开销。量化后的 KV 缓存直接存在 HBM 里，解码时再反量化参与 Attention 计算。

校准策略可选：支持两种校准方式——静态校准（用少量样本提前确定量化参数）和动态校准（运行时实时计算）。静态校准适合离线部署，动态校准更灵活但计算开销稍大。

从华为云披露的内部测试数据看，int4 量化在 GSM8K（数学推理）、HumanEval（代码生成）等 benchmark 上的精度损失在 1% 以内，基本可以忽略。而在长文本任务（如 32K 上下文的文档问答）中，显存占用能从 180GB 降到 72GB，直接决定了能不能在单卡上跑起来。

配合华为云的大模型推理栈

开源 KVarN 不是孤立事件。今年上半年，华为云存储创新 LAB 和北大、南大合作的三篇论文分别入选 USENIX ATC、ICML、ACL 三大顶会，主题都是大模型推理优化：

  • DEEPSERVE（ATC 2025）：Serverless 架构的大模型推理平台，原生适配 Ascend NPU，支持大规模并发和弹性扩缩容。已经在华为云的 MaaS 服务上稳定运行一年多。

  • EPIC（ICML 2025）：位置无关缓存（Position-Independent Caching）机制，突破传统前缀缓存的限制。以前只有完全相同的前缀才能复用 KV 缓存，现在可以复用任意位置的上下文片段，在 RAG 和 Few-Shot 场景下复用率能提升 3-5 倍。

  • RaaS（ACL 2025）：推理感知的 Attention 稀疏化算法。针对长推理任务（数学推理、代码生成）中 KV 缓存爆炸式增长的问题，通过识别"推理关键 token"来选择性保留 KV 缓存，将内存复杂度从 O(N) 降到 O(L)（L 是上下文长度，N 是生成长度），同时保持精度不变。

KVarN 是这套推理栈在工程落地层面的补充。EPIC 解决了缓存复用的问题，RaaS 解决了长推理的内存问题，KVarN 则把单次推理的显存占用压到最低。三者结合起来，理论上可以让同样的硬件支撑更高的并发和更长的上下文。

华为云 CEO 周跃峰在 6 月 5 日的媒体采访中提到，华为云不会跟其他厂商拼算力规模和 Tokens 消耗总量，核心目标是"发展第二个算力平面"——也就是基于国产化算力（Ascend NPU）构建完整的 AI 基础设施。开源 KVarN 是这个策略的一部分：把底层优化能力开放出来，让生态伙伴和开发者能在 Ascend 上跑出接近甚至超过 NVIDIA GPU 的性能。

对开发者意味着什么

降低部署门槛：以前在 Ascend NPU 上跑 vLLM，要么用默认的 fp16 KV 缓存（显存吃紧），要么自己写 CANN 算子做量化（门槛太高）。现在直接在 vLLM 启动参数里加一行 --kv-cache-dtype int4 就能开启量化，和 NVIDIA 的 FP8 KV Cache 一样简单。

更灵活的精度选择：不同任务对精度的要求不一样。聊天机器人、内容生成这种任务对精度容忍度高，可以用 int4 甚至 int2；代码补全、数学推理这种任务需要更高精度，可以选 int8 或 fp8。KVarN 支持运行时切换精度，不需要重新加载模型。

多硬件支持的可能性：虽然目前 KVarN 主要针对 Ascend NPU 优化，但它的架构设计是通用的。社区可以基于相同的接口为其他国产芯片（如海光 DCU、寒武纪 MLU）实现对应的量化后端。这对国产算力生态的互通性是个好消息。

性能数据参考：华为云在 README 里公开了不同量化精度下的性能数据。比如 Llama-3-70B 在 Ascend 910B 上，int4 量化后吞吐从 28 tokens/s 提升到 42 tokens/s，首 token 延迟从 180ms 降到 120ms。这些数据可以帮开发者快速评估量化带来的收益。

当然也有一些限制需要注意：

  • KVarN 目前只支持 decoder-only 架构（GPT、Llama、Qwen 这类），encoder-decoder 模型（T5、BART）暂时不支持。
  • 量化会引入轻微的精度损失，虽然在大多数任务上可以忽略，但在一些对数值精度极其敏感的任务（如科学计算）中需要谨慎评估。
  • 动态量化模式下，量化和反量化本身也有计算开销。在短文本、小 batch 的场景下，量化带来的收益可能被开销抵消。

开源背后的行业趋势

KVarN 的开源反映了几个行业趋势：

国产算力芯片在积极融入开源生态。以前国产芯片的策略是自建生态（比如昇腾的 MindSpore、寒武纪的 Cambricon PyTorch），但开发者习惯很难改变。现在的思路是直接适配主流框架和工具链（PyTorch、vLLM、DeepSpeed），降低开发者的迁移成本。华为云在 3 月的合作伙伴大会上提到，MaaS 服务已经接入超过 160 个业界主流模型，盘古大模型也在陆续开源。

推理优化从模型层下沉到系统层。早期的大模型优化主要集中在模型结构（MoE、稀疏 Attention）和训练效率（ZeRO、FSDP）上。现在随着模型趋于标准化（都是 Transformer），优化重点转向推理侧的系统工程——KV 缓存管理、调度策略、内存分配、算子融合等。这些优化往往需要深入到硬件层面，云厂商和芯片厂商有天然优势。

量化不再是"性能不够用时的妥协"，而是默认选项。NVIDIA 在 H100 上直接支持 FP8，新一代的 Blackwell 架构进一步加强了低精度计算能力。大模型推理的主流路径正在从"fp16 everywhere"转向"能量化就量化"。KVarN 的出现让 Ascend NPU 在这个趋势上没有掉队。

开源是技术竞争的新战场。华为云开源 KVarN 的时机很微妙——就在 NVIDIA 发布 Blackwell 架构、AMD 推出 MI300 系列的节骨眼上。通过开源争取开发者支持、建立技术影响力、倒逼竞品跟进，已经成为云厂商和芯片厂商的常规操作。

下一步可以关注什么

KVarN 目前还是早期版本（0.1.x），华为云在 GitHub 的 Roadmap 里列出了几个方向：

  • 支持更多模型架构（encoder-decoder、multi-modal）
  • 提供自动调优工具，根据硬件和任务自动选择最优量化策略
  • 和 FlashAttention、PagedAttention 等技术结合，进一步压缩内存占用
  • 探索更激进的量化方案（如 1-bit 量化、三值量化）

从社区反馈看，开发者最关心的是两个问题：一是能不能支持其他硬件（特别是 NVIDIA GPU 和 AMD GPU），二是能不能把量化逻辑抽象成统一的接口，让不同硬件的量化后端可以无缝切换。如果这两个问题能解决，KVarN 有机会成为 vLLM 生态里的标准量化方案。

华为云在 AI 基础设施上的投入是长期的。从去年开源盘古大模型，到今年三篇顶会论文 + KVarN 开源，再到下半年计划发布的 AgentArts 智能体平台和 DataArts 数据智能体，可以看出他们在构建一个从算力、框架、工具链到应用的完整栈。KVarN 只是其中一环，但对于需要在国产算力上跑大模型推理的团队来说，是个值得关注的工具。

如果你在用 vLLM 做推理服务，又遇到显存瓶颈，可以试试 KVarN。代码已经在 GitHub 上开源，配合 vLLM 0.4.0+ 版本即可使用。对于没有 Ascend NPU 的开发者，关注它的架构设计和量化策略也有参考价值——毕竟 KV 缓存优化是所有硬件都绕不开的问题。

参考来源