论文阅读：The Missing Memory Hierarchy - Demand Paging for LLM Context Windows
论文标题：The Missing Memory Hierarchy: Demand Paging for LLM Context Windows
作者：Tony Mason
发表位置：arXiv 预印本，Computer Science > Operating Systems，同时涉及 cs.AI 与 cs.SE
arXiv 编号：arXiv:2603.09023v1
提交时间：2026-03-09
原文链接：https://arxiv.org/abs/2603.09023
代码与数据：论文给出 GitHub 仓库https://github.com/fsgeek/pichay，并标注论文快照为v0.1.0-paper
主题：LLM 上下文管理、虚拟内存、按需分页、工作集、Agentic AI
核心问题：LLM Agent 的上下文窗口被当成“全部内存”使用，导致工具定义、系统提示词、旧工具结果长期占用上下文；论文提出把上下文窗口视为 L1 cache，并用按需分页与工作集管理来降低结构性浪费。注：PDF 使用了 ACM/SOSP 模板字样，但 arXiv 页面显示该论文为 2026 年提交的 arXiv 预印本；本文按 arXiv 状态标注，不将其视为已正式发表于 SOSP。
1. 论文要解决什么问题？
这篇论文讨论的是 LLM Agent 的上下文窗口管理问题。在很多 Agentic AI 系统中，每次调用模型时，客户端都会重新拼接一份完整上下文：系统提示词、工具定义、用户与助手消息、工具调用结果等。随着任务推进，这些内容不断累积，旧的工具输出和不再使用的 schema 仍然会被反复发送、tokenize 并参与注意力计算。
作者的核心判断是：上下文窗口不是内存，而是类似 CPU 缓存层次中的 L1 cache。它容量有限、速度快、成本高，不能承担整个系统的长期记忆。如果只不断扩大上下文窗口，而不引入分页、换入换出、工作集估计、持久存储等机制，就相当于只给机器加物理内存，却没有虚拟内存和内存层次结构。
论文用生产会话数据说明这个问题不是个别实现瑕疵，而是当前 Agent 架构的结构性结果：
- 工具定义会在每次请求中被重复发送，即使多数工具在该会话中不会被调用；
- 系统提示词、项目说明、memory 文件等静态内容会重复占据上下文；
- 工具结果尤其是
Read读出的文件内容，会在后续大量回合中持续存在； - 输入 token 的规模远大于输出 token，长会话中的成本和注意力压力不断累积。
论文提出的系统 Pichay，就是一个位于客户端和推理 API 之间的透明代理。它不修改模型、不修改客户端、不修改推理 API，而是在消息流中做上下文管理：删除无用内容、把可恢复内容分页出去、在模型再次需要时检测 page fault，并用 fault history 识别应当保留的工作集页面。
2. 背景和直观类比
2.1 从“上下文窗口”到“物理内存”
论文把 LLM 上下文管理和操作系统虚拟内存做了结构性对应：
| 操作系统概念 | LLM 上下文窗口中的对应物 |
|---|---|
| 物理内存 | 当前上下文窗口，例如 200K tokens |
| 虚拟内存 | 外部持久状态，例如文件系统、数据库、完整 transcript |
| 页表 | 检索句柄、UUID、路径、anchor |
| page fault | 模型重新请求已经被移出上下文的内容 |
| MMU | 代理层，位于客户端和推理 API 之间 |
| working set | 当前任务真正需要的上下文子集 |
| thrashing | 反复移出又换入，消耗大量调用预算 |
| pinning | 根据 fault history 阻止重要页面再次被移出 |
传统计算机早期依赖程序员手工管理 overlay；虚拟内存出现后，系统可以自动在物理内存和外部存储之间移动页面。论文认为，现在的 LLM Agent 仍处于类似“手工 overlay”的阶段：应用把所有东西都塞进上下文，而缺少系统级的换出、换入和工作集管理。
2.2 为什么“更大的上下文窗口”不是完整答案？
扩大上下文窗口当然能缓解一部分问题，但论文认为它不能替代层次化管理，原因包括：
- 上下文越长，注意力计算越重。长上下文不仅增加输入 token 处理，也会影响每个输出 token 对历史内容的 attention 计算。
- 旧信息不一定有用。如果旧工具结果已经不会再被引用，把它继续留在上下文中只会增加噪声和成本。
- 缓存不是内存管理。prompt caching 可以减少静态前缀的重复计算，但缓存 token 仍然占据上下文窗口，也仍然可能参与注意力。
- 长会话会出现工作集变化。规划阶段、执行阶段、调试阶段需要的文件和信息不同，单纯保留全部历史会让热数据被冷数据稀释。
因此，论文主张的不是“缩短上下文”本身，而是把上下文窗口纳入一个可管理的内存层次结构。
3. 方法概述：Pichay 的上下文分页系统
Pichay 是一个透明 HTTP proxy，部署在 Agent 客户端和推理 API 之间。每次请求到达模型之前，Pichay 会看到完整的 JSON 请求，包括系统提示词、工具定义、消息历史和工具结果。它可以测量、替换或删除这些内容，然后把修改后的请求转发给模型服务。
整体思路可以概括为三步：
- 识别哪些内容可以移出上下文：例如旧工具结果、未使用工具 schema、重复技能列表等。
- 把可恢复内容替换成短句柄：例如用
[Paged out: Read /path/to/file.py ... Re-read if needed.]代替完整文件内容。 - 当模型重新请求被移出的内容时检测 fault：如果模型再次调用相同工具读取相同文件，说明之前的移出造成了一次 page fault，系统据此更新 pinning 策略。
论文特别区分了两个概念：
| 类别 | 含义 | 是否可能 fault | 例子 |
|---|---|---|---|
| Garbage Collection | 删除不可稳定重取的临时输出 | 否 | Bash 输出、搜索结果、目录列表 |
| Paging | 移出可以通过稳定身份重新获取的内容 | 是 | 文件读取结果、计划文档、规格说明 |
这个区分很重要。只有可寻址内容被移出后才可能产生 page fault；如果把一次性 Bash 输出也算作分页，会低估真实 fault rate。
4. 关键设计细节
4.1 FIFO 年龄阈值换出
论文当前采用的基础 eviction policy 很简单：按 user-turn 年龄做 FIFO。默认参数是：
- 工具结果距离当前超过
tau = 4个用户回合； - 内容大小超过
s_min = 500字节； - 错误结果不移出，因为模型可能还需要它们进行调试。
符合条件的内容会被替换为短句柄，例如：
[Paged out: Read /path/to/file.py (8,192 bytes, 187 lines). Re-read the file if you need its content.]
这个句柄保留三类信息：被移出的内容是什么、如何恢复、原始内容大致有多大。它比原始内容短得多，但仍能让模型理解“这里曾经有一段可重新读取的内容”。
4.2 Page fault 检测
当模型之后再次调用同一个工具、带相同参数读取同一个对象时，Pichay 会把这视为一次 page fault。比如，某个文件的 Read 结果被移出后，模型又请求读取同一路径，这说明该内容仍属于工作集，之前的 eviction 可能过早。
Page fault 在这里既是错误信号，也是学习信号：它直接告诉系统“这个页面被移出后又被需要了”。
4.3 Fault-driven pinning
Pichay 的一个简单改进是：如果一个页面被移出后造成 fault，就在本会话内 pin 住它，不再移出同一内容版本。
算法大致如下：
1. 移出可寻址内容时，记录路径和内容 hash。
2. 如果之后同一路径被重新读取，检测为 page fault。
3. 如果重新读取的内容 hash 与之前被移出的版本相同，说明模型确实需要旧内容，把该页面 pin 住。
4. 如果文件内容已经变化，则不 pin；旧版本已经过期，新版本重新开始自己的生命周期。
这里使用内容 hash 是为了避免错误 pinning。文件被编辑后，旧内容被移出并不一定是错的；模型重新读取的是新版本，不能说明旧版本应该继续常驻。
4.4 Retrieval handle 作为 anchor
论文观察到，模型能够自然理解这些短句柄。当新模型实例恢复一个包含 paged-out 内容的会话时，它会主动表示需要重新读取被分页出去的文件。也就是说，句柄不仅是省空间的 tombstone，还起到了可延迟解析的 anchor 作用。
更重要的是，这个 handle 默认恢复的是 当前内容，不是被移出时的旧内容。如果文件被编辑过，模型 fault 回来的就是新版本。这避免了 stale cache 的一致性问题。
4.5 Cooperative memory management
经典操作系统通常把应用程序视为非合作对象：OS 只能通过访问模式推断页面冷热。但 LLM 有一个特殊性质：模型本身也希望上下文更干净，因为冗余上下文会降低注意力质量、增加任务失败风险。因此论文提出了 cooperative memory management。
Pichay 设计了两类合作通道。
第一类是 phantom tools，即代理注入给模型、但客户端框架并不知道的工具：
| phantom tool | 作用 |
|---|---|
memory_release(paths) |
模型主动声明某些文件不再需要，代理可以立即移出 |
memory_fault(paths) |
模型请求从代理缓存中恢复已移出的内容，避免真实文件系统 round trip |
第二类是 cleanup tags，即模型在输出文本中嵌入的结构化管理指令：
| tag | 作用 |
|---|---|
drop: block:ID |
立即移出某个 block |
summarize: block:ID "text" |
用模型生成的短摘要替换 block |
anchor: block:ID |
阻止某个 block 被移出 |
collapse: turns N-M "text" |
把一段会话压缩成一个摘要 block |
这使得上下文管理不再完全依赖系统从外部推断，而可以让模型根据自己的任务理解主动释放、压缩或保留信息。
4.6 分层压力区间
Pichay 不是等上下文快满了才行动，而是定义了四个压力区间：
| 区间 | token 范围 | 行为 |
|---|---|---|
| Normal | < 60K | 只观察和记录 |
| Advisory | 60K-100K | 向模型提示内存压力、最大 block 和可用 cleanup 操作 |
| Involuntary | 100K-120K | 代理自动开始按策略 eviction |
| Aggressive | >= 120K | 放宽阈值，优先保证上下文存活 |
其中 Advisory 区间是合作式管理的关键：系统先给模型机会自行清理，而不是一开始就强制移出。
4.7 L3：会话级滚动压缩
除了工具结果，长会话中还有大量对话过程、规划过程和中间决策。这些内容不一定适合用简单的 file-path paging 管理。因此论文把 collapse 操作视为 L3 session history compaction：
- L1：当前生成窗口；
- L2：被 demand-paged 和 pinned 的工作集；
- L3：会话历史，以模型声明损失的方式压缩；
- L4：跨会话持久记忆，尚未完整实现和评估；
- Storage：完整 transcript、工具输出、文档等全量存储。
L3 的压缩不是无损的。它强调保留 outcome，例如“做了什么决定、实现了什么、哪些方案失败”，而不是保留所有推理过程和中间工具输出。
5. 实验设置
5.1 数据集
论文使用的是一个 power user 在约四个月内使用 Claude Code 的生产会话数据，时间范围约为 2025 年 11 月到 2026 年 3 月。冻结 cohort 包含：
| 指标 | 数值 |
|---|---|
| 会话数 | 857 |
| API calls | 54,170 |
| 有效输入 token | 4.45B |
| 软件项目数 | 15 |
会话类型包括主会话、subagent 会话、compact 会话、prompt suggestion 会话等。论文明确指出这是单用户、重度使用者的 corpus，外部有效性有限，但它代表了上下文管理问题最突出的工作负载。
需要注意一个口径差异：arXiv 摘要页面显示 “4.45 million effective input tokens”，但 PDF 正文和多处表格使用的是 4.45 billion。本文按 PDF 正文中的 corpus 数字进行解读，同时保留这一不一致作为元数据注意点。
5.2 三类工具
论文实现并使用了三层测量工具：
| 工具 | 作用 |
|---|---|
probe.py |
离线分析 Claude Code 原始 JSONL transcript，统计工具使用、内容大小、放大因子等 |
proxy.py |
透明 HTTP proxy，截获请求、记录完整 payload，并可应用 trimming / paging |
pichay |
实验运行框架，组织 baseline、trimmed、compact+trim 等对照运行 |
5.3 Treatment 条件
论文比较了三种代理层处理方式：
| 条件 | 说明 |
|---|---|
| Baseline | 只观察记录，不修改请求 |
| Trimmed | 工具定义 stubbing 与 skill 去重 |
| Compact+Trim | 在 trimming 基础上加入旧工具结果 eviction / paging |
6. 主要实验结果
6.1 工具结果是上下文膨胀的主要来源
在完整 corpus 上，论文报告会话字节中约 79.4% 来自工具结果，助手文本约 12.7%，用户文本约 7.9%。在工具结果内部，Read 是最大来源：它占全部工具输出字节的约 75%。这说明在代码 Agent 工作负载中，文件读取结果是上下文膨胀的核心对象。
论文还定义了 amplification factor：一个工具结果产生后，会在后续多少回合中持续留在上下文并被反复处理。主会话的中位放大因子为 84.4x，P75 为 217.9x，P90 为 570.8x。也就是说，一个早期读入的文件结果可能被重复处理几十到几百次。
另一个重要数字是输入输出比例。平均每次 API call 处理 82,061 个有效输入 token，只生成 88 个输出 token，输入输出比约为 933:1。这个工作负载是极端 input-bound 的。
6.2 API 级 waste taxonomy
在 5 个 proxy-captured sessions、99 次 API call、24.4 MB 请求数据上，论文将可处理浪费分为四类：
| 类别 | 请求字节占比 | 机制 |
|---|---|---|
| Dead tool output | 26.5% | 旧工具结果长期留存但不再被引用 |
| Tool definition stubs | 20.2% | 未使用工具的完整 schema 每次都发送 |
| Static re-send | 11.0% | 系统提示词、项目说明等静态内容重复发送 |
| Skill triplication | 2.9% | 同一技能列表以不同前缀注入多次 |
| 合计 | 60.5% | 可通过结构性机制处理的请求字节 |
这个 60.5% 是小样本 API payload 层面的字节占比，不等于整份 corpus 的 token savings。论文随后用更大样本中的 bytes-to-token 常数做 corpus-scale projection。
6.3 Corpus 级节省估计
论文用 139 个 proxy-captured API calls 估计 bytes-to-token 比例，再投影到 857-session corpus。结果如下：
| 干预 | 预计节省 token | 输入 token 占比 |
|---|---|---|
| Tool stub trimming | 487.5M | 11.0% |
| Skill deduplication | 95.8M | 2.2% |
| Static re-send | 387.0M | 8.7% |
| 合计 | 970.4M | 21.8% |
因此，论文的 headline 结论是：在该 corpus 中，有约 21.8% 的有效输入 token 属于结构性可处理浪费。
6.4 离线 replay 的 eviction safety
论文用 29 个 proxy-captured sessions 做 offline replay，模拟 eviction 决策而不真正调用模型：
| 指标 | 数值 |
|---|---|
| 模拟 eviction 次数 | 1,393,000 |
| 检测到 page fault | 354 |
| fault rate | 0.0254% |
| 被移出的内容总量 | 8.49 GB |
这个结果说明，在离线 replay 的访问模式下，超过 4 个用户回合且大于 500 字节的旧 Read 内容几乎不会被再次需要。论文认为 fault rate 不必为 0；少量 fault 是可接受的，因为保留所有页面的累计成本更高。
6.5 Live treatment 对照
在标准任务上，三种 treatment 的有效输入 token 如下：
| 指标 | Baseline | Trimmed | Compact+Trim |
|---|---|---|---|
| API calls | 3 | 4 | 3 |
| Effective input tokens | 114,222 | 88,421 | 71,816 |
| Cache read tokens | 79,712 | 38,639 | 32,228 |
| 任务是否正确完成 | 是 | 是 | 是 |
| token reduction | - | 22.6% | 37.1% |
在这个小规模 live 对照中，Compact+Trim 相比 baseline 减少了 37.1% 的有效输入 token，同时任务仍然完成。
6.6 生产部署中的两种状态：steady-state 与 thrashing
论文报告了两个生产会话。
Session A：稳定编码场景
| 指标 | 数值 |
|---|---|
| compact 前剩余上下文 | 7% |
| compact 后剩余上下文 | 43% |
| 总 eviction | 15 |
| garbage collected | 11 |
| Read eviction | 4 |
| page faults | 1 |
这个例子说明，在常规编码任务中，Pichay 能显著恢复上下文容量。唯一 fault 来自一个计划文件：它在年龄上变旧，但实际上仍是整个会话的参考材料，说明简单 FIFO 无法识别某些长期热页面。
Session B：长时间多 Agent 协调场景
| 指标 | 数值 |
|---|---|
| turns | 681 |
| 总 eviction | 680 |
| Read eviction | 606 |
| page faults | 659 |
| 总体 fault rate | 97% |
| 峰值压缩 | 5,038KB -> 339KB |
| 会话终止原因 | API rate limit |
这个结果不是成功案例，而是 thrashing 病理案例：系统几乎把所有内容都移出，模型又几乎把它们重新请求回来。论文把它解释为经典 working set failure：当当前任务的工作集大于系统允许常驻的集合时，系统会把大量预算消耗在换入换出上，而不是完成有效工作。
7. 设计分析：为什么 LLM 上下文分页和传统虚拟内存不同？
7.1 成本模型是反过来的
传统虚拟内存中，把页面留在 RAM 中通常没有额外运行时成本；主要成本来自 page fault 的磁盘 I/O。因此传统 replacement policy 通常以减少 fault 为目标。
LLM 上下文管理中，成本模型相反：一个 token 只要留在上下文中，就会在后续每一轮持续产生处理成本和注意力压力。如果一个 5,000-token 文件在上下文中停留 20 轮，它会带来约 100,000 token-turn 的累计成本；如果把它移出，需要时重新读一次，可能只付出一次 5,000-token 级别的恢复成本。
论文用如下形式表达总成本：
min sum_p (C_keep(p) + C_fault(p))C_keep(p) = |p| * T_resident(p) * c_token
C_fault(p) = |p| * c_token
在简化线性模型下，如果页面超过一轮不会被引用，就倾向于移出。这解释了为什么简单 FIFO 在很多场景下表现不错：LLM 中“保留”本身很贵。
7.2 但 fault 成本并不总是线性的
论文随后指出，真实 fault 成本更复杂。模型重新请求内容通常需要额外一次 inference pass，而长上下文中的 self-attention 成本与当前上下文长度有关。当上下文已经很大时，再触发 fault 会非常昂贵。
这带来一个反直觉结论：
- 在低填充状态下，fault 相对便宜，可以更激进地 eviction；
- 在高填充状态下，额外一次完整 inference pass 很贵，策略反而应当更保守；
- 页面大小不同，keep cost 和 fault cost 也不同，策略应当 size-aware；
- 永久 pin 也不理想，pin 应当随时间衰减，否则长会话中的工作集只会单调增长。
7.3 结构性修改会破坏 prompt cache
会话 collapse 或大规模重写消息数组会改变 prompt prefix，可能导致 prompt cache miss。论文报告一次 collapse 让 cache hit rate 从 100% 降到 25%，下一轮才恢复。这意味着小而频繁的结构性修改可能得不偿失，较好的做法是批量处理、摊销 cache invalidation 成本。
8. 与相关工作的关系
论文把 Pichay 放在几类相关工作之间：
| 方向 | 代表方法 | 与本文区别 |
|---|---|---|
| Prompt compression | LLMLingua 等 | 压缩 token 内容，通常是有损和模型相关；本文主要移除结构性浪费 |
| Agent context pruning | SWE-Pruner、ACON 等 | 多从 benchmark 上优化 prompt；本文强调生产 waste profile、fault rate 和 working set |
| Prompt-level memory | MemGPT | MemGPT 已提出 OS 类比和多层记忆；本文更强调 proxy 层分页、故障检测和生产数据测量 |
| KV cache 管理 | PagedAttention / vLLM | 管理推理服务中的 KV cache；本文管理的是发送给模型的上下文内容本身 |
| Context engineering | Anthropic 工程实践、context engineering survey | 本文提供一个具体系统机制和实测数据 |
可以看到，本文并不是简单说“压缩上下文”，而是把问题重新表述为 working set management：哪些内容当前必须以完整形式常驻 L1，哪些可以用句柄或摘要驻留，哪些只需要在外部存储中可恢复。
9. 质量评估与局限性
9.1 非劣性质量检查
论文用 18 个 sessions 做 paired check：baseline 保留全部消息，treatment 把 20-message recency window 外已经消费的工具结果替换成 tombstone。之后用相同 continuation prompt 生成输出，并由三个 LLM judge 评价。
| 指标 | Baseline | Treatment |
|---|---|---|
| judge preference | 28% | 37% |
| ties | 35% | 35% |
| mean correctness | 3.89 | 3.74 |
| mean completeness | 3.59 | 3.59 |
| mean coherence | 3.74 | 3.69 |
| reduced-context detection rate | 57% | p = 0.14，未显著高于随机 |
这个结果说明，在该小样本设置中，压缩后的上下文没有明显质量崩坏；但 correctness 和 coherence 略低，且存在两个 treatment 输出退化为空字符串的失败案例。失败模式是：用户后续 prompt 隐式引用了某个已 tombstone 的工具结果内容，而模型无法从短句柄中恢复足够语义。
9.2 局限性
论文自己指出了多项局限：
- 单用户 corpus：数据来自一个重度用户和 Claude Code 工作流，不能直接代表所有用户和所有 Agent。
- 主要评估 L1/L2：L3 的 model-initiated conversation compaction 已实现，但尚未大规模评估。
- 基础 eviction policy 很简单：FIFO 年龄阈值在稳定场景可用，但在长时间多 Agent 场景中会 thrashing。
- 质量评估样本有限：18 个 sessions、54 个 judge verdicts 只能提供初步证据。
- prompt cache 影响复杂：结构性压缩会改变前缀并引起 cache invalidation，需要更细致的成本模型。
- 元信息存在不一致：PDF 模板信息与 arXiv 预印本状态不一致；摘要页面与 PDF 正文对总 token 量也存在口径差异。
10. 论文给出的未来方向
论文提出了几个后续方向：
| 方向 | 核心问题 |
|---|---|
| L3 评估 | 模型主动 collapse 会话历史能恢复多少上下文？对质量有什么影响？ |
| Cost-aware eviction | 不只看空间压力，而看 token-turn 成本和预计未来引用 |
| Cost-weighted pin decay | fault 后不应永久 pin，pin 强度应随时间和成本压力衰减 |
| Phase-aware eviction | 规划、执行、调试阶段工作集不同，策略应按阶段调整 |
| Per-connection isolation | 当前单一 PageStore 可能让 subagent 与主会话污染彼此状态 |
| Trace-driven simulation | 用真实访问序列离线比较 replacement policy |
| Cross-session prediction | 从跨会话访问模式预测文件再次被引用的概率 |
| Object-addressed memory | 不只按文件路径分页，而按语义对象、决策、调试阶段等管理记忆 |
其中最重要的延伸是从 block-addressed paging 走向 object-addressed memory。对 LLM 来说，自然的页面不一定是固定大小字节块，而可能是一个设计决策、一段调试过程、一个会话阶段或一个语义对象。这样的对象可以有不同保真度：完整内容、结构化摘要、关键词 bookmark、可查询外部记录等。
11. 总结
这篇论文的中心贡献是把 LLM Agent 的上下文膨胀问题系统化为一个内存层次结构问题。它不是只说“上下文太长”，而是提出了更具体的工程抽象：
- 上下文窗口是 L1 cache，不是完整内存；
- 旧工具结果、未使用工具 schema、重复静态内容会造成结构性 token 浪费；
- 可寻址内容可以用 retrieval handle 移出上下文，需要时再 fault 回来；
- fault history 可以用来识别工作集并 pin 热页面；
- LLM 可以通过 phantom tools 和 cleanup tags 主动参与内存管理；
- 长会话需要 L1/L2/L3/L4 的完整层次，而不是单一大上下文窗口。
实验上，论文在一个 857-session 的生产 corpus 上报告 21.8% 的结构性有效输入 token 浪费；在离线 replay 中，简单 FIFO paging 的 fault rate 为 0.0254%；在 live treatment 中，Compact+Trim 相比 baseline 减少 37.1% 有效输入 token。与此同时，生产部署也暴露了 thrashing：如果当前工作集超过 resident set，系统会频繁换出换入，甚至比保留内容更消耗 API rate budget。
因此，本文的结论不是“简单 FIFO 就足够”，而是：LLM 上下文管理应从 prompt 压缩问题升级为内存系统问题。扩大上下文窗口可以提高 L1 容量，但真正可扩展的系统还需要分页、工作集估计、成本感知 eviction、会话压缩和跨会话持久记忆。
参考
- Tony Mason. The Missing Memory Hierarchy: Demand Paging for LLM Context Windows. arXiv:2603.09023v1, 2026. https://arxiv.org/abs/2603.09023
- Peter J. Denning. The working set model for program behavior. Communications of the ACM, 1968.
- Peter J. Denning. Virtual memory. ACM Computing Surveys, 1970.
- Charles Packer et al. MemGPT: Towards LLMs as Operating Systems. arXiv:2310.08560, 2024.
- Woosuk Kwon et al. Efficient Memory Management for Large Language Model Serving with PagedAttention. arXiv:2309.06180, 2023.