V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member Sign In
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
Copilot 难民无法承受高昂的 AI 费用，终于堕落到使用中转站了，为此专门搭了个中转站的中转站 metapi, 本意是方便切换中转站的话，不用修改客户端配置,
后台有记录使用日志，能记录输入输出缓存以及价格, 偶然发现，在大部分走缓存的情况下，会突然出现一个请求，基本不走缓存，导致单独这一个请求价格特别高,基本上在 10 倍左右
今天留意了一下，感觉像是压缩上下文导致的。最后一次主动压缩终于确认，就是压缩上下文，
我想了一下，应该是压缩上下文的请求中指令有一些不一样，导致这个不同点之后的内容全部缓存不到，
应该不是中转站本身的问题吧？
亏我原本还想着为了省 token ，提高了使用主动压缩上下文的频率。原以为一个小任务结束，压缩一下再继续是最好的，坑了，
后台有记录使用日志，能记录输入输出缓存以及价格, 偶然发现，在大部分走缓存的情况下，会突然出现一个请求，基本不走缓存，导致单独这一个请求价格特别高,基本上在 10 倍左右
今天留意了一下，感觉像是压缩上下文导致的。最后一次主动压缩终于确认，就是压缩上下文，
我想了一下，应该是压缩上下文的请求中指令有一些不一样，导致这个不同点之后的内容全部缓存不到，
应该不是中转站本身的问题吧？
亏我原本还想着为了省 token ，提高了使用主动压缩上下文的频率。原以为一个小任务结束，压缩一下再继续是最好的，坑了，
 |
1
bwnjnOEI 18h 39m ago via iPhone
正常好像压缩过程本身还应该走缓存，压缩之后算新的 session 从头开始预填充
|
 |
2
106npo 18h 35m ago
压缩本来就是在重建上下文,而且是个超长输出的任务.
输出很贵+下次请求要重建缓存. |
 |
3
dockerhub 18h 16m ago
压缩是在原来的上下文之前加入提示词，大概内容是告知模型对以下内容进行总结。开头破坏了，就不会梦中缓存了。
|
 |
4
lel020 OP |
 |
5
AlexaZhou 17h 59m ago
只能说是实现的有问题，并不是必须设计成这样，可能过几个版本又修好了也说不定
我自己实现的多 agent 系统，压缩上下文的时候，就可以命中缓存, https://github.com/alexazhou/TogoSpace |
|
6
lel020 OP 哎，AI 时代的经验有明显偏科啊, 以前一直用按次计费的时候，压根不用考虑 token 消耗问题, 现在就很容易焦虑这方面
|
 |
7
Nzelites 17h 39m ago
路过说个题外话，我感觉未来可能 ai 的编排会比单一 ai 的强劲实力重要（在顶端 ai 水平差距越来越小，价格却有极大差距的情况下）良好的编排或许可以让多个廉价的优秀 ai 打赢一个高价的高级 ai ？
|
|
8
bwnjnOEI 16h 54m ago
|
 |
10
XuDongJianSama 12h 52m ago
可以试试这个，相当于是超级压缩，相较于压缩有好处有坏处。
加到 claude.md ，想交接的时候说交接俩字就行 ## 自定义指令 - **"交接"**：输出交接内容供用户复制到新会话继续工作，以 [这是上个会话的交接内容] 开头，方便新会话理解 |
 |
11
sujin190 10h 1m ago via Android
请问用的啥中转程序呐？
|
 |
12
YanSeven 9h 7m ago
如果把压缩指令放在 tail ，压缩效果会有问题吗，应该会走缓存了吧。
|
 |
13
abc0123xyz 9h 2m ago
但是不压缩智商只会越来越低
|
|
14
dockerhub 8h 1m ago
@lel020 #4 在正文 message 里面，CC 是这个样子的。
这个看起来并不是一个非常完美的实现方案，我看上面其他楼实现的方案可以实现缓存命中，核心思路是把压缩提示词进行了追加，这个方案不错。 |
|
16
lel020 OP @abc0123xyz 目前看来最优解似乎是让 AI 自己生成交接文档给新 AI 交接，
但长任务下只能是 agent 自己的逻辑处理， 要么短上下文频繁压缩，要么长上下文减少压缩，感觉不好说哪个更好，甚至现在看来也不好说哪个更便宜了， |
 |
17
fqyd 6h 12m ago
codex 压缩也挺耗资源的，我之前用的 plus ，触发了一次压缩，大概消耗了周额度的 2%、5 小时额度的 10%。现在上下文快满了，就开新会话了。
|
Select Language