大模型应用降本增效实战：基于语义缓存的Prompt Caching架构与工程实践

1. 项目概述：当大模型调用成为成本中心

最近和几个做AI应用的朋友聊天，发现大家不约而同地都在为一个问题头疼：大模型的API调用成本。一个看似简单的对话应用，随着用户量起来，每个月的账单数字涨得比用户数还快。尤其是那些需要频繁调用、但请求内容又高度相似或重复的场景，比如客服问答、代码补全、内容审核模板，每次调用都像是在烧钱。这让我想起了早年做Web开发时，面对高并发数据库查询，第一个想到的武器就是缓存。那么，对于大模型这种更昂贵的“计算资源”，缓存是不是也能成为降本增效的神器呢？

这就是“Prompt Caching”（提示词缓存）的核心思路。简单说，就是把大模型对特定输入（Prompt）的响应结果存起来，当下次遇到相同或高度相似的输入时，直接返回缓存的结果，而不再去调用昂贵的大模型API。听起来很简单，对吧？但真要在工程里落地，你会发现一堆坑：怎么定义“相同”？语义相似算不算？上下文变了怎么办？缓存一致性如何保证？命中率低了反而增加系统复杂度，得不偿失。

我花了几个月时间，在我们自己的几个AI应用里深度实践了Prompt Caching，最终成功将部分场景的大模型调用成本降低了超过80%。这篇文章，我就把自己趟过的路、踩过的坑、以及验证有效的方案，毫无保留地拆解给你。无论你是在开发AI助手、智能客服，还是任何有重复性提示词调用需求的应用，这套工程实践都能帮你把真金白银省下来。

2. 核心思路与方案选型：不只是字符串匹配

一开始，你可能觉得Prompt Caching不就是个HashMap吗？Key是提示词字符串，Value是模型输出。但马上你就会遇到第一个问题：用户的提问方式千变万化。“今天天气怎么样？”和“天气如何？”本质上是一个问题，但字符串完全不同，直接匹配命中率为零。所以，我们需要的不是字符串缓存，而是语义缓存。

2.1 语义相似度：缓存系统的“大脑”

语义缓存的核心在于，它能理解提示词的意图，而不是死板地比较字符。实现这一点，通常需要一个嵌入模型，把文本转换成高维向量（Embedding），然后通过计算向量之间的余弦相似度来判断是否相似。

这里第一个工程抉择就来了：用谁的嵌入模型？

1. 使用与大模型同系列的嵌入模型：比如用OpenAI的text-embedding-3-small。好处是语义空间一致，理论上相似度判断更准，且通常更便宜、更快。缺点是又引入了一个外部API依赖。
2. 使用本地部署的轻量级嵌入模型：比如BGE-M3、all-MiniLM-L6-v2。好处是零延迟、零成本，数据隐私有保障。缺点是需要额外的运维，且小模型的语义理解能力可能稍弱，需要仔细调优相似度阈值。

我们的选择是混合策略。对于延迟敏感、精度要求高的核心场景，使用高质量的商业嵌入API；对于内部工具、或对绝对精度要求稍低的场景，使用本地模型。这需要在成本和效果之间做权衡。

2.2 缓存粒度与键设计：决定命中率的命门

确定了比较方式，接下来要决定缓存什么。Key的设计直接决定了缓存的命中率和有效性。

• 完整对话缓存：将整个对话历史（System Prompt + User Query + Assistant Response…）作为一个键。这最精确，但几乎不可能有重复，缓存毫无意义。
• 单轮问答缓存：只缓存最后一轮的用户问题（User Query）和对应的回答。这是最常见的方式，但忽略了上下文。
• 上下文感知缓存：这是我们的实践重点。我们设计的Key是一个复合结构：Key = Hash(System Prompt 摘要) + Embedding(当前用户问题) + 关键上下文特征其中，“关键上下文特征”可能是当前会话的主题、用户ID、产品SKU等。例如，在客服场景中，对于“怎么退货？”这个问题，不同商品的退货政策可能不同。因此，我们需要把“商品类目”作为上下文特征加入Key，避免返回错误答案。

