大模型记忆该放哪里：外部记忆服务部署实战

一、部署概述：先定”记忆放哪里”，再定”部署什么”

当前主流大模型的基本骨架是一套由嵌入层、多层注意力与前馈网络堆叠而成的深度神经网络结构，模型的绝大部分”知识”以参数形式固化在权重文件里。这意味着两件事：一是模型的记忆天然存放在参数中，二是这种记忆难以按条增删、难以追溯来源、也难以满足”用户要求删除某条信息”这类合规诉求。所以工程上要做的并不是”把记忆塞进模型”，而是围绕模型外围搭建一套可控的记忆体系，再把它部署成一个独立可运维的服务。

本文的部署对象：一个对外提供接口的外部记忆服务（Memory Service），具备四类能力——写入（记录事实与对话要点）、检索（按语义召回相关记忆）、更新与淘汰（覆盖、过期、显式遗忘）、上下文组装（在有限的上下文预算内把记忆拼装进提示词）。

部署完成后的预期效果：

• 模型推理服务保持无状态，可自由扩缩容、滚动升级；
• 会话结束后用户偏好、任务进展、领域事实仍然可查；
• 每条记忆可定位、可追溯、可按租户隔离、可按请求删除；
• 检索延迟与上下文长度可控，成本可预测。

适用读者：负责把大模型能力落成线上服务的后端开发者、负责资源与稳定性的运维工程师、负责选型与容量规划的架构师，以及有数据留存与审计要求的企业技术团队。

部署前应理解的背景：推理服务的形态（同步接口/流式输出/离线批处理）、目标并发与响应时延要求、单条记忆的体量、数据敏感等级与留存期限、是否要求跨会话与多用户隔离。这些直接决定后面选哪种记忆位置、用哪些资源规格。

二、三种记忆位置的取舍：决策先于部署

记忆位置	容量特性	写入成本	可删除/可审计	典型适用
参数内（权重、微调）	总量大但更新即全量	高，需训练或增量训练	弱，难按条删除	稳定的风格、格式、领域语感
上下文内（提示窗口）	受窗口长度硬约束	极低	会话结束即失效	当前轮次、临时推理中间结果
外部记忆（服务+存储）	近乎可无限扩展	低，一次接口调用	强，可按条增删改查	用户画像、长期事实、历史轨迹、企业知识

结论并不含糊：参数记”怎么做”，上下文记”当下”，外部记忆记”长期”。因此绝大多数在线业务需要的部署工作，其实是部署一套外部记忆服务，并把它编排进推理链路。对于必须支持”删除某条个人信息”的场景，外部记忆几乎是唯一工程可行方案——因为权重里的信息无法按条摘除。

三、部署场景

1. 多轮助手跨会话记忆：记住用户称呼、偏好、常用参数，新会话开始时自动召回。
2. 企业知识问答：文档解析入库形成长期记忆，对话中沉淀的有效结论回流为记忆。
3. 智能体长期任务：记录任务目标、已完成步骤、工具调用结果与中间产物，支撑断点续跑。
4. 个性化推荐与画像：以结构化标签加语义文本混合存储用户长期兴趣。
5. 合规敏感场景：需要留存审计日志、支持按主体删除、要求数据不出特定网络区域。

四、架构与组件拆解

层次	组件	职责与部署要点
接入层	负载均衡、API 网关	统一入口、TLS 终止、鉴权、限流、按租户路由
应用层	记忆服务（无状态，多副本）	编排写入/检索/淘汰逻辑，控制上下文预算
模型层	嵌入服务、可选重排服务、可选摘要生成	无状态、可独立扩容；版本必须与向量库登记绑定
存储层	向量索引库、关系型数据库、对象存储、缓存	分别承载向量、元数据、原文、热点结果
异步层	消息队列与后台任务	离线索引构建、批量摘要、TTL 清理、慢任务削峰
观测与安全	日志服务、监控告警、链路追踪、密钥管理	全链路 trace_id、指标看板、告警规则、密钥托管

在百度智能云等主流云平台上，上述组件通常对应云服务器、容器平台、对象存储、数据库、缓存服务、消息队列、负载均衡、日志服务、监控告警与身份认证等通用产品类目，具体规格与配额以实际控制台为准。

三条核心链路需要在部署前就想清楚：

