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上周有个读者问我同一个 RAG 应用每天被反复问同一批问题账单却天天涨。查下来重复调用占了总费用的 40% 以上。解法不复杂——LiteLLM 自带一层响应缓存命中缓存的请求根本不打上游 API不产生费用返回也快得多。这篇文章讲清楚 LiteLLM 缓存怎么开、后端怎么选、有哪些坑。先搞清楚命中到底靠什么先说机制不然后面全是玄学。精确缓存的 key 由 model、messages、temperature、max_tokens 等调用参数共同哈希而来换个标点、改个参数就是另一个 key照样全额计费。所以语义完全一样但措辞不同的两个问题在精确缓存里算两次调用。这一点决定了后端怎么选下面直接上表。四种后端一张表后端 type命中逻辑适合场景代价local内存参数完全一致开发、单元测试进程重启即清空多实例互不可见redis参数完全一致多实例生产环境需要跑一个 Redisredis-semantic语义缓存语义相似度达标即命中用户提问措辞多变的成本敏感场景每次查询多一次 embedding 调用s3/gcs/azure-blob参数完全一致跨实例共享、长期留存读写延迟高于 Redis两个补充disk是内存版的落盘替代单机持久化够用DualCache会同时写 Redis 和内存用本地层兜底热点。语义缓存除了 Redis仓库里还有 Qdrant、Valkey 两个实现接口一致按你已有的向量栈挑。开发30 秒挂一个内存缓存import litellm from litellm.caching import Cache litellm.cache Cache(typelocal)local就是进程内字典不碰任何外部服务适合本地开发和 CI。注意它随进程消失别拿它验证重启后数据还在之类的行为。生产Redis 加 TTL 是及格线import litellm from litellm.caching import Cache litellm.cache Cache(typeredis, hostlocalhost, port6379, ttl86400)typeredis所有请求先查 Redis命中直接返回。host/port你的 Redis 地址有密码就加password。ttl条目存活秒数。这里有个坑不设 TTL 意味着今天答对的新闻问题三个月后还在被复用。内容会过期的业务TTL 必填纯知识类问答可以放大甚至不设。另外两点白话说明每个请求想跳过缓存时在调用参数里传cache{no-cache: True}比如健康检查、调试这类调用源码里它自己就是这么做的。用户隔离不用手动操心messages 本来就在 key 里不同问题的 key 天然不同。真正需要担心的是语义缓存——相似问题要跨用户隔离见后面。成本敏感语义缓存和阈值精确缓存对换个说法就失效的提问无能为力。客服、搜索这类入口建议上语义缓存litellm.cache Cache( typeredis-semantic, hostlocalhost, port6379, similarity_threshold0.95, )similarity_threshold是 0 到 1 的相似度线低于线就重新调模型。阈值越低命中越多、省得越多但错误答案的风险也越大越高则保守省钱幅度有限。建议从 0.95 起步跑两周看命中率再调。多租户场景放心LiteLLM 会用 API key、team、org 等字段给语义缓存分组A 用户的相似问题不会命中 B 用户缓存的答案。进阶跨模型共享缓存主用 Claude、备用 GPT-4o 的架构里可以声明它们共享缓存组litellm.completion( modelclaude-3-5-sonnet, messagesmessages, metadata{caching_groups: [[claude-3-5-sonnet, gpt-4o]]}, )任何一次调用写入的条目组内其他模型直接复用降级切换时缓存照样生效。前提是这两个模型在你的场景下输出质量接近别拿差异大的模型凑组。上线前过一遍避坑清单Redis 记得带 TTL过期内容复用是真实事故。语义缓存阈值从 0.95 起步别一上来就 0.8。local缓存在进程重启后全丢别当持久层用。工具调用、代码生成这类输出本来就有波动拿缓存结果做对比测试前先确认输出确实稳定。监控上有个偷懒办法缓存命中的调用不走上游成本几乎为零直接在 Langfuse 这类观测平台的 Trace 里对比命中率前后的花费比看任何面板都直观。一句话回顾开发用local生产用redis TTL成本压力大再叠语义缓存阈值、TTL、no-cache 三个旋钮够你调到满意为止。想继续抠细节可以翻翻 缓存模块源码 里的 key 生成逻辑。【免费下载链接】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），仅供参考
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上周有个读者问我同一个 RAG 应用每天被反复问同一批问题账单却天天涨。查下来重复调用占了总费用的 40% 以上。解法不复杂——LiteLLM 自带一层响应缓存命中缓存的请求根本不打上游 API不产生费用返回也快得多。这篇文章讲清楚 LiteLLM 缓存怎么开、后端怎么选、有哪些坑。先搞清楚命中到底靠什么先说机制不然后面全是玄学。精确缓存的 key 由 model、messages、temperature、max_tokens 等调用参数共同哈希而来换个标点、改个参数就是另一个 key照样全额计费。所以语义完全一样但措辞不同的两个问题在精确缓存里算两次调用。这一点决定了后端怎么选下面直接上表。四种后端一张表后端 type命中逻辑适合场景代价local内存参数完全一致开发、单元测试进程重启即清空多实例互不可见redis参数完全一致多实例生产环境需要跑一个 Redisredis-semantic语义缓存语义相似度达标即命中用户提问措辞多变的成本敏感场景每次查询多一次 embedding 调用s3/gcs/azure-blob参数完全一致跨实例共享、长期留存读写延迟高于 Redis两个补充disk是内存版的落盘替代单机持久化够用DualCache会同时写 Redis 和内存用本地层兜底热点。语义缓存除了 Redis仓库里还有 Qdrant、Valkey 两个实现接口一致按你已有的向量栈挑。开发30 秒挂一个内存缓存import litellm from litellm.caching import Cache litellm.cache Cache(typelocal)local就是进程内字典不碰任何外部服务适合本地开发和 CI。注意它随进程消失别拿它验证重启后数据还在之类的行为。生产Redis 加 TTL 是及格线import litellm from litellm.caching import Cache litellm.cache Cache(typeredis, hostlocalhost, port6379, ttl86400)typeredis所有请求先查 Redis命中直接返回。host/port你的 Redis 地址有密码就加password。ttl条目存活秒数。这里有个坑不设 TTL 意味着今天答对的新闻问题三个月后还在被复用。内容会过期的业务TTL 必填纯知识类问答可以放大甚至不设。另外两点白话说明每个请求想跳过缓存时在调用参数里传cache{no-cache: True}比如健康检查、调试这类调用源码里它自己就是这么做的。用户隔离不用手动操心messages 本来就在 key 里不同问题的 key 天然不同。真正需要担心的是语义缓存——相似问题要跨用户隔离见后面。成本敏感语义缓存和阈值精确缓存对换个说法就失效的提问无能为力。客服、搜索这类入口建议上语义缓存litellm.cache Cache( typeredis-semantic, hostlocalhost, port6379, similarity_threshold0.95, )similarity_threshold是 0 到 1 的相似度线低于线就重新调模型。阈值越低命中越多、省得越多但错误答案的风险也越大越高则保守省钱幅度有限。建议从 0.95 起步跑两周看命中率再调。多租户场景放心LiteLLM 会用 API key、team、org 等字段给语义缓存分组A 用户的相似问题不会命中 B 用户缓存的答案。进阶跨模型共享缓存主用 Claude、备用 GPT-4o 的架构里可以声明它们共享缓存组litellm.completion( modelclaude-3-5-sonnet, messagesmessages, metadata{caching_groups: [[claude-3-5-sonnet, gpt-4o]]}, )任何一次调用写入的条目组内其他模型直接复用降级切换时缓存照样生效。前提是这两个模型在你的场景下输出质量接近别拿差异大的模型凑组。上线前过一遍避坑清单Redis 记得带 TTL过期内容复用是真实事故。语义缓存阈值从 0.95 起步别一上来就 0.8。local缓存在进程重启后全丢别当持久层用。工具调用、代码生成这类输出本来就有波动拿缓存结果做对比测试前先确认输出确实稳定。监控上有个偷懒办法缓存命中的调用不走上游成本几乎为零直接在 Langfuse 这类观测平台的 Trace 里对比命中率前后的花费比看任何面板都直观。一句话回顾开发用local生产用redis TTL成本压力大再叠语义缓存阈值、TTL、no-cache 三个旋钮够你调到满意为止。想继续抠细节可以翻翻 缓存模块源码 里的 key 生成逻辑。【免费下载链接】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），仅供参考
