聊天记录携带轮数优化以利用缓存 #6123
Description
例行检查
- 我已确认目前没有类似 features
- 我已确认我已升级到最新版本
- 我已完整查看过项目 README，已确定现有版本无法满足需求
- 我理解并愿意跟进此 features，协助测试和提供反馈
- 我理解并认可上述内容，并理解项目维护者精力有限，不遵循规则的 features 可能会被无视或直接关闭
功能描述
现在大部分模型都支持缓存了，而且命中缓存价格都比较低。现在携带固定轮数的历史记录发给AI的时候，会导致达到轮数以后每次滚动的最新6条对话记录无法命中缓存
功能建议
建议将轮数设置为一个动态范围，例如6-12，每当达到12的时候，就会清空缩减保留到6轮，然后再逐渐增加到12的过程中就可以利用缓存
⏺ 两种缓存策略成本对比分析
基本参数
- 提示词：8000 token（固定）
- 每轮对话：2000 token
- 默认价格：0.8 元/M token
- 缓存价格：0.16 元/M token（原价的 20%）
方案一：固定6轮滚动窗口
每次请求的输入：8000 + 6×2000 = 20,000 token
由于滚动（删旧加新），对话部分每次都变化，无法命中缓存：
| 部分 | Token数 | 价格 | 成本 |
|---|---|---|---|
| 提示词 | 8,000 | 0.16元/M | 0.00128元 |
| 对话 | 12,000 | 0.80元/M | 0.00960元 |
| 合计 | 20,000 | - | 0.01088元/次 |
方案二：6-12轮周期循环
一个完整周期（7次请求）：
| 请求 | 轮数 | 缓存部分 | 新增部分 | 成本计算 | 成本 |
|---|---|---|---|---|---|
| 1 | 6→7 | 8,000 | 12,000+2,000 | 8k×0.16 + 14k×0.8 | 0.01248元 |
| 2 | 7→8 | 22,000 | 2,000 | 22k×0.16 + 2k×0.8 | 0.00512元 |
| 3 | 8→9 | 24,000 | 2,000 | 24k×0.16 + 2k×0.8 | 0.00544元 |
| 4 | 9→10 | 26,000 | 2,000 | 26k×0.16 + 2k×0.8 | 0.00576元 |
| 5 | 10→11 | 28,000 | 2,000 | 28k×0.16 + 2k×0.8 | 0.00608元 |
| 6 | 11→12 | 30,000 | 2,000 | 30k×0.16 + 2k×0.8 | 0.00640元 |
注：第1次清空后，对话内容改变，12k对话也无法命中缓存
周期总成本：0.04128元（6次请求）
平均每次：0.04128 / 6 = 0.00688元/次
对比结论
| 指标 | 方案一（固定6轮） | 方案二（6-12轮） |
|---|---|---|
| 每次成本 | 0.01088元 | 0.00688元（平均） |
| 相对成本 | 100% | 63.2% |
| 节省比例 | - | 约37% |
结论
方案二成本更低，约节省 37% 的费用。
核心原因：方案二在增长阶段（第2-6次请求）可以利用前缀缓存，只有新增的2000
token按原价计费，而方案一每次都有12000 token的对话按原价计费。
但需注意：
- 方案二在清空后的第一次请求成本较高
- 方案二的上下文平均长度更大（约18k vs 20k），可能影响响应速度
- 如果对话质量对历史长度敏感，方案二在不同阶段表现可能有差异