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/litellmLiteLLM 缓存让重复请求直接命中历史响应削减 LLM API 调用成本与延迟。本文覆盖缓存键的生成逻辑、三类部署场景的后端配置以及两个高频配置坑。快速跑通下面代码开启进程内内存缓存并对同一 completion 发起两次调用。连续运行两遍脚本print输出先False后True第二次响应时间从秒级降到毫秒级import litellm from litellm.caching import Cache litellm.cache Cache(typelocal, default_in_memory_ttl600) response litellm.completion( modelgpt-4o-mini, messages[{role: user, content: 1 1 ?}], ) print(response._hidden_params.get(cache_hit)) # 第二次运行输出 True命中时不再发出上游请求响应对象的_hidden_params里出现cache_hit: True该次调用记录的 spend 为 0。它到底在缓存什么可以把它理解为一个以请求哈希为 key、value 是整条 completion 响应的 KV 层。键由get_cache_key()生成把model、messages、temperature等请求参数的值拼接后做哈希namespace非空时会追加进键调用方也可以传preset_cache_key完全接管键。未命中时响应在 success 回调阶段整体写回后端命中时直接重组响应对象返回不再触碰上游。语义缓存redis-semantic / qdrant-semantic是例外键不含消息文本改为对 prompt 做 embedding 后检索最近邻一共有几个人和总人数是多少这类不同措辞的问题会命中同一条记录。请求 → get_cache_key() 生成哈希键 → 查缓存后端 命中重组响应对象标记 cache_hit直接返回 未命中调用上游 LLM → success 回调把整条响应写回缓存后端选型与配置本地开发 / 单实例内存或磁盘缓存单实例与联调场景用进程内 LRU 足够无外部依赖默认 TTL 600 秒需要跨重启保留时把type换成disklitellm.cache Cache( typelocal, # 进程内 LRU重启即清空 default_in_memory_ttl600, # 秒 )部署到多实例的那一刻内存缓存会导致各实例各自命中各自的键整体命中率下降需要切到共享后端。多实例 / 生产Redis 精确缓存Redis 后端被所有实例共享启用时框架会在其上自动组装「内存 L1 Redis L2」的双层缓存热点键走内存冷键落 Redislitellm.cache Cache( typeredis, hostredis.internal, port6379, namespaceprod, # 隔离环境间的键空间 ttl3600, # 每个键独立过期 )一致性上键的生成完全确定同一请求落在哪个实例都读同一条记录多租户场景用namespace按环境或租户隔离键空间避免互写污染。跨模型复用 / 成本敏感语义缓存 TTL语义缓存命中「措辞不同、意图相同」的问题初始化必须显式给similarity_threshold缺省会直接抛ValueError。经验起点区间 0.950.99过低会让不相关的问题也命中过高则退化成精确缓存。embedding 模型默认text-embedding-ada-002每次未命中会额外产生一次小型 embedding 调用litellm.cache Cache( typeredis-semantic, hostredis.internal, similarity_threshold0.97, default_in_redis_ttl86400, )TTL 与阈值配合使用响应只在数据有效期内被复用上游业务数据更新越频繁TTL 应设得越接近数据更新周期。两个高频踩坑点坑 1TTL 长于数据更新周期旧数据污染新请求。症状业务数据已经更新相同提问仍返回旧答案。根因缓存键只由请求参数哈希生成与上游数据版本无关旧记录在 TTL 到期前不会被主动作废。一行修复litellm.cache Cache(typelocal, default_in_memory_ttl3600)按数据更新周期给 TTL 定值。坑 2语义阈值过松不相关请求命中。症状「查今天天气」返回了「分析上周股价」的缓存答案。根因similarity_threshold设太低内部距离阈值1 - threshold随之放大向量检索捞到了语义较远的记录。一行修复similarity_threshold0.97再观察命中记录逐步收紧。下一步缓存键生成逻辑见 litellm/caching/caching.py 的get_cache_key()命中/未命中数据流在 litellm/caching/caching_handler.py。各后端实现按文件拆分目录litellm/caching/。命中率与节省成本用真实日志先验证再调参。【免费下载链接】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 缓存配置指南：后端怎么选、两个坑怎么避
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/litellmLiteLLM 缓存让重复请求直接命中历史响应削减 LLM API 调用成本与延迟。本文覆盖缓存键的生成逻辑、三类部署场景的后端配置以及两个高频配置坑。快速跑通下面代码开启进程内内存缓存并对同一 completion 发起两次调用。连续运行两遍脚本print输出先False后True第二次响应时间从秒级降到毫秒级import litellm from litellm.caching import Cache litellm.cache Cache(typelocal, default_in_memory_ttl600) response litellm.completion( modelgpt-4o-mini, messages[{role: user, content: 1 1 ?}], ) print(response._hidden_params.get(cache_hit)) # 第二次运行输出 True命中时不再发出上游请求响应对象的_hidden_params里出现cache_hit: True该次调用记录的 spend 为 0。它到底在缓存什么可以把它理解为一个以请求哈希为 key、value 是整条 completion 响应的 KV 层。键由get_cache_key()生成把model、messages、temperature等请求参数的值拼接后做哈希namespace非空时会追加进键调用方也可以传preset_cache_key完全接管键。未命中时响应在 success 回调阶段整体写回后端命中时直接重组响应对象返回不再触碰上游。语义缓存redis-semantic / qdrant-semantic是例外键不含消息文本改为对 prompt 做 embedding 后检索最近邻一共有几个人和总人数是多少这类不同措辞的问题会命中同一条记录。请求 → get_cache_key() 生成哈希键 → 查缓存后端 命中重组响应对象标记 cache_hit直接返回 未命中调用上游 LLM → success 回调把整条响应写回缓存后端选型与配置本地开发 / 单实例内存或磁盘缓存单实例与联调场景用进程内 LRU 足够无外部依赖默认 TTL 600 秒需要跨重启保留时把type换成disklitellm.cache Cache( typelocal, # 进程内 LRU重启即清空 default_in_memory_ttl600, # 秒 )部署到多实例的那一刻内存缓存会导致各实例各自命中各自的键整体命中率下降需要切到共享后端。多实例 / 生产Redis 精确缓存Redis 后端被所有实例共享启用时框架会在其上自动组装「内存 L1 Redis L2」的双层缓存热点键走内存冷键落 Redislitellm.cache Cache( typeredis, hostredis.internal, port6379, namespaceprod, # 隔离环境间的键空间 ttl3600, # 每个键独立过期 )一致性上键的生成完全确定同一请求落在哪个实例都读同一条记录多租户场景用namespace按环境或租户隔离键空间避免互写污染。跨模型复用 / 成本敏感语义缓存 TTL语义缓存命中「措辞不同、意图相同」的问题初始化必须显式给similarity_threshold缺省会直接抛ValueError。经验起点区间 0.950.99过低会让不相关的问题也命中过高则退化成精确缓存。embedding 模型默认text-embedding-ada-002每次未命中会额外产生一次小型 embedding 调用litellm.cache Cache( typeredis-semantic, hostredis.internal, similarity_threshold0.97, default_in_redis_ttl86400, )TTL 与阈值配合使用响应只在数据有效期内被复用上游业务数据更新越频繁TTL 应设得越接近数据更新周期。两个高频踩坑点坑 1TTL 长于数据更新周期旧数据污染新请求。症状业务数据已经更新相同提问仍返回旧答案。根因缓存键只由请求参数哈希生成与上游数据版本无关旧记录在 TTL 到期前不会被主动作废。一行修复litellm.cache Cache(typelocal, default_in_memory_ttl3600)按数据更新周期给 TTL 定值。坑 2语义阈值过松不相关请求命中。症状「查今天天气」返回了「分析上周股价」的缓存答案。根因similarity_threshold设太低内部距离阈值1 - threshold随之放大向量检索捞到了语义较远的记录。一行修复similarity_threshold0.97再观察命中记录逐步收紧。下一步缓存键生成逻辑见 litellm/caching/caching.py 的get_cache_key()命中/未命中数据流在 litellm/caching/caching_handler.py。各后端实现按文件拆分目录litellm/caching/。命中率与节省成本用真实日志先验证再调参。【免费下载链接】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），仅供参考