把 6.7 万个词的文档库塞进大模型，最后只占 16 个 token 的位置，准确率还能反超全量上下文。斯坦福大学 Jure Leskovec 领衔的 SNAP 团队联合多伦多大学、宾夕法尼亚大学和 MIT，以 Apache 2.0 协议开源了潜在语义记忆系统 Memorilla，并同步放出包含 149 名合成用户、每人 200 段对话的 PersonalizationV4 数据集。这套系统用一个约 1.94 亿参数的可训练记忆模块，把任意规模的外部文档动态压成 16 个软记忆 token，直接注入冻结的 Qwen3-8B 输入层。它确实绕开了长上下文的算力墙，但翻开论文附录和代码库就会发现，前端省下的每一分账单，都在后台换成了显存开销、监督微调红利和白盒权重的硬绑定。
先看这套系统的基本盘。Memorilla 的流水线分三步，底层文档先由冻结的 Qwen3-Embedding-4B 单次编码成向量，新增文档无需重算旧数据；提问时，由 2 层 8 头交叉注意力组成的记忆模块带着问题去全量向量库里读取信息，生成 16 个连续向量；最后把这 16 个软 token 投影并拼接到 Qwen3-8B 的输入 Embedding 层。在 4 张 H100 80GB GPU 上跑完约 19 小时三阶段训练后，它在 8 个基准测试中拿到 5 项第一，平均分 49.68。在 FactKG 上，它用 108 倍的文档 token 压缩率跑出 84.33% 准确率，反超全量上下文的 80.43%；在 NarrativeQA 上更是用 16 个 token 替代了 67,385 个文档 token，实现 4,212 倍压缩。
跑分通杀背后的特训红利
只看主表分数，Memorilla 几乎把 Mem0（38.02）、LLMLingua-2（40.75）、xRAG（41.92）和 MemoRAG（47.52）轮流打了一遍。大模型处理外部知识，过去要么硬撑上下文窗口，要么像 RAG 和 Mem0 那样切碎文本再拼接，但容易漏掉跨文档的弱线索。Memorilla 走的是潜在记忆路线，让模型自己学会从全局向量里挑线索。
| 记忆方案 | 核心机制 | 每次查询文档 Token | FactKG 准确率 | PersonaMem-v2 | 8 项基准均分 |
|---|---|---|---|---|---|
| Memorilla | 潜在软记忆注入 | 16 | 84.33% | 44.60% | 49.68 |
| MemoRAG | 记忆模型引导检索 | 784 | 80.38% | 28.76% | 47.52 |
| xRAG | 单 Token 投影压缩 | 1 | 78.98% | 30.90% | 41.92 |
| Mem0 | 提取外部文本记忆 | 212 | 72.79% | 27.48% | 38.02 |
但我不太买账的是这场比武的起跑线。Memorilla 的三阶段训练里，前两阶段用了约 332 万条样本做预训练（分别耗时 6 小时和 4 小时），到了长达 9 小时的第三阶段，它直接把全部 8 个评测基准的训练集混在一起做了联合微调；在 PersonaMem-v2 和 PersonalizationV4 两个个性化榜单上，还各花约 25 分钟额外微调了 5 个 epoch。反观同台竞技的 Mem0 和 MemoRAG，用的是完全冻结的记忆写入模型，零微调直接上场裸考；作者重实现的 xRAG 也只训了 2700 万参数的桥接器。
用特训过的 1.94 亿参数去打零微调的通用基线，赢下比赛并不意外，只是读者很难分清这 49.68 的平均分里，究竟有几成归功于潜在记忆架构，又有几成来自下游训练集的监督信号。更何况在仅 324 个 token 摘要、总共 100 条测试样本的 PubMedQA 上，Memorilla 只拿到 59.00%，落后 LLMLingua-2 整整 10 个百分点，潜在空间压缩天然容易弄丢精确人名和细粒度字面信息的短板，在这里暴露得很彻底。截至 2026 年 11 月 14 日，开源仓库的 Issue #11 还在提醒，官方提供的基准运行器里依然缺失复现 Mem0、MemoRAG 和 xRAG 的对比脚本。
16 个 Token 只是门票，不是总账单
解码器端省下的每一分算力，都在后台换成了显存和预计算账单。
再看工程团队最关心的速度与成本。论文宣称在单张 H100 上处理 512 篇文档（约 128K token）时，Memorilla 端到端响应只要 0.74 秒，比全上下文的 19.9 秒 快 27 倍；换到单张 B200 GPU 上配合预计算缓存，检索 100 万篇文档只要 8.06 毫秒（开启 torch.compile 降至 5.0 毫秒），400 万篇文档也只需 32.8 毫秒。
天下没有白吃的午餐，韩非子早讲过「冰炭不同器」，极致的轻量与全局的无损本就难以兼得。翻到论文附录 F 就会看到，那个慢达 19.9 秒的全上下文靶子，是在关闭了工业界标配的 Paged KV Cache、用原生 Hugging Face Transformers 硬跑 128,064 个 token（开启 YaRN factor 4）且最多只生成 32 个新 token 的极端设定下测出来的，甚至没有把常规 RAG 基线拉进来一起计时。至于 B200 上惊艳的百万级文档毫秒级响应，测试用的其实是随机生成的 Embedding，且只掐表算了 2 层交叉注意力模块本身的耗时，压根没算编码器和 Qwen3-8B 生成答案的时间。更关键的是，要把 400 万篇文档的读取延迟从 282.7 毫秒压到 32.8 毫秒，必须预计算交叉注意力的 KV 缓存，而这份缓存体积是原始向量存储的 4 倍，单这一项就要吃掉 80 GiB 显存。
这其实和早年数据库做内存索引是一笔同样的账，查询看着像零成本，是因为有人提前替你买了昂贵的内存条。
- 风险.由于软 token 必须绕过词表、直接写进模型的输入 Embedding 层，这套方案天然与 GPT-4 或 Claude 等闭源黑盒 API 绝缘，且每个记忆模块都和训练时绑定的特定解码器锁死，哪怕你只是想把底座从 Qwen3-8B 换成别家模型，甚至升级同家族的新版本，都得重新准备 4 张 H100 跑完 19 小时的绑定训练。
所以短期内，Mem0 这类基于纯文本的记忆工具链根本不用慌，只要企业还在调闭源 API、只要业务场景还不能容忍人名和精确数字的丢失，文本检索就依然是刚需。Memorilla 真正打开的口子，是给那些手握自有开源模型权重、需要高频吞吐海量背景文档的团队提供了一条新路——用训练一个不到 2 亿参数的微型交叉注意力读取器，去替代动辄十几万 token 的上下文拼接。至于这条路能不能走成通用标准，先看社区把 vLLM 的 Paged KV Cache 打开之后，那 27 倍的端到端加速还能剩下多少，以及在完全没微调过的陌生任务上，这 16 个软 token 到底能记住几成真东西。