面向面试的体系化梳理：短期记忆 / 长期记忆 / 上下文压缩 / KV Cache 优化 / 前沿架构
2026年7月 · 综合 20+ 篇权威来源深度整理

---

一、问题的本质：为什么 100 万 Context 是伪命题

面试官真正想问的

当面试官说"你们怎么处理 100w token 的上下文"，表面上是问技术方案，实际上他考察的是五个维度的工程判断力：

隐藏问题	考察维度	你不会被问但必须知道
上下文满了怎么办？	短期记忆 / 上下文工程	不是所有消息都值得保留
用户第二天回来还记得吗？	长期记忆 / 跨会话持久化	记忆的本质是"压缩"而不是"存储"
token 成本和延迟怎么控制？	压缩 / KV Cache / RAG	100w token 单次推理可能烧掉几块钱
模型真的能"注意"到所有内容吗？	Lost in the Middle / 注意力衰减	窗口再大，模型也只看首尾
生产环境怎么权衡？	架构设计 / 工程权衡	没有银弹，只有 trade-off

你需要向面试官证明的，不是你读过多少论文，而是你能区分"什么场景用什么方案"，而且能说清楚为什么。

Lost in the Middle——大模型看不见中间

这是 2023 年 Liu 等人发现的现象，至今仍然是长上下文领域引用率最高的研究之一。实验方法非常简单：在 5000 词的文档中，随机位置插入一句关键信息（"The pass phrase is igloo"），然后问模型"pass phrase 是什么？"。把这个问题重复几千次，统计不同位置上的准确率，结果令人震惊：

准确率是一条完美的 U 型曲线。开头 0-20% 位置准确率高达 95%+（首因效应），结尾 80-100% 位置准确率最高达到 98%+（近因效应，因为自回归生成时最后的 token 对下一个 token 影响力最强），而中间 40-60% 位置准确率暴跌至不足 50%。

这不是某个模型的 bug，而是 Transformer 自回归架构的系统性缺陷。三个根因层层递进：第一，训练数据偏差——人类写作天然首尾重要、中间过渡，模型在预训练阶段就学到了这种分布；第二，自回归机制——每生成一个 token，刚刚生成的 token 影响力最大，开头的 token 影响力次之（因为被反复"复习"过），中间的就一直处于注意力盲区；第三，注意力稀释——Softmax 将注意力分数分配在序列的所有 token 上，序列越长，每个 token 分到的注意力比例就越小，中间位置的信号被彻底淹没。

有意思的是，这个效应在 RAG 场景下尤其致命。如果你检索了 20 篇文档拼接成上下文，按相关性排序放进去，排名第 8-12 的文档几乎等于白送。这就是为什么文档重排序（最相关的放首尾）能显著提升 RAG 效果——不是检索更准了，而是避开了大模型的盲区。

验证这个现象的标准工具是 Needle In A Haystack (NIAH) 测试——在长文档的不同深度插入事实，让模型回答，绘制一张"深度 x 上下文长度"的热力图。面试时如果你能说出 NIAH 这个缩写，面试官就知道你做过功课。

三重绞杀：不只记不住，还贵且慢

就算你的模型有 1M 的上下文窗口，生产环境还要面对两重额外打击：

首先是 KV Cache 内存爆炸。以 LLaMA-3 70B FP16 为例，8K 序列时 KV Cache 只占 2.5GB，还不到模型权重的 2%——你几乎感觉不到。但 128K 时就涨到 40GB，占 23.5%，一张 A100 已经有点紧张。到 1M 时，KV Cache 膨胀到 330GB，是模型权重的 2.5 倍——这意味着为了服务一个请求，你需要分配相当于权重两倍半的显存给 KV Cache。这是任何单卡都吃不消的。

其次，注意力计算是 O(n²) 的。虽然 FlashAttention 系列算法通过分块计算和重计算策略把显存 IO 降到了 O(n)，但计算量本身并不减少。64K 序列的 Attention 计算还能接受，1M 序列就会变成一场等待噩梦——首字延迟（TTFT）会达到几十秒甚至几分钟，用户早就走了。

所以结论很明确：暴力扩展上下文窗口是工程师的懒惰，不是工程师的智慧。 真正的方案必须从记忆架构、压缩算法、KV 优化、部署策略等多个层面组合出拳。

---

二、短期记忆：会话级上下文工程

短期记忆就是当前会话中已经发生的历史消息。它们直接参与模型推理，也直接受 maxToken 限制。当用户和你聊了一小时，消息累积到 80K token——你的模型窗口只有 128K，怎么办？

不能简单截断。因为你不知道用户下一句话会不会突然引用 20 分钟前说的某个细节。上下文工程要做的，就是在这 80K 消息里，选出最有价值的 30K 放进下次推理的 prompt 里。

三大策略：缩减、卸载、隔离

这三个策略不是互斥的，实践中往往是组合使用。

