语义缓存 (Semantic Cache)

概述

语义缓存 (Semantic Cache) 是 LLM 应用中最简单、投资回报率最高的成本优化技术之一。它的核心思想是：将 LLM 的响应缓存在向量数据库中，当新查询与缓存中的查询语义相似时，直接返回缓存的响应，无需调用 LLM。在典型的 LLM 应用中，语义缓存可以降低 30%-80% 的 API 调用次数和成本。

为什么需要语义缓存

LLM API 调用的成本结构：

成本项	说明	典型开销
API 调用费用	按 token 计费	$0.15 -$ 15 / 1M tokens
网络延迟	请求-响应往返	200ms-5s
推理延迟	模型生成时间	500ms-30s
速率限制	API 并发限制	每分钟 500-5000 次

对许多应用来说，大量用户查询是重复或高度相似的。例如：

客服系统：80% 的用户问题集中在 20% 的常见问题
文档问答：多个用户对同一文档提问相似问题
代码助手：相同错误信息的查询频繁出现

精确匹配缓存 vs 语义缓存

维度	精确匹配缓存 (Exact Match)	语义缓存 (Semantic Cache)
匹配方式	查询字符串完全一致	查询语义相似
缓存命中率	低（查询的细微变化导致缓存未命中）	高（容忍同义词、语序变化、措辞差异）
实现方式	Redis / Memcached	向量数据库 + 嵌入模型
存储开销	低（仅存储原始查询-响应对）	中等（存储查询-响应-嵌入向量三元组）
查询延迟	极低 (<1ms)	低 (5-50ms)
适用场景	完全相同的重复查询	自然语言查询，高重复率场景
维护成本	极低	低（需维护嵌入模型和向量数据库）
典型命中率	5-15%	30-60%

GPTCache 架构

GPTCache 是 2023 年由 Zilliz 开源的最流行的语义缓存框架，提供了完整的语义缓存解决方案。

核心组件

┌──────────────────────────────────────────────────────────┐
│                    GPTCache 架构                          │
│                                                          │
│  用户查询: "How to train a neural network?"              │
│       ↓                                                  │
│  ┌─────────────────┐                                    │
│  │ 1. Pre-Function  │  查询预处理                        │
│  │    (预处理)       │  - 移除停用词                      │
│  │                  │  - 温度参数剥离                     │
│  └────────┬────────┘  - 系统提示词剥离                   │
│           ↓                                              │
│  ┌─────────────────┐                                    │
│  │ 2. Embedding     │  嵌入生成                          │
│  │    (嵌入)        │  - OpenAI Ada-002                  │
│  │                  │  - 本地模型 (BGE, E5)              │
│  └────────┬────────┘  - 自定义嵌入函数                   │
│           ↓                                              │
│  ┌─────────────────┐                                    │
│  │ 3. Vector Store  │  向量存储与相似度搜索              │
│  │    (向量存储)     │  - Milvus / Qdrant / Chroma       │
│  │                  │  - FAISS (内存)                    │
│  └────────┬────────┘  - Redis (带向量搜索)               │
│           ↓                                              │
│  ┌─────────────────┐                                    │
│  │ 4. Cache Manager │  缓存管理                          │
│  │    (缓存管理)     │  - Eviction Policy (LRU/LFU)      │
│  │                  │  - 相似度阈值判断                  │
│  │                  │  - 命中/未命中决策                 │
│  └────────┬────────┘                                    │
│           ↓                                              │
│  ┌─────────────────┐                                    │
│  │ 5. Post-Function │  后处理                            │
│  │    (后处理)       │  - 温度参数恢复                    │
│  │                  │  - 系统提示词恢复                   │
│  └─────────────────┘  - 响应格式化                       │
└──────────────────────────────────────────────────────────┘

相似度阈值策略

缓存的命中决策基于相似度阈值：

相似度范围	策略	说明
similarity > 0.95	直接返回缓存结果	查询几乎相同
0.85 < similarity < 0.95	返回缓存结果 + 标记	可能需验证
similarity < 0.85	调用 LLM 并缓存新结果	查询差异较大

向量数据库后端对比

后端	类型	延迟	吞吐量	部署复杂度	适用场景
FAISS (内存)	内存索引	<1ms	极高	极低	开发/小规模 (<100K 缓存)
Chroma	嵌入式向量数据库	2-5ms	高	低	中小规模应用
Milvus	分布式向量数据库	3-10ms	极高	高	大规模生产环境
Qdrant	向量数据库	2-8ms	高	中等	中等规模，高性能
Redis (RediSearch)	缓存+向量搜索	1-3ms	极高	中等	已有 Redis 基础设施
PostgreSQL (pgvector)	关系型+向量	5-15ms	中	低	已有 PostgreSQL 基础设施
Weaviate	向量数据库	3-10ms	高	中等	需要内置向量化的场景

语义缓存最佳实践

1. 缓存键设计

不只用用户查询作为缓存键，还应该包含：

系统提示词 (System Prompt)
模型名称和版本
温度等关键参数
用户角色/权限（确保不同用户看到不同结果）

2. 相似度阈值调优

开始训练时使用较高的阈值 (0.92-0.95)，避免返回不相关结果
在生产中根据用户反馈和 A/B 测试逐步调整
可为不同意图/场景设置不同的阈值

3. 缓存预热 (Cache Warming)

分析历史查询日志，识别高频查询模式
提前生成并缓存这些查询的响应
对于新部署的模型版本，重新预热缓存

4. 缓存失效策略

基于时间 (TTL)：设置过期时间（如 24 小时），适用于时效性内容
基于模型版本：模型更新时清空缓存
基于内容更新：知识库更新时选择性清空相关缓存
混合策略：结合 TTL 和事件驱动的失效

2026 年：语义缓存是最简单的成本优化

当前趋势

标准化：语义缓存已成为 LLM 应用的标准基础设施组件，几乎所有 LLM 网关和 API 管理平台都内置了语义缓存功能。
多级缓存架构：L1 精确匹配 (Redis) → L2 语义缓存 (向量数据库) → L3 LLM API，逐级降级，最大化缓存命中率。
跨模型缓存：对不同模型的响应进行语义相似度匹配，实现跨模型复用（例如 GPT-5.5 和 Claude Opus 4.8 之间的缓存共享）。
与 Agent 集成：在 Agentic 工作流中，不仅缓存最终响应，还缓存中间步骤（工具调用结果、推理链等）。
边缘缓存：将语义缓存部署到 CDN 边缘节点，将延迟从 200ms 降至 5ms。
成本优化平台：如 GPTCache Enterprise、Semantic Cache as a Service 等商业产品出现。

投资回报分析

一个典型的 LLM 应用（日均 100 万次查询）：

场景	无缓存	精确匹配缓存	语义缓存
缓存命中率	0%	8%	45%
日均 API 调用	1,000,000	920,000	550,000
日均 API 成本 ($0.50/1K queries)	$500	$460	$275
年节省	$0	$14,600	$82,125
额外基础设施成本	$0	$500/年	$3,000/年
净年节省	$0	$14,100	$79,125

来源

GPTCache GitHub: https://github.com/zilliztech/GPTCache
GPTCache Documentation: https://gptcache.readthedocs.io/
Semantic Cache for LLMs: A Practical Guide (2024): https://www.anyscale.com/blog/semantic-cache-for-llms
LangChain Cache Integration: https://python.langchain.com/docs/integrations/llm_caching/
Cache Augmented Generation (CAG): https://arxiv.org/abs/2312.01523