谷歌最近在其Gemini API中添加了上下文缓存功能,旨在解决长上下文语言模型(LLM)的一些主要局限性。虽然LLM可以保持大量信息,但它们存在几个问题:

• 处理时间增加: 每次查询时,整个上下文都需要发送到LLM,这导致处理大量数据,从而增加了处理时间。
• 高延迟: 每次查询所需的大数据传输导致高延迟。
• 更高成本: 由于API提供商根据令牌数量收费,数据传输增加导致成本更高。

谷歌的上下文缓存功能试图缓解这些问题。它的工作原理如下:

1. 初始化缓存: 您提供一个系统指令或大型上下文(如文档、视频文件、音频文件)以进行缓存。
2. 缓存标识: 每个缓存都有一个唯一的标识符,可以视为缓存的名称,以及一个"生存时间"参数来确定缓存的过期时间。
3. 缓存检索: 当Gemini API收到用户查询时,它会分析可用的缓存数据集,检索适当的缓存,并将其与用户的查询组合进行处理。

这种方法提供了几个好处:

• 减少处理时间: 通过重用缓存数据,系统只需处理用户的查询,从而减少了整体处理时间。
• 降低延迟: 只发送用户的查询,而不是整个上下文,可以降低延迟。
• 节省成本: 减少每次查询发送的令牌数量可以降低成本。

谷歌声称,对于最多2,128,000个令牌的缓存使用,成本可以比每次查询发送整个上下文减少近四倍。

需要注意的是,使用上下文缓存也有一些限制和注意事项:

• 最小输入令牌数: 上下文缓存的最小输入令牌数目目前设定为32,000个令牌。
• 最大令牌数: 可缓存的最大令牌数受模型最大上下文窗口的限制,对于Gemini Pro和Flash模型都约为2百万个令牌。
• 存储成本: 缓存内容会产生存储成本,为每百万个令牌每小时1美元。

总的来说,谷歌Gemini API中的上下文缓存功能是一个有价值的补充,可以显著提高基于LLM的应用程序的性能和成本效益,特别是对于处理大量上下文的应用程序。