上下文缩减 (Reduction) 是信息有损的。比如对于一段 20K token 工具调用结果，你只保留前 500 个字符作为预览（保留预览），或者让一个小模型把它总结成 200 字（总结摘要）。两种方式都会丢信息，但能大幅降低 token 消耗。什么时候可以接受信息丢失？答案是"用户大概率不会追问细节"的内容——比如搜索引擎返回的摘要、冗长的日志输出、中间计算步骤等。

上下文卸载 (Offloading) 是信息无损的。你把完整的原始内容存到外部存储（文件系统、OSS、Redis），消息体中只留一个引用标识（文件路径、UUID）。不需要的时候它不占 token，需要的时候可以通过引用重新加载。这个策略最适合"短时间内容巨大但使用频率低"的数据——网页搜索结果、超长工具输出、临时生成的计划文档等。核心 trade-off：省了上下文，但多了一次 IO 延迟。

上下文隔离 (Isolation) 是一种架构策略。主 Agent 不自己处理一切，而是把独立子任务派发给子 Agent——子 Agent 的上下文只有这个子任务的指令和相关信息，干完活后只把结果返回给主 Agent。主 Agent 完全不关心子 Agent 的执行过程。这很像微服务架构的单体拆分：主服务只知道"调用订单服务"并拿到结果，不了解订单服务的内部实现。代码库搜索、文档分析、数据清洗都是典型的隔离场景。

选择哪个策略取决于三个维度：时间远近（近期消息优先保留）、数据类型（用户输入 > 模型回复 > 系统指令 > 工具输出）、信息可恢复性（能否无损恢复）。把这三维画成决策矩阵，比凭感觉裁剪靠谱得多。

递归摘要：压缩的本质是"遗忘的艺术"

递归摘要的原理出奇地朴素——用一个 FIFO 队列存储最近的消息，当队列满了，不是把老消息删掉，而是让 LLM 生成一个摘要，然后把这个摘要塞回队列的第一位。下次队列又满了，就基于上次的摘要继续生成新摘要。一次复一次，形成一棵信息压缩树。

MemGPT 对这套机制做了优雅的工程化：当 prompt token 达到上下文窗口 70% 时，系统自动在队列里插入一条"内存压力警告"——不是立刻驱逐，而是给 LLM 一个预警，告诉它"你的上下文快满了，赶紧把重要的东西通过函数调用存到外部存储"。如果模型不理，100% 时就强制动手：踢掉一半消息，生成新的递归摘要。这比操作系统的 LRU 策略聪明得多——模型可以自己决定"这段关于用户健康状况的信息比那三回合的闲聊更重要，我应该先存它"。

但递归摘要不是免费的午餐。每一层压缩都是一次信息瓶颈——细节会丢，时间线会模糊，情感色彩会流失。短期聊天的逐字记录里，"用户说他不喜欢吃香菜"和"用户说他不喜欢香菜搭配牛肉"是两条粒度不同的信息，摘要之后可能只剩"用户不喜欢香菜"——丢掉了一个关键限制条件。所以递归摘要只适合"保持对话的连贯感和话题方向"，而不适合"需要精确回忆特定细节"的场景。

各框架的实现差异

Google ADK 的做法最直接——通过 EventsCompactionConfig 配置一个 compaction_interval（每 N 次新调用触发压缩）和 overlap_size（和前一个压缩窗口的重叠数量）。本质是一个带重叠的滑动窗口摘要，参数少、上手快，但策略粒度粗。

LangChain 通过 SummarizationMiddleware 中间件实现，可以指定触发阈值（max_tokens_before_summary）和保留策略（messages_to_keep）。它和消息存储是解耦的——中间件独立运行，不污染消息历史本身。

AgentScope 的 AutoContextMemory 是最精细的。它直接实现了 Memory 接口，当对话历史超过配置阈值时，自动应用 6 种渐进式压缩策略——不是一步到位，而是从轻到重逐级加码：

1. 压缩历史工具调用结果（去掉中间输出，只留结果）
2. 卸载大型消息到外部存储（无损，降低 prompt 体积）
3. 摘要对话轮次（有损，用 LLM 做语义压缩）
4. 移除重复系统指令（system prompt 不需要每次都在）
5. 合并连续同角色消息（"你好" + "今天天气真好" 合并为一条）
6. 激进截断 + 摘要（最终手段）

这个分层思路的精妙之处在于：第 1-2 步几乎不丢信息，第 3-4 步丢的是冗余信息，只有到第 5-6 步才伤筋动骨。大部分对话根本不会走到后面几步。

---

三、长期记忆：跨会话知识沉淀

长期记忆解决的不是"这一轮对话聊了什么"，而是"三个月前用户说过什么、偏好什么、经历过什么"。

短期记忆和长期记忆的分工

这个分工在认知科学里有明确的对应——人类大脑的海马体负责短期记忆编码，皮层负责长期记忆巩固。AI Agent 的记忆系统也遵循同样的原则：短期记忆存的是"原始对话流"，长期记忆存的是"从中抽象出的结构化知识"。