• 写入链路：清洗脱敏 → 切分 → 去重 → 生成嵌入 → 写向量索引 → 写元数据 → 存原文 → 异步摘要。
• 读取链路：查询改写 → 并行召回（向量 + 关键词 + 结构化过滤）→ 重排 → 组装进上下文 → 返回并记账。
• 淘汰链路：TTL 过期、容量水位淘汰、显式遗忘请求（需同时清理向量、元数据、原文、缓存与摘要派生数据）。

五、前置准备清单

账号与权限：准备独立资源账号或项目；创建最小权限子账号；密钥托管在密钥管理服务，禁止写入代码库、镜像与配置文件明文。

资源规格估算（务必先算再买）：

向量库原始容量 ≈ 记忆条数 × 向量维度 × 4 字节
含索引与副本的实际占用 ≈ 原始容量 × 索引膨胀系数(常见 2~4) × 副本数
示例：1000 万条 × 1024 维 × 4B ≈ 40 GB
      → 含 HNSW 类索引与 2 副本，规划 200~350 GB 较为稳妥
嵌入调用量/秒 ≈ 写入条数/秒（每条一次，批量可摊薄）
读 QPS = 会话并发 × 每轮召回次数

同时预留 CPU/内存余量应对索引重建，预留带宽应对全量导入。

依赖与制品：运行时版本、依赖清单锁定（避免浮动版本导致环境漂移）、应用镜像、配置模板、数据库与索引的迁移脚本。

数据准备：明确记忆条目的字段规范、切分粒度、时间戳与时区、租户标识；对历史语料完成脱敏与去标识化。

网络与安全准备：私有网络与子网划分、安全组仅放通必要端口、内外网访问路径、域名解析与证书、调用方白名单、传输与静态加密开关。

六、部署流程（按阶段推进，每步都有前置依赖）

阶段 0：环境与基线
初始化资源账号、网络、镜像仓库与制品仓库；固定运行时版本；确认开发/测试/生产三套环境的依赖版本一致。这一步决定后续能否复现问题——环境漂移是”本地能跑线上报错”的首要原因。

阶段 1：创建依赖组件
按估算规格创建向量索引库、关系型数据库、对象存储、缓存、消息队列，并开启日志与监控接入。先建存储再建应用，是因为应用启动时的健康检查通常要探测依赖连通性，顺序颠倒会导致启动即失败。

阶段 2：构建与推送制品
在流水线中完成依赖安装、静态检查、单元测试、镜像构建与安全扫描，推送至制品仓库并打不可变标签（禁用 latest）。不可变标签是回滚的前提。

阶段 3：配置与密钥注入
配置项分为三类处理：环境相关（连接地址、端口、副本数）、环境无关（切分大小、top_k、超时）、敏感（密钥、口令）。第三类只走密钥管理或环境变量注入。

阶段 4：初始化数据结构
执行数据库迁移、创建向量索引与元数据表、建立必要索引。迁移脚本必须幂等，可重复执行；同时登记当前嵌入模型版本，作为后续向量一致性的基准。

阶段 5：启动服务与自检
容器平台按副本数拉起实例，通过存活探针判断是否重启、就绪探针判断是否接流。就绪探针未通过前不应有流量进入，否则会在依赖未就绪时返回错误。

阶段 6：对外暴露
挂载负载均衡、绑定域名、上传证书、配置鉴权与限流、设置超时与最大请求体。写接口与删接口应与读接口分设限流阈值，避免批量写入挤占在线召回。

阶段 7：数据初始化与预热
批量导入历史文档与既有会话摘要；导入完成后预热索引与缓存（跑一批代表性查询），否则上线首分钟的 P99 会显著偏高。

阶段 8：灰度发布
按小比例流量切入，对比新旧版本的召回质量、延迟与错误率；保留旧版本实例不销毁，作为回滚锚点。

阶段 9：验证与观测确认
执行下一节的验证清单，确认监控有数据、告警能触发。

阶段 10：全量固化
逐步放量至 100%，固化配置为版本化基线，记录本次变更的版本号与回滚命令。

