Zep按字节计费：1.5万条Episode如何从$125跳到$375

Zep的定价不看你写入多少条Episode，而看每条Episode有多大。一个credit覆盖前350字节，之后每350字节（或不足350字节的部分）再加一个credit——公式就是credits = ceil(bytes / 350)。

有人拿每月固定15,000条Episode跑了这个公式，只改变平均Episode大小，结果账单从$125一路涨到$375，写入次数一次没变。

同一个写入量，三倍账单

以每月15,000条Episode为例，按Zep定价页的套餐与额度计算：

平均Episode大小	每条credits	月credits	落点
300 B	1	15,000	Flex，$125
700 B	2	30,000	Flex，$125
1,200 B	4	60,000	Flex加一次top-up，$150
3,500 B	10	150,000	Flex Plus，$375

从300字节到3,500字节，credit消耗翻了十倍，账单翻了三倍。对产品团队来说，这意味着一次看似无关的集成改动，就可能把成本悄悄推高一档。

这里的 credit 是 Zep 的计费单位，与套餐额度绑定。Flex 套餐每月包含一定数量的 credits，超出后需 top-up 或升级到更高档位。表格中的“落点”指 15,000 条 Episode 产生的月 credits 落在哪个套餐区间，从而决定账单金额。值得注意的是，credits 消耗与写入次数解耦，仅由每条 Episode 的字节数决定，因此平均大小的微小变化可能引发档位跃迁。

公式没收费的部分，也要看清楚

这不是一篇纯粹讨伐Zep的文章。Zep对检索、存储、thread、用户和graph存储都不收费——如果你的产品读多写少、写入体积小，跑在Zep上反而便宜。而且计费公式是公开写出来的，不是藏在合同细则里，这一点比一些竞品做得透明。

真正的问题在于：Episode大小是这个产品里最不可控的变量。一个客服集成最初只发送消息正文，后来加上了工单元数据、历史状态和系统备注——写入频率没变，但落点从表格第一行滑到了最后一行，而且没有人为此提过需求。

自托管Zep，2025年4月起不再是退路

过去可以自己部署，现在不行了。Zep在2025年4月宣布调整开源策略，Community Edition被废弃。目前开源的是底层的时序图引擎Graphiti，而不是Zep这个服务本身。定价页上的“免费层”指的是每月10,000 credits的托管套餐，按700字节的Episode算，大约5,000次写入。

所以“自己跑”意味着换一个项目，关键问题变成：你到底想保留Zep的哪一部分。

Graphiti 是 Zep 开源的时序图引擎，支持实体和关系的时间有效性区间，可回答“某个时间点什么是成立的”。它需要搭配图数据库（如 Neo4j、FalkorDB、Neptune）使用，并提供 Server 和 MCP 适配器以便自托管。但 Graphiti 仅提供引擎能力，不包含 Zep 服务层的身份认证、队列、监控、备份等产品化功能，因此从 Zep 迁移到 Graphiti 意味着需要自行构建这些基础设施。

六个替代方案，先看全景

替代方案	替代的是什么	存储	托管选项	成本转移方向
Graphiti	Zep的时序图引擎	Neo4j、FalkorDB、Neptune	Zep本身	自运维图数据库
Statewave	图栈上的主体记忆	Postgres + pgvector	无	Postgres加编译期LLM调用
Hindsight	召回加学到的观察	Postgres或pg0	有	推理成本，而且更多
Cognee	文档与代码知识图谱	关系型、图、向量	有	配置时间
Mem0	熟悉的按用户记忆API	可配置向量库	有	向量库与抽取调用
Letta	有状态Agent运行时	内存块与MemFS	有	编排重写

这里没有对图能力做统一打分。很多读者离开Zep的原因恰恰是不想再让图数据库待在关键路径上，统一打分反而会奖励Graphiti——而那正是他们想删掉的需求。

六个方案逐个拆

1. Graphiti：保留Zep的模型，丢掉服务

