1. 大模型响应缓存为什么你的应用又慢又贵大模型响应缓存说白了就是把已经生成过的回答存起来下次遇到相同或高度相似的请求直接从本地取结果不再重复调用大模型接口。它适合所有在 Python 里做大模型应用的人客服问答、智能助手、内容生成、知识库检索只要你的业务里存在重复提问缓存就能立刻见效。TTL 缓存装饰器则是把这件事做得最优雅的方式——不改动业务函数一行代码加个就完成缓存接入。我做过一个客服机器人的项目上线第一周账单就超了预算。排查日志发现用户问得最多的前 20 个问题占了总请求量的 60% 以上比如怎么退货发货要多久支持哪些支付方式。这些问题答案几乎不变但每次都要重新走一遍大模型推理既慢又贵。响应时间平均 2.3 秒用户等得不耐烦直接关页面Token 消耗像流水一样一个月下来成本高得离谱。缓存这个经典思路放到大模型场景里特别对症。它的核心逻辑就是用空间换时间把高频请求的结果存在内存里命中时响应时间从秒级降到微秒级成本直接归零。但大模型缓存和普通缓存不一样它有三个特殊要求。第一是时效性大模型的回答可能随时间失效比如今天天气这种问题缓存必须能自动过期这就需要 TTL 机制。第二是键值设计prompt 往往是一大段文本直接拿字符串当键会导致键过长、内存浪费需要哈希压缩。第三是线程安全生产环境多线程并发调用时缓存读写必须保证原子性否则会出现缓存击穿甚至数据损坏。这篇文章会从零开始带你实现一个生产级的大模型 TTL 缓存装饰器。我会先讲清楚装饰器的底层原理再给出可复制的完整代码然后演示怎么在真实调用链里验证命中率和失效行为最后把常见的坑一个个排掉。你跟着做半小时内就能给自己的大模型应用加上缓存层。2. 前置准备TaoToken 接入与缓存环境搭建在写缓存装饰器之前得先有一个能调用的大模型接口。我用的是 TaoToken 提供的统一 API 网关它兼容 OpenAI 的接口格式Python 里直接用openai库就能调省去了自己封装 HTTP 请求的麻烦。如果你还没配置可以先去官网看看接入方式整个流程不复杂。TaoToken 的 API 地址是https://taotoken.net/api注意这个地址不带任何查询参数直接作为base_url使用。你需要先在控制台创建一个 API Key然后把它放到环境变量里不要硬编码在代码中。下面是我常用的配置方式import os from openai import OpenAI client OpenAI( api_keyos.environ.get(TAOTOKEN_API_KEY), base_urlhttps://taotoken.net/api ) def call_llm(prompt: str, model: str gpt-4o-mini) - str: response client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], temperature0.7 ) return response.choices[0].message.content这段代码是整个缓存装饰器的被装饰对象。缓存层要做的就是拦截call_llm的调用在真正发起网络请求之前先查缓存。你可以把call_llm理解成一个耗时的慢函数缓存装饰器的任务就是让相同参数的调用不再走这个慢函数。环境方面Python 3.8 以上即可不需要额外安装缓存库标准库里的functools、hashlib、threading、time足够用。如果你用的是虚拟环境确认一下openai库已经装好pip install openai提示API Key 建议通过环境变量注入比如在.env文件里写TAOTOKEN_API_KEYsk-xxx然后用python-dotenv加载。这样代码提交到 Git 时不会泄露密钥。准备好这些我们就可以开始写装饰器了。整个实现分三步走先理解装饰器原理再写基础 TTL 版本最后升级到生产级。3. 从零实现 TTL 缓存装饰器3.1 装饰器原理速通装饰器本质是一个接收函数、返回新函数的高阶函数。Python 里函数是一等对象可以赋值、传参、返回这是装饰器能工作的基础。闭包则让装饰器有了记忆能力——内部函数引用了外部函数的变量即使外部函数执行完毕这些变量依然被保存着。缓存字典就存在这个闭包里生命周期和被装饰函数绑定。写装饰器时一定要加functools.wraps它把原函数的__name__、__doc__等元信息复制到包装函数上。不加的话调试时看到的是wrapper而不是你的函数名排查问题会很痛苦。import functools def my_decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): result func(*args, **kwargs) return result return wrapper3.2 基础 TTL 缓存版本先实现一个能用的版本理解核心逻辑。缓存键用(args, frozenset(kwargs.items()))生成frozenset保证关键字参数顺序不影响键的生成。缓存值存(时间戳, 结果)元组每次读取时对比当前时间和时间戳超过 TTL 就删除并重新调用。import functools import time def ttl_cache(ttl3600): cache_storage {} def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): cache_key (tuple(args), frozenset(kwargs.items())) current_time time.time() if cache_key in cache_storage: cached_time, cached_result cache_storage[cache_key] if current_time - cached_time ttl: print(f缓存命中剩余 {ttl - (current_time - cached_time):.1f} 秒) return cached_result else: del cache_storage[cache_key] print(缓存未命中调用大模型) result func(*args, **kwargs) cache_storage[cache_key] (current_time, result) return result return wrapper return decorator这个版本能跑但有几个明显问题。缓存键用str(args)拼接长 prompt 会导致键过长而且args(1,2)和args(12,)可能产生冲突。没有线程锁多线程并发时可能重复调用大模型。没有容量限制缓存无限增长会撑爆内存。异常也会被缓存网络抖动导致的失败结果会被存下来后续请求一直返回错误。3.3 生产级大模型缓存装饰器针对上面的问题逐个优化。缓存键改用 MD5 哈希固定 32 位长度同时对 kwargs 排序保证顺序一致。加threading.Lock保证线程安全。加 LRU 淘汰策略缓存满时删除最久未使用的项。异常不缓存只存成功结果。import functools import time import hashlib import threading from typing import Any, Callable, Optional class LLMResponseCache: def __init__(self, default_ttl: int 3600, max_size: int 1000): self._cache {} self._access_times {} self._default_ttl default_ttl self._max_size max_size self._lock threading.Lock() self._hits 0 self._misses 0 def _generate_key(self, args: tuple, kwargs: dict) - str: args_str |.join(str(arg) for arg in args) kwargs_str |.join(f{k}{v} for k, v in sorted(kwargs.items())) raw_key f{args_str}||{kwargs_str} return hashlib.md5(raw_key.encode(utf-8)).hexdigest() def _clean_expired(self) - None: current_time time.time() expired [k for k, (ts, _) in self._cache.items() if current_time - ts self._default_ttl] for key in expired: del self._cache[key] self._access_times.pop(key, None) def _evict_lru(self) - None: if len(self._cache) self._max_size: return if self._access_times: oldest min(self._access_times.items(), keylambda x: x[1])[0] del self._cache[oldest] del self._access_times[oldest] def get(self, args: tuple, kwargs: dict) - Optional[Any]: key self._generate_key(args, kwargs) current_time time.time() with self._lock: if key not in self._cache: self._misses 1 return None timestamp, result self._cache[key] if current_time - timestamp self._default_ttl: del self._cache[key] self._access_times.pop(key, None) self._misses 1 return None self._access_times[key] current_time self._hits 1 return result def set(self, args: tuple, kwargs: dict, result: Any) - None: key self._generate_key(args, kwargs) current_time time.time() with self._lock: self._clean_expired() self._evict_lru() self._cache[key] (current_time, result) self._access_times[key] current_time def clear(self) - None: with self._lock: self._cache.clear() self._access_times.clear() self._hits 0 self._misses 0 def stats(self) - dict: with self._lock: total self._hits self._misses return { total_items: len(self._cache), max_size: self._max_size, default_ttl: self._default_ttl, hits: self._hits, misses: self._misses, hit_rate: self._hits / total if total 0 else 0.0 } def cache_llm_response(ttl: int 3600, max_size: int 1000): cache LLMResponseCache(default_ttlttl, max_sizemax_size) def decorator(func: Callable) - Callable: functools.wraps(func) def wrapper(*args, **kwargs): cached cache.get(args, kwargs) if cached is not None: return cached try: result func(*args, **kwargs) except Exception: raise cache.set(args, kwargs, result) return result wrapper.clear_cache cache.clear wrapper.cache_stats cache.stats return wrapper return decorator关键优化点说明。缓存键用 MD5 哈希后固定 32 位长 prompt 也不会撑大内存。threading.Lock保证get和set的原子性多线程下不会重复调用大模型。LRU 淘汰在set时触发缓存满时删掉最久未访问的项。异常直接raise不缓存避免把失败结果存下来。stats方法记录命中次数和未命中次数方便你算命中率。4. 接入真实调用链并验证命中率4.1 装饰大模型调用函数把装饰器套到第 2 节的call_llm上TTL 设 10 秒方便测试过期行为容量设 5 方便测试淘汰。cache_llm_response(ttl10, max_size5) def cached_llm_call(prompt: str, model: str gpt-4o-mini) - str: return call_llm(prompt, model)4.2 验证命中与过期写一段测试脚本连续调用三次相同 prompt观察耗时和缓存统计。import time prompt 用一句话解释什么是缓存 start time.time() r1 cached_llm_call(prompt) t1 time.time() - start print(f第一次调用耗时{t1:.2f}秒) start time.time() r2 cached_llm_call(prompt) t2 time.time() - start print(f第二次调用耗时{t2:.2f}秒) print(f两次结果一致{r1 r2}) print(f缓存统计{cached_llm_call.cache_stats()}) time.sleep(11) start time.time() r3 cached_llm_call(prompt) t3 time.time() - start print(f过期后调用耗时{t3:.2f}秒) print(f过期后统计{cached_llm_call.cache_stats()})预期输出第一次耗时 1 秒以上真实调用大模型第二次耗时接近 0 秒缓存命中两次结果完全一致。等待 11 秒后第三次调用耗时又回到 1 秒以上因为缓存已过期。cache_stats里hit_rate会显示 0.33 左右1 次命中2 次未命中。4.3 验证 LRU 淘汰容量设 5连续调用 6 个不同 prompt第 6 个会触发淘汰最早的那个被删掉。for i in range(6): cached_llm_call(f测试问题 {i}) stats cached_llm_call.cache_stats() print(f缓存项数量{stats[total_items]}) # 应该是 5再调用一次测试问题 0会发现它已经被淘汰重新走大模型调用。这就是 LRU 在起作用。4.4 多线程并发验证开 10 个线程同时调用同一个 prompt验证锁是否生效。import threading results [] def worker(): results.append(cached_llm_call(并发测试问题)) threads [threading.Thread(targetworker) for _ in range(10)] for t in threads: t.start() for t in threads: t.join() print(f结果数量{len(results)}) print(f结果去重后数量{len(set(results))}) # 应该是 1 print(f最终统计{cached_llm_call.cache_stats()})如果锁生效10 个线程只会触发一次真实调用其余 9 次全部命中缓存set(results)去重后只有 1 个结果。5. 本篇常见错误排查5.1 缓存键冲突导致返回错误结果症状不同 prompt 返回了相同的缓存结果。原因通常是缓存键生成方式不健壮比如用str(args)拼接时args(1,2)和args(12,)产生相同字符串。解决方法是改用 MD5 哈希并且在拼接时加分隔符|避免参数边界模糊。5.2 多线程下重复调用大模型症状并发请求时日志里出现多次缓存未命中明明 prompt 相同。原因是get和set之间没有锁保护两个线程同时判断缓存不存在都去调大模型。解决方法是把get和set都放在threading.Lock里或者用双重检查锁定模式。5.3 缓存无限增长导致内存溢出症状服务跑几天后内存占用越来越高最终 OOM。原因是没设容量上限缓存项只增不减。解决方法是加max_size参数和 LRU 淘汰策略每次set时检查容量超了就删最久未使用的项。5.4 异常结果被缓存症状某次网络抖动导致大模型调用失败之后相同请求一直返回错误。原因是try-except里把异常也存进了缓存。解决方法是只在func成功返回后才调cache.set异常直接raise不缓存。5.5 TTL 设置不合理症状缓存命中率极低或者用户拿到过期信息。TTL 太短缓存刚存就过期TTL 太长时效性内容一直返回旧结果。解决方法是按内容类型分级设置新闻天气类 5-10 分钟通用知识类 1-24 小时固定模板类 7 天以上。可以在装饰器参数里传入不同 TTL或者按 prompt 前缀动态判断。5.6 缓存键包含无意义参数症状明明 prompt 相同但缓存一直不命中。原因是调用时传了request_id、trace_id这类每次都变的参数导致缓存键每次都不同。解决方法是在装饰器里过滤掉这些参数或者把它们从缓存键生成逻辑里排除。6. 下一步把缓存接入你的生产链路缓存装饰器写好了接下来就是把它用到真实业务里。如果你还在调试阶段建议先用模型对话功能验证一下大模型接口是否正常确认call_llm能稳定返回结果再加缓存层。接入文档里有完整的接口说明和参数列表遇到报错可以先对照排查。对于长期跑编码任务或者 Agent 应用的场景频繁调用大模型是常态缓存带来的成本节省会非常可观。你可以考虑用 Coding Plan 来管理调用配额配合缓存装饰器把重复请求挡在缓存层只让真正需要推理的请求走到大模型。最后分享一个实用技巧在装饰器里加一个cache_stats方法暴露命中率然后用定时任务每分钟打印一次。命中率低于 30% 说明 TTL 太短或者缓存键设计有问题高于 80% 说明缓存效果很好。这个指标比任何监控都直观能帮你快速判断缓存层是否在正常工作。
1. 大模型响应缓存为什么你的应用又慢又贵大模型响应缓存说白了就是把已经生成过的回答存起来下次遇到相同或高度相似的请求直接从本地取结果不再重复调用大模型接口。它适合所有在 Python 里做大模型应用的人客服问答、智能助手、内容生成、知识库检索只要你的业务里存在重复提问缓存就能立刻见效。TTL 缓存装饰器则是把这件事做得最优雅的方式——不改动业务函数一行代码加个就完成缓存接入。我做过一个客服机器人的项目上线第一周账单就超了预算。排查日志发现用户问得最多的前 20 个问题占了总请求量的 60% 以上比如怎么退货发货要多久支持哪些支付方式。这些问题答案几乎不变但每次都要重新走一遍大模型推理既慢又贵。响应时间平均 2.3 秒用户等得不耐烦直接关页面Token 消耗像流水一样一个月下来成本高得离谱。缓存这个经典思路放到大模型场景里特别对症。它的核心逻辑就是用空间换时间把高频请求的结果存在内存里命中时响应时间从秒级降到微秒级成本直接归零。但大模型缓存和普通缓存不一样它有三个特殊要求。第一是时效性大模型的回答可能随时间失效比如今天天气这种问题缓存必须能自动过期这就需要 TTL 机制。第二是键值设计prompt 往往是一大段文本直接拿字符串当键会导致键过长、内存浪费需要哈希压缩。第三是线程安全生产环境多线程并发调用时缓存读写必须保证原子性否则会出现缓存击穿甚至数据损坏。这篇文章会从零开始带你实现一个生产级的大模型 TTL 缓存装饰器。我会先讲清楚装饰器的底层原理再给出可复制的完整代码然后演示怎么在真实调用链里验证命中率和失效行为最后把常见的坑一个个排掉。你跟着做半小时内就能给自己的大模型应用加上缓存层。2. 前置准备TaoToken 接入与缓存环境搭建在写缓存装饰器之前得先有一个能调用的大模型接口。我用的是 TaoToken 提供的统一 API 网关它兼容 OpenAI 的接口格式Python 里直接用openai库就能调省去了自己封装 HTTP 请求的麻烦。如果你还没配置可以先去官网看看接入方式整个流程不复杂。TaoToken 的 API 地址是https://taotoken.net/api注意这个地址不带任何查询参数直接作为base_url使用。你需要先在控制台创建一个 API Key然后把它放到环境变量里不要硬编码在代码中。下面是我常用的配置方式import os from openai import OpenAI client OpenAI( api_keyos.environ.get(TAOTOKEN_API_KEY), base_urlhttps://taotoken.net/api ) def call_llm(prompt: str, model: str gpt-4o-mini) - str: response client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], temperature0.7 ) return response.choices[0].message.content这段代码是整个缓存装饰器的被装饰对象。缓存层要做的就是拦截call_llm的调用在真正发起网络请求之前先查缓存。你可以把call_llm理解成一个耗时的慢函数缓存装饰器的任务就是让相同参数的调用不再走这个慢函数。环境方面Python 3.8 以上即可不需要额外安装缓存库标准库里的functools、hashlib、threading、time足够用。如果你用的是虚拟环境确认一下openai库已经装好pip install openai提示API Key 建议通过环境变量注入比如在.env文件里写TAOTOKEN_API_KEYsk-xxx然后用python-dotenv加载。这样代码提交到 Git 时不会泄露密钥。准备好这些我们就可以开始写装饰器了。整个实现分三步走先理解装饰器原理再写基础 TTL 版本最后升级到生产级。3. 从零实现 TTL 缓存装饰器3.1 装饰器原理速通装饰器本质是一个接收函数、返回新函数的高阶函数。Python 里函数是一等对象可以赋值、传参、返回这是装饰器能工作的基础。闭包则让装饰器有了记忆能力——内部函数引用了外部函数的变量即使外部函数执行完毕这些变量依然被保存着。缓存字典就存在这个闭包里生命周期和被装饰函数绑定。写装饰器时一定要加functools.wraps它把原函数的__name__、__doc__等元信息复制到包装函数上。不加的话调试时看到的是wrapper而不是你的函数名排查问题会很痛苦。import functools def my_decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): result func(*args, **kwargs) return result return wrapper3.2 基础 TTL 缓存版本先实现一个能用的版本理解核心逻辑。缓存键用(args, frozenset(kwargs.items()))生成frozenset保证关键字参数顺序不影响键的生成。缓存值存(时间戳, 结果)元组每次读取时对比当前时间和时间戳超过 TTL 就删除并重新调用。import functools import time def ttl_cache(ttl3600): cache_storage {} def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): cache_key (tuple(args), frozenset(kwargs.items())) current_time time.time() if cache_key in cache_storage: cached_time, cached_result cache_storage[cache_key] if current_time - cached_time ttl: print(f缓存命中剩余 {ttl - (current_time - cached_time):.1f} 秒) return cached_result else: del cache_storage[cache_key] print(缓存未命中调用大模型) result func(*args, **kwargs) cache_storage[cache_key] (current_time, result) return result return wrapper return decorator这个版本能跑但有几个明显问题。缓存键用str(args)拼接长 prompt 会导致键过长而且args(1,2)和args(12,)可能产生冲突。没有线程锁多线程并发时可能重复调用大模型。没有容量限制缓存无限增长会撑爆内存。异常也会被缓存网络抖动导致的失败结果会被存下来后续请求一直返回错误。3.3 生产级大模型缓存装饰器针对上面的问题逐个优化。缓存键改用 MD5 哈希固定 32 位长度同时对 kwargs 排序保证顺序一致。加threading.Lock保证线程安全。加 LRU 淘汰策略缓存满时删除最久未使用的项。异常不缓存只存成功结果。import functools import time import hashlib import threading from typing import Any, Callable, Optional class LLMResponseCache: def __init__(self, default_ttl: int 3600, max_size: int 1000): self._cache {} self._access_times {} self._default_ttl default_ttl self._max_size max_size self._lock threading.Lock() self._hits 0 self._misses 0 def _generate_key(self, args: tuple, kwargs: dict) - str: args_str |.join(str(arg) for arg in args) kwargs_str |.join(f{k}{v} for k, v in sorted(kwargs.items())) raw_key f{args_str}||{kwargs_str} return hashlib.md5(raw_key.encode(utf-8)).hexdigest() def _clean_expired(self) - None: current_time time.time() expired [k for k, (ts, _) in self._cache.items() if current_time - ts self._default_ttl] for key in expired: del self._cache[key] self._access_times.pop(key, None) def _evict_lru(self) - None: if len(self._cache) self._max_size: return if self._access_times: oldest min(self._access_times.items(), keylambda x: x[1])[0] del self._cache[oldest] del self._access_times[oldest] def get(self, args: tuple, kwargs: dict) - Optional[Any]: key self._generate_key(args, kwargs) current_time time.time() with self._lock: if key not in self._cache: self._misses 1 return None timestamp, result self._cache[key] if current_time - timestamp self._default_ttl: del self._cache[key] self._access_times.pop(key, None) self._misses 1 return None self._access_times[key] current_time self._hits 1 return result def set(self, args: tuple, kwargs: dict, result: Any) - None: key self._generate_key(args, kwargs) current_time time.time() with self._lock: self._clean_expired() self._evict_lru() self._cache[key] (current_time, result) self._access_times[key] current_time def clear(self) - None: with self._lock: self._cache.clear() self._access_times.clear() self._hits 0 self._misses 0 def stats(self) - dict: with self._lock: total self._hits self._misses return { total_items: len(self._cache), max_size: self._max_size, default_ttl: self._default_ttl, hits: self._hits, misses: self._misses, hit_rate: self._hits / total if total 0 else 0.0 } def cache_llm_response(ttl: int 3600, max_size: int 1000): cache LLMResponseCache(default_ttlttl, max_sizemax_size) def decorator(func: Callable) - Callable: functools.wraps(func) def wrapper(*args, **kwargs): cached cache.get(args, kwargs) if cached is not None: return cached try: result func(*args, **kwargs) except Exception: raise cache.set(args, kwargs, result) return result wrapper.clear_cache cache.clear wrapper.cache_stats cache.stats return wrapper return decorator关键优化点说明。缓存键用 MD5 哈希后固定 32 位长 prompt 也不会撑大内存。threading.Lock保证get和set的原子性多线程下不会重复调用大模型。LRU 淘汰在set时触发缓存满时删掉最久未访问的项。异常直接raise不缓存避免把失败结果存下来。stats方法记录命中次数和未命中次数方便你算命中率。4. 接入真实调用链并验证命中率4.1 装饰大模型调用函数把装饰器套到第 2 节的call_llm上TTL 设 10 秒方便测试过期行为容量设 5 方便测试淘汰。cache_llm_response(ttl10, max_size5) def cached_llm_call(prompt: str, model: str gpt-4o-mini) - str: return call_llm(prompt, model)4.2 验证命中与过期写一段测试脚本连续调用三次相同 prompt观察耗时和缓存统计。import time prompt 用一句话解释什么是缓存 start time.time() r1 cached_llm_call(prompt) t1 time.time() - start print(f第一次调用耗时{t1:.2f}秒) start time.time() r2 cached_llm_call(prompt) t2 time.time() - start print(f第二次调用耗时{t2:.2f}秒) print(f两次结果一致{r1 r2}) print(f缓存统计{cached_llm_call.cache_stats()}) time.sleep(11) start time.time() r3 cached_llm_call(prompt) t3 time.time() - start print(f过期后调用耗时{t3:.2f}秒) print(f过期后统计{cached_llm_call.cache_stats()})预期输出第一次耗时 1 秒以上真实调用大模型第二次耗时接近 0 秒缓存命中两次结果完全一致。等待 11 秒后第三次调用耗时又回到 1 秒以上因为缓存已过期。cache_stats里hit_rate会显示 0.33 左右1 次命中2 次未命中。4.3 验证 LRU 淘汰容量设 5连续调用 6 个不同 prompt第 6 个会触发淘汰最早的那个被删掉。for i in range(6): cached_llm_call(f测试问题 {i}) stats cached_llm_call.cache_stats() print(f缓存项数量{stats[total_items]}) # 应该是 5再调用一次测试问题 0会发现它已经被淘汰重新走大模型调用。这就是 LRU 在起作用。4.4 多线程并发验证开 10 个线程同时调用同一个 prompt验证锁是否生效。import threading results [] def worker(): results.append(cached_llm_call(并发测试问题)) threads [threading.Thread(targetworker) for _ in range(10)] for t in threads: t.start() for t in threads: t.join() print(f结果数量{len(results)}) print(f结果去重后数量{len(set(results))}) # 应该是 1 print(f最终统计{cached_llm_call.cache_stats()})如果锁生效10 个线程只会触发一次真实调用其余 9 次全部命中缓存set(results)去重后只有 1 个结果。5. 本篇常见错误排查5.1 缓存键冲突导致返回错误结果症状不同 prompt 返回了相同的缓存结果。原因通常是缓存键生成方式不健壮比如用str(args)拼接时args(1,2)和args(12,)产生相同字符串。解决方法是改用 MD5 哈希并且在拼接时加分隔符|避免参数边界模糊。5.2 多线程下重复调用大模型症状并发请求时日志里出现多次缓存未命中明明 prompt 相同。原因是get和set之间没有锁保护两个线程同时判断缓存不存在都去调大模型。解决方法是把get和set都放在threading.Lock里或者用双重检查锁定模式。5.3 缓存无限增长导致内存溢出症状服务跑几天后内存占用越来越高最终 OOM。原因是没设容量上限缓存项只增不减。解决方法是加max_size参数和 LRU 淘汰策略每次set时检查容量超了就删最久未使用的项。5.4 异常结果被缓存症状某次网络抖动导致大模型调用失败之后相同请求一直返回错误。原因是try-except里把异常也存进了缓存。解决方法是只在func成功返回后才调cache.set异常直接raise不缓存。5.5 TTL 设置不合理症状缓存命中率极低或者用户拿到过期信息。TTL 太短缓存刚存就过期TTL 太长时效性内容一直返回旧结果。解决方法是按内容类型分级设置新闻天气类 5-10 分钟通用知识类 1-24 小时固定模板类 7 天以上。可以在装饰器参数里传入不同 TTL或者按 prompt 前缀动态判断。5.6 缓存键包含无意义参数症状明明 prompt 相同但缓存一直不命中。原因是调用时传了request_id、trace_id这类每次都变的参数导致缓存键每次都不同。解决方法是在装饰器里过滤掉这些参数或者把它们从缓存键生成逻辑里排除。6. 下一步把缓存接入你的生产链路缓存装饰器写好了接下来就是把它用到真实业务里。如果你还在调试阶段建议先用模型对话功能验证一下大模型接口是否正常确认call_llm能稳定返回结果再加缓存层。接入文档里有完整的接口说明和参数列表遇到报错可以先对照排查。对于长期跑编码任务或者 Agent 应用的场景频繁调用大模型是常态缓存带来的成本节省会非常可观。你可以考虑用 Coding Plan 来管理调用配额配合缓存装饰器把重复请求挡在缓存层只让真正需要推理的请求走到大模型。最后分享一个实用技巧在装饰器里加一个cache_stats方法暴露命中率然后用定时任务每分钟打印一次。命中率低于 30% 说明 TTL 太短或者缓存键设计有问题高于 80% 说明缓存效果很好。这个指标比任何监控都直观能帮你快速判断缓存层是否在正常工作。
