面包屑图标 当前位置: 首页
AI资讯
热点详情

超越TurboQuant长上下文推理真二比特KV量化算法

AI热点日报
AI热点日报时间:2026-05-30
热点解读

```html 超越 TurboQuant,显存压力终于得到缓解!Together AI 最新论文 OSCAR 直接挑战 TurboQuant,提出一套面向长上下文推理服务的真正 2-bit KV Cache 系统,实现开箱即用。 长上下文模型的能力正持续增强,这已是不争的事实。然而,一旦投入实际服

```html

超越 TurboQuant,显存压力终于得到缓解!Together AI 最新论文 OSCAR 直接挑战 TurboQuant,提出一套面向长上下文推理服务的真正 2-bit KV Cache 系统,实现开箱即用。

超越TurboQuant,面向长上下文推理的真2-bit KV Quantization算法问世

长上下文模型的能力正持续增强,这已是不争的事实。然而,一旦投入实际服务场景,最先成为瓶颈的往往不是算力,而是 KV Cache。每生成一个 token,都需要从显存中读取不断累积的历史 key 和 value。上下文越长、批处理规模越大,KV Cache 对显存和带宽的消耗就越严重。一个自然的解决方案是:将历史 KV 压缩到 2-bit。从理论上看,显存占用可降低约 8 倍,这无疑极具吸引力。但真正的挑战在于——压缩之后,推理能力不能出现明显下降,且这套方法必须在真实 serving 框架中落地,而不能仅停留在论文图表中。

问题随之而来:为什么 2-bit KV Cache 如此困难?INT2 仅有 4 个量化等级,而 KV activation 中常常隐藏着少量幅值极大的 outlier channel。一旦这些 outlier 主导了量化尺度,大多数正常值就会被挤压到极少的有效等级中,注意力分布很快就会出现漂移。常规的 Hadamard 旋转确实能在一定程度上分散 outlier,但它并不清楚模型在 attention 中实际读取哪些方向。OSCAR 的核心思路非常直接:将旋转目标从「重建原始 K/V 向量」转变为「保留 attention 消费 KV 的方式」。

相比之下,此前的工作如 TurboQuant 只是对向量进行压缩,却忽略了真正影响模型表现的是 attention 质量。OSCAR 所保留的,恰恰是 attention 实际会读取的方向。朴素 INT2 以及全模型层的 3-bit K/V TurboQuant 都会在困难推理任务上出现明显的分数下滑;而 OSCAR 在约 2.28 effective bits per KV element 的设置下仍能逼近 BF16 水平,并在 Qwen3-4B-Thinking 上相较 3-bit K/V TurboQuant 取得了最高 40.1 分的提升。

OSCAR 的出发点

图 1:为何仅关注 K/V 重建误差会带来误导

图 1 对比了 naive INT2、Hadamard-only、clip-only 以及 OSCAR 在量化误差传播链路中的差异。关键在于,原始 K/V 的重建误差并不能完全解释模型的最终表现;真正影响推理质量的是 attention-score KL 散度、attention-block 输出 MSE 以及后续的 hidden-state 误差。OSCAR 的优势并不仅仅在于让向量数值变得更平滑,而是将量化误差压制在 attention 不敏感的方向上。

OSCAR 的设计思路

具体而言,对于 key,量化误差会进入 attention logits,即 QKᵀ,因此 OSCAR 利用 query covariance(QᵀQ)来构建 key 的旋转目标;对于 value,误差会通过注意力权重传导至输出,因此 OSCAR 采用 score-weighted value covariance(VᵀSᵀSV)。在离线校准阶段,OSCAR 从少量校准样本中估计这些 attention-aware covariance,为每一层、每个 head 生成固定的旋转和 clipping 阈值。最终的旋转表示为 R = U・Hadamard・bit-reversal:U 负责对准 attention 相关方向,Hadamard 用于分散 outlier,bit-reversal 则平衡 INT2 分组,避免某个 group 被少数通道完全支配。

更值得关注的是,OSCAR 并非那种离线完成量化、得到指标后便告结束的论文,它已经成功接入 SGLang,真正做到了开箱即用。OSCAR 在 SGLang 中维护了一个 token 池:

BF16 sink (64 tokens) | INT2 history (~2.28 BPE) | BF16 recent (256 tokens)

其中 sink token 和 recent window 保持 BF16,用于保护 attention sink 与短期局部上下文;中间最长的历史段则存储为旋转后的 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,因此能够直接应用于长上下文 workload,而非停留在论文图表之中。

图 2:OSCAR 整体流程示意

图 2 展示了 OSCAR 从离线校准到在线 serving 的完整路径。左侧为离线阶段:OSCAR 从少量校准样本中估计 attention-aware rotation 和 clipping threshold,使 KV activation 在进入 INT2 之前变得更适合量化。右侧为在线阶段:sink/recent token 继续保持 BF16,中间最长的 history KV 则进入旋转后的 INT2 cache,并在 SGLang paged KV 中完成真实 serving。因此,OSCAR 并非单一的量化技巧,而是一套完整的 2-bit KV Cache pipeline。