最接近“保留Zep模型”的选项，因为它就是Zep的模型：实体和关系各自携带有效期区间，可以查询某个日期上什么是成立的。Server和MCP适配器都能自托管。

但它以引擎而非产品形态交付。身份认证、队列、监控、备份、schema和应用API都得自己建、自己维护。成本转移到你运维的图数据库，以及构建图谱的抽取调用。

2. Statewave：Postgres上的主体记忆加策略层

原始Episode只追加、不可变，与从中编译出的类型化记忆分开存放，每条记忆带置信度、有效期和来源Episode ID。记忆按主体（用户、账户、工单、Agent或仓库）划分，而不是每个用户一张图。检索在token预算下运行，YAML策略对敏感标签执行deny和redact，并输出组装包的签名回执。

成本转移到一套Python服务加Postgres，以及编译时的LLM调用。

主体（subject）是 Statewave 中记忆归属的实体，可以是用户、账户、工单、Agent 或仓库。与按用户分图不同，Statewave 按主体组织记忆，每个主体拥有独立的记忆集合，便于跨会话和跨场景的隔离与检索。策略层通过 YAML 定义对敏感标签的 deny 和 redact 规则，并在检索时输出组装包的签名回执，以证明策略被执行。

3. Hindsight：让Agent做整合而非召回

保留世界事实与经验，再把它们整合为观察和心智模型，对两者做reflect，四条召回路径并行。适合想要“形成有证据支撑的信念”而非“召回行”的Agent。Retain是异步的，bank和租户设计要早做决定。成本转移到模型调用，而且因为reflect就是推理，调用量会更多。

reflect 是 Hindsight 中的核心操作，指 Agent 对世界事实和经验进行推理整合，形成观察和心智模型。与传统的召回（retrieval）不同，reflect 不是简单返回匹配的行，而是基于证据生成信念。四条召回路径并行工作，分别处理不同类型的信息。由于 reflect 涉及推理，会消耗更多模型调用，因此成本主要转移到推理侧。

4. Cognee：异质语料与代码

从文档、代码加上会话历史构建图与向量知识层，分布在关系型、图和向量后端上，本地开发有嵌入式默认值。在这份清单里最适合混合语料和文档/代码GraphRAG。成本主要转移到配置时间——它的接口面很宽，默认配置撑不到生产环境。

5. Mem0：迁移量最小

熟悉的按用户记忆API，可配置向量库，一下午就能接入。但自v3开源SDK起，图记忆只在Platform版提供——如果你离开Zep就是为了不再为图功能付费，迁移前务必确认你需要的功能在哪个版本里。成本转移到你的向量库和抽取调用。

6. Letta：如果你本来就要换运行时

可编辑内存块加transcript，再加一个Git支持的内存文件系统，全部位于有状态Agent运行时内。六个方案里记忆设计最“有主见”，版本化文件系统对审计“上周二这个块说了什么”确实有用。代价是范围——它替换的是Agent运行时，不只是记忆层。成本转移到编排重写。

作者自曝短板

Statewave的作者也列出了自家方案的失败场景：

• 没有实体关系图，没有遍历。如果你的产品核心问题是“3月3日什么是成立的，以及它如何从另一件事推导出来”，Graphiti才是诚实答案。
• 没有托管云，没有跨区域集群。
• 租户隔离在应用层执行，不依赖Postgres行级安全。
• 服务端仅在Linux上做过CI测试。

切换前必跑的四个测试

挑一个候选方案，把一个月真实Episode回放到两个后端，检查这四项：

1. 变化的事实：某个值在历史中途更新。新后端返回当前值吗？还能看到旧值吗？
2. 跨会话召回：会话2说过的内容，在会话9不点名也能浮现。
3. 被拒绝的敏感上下文：策略应当扣留的记忆不出现在组装上下文里，而且事后能区分“被扣留”和“不存在”。
4. 主体删除：删掉一个主体，再搜索它的痕迹。半删除是常见故障，而且悄无声息。

然后建模账单。有了字节大小，那个脚本一分钟就能算出Zep这一侧的数字。如果没有，先去测量——整个决策都压在这个数上。