问题

循环架构（looped architecture）不增加参数量，而是让激活反复穿过同一组层来增加计算量。听上去很省，但推理时每一次循环都会生成独立的 KV 缓存，显存占用随循环次数线性上涨。循环 8 次，就等于存 8 份缓存。

已有研究发现，某些情况下最后一次循环的 KV 缓存可以直接给前面几次复用而不掉质量，作者把这种性质叫 KV-shareability。问题是它并不稳定：同样结构、同样训练的模型，有的能共享，有的不能。

两阶段方法

第一阶段在预训练时使用随机深度，诱导出收缩型残差动力学，让不同循环的表示向同一个极限靠拢。第二阶段是 BeNice! 后训练：把最后一次循环的 KV 缓存广播到第一次，同时联合优化「带缓存复用的第一次循环」和「不带复用的最后一次循环」，让前者学会产生兼容的残差，后者保持原有质量。

论文报告，这样得到的共享缓存验证困惑度与常规微调的未共享结果相当。方法还能与 MLA、Kimi delta attention 这类高效序列混合器，以及 fp8、mxfp8、nvfp4 的低精度 KV 量化叠加使用。

数字

  • 1.3B Parcae 模型、循环 8 次：全局 HBM 从 63.82GB 降到 21.60GB（降 66.2%），测试条件为 batch 64、上下文 2048；
  • 模拟低显存长上下文服务：缓存命中率最高提升 31.4%，吞吐最高提升 23.6%；
  • 在每秒 2 个请求的模拟回放中，p90 首 token 延迟从 139.2 秒降到 23.2 秒（降 83.6%）。

局限

所有性能数字都来自作者，尚未被独立复现；服务侧结果使用生产请求轨迹的模拟回放与代理模型，不是真实线上部署；评测对象是特定的 Parcae 检查点，能否迁移到其他循环架构或普通 Transformer 尚未建立。显存数字也依赖具体的 batch 与上下文设置，不能直接外推到你的服务。

判断

这篇论文值得关注的地方不是某个百分比，而是它把「循环架构省参数」的账算完整了：参数省下来的显存，可能被缓存翻倍吃回去。对做推理优化的人，这是一个提醒——评估新架构时，缓存和调度要跟参数一起算，否则基准好看、上线就爆显存。

参数不涨，缓存会涨；省下来的显存，最后还是要还给 KV。