<!-- title: 塞满上下文是在给AI交奢侈品税 -->
<!-- domain: cost-hacks -->

# 塞满上下文是在给AI交奢侈品税：长文一问烧十倍

**导语：** 模型厂商天天拿"1M 上下文窗口"当卖点，国内很多人真信了——把整个代码仓库、整本 PDF、全部聊天记录一股脑塞进一次请求，觉得"反正都能看见，省事"。但你可能没注意：超过 128K token 后，部分厂商会**把单价直接翻倍**；塞得越满，模型反而越容易"中间瞎"（lost in the middle）；而且每一轮对话你都在**全价重复发送同一坨历史**。这一篇拆的是同一个信息差的三层：**长上下文溢价档、长文质量退化、重复输入滚雪球**。读完你会知道怎么把一个 50 轮对话的账单从 30 美元砍到 2 美元——而且答案还更准。

---

## 一、奢侈品税第一条：超过 128K，单价翻倍计价

这是最隐蔽、也最实锤的一笔。绝大多数人盯着"每百万 token 多少钱"这个头部的低价，却没翻到定价表第二行。

Google 的 Gemini 系列从 1.5 Pro 起就采用了**分档计价**：输入 token 在 128K 以内是一个价，超过 128K 进入"长上下文档"，单价直接乘以 2。例如 Gemini 1.5 Pro 的公开定价：≤128K 输入约 $1.25/百万 token，>128K 输入约 $2.50/百万 token；输出同理从 $5 涨到 $10。Flash 的小号版本也是同样的"翻倍档"逻辑。也就是说，你每次把请求撑过 128K 这条线，**每多塞一个 token，单价就贵一倍**——不是多算一倍总价，是边际单价翻倍。

这个结构在 2.x 世代依然延续。很多国内开发者在 Gemini 上跑长文档问答，账单莫名其妙翻番，第一反应是"是不是被限流了""是不是 token 数错了"，实际上就是踩了这条**看不见的分水岭**。

那 Claude 和 GPT 呢？它们的公开定价长期以来是**按 token 平价、不分长度档**——听起来更良心？别急，这正是第二条和第三条税的入口。

> **信息差小结**：用 Gemini 跑长上下文，128K 是一条"价格悬崖"；用 Claude/GPT，虽然没有长度溢价档，但有更狠的"重复输入税"等着你（见第三节）。

---

## 二、奢侈品税第二条：你付了高价，模型反而变笨

比"翻倍计价"更反直觉的是：**塞满上下文，你花钱买到的是更差的答案。**

2023 年 Stanford 的论文《Lost in the Middle: How Language Models Use Long Contexts》（Liu et al., arXiv:2307.03172）揭示了一个现象：把关键信息放在上下文**中间**位置时，模型的召回率显著下降，呈"U 形"——开头和结尾记得牢，中间容易丢。

你可能会说："那是 2023 年的老黄历了，现在的模型 1M 上下文 needle-in-a-haystack 都能 100%。"没错，**单针大海捞针**确实被打磨得近乎完美，厂商也爱拿这个指标宣传。但问题在于：真实任务不是找一根针，而是**多跳推理、多条指令取舍、多文档交叉引用**。这类任务在极端长度下的退化，到 2026 年依然存在——表现为：漏掉中段约束、张冠李戴把 A 文档的结论套到 B 文档、对靠前但被后续内容稀释的指令执行打折扣。

换句话说，**长上下文的"质量曲线"是先升后降的**：

- 0 → ~32K：质量随上下文增加而提升（模型获得更多依据）；
- ~32K → ~128K：边际收益快速递减；
- 128K → 1M：在 Gemini 上单价翻倍，在所有模型上质量开始**净下降**。

这就是真正的奢侈品税：**你为质量退化段付了最高单价。**

> 一个朴素的判断标准：如果你的 prompt 经常超过 100K token，先问一句"这里面有多少是这一轮真正用得上的？"通常答案是不到 10%。

---

## 三、奢侈品税第三条：每一轮都在全价重发历史

这是 Claude / GPT 用户最容易踩、也最贵的坑——**重复输入税**。

对话型应用和 agent 工作流有一个默认行为：每一轮请求都把**完整的对话历史 + 系统提示 + 工具定义**重新发一遍。一个 200K token 的代码库上下文，跑 50 轮迭代，你以为只发了一次，实际账单是 `200K × 50 = 10M` 输入 token。按 Claude Sonnet 平价 $3/百万 算，光输入就是 30 美元——而这些 token **95% 是和上一轮一模一样的**。

