大模型成本直降 50%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 是一款轻量级 AI 网关AI Gateway可让你以 OpenAI 格式统一调用 100 大模型 API并自带成本追踪、负载均衡与日志能力。本文将从零教你配置 LiteLLM 的语义缓存Semantic Cache通过向量相似度复用已有回答让重复提问不再花钱帮助你将大模型 API 成本直降 50% 以上同时显著降低响应延迟。为什么语义缓存能砍掉一半成本 传统缓存只做精确匹配用户问什么是 Langfuse和Langfuse 是什么会被视为两个请求各收一次费。语义缓存则不同它把 Prompt 转成向量Embedding按语义相似度检索已有回答对比项精确缓存语义缓存匹配方式文本完全一致向量相似度 ≥ 阈值改写问题能否命中❌ 不能✅ 能典型命中率较低高客服、FAQ 场景尤甚额外开销无每次一次 Embedding 调用费用极低对于 FAQ、客服机器人、内部知识库这类问题重复率高的场景语义缓存命中率轻松超过 50%意味着一半的请求直接返回缓存零 Token 消耗。LiteLLM 内置了三种语义缓存实现源码位于 litellm/caching/ 目录RedisSemanticCache—— 基于 Redis Stack 向量检索litellm/caching/redis_semantic_cache.pyQdrantSemanticCache—— 独立向量数据库 Qdrantlitellm/caching/qdrant_semantic_cache.pyValkeySemanticCache—— Valkey 后端litellm/caching/valkey_semantic_cache.py完整缓存体系说明见 litellm/caching/Readme.md。快速开始3 步启用 LiteLLM 语义缓存第 1 步部署一个带向量能力的 RedisLiteLLM 的 Redis 语义缓存依赖 RedisVL 扩展需使用 Redis Stack含 RediSearch 向量模块一条 Docker 命令即可docker run -d --name redis-stack -p 6379:6379 redis/redis-stack-server:latest第 2 步编写 config.yaml在 LiteLLM Proxy 的配置文件中加入以下设置litellm_settings: cache: true cache_type: redis cache_redis_host: localhost cache_redis_port: 6379 cache_redis_password: cache_ttl: 300 # 缓存保留 5 分钟 # —— 语义缓存核心配置 —— semantic_cache: true # 开启语义缓存 semantic_cache_type: redis # 后端redis / qdrant / valkey semantic_cache_embedding_model: text-embedding-ada-002 semantic_cache_similarity_threshold: 0.8核心参数一目了然配置项作用建议值semantic_cache语义缓存总开关truesemantic_cache_type选择缓存后端redis/qdrant/valkeysemantic_cache_embedding_model生成向量的 Embedding 模型text-embedding-ada-002semantic_cache_similarity_threshold相似度阈值0~1越高越严格0.7 ~ 0.8cache_ttl缓存条目存活时间秒按业务定如果偏好独立向量数据库 Qdrant只需将semantic_cache_type换成qdrant并补充连接信息semantic_cache_type: qdrant qdrant_api_base: http://localhost:6333 qdrant_api_key: your-api-key qdrant_collection_name: litellm_semantic_cache更多底层参数如 Embedding 超时semantic_cache_embedding_timeout可在 litellm/caching/caching.py 的Cache类中查看。第 3 步验证缓存命中 ✅启动 LiteLLM Proxy 后连续发送两个语义相近的请求如什么是 Langfuse→Langfuse 是什么。第二次请求将直接命中缓存响应速度明显更快——不再等待 LLM 生成日志中记录相似度分数——命中条目会写入semantic-similarity元数据方便你观测实际相似度成本面板不再增长——缓存命中的请求不计 Token 费用可用项目自带的测试用例验证行为例如 tests/test_litellm/caching/test_redis_semantic_cache.py 与 tests/test_litellm/caching/test_qdrant_semantic_cache.py。关键参数调优similarity_threshold 怎么设这是决定省钱幅度与答案质量平衡点的最关键参数0.6 ─────── 0.7 ─────── 0.8 ─────── 0.95 ─────── 1.0 宽松 ←←←←←←←←←←←←←←←←←←←←←←←←←←←←← 严格 命中多、易答错 命中少、更安全FAQ / 客服机器人设0.7~0.75优先省钱容忍少量近义回答通用对话 / 代码问答设0.8是官方默认推荐起点高精度业务金融、医疗设0.9以上宁可不命中也不答错 经验法则先以 0.8 上线观察日志中的实际semantic-similarity分布再决定收紧还是放宽。用管理面板确认省了多少钱 LiteLLM Proxy 自带成本追踪面板每个请求的 Token 消耗与花费都会记录在案——缓存命中的请求不再产生新的模型费用账单一目了然若你接入了 Langfuse 等可观测性平台还能在 Trace 级别对比缓存前 vs 缓存后的单次成本差异。下图为一次 LiteLLM 请求的完整追踪清晰展示了 Token 用量与花费常见问题 FAQQ1语义缓存会增加延迟吗会增加一次轻量 Embedding 调用毫秒级但相比完整 LLM 生成秒级命中缓存后总延迟大幅下降。Q2缓存会跨用户串数据吗不会。LiteLLM 通过litellm_cache_key隔离缓存作用域不同用户/团队的语义缓存相互独立保证数据安全。Q3本地开发没有 Redis 怎么办可以先用cache_type: local内存缓存跑通链路再切换到redis语义缓存。总结 收益说明 成本直降 50%高频重复问题直接命中缓存零 Token 消耗⚡ 响应更快跳过 LLM 生成环节毫秒级返回 统一网关100 模型 OpenAI 格式接入一处配置全局生效 可观测内置成本追踪 相似度日志效果可量化三步配置、一个阈值调优你的大模型账单就能立省一半。现在就可以打开config.yaml动手试试配合管理面板的成本面板验证省下的每一分钱。【免费下载链接】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），仅供参考