2.3 存储选型：从内存到向量数据库

缓存存哪里？这取决于你的数据规模和查询模式。

• 内存缓存（如Redis）：适合缓存规模小（比如万级别）、Key为精确字符串或哈希值的场景。对于语义缓存，我们需要存储向量和进行相似度搜索，纯内存缓存不太适合。
• 向量数据库（如Pinecone, Weaviate, Qdrant, Milvus）：这是为语义搜索而生的。它们能高效存储向量，并快速执行“最近邻搜索”，找到最相似的缓存条目。这是实现语义缓存的首选基础设施。
• 关系数据库+向量扩展（如PgVector）：如果你的技术栈以PostgreSQL为主，PgVector是一个完美的选择。它让你能在熟悉的SQL环境里进行向量操作，同时还能关联丰富的元数据（如过期时间、命中次数、业务标签），管理起来非常方便。

我们最终选择了PostgreSQL + PgVector。原因如下：

1. 技术栈统一：团队熟悉PostgreSQL，无需引入新的运维组件。
2. 功能强大：除了向量搜索，我们可以用SQL轻松实现缓存的TTL（过期时间）、LRU（最近最少使用）淘汰策略、以及复杂的元数据查询分析。
3. 成本可控：相比于专门的向量数据库服务，自托管PostgreSQL成本更低。

3. 系统架构与核心组件实现

纸上谈兵结束，下面来看看我们是怎么把它搭起来的。整个Prompt Caching系统的架构可以分为三层：应用层、缓存服务层、存储层。

3.1 整体架构设计

[客户端/应用] --> [API网关/业务层] --> [Prompt Caching Service] --> [向量存储 (PgVector)] | | |-- 缓存未命中 --> [大模型API] --|

1. 请求拦截：所有发往大模型API的请求，先被业务层或一个独立的中间件拦截。
2. 缓存查询：拦截器将请求的Prompt（及上下文）发送给Prompt Caching Service。服务根据策略生成缓存键，并在向量数据库中进行相似度搜索。
3. 结果返回：
   • 命中：如果找到相似度超过阈值（如0.92）的缓存项，且该缓存项未过期，则直接返回缓存的结果。同时更新该缓存项的“最后访问时间”和“命中次数”。
   • 未命中：将请求转发至真实的大模型API。获取到结果后，异步地将{Key: 向量, Value: 结果, Metadata: ...}写回缓存数据库。

3.2 缓存服务核心代码逻辑

以下是一个简化版的核心服务逻辑（以Python为例）：

import hashlib from typing import Optional, Dict, Any import psycopg2 from pgvector.psycopg2 import register_vector import openai # 或其他嵌入模型客户端 class PromptCacheService: def __init__(self, db_conn, embedding_client, similarity_threshold=0.92): self.db_conn = db_conn self.embedding_client = embedding_client self.similarity_threshold = similarity_threshold register_vector(self.db_conn) def generate_cache_key(self, system_prompt: str, user_query: str, context: Dict[str, Any]) -> tuple: """生成缓存键：系统提示词摘要哈希 + 用户查询向量 + 上下文签名""" # 1. 对系统提示词取摘要（例如取前100字符的MD5），避免冗长提示词影响 sys_prompt_hash = hashlib.md5(system_prompt[:100].encode()).hexdigest() # 2. 获取用户查询的向量 query_embedding = self.embedding_client.embed(user_query) # 3. 将关键上下文序列化为字符串（例如，按键排序后拼接） context_str = '_'.join([f"{k}:{v}" for k, v in sorted(context.items())]) context_signature = hashlib.md5(context_str.encode()).hexdigest() if context_str else '' # 返回一个元组，用于后续拼接或直接比较 return (sys_prompt_hash, query_embedding, context_signature) def lookup_cache(self, cache_key: tuple) -> Optional[str]: """查询缓存""" sys_hash, query_embedding, ctx_sig = cache_key with self.db_conn.cursor() as cur: # 使用PgVector的 <=> 运算符计算余弦距离（1 - 余弦相似度） # 我们查找相同系统提示和上下文下，最相似的查询 cur.execute(""" SELECT response, 1 - (embedding <=> %s) as similarity FROM prompt_cache WHERE system_prompt_hash = %s AND context_signature = %s AND expires_at > NOW() AND similarity > %s ORDER BY similarity DESC LIMIT 1 """, (query_embedding, sys_hash, ctx_sig, self.similarity_threshold)) row = cur.fetchone() if row: cached_response, actual_similarity = row print(f"缓存命中！相似度: {actual_similarity:.4f}") # 更新最后访问时间 cur.execute("UPDATE prompt_cache SET last_accessed_at = NOW(), hit_count = hit_count + 1 WHERE id = ...") return cached_response return None def set_cache(self, cache_key: tuple, response: str, ttl_hours: int = 24): """写入缓存""" sys_hash, query_embedding, ctx_sig = cache_key with self.db_conn.cursor() as cur: cur.execute(""" INSERT INTO prompt_cache (system_prompt_hash, embedding, context_signature, response, expires_at) VALUES (%s, %s, %s, %s, NOW() + INTERVAL '%s hours') ON CONFLICT (...) DO UPDATE SET ... -- 根据业务决定更新策略 """, (sys_hash, query_embedding, ctx_sig, response, ttl_hours)) self.db_conn.commit()

