长高低文模子越来越能"记"，但着实让它们跑到线上时，开端顶不住的时时不是算力，而是KV Cache。
每生成一个新 token，模子都要回读越来越长的历史 Key 和 Value。高低文越长、batch 越大，KV Cache 对显存容量和显存带宽的虚耗就越显然。
这亦然为什么 KV Cache 量化成了长高低文 serving 的中枢问题：压得不够，显存撑不住；压得太狠，推理质地又容易崩。
Together AI、悉尼大学和 UIUC 的商榷团队，为此惨酷了一种面向着实 serving 的 2-bit KV Cache 量化决策——OSCAR。
模子不再仅仅把 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。
这阐发，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 的问题从"向量压缩"鞭策到了" 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 的学术编著实习生 � �
感兴趣兴趣的小伙伴迎接原谅 � � 了解降服
� � 点亮星标 � �
科技前沿流露逐日见尊龙凯时