你同时请几位助手解题，若事先给每人发同样厚的一本草稿簿，简单题会留下大片空白，难题却可能写到一半没纸。今天的长推理 AI 也有类似问题：回答越长，保存的中间结果越多；多个请求一起运行时，显存很快就被这些“草稿”占满。GrowPage 的做法，是不再把每个请求的容量从头锁死，而是在生成过程中观察需求：现有空间够用，就整理旧内容；确实需要更多，再领一页。
这里的“草稿”叫 KV cache——大语言模型生成文字时保存的前文中间结果，后面可以直接利用，不必反复计算。GrowPage 处理的是推理服务，也就是让许多用户共享加速卡、同时获得回答的系统。此时目标不只是让一个回答跑得快，还要兼顾并发量、等待时间、显存占用和回答质量。
这项工作的实验与效果数字目前均来自 GrowPage 论文，尚无独立信源交叉验证。好在论文全文给出了方法、实验设置和对照数据，可以比摘要多看一步。
固定预算为什么别扭
现有不少 KV 压缩方法会先给每个请求规定一个容量上限，再决定其中哪些内容保留、哪些丢弃。问题在于，推理请求并不整齐。
论文在 AIME24、AMC23 和 LiveCode 上分析发现，不同请求能够保持正确作答所需的最低 KV 容量，横跨了整个测试范围。有的题只需少量历史信息，有的题需要更多。统一给得少，难题可能丢掉关键推理记录；统一给得多，简单题又会白占显存。
变化还发生在同一个回答内部。模型有时只紧盯少数历史内容，注意力很集中；有时需要同时回看更广的上下文，注意力变得分散。论文给出的理论结论是：若要覆盖相同份额的注意力并控制最坏情况下的近似误差，注意力越分散，需要保留的 KV 状态就越多。换句话说，一道题在不同推理阶段需要的“草稿纸厚度”也可能不同。
它怎样判断该不该加一页
GrowPage 为每个请求维护两份轻量的 query summary。Query 可以理解为模型当前“正在寻找什么”的内部表示；summary 则是对这些表示做平滑汇总。一份看近期，反应较快；另一份看较长时期，充当历史参照。两者分别估算：为了覆盖给定比例的注意力，需要看多大的历史工作集。
如果近期工作集相对长期参照扩大，说明模型开始广泛回看过去，现有容量可能偏紧；如果近期注意力更集中，就未必需要加空间。作者默认用两种时间尺度的指数平滑，衰减系数分别为 0.9 和 0.999，并以覆盖 99% 注意力质量的工作集来比较需求。
GrowPage 不会每生成一个 Token——文字被模型切分后的基本单位——就做一次昂贵判断。它只在当前容量用尽、来到“容量边界”时二选一：
- Compress & Hold：容量不变，压缩历史 KV 状态，腾出一页空位继续生成。系统会按不同层和注意力头分别选择内容，同时照顾近期与长期都重要的状态，并保护最近的 16 个 Token。
- Grow by One Page：若信号显示工作集正在扩大，就申请一个新的物理页，并把它加入该请求的页面表。实验中一页可容纳 256 个 Token 的 KV 状态。
标题里的“动态扩缩”需要说得更准确。论文采用的是单调增长：它能按需增加物理页，也能在现有配额内压缩内容，但不会主动释放一个仍在运行的请求已经取得的页面。作者解释，回收页面需要进行不可逆的 KV 驱逐；真正双向调整容量只在附录中研究。因此，GrowPage 更像“需要时扩容，不需要时原地整理”，不能写成物理预算会自由伸缩。
页式管理让算法真正进入服务系统
GrowPage 接入 PagedAttention——一种把 KV 缓存按页面管理的机制。可以把它理解成操作系统分配内存页：请求不必占用一整块连续空间，而是逐页取得物理存储。GrowPage 正好把需求判断翻译成页级动作。
当全局还有空页时，扩容请求会立即满足；显存紧张时，系统改为压缩，让单个请求不能独占共享资源。若压力仍未解除，原有调度器还可暂停并重新调度请求。
这种结合也保留了两项常用服务能力。Continuous batching（连续批处理）会在请求完成后及时补入新请求，提高设备利用率；prefix caching（前缀缓存）则让共享相同开头的请求复用已有计算。论文还称其兼容 CUDA Graph，并继承 Zipage 的异步压缩流程，让 KV 整理尽量与正常服务重叠。
数字说明了什么
作者在单张 80 GB NVIDIA A100 上测试 DeepSeek-R1-Distill-Llama-8B 和 Qwen3-8B，任务覆盖 GSM8K、MATH500、AMC23、AIME24 与 LiveCodeBench，包括数学推理和代码生成。所有相关服务实验把 GPU 显存使用比例固定为 0.9。
在 DeepSeek-R1-Distill-Llama-8B 上，GrowPage 五项任务的平均 Pass@1——模型第一次作答即正确的比例——为 68.7%，平均解码吞吐量为每秒 2417 Token。完整保留 KV 的 vLLM 分别为 69.2% 和 1472 Token/s。也就是说，平均正确率接近，而吞吐量按论文计算提高 64.3%。
在 Qwen3-8B 上，GrowPage 的平均 Pass@1 为 87.5%，吞吐量为 2174 Token/s；FullKV vLLM 为 88.7% 和 1357 Token/s。论文报告吞吐量提高 60.2%，代价是平均 Pass@1 低 1.2 个百分点。
更直接的对手是 Zipage。它同样兼容 PagedAttention，但每个请求仍使用预设容量。GrowPage 在两款模型上的平均吞吐量分别为 2417 和 2174 Token/s，Zipage 为 1936 和 1853 Token/s；对应平均 Pass@1，GrowPage 为 68.7% 和 87.5%，Zipage 为 67.6% 和 86.5%。这组结果支持论文的核心判断：与其只研究“固定盒子里该扔什么”，不如也决定盒子何时需要变大。
双时间尺度信号也接受了单独检验。在 Qwen3-8B 的 AMC23 数据上，它与后续真实需求变化呈强单调关系，方向判断一致率为 80.3%。消融实验中，默认设置在 AMC23 和 AIME24 上分别达到 91.4% 与 73.8% Pass@1；直接使用当前 query 虽然吞吐更高，但准确率明显下降。改用注意力熵来衡量需求，也同时损害准确率和吞吐量。
额外判断并非完全免费，但频率不高。论文报告，一次事件中的在线需求计算、注意力评分、窗口遮罩、Top-k 选择和 KV 整理分别耗时 5.84、8.54、0.70、8.72 和 19.05 毫秒，合计占相应长输出解码时间不到 0.32%。
为什么值得关注
GrowPage 最有意思的地方，不是又提出一种“该删哪些 Token”的规则，而是换了问题：每个请求到底应该占多少容量，也可以由运行时决定。这更贴近真实服务负载，因为用户的问题难度不同，同一回答的注意力需求也会随阶段变化。
它还提醒我们，算法节省显存不等于服务吞吐自然提高。MorphKV、R-KV 和 G-KV 在论文实验中虽然压缩了 KV，却因缺少服务系统协同，吞吐量明显落后。GrowPage 把判断接到现有页式内存和调度机制上，才把省下的空间转成更多并发请求与更高吞吐。
局限与未知
- 所有结果来自作者在单张 A100、两款 8B 模型和五项任务上的实验。换用其他硬件、模型规模或真实线上请求后能否保持优势，材料没有给出答案。
- GrowPage 只会逐页扩张或在原容量内压缩，不会主动缩减物理分配。长时间运行时，这种单调增长会怎样影响全局公平性与页面回收，仍需进一步验证。
- “更优的性能—吞吐权衡”依赖具体比较点。现有数据支持它在论文设置下优于若干基线，但不能推成对所有预算、负载和质量要求都占优。