GLM-5 的 200K 上下文，聊着聊着就忘了

大家好，我是 147。

200K token，大约相当于 15 万个中文字，或者一本中篇小说。GLM-5 的上下文窗口够放下一个中等规模项目的全部源码了。

但我在 GitHub 和 X 上反复看到同一类抱怨：跟 GLM 系列模型聊到一定轮次之后，模型突然忘了之前在讨论什么，开始答非所问。

这不是 GLM-5 独有的问题。Claude、GPT 都有类似现象。但因为 GLM-5 的上下文窗口标称 200K，用户的期望值更高，落差也更大。

GLM-5 上下文丢失的典型表现

举一个 GitHub 上的真实 case。有用户在跟 GLM-4.6（GLM-5 的前代）讨论 AI 模型校准的话题，聊了十几轮之后，他输入了一句"set subset relation show me"——他的意思是让模型展示之前讨论过的集合子集关系。

模型的反应是：完全忽略了前面十几轮关于模型校准的讨论，直接开始写一篇"数学集合子集关系"的入门教程，就好像在跟一个新用户对话一样。

这个 issue 目前还是 Open 状态。

另一个常见的现象是"循环重复"。在 vLLM 部署的场景下，如果一次请求里要求模型返回多个答案（设置 n > 1），模型有概率进入无限循环，不停重复同一段话直到上下文塞满。这个 bug 在 GLM-4.5V 上被确认，后来修了，但同类问题在新版本上偶尔还会出现。

长上下文失忆的三个原因

上下文窗口大不等于模型能均匀利用每一段内容。这是当下所有 Transformer 架构模型的共同弱点。

原因有几层。

注意力衰减。 虽然 GLM-5 用了 DeepSeek Sparse Attention（DSA）来降低长文本的计算开销，但稀疏注意力的代价是：模型不会对上下文中的每一个 token 投入同等的"注意力"。越靠近窗口头部（老的信息）和尾部（最近的几轮），注意力越集中；中间的内容容易被忽略。

这就是"Lost in the Middle"效应。2023 年就有论文讨论过这个问题，到现在没有根本性解决。

推理框架的影响。 有一个容易忽略的因素：同一个模型，在官方 API 上跑和在 vLLM / llama.cpp 上跑，表现可能不一样。GLM-4.5-Air 在 vLLM 上的质量就被用户反映明显低于官方部署。智谱官方的回应是"量化导致的质量损失"，但有人用 BF16 非量化版本在 llama.cpp 上跑，也遇到了同样的问题——模型会生成大量冗余的思考 token，有时候超过 2000 个 token 全是自言自语。

这说明推理框架在采样策略、停止条件、温度处理等方面的差异，对模型输出质量有实实在在的影响。

上下文管理策略。 当对话长度接近窗口上限的时候，系统需要决定"丢弃什么"。不同平台的做法不同。GLM-5 在 BrowseComp 评测里用了一种叫"discard-all"的策略（跟 DeepSeek-V3.2 和 Kimi K2.5 相同），简单说就是只保留最近几轮的完整内容，老的内容全部丢掉。

这种策略在搜索任务里效果还行，但在需要持续记忆的多轮对话里就会出问题。

解决 GLM-5 上下文丢失的四种方案

目前社区里讨论比较多的缓解方案有四种，各有优缺点。

1. 滑动窗口 + 摘要压缩

最直观的办法。每隔 N 轮，让模型先对之前的对话做一个摘要，然后用摘要替换原文，释放上下文空间。

好处是简单直接，坏处是摘要本身会丢信息。尤其是代码讨论中的细节（变量名、行号、条件分支），摘要很难完整保留。

实操上，摘要长度控制在原文的 1/5 到 1/3 比较合适。太短了丢太多，太长了省不了多少空间。

2. 检索增强（RAG）

把历史对话存到向量数据库里，每次新提问时先检索相关的历史片段，拼到 prompt 里。