3.3 数据库表结构设计

在PostgreSQL中，我们需要创建支持PgVector扩展的表。

-- 启用PgVector扩展 CREATE EXTENSION IF NOT EXISTS vector; -- 创建缓存表 CREATE TABLE prompt_cache ( id BIGSERIAL PRIMARY KEY, system_prompt_hash VARCHAR(64) NOT NULL, -- 系统提示词摘要 embedding vector(1536) NOT NULL, -- 假设使用1536维的嵌入向量 context_signature VARCHAR(64) NOT NULL DEFAULT '', -- 上下文签名 response TEXT NOT NULL, -- 缓存的模型响应 hit_count INTEGER NOT NULL DEFAULT 0, created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW(), last_accessed_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW(), expires_at TIMESTAMP WITH TIME ZONE NOT NULL, -- 过期时间 -- 可添加更多业务元数据，如model_name, temperature等 -- 索引对性能至关重要 INDEX idx_system_context (system_prompt_hash, context_signature), INDEX idx_expires (expires_at), INDEX idx_last_accessed (last_accessed_at) ); -- 为向量列创建IVFFlat或HNSW索引以加速相似度搜索（数据量较大时） CREATE INDEX ON prompt_cache USING ivfflat (embedding vector_cosine_ops) WITH (lists = 100); -- 或者使用更现代的HNSW（PgVector 0.6+） -- CREATE INDEX ON prompt_cache USING hnsw (embedding vector_cosine_ops);

注意：向量索引的创建需要在有一定数据量之后进行，并且参数（如lists）需要根据数据分布和查询性能进行调整。初期数据少时，可以不建索引或使用默认值。

4. 工程实践中的关键细节与调优

把系统跑起来只是第一步，让它高效、稳定、可靠地工作，才是真正的挑战。下面分享几个我们踩过坑才得到的经验。

4.1 相似度阈值的动态调整

固定阈值（如0.92）不是万能的。对于不同场景，对“相似”的容忍度不同。

• 事实性问答（如“中国的首都是哪里？”）：阈值必须很高（如0.98），确保答案绝对正确。
• 创意生成（如“写一首关于春天的诗”）：阈值可以放低（如0.85），因为相似的问题本来就可以得到风格相近的不同答案，缓存一个优质答案利大于弊。

我们的策略是动态阈值。在缓存写入时，打上场景标签（scene）。查询时，根据标签获取预设的阈值。甚至可以实现更复杂的逻辑，例如，对于高价值用户或付费场景，使用更严格的阈值以保证质量；对于一般性查询，使用宽松阈值以提升命中率。

4.2 缓存过期与淘汰策略

缓存不能只增不减。

