导语： 模型厂商天天拿"1M 上下文窗口"当卖点，国内很多人真信了——把整个代码仓库、整本 PDF、全部聊天记录一股脑塞进一次请求，觉得"反正都能看见，省事"。但你可能没注意：超过 128K token 后，部分厂商会把单价直接翻倍；塞得越满，模型反而越容易"中间瞎"（lost in the middle）；而且每一轮对话你都在全价重复发送同一坨历史。这一篇拆的是同一个信息差的三层：长上下文溢价档、长文质量退化、重复输入滚雪球。读完你会知道怎么把一个 50 轮对话的账单从 30 美元砍到 2 美元——而且答案还更准。
这是最隐蔽、也最实锤的一笔。绝大多数人盯着"每百万 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 文档、对靠前但被后续内容稀释的指令执行打折扣。
换句话说，长上下文的"质量曲线"是先升后降的：
这就是真正的奢侈品税：你为质量退化段付了最高单价。
一个朴素的判断标准：如果你的 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%） | 无额外写入费 |
| 显式 context caching API | 远低于常规输入价 | 按存储时长计费 |
注意那个 0.1×——这是目前业内最猛的折扣。把稳定的系统提示 + 文档前缀用 cache_control 标记一次（写缓存贵 25%），之后 5 分钟内每次命中只付一折。50 轮那笔 30 美元的账，开缓存后能压到 2~3 美元。
但这里有个反直觉的陷阱：前缀缓存只对"完全相同的前缀"生效，一个字都不能变。 如果你每轮都往对话最前面插一个时间戳、一个随机 ID、一个"当前是第 N 轮"的标记——恭喜，你亲手把整条缓存前缀打断了，缓存命中率归零，0.1× 的折扣一分钱都用不上。
最常见且最致命的缓存杀手：把动态变量（时间戳、请求 ID、轮次计数、用户随机问候）放在 prompt 最开头。正确做法是：静态内容在前，动态内容放最后，让前面那一大坨稳定部分能被缓存命中。
把三层税合起来算一笔真实账。场景：一个有 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 倍差距，且答案更聚焦（少了干扰的中段内容）。
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 维对候选集精排。存储省了，速度还快了。
| 维度 | 大多数人（在交税） | 信息差玩家（已退税） |
|---|---|---|
| 处理大文档/大仓库 | 整份塞进 1M 窗口 | 检索 top-5 片段，只发相关部分 |
| 长上下文定价 | 不知道 Gemini >128K 翻倍 | 刻意把请求压在 128K 以内 |
| 稳定的系统提示/历史 | 每轮全价重发 | 开 prompt cache，砍到 0.1× |
| 前缀里的动态变量 | 时间戳/轮次放在开头 | 动态值挪到末尾，保住缓存命中 |
| 向量存储 | 1536 维 float32 全量存 | MRL 截断到 256 维，省 ~6 倍 |
| 50 轮 agent 对话成本 | 25~30 美元 | ~2 美元 |
| 长上下文质量 | 撑到 1M，中段信息丢失 | 控制在 32~64K，答案更聚焦 |
cache_control，或在 OpenAI 侧确认相同前缀 ≥1024 token 以触发自动缓存。立刻观察缓存命中率（cache_read_input_tokens 字段）。cache_control 用法与 0.1× 折扣）：https://docs.anthropic.com/en/docs/build-with-claude/prompt-cachingdimensions 参数与 Matryoshka 截断）：https://platform.openai.com/docs/guides/embeddings注：文中美元数字为基于公开定价结构的举例测算，便于直观对比量级；具体单价请以各厂商官方页面实时为准。联网工具本期受限，未做实时核验，机制性结论（分档计价、缓存折扣比、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 等场景全覆盖。