从零开始学习网站开发计划wordpress 备案号插件

一、软件介绍

文末提供程序和源码下载

      astrbot_plugin_composting_bucket开源程序是一个用于降低AstrBot的deepseek api调用费用的插件，让deepseek api调用费用更低！

本插件功能已集成到 AstrBot ，您可以移除此插件，在

AstrBot -> 配置文件 -> 服务提供商 -> 大语言模型设置 -> 丢弃对话数量(条)

使用这项功能

本插件未来会继续更新，更新方向为：

提供更多灵活、个性化的配置，以增强DeepSeek API的使用体验。

硬盘缓存，计费降低到原本的约四分之一！

在角色扮演互动的场景中，会产生大量的历史消息上下文，每次新的请求都会携带这些内容

对话越长，消耗的token数量也越多

角色扮演互动中，历史上下文占token消耗的绝大部分

但是DeepSeek api提供硬盘缓存服务，命中缓存的token计费将是未命中的四分之一！

• DeepSeek API 创新采用硬盘缓存，价格再降一个数量级：
  • DeepSeek API 创新采用硬盘缓存，价格再降一个数量级 | DeepSeek API Docs
• 上下文硬盘缓存
  • 上下文硬盘缓存 | DeepSeek API Docs

最美妙的是，这项服务不需要你做任何事！

只需要正常使用，默认开启！

二、命中缓存并非必定触发

• 只有当两个请求的前缀内容相同时（从第 0 个 token 开始相同），才算重复。中间开始的重复不能被缓存命中。
• DeepSeek API 最大上下文长度 64K

一些情况，会导致命中缓存这一机制几乎完全失效！

• 每次请求使用不一样的提示词
  • AstrBot WebUI -> 配置文件 -> 服务提供商 -> 大语言模型设置 -> 启用日期时间系统提示

启用日期时间系统提示，会在系统提示词中加上当前机器的日期时间

这会导致每次请求，上下文从此处开始不再一致

将只有系统提示词的内容会命中缓存，携带的所有历史消息都不会命中缓存！

• 从起始处变化的历史上下文
  • AstrBot WebUI -> 配置文件 -> 服务提供商 -> 大语言模型设置 -> 最多携带对话数量(条)

当对话数量超过这项配置，会逐渐丢弃最旧的对话

同上，这也会导致上下文从此处开始不再一致

即使设置为 -1 不限制最大条数也会导致类似的问题

因为 DeepSeek API 存在最大可处理上下文长度

三、主要做了什么?

• 主要解决的问题是

当对话消息达到 最多携带对话数量(条) 配置时

每次新请求，历史上下文都会有一个新的起始

• 处理方式是:

当历史对话消息数量达到 堆肥桶容量 (max_len) 时

清除最旧的 排出消息量 (pop_len) 条

这样，命中缓存机制将仅在排出旧消息后，失效1次

四、使用建议

• 必须遵循的规则
  • 堆肥桶容量 (max_len) 必须小于 最多携带对话数量(条)
  • 排出消息量 (pop_len) 必须小于 堆肥桶容量 (max_len)
• 建议
  • 建议配合 长期记忆 插件一起使用
    • https://github.com/lxfight/astrbot_plugin_mnemosyne
  • 排出消息量 (pop_len) 不宜过于接近 堆肥桶容量 (max_len)
    • 这会导致保留的上下文过少，影响互动质量
  • 对命中缓存计费问题进行数学建模
    • 对于 max_len 与 pop_len 的取值，如何取，能综合对话质量与计费效益？
    • 如果您擅长数学建模，或对解决这个问题有心得，欢迎您提交issue 讨论！

五、软件下载

夸克网盘分享

本文信息来源于GitHub作者地址：https://github.com/Rail1bc/astrbot_plugin_composting_bucket