如何用 LiteLLM 缓存为大模型重复请求降本提速

如何用 LiteLLM 缓存为大模型重复请求降本提速【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm如果你的应用每天向同一个大模型接口发出大量内容雷同的请求那么账单上的重复计费和秒级的等待延迟多半来自同一件事相同的输入被反复完整调用。LiteLLM 缓存机制就是在调用链中间加一层结果复用——命中已有结果时直接返回不再请求上游模型。本文从问题出发讲清楚缓存后端怎么选、几行代码怎么开、过期策略怎么定、效果怎么度量以及落地前容易踩的几个坑帮你把重复的 LLM 调用变成一次性的成本。重复调用为什么会又慢又贵一次大模型请求要经历网络往返、排队、推理三个阶段其中推理耗时和 token 费用与请求内容完全相关。当请求重复时这两项支出没有任何变化属于纯粹的浪费。判断重复最简单可靠的依据是缓存键LiteLLM 会把模型名、消息内容、关键参数做确定性摘要得到同一个请求的唯一指纹。指纹命中且未过期即视为缓存命中。缓存命中率就是命中次数占总请求的比例它是衡量缓存价值的第一个数字——对 FAQ、分类、抽取这类高重复度场景命中率轻松超过 70%对开放式对话则可能只有个位数。所以缓存不是开关而是杠杆杠杆的大小取决于你业务里可复用输入的占比。先估算这个占比再决定投入多少在基础设施上。五种缓存后端按部署规模选LiteLLM 把所有后端收敛在同一个Cache入口后面切换后端只改构造参数。选型时可以对照下表后端类型数据去向命中方式适用场景local内存进程内字典完全相同单机应用、开发测试disk磁盘本地文件完全相同需重启后保留、无外部依赖redisRedis 实例完全相同多进程/多实例共享生产主流选择dual双写内存 Redis先查内存再查 Redis高 QPS 下减少 Redis 往返redis-semantic / qdrant-semantic向量索引语义相近即可同义改写、措辞漂移的长尾问题两点需要在选型时说透命名空间相当于给缓存键统一加前缀不同业务或不同环境的数据各自隔离互不覆盖。Redis 后端建议显式指定例如namespacebilling。TTLTime To Live缓存条目从写入到自动失效的秒数。不设置则长期有效靠手动或容量策略清理。内存缓存零依赖是验证缓存收益最快的起点确认有效后再迁移到 Redis业务代码不用改只换构造参数——这是这个抽象层最大的工程价值。如何开启 LiteLLM 缓存三步落地第一步全局挂载缓存。下面这段代码先挂一个进程内缓存并把 Redis 的等价写法留在注释里方便单机验证后直接切换import litellm from litellm.caching import Cache # 起点进程内内存缓存零外部依赖 litellm.cache Cache(typelocal) # 多实例部署时换成这一行即可业务代码不变 # litellm.cache Cache(typeredis, host10.0.0.5, port6379, # namespacefaq-service)第二步保持默认行为不变。挂载之后completion调用自动先查缓存、未命中才透传上游命中时直接把缓存的响应对象返回调用方无感知。第三步对个别请求做精细控制。同一套 API 里你可以按请求粒度决定这条要不要缓存、缓存多久、放在哪个键空间response litellm.completion( modelgpt-4o-mini, messages[{role: user, content: 如何重置数据库密码}], cache{ s-maxage: 3600, # 本条结果缓存 1 小时后失效 namespace: faq, # 与全局命名空间隔离的独立键空间 }, )cache字典还支持no-store本次结果不写入缓存和no-cache本次只查不存例如敏感查询、要求实时性的调用可以直接标为no-cache避免拿到几小时前的旧答案。让缓存更聪明语义匹配与跨模型复用精确匹配有一个天花板用户把怎么改密码问成如何重置登录凭证指纹不同缓存失守。语义缓存解决的正是这一层。它把每条输入先转成向量再入库查询时按含义而非文本比较相似度阈值 0.95 表示含义接近程度超过 95% 才返回旧结果阈值越严越安全、命中率越低通常从 0.9 起步观察误命中率再收紧litellm.cache Cache( typeredis-semantic, host10.0.0.5, port6379, similarity_threshold0.95, # 语义接近度超过该值才判定为命中 )除了纵向的同义命中LiteLLM 还支持横向的跨模型复用给metadata传入caching_groups同组模型共享同一个缓存键。当业务从 gpt-4o 灰度切到 claude 时切换前的调用结果立刻可被复用切换窗口期的账单不会翻倍response litellm.completion( modelgpt-4o, messagesmessages, metadata{caching_groups: [[gpt-4o, claude-3-5-sonnet]]}, )需要留意的是语义缓存依赖一个 embedding 模型做向量化默认使用 OpenAI 的文本嵌入模型这会带来少量额外调用对私有化部署可换成自托管的嵌入端点。如何设置合理的过期时间过期策略分三层从粗到细全局默认 TTL构造参数里ttl指定所有条目的生存秒数default_in_redis_ttl可单独覆盖 Redis 侧默认值比如把 FAQ 类答案设为86400一天把行情类数据压到几分钟。按请求覆盖上文cache字典里的s-maxage只对该条结果生效优先级高于全局值。主动失效当业务数据源头变更配置更新、文档改版时调用缓存的删除接口按命名空间或键批量清理比等 TTL 自然到期更干净。定 TTL 的实用原则以源数据的最长保鲜期为准而不是业务有多保守。答案 30 天不变就设 30 天为了安全压到 10 分钟只会把命中率白白打低还要多付上游调用的钱。如何度量缓存效果命中率、时延与成本账缓存上线后如果没有度量很快会退化成感觉有用。建议盯住三个指标命中率按后端和命名空间分别统计能定位是哪类请求在贡献命中、哪类在空转时延分布命中请求应落在毫秒级若 P50 没有明显下移说明请求根本没走到查缓存路径费用差值命中即零 token 计费用命中请求数乘以该模型均价就是缓存每月省下的钱。把 LiteLLM 接上 Langfuse 之类的追踪工具后每次调用都会留下完整的追踪记录延迟、token 数、费用一目了然缓存收益可以直接在 trace 里对账除了命中率还要监控缓存存储占用。Redis 侧用INFO memory看驻留大小语义索引的向量库条目数会随请求量线性增长TTL 设置过长的条目是主要的膨胀来源。落地前容易踩的四个坑把非确定性输出当确定性输出缓存。模型带随机性时同一输入每次答案不同缓存第一个答案后用户看到的是冻结的输出。对此类调用要么标no-cache要么把temperature归零后再缓存。多用户共键。把用户身份user id、team id排除在消息之外的请求很容易跨用户命中A 看到 B 的定制答案。要么把用户标识写进消息内容要么按用户开命名空间。语义阈值一刀切。0.95 对 FAQ 合适对总结这段代码这类任务型请求可能把两个不同文件的总结混到一起。语义缓存应按业务线单独调阈值而不是全局一个数。流式与工具调用场景未验证。缓存的是完整响应对象启用前先确认你的链路含工具调用、流式拼装能正确处理缓存返回的对象结构避免上线后在边缘路径上炸出异常。LiteLLM 缓存的价值不在开关本身而在命中率与成本账本上先用内存缓存测出可复用占比再按规模迁到 Redis 或语义后端用 TTL 和命名空间管住数据新鲜度最后用追踪工具对账收益。下一步建议挑一个重复度最高的接口如 FAQ 或分类挂上Cache(typelocal)跑一天把命中率数字算出来再决定要不要为它上 Redis。【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考