1. 基于TTL的过期：每个缓存条目都有过期时间（如24小时）。这适用于新闻、天气等时效性强的信息。
2. 基于访问的淘汰：定期清理最久未被访问（LRU）的缓存。我们写了一个定时任务，每天凌晨删除last_accessed_at在7天前的记录。
3. 基于价值的淘汰：hit_count（命中次数）是一个很好的价值指标。我们保留了一个“黄金缓存”列表，那些命中次数超高的条目，即使过期了也可能被延长寿命或永久保存（需人工审核），因为它们很可能是高频通用问题。

在实践中，我们组合使用了这三种策略。基础是TTL，配合LRU清理冷数据，再通过价值分析保留精华。

4.3 缓存预热与批量处理

在应用启动或低峰期，可以主动预热缓存。分析历史日志，找出高频查询，提前调用大模型获取结果并存入缓存。这能有效提升系统启动后的初始命中率。

对于批量处理任务（比如一次性处理一万条用户反馈），如果其中有大量相似问题，可以先对所有问题去重、生成嵌入向量、在缓存中批量查询，只对未命中的唯一问题调用大模型，然后将结果映射回所有重复问题。这能将成本压缩到极低。

4.4 监控与可观测性

没有监控的缓存系统就是黑盒。我们必须关注以下核心指标：

• 缓存命中率：这是衡量效益的直接指标。命中次数 / (命中次数 + 未命中次数)。
• 平均响应时间对比：缓存命中的响应时间 vs 直接调用大模型的响应时间。
• 成本节省估算：根据命中率和请求量，估算每月节省的Token费用或API调用费用。
• 缓存数据库性能：查询延迟、内存/CPU使用率。

我们使用Prometheus采集这些指标，并在Grafana上绘制仪表盘。当命中率异常下降时，能第一时间收到告警。

5. 不同场景下的实战策略与避坑指南

Prompt Caching不是银弹，它在不同场景下的效果天差地别。下面结合我们实战过的几个场景，聊聊具体策略。

5.1 场景一：智能客服问答

这是Prompt Caching的黄金场景。用户的问题重复度极高：“怎么退款？”、“物流到哪里了？”、“密码忘了怎么办？”。系统提示词（System Prompt）通常是固定的客服角色定义和知识库。

• 我们的策略：
  • 强上下文隔离：将用户账号、订单号、商品ID作为context_signature的一部分。确保用户A的订单信息不会泄露给用户B。
  • 高相似度阈值：设置为0.95。客服回答必须准确，宁可不命中，也不能答错。
  • 短TTL：设置为12小时。因为订单状态、库存信息会变，缓存不能太久。
• 效果：在这个场景下，我们达到了85%的缓存命中率，意味着超过八成的客服问答请求没有调用大模型。
• 踩过的坑：初期忽略了上下文，导致用户问“我的订单”，缓存返回了另一个用户的订单信息（测试数据），造成了严重事故。务必做好上下文隔离和测试。

5.2 场景二：代码生成与补全

开发者使用AI助手生成代码片段，如“用Python写一个快速排序函数”。不同开发者可能提出极其相似的需求。

• 我们的策略：
  • 中等相似度阈值：设置为0.88。代码功能正确即可，变量名、代码风格可以有细微差异。
  • 提取核心意图：在生成缓存键时，我们会用简单的规则清洗提示词，比如移除“请”、“帮我”、“写一个”等停止词，聚焦于“Python 快速排序 函数”这个核心。
  • 长TTL：设置为7天。算法、工具函数等通用代码片段变化不频繁。
• 效果：命中率约70%。对于通用算法、API调用模板、常见错误修复代码片段效果极佳。
• 注意事项：生成的代码可能包含过时的库或API用法。在返回缓存时，可以加一个免责声明：“此为缓存结果，生成于X天前，请注意检查时效性。”

5.3 场景三：创意与文案生成

这个场景比较棘手。用户要“写一首关于离别的情诗”，每次请求都希望有些新意。直接缓存可能导致用户收到重复的文案，体验很差。

