LoopVQ 压缩循环模型缓存以加速推理

长上下文推理慢，瓶颈可能出在反复读取 KV cache。原文介绍的 LoopVQ，针对循环式 Transformer 的缓存冗余，把每个元素压到不足 1 bit。据文中转述，它在 32K tokens 时可将解码延迟降至 BF16 的约一半，并在部分测试中大幅提高吞吐。

这条消息值得关注，但适用范围要看清：主要实验对象是 Ouro 等循环模型，不能直接理解为所有大模型接入后都能提速两倍。对程序员更有用的，是理解它压缩了什么，以及这些成绩该怎么比较。

为什么循环模型的缓存特别值得压缩

KV cache 保存注意力计算中的 Key 和 Value，让模型生成下一个 token 时复用已有结果。上下文越长，需要存储和读取的缓存就越多。

循环式 Transformer 还多了一层压力：重复执行的层会分别保存自己的 Key 和 Value，缓存随循环次数线性增长。作者观察到，不同循环步骤之间存在较高冗余，但此前面向标准 LLM 的向量量化方法，没有专门利用这种冗余。

LoopVQ 的做法是把多个循环步骤放在一起编码，再微调码本。码本可以理解为一套共享的代表向量，缓存通过记录对应编码，减少直接保存数值的空间。

LoopVQ 的关键，是利用循环步骤之间的相似性，把 KV cache 压到每个元素不足 1 bit。

原文称，实现可以直接接入 SGLang，无须重新训练底层 Transformer。不过，它仍需要训练后的码本微调。「不用重训模型」不等于「没有适配成本」，两者要分开看。

延迟减半、吞吐翻倍和峰值六倍分别指什么

原文给出了几组成绩，它们衡量的不是同一件事。

在每个元素 0.5 bit 的配置下，LoopVQ 在 32K tokens 时的解码延迟约为 BF16 的一半。作者给出的解释是：长上下文下，读取缓存占据了解码流程的大量时间，压缩缓存可以减少读取负担，因此上下文越长，收益越明显。

吞吐数据更高：相较 BF16，1.4B 和 2.6B Ouro 模型的峰值服务吞吐分别最高提升至 4.3× 和 6.1×。原文又称，在典型批量大小下，同样硬件的每秒请求承载能力大约翻倍。

峰值吞吐、典型批量下的请求容量，以及解码延迟，需要分别理解。原文没有给出具体硬件、批量大小和完整负载设置，无法据此推算某个线上服务能提升多少。

质量方面，原文称 0.5 bit 下的推理与检索性能损失可忽略，思维链基准结果与全精度接近。但更激进的 0.25 bit 配置，需要结合 TaSQ 才能保留 BF16 的大部分准确率，已经存在质量取舍。原文没有解释 TaSQ 的机制，也没有列出逐项成绩。

我的判断

我认可它对缓存瓶颈的切入：如果解码时间主要花在读取 KV cache，减少缓存数据量就有机会同时改善延迟和容量。联合编码循环步骤，也有明确的模型结构依据。

但证据边界很清楚。实验主要覆盖 1.4B、2.6B Ouro，也涉及 Huginn；其他架构可能需要专门校准。把这些结果推广到一般团队常用的模型，目前依据不足。

与已有向量量化方法相比，LoopVQ 的特点是利用循环轴冗余。不过，这篇短文主要给出了相对 BF16 的成绩，没有提供同条件下与其他缓存量化方案的完整对照，尚不能据此判断它普遍领先。

作者进一步主张，报告长上下文解码速度时应以 sub-bit KV cache 配置替代 BF16 基线。我更倾向于同时报告两者：BF16 有助于保持对照一致，压缩配置则展示实际部署潜力。压缩精度、码本适配过程和质量结果也应一并公开，否则速度数字难以比较。

能拿来做什么

• 如果你在用 SGLang 部署 Ouro 或 Huginn，可以把 LoopVQ 列入评估，先确认模型适配和码本微调成本，再测试自己的上下文长度与生成长度。
• 如果你负责 Node 层的 AI 服务压测，应分别记录解码延迟、每秒请求数和批量大小，避免用峰值吞吐倍数估算用户实际等待时间。
• 如果业务依赖长上下文检索或推理，应把质量回归与速度测试放在一起，尤其不要把 0.5 bit 的质量描述直接套到 0.25 bit 配置上。