每个会话结束后，系统走一遍 Record 流程：LLM 从对话流中提取有效信息（事实、偏好、经验、关系），向量化后存到 VectorDB，实体关系存到 GraphDB，所有操作记入 SQLite 审计日志。当用户开始新的会话，系统走 Retrieve 流程：把当前 query 向量化，在 VectorDB 里做语义检索 Top-K，如果有图关系再补充，经过 Reranker 重排序后，把最相关的记忆注入当前对话的上下文。

这里有一个容易被忽视但非常重要的设计细节：Record 的触发时机。 每句话都触发的代价太高（LLM 调用次数 = 对话轮次），太稀疏又会丢信息。生产环境通常的做法是"会话结束时批量处理 + 检测到重要信息时实时触发"的混合策略。"重要信息"可以是一组简单的关键词规则（"我的名字是"、"我住在"、"我的手机号是"），也可以是让小模型快速判断是否需要记录。

长期记忆 vs RAG：信息来源决定一切

很多人搞混这两个概念。长期记忆和 RAG 在底层技术栈上高度相似——都涉及向量化、向量数据库、语义检索——但解决的问题完全不同。

RAG 的数据来源是外部知识库（公司文档、产品说明、FAQ），内容是静态的、面向领域的、批量索引的。长期记忆的数据来源是用户交互历史，内容是动态的、面向个人的、实时流式更新的。RAG 回答"公司的退货政策是什么"，长期记忆回答"用户上次退货时遇到了什么问题、他偏好什么沟通方式"。

一个个人助手系统里，RAG 和长期记忆是并行的。用户问"我的订单到哪了"，RAG 先拉出物流政策，长期记忆拉出"用户上次抱怨过快递慢"——系统就知道回复时加上一句"我了解您上次等了五天，这次预计三天到"。

记忆框架横评：2026 版

2026 年开源记忆框架生态已经很成熟，但选择并不简单。主流的五个框架在架构理念上走的是完全不同的路。

Mem0 的架构是极简主义——扁平 KV 存储 + 语义向量索引。LLM 从对话中抽取事实片段，向量化后存入数据库，检索时算余弦相似度。没有时序模型，没有层级归纳，没有实体关系图谱。但正因为它简单，5 分钟就能接入，延迟极低，API 设计清爽。入门首选，但做不到"用户三个月前说过什么"的跨时间推理。

Zep 的架构相反——它是情节记忆图谱，从对话中自动抽取实体、关系和事件构建图节点，每个节点打时间戳。当用户问"我从互联网行业跳槽到金融是什么时候"，Zep 不是在向量库里找相似文本，而是在图谱里沿"职业变化"这条边做图遍历。它有时序感知能力，但在超长时间跨度（以月记）下，图谱本身会变得庞大且混乱，缺少自动的层级归纳机制。

LangMem 是一个设计精巧的双层记忆系统——工作记忆（当前会话，详细但临时）+ 长期语义存储（跨会话，精简但持久）。它深度集成在 LangGraph 的状态管理中，记忆管理逻辑完全透明可控。但它的劣势也在于生态绑定——离开 LangChain 体系很难独立使用，长期记忆层本质上还是语义检索，时序能力有限。

MemOS 提出了"记忆操作系统"的概念。它是图谱结构 + 多模型支持 + MCP 集成的综合体，支持 Qwen3、SiliconFlow 等多种 embedding 模型，可以做复杂的实体关系推理。但部署复杂，macOS 兼容性存在问题，同样缺少自动层级归纳。

TiMem 是 2026 年新出的黑马，来自论文 arXiv:2601.02845。它的核心创新是时序记忆树（Temporal Memory Tree, TMT）——和 MemGPT 的内存分层思路不同，TiMem 是在时间维度上做自动层级归纳。底层 L1 存原始对话片段（毫秒级写入），L2 存会话摘要（对话结束后 LLM 自动归纳），L3 存每日总结（日维度），L4 存每周总结（周维度），L5 是用户画像（全生命周期）。每一层向上汇总时，信息密度递增，粒度递减。

这套架构的妙处在于复杂度感知召回——系统根据问题类型自动决定检索哪些层。问"上周说了什么"，只搜 L1/L2（低层 = 高精度）。问"这几个月有什么变化"，搜 L3/L4（中层 = 趋势）。问"这个用户整体画像是什么"，直接捞 L5（顶层 = 全局总结）。不会出现"问一个大方向你却返回了三周前某条具体消息"的尴尬。

在 LoCoMo（长对话记忆主流评测）和 LongMemEval-S（长期记忆检索质量评测）基准上，TiMem 分别达到 75.3% 和 76.88%，同时 token 消耗比 Mem0 基准节省了 52%。换句话说，它记得更准，花钱更少。

一句话选型：对话周期越长、时序需求越强 → TiMem；场景越简单、需要快速上线 → Mem0；LangChain 生态内 → LangMem；需要实体关系推理 → Zep。

---

四、上下文压缩：宁可少传，不可乱传

上下文压缩是 prompt 在进入 LLM 之前的"瘦身手术"。它解决的不是"什么是重要的"（那是记忆系统的事），而是"哪些词是废话"。

Hard Prompt 与 Soft Prompt：两条路

