一句话结论
循环 Transformer 省的是参数，不省缓存：同一组层被重复调用多个循环步，每一步都要存自己的键和值，键值缓存随循环步数线性增长，成为推理时的主要内存瓶颈。LoopVQ 要解决的就是这块缓存——把多个循环步的通道放在一起做向量量化，压到每元素 0.5 比特仍优于既有方法，叠加 TaSQ 后到 0.25 比特还能保住大部分 BF16 精度（论文摘要页）。
方法要点
论文的出发点来自两个观察，都写在摘要里：
- 循环轴高度冗余。 循环模型反复套用同样的层，相邻循环步产出的键值在通道维度上信息重叠明显，单独对每一步做量化等于把重复信息重复存了一遍。
- 各循环步对量化的敏感度差别很大。 用同一套量化参数平摊到所有步，会被最敏感的那几步拖住精度，导致整体只能停在较高比特数。
基于这两点，LoopVQ 做了两件事：
第一，跨循环步联合编码。 不是把某一步的键值当独立向量去查表，而是把同一通道在多个循环步上的取值拼成一个向量，整体映射到一个码字。这样冗余部分被同一个码字吸收，等效比特数被摊薄——这也是它能在 0.5 比特/元素这一档跑赢"面向标准大模型的既有缓存向量量化方法"的原因。按作者描述，这个设计与那些方法正交：它们处理的是单步内的键值分布，LoopVQ 处理的是步与步之间的关系。
第二，码本微调对齐全精度输出。 码本不是聚类完就固定，而是以全精度模型的输出为目标做微调，让量化后的注意力计算结果逼近未量化版本。这一步把"压缩误差"从中间张量层面挪到了最终输出层面来约束。
# LoopVQ 核心流程（按论文描述整理的伪代码，非官方实现）
for step in range(num_loop_steps):
K[step], V[step] = shared_layer(x, step) # 同一组层被重复调用
# 1) 沿循环轴联合编码：同一通道跨多个 step 拼成一个向量
vec = concat([K[s][c] for s in range(num_loop_steps)])
code = nearest_codebook(vec) # 联合查表，冗余被同一码字吸收
# 2) 码本微调：目标是全精度模型的输出，而不是重建误差
loss = || attn(K_bf16, V_bf16) - attn(dequant(code)) ||
loss.backward()
update(codebook)
关键数字
摘要给出的数字集中在两处：精度对比与线上服务表现。原文的逐数据集绝对分数不在摘要范围内，下表只列可核对的量。
| 场景 | 指标 | 对比基线 | 结果 |
|---|---|---|---|
| 通用语言建模（Ouro、Huginn） | 每元素 0.5 比特 | 面向标准大模型的既有缓存向量量化方法 | 优于基线 |
| 长链思维推理 | 每元素 0.5 比特 | 同上 | 优于基线 |
| 长上下文检索 | 每元素 0.5 比特 | 同上 | 优于基线 |
| 与 TaSQ 组合 | 每元素 0.25 比特 | BF16 | 保留大部分精度 |
| 32K 上下文解码 | 解码延迟 | BF16 | 接近减半 |
| 1.4B Ouro 服务 | 峰值吞吐 | BF16 | 4.3 倍 |
| 2.6B Ouro 服务 | 峰值吞吐 | BF16 | 6.1 倍 |
需要说明的是，0.5 比特是 LoopVQ 单独使用的档位，0.25 比特要靠与 TaSQ 组合才拿到；这两档的精度结论分别对应"优于既有量化方法"和"接近 BF16"，不是同一件事。延迟与吞吐数字来自作者在 SGLang 中的实现，测试点为 32K 上下文。
局限与前提
摘要没有单列局限小节，以下边界是从方法设计本身能直接读出的：
- 只适用于循环架构。 整套方法建立在"同一组层被多次调用、循环轴存在冗余"这个前提上。标准非循环 Transformer 没有循环轴，联合编码的对象不存在，方法无法直接迁移。论文的验证模型是 Ouro 与 Huginn。
- 依赖码本微调。 不是纯免训练的即插即用方案，需要跑一轮以全精度输出为监督的微调，意味着要能前向全精度模型、要有校准数据，训练开销摘要未给。
- 0.25 比特是组合方案的结果。 如果只上 LoopVQ，可用的档位是 0.5 比特；想要更低比特必须再引入 TaSQ，多一个组件就多一层调参和兼容成本。
- 收益随上下文长度变化。 延迟减半是在 32K 上下文测的，缓存本来就小的短上下文场景收益会明显缩水；吞吐的 4.3 倍与 6.1 倍分别对应 1.4B 和 2.6B 两个规模，更大模型、不同批大小下的曲线摘要里没有。
- 精度结论是相对表述。 摘要说"优于既有方法"“保留大部分 BF16 精度”，但没有给出各任务的具体分数与退化最大的任务类型，长链推理这类对误差敏感的场景实际掉多少，需要看正文表格。
能不能用
开源情况： 摘要页目前没有指向明确的代码仓库或权重发布地址，页面上的代码与权重入口是 arXiv 的通用检索链接，不等于作者已放出实现。想复现得先翻全文与附录确认，或在作者主页跟进。
复现条件，按方法要求推算：
- 模型侧需要 Ouro 或 Huginn 这类循环语言模型权重，规模上论文测的是 1.4B 与 2.6B 两档；
- 推理侧需要 SGLang，作者的服务端数据就是在其中实现的，脱离该后端能否拿到同样的延迟收益未知；
- 微调侧需要一份校准数据，并能前向 BF16 全精度模型产出监督信号；
- 长上下文场景需要能撑住 32K 上下文的显存预算——压制缓存的意义正在于此，但校准阶段仍要按全精度跑。
判断建议： 如果你的服务跑的是循环架构模型、上下文经常拉到几万 token、且缓存确实是显存瓶颈，这套方法值得跟进，0.5 比特档位已经能和既有量化方法正面比；如果用的是常规 Transformer，或者上下文普遍在几千 token 以内，收益不足以抵消引入码本微调的工程量。想更激进压到 0.25 比特，先评估 TaSQ 在你的栈里是否已有落地。
参考来源
- LoopVQ 论文摘要页（arXiv:2611.05304，cs.LG，2026 年 11 月 3 日提交，作者 Minsoo Cheong、Sungjoo Yoo）：https://arxiv.org/abs/2611.05304
- 论文全文 HTML 版（含方法细节与实验表格）：https://ar5iv.labs.arxiv.org/html/2611.05304
- DOI 记录：https://doi.org/10.48550/arXiv.2611.05304