在消费级显卡上跑大模型，真正的天花板往往不是权重，而是 KV 缓存。
权重是一次性加载的，KV 缓存却随着每解码一个 token 就往上涨。数据中心 GPU 靠大容量和高带宽能吸收这份开销，换到一台 8GB 显存的笔记本上，同样的开销会直接翻译成吞吐量下滑、延迟飙升，以及远在模型标称上下文窗口之前就先撞上的 OOM。
arXiv 在 2026 年 10 月 13 日放出的一篇论文（SparPR: Runtime KV-Cache Recovery for Resource-Constrained LLM Inference on Consumer Hardware，https://arxiv.org/abs/2610.18140）尝试处理这个老问题。它不做压缩也不做量化，而是把「缓存装不下」拆成三个可以在线做出的运行时决策。
三个决策，而不是一个压缩率
论文把已有工作归成三条互不相通的线：FlexGen、LeoAM 这类分层卸载系统回答「能不能跑起来」；StreamingLLM、H2O 这类缓存保留方法回答「该留哪些信息」；Quest、ProphetKV 这类局部恢复方法回答「怎么把它弄回来」。SparPR 的主张是，这三个问题本该串在同一个运行时循环里。
Query-Aware 的 key-block 选择。 给每个历史块预计算一个紧凑摘要——块内各注意力头 key 向量的均值。这些摘要常驻 GPU，打分时只碰摘要，不碰已卸载到 CPU 或磁盘的完整 KV 块，块的相关性得分就是 query 与各头摘要的内积之和。论文用 Top-k 而非固定阈值，让候选块数量变化时选择尺度保持稳定。
动态预算控制。 系统分别估算单块的拷贝成本和重算成本：拷贝按数据量除以主机到设备带宽计算，系数 2 对应 key 和 value 两份；重算按块长度与隐藏维平方估算，稀疏路径上只通过注意力投影从检查点重建，不重跑 MLP 也不走完整前向。两个成本的比例映射到目标保留率，再套一个 Minimum Keep Floor 作为保守下界，防止预算在压力下收缩得太狠。
按需局部重算加成本感知回退。 Top-k 选出的块往往散落各处，逐块恢复带来碎片化开销，所以先把相邻块合并成连续 span，再比较全量恢复与稀疏恢复的成本。当稀疏路径不再明显便宜时就退回全量，这就是 Dense Fallback Threshold γ 的作用。
一台笔记本上的实测数字
环境很具体：一台消费级笔记本，RTX 3070 Ti 8GB，Ryzen 9 6900HX 移动版 CPU，16GB 主机内存，Windows 加 WSL，引擎是 FlexGen/FlexLLMGen，模型是 facebook/opt-6.7b，batch size 4。
DeepSpeed 和 HF Accelerate 在 1k token 之前就 OOM，Quest 风格方案在 1200 token 处 OOM，只有 FlexGen 和 SparPR 保持可运行。FlexGen 靠溢出到 CPU 和磁盘完成 1k 到 4k，但在 8k 处超时；SparPR 把 1k、2k、4k 的端到端延迟分别降低 31%、52%、63%，吞吐提升 1.4 倍、2.1 倍、2.7 倍，并在 44 分钟内跑完 8k 负载。
保真度用 Needle 任务测：把一条目标事实插进《爱丽丝梦游仙境》节选的两个深度位置。50% 保留率下 SparPR 在 2k/4k/8k 分别是 .943/.879/.780，H2O 是 .492/.506/.511，StreamingLLM 是 .445/.467/.485。压到 10% 时差距更明显：SparPR 还有 .600/.482/.308，H2O 掉到 .12 左右，StreamingLLM 崩到 .02。论文解释：前者基于位置，needle 只有落在最近窗口里才活下来；H2O 与查询无关，命中率基本跟着保留率走。
消融里两个结果值得留意。去掉动态预算后准确率反而更高（.963 对比完整版 .957），说明预算机制的收益主要体现在更长上下文上。Quest-only 变体准确率只有 .777，是所有变体最低的——省下的延迟是拿检索质量换的。论文对局限也说得清楚：只有一个 OPT-6.7B、一块消费级 GPU、一个构造的 needle 任务。
所以呢
这篇论文的价值可能不在那几个漂亮的百分比，而在于它给出了一个更务实的框架：端侧推理的瓶颈管理，本质是不断在「搬」和「算」之间做动态权衡，而不是找到一个一劳永逸的压缩率。