GoForum › 🌐 V2EX
压缩上下文居然吃不到缓存？告诉我不是最后一个知道的
lel020 ·
2026-05-11 00:10 ·
0 次点赞 · 7 条回复
Copilot 难民无法承受高昂的 AI 费用，终于堕落到使用中转站了，为此专门搭了个中转站的中转站 metapi, 本意是方便切换中转站的话，不用修改客户端配置, 后台有记录使用日志，能记录输入输出缓存以及价格, 偶然发现，在大部分走缓存的情况下，会突然出现一个请求，基本不走缓存，导致单独这一个请求价格特别高,基本上在 10 倍左右
今天留意了一下，感觉像是压缩上下文导致的。最后一次主动压缩终于确认，就是压缩上下文， 我想了一下，应该是压缩上下文的请求中指令有一些不一样，导致这个不同点之后的内容全部缓存不到，
应该不是中转站本身的问题吧？
亏我原本还想着为了省 token ，提高了使用主动压缩上下文的频率。原以为一个小任务结束，压缩一下再继续是最好的，坑了， https://i.imgur.com/wqK7yZj.png
7 条回复
@bwnjnOEI 我也是这么想的，但是刚刚粗看了一下调试信息，发现压缩上下文这个请求开头没有携带 skill 列表, 这应该就是重要的分歧了。这之前的系统指令依然走了缓存，这之后的所有内容就和普通的请求对不上了 @106npo 输出并不多，压缩非常狠，有用没用的都丢了，几百 K 可能压缩到 1K ， 主要成本还是无缓存的输入 @dockerhub 确实是开头被破坏了，不过我看提示词好像没有找到区别，也可能是提示词太长了，没有去仔细对比它。但我发现了关键区别是 skill 列表没有了
只能说是实现的有问题，并不是必须设计成这样，可能过几个版本又修好了也说不定
我自己实现的多 agent 系统，压缩上下文的时候，就可以命中缓存, https://github.com/alexazhou/TogoSpace
添加回复
你还需要 登录
后发表回复
正常好像压缩过程本身还应该走缓存，压缩之后算新的 session 从头开始预填充