评估结果

OSCAR 在 Qwen3-4B-Thinking、Qwen3-8B、Qwen3-32B 以及 GLM-4.7-FP8 上进行了测试,任务涵盖 GPQA、HumanEval、LiveCodeBench v6、AIME25、MATH500,生成长度最高达到 32K,每个设置运行 5 次并取平均值。

OSCAR 在 2.28 BPE 的设置下,Qwen3-4B-Thinking 距离 BF16 仅 3.78 分,Qwen3-8B 距离 BF16 仅 1.42 分,而 Qwen3-32B 与 GLM-4.7-FP8 则基本与 BF16 持平。相比之下,QuaRot-INT2 和 naive INT2 在这些 reasoning / coding 任务上大多直接崩溃;TurboQuant 在全层 3-bit K/V、无 mixed-precision 保护的公平设置下,也在小模型推理任务上出现了明显的分数下降。

OSCAR 还在 128K 长上下文设置下对中 / 大规模模型进行了 RULER-NIAH 测试:OSCAR 在 Qwen3-8B 和 GLM-4.7-FP8 上都保持了明显更稳定的检索性能,这表明这种 attention-aware 旋转不仅能够支撑短评测任务,也能够有效抵抗超长历史中 KV 误差的累积。换句话说,OSCAR 是少数能够在真正接近 2-bit 设置下仍保持现代 reasoning model 质量的方法。

系统层面的收益同样非常直接:相较于 BF16 history storage,OSCAR 可减少约 8 倍的 KV Cache 内存占用;在 100k context、batch-size-1、full prefix-cache hit 设置下,decode 速度最高可提升约 3 倍;在大 batch、同等显存预算条件下,job-level throughput 最高可提升约 7 倍。prefix cache 命中率越高,OSCAR 就越能利用更小的 KV footprint 来提升并发吞吐,这对于共享系统提示、多轮 Agent、工具调用循环等长前缀复用场景尤为关键。

精度表现

图 3:完整主结果表,多种 KV 量化方法同台对比

图 4:AIME25 32K 生成,与 KIVI / Kitty 的专项对比

图 3 是论文的主结果表,包含了 BF16、Saw-INT4、TurboQuant、QuaRot-INT2、Naive INT2 以及 OSCAR 在四个模型、五个任务上的完整对比。BF16 代表精度上界;Saw-INT4 是强 4-bit 参考,BPE 为 4.25;TurboQuant 在此处使用无 mixed-precision 保护的全层 3-bit K/V 设置,BPE 为 3.25;QuaRot-INT2 和 Naive INT2 是接近 2-bit 的旋转 / 朴素基线,BPE 约 2.25;OSCAR 则在 2.28 BPE 下运行。

这张表的重点并非单一模型,而是「低比特能否保持稳定」。在 Qwen3-4B-Thinking 上,TurboQuant 的均值为 31.74,QuaRot-INT2 仅为 1.40,Naive INT2 则为 0.00;OSCAR 达到了 71.86,距离 BF16 仅差 3.78,并相对 TurboQuant 提升了 40.1 分。在 Qwen3-8B 上,OSCAR 均值为 69.42,距离 BF16 仅差 1.42,而 TurboQuant 为 56.88。到了 Qwen3-32B 和 GLM-4.7-FP8,OSCAR 基本与 BF16 持平。换句话说,在接近 2-bit 的 KV 预算下,OSCAR 是表中唯一能够在多模型、多任务上稳定贴近 BF16 的 INT2 方法。

图 4 单独聚焦 AIME25 这一高难度数学推理任务,并对比了 KIVI-KV2、Kitty 和 OSCAR。由于 KIVI、Kitty 缺乏 framework 支持,无法进行 long context run,因此选取了他们方法唯一在 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 的预算下保住困难数学推理能力。

系统加速效果

图 5:100k 长上下文下的 decode / batch throughput

图 5 展示了 100k 上下文下的系统性能。OSCAR 在 batch-size-1、full prefix-cache hit 的纯 decode 场景下最高可实现约 3 倍 加速;在固定显存预算下,随着 batch size 增大,INT2 history 带来的 KV footprint 降低能够显著提升 job-level throughput,最高可达约 7 倍。这说明 OSCAR 不仅在精度上表现可靠,也能切实降低显存带宽压力。

图 6:prefix cache 命中率越高,吞吐前沿越向外扩展

