最近看到一篇非常有意思的论文：

《The Missing Memory Hierarchy: Demand Paging for LLM Context Windows》

论文地址：

• The Missing Memory Hierarchy: Demand Paging for LLM Context Windows
• 原文：https://arxiv.org/abs/2603.09023

这篇论文的核心观点非常简单但极具启发性：

LLM 的上下文窗口，本质上是一个没有内存管理系统的“裸内存”。

如果把 LLM Agent 看成一个程序，那么当前的设计就像：

• 所有历史数据都一直留在内存里
• 每次执行都重新扫描整个内存
• 没有分页
• 没有缓存
• 没有工作集
• 没有淘汰策略

这显然是非常原始的。

论文作者做了一件很“操作系统味”的事情：

给 LLM 上下文加一个虚拟内存系统。

一、问题：LLM 上下文在大量浪费 token

作者首先做了一件很重要的事情：

分析真实生产日志。

数据来源：

• 857 个 Claude Code 会话
• 54,170 次 API 调用
• 总输入 token：4.45B

作者把每条消息拆成几类：

• 用户输入
• 模型回复
• 工具输出（read file / bash / etc）

然后统计：

• token 占比
• 使用频率
• 重复读取情况

结果非常惊人。

1 结构性浪费：21.8%

约 21.8% 的 token 是结构性浪费：

主要来自：

1️⃣ 工具定义

很多工具定义几千 token 但会话里从未调用。

却在 每一轮请求里重复发送。

2️⃣ 旧工具输出

比如：

后续 80 轮对话里：

• 每一轮 API 调用
• 都重新发送这 10KB
• 都参与 attention

但实际 再也没被引用过。

3️⃣ 重复配置

例如：

• skill 列表
• agent 说明
• prompt 模板

经常被复制多份。

二、关键观察：工具输出会被“无限放大”

论文提出一个概念：

Amplification Factor（放大因子）

例如：

• 第 5 轮读取一个文件
• 文件大小 10KB
• 会话共 85 轮

那么这个文件会被：

放大因子：

而每一次都要参与 attention 计算。

三、解决方案：给 LLM 上下文做“虚拟内存”

论文的核心系统叫：

Pichay

它的实现非常巧妙。

不是改模型。

而是：

在客户端和 LLM API 之间插一个代理。

架构如下：

代理负责：

• 统计 token
• 修改上下文
• 删除旧内容
• 必要时再恢复

模型和客户端完全无感。

四、核心思想：Demand Paging

作者把 LLM 上下文类比为操作系统内存。

1 淘汰策略（Eviction）

非常简单：

当一个工具输出满足：

就淘汰。

2 被淘汰的内容如何表示？

替换成一个 占位符：

模型如果需要：

就会再次调用工具。

3 Page Fault（缺页）

如果模型再次调用：

代理检测到：

于是：

• 重新读取文件
• 注入上下文

这就是：

LLM 的 page fault。

4 Fault-driven Pinning

如果某个页面：

说明淘汰太早。

系统就会：

以后不再淘汰。

除非：

五、离线实验：删错概率极低

作者用 29 个完整会话做离线重放实验。

模拟：

结果：

• 模拟删除：1,393,000 次
• 缺页：354 次

缺页率：

也就是说：

99.97% 的删除都是安全的。

六、在线实验：token 下降 37%

作者对比三种策略：

结果：

而任务：

• 全部完成
• 没有质量下降

甚至有些情况下：

回答质量更好。

原因很简单：

噪音减少，注意力更集中。

七、真实生产案例

作者把 Pichay 用在自己的开发环境。

Case A：正常开发

原始上下文：

启用分页：

删除：

缺页：

几乎完美。

Case B：极端长会话

681 轮。

系统出现：

Thrashing（抖动）

原因：

工作集太大。

不断：

类似操作系统的：

swap storm。

八、最重要的理论结论

传统操作系统：

所以策略是：

但 LLM 完全相反。

LLM 的成本模型

如果一个内容一直留在上下文：

每生成一个 token 都要重新计算 attention。

复杂度：

因此：

保留 token 的累计成本非常高。

而重新读取文件：

成本是：

所以结论是：

在 LLM 中，宁可多一点 page fault，也不要保留太多 token。

九、这件事为什么很重要

这篇论文其实在说一件很大的事情：

未来的 LLM 系统必须有内存层级。

可以类比成：

当前 LLM 系统：

只有 L1。

十、未来方向

论文提出了很多值得研究的方向：

1 成本驱动的 eviction

不再看：

而是计算：

2 phase-aware memory

识别：

不同阶段使用不同策略。

3 pin decay

当前：

未来：

4 object-level memory

不再按：

分页。

而是：

十一、我的一些思考

这篇论文的最大价值是：

把 LLM memory 问题彻底系统化。

它告诉我们：

未来 AI Agent 的架构可能会像这样：

而不是：

换句话说：

Prompt Engineering → Context Engineering

十二、总结

这篇论文最核心的发现：

1️⃣ 21.8% token 是结构性浪费

2️⃣ 简单分页策略缺页率只有 0.025%

3️⃣ token 使用减少 37%

4️⃣ 回答质量没有下降

5️⃣ LLM 的成本模型与传统虚拟内存完全相反

如果未来 LLM agent 真的要：

• 长时间工作
• 多工具协作
• 持续项目开发

那么：

Memory hierarchy 可能会成为 AI 系统的核心基础设施。

而这篇论文很可能会成为这个领域的 早期经典工作之一。