1.3 倍规则下的 prompt 缓存：命中与未命中的差价在扣费记录里怎么体现

计费基础：先理解 ×1.3 规则

聚合站按模型官方价格乘以 1.3 扣费，贡献 key 按官方价 ×1.1（优质 ×1.2）返 USDC。这意味着你的账单始终与「官方价」挂钩，缓存折扣也发生在官方价层面，再乘以 1.3 体现在你的余额消耗上。

缓存命中在扣费记录里如何体现

不同后端（Claude、GPT、DeepSeek、Qwen、GLM、Kimi）的缓存机制细节不同，但计费明细通常呈现为两类条目：

• 缓存写入（cache write）：首次请求中未被缓存的前缀部分。Claude 等后端可能对缓存写入单独计价，费率通常高于普通输入；GPT 等后端可能不单独收费，仅按输入 token 计。
• 缓存读取（cache read）：后续请求命中缓存的前缀部分，按显著低于普通输入的费率计费。
• 未命中（cache miss）：未命中部分按普通输入费率计费。

在聚合站的扣费记录中，你会看到输入 token 被拆分为「缓存读取」「缓存写入」「普通输入」三类。由于站内统一乘以 1.3，缓存折扣的绝对值也相应放大，但折扣比例与官方一致。

如何组织提示词提高命中率

缓存通常基于「前缀匹配」：只有从提示词开头起完全一致的部分才可能命中。

• 固定内容放前面：系统提示、角色设定、工具定义、少样本示例等稳定内容放在最前，且保持逐字节一致。
• 动态内容放后面：用户输入、时间戳、随机 ID 等变化内容放在末尾，避免破坏前缀。
• 避免前缀漂移：不要在系统提示中插入每次变化的字段（如当前时间、请求编号）。
• 结构化模板：用统一的模板拼接提示词，保证前缀稳定；变更模板时集中发布，减少碎片化。
• 合理设置缓存断点：若后端支持显式缓存标记，将断点放在稳定段末尾，覆盖最长的可复用前缀。
• 控制前缀长度：缓存通常有最小 token 门槛，过短的前缀无法命中；确保稳定段达到门槛。

查看扣费记录与验证效果

在聚合站的控制台中，按请求查看扣费明细，对比同一提示词模板下「缓存读取」占比的变化。命中率提升后，输入侧费用会下降，但由于输出费用不变，整体节省幅度取决于输入占比。

注意事项

• 缓存有生命周期，长时间不请求后可能失效，首次请求会重新写入。
• 不同模型的缓存策略不同，切换模型时不要假设缓存通用。
• 计费明细中的缓存折扣比例以官方为准，聚合站仅在此基础上统一乘以 1.3。