Agent 系统的紧凑记忆优化：降低上下文成本

Agent 系统需要内存。

客户服务 agent 必须记住它向客户承诺的内容。NPC 必须保存关系和过去的事件。企业助手必须恢复数天或数月前做出的决策。

最直接的解决方案是将对话历史发送回语言模型。

但有个问题：

历史在增长，加载它的成本也随之增长。

更大的上下文窗口让模型能处理更多信息，但这并不能使所有信息都与下一步决策相关。

这个问题促成了 ASM-CM —— Aletheion 紧凑内存模型。

ASM-CM 探索了一种不同的策略：

growing local history
        ↓
compact associative memory
        ↓
selective retrieval
        ↓
minimum authorized context
        ↓
local or remote LLM

系统不是发送整个过去，而是只检索与当前交互相关的内存。

本文估计该方法能节省多少。

H 为完整历史中的 token 数；

R 为内存系统检索的 token 数；

C 为每天的调用次数；

P 为每百万个输入 token 的价格。

近似月度节省为：

saving =
30 × C × (H - R) / 1,000,000 × P

此计算仅涵盖不再发送的输入 token。

我们仍必须扣除：

本地基础设施；

内存系统的维护。

除非 LLM 在本地运行，否则输出 token 成本保持不变。

场景 1：一个人每天使用 agent

想象一个人每天与 agent 交互 50 次。

Complete history:        20,000 tokens
Retrieved context:        2,000 tokens
Avoided tokens:          18,000 per call
Daily calls:                 50

18,000 × 50 × 30
= 27,000,000 avoided tokens

以当前 OpenAI API 输入价格为参考：

参考：OpenAI API 模型和定价

对于一个人来说，节省并不显著。当用户和 agent 的数量增加时，它变得更加重要。

场景 2：拥有 100 个用户的公司

Users:                          100
Calls per user per day:          50
Total calls per day:          5,000
Average history:             20,000 tokens
Retrieved context:            2,000 tokens

月度避免的输入：

5,000 × 18,000 × 30
= 2.7 billion tokens

在这种规模下，内存不再仅仅是一个产品特性。

它变成了一个基础设施决策。

场景 3：拥有长期运行 agent 的平台

考虑一个处理以下内容的平台：

10,000 calls per day
32,000 history tokens per call
 2,000 tokens retrieved by ASM-CM

这是每次调用减少 30,000 个输入 token。

10,000 × 30,000 × 30
= 9 billion avoided tokens

这些数字假设未缓存的输入，还未扣除本地内存基础设施的成本。

那 prompt 缓存呢？

此比较必须解决一个重要的异议：

LLM 提供商会对缓存的输入 token 打折。

对于参考模型，缓存输入目前的成本大约是常规输入的十分之一：

参考：OpenAI 模型对比

如果每个被移除的历史 token 都能获得完美的缓存命中，节省也将大约减少十倍。

对于避免 27 亿 token 的企业场景：

真实部署通常位于这两个极端之间。

静态 prompt 部分可能被缓存，而新事件、工具结果和检索的内存继续变化。

因此，认真的比较必须衡量：

常规输入 token；

每次交互的总成本。

第二项节省：KV 缓存

当 LLM 在本地运行时，另一个成本变得重要：Transformer 的 KV 缓存。

在生成过程中，Transformer 通常保留与以前 token 相关联的键和值。

确切的大小取决于架构，但我们可以使用以下方式构造一个说明性示例：

32 layers
8 KV heads
head dimension 128
BF16

每个 token 的近似存储将是：

2 × 32 × 8 × 128 × 2 bytes
= 131,072 bytes
= 128 KiB per token

128 KiB × 32,768
≈ 4 GiB per stream

如果内存层将发送给 LLM 的上下文从 32K 减少到 2K：

此估计不适用于所有 Transformer。使用分组查询注意、量化或其他优化的模型将有不同的数字。

基本属性仍然相关：

减少活跃上下文也可以减少 KV 缓存所需的内存。

我们用 ASM-CM 测量的结果

在当前实验协议中，ASM-CM 取得了以下成果：

100% MQAR 在 32K 时的检索；

跨三个种子的批准；

每个流大约 140 KiB 的保留状态；

评估组件约 363.66 MiB 的峰值 VRAM；

15 个内存试点案例全部通过；

每个字符最多 10,000 个干扰项后的检索；

与三个独立训练的检查点确认；

一小时的定时耐久性测试，伴随真实流程重启；

快照、恢复和哈希验证。

这些测量的范围很重要：

约 363 MiB 的数字属于在测量协议下的 ASM-CM 组件。

完整应用程序还需要以下内存：

一千个 agent 是否需要一千个模型？

模型可以共享，同时每个 agent 保留独立的状态。

在每个流大约 140 KiB 的情况下：

1,000 × 140 KiB
≈ 137 MiB

添加测量的共享组件：

ASM-CM component:       approximately 366 MiB
One thousand states:    approximately 137 MiB
Approximate total:      approximately 503 MiB

这是一个状态存储投影，而不是一千个并发 agent 的基准。

我们仍需要测量：

聚合吞吐量；

生产资源消耗。

隐私也有经济价值

还有另一项节省不会直接出现在 API 发票上。

如果完整历史反复发送到外部 LLM，组织必须管理：

敏感信息的泄露；

本地内存架构支持不同的流程：

private local data
        ↓
ASM-CM
        ↓
associative retrieval
        ↓
authorization
        ↓
minimum context
        ↓
LLM

这并不能自动使系统安全。

防止内存中毒。

但它引入了一个重要的架构区分：

产生答案的模型不需要接收组织的完整内存。

节省应该在哪里最大？

当以下情况时，ASM-CM 应该在经济上更有趣：

有许多交互；

只有一小部分过去相关；

每个用户或 agent 需要隔离内存；

数据必须保持本地；

外部 LLM 很昂贵；

KV 缓存限制本地推理；

agent 继续运行数天或数月。

当以下情况时，节省应该更小：

对话很短；

历史获得近乎完美的缓存命中率；

外部模型非常便宜；

几乎整个历史都必须被检索；

本地基础设施成本超过消除的 token。

我们仍需要的基准

要将此投影转变为经过验证的商业主张，我们需要比较：

Complete history
vs.
Prompt caching
vs.
Summarization
vs.
Vector RAG
vs.
ASM-CM

基准必须衡量：

常规输入 token；

每千次交互的成本；

安全和隔离。

仅仅成本更低还不够。

检索的内存必须保持正确。

在一个说明性的企业场景中：

平均历史 20K token；

检索的上下文 2K token；

像 ASM-CM 这样的内存层每月可避免大约 27 亿个输入 token。

取决于模型和缓存利用率，这可能代表每月数百或数千美元。

在更大的平台规模，潜在节省可能达到每月数万美元。

但最重要的价值可能不是纯粹的财务。

这是构建以下 agent 的可能性：

仅检索必要的内容；

保持私有数据本地；

披露更少信息；

不必在每次决策前重新加载整个过去。

也许更好的 agent 不需要同时记住一切。

也许他们需要在正确的时刻记住正确的事情。

ASM-CM 是一个实验性的 AletheionAGI 项目。

我们正在为 agent、游戏和本地系统中的持久内存试点选择合作伙伴。

联系：contact@aletheionagi.com

对于进一步的操作，您可能需要考虑屏蔽此人和/或报告滥用