基本缓存策略

将一个可用的LLM应用原型转变为可部署的系统，需要解决实际的工程难题。一个主要的优化方面是管理重复调用LLM API所产生的成本和延迟。基本的缓存策略提供了一种有效的方法来提升性能和成本效益。

LLM API调用可能相对较慢，涉及网络通信和提供方大量的计算时间。此外，大多数商业API根据处理的输入和输出token数量收费。如果你的应用程序频繁向LLM发送相同或相似的提示，你将承担不必要的成本和延迟。缓存提供了一种解决方案，通过存储昂贵操作（如API调用）的结果，并在再次出现相同输入时重用这些结果。

为什么缓存LLM响应？

即使为LLM交互实施简单的缓存，也能带来多项益处：

1. 降低成本： 这通常是最主要的原因。通过存储给定提示及其参数的响应，你可以避免在稍后发出完全相同的请求时进行新的API调用。由于API使用通常按token计量，消除冗余调用直接意味着更低运营开销。
2. 改善延迟： 从本地缓存（如服务器内存或快速缓存服务）获取响应比往返外部LLM API快得多。这使得重复请求的用户体验更加迅速。
3. 速率限制管理： LLM提供商对API使用施加速率限制（例如，每分钟请求数）。缓存减少了API调用的总数，使得你的应用程序不太可能触及这些限制，从而提升可靠性。

简单的缓存策略

对于许多应用程序而言，基本的缓存方法足以实现很大的收益。

内存缓存

最简单的缓存形式是使用应用程序内存中的标准数据结构。在Python中，字典是存储请求到响应映射的常见选择。

# 内存缓存示例
llm_cache = {}

def get_llm_response_with_cache(prompt, params):
    cache_key = generate_cache_key(prompt, params) # 生成唯一键的函数

    if cache_key in llm_cache:
        print("缓存命中！")
        return llm_cache[cache_key] # 返回缓存响应
    else:
        print("缓存未命中。正在调用API...")
        response = call_llm_api(prompt, params) # 实际API调用
        llm_cache[cache_key] = response # 将响应存储到缓存中
        # 可选：在此处实现缓存大小限制逻辑（例如，LRU）
        return response

# 示例辅助函数（简化版）
def generate_cache_key(prompt, params):
    # 在实际应用中，使用提示 + 排序参数的哈希值
    return hash((prompt, tuple(sorted(params.items()))))

# 实际API调用函数的占位符
def call_llm_api(prompt, params):
    # ... 与LLM API交互的逻辑 ...
    return f"Response for: {prompt} with params {params}"

# 用法
params1 = {'temperature': 0.7, 'max_tokens': 100}
response1 = get_llm_response_with_cache("Summarize this text: ...", params1)
print(response1)

response2 = get_llm_response_with_cache("Summarize this text: ...", params1) # 相同请求
print(response2)

• 优点： 访问速度极快（内存速度），对于基本用例实现简单。
• 缺点：
  • 非持久性： 如果应用程序重启，缓存会丢失。
  • 扩展性限制： 你的应用程序的每个实例都维护自己独立的缓存。如果你在负载均衡器后运行多个实例，这效率不高，因为相同的请求可能会命中不同的实例，导致缓存未命中。
  • 内存占用： 存储大型LLM响应会占用大量内存。你需要限制缓存大小的策略（例如，最近最少使用淘汰）。

外部缓存系统（简要概述）

对于需要持久性或跨多个应用程序实例共享缓存的更复杂情况，通常使用专门的缓存系统，如Redis或Memcached。它们作为独立服务运行，你的应用程序与之通信。

• 优点： 持久性（可配置），多个应用程序实例可访问的共享缓存，高级功能（如存活时间、淘汰策略）。
• 缺点： 增加了基础设施复杂性（安装、管理缓存服务器），引入了访问缓存的少量网络延迟（尽管通常非常低）。

尽管功能强大，但设置和管理外部系统超出了“基本”缓存的范畴。对于许多初始应用程序或小型部署，内存缓存提供了一个不错的起点。

定义缓存键

缓存的一个重要方面是确定什么构成唯一请求。不仅仅是提示文本本身。LLM生成通常受以下参数影响：

• model：正在使用的具体LLM（例如，gpt-4，claude-3-opus）。
• temperature：控制随机性。
• max_tokens：限制响应长度。
• top_p：核心采样参数。
• 任何其他影响输出的参数（stop_sequences等）。

因此，你的缓存键应唯一表示提示和所有相关生成参数的组合。一个常见的方法是创建提示和排序参数的字符串表示，然后使用哈希函数（如SHA-256）生成一个一致的、固定大小的键。

缓存失效：保持数据新鲜

一个项目应该在缓存中停留多久？这是缓存失效的问题。对于LLM响应，如果提示和参数相同，确定性模型的理想响应可能也是相同的。然而，模型更新或非确定性生成中的微小变化（temperature > 0）等因素使情况变得复杂。

一种简单且常用的策略是存活时间（TTL）：

• 为每个缓存项目分配一个过期时间（例如，1小时，1天）。
• TTL过期后，该项目将被移除或视为过期，强制在下一次请求时进行新的API调用。
• 适当的TTL取决于你预期给定提示的“正确”答案变化的速度，或者仅仅作为控制缓存大小和定期刷新可能次优的缓存结果的机制（尤其是在使用较高温度时）。

实施考量

• 缓存键生成： 确保你的键生成是确定性的并处理潜在冲突（尽管使用好的哈希函数时可能性较小）。对提示和参数的规范表示（例如，已排序的键值对元组）的组合进行哈希处理。
• 缓存大小管理： 对于内存缓存，实施大小限制（例如，最大条目数或总内存使用量）和淘汰策略（如最近最少使用——LRU）以防止内存无限增长。有许多库可以帮助实现这一点（例如，Python的functools.lru_cache装饰器或专用缓存库）。
• 序列化： 存储复杂响应对象（不仅仅是字符串）时，确保它们可以正确地序列化（转换为可存储的格式，如JSON或字节）和反序列化。

缓存逻辑示意图

下图描绘了包含缓存检查时的基本流程：

包含缓存检查的请求处理流程。如果生成的键存在于缓存中，则直接返回存储的响应；否则，调用LLM API，并将结果存储后再返回。

通过实施这些基本缓存策略，你可以大幅降低LLM应用程序的运营成本并提高其响应速度，使其更具实用性和可扩展性。即使是一个具有合理淘汰策略的简单内存缓存也能以相对较少的实施工作带来很大的益处。