超越TurboQuant：Together AI把2-bit KV Cache推向真实服务

长上下文模型越来越能“记”，但真正跑到线上时，最先撑不住的往往不是算力，而是KV Cache。

每生成一个新token，模型都得回头去读越来越长的历史Key和Value。上下文越长、batch越大，KV Cache对显存容量和访存带宽的消耗就越吃紧。这也是为什么KV Cache量化几乎成了长上下文服务绕不开的核心命题：压得不够，显存扛不住；压得太狠，推理质量又容易崩。

Together AI、悉尼大学和UIUC的研究团队，为此提出了一套面向真实服务的2-bit KV Cache量化方案——

。这套方案的核心思路，不再是单纯把K/V张量压小，而是围绕attention真正会消费的方向来做旋转、裁剪和分组，让量化误差尽量避开模型最敏感的区域。结果如何？在约2.28 effective bits per KV element的预算下，OSCAR依然能的表现；在Qwen3-4B-Thinking上，相比全层3-bit K/V TurboQuant，。

这意味着，KV Cache压缩的讨论，已经不再停留在“怎么少占显存”，而是开始进入真实长上下文服务系统的设计核心。

不是更会“压缩向量”，而是开始保护attention

过去很多KV Cache量化方法，关注点是如何更好地还原K/V向量本身。但在低比特场景里，这个目标并不总是等价于更好的生成质量。原因很直接：

K/V的重建误差看起来不大，并不代表attention logits、attention block output和后续hidden state不会被放大偏移。

2-bit INT只有4个离散等级，而KV activation中又常常存在少数幅值很大的outlier channel。如果量化尺度被这些极端通道牵着走，大部分正常值会被挤到很窄的区间里，attention分布也会跟着偏。普通Hadamard旋转可以把outlier打散，但它不知道哪些方向对attention更关键。

OSCAR的核心变化就在这里：

△只用K/V重建误差，容易低估真实误差传播

OSCAR把旋转对准attention

OSCAR的方法可以概括成一句话：

具体到

，量化误差会通过QKᵀ进入attention logits，因此OSCAR使用query covariance，也就是QᵀQ，来决定Key的旋转方向。具体到，误差会先被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的精度仍然

。

以

为例：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的核心瓶颈不是“能不能压”，而是

OSCAR的优势，正是让接近2-bit的预算仍然守住推理质量。

论文还专门看了

这个高难数学推理任务，并加入了KIVI-KV2、Kitty和OSCAR的对比。在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。

这说明，OSCAR的优势不只体现在与TurboQuant的比较中。在现有KV Cache量化方法里，它也能以接近2-bit的预算守住

但对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倍。

这背后的逻辑很直白：当历史KV footprint变小，系统就能在同样显存预算下容纳更长上下文、更大batch，或者更多并发请求。prefix cache命中率越高，KV Cache压缩带来的收益越容易转化为吞吐提升。对于共享系统提示、多轮Agent、工具调用链路这类长前缀高复用场景，这一点尤其重要。

如果把OSCAR放在KV Cache量化的发展脉络里看，最重要的不是它又把bit数压低了一点。更关键的是，它把2-bit KV Cache的问题从“向量压缩”推进到了

和共同设计。很多低比特方法为了保分，会把第一层、最后一层或若干敏感层保留在更高bit。这当然能减少精度损失，但也会抬高平均bit数，并让kernel和cache layout更复杂。OSCAR的设定：历史KV主体统一使用INT2，只在sink和recent两个很小窗口保留BF16。这让它更容易接进paged cache、prefix cache和批量调度。

为什么这对长上下文Agent很重要

真实Agent往往包含很长的系统提示、工具说明、历史对话和检索内容。不同请求之间，还会存在大量共享前缀。如果KV Cache全部使用BF16，显存很快会成为天花板。如果直接上朴素INT2，推理链条又可能失真。OSCAR给出了一种更系统的折中：

这也解释了为什么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如果要真正上线，旋转不能只追求“有”，而要

同时，它也必须被放进真实serving系统里一起设计。

不过，虽然目前OSCAR已经覆盖多个模型规模和多类推理任务，但真实线上workload更复杂。未来仍需要在更多模型架构、硬件环境、prefix cache命中模式、多租户请求和尾延迟场景中继续验证。此外，OSCAR重点解决的是attention-aware rotation与2-bit KV serving。后续如果能结合更强的动态窗口策略、更多硬件后端和统一serving框架，低比特KV Cache的边界还可能继续向前推进。