Hard Prompt 方法在自然语言层面做减法和改写，输出的还是人能读懂的文本。这让它可以和任何黑盒 LLM 配合——不需要修改模型、不需要权重访问，纯 prompt 操作。

Soft Prompt 方法则完全不同——它训练一个编码器，把长 prompt 压缩成一组特殊 embedding token，这些 token 对人来说是乱码，但解码器能从中恢复出原始信息。压缩比可以极高（500xCompressor 能做到 480×），但代价是编码器需要训练、和特定 LLM 绑定、更新 LLM 版本时编码器可能也需要重新训练。

LLMLingua 的粗到细三阶段

LLMLingua 是目前面试中最高频的 prompt 压缩方案，理解它对回答"你怎么减少 token 消耗"这类问题至关重要。

它的算法分三步走。第一步是预算控制——根据目标压缩比，计算每个模块（指令、上下文示例、问题）最多能保留多少 token。上下文示例占的空间最大，所以优先按困惑度（PPL）筛选——PPL 越低的示例越"典型"，越应该保留。

第二步是迭代 token 级压缩——用一个很小的语言模型（GPT-2 Small 即可，参数量约 1.5 亿），逐 token 计算困惑度。原理很简单：PPL 高 = 这个 token 在当前上下文中"出乎意料" = 信息量大 = 保留；PPL 低 = 这个 token"理所当然" = 冗余 = 删除。对于数字和单位这类"虽小但关键"的 token，LLMLingua 有专门的保留算法——你不会希望"体温 39.5 度"被压缩成"体温高"。

第三步是分布对齐——计算原始 prompt 和压缩后 prompt 在 LLM 输出上的 KL 散度，做最小化优化。确保压缩不会导致模型"答非所问"。

LLMLingua 能做到 20 倍压缩比，已经足够把 100K token 的 prompt 压到 5K。LongLLMLingua 在这个基础上加入了文档重排序（把最重要的文档排在首尾、次要放中间）和子序列恢复（长文档压缩后重组），在长上下文场景下效果更好。

SelectiveContext 的自信息量筛选

SelectiveContext 用的是一个更直观的指标——自信息量，也就是每个词在当前上下文中的"信息密度"。信息量低的词被标记为可删除。但直接删词会导致句子支离破碎，所以 SelectiveContext 用了 spaCy 的依存句法解析能力，把单个 token 按依存关系分组为名词短语——要删就整组删，保持语言连贯性。

它的最大优势是不带任何外部模型，不依赖 LLM 也不依赖额外参数，可以套在任何架构上。劣势是没法合并动词短语、依赖于 spaCy 的解析精度，而且过滤后的 prompt 还需要 LLM 重新编码——压缩只是省了 token 数，但没省掉 LLM 的编码开销。

Soft Prompt 阵营的精妙之处

GIST（要点 token）是最早引起广泛关注的 soft prompt 方案。它在原始 prompt token 后插入一组可训练的压缩 token，然后修改注意力掩码——压缩 token 可以关注原始 prompt 中的所有 token，但后续生成的新 token 只能关注压缩 token 而不能直接看原始 prompt。这实际上是一个编解码器架构：原始 prompt → 压缩 token（编码）→ 生成（解码）。26 倍的压缩比在一系列任务上保持了接近原始 prompt 的效果。

500xCompressor 更激进——它不是把压缩后的 embedding 喂给解码器，而是直接把压缩 token 的 KV 值传过去。KV 值比 embedding 保留了更丰富的细节（尤其是在高压缩比时），因此即使用一个 token 压缩 480 个 token，仍然能保留 62%-73% 的原始能力。代价是需要修改模型推理流程，不能对所有黑盒 LLM 使用。

xRAG 走到了极端——它证明冻结的 embedding 模型可以将整段文档压缩成一个 token，然后用于问答。虽然主要是为 RAG 场景设计的，但它揭示了一个深刻的事实：当前 embedding 模型的信息密度远超我们的使用方式。

Lost in the Middle 的五条缓解策略

Lost in the Middle 不是靠一个技术就能解决的，而是需要在 prompt 设计的每一层都做防护：

指令位置法则（最重要）：核心指令必须放在 prompt 的末尾，不能放在开头。这违反了很多人"先写规则再给数据"的直觉，但实验数据不会骗人——末尾位置的准确率比中间位置高 40 个百分点以上。当你要求模型"基于以下文档回答问题"时，把"注意：如果文档中没有明确答案，请说'无法确定'"放在最后，而不是放在开头。

文档重排序：RAG 返回的文档不要按检索分数直接拼接，而要做一次人工排序——最相关的放最前和最后，中等相关的放在中间区域。这不是在优化检索质量，而是在利用 U 型曲线，不让重要信息掉进注意力黑洞。

RAG 降噪：很多时候，少即是多。检索 20 篇文档塞进上下文的准确率，常常低于检索 5 篇真正高质量的文档。因为 20 篇带来的噪声分散了模型注意力，5 篇精品反而让模型聚焦。

Prompt 压缩：去冗余 token、删除 HTML 标签和注释、压缩冗长的 log 输出。这些"噪音"不仅浪费 token，还挤占了关键信息在上下文中的物理位置——你可能把重要事实推到了 U 型曲线的谷底。