图 6 展示了 prefix-cache hit ratio 对端到端 serving throughput 的影响。横轴为单用户吞吐,纵轴为单 GPU 吞吐;从 cache disabled 到 normal cache,再到接近 100% warmup replay,吞吐前沿逐步向外扩展。OSCAR 保持了标准的 paged KV / prefix cache 抽象,因此共享系统提示、多轮 Agent、工具调用循环等长前缀复用场景可以直接受益。

这些结果传递了一个重要信息:OSCAR 并没有依赖「挑选少数层保留高精度」的策略来保住分数。许多低比特方法在实际部署时会借助混合精度:第一层、最后一层或若干敏感层仍然保留较高 bit,这会导致平均 bit 数上升,同时使 kernel 和 cache layout 变得更加复杂。OSCAR 的对比更为严格:历史 KV 主体保持统一的 INT2 表示,仅在 sink 和 recent 两个很小的窗口保留 BF16。这样做的好处是,系统工程上更容易接入 paged cache、prefix cache 和批量调度,也更贴近真实服务场景中的显存预算。

总结与展望

另一个值得强调的要点是,OSCAR 的收益并非仅在小模型或短上下文上成立。论文同时测试了 4B、8B、32B 以及 GLM-4.7-FP8 这样的大模型;既涵盖了数学、代码、知识问答等 32K 推理生成任务,也包含了 128K RULER-NIAH 长上下文检索任务。在短评测中,OSCAR 能够接近 BF16 水平;在长上下文中,它也能让 attention 分布随上下文增长保持更稳定。这表明 attention-aware rotation 并非仅在某个 benchmark 上调参有效,而是在缓解 KV 误差随历史长度累积这一根本问题上发挥了作用。

从应用角度来看,这对长上下文 Agent 尤为关键。真实的 Agent 场景通常包含很长的系统提示、工具说明、历史对话和检索内容,并且不同请求之间存在大量共享前缀。如果 KV Cache 只能用 BF16 存储,系统很快会被显存所限制;如果直接采用朴素 INT2,又可能导致推理链条失真。OSCAR 的设计恰好介于两者之间:长历史使用 INT2 来降低显存和带宽消耗,关键的 sink/recent 区域用 BF16 确保稳定性,再通过 prefix cache 复用共享前缀。换句话说,它将「能压到 2-bit」和「能上线 serving」放在了同一个系统中进行统筹考虑。

TurboQuant 是一种强大的通用 online vector quantization 方法;而 OSCAR 则专注于 attention-aware 2-bit KV serving。二者并非简单的替代关系,例如 OSCAR 的最新 codebase 中已经在 attention-aware rotation 中引入了更强的 Lloyd Max Codebook,将压缩推向极致。OSCAR 带来了一个独特的观点:2-bit KV Cache 要能够上线部署,旋转操作不仅关乎「有没有」,更必须对准 attention,并且要有真实 serving 系统的支撑。

```
热点追踪提示词
你是一名 AI 行业编辑,请围绕下面这条热点输出一份资讯解读:
热点:超越TurboQuant长上下文推理真二比特KV量化算法要求:
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题
来源:https://www.jiqizhixin.com/api/article_library/articles/2026-05-29-3
TURBO

游乐网为非赢利性网站,所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系youleyoucom@outlook.com。

相关热点
AI热点2026-07-14 19:48
面壁智能CTO谈端侧AI:从打字机到大模型的进化突围

面壁智能聚焦端侧AI,不拼参数大小,而是通过知识密度提升与模型风洞技术,将大模型压缩至手机、汽车等设备。其MiniCPM以2B参数超越同期8B对手。CTO曾国洋22岁主导训练中国首个大语言模型CPM-1。端侧AI追求“默契系统”,在用户开口前预判需求,已在吉利、上汽大众等车型落地应用。

AI热点2026-07-14 19:48
印度IT巨头HCL Tech投350亿卢比建50MW AI数据中心

印度IT巨头HCLTech投资最高350亿卢比建设AI数据中心,容量可扩展至50MW,提供从设计到运营的端到端服务,旨在满足政府及企业日益增长的算力需求,抢占印度快速增长的数据中心市场,并推动AI基础设施布局。

AI热点2026-07-14 19:48
小米具身智能机器人新工站双侧螺母上件成功率达98%

小米具身机器人在汽车工厂自攻螺母上件工站实现双侧作业成功率98%,接近人工水平。同时在新工站分别达到90%成功率,从单一操作拓展至多工站协同,验证了具身智能在复杂工业环境的落地能力。

AI热点2026-07-14 19:48
DeepSeek梁文锋身价360亿美元成AI新首富

全球AI行业正迎来新的财富格局,DeepSeek创始人梁文锋凭借其公司的迅猛发展,个人财富急剧膨胀,一举超越多位硅谷知名人物,成为全球AI公司领域的新首富。以下将详细解析其身价飙升背后的关键因素及公司发展历程。 一、身价飙升至360亿美元,超越多位AI大佬 根据最新彭博亿万富豪指数,DeepSeek

延伸阅读