长上下文模型越来越能 " 记 "，但真正让它们跑到线上时，最先顶不住的往往不是算力，而是KV Cache。
每生成一个新 token，模型都要回读越来越长的历史 Key 和 Value。上下文越长、batch 越大，KV Cache 对显存容量和显存带宽的消耗就越明显。
这也是为什么 KV Cache 量化成了长上下文 serving 的核心问题：压得不够，显存撑不住；压得太狠，推理质量又容易崩。
模型不再只是把 K/V 张量压小，而是围绕 attention 真正会使用的方向来做旋转、裁剪和分组，让量化误差尽量避开模型最敏感的部分。
在约 2.28 effective bits per KV element 的预算下，OSCAR 仍能接近 BF16；在 Qwen3-4B-Thinking 上，相比全层 3-bit K/V TurboQuant，最高提升 40.1 分。
这意味着，KV Cache 压缩不再只是 " 少占显存 "，而是开始进入真实长上下文服务系统的设计核心。
不是更会 " 压缩向量 "，而是开始保护 attention
过去很多 KV Cache 量化方法，关注的是如何更好地还原 K/V 向量本身。
但在低比特场景里，这个目标并不总是等价于更好的生成质量。
原因很直接：attention 真正消费的是 Key 和 Query 之间的匹配关系，以及 Value 被注意力权重加权后的输出。K/V 重建误差看起来不大，并不代表 attention logits、attention block output 和后续 hidden state 不会被放大偏移。
2-bit INT 只有 4 个离散等级，而 KV activation 中又常常存在少数幅值很大的 outlier channel。
如果量化尺度被这些极端通道牵着走，大部分正常值会被挤到很窄的区间里，attention 分布也会跟着偏。
普通 Hadamard 旋转可以把 outlier 打散，却不知道哪些方向对 attention 更关键。
OSCAR 的核心变化就在这里：
它不再只问 " 怎么把 K/V 向量还原得更像 "，而是问 " 怎么让 attention 读到的关键信息尽量不变 "。
△只用 K/V 重建误差，容易低估真实误差传播 OSCAR 把旋转对准 attention
OSCAR 的方法可以概括成一句话：
用 attention-aware covariance 来决定 K/V 应该怎么旋转。
具体到Key，量化误差会通过 QK 进入 attention logits，因此 OSCAR 使用 query covariance，也就是 Q Q，来决定 Key 的旋转方向。
具体到Value，误差会先被 attention score 加权，再进入 attention 输出，因此 OSCAR 使用 score-weighted value covariance，也就是 V S SV，来决定 Value 的旋转方向。
离线校准阶段，系统用少量样本估计每一层、每一个 head 的这些 covariance，并生成固定的旋转矩阵和 clipping 阈值。
推理阶段，这些参数直接复用，不需要任务级微调，也不需要在线学习。
最终旋转可以写成：
R=U · Hadamard · bit-reversal
其中，U 负责对齐 attention 相关方向，Hadamard 用来摊平 outlier 能量，bit-reversal 让 INT2 分组更均衡，避免某个 group 被少数异常通道主导。
也就是说，OSCAR 不是简单 " 加一个旋转 "，而是把旋转、裁剪和分组都放进 attention 质量这个目标里。
△从离线校准到在线推理的 pipeline
OSCAR 的另一个关键点，是它没有停留在离线量化评测里。
它已经接入 SGLang 的服务路径，在运行时维护一个三段式 token pool：
BF16 sink（64 tokens）｜INT2 history｜BF16 recent（256 tokens）
开头的 attention sink token 和最近窗口 token 继续用 BF16 保存，用来保护 attention sink 与最近上下文。
中间最长、占比最大的历史 KV，则保存为旋转和裁剪后的 INT2。
新 token 会先写入 recent window。随着解码推进，最老的 recent token 会被融合 Triton kernel 处理，完成 rotate、clip、quantize 和 pack，然后降级进入 INT2 history。
存储上，每 4 个 2-bit 数值被打包进 1 个 byte。
decode 阶段，OSCAR 在 GPU 上分别处理 BF16 段和 INT2 段：
INT2 kernel 负责 unpack、scale/zero point 反量化以及浮点累加；BF16 kernel 处理 sink/recent；最后再通过 online softmax merge 合并两部分结果。
由于它兼容 paged KV、radix prefix cache 和 SGLang 的 fused kernel pipeline，OSCAR 面向的是可部署的长上下文 workload，而不是只展示漂亮的离线准确率。
小模型也能守住高难推理
论文在 Qwen3-4B-Thinking、Qwen3-8B、Qwen3-32B 和 GLM-4.7-FP8 上做了评估。
任务覆盖 GPQA、HumanEval、LiveCodeBench v6、AIME25 和 MATH500，最长生成长度达到 32K，并且每个配置运行 5 次取平均。
结果显示，在约 2.28BPE 下，OSCAR 的精度仍然非常接近 BF16。
以Qwen3-4B-Thinking为例：
TurboQuant mean 为 31.74，QuaRot-INT2 只有 1.40，Naive INT2 为 0.00；OSCAR 达到 71.86，距离 BF16 只差 3.78，并且比 TurboQuant 高 40.1 分。
在 Qwen3-8B 上，OSCAR mean 为 69.42，BF16 为 70.84，TurboQuant 为 56.88。
到了 Qwen3-32B 和 GLM-4.7-FP8，OSCAR 与 BF16 基本持平。
当任务真正依赖长链推理、代码生成和数学推导时，低比特 KV Cache 的核心瓶颈不是 " 能不能压 "，而是压缩误差会不会破坏 attention 的关键路径。
OSCAR 的优势，正是让接近 2-bit 的预算仍然守住推理质量。
论文还专门看了AIME25这个高难数学推理任务，并加入 KIVI-KV2、Kitty 和 OSCAR 的对比。由于 KIVI 和 Kitty 没有可直接用于 long context run 的 framework 支持，论文选取了它们唯一在 32K 下汇报的 AIME25 结果。
在 Qwen3-8B 上，OSCAR 以 2.38 BPE 达到 66.67，几乎追平 BF16 的 66.00，并明显高于 KIVI-KV2 与 Kitty。
在 Qwen3-32B 上，OSCAR 达到 74.00，略高于 BF16 的 72.59，也超过 Kitty 的 69.26。
但对 serving 系统来说，精度只是第一关。真正上线时，还要看显存、带宽、batch、prefix cache，以及端到端吞吐。
OSCAR 在系统层面的收益也很直接：
相比 BF16 history storage，OSCAR 可以把 KV Cache memory 降低约 8 倍。
在 100k context、batch-size-1、full prefix-cache hit 的设置下，decode 最高约 3 倍加速。
在大 batch 且显存预算固定时，job-level throughput 最高约 7 倍。
prefix cache 命中率越高，KV Cache 压缩带来的收益越容易转化为吞吐提升。
对于共享系统提示、多轮 Agent、工具调用链路这类长前缀高复用场景，这一点尤其重要。
更关键的是，它把 2-bit KV Cache 的问题从 " 向量压缩 " 推进到了"attention 质量 "和"serving 系统 "共同设计。
很多低比特方法为了保分，会把第一层、最后一层或若干敏感层保留在更高 bit。这当然能减少精度损失，但也会抬高平均 bit 数，并让 kernel 和 cache layout 更复杂。
OSCAR 的设定更接近真实服务：历史 KV 主体统一使用 INT2，只在 sink 和 recent 两个很小窗口保留 BF16。
这让它更容易接进 paged cache、prefix cache 和批量调度。
为什么这对长上下文 Agent 很重要
真实 Agent 往往包含很长的系统提示、工具说明、历史对话和检索内容。不同请求之间，还会存在大量共享前缀。
如果 KV Cache 全部使用 BF16，显存很快会成为天花板。如果直接上朴素 INT2，推理链条又可能失真。
OSCAR 给出了一种更系统的折中：长历史用 INT2 降容量和带宽；关键 sink/recent 用 BF16 保稳定；再让 prefix cache 复用共享前缀。
这也解释了为什么 attention-aware rotation 值得被单独提出。
它不是一个更花哨的旋转技巧，而是在重新定义低比特 KV Cache 的优化目标：压缩不是目的，让模型在压缩后仍然能正确使用注意力机制，才是目的。
诚然，TurboQuant 仍是很强的通用 online vector quantization 方法，OSCAR 则更专注于 attention-aware 的 2-bit KV serving。
两者并不一定只能二选一。
OSCAR 目前 code repo 中已经把 attention-aware rotation 与更强的 Lloyd Max codebook 结合，把压缩率继续往极限推。
OSCAR 带来的关键启发是：2-bit KV Cache 如果要真正上线，旋转不能只追求 " 有 "，而要对准 attention。
同时，它也必须被放进真实 serving 系统里一起设计。
不过虽然目前 OSCAR 已经覆盖多个模型规模和多类推理任务，但真实线上 workload 更复杂。未来仍需要在更多模型架构、硬件环境、prefix cache 命中模式、多租户请求和尾延迟场景中继续验证。
此外，OSCAR 重点解决的是 attention-aware rotation与 2-bit KV serving。
后续如果能结合更强的动态窗口策略、更多硬件后端和统一 serving 框架，低比特 KV Cache 的边界还可能继续向前推进。
P.S. 作者 Zhongzhu Zhou 是 Together AI 的 Senior Research Scientist，悉尼大学博士，研究方向包括高效机器学习系统、模型训练与推理的算法系统协同设计，以及 LLM 压缩与量化。
团队成员分别来自 Together AI、悉尼大学和伊利诺伊大学厄巴纳 - 香槟分校。
Together AI 创立于 2022 年 6 月，联合创始人包括苹果前高管 Vipul Ved Prakash、斯坦福大模型研究中心主任 Percy Liang、芝加哥大学副教授 Ce Zhang，以及 FlashAttention 作者 Tri Dao。
论文链接：https://arxiv.org/abs/2605.17757
项目主页：https://oscar-quantize.github.io/
代码链接：https://github.com/FutureMLS-Lab/OSCAR
ModelScope 链接：https://modelscope.cn/models/togethercomputer/OSCAR-RotationZoo
HuggingFace 链接：https://huggingface.co/Zhongzhu/OSCAR-RotationZoo
一键三连「点赞」「转发」「小心心」
欢迎在评论区留下你的想法！
— 完 —
我们正在招聘一名眼疾手快、关注 AI 的学术编辑实习生
感兴趣的小伙伴欢迎关注 了解详情
科技前沿进展每日见
