2603.09023

缺失的内存层级：面向 LLM 上下文窗口的需求分页

一句话定位

提出 Pichay 系统，将操作系统中的需求分页与虚拟内存层级思想引入 LLM 上下文管理，解决因重复加载工具定义、陈旧结果等导致的 21.8% 结构性浪费问题。

小学生也能听懂

这篇论文发明了一个叫Pichay的智能助手，它像整理书包一样帮大模型管理记忆：把不常用的旧作业（工具结果）收进抽屉，只留重要的在桌上，需要时再拿出来，这样大模型就不用反复看重复内容，节省了大量时间和精力。

为什么值得记录

• 首次在大规模生产语料（857 会话，44.5 亿 token）中量化了 LLM 上下文中的结构性浪费（21.8%），并给出分类（死工具输出 26.5%、工具定义模式 20.2%、静态系统内容 11.0%）
• 提出并实现了一个透明代理架构 Pichay，无需修改模型或客户端即可实现上下文分页、缺页检测与工作集固定，已在生产环境部署
• 引入合作式内存管理机制（phantom tools 与 cleanup tags），使 LLM 能主动释放冷页面或请求恢复，突破了传统硬件内存管理中非合作应用的限制
• 构建了四级 LLM 内存层级模型（L1 生成窗口 → L4 跨会话持久记忆），其中 L1-L3 已部署，为长上下文系统提供了可扩展架构范式

核心方法

• Pichay 作为透明 HTTP 代理插入客户端与推理 API 之间，拦截并修改消息数组，保留原始会话历史作为后备存储
• 区分垃圾回收（不可重请求的临时输出）与分页（可寻址内容如文件读取），仅后者可能引发缺页
• 采用 FIFO 按用户轮次年龄驱逐陈旧工具结果（>4 轮且 >500 字节），替换为检索句柄（如 '[Paged out: Read file.py...]'）
• 缺页检测通过匹配工具调用名与参数识别模型对已驱逐内容的重新请求
• 故障驱动固定策略：若某页被驱逐后引发缺页，则永久固定该路径内容，防止重复驱逐；文件编辑时自动解除固定
• 实现四级压力区（<60K 观察 → ≥120K 紧急驱逐），在中等压力下向模型注入内存状态信息以促使其合作清理
• L3 层级通过 cleanup tags 支持模型发起对话折叠（collapse），将多轮对话压缩为带声明损失的单句摘要

关键结果

• 离线回放 140 万次模拟驱逐，缺页率仅 0.0254%
• 生产部署中单会话上下文消耗从 5,038KB 降至 339KB（减少 93%），空闲上下文从 7% 提升至 43%
• 在 681 轮会话中维持 97% 驱逐率，极端压力下出现预期抖动现象（反复缺页调入）
• 整体减少 21.8% token 浪费，相当于每输出 token 注意力计算减少 21.8%，累计节省 850 亿 token-token 注意力对
• 通过工具定义存根化、内容去重与陈旧结果驱逐三项干预，显著降低上下文膨胀

局限与风险

• 当前驱逐策略仍基于简单 FIFO，未考虑访问频率或语义重要性，可能影响复杂任务下的工作集准确性
• 合作机制依赖模型理解并正确使用 phantom tools 与 cleanup tags，存在学习成本与行为不确定性
• L3 折叠机制尚未大规模评估，其摘要质量与故障恢复准确性有待验证
• 实验基于单一高级用户的语料，虽具代表性但多用户泛化性需进一步验证

适合沉淀的概念

demand-paging, memory-hierarchy, context-window-management, fault-driven-pinning, cooperative-memory-management, retrieval-handles, structural-waste, attention-cost-quadratic

阅读注意

• 重点理解 Table 1 和 Table 2 中 OS 概念与上下文管理的类比映射，这是全文架构思想的核心
• 关注 Section 5.1 中的放大因子（84.4×）与 Section 6.6 中的累积成本节省，体现 O(n²) 注意力成本的现实影响
• 注意区分 garbage collection 与 paging 在故障率计算中的不同作用，避免误解系统性能
• Section 3.7 提出的合作式管理是创新点，对比传统 OS 中非合作应用的设计差异
• Appendix A 提供了数据复现路径，适合验证实验结果

质量说明

• 采用来源：clean，papers/2026/03/2603.09023.md
• 生成模型：LongCat-Flash-Chat
• 源材料判断：论文提供了完整的方法描述、大规模实证数据、开源代码与可复现脚本，实验设计严谨，结果可信度高。