你让手机上的 AI 看一段长视频，再追问开头出现了什么。模型不只要“看懂”，还得一直留着前文的线索。内容越长，这份临时记忆越大，最后往往不是模型不会答，而是手机内存先撑不住。
TierKV 处理的正是这道难题。它没有简单删除旧内容，而是把模型的临时记忆分成三档：重要部分原样留在内存，更多内容压缩保存，超长的尾部转移到闪存。更关键的是，它会在正式生成答案前预测需求，提前决定每部分放在哪里。
这项工作的全部方法和效果数据均来自 TierKV 论文，尚无代码仓库或第三方复现；文中的最高加速不能理解为所有模型和场景都能达到同样效果。
手机真正装不下的，可能不是模型
端侧推理（On-device Inference）指模型直接在手机等个人设备上运行，不把请求送往云端。这样做有隐私、离线可用等优势，但手机的内存、带宽和能耗都更紧张。
长上下文尤其麻烦。模型生成文字时，会保存此前每个 token——可以理解为文字、图像或音频被切分后的基本处理单位——在各层产生的中间结果。这就是 KV Cache（键值缓存）：像一叠随用随查的草稿纸，避免模型每生成一个新词都从头计算。
草稿纸的厚度会随 token 数量近似线性增长，而且模型每一步生成都要读取它。论文给出的例子是，Llama-3.2-3B 处理 32K token 时，仅 KV Cache 就约占 1.8 GB；Llama-3.2-1B 到 131K token 时则超过 4 GB。这还没有算模型权重和运行缓冲区。
手机内存也不是全部交给 AI。论文记录的 OnePlus 12 有 12 GB 物理内存，其中 Linux 内核、Android 系统与服务、硬件缓冲区及安全余量合计占去约 4.6—4.8 GB。应用越过稳定预算后，可能触发系统的低内存清理机制，直接被终止。
三层“书桌”，但不丢掉原文
过去的办法各有代价。低秩压缩会用更小的近似表示保存 KV Cache，但恢复数据需要计算；直接淘汰 token 可以省内存，却会永久丢掉信息；把数据卸载到闪存，则可能让模型停下来等读盘。
TierKV 的核心机制叫 Predictive Multi-Tier Cache Optimization，简称 PMCO，即“预测式多级缓存优化”。多级缓存很好理解：常用资料摊在桌面，不那么常用的放进抽屉，更少用的收入柜子。难点不是分层本身，而是提前判断什么资料下一刻会用到。
它把 KV Cache 分成三层：
- Tier-0（Exact）保存未经压缩的 token，保护对压缩敏感的位置。
- Tier-1（Compressed）用 SVD 低秩形式保存大部分上下文。SVD 是一种把大矩阵近似拆成更小表示的方法；压得越狠，越省空间，但信息损失风险也越高。
- Tier-2（Offloaded）把长尾部分以完整精度放进闪存，限制常驻内存的规模。
因此，“保留完整上下文”不等于所有数据都以无损、全精度形式留在 RAM。它的准确含义是：TierKV 不做不可逆的 token 删除，三层数据仍可被访问；其中压缩层使用近似表示，闪存层则要付出读取成本。
它到底预测什么？
模型正式逐词生成前，要先完成 prefill——先读完整个输入，并建立初始 KV Cache。这个阶段本来就会产生 hidden states（隐藏状态），也就是模型处理输入后留下的内部表示。TierKV 直接复用这些结果，不额外跑一个预测模型。
它会根据输出概率的熵给隐藏状态加权。这里的“熵”可以粗略理解为模型有多拿不准：越可能影响决策的 token，权重越高。系统由此生成一枚请求“指纹”，再到设备本地的历史记录中寻找相似请求，用它们过去的输出长度预测这次最终会有多长。这个方法不需要训练额外参数，但依赖本地历史能否提供足够相似的样本。
预测完成后，PMCO 同时选择三个东西：原样保存到哪里为止、压缩保存到哪里为止，以及各层使用多大的压缩秩。选择必须同时满足设备内存和论文设定的准确度预算。论文称，这个运行时问题可以用 closed-form solver（可直接求解、无需漫长迭代搜索的求解器）处理；每个请求的在线选择耗时低于 0.1 秒。
预测错了也有退路。高估长度只会留下暂时没用上的容量；低估长度时，新增 token 会进入全精度的 Tier-2，代价是更多闪存 I/O，而不是越过内存预算或继续压缩导致精度风险。
省下内存后，别把时间花在搬运上
分层缓存最容易出现两个新瓶颈：解压计算和闪存等待。TierKV 为此改写了注意力计算路径。
普通做法会先把压缩数据完整还原，写进临时内存，再交给注意力计算。TierKV 将原样数据和压缩数据放进同一条融合计算路径，只在芯片上的高速空间里按块恢复需要的 key，不把完整中间结果写回全局内存。处理 value 时，它先在压缩后的低维空间累加，最后只做一次投影。论文称，在 Llama-3.2-1B、50% rank 的设置下，这让 value 路径的浮点运算量减少 45%。
另一部分优化来自预取（Prefetching）：系统在计算真正索要数据前，先从闪存搬运下一批内容。TierKV 又把等待读取形成的空档拿来做压缩层重建。论文报告，这种重叠调度相对不重叠的实现降低了 10%—30% 的端到端延迟；其 I/O 调度器的预取命中率为 94.4%。
数字说明了什么？
论文在三款手机 SoC 上测试了八个文本、视觉和音频模型，GPU 覆盖 Adreno 750、Adreno 740 和 Mali-G715。对比对象包括 llama.cpp、MNN-LLM 与 MLC-LLM。
最醒目的 17.6 倍来自 prefill throughput（读入并处理初始上下文的吞吐量）的最高提升，不是普遍加速。具体到 TinyLlama-1.1B，TierKV 的 prefill 为 272.8 token/s，llama.cpp 为 174.6 token/s，MNN-LLM 为 56.7 token/s；表中的 17.6 倍对应其相对 MLC-LLM 的 12.2 token/s。不同框架对模型、精度和上下文长度的支持并不完全一致，因此这个峰值更适合说明优化上限，而非通用体验。
代价也很清楚。以 Llama-3.2-1B 为例，解码速度从 llama.cpp 的 6.0 token/s 降到 4.3 token/s，下降约 28%，原因是 SVD 重建增加了计算。论文认为，更快的 prefill 抵消了这部分损失，但不同模型差异明显；采用 MHA 架构的 SmolVLM2-1.7B，解码速度从 4.6 降至 1.9 token/s。
内存收益更稳定。论文报告，常驻 RAM 的 KV Cache 减少 12.5%—34%，平均为 25%。这不是总内存或峰值内存同幅下降。它带来的实际价值，是在相同预算下容纳更多上下文：例如 Llama-3.2-3B 从基线的 7K token 扩展到测试中的 14K，Gemma4 E2B 从 50K 扩展到 128K。论文强调，TierKV 一侧给出的是实际测试到的最大长度，不一定是系统硬上限。
为什么值得关注
TierKV 的意义不只是又一种压缩算法。它把端侧长上下文改写成一个资源编排问题：先预测一次请求会长成什么样，再共同安排精度、内存、计算和闪存带宽。
这也贴近真实的多模态负载。图像、视频和音频会先变成大量 token；即使用户只问一句话，模型背后也可能要处理很长的输入。端侧模型从“能够启动”走向“能够处理真实任务”，关键不只是缩小模型，还要管理不断增长的运行时记忆。TierKV 展示了一条具体路线：让有限 RAM 不再直接决定上下文的终点，再用调度控制为此付出的速度代价。
局限与未知
- 论文把精度损失描述为“较小”，但不同任务对压缩非常敏感。其 profiling 中，GSM8K 在部分激进设置下明显崩塌；现有材料没有给出所有最终配置对应的完整精度变化，不能把“较小”视为已被普遍证实。
- 17.6 倍是特定组合下的最高 prefill 提升。框架支持范围、模型结构和上下文长度并不统一，不能外推为日常生成速度提高 17.6 倍。
- 所有效果均来自论文作者的测试。材料未提供代码仓库或第三方复现，预测器面对全新任务、长期使用记录不足以及不同闪存状态时的实际表现，仍待外部验证。