强制 CoT 提取：在 prompt 中要求模型"先逐条摘录原文中的相关信息，再基于摘录内容回答"。这听起来多此一举，但强制摘录步骤迫使模型重新"阅读"了所有输入，而不是凭自回归机制"猜测"中间内容。实验证明这个简单技巧能把中间位置的准确率提升 10-15 个百分点。

---

五、KV Cache 优化：算力之下的隐形杀手

KV Cache 是 LLM 推理中最容易被忽视的性能瓶颈。大多数工程师知道它"占显存"，但不清楚它"占多少"和"怎么省"。

从公式理解本质

KV Cache 的内存占用量 = 2 × 层数 × Batch Size × 序列长度 × KV 头数 × 每头维度 × 精度字节数。以 LLaMA-3 70B 为例（80 层、GQA 8 组、FP16）：8K 序列时 KV Cache 仅 2.5GB，是个小透明；128K 时 40GB，已经值得关注；1M 时 330GB——是模型权重的 2.5 倍。这意味着为了服务一个长上下文请求，你需要分配三倍于模型大小的显存。这就是为什么"模型支持 1M 上下文"和"能在你的 GPU 上跑到 1M 上下文"是完全不同的两件事。

方向一：架构层面（选模型时就要决策）

这是训练阶段的决策，部署时无法更改。MQA（Multi-Query Attention）让所有 Query 头共享同一套 Key/Value，极端压缩但可能损失模型质量。GQA（Grouped-Query Attention）折中——把 Query 头分 4-8 组，组内共享 KV——已成为 2024 年后几乎所有开源模型的标配。

DeepSeek 的 MLA（Multi-head Latent Attention）是目前最激进的架构优化。核心思路是把 Key 和 Value 映射到一个低维潜在空间，存的是潜在向量而非完整的 KV 矩阵。对于标准 MHA 来说每个 token 的 KV 是 32768 维 × 2 bytes = 65536 bytes；MLA 只需要 512+64 = 576 维 × 2 bytes = 1152 bytes。压缩比 56.9 倍。100 万 token 场景，标准方案要 67GB KV Cache，MLA 只需要 1.18GB——一张消费级显卡都能跑。这就是为什么 DeepSeek-V2 能以极低的推理成本支持 128K 上下文。

DeepSeek 的 NSA（Native Sparse Attention）补上了注意力计算的短板。它把稀疏注意力分成三路并行：粗粒度 Token 压缩（用压缩块捕获全局语义）、细粒度 Token 选择（按重要性分数动态筛选关键 token）、滑动窗口局部注意力（保证近邻精度）。三路输出融合后送入下一层。与 MLA 组合，从内存到计算都做了双边优化。

方向二：系统层面（部署引擎帮你做）

PagedAttention 是 vLLM 的看家本领，把操作系统的虚拟内存分页机制搬到了 KV Cache 管理上。传统的 KV Cache 必须预分配一整块连续的显存，导致大量碎片和浪费（利用率通常只有 20%-40%）。PagedAttention 把 KV Cache 切成小页，逻辑上连续但物理上可以分散存放，利用率拉满到接近 100%，吞吐量提升 2-4 倍。

Prefix Caching 利用了一个简单但重要的规律：在聊天机器人和多轮对话场景中，不同请求之间共享大量前缀——system prompt 完全一样，前几轮对话也高度重合。与其每个请求都重新计算这些前缀的 KV，不如第一次算完后就缓存起来。前缀匹配命中时，可以直接复用缓存的 KV，跳过 Prefill 阶段的计算。TTFT（首字延迟）能降低 60-80%，这对于需要"秒回"的场景是质的提升。SGLang 的 RadixAttention 更进一步，用前缀树（Radix Tree）管理缓存，支持 token 级别的部分匹配——即使两个请求的前缀不完全相同，也能复用共享部分。

Continuous Batching 解决了传统批次调度"先到齐再一起推"的低效问题。它不做批次级别的同步，而是在每个 token 生成的迭代中动态决定哪些请求参与本轮计算。某个请求生成完就退出，新请求随时加入。这使得 GPU 利用率大幅提升，吞吐最高可达传统方案的 23 倍。

方向三：量化层面（精度换空间）

FP8 是最直接的方案——H100/H200 有原生 FP8 张量核心支持，性能无损近一半。KIVI 推进到 2-bit 量化，对 Key 做逐通道量化（因为不同通道的数值范围差异大）、对 Value 做逐 Token 量化（因为同一 token 的不同维度分布相近），非对称策略让 2-bit 下仍有合理的精度。

KVQuant 是目前单卡长上下文推理的标杆方案，3-bit 精度就能让一张 A100 支持 100 万 token。它的核心创新有三个：Pre-RoPE 量化——在应用旋转位置编码之前先做量化，避免 RoPE 引入的混合精度问题；非均匀量化——对稠密值和稀疏值用不同的量化网格；稠密-稀疏分离——少部分离群 channel 保持高精度，大部分用 3-bit。TurboQuant 在 2026 年用极坐标量化把内存进一步压缩 6 倍，注意力加速 8 倍。

