大语言模型在语言理解与生成方面已经展现出惊人的能力，但其记忆能力始终是核心瓶颈。无论上下文窗口扩展到多长，用户始终面临信息遗忘、幻觉产生以及历史对话无法有效利用的问题。传统的解决方案往往只能解决单一维度的记忆需求，而 Supermemory 通过向量搜索与知识图谱的混合存储架构，配合边缘计算基础设施，成功实现了支撑每用户五千万 tokens 记忆规模、每秒处理超过五十亿请求的工程目标。本文将从存储层设计原理、基础设施选型逻辑以及生产环境参数三个层面，解析这一记忆引擎的核心技术实现。
单层存储的局限性：从向量数据库到知识图谱的困境
在构建 LLM 记忆系统时，开发者通常首先想到的是向量数据库方案。这种方法将文本转换为高维向量嵌入，通过相似度计算实现语义检索。然而，随着数据规模增长，向量数据库面临严峻的成本与性能挑战。当向量数量达到数百万级别时，即使采用最新的分层索引技术，查询延迟也会显著上升。更关键的是，纯向量检索无法捕捉实体之间的复杂关系 —— 它只能告诉你 "这段内容与那段内容语义相似"，却无法回答 "这个概念如何关联到另一个概念" 这类关系型问题。
图数据库在关系表达方面具有天然优势，通过节点与边的结构可以精确建模实体间的关联。但图查询的性能特征与向量搜索截然不同：每次查询可能需要遍历数倍于目标节点的边，这在大规模图上会造成严重的延迟波动。此外，图的构建与维护成本极高，新增一条关系往往意味着更新多个关联节点的索引结构。对于需要高频写入的记忆系统而言，这种开销难以接受。键值存储方案看似简单，将完整记忆以键值对形式存储后通过检索获取，但受限于 LLM 的上下文窗口长度，这种方案实际上将问题从 "记忆存储" 转移到了 "记忆压缩"，本质上是一种逃避而非解决。
Supermemory 的核心洞察在于：记忆系统需要的不是某种单一的最优数据结构，而是一套能够根据不同访问模式动态调度资源的混合架构。向量索引负责语义相似性召回，图结构维护实体关系与推理路径，关系型数据库则承担元数据存储与事务一致性保证。三者各司其职，通过统一的查询路由层实现对上层应用的无缝支持。
混合存储架构的设计原理与数据流转
理解 Supermemory 的存储架构，首先需要厘清一条记忆从入库到召回的完整数据流转。当用户添加一段内容时，系统首先进行语义切分，将长文本拆分为适合独立检索的片段。这一步骤的关键参数是分块大小与重叠策略：分块过大可能导致语义模糊，过小则会破坏上下文连贯性。Supermemory 采用基于语义的动态分块算法，而非简单的固定长度切分，这需要调用语言模型对文本结构进行初步分析。
分块完成后，每个片段被转换为向量嵌入。这一过程涉及模型选择与维度权衡：高维嵌入（如 1536 维的 text-embedding-ada-002）能够保留更丰富的语义信息，但存储与计算成本也相应增加。Supermemory 支持多模型嵌入，并提供自动降维选项，允许用户在精度与效率之间做出动态平衡。向量数据被写入自定义向量引擎，而原始文本与结构化元数据则存入 Postgres 数据库。图结构的更新是异步进行的：系统通过命名实体识别提取内容中的关键实体，自动构建或更新实体间的关联边。这种分离设计确保了写入路径的低延迟 —— 用户无需等待图索引构建完成即可立即进行检索。
召回流程体现了混合架构的真正价值。当应用发起记忆查询时，查询首先被编码为向量，在向量引擎中执行初步相似度检索，获取候选记忆片段。随后，系统根据候选片段中的实体标识，查询图数据库获取关联记忆，形成 "语义相近 + 关系相连" 的双重筛选结果。最后，关系型数据库中的元数据（创建时间、访问频率、用户标签等）用于最终排序与过滤。整个流水线设计保证了在大多数场景下，亚 400 毫秒的端到端延迟是可实现的。
边缘优化基础设施：Cloudflare Durable Objects 的工程考量
基础设施选型往往决定了系统性能的上限与下限。Supermemory 的技术栈围绕 Cloudflare 生态构建，包括 Cloudflare Workers、KV 存储、Pages 以及核心的自定义向量引擎 —— 基于 Cloudflare Durable Objects 实现的分布式向量索引。这一选择背后有着清晰的工程逻辑。
传统的向量数据库通常需要长期运行的服务器实例，这不仅带来固定的运维成本，还面临跨地域延迟的挑战。Cloudflare Durable Objects 提供了另一种思路：将向量索引以状态 ful 容器的形式部署在全球数百个边缘节点上。每个 Durable Object 负责特定分片的数据管理与查询执行，由于容器本身具备状态保持能力，向量索引可以常驻内存而无需频繁磁盘 IO。对于查询请求，Cloudflare 的智能路由会将其导向最近的边缘节点，显著降低网络往返延迟。官方数据显示，这一架构能够支撑每用户五千万 tokens 的记忆规模，这与边缘部署的低延迟特性密不可分。
Postgres 的角色同样关键。它负责存储那些不适合放在边缘的 "重量级" 数据：用户配置、历史会话记录、访问控制策略等。Drizzle ORM 提供了类型安全的数据库访问接口，使得业务代码与数据库模式的同步更加可靠。Supermemory 采用连接池优化与读写分离策略，确保数据库层不会成为整体架构的瓶颈。需要注意的是，Postgres 本身并非部署在边缘，而是使用托管数据库服务，这种混合部署模式平衡了边缘计算的低延迟与关系型数据库的可靠性需求。
生产环境工程参数：从基准测试到调优策略
理论设计需要转化为可操作的工程参数才能真正落地。基于公开的技术文档与社区实践，以下是 Supermemory 架构中几个关键的可配置维度与推荐值。
向量维度与模型选择构成第一组权衡。默认配置下，系统使用 1024 维嵌入，这在大多场景下提供了足够的语义表达能力与可接受的存储开销。若应用涉及大量专业术语或需要更精细的语义区分，可考虑切换至 1536 维模型。对于性能敏感型场景，Supermemory 支持在线量化，将浮点向量压缩为二进制或整数量化格式，存储空间可减少四到八倍，而检索精度损失通常控制在百分之五以内。分块策略方面，经验值为单块 500 至 800 tokens，重叠区域设置为块大小的百分之十五至二十五。这一配置能够有效避免语义断裂，同时控制总体索引数量。
缓存策略对延迟影响显著。Supermemory 在边缘节点维护多层缓存：热点向量的内存缓存、频繁查询结果的应用层缓存、以及基于用户 ID 的个性化记忆缓存。缓存淘汰采用 LRU 策略与频率计数相结合的算法，命中率在活跃用户群体中可达百分之七十以上。对于新写入的记忆，系统提供 "预热" 接口，触发后台的主动缓存填充，确保首次查询不会出现冷启动延迟。容错与降级机制同样重要：当向量引擎因负载过高无法在时限内响应时，系统会自动切换至纯图检索模式，虽然召回率有所下降，但可用性得到保证。
资料来源
本文核心信息参考自 Supermemory 官方技术博客（2025 年 6 月《Architecting a memory engine inspired by the human brain》）、官方文档（概念与架构章节）以及 GitHub 开源代码仓库（技术栈与基础设施配置）。