MemoryLake
返回全部文章
Tutorial2026 年 8 月 17 日·10 分钟阅读

为什么 1M Token 的上下文窗口不是记忆 (2026)

2026 年 8 月 14 日,Qwen 发布了 Qwen3.8-27B 的开源权重——采用 Apache-2.0 协议,其大小足以在您实际买得起的硬件上运行,并且其上下文声明听起来就像是终结了某种争论:“原生 262,144 token,可扩展至 1,000,000 token。”该模型的 Model Card 比大多数模型走得更远。它指出,在默认情况下,“Qwen3.8 保留了所有历史消息中的思考块,在整个对话中维护完整的推理轨迹。”

100 万 token。完整的推理得以保留。在您自己的机器上运行。然而,当您关闭该对话并开启一个新对话时,它对您一无所知。

一句话道尽了全部,这值得我们深思,因为“我们只需使用更大的上下文窗口”已成为行业中解决每个记忆问题的默认答案。上下文窗口是单次请求的工作空间。而记忆是在请求结束后依然存在的东西。 它们不是同一种资源,彼此不构成竞争关系,购买更多前者并不能让您获得任何后者。

本文将深入探讨为什么这两者会被混淆、窗口中的所有内容实际上发生了什么,以及持久化层应该归于何处。

为什么更大的上下文窗口不会变成记忆

每次请求时窗口都是从头开始重建的

大多数人的心智模型是,对话在模型内部不断累积,就像服务器上的会话一样。事实并非如此。每次请求都会向模型发送一个文本块——系统提示词、先前的对话轮次、任何附加的文件——然后模型生成后续内容。接着就结束了。模型端不会保留任何内容。

造成连贯性错觉的是您的客户端每次都在重新发送聊天记录。这就是为什么对话能“记住”您十分钟前说的话,却对您昨天的聊天内容一无所知:昨天的聊天记录不在当前的文本块中。更大的窗口意味着文本块可以更大。这并不意味着文本块之间会保留任何内容。

这也是为什么将窗口大小作为记忆指标会产生误导。262,144 token 大约是每次请求数十万字的容量,而不是存档。即使您把它完全填满,下次开始时依然是一片空白。

保留的推理是对话内部的连贯性,而不是跨对话的连贯性

Qwen3.8 的思考块行为是一个真正有用的功能,也是这一界限的完美例证。保留“整个对话中完整的推理轨迹”意味着模型可以查看它是如何得出早期结论的,而不是重新推导它们——从而减少矛盾、更好地进行长程任务,并减少模型忘记自己早期推理时出现的偏差。

请仔细阅读其适用范围:在对话中(across the conversation)。而不是跨对话(across conversations)。推理轨迹是重新发送的聊天记录的一部分,因此它的生命周期与聊天记录完全相同。关闭会话,推理轨迹也随之消失。一个让单次长会话更具连贯性的功能,并不能让明天的会话获得信息输入。

100 万 token 是您主动选择的配置,而且它并非免费

延长长度是一种缩放技术,而不是默认设置。Qwen 的 Model Card 描述了使用 YaRN——修改模型配置中的 rope_parameters 字段——特别是对于 vLLM,使用 VLLM_ALLOW_LONG_MAX_MODEL_LEN=1--max-model-len 1000000 进行服务。这是对模型处理位置方式的刻意修改,因为您认为这种权衡是值得的。

这确实是一种权衡。长上下文会消耗保存 KV 缓存的设备显存,并增加生成每个 token 的时间。在本地运行 100 万 token 的上下文是一个硬件层面的讨论,而不是勾选一个选项那么简单。与此同时,您真正想要的东西——让模型在下周二知道您的项目——在显存中不消耗任何成本,因为这根本不是上下文问题。

仍然需要有人决定将什么放入窗口中

这是被忽略的部分。假设您有 100 万 token 的空间和富余的硬件。您要在里面放什么?

要回答这个问题,您需要知道存在什么、哪些部分是最新有效的,以及哪些部分对当前任务至关重要。这是一个检索与筛选的问题,而且它不会随着窗口的增大而变得简单——反而会变得更难,因为“把所有东西都放进去”开始显得可行,直到您注意到“所有东西”包括了您已经推翻的决定、已经重写了两次的过时架构文档,以及同一规范的三个相互矛盾的版本。

大窗口改变了您可以加载内容的上限。它并不能告诉您应该加载什么。当窗口中充斥着矛盾时,模型的输出会变差,而不是变好——这也是为什么各大厂商普遍建议保持始终加载的指令文件简短的原因。

长上下文基准测试衡量的是另一种能力

