新的 KV 量化方案来了 😍 Welcome OSCAR kv quant 由 Together AI 开源

# Together AI 开源 OSCAR：一种用于长上下文 LLM 服务的注意力感知 2 位 KV 缓存量化系统 来源：https://www.marktechpost.com/2026/05/25/together-ai-open-sources-oscar-an-attention-aware-2-bit-kv-cache-quantization-system-for-long-context-llm-serving/ 长上下文推理使 KV 缓存成为服务 LLM 的主要成本之一。在自回归解码过程中，缓存随着上下文长度、批处理大小和模型深度而增长。在高批量大小和长上下文（跨越数十个并发请求的 100K token）下，KV 缓存消耗了 GPU 内存的很大一部分。压缩它是增加批处理大小和减少内存流量的直接方法。 显而易见的方法是量化。但将 KV 缓存推向 INT2（2 位）精度在很大程度上是不切实际的。先前的方法要么精度崩溃，要么需要与分页 KV 缓存系统不兼容的自定义服务布局。**Together AI 的 OSCAR（离线谱协方差感知旋转）解决了这两个问题。** ## **为什么 INT2 KV 缓存量化很难** KV 激活包含通道级异常值。一小部分通道包含极大的值。大多数通道表现良好。当你应用只有四个可表示级别的 INT2 量化，并且这些异常值主导了缩放因子时，量化器会将其大部分范围浪费在罕见尖峰上。正常值被压缩到仅一两个有效级别。这严重降低了注意力质量。 基于旋转的量化通过应用固定的正交变换（通常是**Hadamard 变换**）来重新分布所有通道上的异常值能量，从而解决这个问题。这种方法在 INT4 下效果相当好。在 INT2 下，一个更深层次的问题仍然存在：旋转是*数据无关*的。它可以平滑激活范围，但它不知道注意力机制实际读取哪些方向。均匀分布量化误差与将其推入低重要性方向是不同的。在 INT2 下，只有四个级别，这个区别决定了模型是否还能工作。 https://arxiv.org/pdf/2605.17757v1 ## **OSCAR 有何不同做法** OSCAR 的关键观察是，在量化之前应用的旋转应该源自注意力统计本身——而不是 KV 激活的原始分布。 **对于键**，相关下游误差不是 K 的欧几里得重建误差。它是注意力 logits 中的误差。研究团队展示了这个误差为：`‖QK⊤ − QK̂⊤‖2F = tr((K − K̂)Q⊤Q(K − K̂)⊤)`。权重矩阵是*查询协方差* Q⊤Q，而不是 K⊤K。查询能量大的方向会放大 logits 中的量化误差。OSCAR 从校准集中估计经验查询协方差 `CQ = (1/N) Σ qn⊤qn`，对其进行特征分解，并使用特征向量 UQ 作为键旋转基。 **对于值**，相关误差在注意力输出 SV 中。这取决于注意力分数矩阵 S 如何对每个值行进行加权。研究团队定义了分数加权值协方差 `CS = (1/N) V⊤S⊤SV`。在通过 S 聚合后仍然很大的方向是量化误差传播的方向。OSCAR 使用 CS 的特征向量 US 作为值旋转基。 **最终的组合旋转是：** `RK = UQ · HHad · Pbr` `RV = US · HHad · Pbr` **这三个因子各自解决了每组低比特量化中的一个不同失败模式：** - **UQ / US** 将通道与注意力重要性方向对齐。这对角化了误差权重矩阵，使得最重要的方向可识别。 - **HHad**（Walsh-Hadamard 变换）然后精确地均衡通道重要性。论文中的引理 1 证明 `HHad⊤ Λ HHad` 的每个对角元素都等于 `tr(Λ)/d`——由 UQ 暴露的尖峰特征谱被压缩为所有通道上的均匀值。 - **Pbr**（置换位反转）重新排序通道，使得对于任何二的幂次量化组大小，每个组都能从重要性层次结构中的每个级别获得一个代表。 研究团队提供了定理 1，证明在冻结误差代理目标和对角残差假设下，UQ 和 US 是最优的。 ## **服务系统：混合精度缓存布局** OSCAR 作为 INT2 KV 缓存模式集成到 SGLang 的生产服务栈中，并与分页注意力完全兼容。 KV 缓存布局每个请求使用三个区域： - **Sink token**（前 S0 = 64 个 token）：以 BF16 存储。这些充当注意力 sink。 - **最近 token**（当前位置之前的最后 W = 256 个 token）：以 BF16 存储。 - **历史 token**（介于两者之间的所有 token）：在 OSCAR 旋转和裁剪后以 INT2 存储。 在 128K 上下文长度下，BF16 的 sink 和最近窗口仅占总 token 的 0.24%。消融实验（论文表 5）显示 (S=64, R=256) 是精度-效率的拐点：较小的窗口会明显损害精度；较大的窗口在更高的 BF16 内存成本下带来的额外收益可以忽略不计。 https://arxiv.org/pdf/2605.17757 写入和读取路径使用融合的 Triton 内核。在写入路径上，每个 token 被旋转、裁剪到校准衍生的百分位阈值（典型值：cK = 0.96, cV = 0.92），然后以默认组大小 GK = 每组 64 个通道使用每 token 非对称 INT2 进行量化。在读取路径上，INT2 内核解包字节、去量化、逆旋转，并将结果传递给注意力内核——所有操作都在一个融合通道中完成，无需额外的内存流量。值旋转 RV 被离线吸收到模型的投影权重中，从而消除了其在线计算成本。 ## **结果** 研究团队在四种模型配置上评估了 OSCAR：Qwen3-4B-Thinking-2507、Qwen3-8B、Qwen3-32B 和 GLM-4.7-FP8（358B 参数）。基准测试包括 AIME25、GPQA-Diamond、HumanEval、LiveCodeBench v6 和 MATH500，所有测试均在 32K 最大生成长度下进行。 **精度（每 KV 元素 2.28 位）：** | 模型 | BF16 平均 | OSCAR 平均 | 与 BF16 差距 | | :--- | :--- | :--- | :--- | | Qwen3-4B-Thinking-2507 | 75.64 | 71.86 | -3.78 | | Qwen3-8B | 70.84 | 69.42 | -1.42 | | Qwen3-32B | 74.19 | 74.17 | -0.02 | | GLM-4.7-FP8 (358B) | 77.89 | 78.16 | +0.27 | 为提供竞争方法的对比背景：朴素 INT2（无旋转）在 Qwen3-4B 和 Qwen3-8B 上均得分为 0.00。QuaRot-INT2（仅 Hadamard 旋转）在 Qwen3-4B 上得分为 1.40，在 Qwen3-8B 上得分为 10.14。TurboQuant 在 3.25 位下在 Qwen3-4B-Thinking 上下降 43.90 分。Saw-INT4 在 4.25 位下在 Qwen3-4B 上达到 73.11——OSCAR 在 2.28 位下达到 71.86。 https://arxiv.org/pdf/2605.17757 研究团队还在 AIME25 上与通道级方法进行了比较（表 1）。在 Qwen3-8B 上，OSCAR 在 2.38 BPE 下达到 66.67±3.33——高于 KIVI-KV2* 的 57.67（2.26 BPE）和 Kitty 的 59.67（2.39 BPE）。请注意，通道级方法需要残差缓冲区或不符合标准分页注意力服务的自定义页面布局，因此此比较仅限于有可用结果的单个共享基准测试。 **长上下文鲁棒性（RULER-NIAH）：** | 模型 | 方法 | 16K | 32K | 64K | 128K | | :--- | :--- | :--- | :--- | :--- | :--- | | Qwen3-4B-Thinking | BF16 | 99.7 | 99.3 | 85.3 | 81.0 | | Qwen3-4B-Thinking | QuaRot-INT2 | 0.0 | 0.0 | 15.6 | 0.0 | | Qwen3-4B-Thinking | OSCAR | 97.8 | 87.6 | 61.9 | 39.5 | | Qwen3-8B | BF16 | 98.9 | 97.3 | 79.2 | 78.2 | | Qwen3-8B | QuaRot-INT2 | 19.0 | 9.8 | 0.0 | 0.0 | | Qwen3-8B | OSCAR | 93.9 | 86.3 | 61.9 | 45.0 | 在 GLM-4.7-FP8 上，OSCAR 在 128K 时与 BF16 曲线匹配。 **吞吐量（H100, 100K 上下文，批处理大小 1）：** 与 BF16 相比的解码吞吐量加速比，在增加的上下文长度下： | 模型 | 30K | 60K | 100K | | :--- | :--- | :--- | :--- | | Qwen3-4B-Thinking | 1.98× | 2.52× | 3.08× | | Qwen3-8B | 1.84× | 2.29× | 2.88× | | GLM-4.7-FP8 | 1.98× | 2.49× | 2.83× | 在批处理大小 32 时，100K 上下文下的作业级吞吐量在 Qwen3-4B-Thinking 上达到 BF16 的 6.17 倍，在 GLM-4.7-FP8 上达到 7.83 倍。加速比随着上下文长度增加而增加，因为解码越来越受 KV 带宽限制。将 KV 内存减少 8 倍直接减轻了该瓶颈。在线旋转开销被吸收到解码内核中。 ## **Marktechpost 的可视化讲解** OSCAR —— 操作指南 01 / 08 01 概述 什么是 OSCAR？ **OSCAR**（离线谱协方差感知旋转）是 Together AI 为长上下文 LLM 服务开发的 2 位 KV 缓存量化系统。 OSCAR 不是应用通用的 Hadamard 旋转，而是通过一次性离线校准过程推导出**注意力感知旋转**——将量化噪声与注意力最不敏感的方向对齐。 结果：INT2 精度接近 BF16，并且与分页 KV 缓存服务完全兼容。 8× KV 内存减少 3× 解码加速 每 KV 元素 2.28 位 02 设置 先决条件 开始之前，请确保满足以下条件： - 01 **硬件：** 推荐 NVIDIA H100 GPU (80 GB)。A100 可能适用于较小的模型。 - 02 **安装 SGLang：** OSCAR 已集成到 SGLang 服务框架中。从源代码安装最新版本。 - 03 **Triton：** 自定义融合内核使用 Triton 编写。Triton 附带大多数最新的 PyTorch / SGLang 安装。 - 04 **支持的模型：** Qwen3-4B, Qwen3-8B, Qwen3-32B, GLM-4.7-FP8 或 MiniMax-M2.7。所有这些模型都提供了预计算的旋转矩阵。 `` pip install sglang[all] --upgrade pip install triton `` 03 步骤 1 通过 RotationZoo 下载预计算旋转矩阵 Together AI 在 ModelScope 上的 **RotationZoo** 中发布了支持模型的预计算旋转矩阵和裁剪阈值。无需重新校准。 `` from modelscope import snapshot_download # 为你的模型下载 RotationZoo rotation_path = snapshot_download( 'togethercomputer/OSCAR-RotationZoo' ) `` 下载的工件包含每个支持模型的逐层 `RK`, `RV` 旋转矩阵和裁剪阈值 `cK`, `cV`。这些是固定的离线参数——运行时不会更新。 Qwen3-4B / 8B / 32B2.28 BPE GLM-4.7-FP8 (358B)2.28 BPE MiniMax-M2.72.28 BPE 自定义（运行校准）任何模型 04 步骤 2（可选） 为自定义模型运行离线校准 如果你的模型不在 RotationZoo 中，请运行一次性校准过程。OSCAR 从一个小型数据集中转储 Q、K、V 激活，估计注意力感知协方差，并写出旋转矩阵和裁剪阈值。 `` python calibrate_oscar.py \ --model-path /path/to/your-model \ --calib-data gpqa_diamond \ --calib-tokens 8192 \ --output-dir ./oscar_rotations/ `` **校准并非特定于任务。** 论文表明，结果对领域（MMLU、WikiText、GPQA-Diamond 均产生相似精度）的敏感性较低。运行一次并在所有任务中重复使用。 产生的典型值：每层 `cK ≈ 0.96`, `cV ≈ 0.92`。 05 步骤 3 启动启用 INT2 KV 缓存的 SGLang 传递旋转路径并在启动 SGLang 服务器时启用 INT2 KV 模式。 `` python -m sglang.launch_server \ --model-path Qwen/Qwen3-8B \ --kv-cache-dtype int2 \ --oscar-rotation-path ./oscar_rotations/ \ --oscar-sink-size 64 \ --oscar-recent-size 256 \ --tp 1 \ --port 30000 `` **支持张量并行。** 对于 Qwen3-32B 使用 `--tp 2`（2×H100）。对于 GLM-4.7-FP8 使用 `--tp 8`（8×H100）。 服务器暴露标准的 OpenAI 兼容 API。客户端无需更改。 06 步骤 4 关键配置参数 | 参数 | 默认值 | 控制内容 | | :--- | :--- | :--- | | `--oscar-sink-size` | 64 | 前 N 个 token 以 BF16 保留作为注意力 sink | | `--oscar-recent-size` | 256 | 当前位置之前的最后 N 个 token 以 BF16 保留 | | cK (裁剪比例) | 0.96 | 旋转后键激活的百分位裁剪 | | cV (裁剪比例) | 0.92 | 旋转后值激活的百分位裁剪 | | 组大小 GK | 64 | 每个 INT2 量化组的通道数（头维度） | 论文将 **(sink=64, recent=256)** 确定为精度-效率拐点。较小的窗口会明显降低精度；较大的窗口会增加 BF16 内存开销，收益甚微。 07 步骤 5 运行推理并验证 服务器启动后，使用标准 OpenAI 客户端查询： `` from openai import OpenAI client = OpenAI( base_url="http://localhost:30000/v1", api_key="none" ) response = client.chat.completions.create( model="Qwen/Qwen3-8B", messages=[{"role": "user", "content": "Your long-context prompt here"}], max_tokens=1024 ) print(response.choices[0].message.content) `` **前缀缓存开箱即用。** OSCAR 保留了标准的分页 KV 缓存抽象，因此 SGLang 的基数缓存和前缀重用功能正常运行。无需应用程序级更改。 08 结果 与 BF16 基线的精度对比 平均结果（AIME25, GPQA-Diamond, HumanEval, LiveCodeBench v6, MATH500，生成长度 32K）。 **论文：** arXiv:2605.17757 **RotationZoo：** modelscope.cn/models/togethercomputer/OSCAR-RotationZoo ## **关键要点** - OSCAR 通过使用注意力感知协方差矩阵（而非通用 Hadamard 变换）旋转激活，将 LLM KV 缓存量化到 2 位精度。 - 在每 KV 元素 2.28 位时，OSCAR 在 Qwen3-4B-Thinking 上与 BF16 精度的差距保持在 3.78 分以内，而朴素 INT2 则崩溃为零。 - KV 缓存内存下降约 8 倍，在 100K 上下文下解码速度提升高达 3 倍，在大批量大小下作业级吞吐量达到高达 7.83 倍。 - Qwen3-4B/8B/32B、GLM-4.7-FP8 和 MiniMax-M2.7 的预计算旋转矩阵可在 RotationZoo 中获得——无需重新校准。 - OSCAR 直接集成到 SGLang 中，具有完整的分页 KV 缓存和前缀缓存兼容性，推理客户端无需任何更改。 --- 查看 **GitHub 仓库 (https://github.com/FutureMLS-Lab/OSCAR)、ModelScope (https://modelscope.cn/models/togethercomputer/OSCAR-RotationZoo)** 和 **研究论文 (https://arxiv.org/pdf/2605.17757v1)。** 此外，欢迎在 **Twitter (https://x.com/intent/follow?screen_name=marktechpost)** 上关注我们，别忘了加入我们的 **150k+ ML SubReddit (https://www.reddit.com/r/machinelearningnews/)** 并订阅 **我们的 Newsletter (https://www.aidevsignals.com/)**。等等！你在 telegram 上吗？**现在你也可以在 telegram 上加入我们。(https://t.me/machinelearningresearchnews)** 需要与我们合作推广你的 GitHub Repo 或 Hugging Face Page 或产品发布或网络研讨会等？**联系我们 (https://forms.gle/MTNLpmJtsFA3VRVd9)**