这就是为什么"塞满上下文"在 agent 场景下是灾难：它不只是贵一次，而是**每一步都贵一次，复利式滚雪球**。

好消息是，三大厂商现在都提供了**前缀缓存（prompt caching）**，而且机制各不相同，这是和"语义缓存"完全不同的两码事（语义缓存是不同措辞命中同一个答案；前缀缓存是同一串 token 的 KV 缓存直接复用）：

| 厂商 | 机制 | 缓存命中折扣 | 写入成本 |
|---|---|---|---|
| Anthropic | 手动标记 `cache_control: {"type":"ephemeral"}` | 输入价 **0.1×**（省 ~90%） | 1.25× 输入价 |
| OpenAI | 自动缓存（≥1024 token 相同前缀） | 输入价 **0.5×**（省 50%） | 无额外写入费 |
| Google | 显式 context caching API | 远低于常规输入价 | 按存储时长计费 |

注意那个 **0.1×**——这是目前业内最猛的折扣。把稳定的系统提示 + 文档前缀用 `cache_control` 标记一次（写缓存贵 25%），之后 5 分钟内每次命中只付一折。50 轮那笔 30 美元的账，开缓存后能压到 2~3 美元。

但这里有个反直觉的陷阱：**前缀缓存只对"完全相同的前缀"生效，一个字都不能变。** 如果你每轮都往对话最前面插一个时间戳、一个随机 ID、一个"当前是第 N 轮"的标记——恭喜，你亲手把整条缓存前缀打断了，缓存命中率归零，0.1× 的折扣一分钱都用不上。

> **最常见且最致命的缓存杀手**：把动态变量（时间戳、请求 ID、轮次计数、用户随机问候）放在 prompt **最开头**。正确做法是：**静态内容在前，动态内容放最后**，让前面那一大坨稳定部分能被缓存命中。

---

## 四、对账：塞满 vs 检索+缓存

把三层税合起来算一笔真实账。场景：一个有 200K token 代码库上下文的编码 agent，跑 50 轮迭代对话。

**路径 A（塞满 + 不缓存，绝大多数人的默认玩法）：**
- 每轮全量重发 200K；
- Claude Sonnet 平价 $3/百万：`200K × 50 × $3/M ≈ $30`；
- 若在 Gemini 上还可能撞 128K 溢价档，更贵；
- 质量上：200K 中段约束容易被忽略，返工率上升（隐性成本）。

**路径 B（检索 top-5 片段 ≈10K + 稳定前缀开缓存）：**
- 每轮只发 ~10K 新检索内容 + 缓存命中的 30K 系统提示；
- 缓存读 30K × $0.3/M（0.1×）+ 新鲜 10K × $3/M ≈ `$0.009 + $0.03 = $0.039/轮`；
- 50 轮 ≈ **$2**，外加一次写缓存的小额费用。

**结论：同一个任务，$30 → $2，约 15 倍差距，且答案更聚焦（少了干扰的中段内容）。**

```mermaid
flowchart TD
    Q[用户提问] --> D{是否塞满长上下文?}
    D -->|是·路径A 奢侈品税| A1[整库/全文塞入 200K-1M token]
    A1 --> A2{厂商是 Gemini?}
    A2 -->|是| A3[撞 128K 溢价档 单价 x2]
    A2 -->|否 Claude/GPT| A4[平价但无缓存 每轮全量重发]
    A3 --> A5[每轮全量重发]
    A4 --> A5
    A5 --> A6[50轮账单 ~25-30刀]
    A6 --> A7[且 中段丢失 质量下降]

    D -->|否·路径B 检索+缓存| B1[BM25+向量 混合检索 top-5 ≈10K]
    B1 --> B2[静态前缀 开 prompt cache]
    B2 --> B3[每轮只发增量 token]
    B3 --> B4[50轮账单 ~2刀]
    B4 --> B5[上下文更聚焦 质量更稳]

    A7 --> Z1[花更多钱 得更差答案]
    B5 --> Z2[省钱 且 更准]
```

---

## 五、三步"退税"操作指南

