LoopVQ压缩循环Transformer KV Cache，32K解码延迟近乎减半

摘要：LoopVQ 针对循环 Transformer 在每轮迭代中分别保存 Key、Value 所造成的线性 KV Cache 膨胀，跨循环轮次联合量化多个步的通道，并通过微调码本逼近全精度模型输出。实验显示，该方法在 0.5 bit/元素下优于面向标准 LLM 的既有向量量化方案；与 TaSQ 组合后，0.25 bit/元素仍可保留大部分 BF16 精度。其 SGLang 实现在 32K 上下文中将解码延迟近乎减半，并在 1.4B、2.6B Ouro 模型上将峰值服务吞吐分别提升至 4.3 倍和 6.1 倍，为循环模型的显存与带宽瓶颈提供了可直接落地的缓解路径。

---

LoopVQ 将循环 Transformer 的 KV Cache 从“每个循环步独立存储”改为“跨循环步联合编码”，目标是解决参数共享架构中最容易被忽视的运行时瓶颈：显存占用与内存带宽仍随迭代轮数线性增长。

为什么循环模型省了参数，却没省 KV Cache

循环 Transformer 通过重复调用同一组层权重执行多轮计算，以较少参数模拟更大模型的部分能力。若序列长度为 (L)，隐藏维度为 (D)，注意力头数为 (H)，循环步数为 (S)，标准自回归推理的 KV Cache 大致随 (L) 线性增长；循环模型还需要为每一轮分别保留 K/V，因此额外引入近似 (S) 倍的缓存维度。

以常见 GQA 配置为例，单层缓存可近似表示为：

[ M_{KV}=2 \times L \times S \times H_{kv} \times D_h \times b ]

其中 (b) 是每个元素的存储字节数，(H_{kv}) 是 KV 头数。普通 Transformer 只保存一轮，而循环模型保存 (S) 轮，因此即使权重完全共享，缓存仍可能成为长上下文解码阶段的主要显存消费者。

LoopVQ 的关键观察是：循环轴上的缓存存在高度冗余，而且不同循环步对量化的敏感度明显不同。若所有步共享同一套码本或统一分配比特预算，容易让量化误差集中到最敏感的步骤。

跨循环步联合向量量化

LoopVQ 不再分别压缩每一轮的 Key 和 Value，而是把多个循环步的对应通道组织成联合向量，再通过向量量化器映射到离散码本。解码时，每一步无需保留完整 BF16/FP16 张量，而是保存索引与共享码本；这既减少缓存字节数，也降低读取 KV Cache 时的 HBM 流量。

训练阶段，LoopVQ 会微调码本，使量化模型的输出逼近全精度模型。与仅优化重构误差的方法相比，这一目标更贴近最终生成质量，因为 KV Cache 误差会经过后续注意力计算、归一化和输出投影不断传播。

联合编码利用的是循环步之间的结构相似性，而不是简单套用逐通道量化。因此，它对循环 Transformer 的专用收益不能简单外推到普通 LLM；反过来，论文也表明 LoopVQ 与标准 LLM 的既有 KV Cache 向量量化方法正交，可以叠加使用。

0.25 bit 仍保持大部分 BF16 精度

在 Ouro 与 Huginn 模型上，LoopVQ 在 0.5 bit/元素时优于面向标准 LLM 的既有向量量化方法，覆盖通用生成、长链式思维推理和长上下文检索。与 TaSQ 组合后，即使降至 0.25 bit/元素，仍可保留大部分 BF16 精度。

这意味着缓存理论体积可缩小到 BF16 的约 1/64，但实际收益不能直接按 64 倍计算。原因包括：

• 码本与元数据需要额外常驻显存；
• 极低比特下码本查找、向量重建和反量化会增加计算开销；
• GPU kernel、批量大小与请求长度会改变收益；
• 评测仍需覆盖多轮工具调用、严格结构化输出和高精度代码任务。

论文当前披露的是论文报告的量化准确度与任务表现，而不是所有生成任务的逐位等价。对于法律、医疗、代码执行等高容错敏感场景，生产上线前仍应自行测量任务级成功率与输出稳定性。

SGLang 实测：收益主要来自带宽与延迟

作者将 LoopVQ 集成进 SGLang。在 32K 上下文条件下，解码延迟相对 BF16 近乎减半；1.4B 和 2.6B Ouro 模型的峰值服务吞吐分别最高提升 4.3 倍和 6.1 倍。

这类结果符合循环模型的内存系统特征。参数共享减少了权重容量，却不自动消除每轮 KV 的读写量；压缩缓存后，自回归解码每生成一个 Token 都需要读取历史状态，HBM 带宽下降能够直接转化为更短的迭代时间，并在批处理场景中容纳更多并发序列。

不过，吞吐倍数不能脱离硬件、并发度、输入输出长度和 KV 长度解读。若服务负载偏短或主要受模型计算限制，缓存压缩收益会缩水；若上下文持续增长，收益通常更明显。摘要也未披露峰值显存、码本占用、不同批大小下的尾延迟及与 FP8 等生产基线的完整对照。

开发者落地建议

1. 先确认循环步数是否足够高：若循环步数很少，跨步冗余有限，复杂量化可能得不偿失。
2. 优先在长上下文场景压测：LoopVQ 的主要价值是控制 KV Cache，而非减少模型主体计算。
3. 同时记录质量、延迟和显存：不要只比较理论压缩率，应覆盖首 Token 延迟、每 Token 延迟、吞吐、峰值显存和任务成功率。
4. 对 0.25 bit 设置回退阈值：可先用 0.5 bit 建立质量基线，再依据任务容忍度测试 0.25 bit，并保留 BF16 或较高比特路径作为异常回退。
5. 验证 kernel 兼容性：生产收益取决于量化、反量化和码本查找是否融合进高性能推理路径；若存在频繁 CPU 同步或额外拷贝，理论优势会明显折损。

LoopVQ 的工程意义不在于再提供一个通用量化算法，而在于识别出循环 Transformer 的专用结构：权重共享解决了参数容量，却没有自动解决逐轮 KV 膨胀。跨循环步联合量化把这种冗余转化为可部署的显存和带宽收益，为循环模型的真实服务化补上了关键一环。

---

消息来源：Hugging Face Daily Papers (2026-11-03)

—— 完 ——

主题标签： #LoopVQ 关注 #KV Cache量化 关注 #循环Transformer 关注 #SGLang 关注 #低比特推理 关注