做LangChain应用的朋友到一定规模后都会盯上两个数字一个是账号后台的token消耗量一个是用户聊天时的等待时长。我自己做过一个RAG客服机器人上线第二个月账单直接翻上去后来翻日志才发现几百个用户当天其实在反复问同一批问题只是每句话的措辞都不一样系统每次都老老实实调了一次大模型几千token就这么打了水漂。这件事给我的印象很深缓存才是LLM应用降本提速的第一优先级而不是急着换小模型、压缩prompt。这篇文章打算把缓存这件事拆透。我会用同一个LangChain生产项目的口径把无缓存、普通缓存、语义缓存三档方案从原理、代码到实测数据完整讲一遍适合正在做RAG问答、智能客服、文档助手这类应用且LLM调用量已经到十万级/月以上的团队参考。看完你可以直接照着落地也能避开我在生产环境里踩过的那些坑。1. 先算账一次LLM请求的钱和时间都花在哪了在聊缓存方案之前你得先搞清楚每一分token钱和用户等待的每一秒到底流向了哪里。不把这个问题看清后面做缓存设计很容易南辕北辙。1.1 一个RAG请求的token构成以一个典型的RAG多轮问答请求为例。假设用的是某家商用大模型API输入价格约1元/百万tokens输出价格约2元/百万tokens各家有差异先按这个量级估算。一次请求的输入输出大致是系统提示词约500 tokens召回并拼接进上下文的文档片段约1500 tokens最近5轮对话历史约1000 tokens用户本次问题约50 tokens模型生成的回答约300 tokens一次请求的token消耗大约是输入3050 tokens、输出300 tokens。按上面的单价折算单次调用成本是3050 / 1000000 × 1 300 / 1000000 × 2 0.00365元单看一次确实便宜连一分钱都不到但放到日请求10万次的业务里一天就是365元一个月超过一万元——这还只是推理token费用没算向量化、检索、服务器和人工成本。更关键的是这3050个输入tokens里真正属于这一次问题的只有那50个用户query。系统提示、文档片段、历史对话这三块在同一个会话里反复出现本质上是每次请求都要重复付费的部分。这就是LLM应用和传统Web应用最大的差别传统接口的缓存目标是降低数据库压力LLM的缓存目标则是减少重复发生的token付费。1.2 延迟的构成与重复劳动问题再说延迟。一次LLM调用的耗时通常由三部分构成prefill输入处理时间取决于喂了多少输入tokens毫秒到几百毫秒不等首token延迟TTFT模型开始输出第一个字之前的时间同样受输入长度影响生成时间按输出token数乘以单token生成时间计算。生成速度在30-50 tokens/s时300 tokens大约要6-10秒。也就是说输入越长用户等得越久。多轮对话的历史会不断变长每次请求的输入token数都在涨响应速度也在肉眼可见地变慢。而缓存命中的请求直接返回之前的结果延迟可能从六七秒压到几百毫秒这是用户端感受最明显的地方。所以能不能少调一次LLM、能不能让不属于新问题的请求更快返回这个问题的答案直接决定了月底账单和用户体验。下面依次看三档做法。2. 无缓存档什么时候真的不能缓存以及无缓存状态下还能做什么先声明一点无缓存不是一个方案它是做缓存之前的基线状态。但这不意味着它不值得讨论——恰恰相反搞清楚哪些请求必须保持无缓存你才知道缓存该往哪放。2.1 有三类问题必须保持无缓存第一类是强时效性任务。比如现在股票多少钱今天什么时候下班当前服务器负载是多少这类问题的答案随时间的推移会失效缓存命中反而有害因为它会把旧答案当新答案返回。第二类是强个性化任务。比如帮我写一封给客户的道歉邮件每个用户的背景、语气、诉求都不同缓存一个通用答案反而显得敷衍。第三类是本身带有随机性的任务比如头脑风暴、文案润色要求每次输出的写法不一样缓存会扼杀掉多样性的价值。所以做缓存之前先给业务问题分个类。凡是答案跟时间、用户、随机性强相关的请求直接走无缓存通道不要在缓存层里做文章。省下来的维护成本比那点缓存命中率值钱。2.2 就算不加缓存也要先堵住两个浪费口在无缓存通道里仍然有两个纯浪费的地方值得处理。第一个是对话历史无限膨胀。我在生产项目里见过最夸张的情况一个用户连续问50轮每轮请求都把全部历史送进模型历史轻松涨到8000-10000 tokens而且绝大多数与当前问题无关。处理方式是用摘要压缩历史——每几轮把前面对话浓缩成一段小结让小结作为历史参与后续请求。这个方法不算缓存但效果跟缓存一样好输入token量直接腰斩。第二个是固定的公共上下文重复注入。像系统提示词、知识库的公共部分每次请求都带一份一模一样的。如果API支持prompt前缀缓存能力可以把这个公共前缀单独命中如果不支持就尽量把公共部分压缩精简。这一步做好一次请求的输入token数可能从3050掉到2000出头一个月省出的钱也相当可观。一句话总结无缓存档的定位它不是一个优化手段而是一个分类通道。把不该缓存的请求挡在这里把该缓存的请求交给后面两档。3. 普通缓存档LangChain五分钟能接好但别指望它扛住用户问法聊完基线来看第一档真正的缓存方案普通缓存。在LangChain里这一档对应官方缓存模块配置极其简单很多人甚至不需要改业务代码。3.1 LangChain的缓存抽象与落地代码LangChain从0.1版本开始就设计了一套缓存抽象底层是BaseCache接口核心方法是lookup查缓存和update写缓存。基于这个接口的实现包括InMemoryCache进程内存、RedisCache基于Redis、SQLiteCache本地文件、UpstashRedisCacheServerless Redis等。生产环境我推荐直接用RedisCache。原因很简单LangChain进程通常不止一个副本InMemoryCache在各副本之间不共享命中率会被拆散而Redis是大多数后端团队已有的基础设施多副本共享一份缓存还自带过期策略。接入代码短得出乎意料import redis from langchain_core.caches import RedisCache from langchain_core.globals import set_llm_cache redis_client redis.Redis.from_url(redis://localhost:6379/3) set_llm_cache(RedisCache(redis_redis_client)) from langchain_openai import ChatOpenAI llm ChatOpenAI(modelgpt-4o-mini, temperature0)设置好之后所有经过llm的请求都会先被LangChain查一次缓存。它的key设计是把模型名称、API参数temperature这类、以及传入的消息列表做序列化与哈希。也就是说只有连续两次调用在模型、参数、输入消息三个维度完全一致时第二次才会命中缓存并直接返回第一次的答案。3.2 普通缓存的命中率为什么上不去问题就出在完全一致这四个字上。我用真实线上日志统计过在一个开放聊天的RAG客服场景里1000条用户query用普通缓存跑命中率只有3%左右。原因很好理解用户很少把同样一句话原封不动说两遍。今天的你们多久发货和明天的你们多久发货可能一字不差但更多时候是发货时效是几天请问发货要多久一般几天能到这类五花八门的变体——普通缓存对它们完全无能为力。所以在接普通缓存之前先看看请求来源结构。如果用户是键盘敲进来的自由文本普通缓存基本等同没有。如果用户问题是从按钮、下拉框、模板里选出来的每个问题对应一个固定id那命中率会相当高。3.3 最适合普通缓存的三类场景从我的经验看普通缓存真正发挥作用的是下面三类场景一是系统内部的固定任务。比如每天定时生成的日报摘要、批量给商品打标签输入prompt完全一样只换对象id普通缓存能把重复部分全部接住。二是完全相同的公共问题。有些用户确实会连续问同一个问题比如刚问完怎么申请发票没几分钟又问一遍普通缓存能接住第二遍。三是微调与评估阶段的重复实验。做模型评测时同一个测试集要跑好几轮开了普通缓存第二轮以后直接秒回评测时间大幅缩短。普通缓存成本低、接入快我的建议是把它当作所有LangChain项目的默认项先开了再说。它的收益可能不大但这是给语义缓存打的地基——语义缓存本质上是在这个缓存框架上增加了语义键的能力。4. 语义缓存档把同一件事的一百种说法变成一次LLM调用如果普通缓存只能解决原封不动再问一遍那语义缓存要解决的就是换着说法再问一遍。这一档的核心思路是不再用字符串判断两个问题是否相同而是用向量距离判断两个问题是否语义相近。4.1 语义缓存的工作原理与适用判断流程其实非常简单用户query进来之后先做embedding向量化拿向量去向量数据库做相似度检索找到历史上语义最接近的一个缓存条目如果相似度超过阈值说明这次的问题和上次某个问题含义相同直接返回缓存答案如果没超过阈值说明这是新问题才真正调用LLM生成答案后把query向量和答案一起写进缓存。这个方案天然契合RAG类的客服、FAQ、文档问答场景因为这类场景的问题高度重复但表达方式五花八门。一个你们营业时间是几点的query用户能说出几点开门上班时间什么时候营业你们几点开始接待十几种变体普通缓存一个都接不住语义缓存能全部识别成同一问题。但也有不适合语义缓存的场景。比如指望它缓存多轮对话的整体回答——每轮对话上下文都不一样拼接起来的输入向量差异很大相似度天然偏低。又比如一次性创意任务用户要的就是个性化输出命中缓存反而让体验变差。所以语义缓存更适合单轮、事实型、答案相对稳定的问题。一个直觉判断标准答案能被复用的前提是语义相同且答案不过期。4.2 用LangChain风格实现一个语义缓存层LangChain官方目前没有内置语义缓存模块截至项目落地时但好消息是BaseCache抽象给了我们一个非常干净的扩展位置。你可以写一个SemanticCache类塞进set_llm_cache让LangChain的所有LLM调用自动先走语义缓存。核心代码骨架大致如下import hashlib from langchain_core.caches import BaseCache from langchain_core.load import dumps, loads from langchain_core.embeddings import Embeddings import chromadb class SemanticCache(BaseCache): def __init__(self, embeddings: Embeddings, collection, threshold: float 0.93): self.embeddings embeddings self.collection collection self.threshold threshold def _embed(self, text: str): return self.embeddings.embed_query(text) def lookup(self, prompt: str, llm_string: str) - list | None: # 把模型参数拼进查询文本保证不同模型/参数下的缓存互相隔离 query_text f{llm_string}:::{prompt} vector self._embed(query_text) results self.collection.query( query_embeddings[vector], n_results1, ) if not results[ids]: return None distance results[distances][0][0] if distance self.threshold: # 按实际使用的向量库和距离口径调整 return None return loads(results[documents][0][0]) def update(self, prompt: str, llm_string: str, return_val): vector self._embed(f{llm_string}:::{prompt}) self.collection.add( ids[hashlib.md5((llm_string prompt).encode()).hexdigest()], embeddings[vector], documents[dumps(return_val)], ) # 接入方式 from langchain_core.globals import set_llm_cache from langchain_chroma import Chroma from langchain_openai import OpenAIEmbeddings embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vectorstore Chroma( collection_namesemantic_cache, embedding_functionembeddings, ) set_llm_cache(SemanticCache(embeddings, vectorstore, threshold0.93))这里有个细节值得留意把llm_string拼进query文本是为了隔离不同模型、不同temperature下的缓存——同一个什么是退款的问题在不同模型下的答案不应该互相污染。距离判断部分用的是Chroma的L2距离距离越小越相似代码里的threshold0.93实际上是一个距离上限可以理解成相似度下限的镜像。Chroma也支持用余弦距离生产环境按向量库文档把口径对齐。另外真实的BaseCache接口在不同LangChain版本里细节有调整比如部分版本用异步lookup/update生产环境建议按你锁定的版本适配并在缓存答案里带一个版本字段做校验。4.3 阈值、变参和embedding选型这三个细节决定成败语义缓存第一个天坑是阈值。定得太松会把退款流程是什么和退货流程是什么当成同一问题返回错答案定得太紧语义缓存退化成普通缓存。我给出的经验区间事实型FAQ场景按余弦相似度口径从0.90-0.95起步然后跑一周线上日志抽检相似度在0.85-0.93之间被拒绝的请求人工标记哪些其实应该命中再来回调阈值。没有这一步阈值永远都是拍脑袋。第二个天坑是动态变量。看这句今天股票涨了多少和昨天股票涨了多少语义相似度接近1但答案完全不同。如果问题里含有日期、时间、人名、金额这类动态实体直接做语义缓存就是灾难。这类问题要么在入口用规则判断强制走无缓存通道要么在写缓存前把动态实体替换成占位符——比如把2024-11-11统一替换成DATE_TOKEN再算向量、存答案命中时再把缓存答案里的占位符替换回当前实体值。第三个天坑是embedding模型选型。语义缓存的质量上限由embedding模型决定而不是由向量库决定。对中英文混杂的客服场景建议先用bge系列或text-embedding系列做一轮对比测试拿一批真实query算两两相似度看是否能把同义不同形的句子拉到高相似度、把形似义不同的句子拉开距离。选定模型后在线下单独部署一个向量化服务不要每次都临时调在线API否则缓存命中多出来的embedding时间和费用会吃掉一部分收益。5. 三档实测数据同一批线上请求跑出来的真实差距理论说再多没有数据都是空话。我把项目里的一次对比测试结果贴出来这是某个RAG客服机器人在真实线上日志里抽的1000条用户query分别用无缓存、普通缓存、语义缓存三档跑一遍统计命中率、平均响应时间和token消耗。5.1 测试设计与三个关键指标测试环境是同一个LangChain应用、同一个向量知识库、同一个LLM模型唯一区别就是缓存层。语义缓存的相似度阈值按0.93的余弦相似度配置。结果如下指标无缓存普通缓存语义缓存缓存命中率0%3.1%38.6%平均响应时间P506.4s6.1s3.9s每1000次请求的LLM调用次数1000969614输入token总消耗量近似305万296万187万输出token总消耗量近似30万29万18万普通缓存的3.1%命中率基本验证了前面的判断用户自由输入的问题原话重复概率极低。语义缓存命中率38.6%意味着1000次请求里有386次不用再调用LLM直接用缓存答案返回。响应时间从6.4秒压到3.9秒看起来只少了2.5秒但这里有个关键点——命中请求的P50其实在400毫秒左右剩余3.9秒是被未命中请求拉起来的。如果你把命中请求单独统计用户感知差异非常明显。费用方面按输入1元/百万tokens、输出2元/百万tokens估算每1000次请求无缓存约3.65元普通缓存约3.54元语义缓存约2.23元。放到月请求100万次的场景语义缓存比无缓存省下约1400元。单看绝对值不算多但这里还没算延迟降低带来的体验收益以及同样预算下可以承接更多请求量的容量收益。5.2 命中率之外的隐形收益P99延迟与并发配额保护这组数据里最值得说的不是平均耗时而是P99延迟和并发配额。在无缓存状态下高峰时段100个人同时问怎么退订单这类热门问题100个请求会同时打到LLM接口上。语义缓存的效果是第一个人触发LLM后后面99个语义相同的问题直接命中缓存LLM接口的实际并发压力被压缩了98%以上。这一点在国内外大模型API普遍限流限配额的背景下尤其值钱——它不是多花钱的问题而是根本没有那么多配额能花。另一个被低估的收益是兜底能力。如果知识库检索返回空结果或者LLM API临时不可用语义缓存里已有的高频答案可以作为降级兜底返回给用户避免用户拿到系统错误。这种价值不在能算出来的钱里但对业务连续性很重要。6. 语义缓存落地时最容易踩的五个坑最后聊落地。语义缓存实现起来并不复杂真正让它翻车的往往是下面五个问题逐个说每个都附解决办法。6.1 热点穿透与并发放大第一个坑出现在流量高峰。1000个人同时问同一个热门问题缓存里还没有这条记录结果就是1000个请求全部穿透到LLM。普通缓存也有这个问题但语义缓存场景下更隐蔽——因为用户问法不同语义缓存即便有近似记录判定未命中后同样会全量打到LLM。解决办法是在缓存层前面加一个singleflight单飞机制当某个语义槽位正在被LLM生成时后续相同或近似语义的请求先挂起等待等第一个请求把答案写进缓存后直接命中返回。很多语言都有现成的singleflight库LangChain的异步接口也适合挂这个机制。这个坑千万别忽略否则大促期间语义缓存可能把LLM并发直接打满。6.2 缓存污染与prompt版本漂移第二个坑是prompt模板升级。今天系统提示词写的是请用简体中文回答缓存里存了一批基于旧提示词生成的答案明天把提示词改成请用繁体中文回答旧缓存没有清理用户就会拿到繁体还错漏的旧答案。这种污染比没有缓存更可怕因为它是有规律地输出错误。我的习惯是给缓存键加一个version字段prompt模板每次改动版本号加1同时清空一次语义缓存。这个版本号直接拼进llm_string让两个版本的缓存天然隔离。一句话总结缓存永远绑定prompt版本不绑定的缓存早晚出事。6.3 误命中与业务歧义第三个坑是语义误命中。我接过一个售后项目我要退款和我要退货语义上高度接近相似度能到0.96但业务上一个是钱的事一个是货的事答案完全不同。如果阈值定在0.93这个case就错了。针对这类问题光调阈值没用。我最终的方案是三层防护第一层业务侧维护一个歧义短语黑名单在进入缓存前对query做关键词检测命中退款、退货、更换这类词对强制走无缓存通道第二层缓存命中后不仅看相似度还要返回原始query用精确或规则校验兜底第三层对缓存答案打置信度标签低置信度的只作为参考草稿不直接展示。生产上这套组合打下来误命中率从0.8%降到了0.1%以下。6.4 可观测性是缓存系统的另一半第四个坑是看不见的缓存。没有监控的缓存层等于没做缓存你不知道命中率是高是低、不知道阈值该调大还是调小、不知道哪天prompt改版把缓存污染了。我在项目里强制给缓存层加了四项指标命中率、相似度分布、节省的token估算、缓存写入失败率。前两个用来调阈值第三个用来向老板证明系统价值第四个用来在存储出问题时及时获知。这些指标最后都接入监控系统并配了告警一旦命中率比前7天均值下滑超过15%大概率是有人改了prompt或知识库结构直接去查发布记录。这个习惯救过我很多次。6.5 成本账里最容易漏掉的embedding开销最后一个坑是钱没算全。语义缓存不是完全免费的每一次请求无论命中还是未命中都要先做一次embedding。如果embedding走在线API一次embedding消耗几十到几百tokens费用不高但叠加高频请求后会占到总成本的一两个百分点——更麻烦的是延迟在线embedding多一跳网络命中请求的400毫秒可能变成800毫秒优势大减。所以我的建议是在自己的服务器上部署一个本地embedding服务用开源的bge系列模型把向量化延迟压到几十毫秒以内同时给每个embedding结果再做一层缓存——同一句话反复出现的概率在语义缓存场景里其实不低。这一步做完语义缓存才算真正跑顺了。把无缓存、普通缓存、语义缓存放到一起看定位完全不同普通缓存是默认项花十分钟接上命中率虽然低但几乎零成本语义缓存是增值项值得认真设计阈值、处理变参、做监控无缓存是业务分类通道用来拦住那些根本不该复用的请求。我个人的落地建议是分两步走先全量开普通缓存把LangChain这套机制跑通再针对高频单轮问答场景迭代语义缓存用一到两周的线上数据把阈值校准到位。最后提醒一句缓存解决了重复的成本但解决不了答案质量本身评估模型策略和知识库质量依然值得持续投入别让缓存成了掩盖badcase的遮羞布。