# Unlimited Context LLM：为本地大模型提供十亿级Token记忆的虚拟内存方案

> Unlimited Context LLM通过虚拟内存机制突破本地LLM的上下文窗口限制，让8B参数模型能够访问数十亿Token的编码记忆池，实现真正的长程连贯推理。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-06-03T12:46:24.000Z
- 最近活动: 2026-06-03T12:49:37.095Z
- 热度: 161.9
- 关键词: LLM, Ollama, 上下文窗口, 虚拟内存, 本地部署, RAG, 长文本处理, AI代理, 开源工具
- 页面链接: https://www.zingnex.cn/forum/thread/unlimited-context-llm-token
- Canonical: https://www.zingnex.cn/forum/thread/unlimited-context-llm-token
- Markdown 来源: ingested_event

---

## 原作者与来源

- 原作者/维护者：DBarr3
- 来源平台：GitHub
- 原始标题：Unlimited-Context-LLM
- 原始链接：https://github.com/DBarr3/Unlimited-Context-LLM
- 来源发布时间/更新时间：2026-06-03T12:46:24Z

---

## 引言：上下文窗口的硬边界

任何使用过AI编程助手或长文本处理工具的人，都遇到过那个令人沮丧的时刻——模型突然"失忆"了。它开始重复自己已经写过的代码，忘记三分钟前提到的关键需求，或者在长对话中逐渐偏离主题。这不是模型的错，而是上下文窗口的物理限制。

即使是最先进的模型，128K的上下文窗口在复杂的多步骤任务面前也显得捉襟见肘。当窗口填满时，模型被迫压缩自己的历史记录，那些"不重要"的细节被默默丢弃——而往往正是这些细节决定了任务的成败。更大的窗口只是延缓了问题的发生， stuffed 的百万级窗口同样会在中间部分丢失信息。

## 核心创新：编码而非压缩

Unlimited Context LLM提出了一种全新的思路：与其压缩溢出的内容，不如将其编码并外部化。这个开源项目为Ollama本地模型提供了一个"虚拟内存"层，让模型能够访问存储在磁盘上的海量编码记忆。

### 技术架构类比

项目巧妙地将操作系统虚拟内存的概念迁移到了LLM的注意力机制中：

| 操作系统概念 | Unlimited Context 对应实现 |
|---|---|
| RAM（物理内存） | **Resident Window** — 模型当前可见的小型快速上下文窗口 |
| 磁盘存储 | **Context Pool** — 约5GB存储约11.6亿Token的编码记忆池 |
| 页面调度器 | **Slice Loader** — 根据模型当前推理内容预取相关切片 |
| 页面替换算法 | **Witnesses (+/−)** — 重要切片硬化保留，过时切片逐渐淡化，相关切片可重新激活 |

这种设计的精妙之处在于：所有操作都与模型生成过程并发执行，隐藏在模型的思考时间之后，因此访问记忆池不会增加额外的等待时间。

## 记忆池的规模与实用性

项目提供了直观的存储规模选择器，用户可以根据需求配置不同的记忆池大小：

| 存储池大小 | 编码可达Token数 | 典型应用场景 |
|:---:|:---:|:---|
| 5 GB | ~11.6亿 | 单个大型项目（最低配置） |
| 10 GB | ~23.3亿 | 大型单体仓库+文档 |
| 15 GB | ~34.9亿 | 多仓库/长时间运行任务 |
| 20 GB | ~46.5亿 | 海量语料库/重度用户 |

### 实际编码时间的估算

真正令人印象深刻的是这些数字背后的实际意义。假设一个活跃的编程代理每小时编码30万到100万个值得保留的Token，5GB的记忆池可以支持约1200到3900小时的连续工作——相当于数周不间断的构建时间。

为了更直观地理解：5GB的存储空间约等于1亿行代码，或者8000本书的容量。这意味着在单次会话中几乎不可能填满它。

## 多会话与内存管理

项目提供了两种池共享模式，适应不同的使用场景：

### Shared Pool 模式

- **机制**：所有会话共享同一个池和索引
- **内存开销**：每增加一个会话仅增加约30MB RAM
- **适用场景**：相关项目工作、最大化小机器上的并发
- **权衡**：会话间无隔离，彼此可见对方的上下文

### Separate Pool 模式（默认）

- **机制**：每个会话拥有独立的池和索引
- **内存开销**：每个会话都需要支付完整的索引成本
- **适用场景**：不相关的任务、需要隔离的场景
- **权衡**：RAM随会话数量线性增长

### 实际并发能力

基于8GB和16GB内存配置，不同存储池大小下的实际会话承载能力：

| 存储池 | 8GB内存·Shared | 8GB内存·Separate | 16GB内存·Shared | 16GB内存·Separate |
|:---:|:---:|:---:|:---:|:---:|:---:|
| 5 GB | 数十个 | ~13个 | 数十个 | ~33个 |
| 10 GB | 数十个 | ~7个 | 数十个 | ~18个 |
| 15 GB | 数十个 | ~4个 | 数十个 | ~12个 |
| 20 GB | 数十个 | ~3个 | 数十个 | ~9个 |

## RAM 占用的精确计算

与传统的向量数据库不同，Unlimited Context LLM将向量存储在磁盘上（通过mmap映射），只有小型HNSW索引图和热工作集会常驻内存。这使得RAM占用可以精确预测：

```
RAM ≈ ~180 MB（引擎+共享静态编码器）
    + ~29 MB × 存储池GB数（常驻索引）
    + ~30 MB × 活跃会话数
```

不同存储池大小的索引RAM占用：

| 存储池 | 索引RAM（常驻） |
|:---:|:---:|
| 5 GB | ~146 MB |
| 10 GB | ~291 MB |
| 15 GB | ~436 MB |
| 20 GB | ~582 MB |

编码器是共享的无状态组件（约31MB），只加载一次。这种设计确保了即使在大规模存储池配置下，系统的内存占用仍然保持合理。

## 技术实现细节

项目的核心技术指标基于以下计算：每个切片约2.2KB（包含256维向量+压缩文本+元数据），每512个Token编码为一个切片。这意味着每GB存储约45.5万个切片，提供约2.33亿Token的访问能力。

### 关键特性总结

- **无界访问**：约11.6亿Token的编码记忆，模型通过切片访问
- **零延迟增加**：分页器与生成过程并发运行，不增加等待时间
- **精选优于堆砌**：小型相关常驻窗口优于 stuffed 的大型窗口
- **本地优先**：上下文数据永不离开本机，完全离线可用
- **模型无关**：支持Llama、Qwen、Mistral、Phi等通过Ollama运行
- **可测量的连贯性**：提供对比测试，展示开启/关闭引擎时的漂移率差异

## 安装与使用

项目通过PyPI分发，安装简单：

```bash
pip install aether-context
```

首次运行会引导用户选择存储池大小，之后即可通过命令行与本地Ollama模型交互，享受扩展的上下文记忆能力。

## 意义与展望

Unlimited Context LLM代表了本地AI部署的一个重要突破。它证明了通过巧妙的系统架构设计，可以在消费级硬件上实现接近无限的上下文记忆，而不需要依赖云端API或昂贵的专业硬件。

对于开发者和研究人员来说，这意味着可以在完全私密的环境中运行长程连贯的AI任务——无论是深度代码重构、长篇文档分析，还是复杂的多步骤研究工作流。

更重要的是，这种"虚拟内存"的思路可能被应用到更广泛的AI系统中，为上下文管理提供一种全新的范式。