方向四：稀疏化驱逐（选择性丢弃）

KV Cache 不一定要存全部历史 token。最大的发现来自 H2O——注意力分布极度不均，大约 5% 的 token 占据了 95% 的注意力分数。这 5% 叫 Heavy Hitters，只要保留它们 + 最近的滑动窗口 token，就能保持几乎全部的模型质量。保留比例仅需 20% 左右，内存和计算都砍掉大半。

StreamingLLM 发现了一个更基础的现象：前 1-4 个 token 在各层注意力中持续吸收大量分数，称之为 Attention Sink（注意力沉没区）。如果你把这几个 token 丢掉了，模型立刻崩溃——不是因为它们携带了语义信息，而是因为它们充当了注意力机制的"垃圾桶"：多余的注意力分数需要一个地方"泄洪"，初始 token 天然就是那个泄洪口。保留这 4 个 "Sink token" + 滑动窗口，StreamingLLM 能以 O(1) 的固定 KV Cache 大小稳定推理 400 万+ token。这是一个极其优雅的工程发现——几个 token 的保留与否，决定了模型能否无限流式推理。

PyramidKV 从另一个维度切入——不是按时间或注意力分数选择保留哪些 token，而是按层数分配保留预算。它的洞察是：底层（靠近输入）的注意力分布更均匀，需要多保留一些；顶层（靠近输出）的注意力高度集中，保留少量即可。按金字塔式分配——底宽顶窄——只用 2.5% 的 KV 就能保持 90% 以上的 LongBench 性能。

方向五：卸载策略（多级存储）

当 GPU 显存不够时，把不活跃的数据往更低速但更便宜的存储上搬。FlexGen 开创了 GPU-CPU-SSD 三级卸载，让一张 RTX 3090 就能跑 OPT-175B。LMCache 专注于 KV Cache 的分布式各级缓存——热数据在 GPU HBM、温数据在 CPU DRAM、冷数据在 NVMe SSD 或远程节点——TTFT 降低 3-10 倍。腾讯的 FlexKV 更进一步，把 KV 存储做成分布式共享服务，多个推理实例共享同一份 KV，避免重复计算。

---

六、前沿架构：从补丁到范式变革

MemGPT / Letta：把 OS 虚拟内存搬进 LLM

MemGPT 是 2023 年 UC Berkeley 的论文，但它至今仍然是理解长上下文记忆管理的必读文献。一句话概括：既然操作系统能通过在 RAM 和硬盘之间搬运数据让程序以为自己拥有无限内存，LLM 为什么不能在有限的上下文窗口和外部存储之间做同样的事？

主上下文就是"物理内存"——LLM 推理时实际看到的 prompt token，分为三段：只读的系统指令告诉模型 MemGPT 的控制流和函数用法；可读写的工作上下文存放关键事实和用户画像（类比常驻内存的核心数据）；FIFO 队列存最近的消息历史。队列的第一条消息始终是对已驱逐消息的递归摘要。

外部上下文就是"硬盘"——召回存储是全量历史消息数据库，支持语义搜索；归档存储是基于 pgvector 的向量数据库，支持任意长度文本的存储和检索。

LLM 自己通过函数调用来触发"换页"——这正是 MemGPT 最精巧的设计。模型在推理时生成函数调用，系统解析执行，结果再送回 LLM 形成反馈循环。不需要外部调度器，模型自主决定什么时候查归档、什么时候写工作上下文、什么时候更新用户画像。

MemGPT 还支持"函数链式调用"——有些任务需要连续多次查询，比如逐页翻归档存储、跨数据源拼接信息。LLM 可以设置一个 request_heartbeat 标志，告诉系统"函数执行完后立即再次触发推理，不等用户发下一条消息"，一口气完成多步检索。

实验数据令人印象深刻：深度记忆检索任务中，GPT-4 基线准确率只有 32.1%——这意味着在五轮对话后，GPT-4 有 68% 的概率记不住之前的关键信息。加上 MemGPT 后跳到 92.5%，提升了整整 60 个百分点。嵌套 KV 检索更精彩——GPT-4 在 3 层嵌套时准确率归零，MemGPT+GPT-4 在所有层数上都保持接近 100%。这说明传统模型不是不聪明，而是信息根本没被放进它的视线范围内。

2025 年 MemGPT 工程化为 Letta 框架，支持多种存储后端和模型，成为开源 Agent 记忆管理的核心基建。

Google Titans：记忆本身就是神经网络

Titans（2025, Google Research）提出了一个根本性的范式转换——不是在 Transformer 外面挂一个记忆库，而是让模型内部有一个可以持续学习的长期记忆模块。

Titans 的核心是一个 MLP 网络，作为"神经长期记忆"。在推理时，每当新信息到来，这个 MLP 通过梯度下降来更新自己的权重，把新信息编码进去——这与人类大脑通过突触可塑性编码长期记忆的过程惊人地相似。

