企业官网建设流程全解析

本地LLM派还是云端API派？Supermemory五种部署姿势横评，隐私团队照抄

【免费下载链接】supermemoryMemory and context engine + app that is extremely fast, scalable, and can be run fully locally. The Memory API for the AI era.项目地址: https://gitcode.com/GitHub_Trending/su/supermemory

给 AI 装"长期记忆"正在成为 Agent 工程的新基础设施层。但记忆层与普通 API 服务有个本质区别：它是长驻运行的，你投喂进去的是对话记录、用户画像、内部文档这类最敏感的数据。于是部署问题从"技术细节"上升成了"合规决策"——数据留在哪、模型跑在哪、提取质量能换多少隐私，直接决定了你选哪条路。

Supermemory 的特殊之处在于，它把这个问题拆成了五条可以自由组合的路径：托管云平台、单机自托管二进制、全离线本地 LLM、混合架构（本地记忆引擎 + 云端模型）、以及面向无服务器环境的 SMFS 文件系统。官方文档的原话是"can be run fully locally"（README），而仓库里自托管文档则把整条链路拆成了"一个引擎、同一套 API、五种跑法"。本文基于官方文档与仓库源码，把五种部署姿势、隐私取舍和分场景选型表一次讲清楚。

一、先看懂架构：为什么同一个引擎能拆出五种跑法

Supermemory 的核心不是"向量数据库套壳"，而是两个自有组件（How Supermemory works）：

• 学习模型（learning model）：决定学什么、什么重要、何时遗忘、如何建立关系；
• 时序向量图谱引擎（temporal vector-graph engine）：事实存储与检索底座，向量、全文检索、图谱三合一。

一条数据进来走的是固定流水线：queued → extracting → chunking → embedding → indexing → done，随后进入第二阶段dreaming（记忆入图）。dreaming 分两种模式：dynamic把相关文档打包成"连贯单元"再生成记忆，适合生产环境；instant单文档立即入图，适合 demo 和需要即刻可查的场景（quickstart.mdx）。最终同一份文档产出三样东西：Document chunks（RAG 检索用）、Memories（图谱事实）、Profile（用户画像，约 50ms 一次调用）。

关键在于：本地自托管服务器与托管平台讲的是同一种 API。SDK 只需要改一行baseUrl就能在两者之间切换（overview.mdx）：

