09 中转站猫腻，缓存省下的钱到底给了谁

前面几节讲的是模型和 Agent 框架。到中转站这里，问题会变得更现实。

模型有没有缓存，是一回事。用户有没有拿到缓存收益，是另一回事。

Claude、OpenAI、DeepSeek 都会在 usage 里返回缓存相关信息。字段名字不同，但作用差不多：让你知道这轮输入里，哪些按普通输入算，哪些走了缓存优惠。

这些信息一旦经过中转站，就可能消失。

很多 OpenAI-compatible API 会把不同供应商的 usage 统一成一套简单格式。接入方便了，缓存账本也被压平了。用户最后只看到总 input token，看不到上游到底省了多少。

这里就有第一层问题。

上游可能已经按缓存读取收了便宜价，中转站仍然按普通输入给用户计费。它不需要改请求，只要账单不区分普通输入和缓存输入，用户就很难发现。DeepSeek 这种 hit / miss 价差很大的模型尤其明显。

第二层问题是路由。

Prompt caching 依赖前缀一致，也依赖请求落到能复用缓存的位置。中转站如果在多个 key、workspace、region、上游账号之间轮询，同一个会话的请求就可能被打散。

用户看到的模型名可能一直没变，比如 claude-opus-4-8、gpt-5.5、deepseek-v4-pro。但背后实际走到哪个上游渠道，用户通常不知道。

有时中转站自己也未必掌握完整链路。它上面可能还接了别的聚合层、云厂商入口、区域路由或备用渠道。模型名保持一致，不代表缓存位置也一致。

第三层问题是请求被中转站改写。

有些中转站会插入自己的 system prompt，改 tool schema，或者为了兼容 OpenAI-compatible 格式重排 messages。用户以为自己发出去的是原始请求，实际到上游时，前缀已经变了。

这和缓存直接相关。Prompt caching 看的是请求前缀，前缀被中转站改过，用户自己保持稳定也没用。更麻烦的是，这类改写通常不会出现在用户侧日志里。用户只能看到自己发给中转站的请求，看不到中转站转给上游的最终请求。

所以判断中转站，不能只看标价。

便宜单价没有意义，关键要看它怎么处理缓存账本。

至少看三件事。

第一，usage 字段有没有透传。最好能看到供应商原始字段，不能只给一个总 token。

第二，缓存输入怎么计费。上游低价读取的部分，是不是也按低价算给用户。

第三，同一会话有没有路由粘性。连续任务里，请求最好固定在同一组上游资源上，不要每轮乱跳。

所以这一节先不写测试方案。

判断中转站有没有把缓存收益还给用户，不能靠几句泛泛的“连续请求试一下”。真实情况会受模型、TTL、路由、上游账号、计费粒度、账单刷新延迟影响。测试设计不严谨，很容易把缓存没命中、账单没透传、路由打散、后台延迟这几件事混在一起。

这里先把原则说清楚：没有请求级 usage，没有缓存输入的计费说明，没有路由粘性说明，就很难对账。后面讲“怎么判断”时，再单独设计可执行的检查步骤，不把它揉在中转站这一节里。