智能体记忆系统压测：并发下的延迟与召回

dev.to 一位作者用本地 Ollama、ChromaDB 和 5 万条对话片段，对 Hindsight 智能体记忆系统做了压测。已展示的数据里，并发从 10 升到 25，吞吐从 8.2 增至 14.1 请求/秒，p95 延迟也从 420 升至 890 毫秒，语义召回略降。

目前能确认什么

这套测试先用自然语言检索记忆，取回最相关的 5 条片段，再拼入模型提示词，计时到模型输出首个 token。这里的延迟覆盖检索和模型响应，不能直接当作向量数据库的查询耗时。 p95 表示约 95% 请求的延迟不超过该值，能反映较慢请求的体验。

作者使用 llama3.2:3b、nomic-embed-text 和持久化模式的 ChromaDB，硬件为 32GB 内存、Ryzen 9 5950X，没有 GPU 卸载。作者称，更高并发下出现吞吐平台期、查询停顿及召回下降，并将部分问题归因于嵌入生成和索引争用。这些属于该配置下的报告，不能直接视为 Hindsight 的容量上限。

我的判断

对准备给客服 Agent 接入长期记忆的程序员，这组数据最有用的提醒是：吞吐提高时，慢请求可能已经明显变差。容量测试应同时看请求量、尾延迟和召回质量。

但节选还不足以支撑选型。配置只写了 50 并发用户，后文却报告了 75、100 并发的结果；召回下降被归因于高写入压力，前面的流程却只描述查询，写入负载和召回评测方法都没交代。

内存数据也需要核对：5 万条片段的基线约为 520MB，后文却称 8 万条时超过 32GB，缺少中间的资源拆分。网关对比又引入路由和云端回退，不能据此判断 Hindsight 自身提速。完整测试脚本、负载构成和指标口径补齐前，我会把它当作压测线索，不会拿这些阈值制定生产容量。