关键问题是：不可能每条信息都触发一次梯度更新——计算成本太高。Titans 的解法是"惊喜机制"（Surprise Metric）。新输入进来时，计算它关于当前记忆状态的梯度大小。梯度小 = 可预测 = 不重要 = 跳过更新。梯度大 = 出乎意料 = 有价值 = 刻入记忆。配合动量和遗忘机制，Titans 模拟了人脑记忆巩固的三个阶段：编码（新信息写入）、巩固（重要信息强化）、遗忘（不重要的消退）。

在 200 万+ token 的 BABILong 长推理基准上，参数量远小于 GPT-4 的 Titans 却超越了 GPT-4。更关键的是——它的推理速度保持线性（类似 RNN），而精度保持 Transformer 水平。这打破了"想记得久就得算得慢"的魔咒。

Google 几乎同时提出的 MIRAS 理论框架为所有这些记忆架构提供了统一的分类语言。它把序列建模问题抽象为四个维度：记忆架构（向量/矩阵/神经网络）、注意力偏差（优先关注什么）、记忆保持门（新旧知识平衡）、记忆算法（梯度优化方法）。在这个框架下，Transformer 是"向量记忆 + 全注意力 + 全保留"的极端配置，Mamba 是"矩阵记忆 + 状态门 + 选择性遗忘"，Titans 是"神经网络记忆 + 惊喜门 + 在线学习"。

DeepSeek 的 MLA + NSA 组合拳

DeepSeek 走了另一条工程化路线——不是改变架构范式，而是把现有 Transformer 架构的效率推到极致。MLA 解决 KV Cache 的内存爆炸（1M token 只需 1.18GB），NSA 解决注意力计算的 O(n²) 诅咒（64K+ 序列显著加速）。两者组合，从训练到推理做双边优化，让 DeepSeek-V2/V3 以训练成本的一小部分实现了接近顶级的性能。这是 2025-2026 年中国 AI 在长上下文推理效率上最重要的贡献，也是面试中展示技术深度的绝佳话题。

---

七、面试速查与决策指南

14 个核心概念一句话

概念	一句话精华	面试官的追问
短期记忆	当前会话内的历史消息，受 context window 直接限制	满了你怎么处理？
长期记忆	跨会话持久化的用户画像和知识，从短期记忆中抽象得出	你用哪个框架？为什么不用 Mem0？
Lost in the Middle	LLM 对长文本中间内容准确率暴跌的 U 型曲线	你实际遇到过吗？怎么解决的？
上下文压缩	删除冗余 token/生成摘要，减小 prompt 体积	有损压缩你怎么评估质量？
LLMLingua	小模型 PPL 评估 + 迭代删除 + 分布对齐，20× 压缩	GPT-2 的 tokenizer 和目标模型不一致怎么办？
GQA	Query 头分组共享 KV，4-8× 压缩，2024 后工业标准	MQA 和 GQA 的性能差距有多大？
MLA	低秩压缩 KV，存潜在向量，56.9× 压缩	RoPE 和低秩压缩的兼容性怎么处理的？
PagedAttention	OS 虚拟内存分页搬进 KV Cache 管理	和 Prefix Caching 怎么协同？
KVQuant	3-bit 非均匀量化 + 稠密稀疏分离，单卡 100 万 token	离群 channel 的处理策略是什么？
StreamingLLM	Attention Sink + 滑动窗口，O(1) 固定 KV 推理 400 万+	为什么前 4 个 token 绝不能丢？
MemGPT/Letta	OS 虚拟内存思路，函数调用触发"缺页中断"换页	驱逐策略比 LRU 好在哪？
Titans	神经长期记忆 MLP + 惊喜机制 + 在线学习	推理时需要梯度计算，延迟怎么控制？
递归摘要	层层压缩老消息，保持语义连贯但细节逐层丢失	你怎么衡量信息丢失的幅度？
RAG vs 长上下文	RAG 精准定位、长上下文全局理解，两者互补不互斥	什么场景下你会同时用？什么场景下只用 RAG？

面试回答模板（五层递进）

"这个问题需要从五个层面来回答。

架构决策层：我们不会真的把所有数据都塞进 context window。对于精准事实查询——比如'用户的手机号是什么'——走 RAG 检索就够了，1M context 是大炮打蚊子。只有当任务需要全局理解——比如'总结整个代码库中所有安全漏洞'——我们才会把尽可能多的上下文送入 LLM。

短期记忆层：会话内的历史消息通过上下文工程管理。当 token 接近阈值时，老消息走递归摘要压缩成'会话要点'，保留大局观但牺牲细节；大块的工具输出和中间结果卸载到外部存储只留引用；需要独立完成的子任务隔离到子 Agent，主 Agent 只要结果。这三个策略按'时间远近 × 数据类型 × 可恢复性'三维决策矩阵来分配。

长期记忆层：跨会话的记忆用 TiMem/Zep 这类框架，核心是在时间维度上做自动层级归纳——对话结束后 LLM 自动总结为会话摘要，日结尾汇总为每日总结，周汇总为每周总结，最终沉淀为用户画像。Record 阶段 LLM 做事实抽取，Retrieve 阶段根据问题复杂度自动决定检索哪些层。