声明式配置示意（通用语法，占位符需替换）：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: memory-service
spec:
  replicas: 3
  selector:
    matchLabels: { app: memory-service }
  template:
    metadata:
      labels: { app: memory-service }
    spec:
      containers:
        - name: api
          image: <制品仓库地址>/memory-service:<不可变版本标签>
          ports: [{ containerPort: 8080 }]
          env:
            - name: VECTOR_STORE_ENDPOINT
              valueFrom: { configMapKeyRef: { name: memory-conf, key: vectorEndpoint } }
            - name: EMBEDDING_MODEL_VERSION
              value: "<版本标识>"
          resources:
            requests: { cpu: "1", memory: "2Gi" }
            limits:   { cpu: "2", memory: "4Gi" }
          readinessProbe:
            httpGet: { path: /healthz/ready, port: 8080 }
            initialDelaySeconds: 10
          livenessProbe:
            httpGet: { path: /healthz/live, port: 8080 }
            periodSeconds: 20
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: memory-service-hpa
spec:
  scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: memory-service }
  minReplicas: 3
  maxReplicas: 12
  metrics:
    - type: Resource
      resource: { name: cpu, target: { type: Utilization, averageUtilization: 65 } }

七、关键配置说明与风险点

记忆条目结构（建议字段）：id、tenant_id、user_id、session_id、type（事实/偏好/摘要/轨迹）、content、embedding_ref、tags、source（来源可追溯）、created_at、updated_at、ttl、version、sensitivity_level。其中 tenant_id 是隔离的唯一依据，sensitivity_level 决定是否需要额外脱敏与更短留存。

检索参数：

参数	作用	风险
top_k	召回条数	过大导致上下文膨胀、成本与延迟上升
相似度阈值	过滤噪声	过低引入无关记忆，产生”模型胡说”
时间衰减权重	偏好新近信息	权重过强会遗忘仍然有效的长期事实
重排开关	提升相关性	增加一跳延迟，建议仅在高价值链路启用
上下文预算	限制拼装长度	缺失会挤掉用户当前问题本身

写入与淘汰：切分粒度影响召回精度（过大噪声多，过小语义碎）；去重建议用内容哈希加语义近似双判；淘汰需明确”过期、超容量、显式遗忘”三条路径，且遗忘必须级联清理派生数据（摘要、缓存、离线索引）。

最高频的事故来源：更换嵌入模型版本后未重建向量库，导致新旧向量不在同一语义空间，检索结果看似”返回了但完全不对”。务必把嵌入模型版本作为向量库的强绑定属性，变更时走双写加全量重建加灰度切换。

八、链路伪代码示意

def on_message(msg):
    items = clean_and_dedup(split(msg.text))          # 清洗、切分、去重
    items = [i for i in items if not pii_hit(i)] or mask_pii(items)
    vecs = embed_batch(items, model=VECTOR_MODEL_VER)  # 批量嵌入，摊薄成本
    vector_store.upsert(ids, vecs, meta={tenant, session, ts, ttl})
    metadata_db.insert(items)                          # 元数据用于精确过滤
    object_store.put(msg.raw_ref)                      # 原文留档，便于追溯
    queue.publish("summarize", {"session": msg.session})  # 异步摘要，削峰
def recall(query, tenant, budget):
    qv = embed(query, model=VECTOR_MODEL_VER)
    cand = vector_store.search(qv, top_k=50,
                              filter={"tenant_id": tenant, "ttl>": now()})
    cand = rerank(query, cand)[:8] if need_rerank else cand[:8]
    return pack_within_budget(cand, budget)            # 按 token 预算裁剪
def forget(memory_id, tenant):
    vector_store.delete(memory_id, filter_tenant=tenant)   # 强制带租户条件
    metadata_db.delete(memory_id, tenant)
    object_store.delete(raw_ref)
    cache.invalidate(prefix=f"m:{tenant}:{memory_id}")
    queue.publish("rebuild_derived", {"ids": [memory_id]})  # 清理摘要等派生

九、上线验证清单

• 功能：写入后可按语义召回；更新后旧值不再返回；遗忘后向量、元数据、原文、缓存均无残留。
• 隔离：换一个 tenant_id 查询，不得返回他人记忆（这是安全红线，必须专门做负向测试）。
• 接口：无凭证请求应被拒绝；超出限流应返回明确错误码；下游超时时不应无限阻塞。
• 数据质量：用自建标注集评估召回命中率与前若干条相关性，记录基线，后续每次变更回归对比。
• 资源与性能：观察 CPU/内存、数据库连接数、慢查询、P95/P99 延迟、错误率；缓存命中率是否达到预期。
• 容量：以目标峰值的 1.5~2 倍压测，验证自动扩容是否及时、扩容期间是否出现明显抖动。
• 可观测：日志包含 trace_id 可串起一次完整请求；监控看板有数据；主动触发一次故障确认告警可达。
• 回滚可用性：确认上一版本镜像仍在、配置可切回、数据结构变更向后兼容。