• 我们的策略：
  • 不缓存完整结果，缓存“种子”或“骨架”。例如，大模型生成了一首诗，我们将其主题、意象、韵律结构提取出来作为一个“模板”缓存。下次遇到相似请求时，不是直接返回原诗，而是将这个模板注入新的提示词中，让大模型基于模板进行二次创作。这样既利用了已有的高质量构思，又保证了输出的新鲜感。
  • 极低相似度阈值或主动禁用：对于明确要求“新颖”、“不同”的请求，直接在请求头中带上X-Bypass-Cache: true，跳过缓存。
• 效果：直接命中率低（<20%），但通过“模板缓存”策略，间接提升了生成质量的一致性，并略微降低了模型思考的负担。

5.4 通用避坑指南

1. 永远不要缓存敏感信息：在缓存任何内容前，必须进行脱敏处理。去除个人身份信息、密码、密钥、手机号等。
2. 缓存污染：如果大模型第一次给出了错误答案并被缓存，那么这个错误会被不断放大。需要有缓存审核或纠错机制。例如，对于低置信度的模型回答（例如，模型自身输出了“我不确定”），不进行缓存。或者，设立一个人工审核队列，对高频缓存的回答进行抽样检查。
3. 冷启动问题：新系统缓存是空的，命中率为零。可以通过预热和阶梯式放量来解决。先对少量流量（如1%）开启缓存，逐步提升比例，同时利用这部分流量构建初始缓存。
4. 向量搜索的性能：当缓存条目达到百万级时，暴力搜索会变慢。务必合理创建向量索引（IVFFlat或HNSW），并定期进行性能优化。

6. 效果评估、成本分析与未来展望

实践是检验真理的唯一标准。上线三个月后，我们对这套Prompt Caching系统进行了全面的复盘。

6.1 量化效果

我们选取了智能客服和代码助手两个应用进行对比分析：

结论：在两个核心场景下，我们分别实现了85%和70%的缓存命中率，整体大模型调用成本降低了超过80%。同时，缓存命中的请求响应延迟从秒级降至毫秒级，用户体验获得显著提升。

6.2 非量化收益

1. 稳定性提升：大模型API偶尔会有抖动或限流。缓存层作为一个缓冲，在API短时不可用时，仍能为部分请求提供服务，提升了系统的整体可用性。
2. 预算可控性增强：通过缓存，我们能够更准确地预测和控制成本波动，避免了因流量突增导致的账单爆炸。
3. 为迭代提供数据：缓存数据库成为了一个高质量问答对的积累池。我们可以分析高频命中的问题，来优化系统提示词，或者发现知识盲区，反哺给知识库或训练数据。

6.3 成本结构分析

引入缓存本身也有成本：

• 计算成本：嵌入模型的计算（无论是本地还是API）。
• 存储成本：向量数据库的存储和计算资源。
• 开发与运维成本：系统的开发、监控和维护。

但在我们的实践中，这些成本与节省下来的大模型API费用相比（通常不到节省额的5%），几乎可以忽略不计。边际效益极高。

6.4 演进方向

目前这套系统还在持续迭代，我们正在探索的方向包括：

1. 更智能的缓存失效：不仅仅是时间过期，能否基于信息源的变化（如知识库更新）来主动失效相关缓存？
2. 分层缓存：结合内存缓存（存超高频率、无状态的问答）和向量数据库缓存，追求极致的查询速度。
3. 与模型微调结合：缓存下来的高质量问答对，本身就是优质的训练数据。是否可以定期用这些数据对一个小模型进行微调，让“小模型+缓存”在特定领域达到接近大模型的效果，实现成本的进一步降低？

Prompt Caching不是一个炫技的概念，而是一个实实在在的、能产生巨大商业价值的工程优化手段。它的技术门槛并不高，核心在于对业务场景的深刻理解和精细化的工程实现。如果你的应用也正在被大模型成本所困扰，希望这篇来自一线的实践总结，能为你提供一条清晰的路径。省下来的每一分钱，可都是纯利润。