const client = new Supermemory({ apiKey: "sm_...", // 首次启动自动生成 baseUrl: "http://localhost:6767", // 唯一要改的地方 })

正是"同一 API、不同后端"的设计，让五种部署姿势有了横向对比的基准。而隔离模型也很朴素——每个命名空间（namespace，v3/v4 时代的 container tag）是一条硬隔离边界，用户、租户、项目各占一个空间（quickstart.mdx）。

二、五种部署姿势逐一拆解

姿势一：托管云平台——全家桶模式

这是功能最全的路线。console.supermemory.ai负责发 key 与用量管理，api.supermemory.ai承接所有请求；云端跑的是官方专有模型，专门为"长周期数据理解与记忆提取"调优，提取质量最高、规模化成本最低（overview.mdx）。

云端独占四样东西（configuration.mdx 明确定义为 platform-only）：

• Connectors：Google Drive、Gmail、Notion、OneDrive、GitHub、Granola、Web Crawler 的实时同步（webhook + 每 4 小时定时），详见 connectors/overview.mdx；
• Supermemory MCP：托管在https://mcp.supermemory.ai/mcp的 MCP 服务，走 OAuth，可直接接入 Claude Desktop、Cursor、ChatGPT Web 等客户端（apps/mcp/README.md）；
• 优化的记忆提取管线：比自带 key 更高质、更低成本；
• 托管规模：全球分布式基础设施，无需自己做容量规划。

一句话总结：要 Connectors、要 MCP、要组织级管控，就别想着自托管——这些功能在自托管二进制里是物理不存在的。

姿势二：单机自托管二进制——零配置私有化

这是"一条命令、一个进程、一个目录"的路线：

curl -fsSL https://supermemory.ai/install | bash # 或 npx supermemory local supermemory-server

首次启动会完成三件事：内嵌图谱引擎自动建库（无需任何数据库）、本地 embedding 模型Xenova/bge-base-en-v1.5（768 维）直接内置、并打印专属 API key：

┌──────────────────────────────────────────────────┐ │ url http://localhost:6767 │ │ database ./.supermemory │ │ api key sm_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx │ │ org id xxxxxxxxxxxxxxxxxxxxxx │ └──────────────────────────────────────────────────┘

所有状态落在一个目录./.supermemory/（或$SUPERMEMORY_DATA_DIR），备份就是拷贝目录，迁移就是搬目录（quickstart.mdx）。许可证方面，自托管在 lite license 限额内免费；需要提醒的是服务器二进制本身不开源（开源的是 SDK 与周边组件），托管平台才是完整产品所在地（local-vs-enterprise.mdx）。

姿势三：全离线本地 LLM——数据真正不出门

自托管二进制的杀手锏是"完全离线"。因为 LLM 只负责摘要、上下文分块和记忆提取这些智能步骤，而它们都走 OpenAI 兼容端点协议——这意味着 Ollama、LM Studio、vLLM、llama.cpp 全都能顶上（configuration.mdx）：

OPENAI_BASE_URL=http://localhost:11434/v1 \ OPENAI_API_KEY=ollama \ OPENAI_MODEL=gpt-oss:20b \ supermemory-server

本地图谱引擎 + 本地 embedding + 本地 LLM 三者齐备后，文本记忆处理在 embedding 模型首次下载完成后可以全程留在本机。补上两个开关就能做到零出网：

• SUPERMEMORY_DISABLE_TELEMETRY=1关闭遥测；
• URL 摄取用的是托管 reader 服务，离线场景请改用本地文本或文件输入（overview.mdx）。

代价也很具体：提取质量完全取决于你本地模型的水平；默认的本地 embedding 是纯英文模型，非英语语料的语义召回会明显变弱（多语言方案见下）；大模型对硬件有要求，gpt-oss:20b是笔记本级 GPU 的推荐起点（providers.mdx）。

姿势四：混合架构——本地记忆引擎 + 云端模型 API

隐私团队的典型折中方案：记忆与数据留在自己机器上，提取质量交给商业模型。自托管服务器支持 OpenAI、Anthropic、Gemini、Groq、Cloudflare Workers AI、Vertex 等所有主流提供商（configuration.mdx）：

# 只填一个 key 就够 OPENAI_API_KEY=sk-... # 可选：不填则保持本地 Xenova/bge-base-en-v1.5 (768d) # SUPERMEMORY_EMBEDDING_PROVIDER=openai # SUPERMEMORY_EMBEDDING_MODEL=text-embedding-3-small # SUPERMEMORY_EMBEDDING_DIMENSIONS=1536

编程插件也支持这种姿势：Claude Code、Muse Code、Codex、OpenCode 全部可以指向本地服务器，只需设置SUPERMEMORY_API_URL=http://localhost:6767（overview.mdx；OpenCode 插件文档也明确写了"想全部留在本机？插件与自托管版一起用"）。这类"本地记忆 + 云端推理"的混合架构，正是社区教程反复强调的高隐私需求场景主流解法。

姿势五：边缘/无服务器——SMFS 文件系统

第五条路不再以"服务器"为形态，而是把记忆容器挂载成一个真实目录，让 Agent 用ls、cat、grep直接操作记忆（SMFS 总览）：

• 语义化 grep 默认开启：一条命令跨全容器按语义排序召回，加参数才退回字面 grep；
• 记忆路径蒸馏：标记为 memory path 的文件会被提取索引，不撑爆模型上下文；
• 虚拟profile.md：挂载根目录下实时生成容器摘要，cat profile.md即得全貌；
• 双向同步：本地读走缓存，写入推回 Supermemory。

SMFS 提供两种形态：mount 二进制（NFSv3/FUSE，适合 Claude Code、devcontainer、Docker）和bash tool（TypeScript 与 Python 版本），后者专为无服务器环境设计，官方给了 Cloudflare Workers、AWS Lambda、Vercel、Modal 的接入示例，以及 Daytona、E2B 等沙箱提供商的对接指南（smfs/providers）。仓库数据还给出一个硬指标：SMFS 在 110 题的 xAFS 基准上让 Claude 的 token 消耗降为原来的约 1/3、Codex 约降 43%（README）。

三、隐私敏感场景的取舍：数据主权与性能平衡

把五种姿势按"数据流向"排开，取舍一目了然：

这里有几个部署红线，隐私团队务必照抄：

1. 多语言语料必须换 embedding。默认的Xenova/bge-base-en-v1.5只训练了英文。德语、荷兰语等非英语语料即使混检（hybrid keyword）偶尔能召回稀有 token，稠密语义召回也会失效。多语言部署要在大批量回填前切换，例如本地换Xenova/bge-m3（1024 维），或改用远程多语言 API（embeddings.mdx）：

SUPERMEMORY_EMBEDDING_PROVIDER=local SUPERMEMORY_EMBEDDING_MODEL=Xenova/bge-m3 SUPERMEMORY_EMBEDDING_DIMENSIONS=1024

2. 维度锁与模型混用是真实踩过的坑。文档记录了一个 v0.0.5 的线上事故：写入路径用 OpenAI embedding、读取路径却用本地默认模型，导致日文等无语义空格的语言在/v4/search与/v4/profile上静默返回空结果；v0.0.7 通过"全路径锁定 embedding 计划"修复。而变更 embedding 模型/维度不支持原地切换——要么全新数据目录，要么全量重灌，维度不一致时服务器直接拒绝启动（embeddings.mdx）。

3. 别把自托管服务器裸奔到公网。当前发布的 v0.0.8 绑定所有网络接口且本地认证隐式开启，官方文档的警告原文是"Do not expose it"——必须用防火墙隔离或跑在独立机器上，下一个版本才会改为仅绑定回环地址并要求每个请求都带 key（configuration.mdx）。

4. 吞吐与内存可控。查询永远优先于摄取（搜索绝不在摄取队列后面排队），摄取内存占用被限制在启动基线之上最多 1GB（SUPERMEMORY_EMBEDDING_RAM_LIMIT，可调），超限时新文档排队而不是丢弃。大机器上可以放宽并发与内存做批量导入，小 VPS 上调低以保持轻盈（configuration.mdx）。

四、给团队的分场景选型决策表

横向对比的核心矛盾始终是：数据主权、提取质量、运维成本，三选二。想要 Connectors 和 MCP 全家桶，就接受数据进云；想要零出网，就接受本地模型的提取上限或添购推理硬件；大多数隐私团队的最优解，落在那条"本地引擎 + 商业模型 API"的混合路径上——它同时拿到了数据主权的底线与当下最好的提取质量。

值得强调的是，无论哪种姿势，API 是同一套：在本地把 Agent 打磨好，换一个baseUrl就能迁到托管平台（或反向），local-vs-enterprise.mdx 给出的迁移路径就是这么简单。这也是我认为"部署姿势之争"本质上是伪命题的原因——真正的变量从来不是"选哪边"，而是"你想把哪一层数据主权握在自己手里"。先按上表选好姿势，再把提取模型与 embedding 模型配置锁死，剩下的事情，交给同一套记忆 API 就好。

【免费下载链接】supermemoryMemory and context engine + app that is extremely fast, scalable, and can be run fully locally. The Memory API for the AI era.项目地址: https://gitcode.com/GitHub_Trending/su/supermemory