窗口内检索评估测试的是模型能否找到您刻意放入上下文中的某个事实。这是一种真正的能力,而且模型在这方面已经有了显著的提升。但请注意这种设置的假设:该事实已经存在于窗口中。是有人把它放进去的。

人们实际遇到的失败则不同。没有人把它放进去,因为那是三周前在一个已经结束的对话中决定的,并且没有任何机制能将其传递下来。长上下文基准测试上的任何分数都无法解决这个问题,因为这根本不是一个能力问题。

人们的尝试

在每次会话中粘贴相同的上下文。 普遍的临时解决方案。它确实有效,但成本高昂——您必须为每次请求中的这些 token 付费,您必须记住要粘贴什么,而且一旦您换了机器或同事询问时,它就不存在了。

永远保持一个巨大的对话处于开启状态。 只是推迟了问题的出现。最终,线程会变慢、被总结或丢失,而总结是有损的,且往往在关键点上造成损失:例如“由于顺序保证,我们排除了基于队列的设计”等具体细节会被压缩为“讨论了架构”。

购买更大的窗口。 只是提高了上限,而没有改变边界。这种升级被宣传为一种解决方案,这也是为什么刚刚迁移到长上下文模型的团队往往最惊讶于会话之间没有任何改善的原因。

自托管以确保数据保留在本地。 这是自托管的一个好理由,但与记忆无关。在您自己的 GPU 上运行的开源权重模型遗忘您的彻底程度与托管模型完全相同。如果说有什么不同的话,那就是您会更明显地注意到这一点,因为您现在要负责它周围的每一个层级——为自托管模型添加记忆中也提到了同样的差距。

将文档放入向量存储中。 更接近了,而且对于寻找源材料确实有用。它检索您撰写的文档块。但它无法保存您得出但从未写下来的结论——这正是为什么 RAG 不是记忆以及AI 记忆与向量数据库之间的区别。

将聊天记录保存到文件夹中。 现在您有了一个没有任何东西去读取的存档。存储也不等于记忆;记忆意味着在使用的那一刻进行检索。

解决方案:将知识保留在窗口之外

一旦您将这两种资源分开,设计就会变得简单。上下文窗口是单次请求进行工作的地方。持久化层是请求之间知识存在的地方,它的工作是在正确的时刻将正确的几千个 token 放入窗口中——而不是在大小上与窗口竞争。

这就是 MemoryLake 的作用:一个供您的助手读取的记忆层,它独立于您运行的模型或它能容纳多少上下文。下个月把 Qwen3.8 换成其他模型,在本地运行或托管运行,使用 32K 窗口还是 100 万窗口——记忆都不会丢失,因为它从未存在于模型内部。设置只需三个步骤。

步骤 1:创建 API 密钥

登录 MemoryLake 并创建 API 密钥。这是您的工具用于读取和写入记忆的凭证,它刻意设计为与模型无关——正是这一特性使其能够在您的下一次升级中幸存下来。

创建 MemoryLake API 密钥以将记忆保留在上下文窗口之外
创建 MemoryLake API 密钥以将记忆保留在上下文窗口之外

步骤 2:上传您的第一批记忆

放入那些原本需要重复粘贴的内容:您的项目是如何构建的、代码中不明显的约束、决策及其背后的推理、您尝试过但放弃的方法。保持条目简短且单一目的。一个好的条目应该能让同事直接执行而无需追问,而且简短条目的检索效果比长条目更好。

将项目知识上传到 MemoryLake 工作区
将项目知识上传到 MemoryLake 工作区

步骤 3:连接您的 AI 和智能体

连接您使用的工具。MemoryLake 可通过 MCP 和 API 访问,因此 MCP 原生智能体(包括 Claude Code、Codex 和 OpenClaw)可以通过指向 MCP 服务器进行连接,而其他任何工具则通过 API 读取相同的记忆。实际效果是,窗口获得的是一个简短、相关且最新的片段,而不是将您可能需要的所有内容进行庞大的粘贴。

通过 MCP 和 API 将长上下文模型连接到 MemoryLake
通过 MCP 和 API 将长上下文模型连接到 MemoryLake

两个坦诚的限制。记忆层不会让模型在长上下文检索方面变得更聪明——这是模型本身的属性,而 Qwen 在这方面的工作是实实在在的。而且它只知道您或您的智能体放入其中的内容;它不会倾听您的会议,也不会阅读您的心思。它消除的是重复解释,而不是决策本身。

这在实践中改变了什么

Token 支出下降,而能力不减。 重复粘贴上下文意味着在每次请求中都要为相同的数千个 token 付费。检索相关的片段只需花费极少的一部分成本,而且模型的表现会更好,因为它不需要费力阅读与当前任务无关的材料。具体的计算方法在记忆如何降低 token 成本中有所介绍。

