一把 key 上六个后端的提示词缓存：同一段前缀谁会重复计费

一把 key 背后其实是六个计费口径

聚合站对用户展示的是一个 API key、一个 OpenAI 兼容入口，但请求最终会被路由到不同厂商的后端。这意味着：同一段提示词前缀，在不同后端上走的是不同的缓存机制、不同的计费规则。

在你这边看到的是统一的 ×1.3 结算，在厂商那边是各自独立的 prompt caching 实现。理解这一点，才能判断“重复长前缀到底有没有被二次计费”。

缓存是后端能力，不是聚合层能力

先把概念理清：

• 提示词缓存由模型提供方实现，缓存键、命中条件、TTL、最小可缓存长度、折扣比例都由各厂商自己定义。
• 聚合层做的是转发与计费换算，它不会替你“记住”上一次的提示词再补发。
• 因此缓存是否命中，取决于发往后端的请求体本身是否与后端已缓存的前缀逐字节一致。

结论很直接：如果请求体每次都不一样，无论走哪个后端，都不会命中缓存，长前缀会被完整重复计费。

各后端命中条件的共性

不同厂商细节不同，但工程上有几条共性值得记住：

1. 前缀匹配：缓存通常只对请求开头的连续片段生效，一旦中间某处不同，后面的内容就不再属于同一缓存前缀。
2. 最小长度门槛：多数实现要求前缀达到一定 token 数才进入缓存，短提示词谈不上命中。
3. TTL 有限：缓存不是永久存储，隔太久再发同样的前缀可能已经过期。
4. 精确一致：多一个空格、换一个换行、时间戳变化，都可能让前缀失配。

这几条决定了：缓存命中率是提示词工程问题，不是接口参数问题。

把提示词切成“稳定段 + 易变段”

要让长前缀真正被复用，推荐的请求体结构是：

[系统指令 / 角色设定]      <- 几乎不变
[长文档 / 知识库 / 代码库]  <- 会话内不变
[少样本示例]              <- 稳定
--- 以上为可缓存前缀 ---
[用户当前问题]            <- 每次都变
[临时上下文 / 时间信息]    <- 每次都变

关键原则：任何会变化的内容都不能出现在稳定段之前。常见踩坑是把当前时间、请求 ID、随机排序的检索结果拼在系统提示词开头，这会让整段前缀每次都不同，缓存永远打不中。

多后端场景下的具体做法

一把 key 调多个模型时，还要注意跨后端的组织方式：

• 同一任务尽量固定后端。同一段前缀先发给 A、再发给 B，是两个独立的缓存空间，不会互相复用。做 A/B 对比评测时这点尤其明显。
• 按后端分别维护前缀模板。各厂商对 system 消息的拼接方式、是否支持显式缓存标记略有差异，模板分开维护比强行统一更稳。
• 变量后置。把模板里的动态槽位统一放到末尾，让前面的结构对所有后端都保持字节级稳定。
• 避免无意义的格式化抖动。比如 JSON 序列化时键顺序随机、列表顺序随机，都会破坏前缀一致性。

怎么验证有没有被二次计费

不要凭感觉判断，用可观测手段：

• 看响应里的 usage 字段。多数后端会分别报告缓存写入 token 与缓存读取 token，如果读取量长期为零，说明前缀没命中。
• 构造对照实验：同一段长前缀连续发两次，比较两次的计费 token 结构；再把前缀开头改一个字符重发，观察差异。
• 记录请求体的哈希。对稳定段做哈希并落日志，一眼能看出哪次请求破坏了前缀一致性。

成本视角的正确表述

聚合站的计价是官方价 ×1.3 扣费、贡献 key 按 ×1.1（优质 ×1.2）返 USDC，这是结算倍率，与后端缓存折扣是两件独立的事。

缓存命中带来的节省发生在厂商侧，会体现在折算前的 token 计量里；倍率是在此基础上叠加的。所以正确的心智模型是：先靠提示词结构把缓存打中，再谈倍率。指望靠换聚合站把长前缀成本降下来，方向就错了。

小结

同一段前缀会不会被重复计费，答案不在聚合层，而在你的请求体是否对每个后端都保持前缀稳定。把稳定内容放前、易变内容放后、同任务固定后端、用 usage 字段验证命中——这四步做完，一把 key 调六个后端时，长前缀的重复计费问题基本就收敛了。