AI 搜索引擎的第一反应是"堆 GPU"——但 Pollinations 团队刚刚用一篇 arXiv 论文证明:把缓存做对,一台 8 核 CPU 服务器就够撑起一个带会话记忆、语义去重的开源 AI 搜索引擎。论文《A Three-Layer Caching Architecture for Low-Latency LLM Web Search on Commodity CPU Hardware》(arXiv:2609.05463)围绕他们开源的 OreoLook(前名 lixSearch)展开:本地搜索、缓存、会话管理、嵌入栈全部跑在普通 CPU 硬件上,答案合成走远程推理服务。

为什么缓存是 AI 搜索的成本命门

OreoLook 是一个自动化浏览器 Agent 加多路推理路由的答案引擎:问题进来后,搜索 Agent 并发散到网页、YouTube、图片,提取全文与转录,再由 LLM 合成带来源的答案。作者在摘要里直接点出规模化后的三个痛点:会话丢上下文、换种问法就触发重复计算、同一个 URL 在不同会话里被反复嵌入。这三个问题的共性是:钱花在了已经算过的东西上。

三层缓存,各管一段

论文的核心设计是三层缓存,每一层对应一个具体的浪费源:

  • 会话上下文窗口:最近对话滚动保存在 Redis,溢出部分经 Huffman 压缩归档到磁盘。配合后台 LRU 驱逐守护进程,闲置会话自动从 Redis 迁到磁盘、需要时再水合回来,对话可以按保留策略在数小时或数天后恢复。
  • 语义查询缓存:对查询的嵌入向量做余弦相似度匹配,换种问法的等价查询直接命中缓存,省掉整条搜索+合成流水线。仓库 README 给出实现参数:Redis DB0,余弦阈值 0.90,重复查询 15 毫秒内返回。
  • URL 嵌入缓存:跨会话去重 URL 的嵌入计算,同一个网页不再被反复向量化。

部署数字直接取自论文:单台 8-vCPU Intel Cascade Lake 服务器(2 GHz、32 GB 内存),跑 30 个 Hypercorn worker 进程、分三个容器化副本,聚合 Redis 命中率 89.3%,读取延迟 0.1 毫秒,Redis 内存开销仅 1.38 MB。

单源数字怎么看

有一点值得说明:89.3% 是 Redis 键空间命中率,作者在社区讨论里明确区分了"键空间命中率"与"端到端查询避免率"两个概念——这是生产系统论文里少见的老实。仓库还把这套缓存拆成了独立 PyPI 库 lix-open-cache,只依赖 Redis、numpy、loguru,不依赖服务器端;完整搜索引擎以 Docker 镜像发布,一条 docker compose 命令即可自托管。技术栈上,检索层用 Qdrant,浏览器自动化用 Playwright,API 层兼容 OpenAI 格式,还带一个无状态 MCP 端点支持深度研究与 PDF 导出。

所以呢

对做 AI 搜索产品的团队,这篇论文的参考价值不在模型而在账本:大厂把答案合成的算力成本转嫁给了用户看不见的推理集群,而 OreoLook 论文口径下近九成键空间读取由缓存接管,单次读取 0.1 毫秒。三层缓存里最值得抄的是语义查询缓存——换种问法就能命中,这在多轮对话产品里几乎是白捡的延迟优化。论文地址:arxiv.org/abs/2609.05463,代码在 GitHub pollinations/search.elixpo。