模型升级不再是迁移。 当知识存在于模型之外时,在您自托管的开源权重模型和托管的前沿模型之间切换只是一个配置更改。而当它存在于长期运行的对话中时,每次切换都必须从零开始。

自托管变得更容易被证明是合理的。 运行自己模型的一个常见反对意见是托管产品“能记住我”。将这些层分开,这一优势就消失了——您可以同时拥有本地权重持久化上下文,这比单独拥有其中任何一个都要强大得多。

长上下文被用于它们擅长的事情。 大窗口非常适合那些真正需要一次性查看大量材料的任务:一次性阅读大型代码库、比较多个文档、长程智能体运行。当窗口没有被粘贴的背景信息填满一半时,这些任务的执行效果会更好。

使用长上下文模型的最佳实践

将窗口大小视为容量规格,而不是记忆规格。 在评估模型时,请提出两个独立的问题:它一次能容纳多少内容,以及会话之间能传递什么。第二个问题几乎从来都与模型本身无关。

即使不需要,也要刻意加载。 仅仅因为能容纳 100 万 token 并不意味着它们会有所帮助。窗口中相互矛盾和过时的材料会降低输出质量;这就是“粘贴所有内容”的真实代价。

写下结论,而不仅仅是产出物。 文档描述了存在什么。昂贵的知识是您做出的决定以及您为什么拒绝替代方案——而这正是永远不会单独进入文件的部分。

在依赖宣传数字之前,先检查扩展设置。 通过 YaRN 扩展上下文是一项具有实际硬件成本的配置更改,而不是默认设置。请确认您实际提供服务时使用的是什么配置。

不要让一个对话成为存档。 如果某个决定仅存在于一个线程中,那么该决定就存在单点故障和有效期。

保持始终加载的指令简短。 无论您的持久化层是什么,每次请求加载的材料都应该是简短且最新的。冗长的始终开启文件会降低遵循度——这是各厂商的一致建议,无论窗口大小如何。

结论

Qwen3.8-27B 是一个真正令人瞩目的发布:采用 Apache-2.0 协议的开源权重、原生 262K 上下文、可扩展至 100 万,并且在对话中保留了推理轨迹。其中的每一项都是真正的改进,但它们都不是记忆。

这之所以重要,并非出于学究式的执念。而是因为“等待更大的窗口”已成为推迟构建持久化层的借口,而这种等待是无止境的——因为所等待的东西并不会从那个方向到来。窗口会变大。但在请求结束后能保留下来什么是一个独立的决定,这取决于您。如果您正在更广泛地权衡记忆的意义,什么是持久化记忆是一篇很好的后续读物;如果您正在转向 Qwen 的托管层,在不丢失上下文的情况下切换到 Qwen3.8-Max 介绍了这一途径。

常见问题

1M Token 的上下文窗口是否意味着模型能记住我?

不。窗口是模型在单次请求中可以处理的文本量。其中的所有内容都是由您的客户端在发起该请求时提供的,并在请求结束后消失。记忆是下次再次提供的内容,这是您系统设置의属性,而不是模型的属性。

“保留所有历史消息中的思考块”实际上是什么意思?

Qwen3.8 的 Model Card 描述了在对话中保持模型的推理轨迹可用,以便它可以查看如何得出早期的结论,而不是重新推导它们。其范围仅限于单次对话——推理轨迹是重新发送的聊天记录的一部分,因此它会随着对话的结束而结束。

Qwen3.8 是开源权重吗?采用什么许可协议?

Hugging Face 上的 Qwen3.8-27B 仓库采用 apache-2.0 许可协议。Max 级别的 Qwen3.8-2.4T-A95B 仓库的许可证字段显示为 other,因此请检查该特定模型的条款,而不是假设整个系列共享同一个许可证。

我该如何实际获得 1M 上下文?

这是一个扩展,而不是默认设置。Qwen 记录了通过修改模型配置中的 rope_parameters 字段来使用 YaRN,对于 vLLM,使用 VLLM_ALLOW_LONG_MAX_MODEL_LEN=1--max-model-len 1000000 进行服务。在这种长度下,预计会有实际的显存和延迟成本。

如果我进行自托管,数据不就留在我这里了吗?

您的数据保留在本地,这是自托管的一个好理由。但这并不能让模型具有持久性。在您自己的硬件上运行的开源权重模型在开始每次对话时,对之前的对话一无所知,这与托管模型完全一样。

如果我每次都粘贴我的上下文,长窗口难道不够用吗?

它确实有效,但这是最昂贵的选择。您必须为每次请求中的这些 token 付费,粘贴取决于您是否记得要粘贴什么,而且团队成员或其他工具都无法使用这些内容。这正是持久化记忆层所要替代的临时解决方案。