1M 长上下文的价格真相：用满一次到底花多少钱

公式只有一行：满上下文一次请求的输入费 = 输入单价（¥/百万 token）× 上下文长度（百万 token）。下表是目前价格库里上下文 ≥ 1M 的全部模型，按用满一次的输入费从高到低排。

同样标着『1M 级长上下文』，用满一次的钱差出近 50 倍（33.93 ÷ 0.68 ≈ 49.9）。另一个反直觉的点：Gemini 3.1 Pro Preview 单价 ¥13.57/M 不到 Opus 4.8 的一半，但因为窗口是 2M，真用满反而要 ¥27.14，绝对金额直逼 Opus。看单价不够，得看『单价 × 你实际会塞多少』。

还没完——输出另算。Opus 4.8 输出价 ¥169.63/百万 token，如果顶满 64K 输出，再加 169.63 × 64,000/1,000,000 ≈ ¥10.86。一次满窗口请求合计约 ¥44.8。

LLM API 是无状态的——服务端不记得上一轮聊了什么，每一轮都要把系统提示加全部历史原样重发，重发的部分按输入价全额计费。这意味着长对话的成本不是线性涨，而是近似平方级涨：历史越长，每一轮的『底座』越厚。

算个典型的 agent 会话：起始上下文 50K token（系统提示 + 检索进来的代码文件），每轮新增约 10K（工具输出 + 模型回复）。第 1 轮输入 50K，第 10 轮输入 50K + 9 × 10K = 140K——你这轮可能只追问了 20 个字，计费的是 140K。10 轮累计输入 = 50K × 10 + 10K × (1+2+…+9) = 950K token。用 Opus 4.8 跑：33.93 × 950,000/1,000,000 ≈ ¥32.23。注意，整个会话从没用满过 1M，但累计输入费已经几乎等于用满一次的钱。换 Claude Sonnet 4.6 是 20.36 × 0.95 ≈ ¥19.34，换 DeepSeek V4 Pro 是 3 × 0.95 = ¥2.85。

工程上的对策都不新鲜，但确实管用：

场景：一套 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 问的重复场景，差的是数量级，工程投入很快回本。

Prompt 缓存的原理：请求里重复出现的前缀（比如那本 30 万 token 的文档）在厂商侧缓存，后续请求命中时按便宜得多的缓存价计费。Opus 4.8 的缓存命中价是 ¥3.39/百万 token，约为输入原价的十分之一。

套回上面的整本塞场景：假设文档全部命中缓存，每问输入费 3.39 × 0.3 ≈ ¥1.02，一天 20 问约 ¥20.34——比不缓存的 ¥203.58 省了九成，确实可观。但对比 RAG 方案的 ¥3.39/天，仍是它的 6 倍。缓存把斜率压低了，没有改变『费用随上下文长度线性增长』这件事。便宜模型是另一回事：DeepSeek V4 Flash 缓存命中价 ¥0.02/M，每问只要 0.02 × 0.3 = ¥0.006，整本塞的痛感基本消失。

几个常见的翻车点：缓存命中要求前缀逐字节一致，文档前面改一个字、或者把动态内容（时间戳、用户名）放在了文档前头，就全员 miss；缓存有有效期，低频访问可能反复过期重建；首次写入通常另有计费。各家规则差异不小，以官方文档为准。另外缓存只救重复前缀，救不了多轮对话里每轮新增的历史，更救不了输出费。

骂完该说公道话：有些任务的价值恰恰在『全部内容同时在场』，切片会直接毁掉任务本身。

判断标准其实就一条：任务需要的是全局关联还是局部检索？前者值得整本塞，后者用 RAG。值得的典型场景：

真决定用满长上下文，顺序建议是：先拿便宜档验证流程——DeepSeek V4 Flash 用满一次 ¥1、Gemini 2.5 Flash-Lite ¥0.68、MiniMax M2.7 ¥2.10，把切分逻辑、提示词、输出格式都调顺；确认任务确实需要旗舰的推理质量，再换 Opus 4.8（¥33.93/次）或 Gemini 3.1 Pro Preview（用满 2M ¥27.14），这时多花的钱才花在刀刃上。

最后一个提醒：标称 1M 不等于全程稳定可用。长上下文末端的检索和推理精度普遍会衰减（业内常说的 lost in the middle），关键信息别埋在中段，各家衰减程度差异也大——窗口大小是营销数字，有效窗口得自己测。完整的长上下文模型横向对比可以看 /compare/long-context-llm，具体用量套自己的参数算一遍，比任何文章的结论都可靠。