苏姆卡皮首页 / 长上下文与缓存成本
长上下文与缓存成本
苏姆卡皮 · OpenAI 兼容 AI API 网关 · Base URL https://sub.sumcapi.top/v1
长上下文本身不贵，贵的是每次把同样的内容再发一遍。把可复用的前缀固定下来让它命中缓存，是多数业务见效最快的省钱动作。
长上下文与缓存成本
成本从哪来
输入 token ≈ 系统提示词 + 工具定义 + 少样本示例 + 检索片段 + 历史轮次同一个会话或同一批任务里，前几项几乎不变，却因为每次重新发送而被反复计价。缓存的作用就是让重复前缀按更低的缓存价计费。
让缓存命中的四条写法约定
- 前缀严格稳定：系统提示词、工具定义、少样本示例放在最前面，顺序与文本完全一致；日期、trace_id、用户名一律挪到末尾的用户消息里。
- 不要在长前缀中间插入变化：中间任何一个字符不同，都会让它之后的部分全部失效。
- 历史轮次只追加不重写：做上下文压缩时把摘要追加到尾部，不要回头改早期消息。
- 检索片段先去重再拼：Top-K 中重叠内容合并，既省 token 又减少模型自相矛盾。
长文档的三种处理方式
| 方式 | 适合 | 代价 | 建议 |
|---|---|---|---|
| 整篇塞进上下文 | 单次分析、需要全局推理 | 输入 token 高，多问题复用不划算 | 一次提问覆盖多个结论，避免反复投喂 |
| RAG 召回片段 | 高频问答、语料规模大 | 需要建索引与维护切片 | 召回后附来源段落编号，便于校验 |
| 分段摘要再汇总 | 超长文档、批量归档 | 多轮调用，链路变长 | 摘要结果落库复用，不要每次重算 |
实践中常见的是混合：先用稳定前缀做整篇分析拿全局结论，再用 嵌入与检索 支撑高频细节问答。
估算方法（可直接照抄）
- 在控制台「用量统计」取一次真实请求的输入与输出 token；
- 拆成"固定前缀 A"与"每次变化 B"两部分；
- 前缀占比 = A / (A + B)，占比高且调用频繁时缓存收益基本线性；
- 月成本 ≈ 折算缓存价后的单位成本 × 月调用次数，与切换前账单对比即可验证。
倍率、缓存单价与限速以模型广场和控制台的实时展示为准；公式与争议处理见 计费与退款政策。
别忘了延迟与稳定性
- 长上下文会拉长首 token 时间：在线场景精简"必读材料"，可选项交给检索。
- 显式设置输出上限：不设
max_tokens时长文摘要容易一路写到截断，费用和等待都失控。 - 关键链路配置兜底模型：同名模型可能由不同渠道提供，长上下文请求更容易触达上游限制，见 API 文档。
下一步
- 按能力选模型：模型指南
- 稳定输出格式：结构化输出与函数调用
- 成本对照：AI API 成本测算 · 模型定价
常见问题
上下文越长就越贵吗？
输入按 token 计费，所以长度直接决定成本；但重复前缀若能命中缓存，缓存读取价通常远低于常规输入价，长会话反而更划算。
命中缓存需要改代码吗？
大部分情况下只需要调整写法：把稳定内容放在最前面，动态内容追加在后面，不要每轮重新排序系统提示与示例。
多少 token 才算「长上下文」？
经验值：单次请求输入超过 8k token 就值得做前缀规划，超过 32k 必须先确认上游的上下文上限与限速，否则容易 400/429。
长文档一定全量塞进去吗？
不一定。全量塞实现简单、召回完整，但慢且贵；先摘要或抽取候选段落再送入，成本更低；对时效敏感的场景走检索。三者按「命中率 × 成本」实测选择。