记忆张量发布 MemT-1.0，称 128K 历史的持久状态约为全量 KV 缓存的 1/66
记忆张量 10 月 20 日发布 MemT-1.0：报告称 128K 历史下持久状态约为全量 KV 缓存的 1/66，论文表里 MemOS 等文本记忆仍更高。
记忆张量（MemTensor）发布的 MemT-1.0 是一组“记忆原生”的基础模型。它在骨干网络的注意力旁边加了一个原生记忆模块，历史写进这个模块的状态里，推理时不再读取原始上下文。10 月 20 日，团队发布了这个模型族；技术报告 10 月 19 日已经挂上 arXiv（2610.26825）。报告称，在 128K 历史长度下，Nano 版每条轨迹的持久状态约为全量上下文 KV 缓存的 1/66。
要点
- 存储与速度：128K 历史下，Nano 每条轨迹的持久状态约为全量上下文 KV 缓存的 1/66，端到端推理约快 1.86 倍。这些是论文的数字，存储口径不含共享权重。
- 跑分：11 项记忆基准里，两款 MemT 在“参数化记忆方法”中分列第一、第二。但论文表 2 中，文本记忆系统 MemOS 的均分是 68.55，高于 MemT 大模型的 50.60。
- 许可：GitHub 仓库是 PolyForm 非商用许可，论文是 CC BY-NC-SA 4.0，Nano 的权重卡标 Apache-2.0，另一款的权重卡标 MIT。官方没有解释这些差异。
背景
给模型加长期记忆，常见做法有两类。一类是文本记忆系统：把历史存成文本或向量，用时再检索出来放进上下文，MemOS 和 Mem0 属于这一类。另一类是把全部历史留在上下文窗口里，历史越长，占用越大。MemT-1.0 走第三条路：历史被写进一块大小固定的记忆状态，推理时直接读这块状态。
记忆张量此前的项目 MemOS 属于文本记忆系统，其仓库 MemTensor/MemOS 在 2025 年 8 月就上过 Hacker News。本站近两天写过两条相关条目：腾讯混元 Hy Memory 2.0 是三层记忆系统，自带一个 30B-A3B 的记忆模型；ai-memory 3.1.1 让 Claude Code 与 Codex 共用一份 git 里的 markdown 记忆。两者都把记忆放在模型外部，MemT-1.0 不同。
事实部分
模型族有两款，下表规格来自 GitHub README 的模型表。
| 型号 | 骨干模型 | 总参数 | 激活参数 | 可训练记忆参数 | 动态记忆状态 |
|---|---|---|---|---|---|
| MemT-1.0-Nano | Qwen3.6-35B-A3B | 36B | 3B | 451M | 10M |
| MemT-1.0 Flash 版 | DeepSeek-V4-Flash | 288B | 17B | 3.61B | 336M |
论文表 2 给出 11 个记忆基准的均分，下表取其中六行，骨干写在括号里。
| 系统 | 论文分组 | 均分 |
|---|---|---|
| MemOS（DeepSeek-V4-Flash） | 文本记忆 | 68.55 |
| Mem0（DeepSeek-V4-Flash） | 文本记忆 | 65.53 |
| 全量上下文（DeepSeek-V4-Flash） | 文本记忆 | 64.98 |
| DenseRAG（DeepSeek-V4-Flash） | 文本记忆 | 57.28 |
| MemT-1.0 Flash 版（DeepSeek-V4-Flash） | 参数化记忆 | 50.60 |
| MemT-1.0-Nano（Qwen3.6-35B-A3B） | 参数化记忆 | 46.97 |
差距最大的是两个长历史基准。LongMemEval-S 上，Flash 版得 37.20 分，MemOS 得 83.20 分；BEAM-1M 上两者分别是 37.04 与 72.59。论文自己承认，最强的文本记忆系统在这两项上仍明显更高。
速度与存储的数字同样来自论文。
| 指标 | 数值 | 口径 |
|---|---|---|
| Nano 端到端推理加速 | 64K 约 1.20 倍，128K 约 1.86 倍，256K 约 3.99 倍 | 相对全量上下文 |
| 每条轨迹的持久状态 | 64K 约 1/33，128K 约 1/66 | 相对全量上下文；不含共享骨干权重、嵌入器与超记忆参数 |
| 256K 存储（论文图 3） | 全量上下文 5.061 GiB，Nano 40.00 MiB | 图中标注；两者相除约 130 倍，论文正文未写出该比值 |
| Nano 查询首字延迟 | 104–112 毫秒（256K 时全量上下文为 445 毫秒） | 论文正文 |
1/66 衡量的是持久状态，不是推理时的显存总量，当前一步的 KV 缓存和模型权重都不在统计范围内。训练方面，论文报告用了 34B tokens；后训练的采样检查点平均分在两个 epoch 内从 36.65 升到 46.80；记忆专家从 2 个增加到 4 个时，5,500 步检查点上平均分高 2.69 分。在 SWE-bench Verified 上，Nano 的平均成功率从无经验基线的 66.07% 升到 69.33%，经验在执行前注入。
各方说法
网易智能（10 月 20 日）报道，256K 历史下 MemT 的状态约为 40 MiB，传统方法为 5.06 GiB，约 130 倍。这与论文图 3 的标注一致（图中 Nano 为 40.00 MiB，全量上下文为 5.061 GiB）；130 倍是两者相除的结果，论文正文没有写出这一比值。它报道的首字延迟（104–112 毫秒对 445 毫秒）与论文一致。
爱范儿（10 月 20 日）报道，记忆张量当天“正式发布并开源”了 MemT 1.0。这里的“开源”要打个折扣：仓库许可禁止商业使用，通行的开源定义通常不把这类许可算作开源，所以本文标题用了“发布”。爱范儿转述的基准差距（大模型与 Nano 分别领先同组最强参数化基线 12.5 分和 8.9 分）与论文一致。它还引用一组消融数字，说去掉后训练后 Nano 会从 47.0 掉到 36.3。论文表 4 与此一致：w/o PT（只做持续预训练、不做后训练的检查点）的总均分为 36.3，比完整的 Nano（47.0）低 10.7。
安全研究机构 Socket 的分析指出，2026 年 9 月 23 日，有攻击者在 npm 与 PyPI 上发布了记忆张量名下两个包的恶意版本：npm 的 @memtensor/memos-cloud-openclaw-plugin 的 0.1.21、0.1.23、0.1.25，以及 PyPI 的 MemoryOS 2.0.34。恶意代码会搜集 GitHub、npm、PyPI、AWS 等服务的凭据。RelayShield 在 9 月 28 日的博文中转述 Aikido 的分析，称攻击者“取得了发布权限”；Socket 则说无法确认攻击者如何拿到权限。截至 10 月 20 日，上述版本已不在 npm 与 PyPI 的版本列表中，npm 的 latest 标签指向 0.1.24，PyPI 最新版本为 2.0.33。在两篇安全分析、npm 与 PyPI 的登记信息、Hacker News 以及 MemTensor 名下仓库的 issue 里，我们都没有找到厂商的回应。
Hacker News 上，用 Algolia 检索 MemT-1.0 没有讨论；检索 MemTensor 得到的是上述安全事件的两条讨论，以及 2025 年的 MemOS 条目。
编辑判断
对做长程智能体的工程团队来说，这个设计值得看：状态大小不随历史增长，推理时也不必重读原始历史。代价是容量。论文第 8 节写明，固定大小的状态有容量约束，需要精确回忆的任务会损失记忆保真度。
要直接用，有三个卡点。第一是许可：仓库代码只许非商业使用；Nano 权重卡写 Apache-2.0；README 又说权重不在仓库许可之下，条款“随相应发布提供”。三者的关系官方没有解释，商用前应先问作者。第二是跑分，这张表是作者自己做的，长历史上文本记忆系统仍然领先。第三是门槛：示例需要 Linux、NVIDIA CUDA 与 Python 3.11 以上，服务端用了两张 GPU，不是一分钟能跑通的东西。
信任层面还要算上 9 月的事件。它涉及的是 npm 插件和 PyPI 包 MemoryOS，不是这次发布的仓库或权重，我们也没有核实 MemT-1.0 的发布产物。但据 RelayShield 转述的分析，发布权限在 9 月被人接管过，而我们没有找到厂商的说明。试用时应按 README 从仓库的 inference 目录安装，不要直接用包管理器里的同名包。
接下来值得盯的有三件事：权重许可有没有正式说明；有没有独立团队复现这组跑分；记忆张量会不会对 9 月的事件作出说明。
怎么试
按 README，在 Linux 服务器上进入仓库的 inference 目录，运行 uv pip install '.[server]' 安装服务端，再执行 sh start_memt_nano.sh /models/MemT-1.0-Nano。服务会在 http://127.0.0.1:30000 提供接口，示例用了两张 GPU。会话记忆可以用 save_state 保存，恢复时把返回的路径传给 state 参数。