循环架构的显存账，有人靠共享缓存来平

参数量不变，效果靠「多过几遍」来换——循环架构是这个思路的代表。但它有个隐性代价：推理显存随着轮数线性涨。一篇 10 月 22 日的 arXiv 论文专门处理这笔账。

一、发生了什么

循环架构让激活值反复穿过同一组层，参数不增加，质量往上叠。问题出在推理阶段：每一轮都会生成自己独立的一套 KV 缓存，轮数越多，显存占用线性增长，长上下文场景尤其难受。

此前有工作发现，最后一轮的缓存可以直接给前面各轮复用，效果不掉——研究者把这个性质叫「可共享性」。但怪就怪在，它不稳定：同样训练方式训出来的模型，有的有这个性质，有的没有，机理一直没说清。

论文分两步把这件事做成了可控的。第一步在预训练阶段引入随机深度，让各轮的表示被推向一个共同的收敛点，给共享打地基；直觉上，这相当于训练时随机「抄近路」，逼着各轮学会产出彼此接近的中间状态。第二步是训练后的调整：把最后一轮的缓存广播进第一轮，再训练一轮，让模型学会产出兼容的残差，同时保住原有质量。按论文报告，调整后模型与常规微调的困惑度持平。

更实用的是组合性：这种共享可以和低精度缓存量化（fp8、mxfp8、nvfp4）以及新的序列混合器叠加使用。在模拟的低显存长上下文推理里，缓存命中率最多提高 31.4%，吞吐最多提高 23.6%，九成位延迟的首字时间最多缩短 83.6%。

（背景补充，非论文结论：KV 缓存是长上下文推理显存的大头，业界有多种压缩路线，共享缓存属于「从架构设计源头省」的一类。）

二、跟你有什么关系

自建推理服务的人。 显存扩容成本高，这类结构级省法叠加量化，能比单纯换更大显卡省得多。首字延迟能砍掉八成的结果，对交互式产品尤其值钱——用户对「卡住不吐字」的忍耐远低于对吐字慢的忍耐。

选模型的人。 同样的上下文长度，不同架构的显存曲线差很多，长文本场景要把这个因素算进成本。测显存别只看峰值，要看它随会话轮数的增长速度。

做 agent 的人。 长会话、多轮任务的显存压力，未来可能因为这类改进而明显缓解，今天超限的场景未必一直做不了。

三、怎么用

1. 先量现状：压测一下你的服务里，KV 缓存占总显存的比例，占比低就不用折腾。
2. 显存紧张时按顺序试：量化缓存、共享类结构、换混合器，每步都要回归测试。
3. 关注新开源模型的技术报告，看它有没有内置这类设计，选型时把「显存随轮数增长慢」当加分项。

四、三个别信的说法

「参数少就省显存。」 循环架构参数不变，缓存照样涨，参数量根本不反映推理显存。

「缓存只能靠量化压。」 量化是主流，但从结构上让各轮共享是另一条路，两者还能叠加。

「这类改进离落地很远。」 论文报告的吞吐和延迟收益是在模拟条件下测的，数字要打折看，但方向已经能用工程语言评估了。

五、一句话结论

推理省显存，别只盯着砍精度，让该共用的东西共用起来。

信息来源

• arXiv 论文页：循环架构的缓存共享，2026-10-22

功能与价格以官方公告为准。本文写于 2026 年 10 月 25 日。