1M 长上下文的价格真相：用满一次到底花多少钱
模型发布会上，上下文窗口是必报参数：1M、2M，数字一年比一年大。很多人选型时也把它当硬指标——窗口越大越好，反正放着不用又不要钱。前半句没错，后半句错得很贵：API 按输入 token 计费，上下文是容量上限，不是赠品。你塞多少，就按多少收钱；塞满，就按满收。
算一笔最直白的账：Claude Opus 4.8 输入价 ¥33.93/百万 token，把 1M 上下文塞满发一次请求，光输入就是 33.93 × 1,000,000/1,000,000 = ¥33.93。Gemini 3.1 Pro Preview 标称 ¥13.57/M 看着便宜一半多，但它对超过 20 万 token 的请求整单按高档计价（¥27.14/M），用满 2M 实际是 27.14 × 2 = ¥54.28——比 Opus 还贵。注意，这都是一次请求的钱，输出还没算。
这篇把长上下文的真实成本拆成四笔账：用满一次的标价、多轮对话的累计雪球、长文档 QA 里整本塞与 RAG 的对照算式，以及缓存能救到什么程度。最后说清楚哪些场景真值得把窗口用满。
用满一次的标价：ctx ≥ 1M 的模型都在这
公式只有一行：满上下文一次请求的输入费 = 该请求所在档的输入单价（¥/百万 token）× 上下文长度（百万 token）。下表是目前价格库里上下文 ≥ 1M 的全部模型，按用满一次的输入费从高到低排。
为什么要强调『所在档』：有几家对长输入是分档计价的，超过阈值不是只对超出部分涨价，而是整单按高档算。表里标 ▲ 的行就是这种——Gemini 3.1 Pro Preview / Gemini 2.5 Pro / Claude Sonnet 4.6 / Grok 4.3 都是单次输入超过 20 万 token 后单价翻倍，Qwen3.5 Plus/Flash 则是 13 万、26 万两道坎、共三档。所以这些行的『输入价』列是首档标价，『用满一次』列已经按跨档后的高档价算过了，两列对不上是正常的。
同样标着『1M 级长上下文』，用满一次的钱差出近 100 倍（67.86 ÷ 0.68 ≈ 99.8）。另一个反直觉的点：Gemini 3.1 Pro Preview 单价 ¥13.57/M 不到 Opus 4.8 的一半，但窗口是 2M、且跨档后单价翻倍，真用满要 ¥54.28——不是接近 Opus，是反超它六成。看单价不够，得看『你实际会塞多少 × 那个量对应的档位价』。
还没完——输出另算。Opus 4.8 输出价 ¥169.63/百万 token，如果顶满 64K 输出，再加 169.63 × 64,000/1,000,000 ≈ ¥10.86。一次满窗口请求合计约 ¥44.8。
| 模型 | 上下文 | 输入价(¥/M) | 用满一次输入费 |
|---|---|---|---|
| Claude Fable 5 | 1M | ¥67.86 ($10) | ¥67.86 |
| Gemini 3.1 Pro Preview ▲ | 2M | ¥13.57 ($2) | ¥54.28 |
| Claude Sonnet 4.6 ▲ | 1M | ¥20.36 ($3) | ¥40.71 |
| Claude Opus 4.8 | 1M | ¥33.93 ($5) | ¥33.93 |
| Claude Opus 4.7 | 1M | ¥33.93 ($5) | ¥33.93 |
| Gemini 2.5 Pro ▲ | 2M | ¥8.48 ($1.25) | ¥33.93 |
| Grok 4.3 ▲ | 1M | ¥8.48 ($1.25) | ¥16.96 |
| Qwen3.7 Max | 1M | ¥12.00 | ¥12.00 |
| Gemini 3.5 Flash | 1M | ¥10.18 ($1.5) | ¥10.18 |
| MiniMax M3 | 1M | ¥4.20 | ¥4.20 |
| Qwen3.5 Plus ▲ | 1.05M | ¥0.80 | ¥4.19 |
| DeepSeek V4 Pro | 1M | ¥3.00 | ¥3.00 |
| MiniMax M2.7 | 1M | ¥2.10 | ¥2.10 |
| Gemini 2.5 Flash | 1M | ¥2.04 ($0.3) | ¥2.04 |
| Gemini 3.1 Flash-Lite | 1M | ¥1.70 ($0.25) | ¥1.70 |
| Qwen3.5 Flash ▲ | 1.05M | ¥0.20 | ¥1.26 |
| DeepSeek V4 Flash | 1M | ¥3 峰时 / ¥1.5 空闲 | ¥3 峰时 / ¥1.5 空闲 |
| Gemini 2.5 Flash-Lite | 1M | ¥0.68 ($0.1) | ¥0.68 |
多轮对话的雪球：你发了 20 个字，计费的是 14 万 token
LLM API 是无状态的——服务端不记得上一轮聊了什么，每一轮都要把系统提示加全部历史原样重发，重发的部分按输入价全额计费。这意味着长对话的成本不是线性涨，而是近似平方级涨：历史越长，每一轮的『底座』越厚。
算个典型的 agent 会话：起始上下文 50K token，每轮新增约 10K。第 1 轮输入 50K，第 10 轮输入 140K，10 轮累计输入 = 950K token。用 Opus 4.8 跑约 ¥32.23，Claude Sonnet 4.6 约 ¥19.34；DeepSeek V4 Pro 峰时为 9 × 0.95 = ¥8.55，空闲为 4.5 × 0.95 ≈ ¥4.28。分档看单次请求输入量，分时则看请求发生的北京时间；这个例子每轮最多 140K，没跨 Sonnet 的 20 万门槛，但 DeepSeek 仍必须按实际时段计费。
工程上的对策都不新鲜，但确实管用：
- 截断历史：只保留最近 N 轮 + 系统提示，老历史丢掉或换成滚动摘要
- agent 的工具输出落盘，上下文里只留路径和摘要，需要时再读
- 长会话定期『重开』：把结论压缩成一段新系统提示，从零开始
长文档 QA：整本塞进去，还是 RAG？
场景：一套 30 万 token 的文档库（大约几百页 PDF），团队每天问 20 个问题。两条路：方案 A 每次把整库塞进上下文；方案 B 上 RAG——检索增强生成，白话讲就是先用向量检索从文档里捞出最相关的几段，只把这几段（按 5K token 算）发给模型。
方案 A 的日输入量是 300K × 20 = 6M token；方案 B 是 5K × 20 = 100K = 0.1M token。输入量直接差 60 倍（6M ÷ 0.1M），费用按模型算如下表。
RAG 不是免费午餐：要做切片、维护向量库、调检索质量，问题答不准时排查链路也更长。如果文档只有几万 token、一周问不了几次，整本塞反而省事。但像上面这种每天 20 问的重复场景，差的是数量级，工程投入很快回本。
| 方案 | 日输入量 | 日输入费 | 30 天 |
|---|---|---|---|
| 整本塞 × Claude Opus 4.8 | 6M | 33.93 × 6 = ¥203.58 | ¥6,107.40 |
| 整本塞 × DeepSeek V4 Flash | 6M | ¥18 峰时 / ¥9 空闲 | ¥540 峰时 / ¥270 空闲 |
| RAG × Claude Opus 4.8 | 0.1M | 33.93 × 0.1 ≈ ¥3.39 | ¥101.79 |
| RAG × DeepSeek V4 Flash | 0.1M | ¥0.30 峰时 / ¥0.15 空闲 | ¥9 峰时 / ¥4.50 空闲 |
缓存能救吗：能省九成，但治标
Prompt 缓存的原理：请求里重复出现的前缀（比如那本 30 万 token 的文档）在厂商侧缓存，后续请求命中时按便宜得多的缓存价计费。Opus 4.8 的缓存命中价是 ¥3.39/百万 token，约为输入原价的十分之一。
套回上面的整本塞场景：假设文档全部命中缓存，Opus 每问约 ¥1.02，一天 20 问约 ¥20.34；对比 RAG 方案的 ¥3.39/天仍是 6 倍。DeepSeek V4 Flash 缓存命中峰时 ¥0.10/M、空闲 ¥0.05/M：每问 30 万 token 文档分别约 ¥0.03/¥0.015，一天 20 问约 ¥0.60/¥0.30（未计可变问题与缓存写入）。缓存把斜率压低了，但仍要按时段、命中率和写入规则核算。
几个常见的翻车点：缓存命中要求前缀逐字节一致，文档前面改一个字、或者把动态内容（时间戳、用户名）放在了文档前头，就全员 miss；缓存有有效期，低频访问可能反复过期重建；首次写入通常另有计费。各家规则差异不小，以官方文档为准。另外缓存只救重复前缀，救不了多轮对话里每轮新增的历史，更救不了输出费。
什么时候长上下文真值得用满
骂完该说公道话：有些任务的价值恰恰在『全部内容同时在场』，切片会直接毁掉任务本身。
判断标准其实就一条：任务需要的是全局关联还是局部检索？前者值得整本塞，后者用 RAG。值得的典型场景：
- 跨文档推理：5 份合同对照找冲突条款、多份财报横向比对——关联本身分散在文档各处，检索切片给不出全局视角
- 整库代码理解：出重构方案要看跨文件调用链和依赖图，这正是 RAG 切片丢掉的东西
- 一次性任务：读完 50 万 token 的代码库出一份迁移评估，只调一次，Opus 4.8 也就 33.93 × 500,000/1,000,000 ≈ ¥16.97，比工程师人肉读三天便宜得多
- 低频高价值：法律尽调、论文综述这类一个月跑几次的活，单次贵点无所谓
选型建议：先用便宜的 1M 把流程跑通
真决定用满长上下文，先拿低价模型验证流程：Gemini 2.5 Flash-Lite 用满 1M 输入约 ¥0.68，Qwen3.5 Flash 用满 1.05M 因跨第三档约 ¥1.26，DeepSeek V4 Flash 用满 1M 峰时 ¥3、空闲 ¥1.5，MiniMax M2.7 为 ¥2.10。确认任务确实需要旗舰质量，再比较 Opus 4.8（¥33.93/1M 输入）或 Gemini 3.1 Pro Preview（用满 2M ¥54.28）。挑验证模型也要按完整请求所处档位和时段算，不能按首档标称价。
最后一个提醒：标称 1M 不等于全程稳定可用。长上下文末端的检索和推理精度普遍会衰减（业内常说的 lost in the middle），关键信息别埋在中段，各家衰减程度差异也大——窗口大小是营销数字，有效窗口得自己测。完整的长上下文模型横向对比可以看 /compare/long-context-llm，具体用量套自己的参数算一遍，比任何文章的结论都可靠。
常见问题
1M 上下文用满一次到底要花多少钱？
输入费 = 该请求所在档或时段的输入单价 × 上下文长度。Claude Opus 4.8 用满 1M 为 ¥33.93；Gemini 3.1 Pro Preview 用满 2M 因升档为 ¥54.28；DeepSeek V4 Flash 用满 1M 峰时 ¥3、空闲 ¥1.5；Gemini 2.5 Flash-Lite 用满 1M 为 ¥0.68。输出 token 另计，默认预算取 DeepSeek 峰时价。
多轮对话为什么越聊越贵？
LLM API 无状态，每一轮都要把系统提示加全部历史重发并按输入价全额计费，累计费用随轮数近似平方级增长。起始 50K、每轮增 10K 的会话，10 轮累计输入就有 950K token，用 Opus 4.8 约 ¥32.23——几乎等于用满一次 1M 的钱。
Prompt 缓存能解决长上下文贵的问题吗？
能大幅缓解但治标：Opus 4.8 缓存命中价 ¥3.39/M 约为输入原价的十分之一，30 万 token 文档全命中时每问约 ¥1.02，但日费用仍约为 RAG 方案的 6 倍。缓存要求前缀逐字节一致且有有效期，写入另有计费，具体规则以官方文档为准。
长文档问答该整本塞还是用 RAG？
看频率和任务类型。每天 20 问的重复 QA，整本塞 30 万 token 日输入 6M，用 Opus 4.8 要 ¥203.58/天，RAG 只送 5K 切片则约 ¥3.39/天，差 60 倍。但跨文档推理、整库代码理解这类需要全局关联的任务，切片会丢信息，值得整本塞。
最便宜的 1M 级长上下文模型是哪个？
要分清标称首档和用满成本。Gemini 2.5 Flash-Lite 用满 1M 输入约 ¥0.68；Qwen3.5 Flash 用满 1.05M 因升档约 ¥1.26；DeepSeek V4 Flash 用满 1M 峰时 ¥3、空闲 ¥1.5，缓存命中另为峰时 ¥0.10/M、空闲 ¥0.05/M。长上下文要按完整请求的档位和时段比较，不能只看首档。
文中价格与价格表同源、每日核对。选型前去看一眼最新价。
打开价格表 →