跳到主要内容

上下文硬盘缓存

WillingPick 上下文硬盘缓存技术对所有用户默认开启，用户无需操作即可享用。

用户的每一个请求都会触发硬盘缓存的构建。若后续请求与之前的请求在前缀上存在重复，则重复部分只需要从缓存中拉取，计入"缓存命中"。

注意：两个请求间，只有重复的前缀部分才能触发"缓存命中"，详见下面的例子。

例：多轮请求​

第一次请求

messages: [
    {"role": "user", "content": "<男>"}
    {"role": "user", "content": "<33岁>"}
    {"role": "user", "content": "<185cm+>"}
    {"role": "user", "content": "<成都>"}
    {"role": "user", "content": "<性格稳定>"}
]

第二次请求

messages: [
    {"role": "user", "content": "<男>"}
    {"role": "user", "content": "<33岁>"}
    {"role": "user", "content": "<185cm+>"}
    {"role": "user", "content": "<成都>"}
    {"role": "user", "content": "<性格稳定>"}
]

在上例中，两次请求都有相同的条目，即 user 消息中的内容。

第二次请求时，复用第一次请求中的 user 消息内容（包括文字字符、间隔逗号、分隔符号），这部分会计入"缓存命中"。

在实际应用中，用户可以通过调整必选条目的方式，来提升模型的输出效果。在请求中找到适合的条目搭配模式，在硬盘缓存的加持下，tokens的费用显著降低。

硬盘缓存与输出随机性​

硬盘缓存只匹配到用户输入的前缀部分，输出仍然是通过计算推理得到的，仍然受到 temperature 等参数的影响，从而引入随机性。其输出效果与不使用硬盘缓存相同。

其它说明​

  1. 缓存系统以 516 tokens 为一个存储单元，不足 516 tokens 的内容不会被缓存。
  2. 缓存系统是"尽力而为"，不保证 100% 缓存命中。
  3. 缓存构建耗时为秒级。缓存不再使用后会自动被清空，时间一般为几个小时到几天。