长上下文成本是什么
超长上下文有三个代价：输入 token 线性计费，长资料反复发送会持续叠加；注意力质量衰减，中段信息利用率下降；部分厂商对超过阈值的长上下文设置更高单价档（以官网为准）。因此正解是用缓存与检索缩减输入，而不是无脑堆窗口。判断标准很直接：同一份资料如果会被反复使用，就第一次写进缓存或知识库，之后每轮只带几百 token 的检索片段，通常从第二轮起就比每轮重发全文更便宜。
基本信息
| 计费方式 | 输入 token 数乘以单价，长资料反复发送成本叠加 |
|---|---|
| 质量影响 | 超长上下文中部信息利用率下降 |
| 价档变化 | 部分厂商超阈值后单价上浮（以官网为准） |
| 对策一 | 缓存稳定前缀，配合缓存折扣 |
| 对策二 | 检索按需注入，只送相关片段 |
| 对策三 | 摘要压缩，保留数字与限定条件 |
典型使用场景
- 长文档助手：同一手册被反复提问，应先入缓存或知识库
- 代码仓库问答：不要每轮贴整仓代码，改为检索相关文件
- 会议材料分析：先摘要再按问题注入细节
- 批量标注：同一批资料反复使用，应结合缓存与批处理
- 成本对比：评估「加窗口」与「加检索层」两条路线的总成本
两种成本结构对比
两种成本结构对比
方案 A：每轮请求都带 5 万 token 全文
成本 = 50K × 单价 × 轮数（每轮都重新付费）
方案 B：全文进缓存或知识库
成本 = 首次写入成本 + 每轮约 0.5K 检索片段 + 缓存读折扣
# 轮数越多，方案 B 的优势越明显；轮数等于 1 时方案 A 更省
# 具体折扣与单价档以厂商官网计价为准，先按自家用量测算再选型
# 关键资料放最前面，避免中段忽略导致的返工成本三种输入方式对比
| 方式 | 计费特征 | 适用情况 |
|---|---|---|
| 每轮发送全文 | 全文 token 乘以轮数 | 一次性、只问一次的任务 |
| 缓存后引用 | 首次写入加每轮折扣读取 | 同一资料被反复提问 |
| 检索按需注入 | 每轮只付命中片段 | 资料量大、问题分散 |
| 摘要后注入 | 压缩成本加较小的固定输入 | 需要整体理解的归纳任务 |
把长上下文能力当卖点前先算账：反复发送的长文本是持续成本，不是一次性投入，用量上来后差异会非常明显。
长窗口替代检索还有隐性代价：无法按权限过滤、无法引用出处、无法控制噪声，成本之外的功能性损失同样要考虑。