部署优化层：推理引擎用 vLLM 的 PagedAttention（解决 KV Cache 碎片）+ Prefix Caching（system prompt 和共享前缀复用）。模型选型时优先考虑 GQA/MLA 架构，必要时上 KVQuant 3-bit 量化把 KV Cache 压到几分之一，或用 StreamingLLM 保持固定 KV 大小实现无限流式推理。

提示词防护层：核心指令永远放末尾，最相关的文档放首尾，Review 文档放中间。关键事实类问题用强制 CoT 提取——'先摘录原文中的相关段落，再基于摘录回答'——防止 Lost in the Middle。如果 prompt 仍然过长，用 LLMLingua 做前置压缩去冗余——这一步在 token 进入 LLM 之前完成，不影响 LLM 本身的推理流程。"

按场景选方案

你的场景	记忆框架	KV Cache 策略	上下文管理
聊天机器人（简单）	Mem0	vLLM PagedAttention	滑动窗口 + 截断
个人助手（长期）	TiMem	GQA + FP8	递归摘要 + 上下文卸载
LangChain 项目	LangMem	vLLM Prefix Caching	SummarizationMiddleware
多 Agent 系统	Zep/MemOS	Continuous Batching	上下文隔离
超长文档分析	TiMem + RAG	MLA + KVQuant	文档重排序
低成本部署	Mem0	StreamingLLM + KIVI 2bit	激进压缩
高并发生产	Zep	PagedAttention + Radix	Chunked Prefill

---

技术演进时间线

2023 ─ MemGPT 论文（OS 虚拟内存思路首次提出）
  │   Lost in the Middle 论文（确认 U 型曲线现象）
  │   LLMLingua v1（20× 压缩比，粗到细三阶段）
  │   H2O（Heavy Hitters 驱逐理论）
  │
2024 ─ GQA 成为工业标准（LLaMA-3、Qwen2、Gemma 标配）
  │   PagedAttention (vLLM) 落地（KV Cache 利用率拉满）
  │   StreamingLLM（Attention Sink 发现，无限流式推理）
  │   LLMLingua-2, LongLLMLingua
  │   KVQuant（单卡 100 万 token 技术验证）
  │   DeepSeek MLA + NSA 发布（训练推理双边优化）
  │
2025 ─ Letta（MemGPT 工程化为开源框架）
  │   Google Titans + MIRAS 发布（神经记忆新范式）
  │   TiMem 时序记忆树（LoCoMo 领先）
  │   Mem0/Zep/LangMem 生态成熟
  │   SGLang RadixAttention（前缀树缓存）
  │
2026 ─ 多层记忆成为 Agent 标配（短期+长期+外部三级架构）
  │   MaaS（记忆即服务）成为趋势
  │   TurboQuant 极坐标量化（内存节省 6×）
  │   多模态记忆系统初期探索
  │   MemOS 图谱记忆操作系统生态扩展

---

参考来源

1. Liu et al., "Lost in the Middle: How Language Models Use Long Contexts", arXiv:2307.03172, 2023
2. Packer et al., "MemGPT: Towards LLMs as Operating Systems", arXiv:2310.08560, UC Berkeley, 2023
3. Behrouz et al., "Titans: Learning to Memorize at Test Time", arXiv:2501.00663, Google Research, 2025
4. DeepSeek-AI, "DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model", 2024（MLA）
5. DeepSeek-AI, "Native Sparse Attention: Hardware-Aligned and Natively Trainable Sparse Attention", 2025（NSA）
6. Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention", SOSP 2023
7. Xiao et al., "Efficient Streaming Language Models with Attention Sinks", ICLR 2024
8. Zhang et al., "H2O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models", NeurIPS 2023
9. Hooper et al., "KVQuant: Towards 10 Million Context Length LLM Inference with KV Cache Quantization", NeurIPS 2024
10. Liu et al., "KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV Cache", ICLR 2024
11. Jiang et al., "LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models", EMNLP 2023
12. Li et al., "LLMLingua-2: Data Distillation for Efficient and Faithful Task-Agnostic Prompt Compression", 2024
13. Li et al., "Prompt Compression for Large Language Models: A Survey", arXiv:2410.12388, 剑桥大学, 2024
14. 知乎, "2025年Memory最全综述！AI Agent记忆统一分类体系", 2025
15. 掘金, "2026 AI 记忆框架横评：Mem0 / Zep / LangMem / TiMem", 2026
16. CSDN, "2026开源AI 记忆框架全景：Mem0、Zep、LangMem、MemOS、TiMem深度横评", 2026
17. 阿里云开发者, "AI Agent 记忆系统：从短期到长期的技术架构与实践", 2026
18. 腾讯云开发者社区, "KV缓存：LLM推理的内存怪兽与优化之道", 2025
19. AgentMarketCap, "Agent Memory at Scale 2026: Letta, Zep, Mem0, LangMem", 2026
20. Redis Blog, "RAG vs Large Context Window: Real Trade-offs for AI Apps", 2026