你比价的那张表，只决定了账单的一部分
选 API 的时候，绝大多数人的动作是打开一张价目表，比较「每百万 token 多少钱」，然后挑便宜的那个。
这个动作在 2024 年基本成立。到 2026 年，它已经不够用了。
原因是：价目表上的单价，只是账单里的一个乘数。真正决定你月末付多少的，还有另外四个乘数，它们全都不写在价目表上。
这四个乘数分别是：长上下文分档、思考 token、分词器换算法、以及「窗口 / 输入上限 / 输出上限」这三个数被混为一谈。
同一个模型、同一份价目表、同一个请求，在这四个乘数叠加之后，账单能差出 2 倍、10 倍，极端情况下 134 倍。
下面逐个拆开，每一个都给出可核实的出处和可执行的自查动作。
乘数一：长上下文分档——超过阈值后，是整个请求变贵
这是四个乘数里最反直觉的一个。
多数人的默认假设是：如果超过某个长度要加价，那应该是超出阈值的那部分按高价算，阈值以内的还按原价。
实际规则恰好相反：一旦跨过阈值，整个请求的所有 token 都按更高的单价计费，不是只对超出部分。
2026 年 8 月 30 日的各家公开费率梳理显示，长上下文分档的阈值和倍数如下：
| 厂商 / 模型 | 触发阈值 | 加价倍数 | 说明 | |---|---|---|---| | OpenAI GPT-5.6 家族、GPT-6 Astra | 输入超过 272,000 token | 输入 2×、缓存 2×、输出 1.5× | 对整个请求生效 | | Google Gemini 3.1 Pro Preview、2.5 Pro | 输入 ≥ 200K token | 输入 2× | Flash / Flash-Lite 全系到 1,048,576 平坦 1×，无悬崖 | | xAI Grok 全系 | 达到 200K token | 2× | — | | Anthropic Claude 4.6 及以后 | 无阈值 | 1× | 完整 1M 窗口按标准价 | | MiniMax-M3 | 输入超过 512K | 2× | — | | 阿里 qwen3.7-flash / qwen3.7-plus | 按请求总量分 32K / 256K 档 | 逐档递增 | 分档方式与其他家不同 |
国内同样存在这类阶梯：火山引擎方舟的 Seed-2.0-Lite 就是阶梯计价——上下文 ≤32K 是一个价，超过 32K 单价上浮，窗口为 256K。
关键点在于：这个差异在价目表首页看不到。 你看到的「输入 $2 / 百万 token」是低于阈值时的价格。等你把整个代码库塞进上下文做重构，单价悄悄翻了一倍，而你的成本模型还在按原单价算。
一个不该被忽略的细节：能力上限，精确落在计费分界线上
2026 年 8 月 28 日，开发者在 GitHub 上针对 CLI v0.144.3 提交 issue：多文件重构任务开始失败，排查后发现有效上下文窗口从约 353,000 token 降到了约 258,000 token，缩水 27%。
三个细节值得注意：
- 新的上限是 272,000 token——这个数字精确对齐 OpenAI 自己的长上下文加价阈值。
- 没有邮件通知，没有变更日志，用户是靠会话被截断才发现的。
- 官方对此的表述是：营销页上的数字描述的是底层模型的天花板，不一定是某个产品实际提供给用户的量。
我们不评价厂商的商业决策。把这则信息放在这里，是为了说明一件事：当一家厂商同时控制「你的能力上限」和「你的计费分界线」时，这两条线是有可能对齐的。
给开发者的可执行结论很简单：不要把任何上下文长度硬编码进你的工作流，每次会话开始时先向服务端确认它当前实际提供多少。
乘数二：思考 token——你没看见，但你在付钱
第二个乘数藏在输出里。
当你开启扩展思考、或者使用推理类模型的高强度模式时，模型在给出答案之前会先生成一段内部的推理过程。这段推理 token 按输出 token 计费，无论你是否看得到它。
一个被广泛引用的算例：
- 你的问题：15 token
- 模型的内部思考：2,000 token（计费）
- 你拿到的答案：15 token
- 实际按输出计费：2,015 token，而不是 15
按 Claude Opus 5 每百万输出 25 美元计算：不开思考是 0.000375 美元，开了思考是 0.050375 美元——同一个问题，134 倍。
行业口径是：o 系列与扩展思考模式都按输出费率对内部推理计费，在推理密集型任务上，实际成本是基础价的 3 到 10 倍。
对国内用户更直接的一点：DeepSeek V4 系列提供 thinking 与 non-thinking 双模式，官方接口文档中对「最大输出」与「最大思维链输出长度」是分开标注的——这意味着思考 token 的消耗是可以被单独观察的，前提是你去看。
可执行动作：在日志里把 reasoning_tokens（或各家对应字段）与 completion_tokens 分开打点。如果你从不看这个数，你就是在为一段自己没读过的文字付钱，而且不知道付了多少。
乘数三：分词器换算法——同样的文本，token 多了 30%
第三个乘数最隐蔽，因为它不改变任何价格，只改变「一个 token 代表多少字」。
Anthropic 自己说明过：Claude 4.7 及以后的模型使用了新的分词器，对同样的文本会多产出大约 30% 的 token。 Sonnet 5、Opus 5、Fable 5 都用的是这个新分词器。
后果是什么？
跨厂商按「每 token 单价」比价，会系统性低估使用新分词器一方的实际成本。 你拿同一段中文文本分别打给两家，A 家数出 1,000 token，B 家数出 1,300 token；即便两家单价完全相同，B 家的实际账单也贵 30%。而这个 30% 不会出现在任何一张价目表上。
可执行动作：跨厂商比价时，不要用「单价 × 你猜的 token 数」，要用「同一批真实业务文本，各自实际切出来的 token 数 × 各自的单价」。差距往往在你做这一步时才第一次显形。
乘数四：窗口、输入上限、输出上限是三个不同的数
第四个乘数不是加价，是买到的东西比标价少。
行业里「100 万上下文」这个说法，在不同厂商那里指的是不同的量：
| 厂商 | 宣传口径 | 实际构成 | |---|---|---| | OpenAI | 1,050,000 | 922,000 输入 + 128,000 输出（窗口包含输出） | | Google | 1,048,576 | 输入上限，输出另加 65,536 | | Anthropic Claude Fable 5.1 / Opus 5 / Sonnet 5 | 1,000,000 | 上下文 1M，同步请求最大输出 128,000（Batch API 开 beta 头可到 300,000） | | DeepSeek V4 Pro / V4 Flash | 1,000,000 | 最大输出 384,000 |
两家头部厂商的「1M」根本不是同一个量，不能直接比较。 OpenAI 的窗口把输出算在内，Google 的窗口是纯输入。差出来的那 12.8 万 token，在你做长上下文规划时是真金白银。
另外，输出上限的差距比窗口大得多：Gemini 系列是 65,536，Claude 是 128,000，DeepSeek V4 是 384,000。如果你的场景是长文生成或大段代码输出，输出上限往往比窗口更早撞墙。
可执行动作：把「上下文窗口」「输入上限」「输出上限」三个数分开记录在你的选型表里，不要只抄宣传页那一个数。
4 步自查：把四个乘数变成你管得住的东西
四个乘数讲完，落到可执行层面是四步：
第 1 步：量出你的真实输入长度分布。 打点统计一次请求的输入 token 数的 P50 / P95 / P99。如果你的 P95 已经跨过所用模型的分档阈值，你就在为「整个请求」付高价，而不是为超出的部分。
第 2 步：把思考 token 单独打点。 如果一个开关能让你在推理密集任务上省下 3 到 10 倍，你至少应该知道它现在开着还是关着、花了多少。
第 3 步：跨厂商比价改成「实测 token 数 × 单价」。 拿一批真实业务文本，分别问各家切出多少 token，再做乘法。这一步能同时暴露分词器差异和分档加价两个乘数。
第 4 步：把三个上限分开记。 窗口、输入上限、输出上限各记一列，撞墙时才知道撞的是哪一堵。
顺带一个提醒：缓存是最容易静默失效的一项。多数厂商的缓存命中价是输入价的 10%，但只要你重排了 prompt、让稳定前缀发生变化，所有缓存 token 就会悄悄回到 10 倍价格，并且没有任何通知。缓存的收益需要靠埋点观察，不能靠假设。
我们这边能给你什么，给不了什么
说完行业，说本站。按惯例，能给和给不了分开写，不夸大。
能给的四件事：
- 统一倍率，不设长上下文附加档。 本站对在架的 DeepSeek-V4-Flash（火山引擎方舟官方授权通道）按固定倍率计价，不随输入长度分档——你的请求是 3 万 token 还是 30 万 token，倍率是一样的。
- 不随调用时段浮动。 上游方舟与 DeepSeek 官方自 2026 年 8 月起实行峰谷分时（高峰为 9:00–12:00 与 14:00–18:00，高峰价为闲时的 2 倍），这部分差价由我们承担，不转嫁到你的账单上。这条在此前已作为长期承诺公示，此处再次确认。上游若调整分时段结算，我们会提前公告，不做静默变更。
- 上游怎么算，我们就怎么算，不额外加价。 思考 token 是否计费、按什么口径计费，是上游模型的规则。我们原样透传，不在上游口径之上再加一层，也不做「看起来便宜、实际按别的方式补回来」的处理。
- 逐笔调用明细可导出。 上面四个乘数，你都可以拿自己的明细去核。这是我们唯一主张的验证方式——别信我们的说法，导出你自己的数据看。
给不了的三件事：
- 不替你吸收上游的计费口径。 如果上游把思考 token 计为输出，那它就会按输出出现在你的账单里。我们不会因为「你没看见」就免掉这部分——那是上游的规则，中转站改不了，改了就是在骗你。
- 不替你裁剪上下文、不替你关闭思考模式。 这些是你应用层的决策。我们能做的是把明细给你，让你判断该不该裁，不是替你裁完再告诉你省了多少。
- 当前方舟通道只激活了 1 个模型。 这是本站的真实短板，不掩饰。如果你的业务需要模型广度，现阶段我们不是最合适的选择。
最后一句：这四个乘数里，没有一个会出现在营销页上。 但每一个都会出现在你的账单上。区别只在于，你是月末看到数字才发现，还是现在就把它纳入成本模型。