十、常见问题与排查

现象	可能原因	排查与处理
返回了结果但不相关	切分不合理、嵌入版本不一致、无重排、无阈值	核对模型版本登记；加相似度阈值；抽样人工评估
首次查询特别慢	冷启动、索引未预热、连接池过小、跨地域访问	预热热点查询；调大连接池；同地域部署
写入成功但查不到	异步索引延迟、缓存未失效、租户过滤条件写错	查队列积压；核对过滤字段；必要时读写同库保证一致
内存持续增长	缓存无上限、批量过大、连接未释放	设置缓存容量与过期；限制批量；检查连接生命周期
成本突然上升	上下文膨胀、重复写入、日志全量采样、频繁重建索引	收紧上下文预算；开启去重；降低日志采样；错峰重建
删除不彻底	只删了元数据	按遗忘级联清单逐项核对，补建对账任务
偶发鉴权失败	密钥轮换后部分实例未更新、时钟偏移	滚动重启同步密钥；校准时间同步

排查顺序建议固定为：先看监控与错误率 → 再用 trace_id 定位慢在哪一跳 → 再用最小复现请求在测试环境重放。避免直接在生产上反复改配置试错。

十一、运维与持续优化

稳定性：健康探针与自动重启、下游调用统一超时与重试（限次加退避）、熔断与降级（记忆检索失败时降级为纯上下文回答，而不是整体报错）、多副本反亲和分布、定期备份并实际演练恢复——未演练过的备份等于没有备份。

安全：最小权限子账号；租户级强制过滤（在数据访问层统一注入，而非依赖调用方自觉）；传输与静态加密；密钥定期轮换；敏感字段脱敏；全量写删操作留审计日志；按合规要求处理删除请求并保留处理凭证。

性能：热点记忆进缓存；嵌入批量调用；数据库连接池与读写分离；离线摘要与索引异步化；重排仅在价值链路启用。

扩展性：以 tenant_id 哈希作为分片键避免单租户热点；冷热分层（热数据在缓存/内存索引，温数据在向量库，冷数据在对象存储）；按时间或租户做容量分片；容量增长曲线纳入日常看板。

成本：设置单会话上下文预算硬上限；写入去重与 TTL；对象存储配置生命周期策略；按需与包年包月组合；定期清理僵尸索引、闲置实例与孤立存储卷。

可维护性：配置与代码分离并版本化；数据库与索引变更走迁移脚本；嵌入模型与重排模型登记版本，切换走灰度；每次变更记录”版本号、变更内容、验证结论、回滚方式”。

十二、总结与决策清单

大模型的记忆不应只存放在参数里。参数适合承载稳定不变的风格与语感，上下文适合承载当下这一轮的推理信息，而长期、可检索、可删除、可审计的记忆应当部署成独立的外部记忆服务。这套服务的部署重点不在”启动一个进程”，而在于：先算容量再定规格、先建依赖再启应用、配置与密钥严格分离、嵌入模型版本与向量库强绑定、遗忘操作级联清理、上线前完成隔离与容量的负向验证、上线后持续看召回质量而非只看服务存活。

如果你的场景是	建议的记忆位置	需要部署的组件
只需当前对话连贯	上下文	无额外组件
需要固定输出风格与格式	参数（微调）	训练与模型发布流水线
需跨会话记住用户偏好	外部记忆	记忆服务 + 向量库 + 缓存
需企业知识长期沉淀与追溯	外部记忆 + 对象存储	记忆服务 + 向量库 + 关系库 + 对象存储 + 异步任务
需满足删除与审计要求	外部记忆（唯一可行）	记忆服务 + 全量审计日志 + 遗忘对账任务

按上述流程落地后，模型才真正从”一次性问答”变成”可持续积累的服务”，而这套记忆体系的容量、延迟与成本也就此变成了可度量、可优化、可运维的工程指标。