三层缓存架构，让低配 CPU 也能支撑低延迟 LLM 网页搜索

导语

实时网页搜索型大语言模型产品，难点不只是生成答案，还包括抓取网页、管理多轮会话、计算嵌入以及调用远程模型。用户的一次追问，往往会让系统重新读取上下文、重复搜索相似问题，并再次为已经出现过的 URL 生成向量。OreoLook 的工作重点不是复用最终答案，而是从搜索流程的多个环节削减重复劳动。

三层缓存分别解决什么问题

• 会话上下文窗口：将近期消息保存在 Redis 中，供搜索代理和答案生成快速读取。当上下文超出窗口后，系统会把溢出内容进行 Huffman 压缩并写入磁盘。后台 LRU 驱逐进程负责迁移长期闲置会话，需要时再恢复，因此会话可以在数小时或数天后继续使用，具体取决于保留策略。
• 语义查询缓存：系统先把查询转换为嵌入向量，再通过余弦相似度寻找语义上接近的历史问题。这样，措辞不同但意图相近的请求有机会复用已有结果，避免再次触发昂贵的搜索和远程 LLM 调用。
• URL 嵌入缓存：多个会话可能引用同一网页。该层以 URL 为去重边界，复用已经生成的嵌入，减少跨会话的重复计算。

部署结果与解读

论文介绍的评估环境是一台配备 8 个 vCPU、32 GB 内存的 Intel Cascade Lake 服务器，运行 30 个 Hypercorn worker，并分布在三个容器副本中。作者报告了 89.3% 的 Redis keyspace 命中率、约 0.1 毫秒的读取延迟，以及 1.38 MB 的已测 Redis 内存开销。这说明缓存本身可以在相对有限的硬件资源上运行。

不过，这些数字需要准确理解。Redis keyspace 命中表示某次键访问找到了数据，并不自动意味着整个查询被缓存，也不等价于端到端延迟按同等比例下降。语义缓存还涉及相似度阈值、结果时效性和不同用户之间的隔离问题；实时网页内容发生变化时，过度复用也可能带来答案陈旧风险。原材料明确将该系统描述为生产实践导向的架构，而不是对所有工作负载都适用的通用结论。

意义与影响

OreoLook 展示了一种较务实的优化路径：不要求在本地部署大型模型，而是把 CPU 资源用于搜索编排、会话管理和缓存，把答案合成交给远程推理提供商。对于预算有限、但需要多轮网页问答的产品，这种分层设计有助于降低重复搜索、嵌入计算和模型调用成本。更重要的是，它把“缓存 LLM”从只复用最终文本，扩展到上下文、查询意图和网页特征等中间状态，为后续研究长期代理记忆、缓存隔离和更严格的评测方法提供了工程起点。

来源：Hugging Face Daily Papers