1. 项目概述当大模型调用成为成本中心最近和几个做AI应用的朋友聊天发现大家不约而同地都在为一个问题头疼大模型的API调用成本。一个看似简单的对话应用随着用户量起来每个月的账单数字涨得比用户数还快。尤其是那些需要频繁调用、但请求内容又高度相似或重复的场景比如客服问答、代码补全、内容审核模板每次调用都像是在烧钱。这让我想起了早年做Web开发时面对高并发数据库查询第一个想到的武器就是缓存。那么对于大模型这种更昂贵的“计算资源”缓存是不是也能成为降本增效的神器呢这就是“Prompt Caching”提示词缓存的核心思路。简单说就是把大模型对特定输入Prompt的响应结果存起来当下次遇到相同或高度相似的输入时直接返回缓存的结果而不再去调用昂贵的大模型API。听起来很简单对吧但真要在工程里落地你会发现一堆坑怎么定义“相同”语义相似算不算上下文变了怎么办缓存一致性如何保证命中率低了反而增加系统复杂度得不偿失。我花了几个月时间在我们自己的几个AI应用里深度实践了Prompt Caching最终成功将部分场景的大模型调用成本降低了超过80%。这篇文章我就把自己趟过的路、踩过的坑、以及验证有效的方案毫无保留地拆解给你。无论你是在开发AI助手、智能客服还是任何有重复性提示词调用需求的应用这套工程实践都能帮你把真金白银省下来。2. 核心思路与方案选型不只是字符串匹配一开始你可能觉得Prompt Caching不就是个HashMap吗Key是提示词字符串Value是模型输出。但马上你就会遇到第一个问题用户的提问方式千变万化。“今天天气怎么样”和“天气如何”本质上是一个问题但字符串完全不同直接匹配命中率为零。所以我们需要的不是字符串缓存而是语义缓存。2.1 语义相似度缓存系统的“大脑”语义缓存的核心在于它能理解提示词的意图而不是死板地比较字符。实现这一点通常需要一个嵌入模型把文本转换成高维向量Embedding然后通过计算向量之间的余弦相似度来判断是否相似。这里第一个工程抉择就来了用谁的嵌入模型使用与大模型同系列的嵌入模型比如用OpenAI的text-embedding-3-small。好处是语义空间一致理论上相似度判断更准且通常更便宜、更快。缺点是又引入了一个外部API依赖。使用本地部署的轻量级嵌入模型比如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。原因如下技术栈统一团队熟悉PostgreSQL无需引入新的运维组件。功能强大除了向量搜索我们可以用SQL轻松实现缓存的TTL过期时间、LRU最近最少使用淘汰策略、以及复杂的元数据查询分析。成本可控相比于专门的向量数据库服务自托管PostgreSQL成本更低。3. 系统架构与核心组件实现纸上谈兵结束下面来看看我们是怎么把它搭起来的。整个Prompt Caching系统的架构可以分为三层应用层、缓存服务层、存储层。3.1 整体架构设计[客户端/应用] -- [API网关/业务层] -- [Prompt Caching Service] -- [向量存储 (PgVector)] | | |-- 缓存未命中 -- [大模型API] --|请求拦截所有发往大模型API的请求先被业务层或一个独立的中间件拦截。缓存查询拦截器将请求的Prompt及上下文发送给Prompt Caching Service。服务根据策略生成缓存键并在向量数据库中进行相似度搜索。结果返回命中如果找到相似度超过阈值如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_threshold0.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); -- 或者使用更现代的HNSWPgVector 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 缓存过期与淘汰策略缓存不能只增不减。基于TTL的过期每个缓存条目都有过期时间如24小时。这适用于新闻、天气等时效性强的信息。基于访问的淘汰定期清理最久未被访问LRU的缓存。我们写了一个定时任务每天凌晨删除last_accessed_at在7天前的记录。基于价值的淘汰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%开启缓存逐步提升比例同时利用这部分流量构建初始缓存。向量搜索的性能当缓存条目达到百万级时暴力搜索会变慢。务必合理创建向量索引IVFFlat或HNSW并定期进行性能优化。6. 效果评估、成本分析与未来展望实践是检验真理的唯一标准。上线三个月后我们对这套Prompt Caching系统进行了全面的复盘。6.1 量化效果我们选取了智能客服和代码助手两个应用进行对比分析指标智能客服上线前智能客服上线后代码助手上线前代码助手上线后日均请求量50万50万10万10万大模型API日均调用量50万7.5万10万3万缓存命中率0%85%0%70%平均响应延迟1200ms命中45ms / 未命中1200ms1500ms命中50ms / 未命中1500ms月度API成本估算$15,000$2,250$5,000$1,500结论在两个核心场景下我们分别实现了85%和70%的缓存命中率整体大模型调用成本降低了超过80%。同时缓存命中的请求响应延迟从秒级降至毫秒级用户体验获得显著提升。6.2 非量化收益稳定性提升大模型API偶尔会有抖动或限流。缓存层作为一个缓冲在API短时不可用时仍能为部分请求提供服务提升了系统的整体可用性。预算可控性增强通过缓存我们能够更准确地预测和控制成本波动避免了因流量突增导致的账单爆炸。为迭代提供数据缓存数据库成为了一个高质量问答对的积累池。我们可以分析高频命中的问题来优化系统提示词或者发现知识盲区反哺给知识库或训练数据。6.3 成本结构分析引入缓存本身也有成本计算成本嵌入模型的计算无论是本地还是API。存储成本向量数据库的存储和计算资源。开发与运维成本系统的开发、监控和维护。但在我们的实践中这些成本与节省下来的大模型API费用相比通常不到节省额的5%几乎可以忽略不计。边际效益极高。6.4 演进方向目前这套系统还在持续迭代我们正在探索的方向包括更智能的缓存失效不仅仅是时间过期能否基于信息源的变化如知识库更新来主动失效相关缓存分层缓存结合内存缓存存超高频率、无状态的问答和向量数据库缓存追求极致的查询速度。与模型微调结合缓存下来的高质量问答对本身就是优质的训练数据。是否可以定期用这些数据对一个小模型进行微调让“小模型缓存”在特定领域达到接近大模型的效果实现成本的进一步降低Prompt Caching不是一个炫技的概念而是一个实实在在的、能产生巨大商业价值的工程优化手段。它的技术门槛并不高核心在于对业务场景的深刻理解和精细化的工程实现。如果你的应用也正在被大模型成本所困扰希望这篇来自一线的实践总结能为你提供一条清晰的路径。省下来的每一分钱可都是纯利润。