好处是理论上可以"记住"无限长的历史。坏处是检索的质量取决于 embedding 模型和检索策略。如果历史对话的主题很相近（比如一直在讨论同一个模块的不同方面），检索容易混淆。

另一个问题是延迟。每次请求都要先做一遍检索，在交互式对话场景下会增加几百毫秒到几秒的等待。

3. 上下文缓存

GLM-5 的 API 支持 Context Caching（上下文缓存）。简单说就是你可以把一段固定内容（比如系统 prompt、项目背景说明）缓存起来，后续请求直接复用，不需要重复传输和计算。

从官方定价看，缓存输入的价格是普通输入的约 1/6，所以对成本也有帮助。

这个方案适合"有大量固定上下文 + 少量变化内容"的场景，比如客服系统、代码助手。但对于话题频繁变化的自由对话，缓存的命中率不高。

4. 显式记忆文件

这是我个人比较推荐的做法。灵感来自 OpenClaw 的 AGENTS.md 方案。

具体来说，在对话过程中维护一个"记忆文件"，每当讨论出重要的结论、决策或约束时，让模型把它写到记忆文件里。下次对话时，先把记忆文件加载到 prompt 开头。

好处是记忆是结构化的、可编辑的、可审计的。你随时可以打开文件看看模型"记住了什么"，也可以手动修正。

坏处是需要额外的工程开发，而且依赖模型"知道什么该记住"的判断。

GLM-5 上下文管理的实操建议

对于使用 GLM-5 API 的开发者，我的建议是：

不要无脑依赖 200K 窗口。超过 50K 之后就开始注意内容管理
把重要信息放在 prompt 的开头和结尾，避免放在中间段落
如果用的是 vLLM 或 SGLang 本地部署，务必对比一下跟官方 API 的输出质量。发现差异时，先排查采样参数（temperature、top_p、repetition_penalty）是否一致
对于需要长期记忆的 Agent 场景，上 RAG 或显式记忆文件。别指望上下文窗口一招鲜

大模型长上下文记忆的未来方向

GLM-5 用的 DSA（DeepSeek Sparse Attention）是目前长上下文优化的主流方案之一。但稀疏注意力的本质是用精度换效率，这个 trade-off 在更长的上下文下会越来越明显。

我比较期待的方向是"分层记忆"——模型内部维护一个长期记忆和一个工作记忆，类似人脑的海马体和前额叶的分工。Gemini 在这个方向上有一些探索（Memory Stones 机制），但目前还没有成熟的开源方案。

另一个方向是让模型学会"主动复习"——在生成回复之前，先回头翻一遍关键信息。这本质上是一种 Chain-of-Retrieval，跟 Chain-of-Thought 的思路类似，但目标不同。

不管哪个方向，"上下文窗口"只是输入的管道粗细。模型真正的记忆能力，取决于它怎么处理管道里的内容。窗口从 128K 扩到 200K 再扩到 1M，如果注意力分配的问题不解决，失忆照样会发生。

常见问题

GLM-5 的上下文窗口到底有多大？ GLM-5 支持最大 200K token（约 205,000 token）的上下文输入，最大输出 131K token。但实际使用中，超过 50K token 后模型对中间内容的记忆质量会下降。

GLM-5 在 vLLM 上跑和官方 API 表现为什么不一样？ 推理框架在采样策略、停止条件和温度参数处理上与官方部署存在差异。此外，量化版本（FP8/AWQ）也会带来质量损失。建议先对齐采样参数再做对比。

怎么避免 GLM-5 多轮对话中的"失忆"？ 四种常用方案：滑动窗口 + 摘要压缩、RAG 检索增强、上下文缓存（Context Caching）、显式记忆文件。根据场景选择合适的组合。

参考资料：

GitHub issue: zai-org/GLM-4.5 #104（多轮对话上下文保持问题）
GitHub issue: zai-org/GLM-4.5 #53（vLLM/llama.cpp 质量问题）
"Lost in the Middle: How Language Models Use Long Contexts", Liu et al., 2023
GLM-5 API 文档：docs.z.ai/guides/llm/glm-5