**第 1 步：把"塞满"改成"检索"。**
别再把整个仓库/文档丢进上下文。建一个最简的混合检索：用 BM25（关键词，几乎零成本）做一轮粗筛，再用向量召回做精排，最终只取 top-3~5 个片段（通常 5K~15K token）。这一步直接砍掉 90%+ 的输入量。向量库别一上来就 Pinecone 托管——你现有的 Postgres 加 `pgvector` 扩展往往就够了，省掉一份单独订阅。

**第 2 步：把稳定前缀开上缓存，并"清洗"前缀。**
把 system prompt、工具定义、固定的 few-shot 示例放到 prompt **最前面**，用 Anthropic 的 `cache_control: {"type":"ephemeral"}` 标记，或直接享受 OpenAI 的自动缓存。然后做一次前缀审计：把所有时间戳、请求 ID、轮次计数、`new Date()` 之类的动态值**挪到 prompt 末尾**。这一条常常是缓存命中率从 0 到 90% 的关键开关。

**第 3 步：向量维度做 Matryoshka 截断。**
如果你的 RAG 规模在百万级以上，存 1536 维 float32 向量很烧存储和检索算力。用支持 **Matryoshka Representation Learning** 的嵌入模型（如 OpenAI `text-embedding-3-small/large` 通过 `dimensions` 参数），把 1536 维截断到 256 维——存储降到约 1/6，召回率通常只损失 5% 上下。需要更高精度时再走**两级检索**：先用 256 维粗排，再用 1536 维对候选集精排。存储省了，速度还快了。

---

## 信息差总结：你交的税 vs 别人省的钱

| 维度 | 大多数人（在交税） | 信息差玩家（已退税） |
|---|---|---|
| 处理大文档/大仓库 | 整份塞进 1M 窗口 | 检索 top-5 片段，只发相关部分 |
| 长上下文定价 | 不知道 Gemini >128K 翻倍 | 刻意把请求压在 128K 以内 |
| 稳定的系统提示/历史 | 每轮全价重发 | 开 prompt cache，砍到 0.1× |
| 前缀里的动态变量 | 时间戳/轮次放在开头 | 动态值挪到末尾，保住缓存命中 |
| 向量存储 | 1536 维 float32 全量存 | MRL 截断到 256 维，省 ~6 倍 |
| 50 轮 agent 对话成本 | 25~30 美元 | ~2 美元 |
| 长上下文质量 | 撑到 1M，中段信息丢失 | 控制在 32~64K，答案更聚焦 |

---

## 行动指南（今天就能做）

1. **审计你的最长请求**：翻一次最近 7 天的 token 用量日志，找出输入超过 100K 的请求——它们要么踩了 Gemini 溢价档，要么在交重复输入税。
2. **开一个前缀缓存开关**：在 Anthropic 调用里给 system prompt 加 `cache_control`，或在 OpenAI 侧确认相同前缀 ≥1024 token 以触发自动缓存。立刻观察缓存命中率（`cache_read_input_tokens` 字段）。
3. **做一次前缀清洗**：把所有动态变量移到 prompt 末尾，这是把缓存命中率从 0 拉到 90% 的最常见开关。
4. **把"全塞"改成"检索"**：对超过 50K 的文档，先 BM25+pgvector 取 top-5，再喂模型。省 token、提质量。
5. **向量降维**：嵌入入库时把维度从 1536 截到 256（Matryoshka），存储与检索成本立省，召回几乎无损。

---

## 参考来源

- Anthropic 官方 Prompt Caching 文档（`cache_control` 用法与 0.1× 折扣）：https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching
- Google Gemini API 定价页（128K 长上下文分档计价）：https://ai.google.dev/pricing
- 《Lost in the Middle: How Language Models Use Long Contexts》, Liu et al., 2023（arXiv:2307.03172）：https://arxiv.org/abs/2307.03172
- OpenAI 嵌入模型文档（`dimensions` 参数与 Matryoshka 截断）：https://platform.openai.com/docs/guides/embeddings
- Matryoshka Representation Learning 原论文（Kusupati et al., 2022, arXiv:2205.13147）：https://arxiv.org/abs/2205.13147

> *注：文中美元数字为基于公开定价结构的举例测算，便于直观对比量级；具体单价请以各厂商官方页面实时为准。联网工具本期受限，未做实时核验，机制性结论（分档计价、缓存折扣比、MRL 截断）均来自长期稳定的公开文档。*

---
> 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护。
> 聚焦5G/6G核心网、3GPP标准、AI工具实战。知识星球「51学通信」提供深度技术答疑和行业洞察。

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
