内存优化

想给两个常驻的 AI agent（一个跑在宿主机上的编码 agent，一个跑在容器里的 Hermes）配一套长期记忆服务，卡在两条硬约束上：机器是双核 3855U、总内存 3.8G、可用只剩 1.5G 左右，任何要跑本地 PyTorch 或嵌入/重排模型的方案直接出局；同时这台机器没有桌面环境，数据必须落进现有备份链路，挂了要能恢复。 选型是 Hindsight——它支持把 LLM 抽取、嵌入、重排全部指向远端 API，本地只留服务本体和一个嵌入式 PostgreSQL（pg0）。整件事的思路就一句话：把重活外包给云 API，是低配机器跑带向量检索服务的通用解法。 一、先验 API，再动容器 所有模型名都是先 curl 一遍确认存在的，不照文档猜：LLM 走小米 mimo 的 mimo-v2.6-flash，嵌入走阿里云百炼 qwen3.7-text-embedding（实测 1024 维），重排走 qwen3.7-text-rerank。 重排这里有个坑：Hindsight 的 alibaba provider 用的是 /compatible-api/v1/reranks——是 compatible-api，不是 embeddings 那边的 compatible-mode，端点写错了返回 404，很容易误判成"模型不可用"。 二、内存预算：把连接池收紧 数据库用镜像内嵌的 pg0，把默认连接池从 100 收到 10： HINDSIGHT_API_DATABASE_URL: "pg0://hindsight?shared_buffers=64MB&max_connections=20" HINDSIGHT_API_DB_POOL_MAX_SIZE: "10" mem_limit: 800m 实测容器记账 451~576MiB / 800MiB，看着像快满了。拆开 cgroup memory.stat 才发现真实进程内存只有约 421MB，另外 326MB 是页缓存——内核随时能回收。判断这类"快爆了"的假象，看 anon 才准，docker stats 会骗人。 三、三个坑 坑一：不设 worker id，容器重建后任务永久卡死。 首次启动日志有条警告：worker id 默认取容器主机名，而容器一重建主机名就变，旧主机名下处于 processing 的任务再也没人回收，consolidation 会静默卡住。短期完全看不出问题，等某次重建后才发作。修复是写死一个： ...