LiteLLM 缓存快速上手削减重复 LLM 调用与成本【免费下载链接】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 缓存要解决的问题LiteLLM 是一个统一的 LLM 网关与 SDK开启缓存后相同或语义相近的请求再次到达时它直接返回之前存下的回答不再转发上游不产生新费用响应时间从秒级降到毫秒级。选缓存后端你的应用属于什么规模LiteLLM 缓存提供四类存储后端选型前回答三个问题单实例还是多实例要不要多实例共享用户提问是否总换一种说法后端初始化类型跨实例共享相似度匹配适用规模内存缓存local否仅精确匹配单进程、开发测试Redis 缓存redis是仅精确匹配多实例生产环境语义缓存redis-semantic/qdrant-semantic是相似问法可命中高频客服问答云存储缓存s3/gcs/azure否每实例独立仅精确匹配无 Redis 又需持久化判断路径单进程用 local 即可多实例挂同一负载均衡就用 redis否则每个实例各存一份命中率直接减半用户经常换说法问同一个问题才在 redis 之上加语义缓存没有 Redis 资源又想持久化选 S3 或 GCS。各后端的源码与说明集中在 litellm/caching/。LiteLLM 缓存配置最短可用路径初始化、发起调用、确认命中三步完成。import litellm from litellm import Cache, completion litellm.cache Cache(typelocal) # 内存缓存零配置 messages [{role: user, content: 法国首都是哪里}] r1 completion(modelgpt-4o-mini, messagesmessages) # 首次调用走上游 r2 completion(modelgpt-4o-mini, messagesmessages) # 第二次应命中缓存如何确认命中最省事的办法是计时缓存命中会跳过到上游的网络往返import time t time.perf_counter(); completion(modelgpt-4o-mini, messagesmessages) print(f{time.perf_counter() - t:.2f}s) # 约 1.8s首次走上游 t time.perf_counter(); completion(modelgpt-4o-mini, messagesmessages) print(f{time.perf_counter() - t:.2f}s) # 约 0.02s第二次命中上生产时换成 Redis顺手完成隔离与过期设置litellm.cache Cache( typeredis, hostlocalhost, port6379, namespacemyapp-prod, # 缓存键按应用隔离 default_in_redis_ttl3600, # 条目 1 小时后过期 )调参与验证TTL、命名空间与阈值TTL 设多少合理TTL 决定一条缓存答案最长能活多久按数据更新频率定股价、汇率这类实时数据按分钟产品文档、FAQ 按小时到小时级。拿不准就先设 3600 秒观察一周命中率再放宽。命名空间隔离什么命名空间是加在缓存键前的前缀不隔离时多个应用共用一个 Redis 会互相覆盖。全局用namespace参数设置需要按用户隔离时可在单次请求传cache{namespace: user_123, s-maxage: 3600}其中 s-maxage 表示该条目的最长存活时间请求级设置优先于全局。语义缓存阈值怎么设相似度阈值是两句话判定为同一问题所需的最低相似度0 到 1 之间起点建议 0.75。改写问法仍漏出、命中率停在 40% 左右降到 0.7出现答非所问升到 0.85。一次实测从 0.7 降到 0.65命中率从 40% 提到 78%误命中在抽检下可控。调完看三个指标命中率策略是否生效、p95 延迟命中是否兑现、每千次请求成本LLM 成本优化的最终目标。三者都能在 LiteLLM 管理面板或你接的日志回调里取到。避坑最容易踩的三个案例回答过期。现象用户反馈产品说明和新版本对不上。原因TTL 设为 30 天内容更新后没人清缓存。解法TTL 对齐数据更新频率内容变更时主动清除对应键。数据串扰。现象用户 A 拿到用户 B 的回答。原因共用一个 Redis 且没设命名空间键只是消息的哈希。解法全局设置 namespace并按用户 ID 在请求级再隔离。语义误命中。现象退货政策和如何申请退款返回同一条答案。原因similarity_threshold 设得太低0.6。解法升到 0.8 以上用一组易混淆问题做抽检。回到开头那张账单同一句问候现在只计费一次其余都从缓存里返回。下一步从本地缓存跑一周开始看命中率数字再决定是否加 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），仅供参考