长上下文分级计价：最高 6.7 倍，网关页面却不展示

一旦 prompt 变长，网关模型页面上的价格就不再等于账单上的价格。我们通过一家大型多供应商聚合网关，对 9 个采用分级计价的模型逐一测试了所有公开长度阈值的两侧。越过第一档阈值后，其中 5 个模型严格按页面价格的 2 倍计费；Alibaba 的 3 个模型在最高档分别涨到 3 倍、3 倍和 6.7 倍；另有一个由 Azure 提供服务的模型，在阈值两侧都按页面所列 endpoint 费率的 1.25 倍计费，越线后再翻倍。这些信息在页面上完全没有展示。Google、OpenAI、xAI、Alibaba、ByteDance 和 MiniMax 都在官方文档中说明了计费机制：输入 token 一旦超过 32K、128K、200k、256K、272K 或 512k 的阈值，整次请求都会改按更高费率计价，包括输出。本文先展示账单，再梳理背后的分档价格表，最后说明如何通过配置让请求保持在阈值以内。

TL;DR

• 通过一家页面只展示单一价格的聚合网关测试后，9 个分级计价模型越过供应商阈值时，实际费用是页面价格的 1.8 倍至 6.7 倍；通过 Azure 提供服务的 GPT-5.6 Luna 则按标价的 1.25 倍计费。
• qwen3.7-flash 在 32K 和 256K 两个阈值处，输入价格从每百万 token $0.03 涨到 $0.10，再涨到 $0.20；qwen3-coder-plus 到 3 倍后不再上涨，而供应商列出的最高档为 6 倍。
• 输入一旦越过 32K 到 512k token 之间的某个阈值，供应商会对整次请求重新计价，包括输出。
• 要限制的是输入，不是输出：Claude Code /autocompact、Codex model_context_window、API 压缩触发器。

网关会按页面标价收费吗？

prompt 变长后不会。要查清每家中间商实际收了多少，需要两类数据：网关公开的价格元数据，以及请求在阈值两侧时实际报告的费用。

一家大型多供应商聚合网关通过 pricing.overrides 数组发布目录价格：基础价格之外，还会附带条件规则，例如 min_prompt_tokens: 200000 以及对应的更高费率。DeepSeek 和 Tencent 模型还带有用于低峰时段计价的 utc_start / utc_end 时间窗口。我们在 2026-09-01 拉取的目录中，有 60 个条目包含 override，其中包括 Gemini Pro 系列、Grok 4.x、qwen3.7-plus、qwen3.7-flash、qwen3-coder-plus、Seed 2.0 系列，以及在 272,000 token 处切换价格的整个 GPT-5.6 系列。模型页面只显示基础价格，分档规则只存在于元数据中。而且元数据也不一定完整反映供应商的阶梯价格：qwen3-coder-plus 在 32,000 和 128,000 处有规则，但供应商的第 4 档阈值 256K 并未出现。

因此，我们通过该聚合网关，在每个公开阈值的两侧分别发送请求，并启用 usage accounting。聚合网关会在响应中返回实际收取的金额，同时记录提供服务的 endpoint。聚合网关上的一个模型 id 可能对应多个上游服务商，每个服务商价格不同，聚合网关将它们称为 endpoint。测试分别在 2026-09-02 和 2026-09-03 进行，每个点运行两次：

这些页面与账单在同一天截取。页面只有一个主价格和一张 endpoint 价格表，都没有长度分档。上述每一笔收费都与元数据分毫不差。9 个模型在供应商的第一条阈值处，都按供应商规定的倍数跳档。3 个 Alibaba 模型的账单还沿着页面从未提到的阶梯继续上涨：qwen3.7-flash 在 32K 处从 $0.03 涨到 $0.10，在 256K 处再涨到 $0.20，达到页面价格的 6.7 倍，而页面仍只显示 $0.03。GPT-5.6 Luna 也会在阈值处跳档，并且还有第二层价差：所有由 Azure 提供服务的请求，无论阈值上下，实际费用都是所列 Azure endpoint 价格的 1.25 倍（$0.275 对 $0.22，$0.50 和 $0.55 对 $0.40 和 $0.44）。这笔附加费用既没有出现在页面上，也没有出现在 endpoint 元数据中。

聚合网关的阶梯也可能比供应商的少一档。qwen3-coder-plus 的价格在 32K 处涨到 1.8 倍，在 128K 处涨到 3 倍，之后直到 276k token 都保持在每百万 $1.95。Alibaba 官方价格在 256K 后则会将输入提高到 $6，输出提高到 $60，分别是基础价格的 6 倍和 12 倍。聚合网关的元数据在 256K 处没有规则，因此实际收费也没有变化。聚合网关是自行承担了差价，还是采用了不同的采购合同，从外部无法判断。可以确认的是，账单遵循元数据，而元数据和页面并不是同一份价格说明。

因此，透明度问题不在元数据和账单之间，而在页面与这两者之间。页面顶部的价格是下方表格中最便宜 endpoint 的费率，不一定是实际为请求提供服务的 endpoint 费率。无论顶部价格还是 endpoint 价格，都没有附带长度条件。只看一张标有单一价格的模型卡，无法知道是否存在分档、下一次请求会由哪个 endpoint 提供服务，也无法确认当前账号是否能够使用正在查看价格的那个 endpoint。

处理方式很直接。读取实际使用模型在 endpoint 级别的机器可读价格，并检查是否有长度条件；然后启用 usage accounting，在阈值两侧各发送一次请求，对比报告费用。如果网关在页面没有说明的阈值处涨价，说明它直接传递了供应商规则，却没有在页面告知。如果供应商会涨价而网关保持不变，那么要么它使用了价格不同的上游服务商，要么它自行承担差价。只有前一种情况可能长期稳定。

阈值在哪里，分档价格如何生效？

有 6 家供应商公开了长度阈值。凡是明确说明规则的模型，都会在越线后对请求中的所有 token 使用更高费率，包括输出。大多数模型在第一条阈值处涨到 2 倍，但多档阶梯会继续上涨：qwen3.7-plus 唯一一条阈值直接涨到 3 倍；qwen3.7-flash 到第 3 档时，输入价格达到 6.7 倍；qwen3-coder-plus 到第 4 档时，输入为 6 倍，输出为 12 倍。以下价格均按每百万 token 计，数据取自供应商在 2026-09-01 的价格页面。

实现计费代码时，需要特别处理两个边界细节。Google 的两个页面对边界相差 1 个 token：Vertex 脚注写的是“大于或等于 200K”，Gemini API 价格表写的是“prompt > 200k token”。Alibaba 则明确规定了 K 的含义：128K 等于 128,000 token，256K 等于 256,000 token，不是 2 的幂。

档位仅由输入长度决定，但一旦选定，会应用于整次请求的所有 token，包括输出。因此，越过阈值的那个 token 所带来的边际成本，等于之前全部 token 的额外差价。以 Gemini 2.5 Pro 为例：199,999-token 的 prompt，输入费用为 $0.25；达到 200,001 token 后，输入费用变成 $0.50，4,000-token 的回答也会从 $0.04 涨到 $0.06。只多 1 个 token，总费用却增加 $0.27。

qwen3.7-plus 的跳档幅度是 3 倍：按官方费率，255,029-token 的 prompt 费用为 $0.102，257,332-token 的 prompt 则为 $0.309。qwen3-coder-plus 使用同一机制，但叠加为 4 个档位，因此 260k-token prompt 的每 token 费率是 30k-token prompt 的 6 倍，输出费率则是 12 倍。

这条规则不仅写在供应商价格表中，也能从真实账单中看出来。qwen3.5-plus 的官方输入价格在 256K 处分为每百万 $0.40 和 $0.50。我们通过网关分别进行了 10 次阈值以下测试（243k token）和 24 次阈值以上测试（256k 至 321k token），每个输入 token 的账单价格恰好相差 1.25 倍，而输出价格不变。259k 请求不是只对最后 3k token 按 1.25 倍收费，而是全部 token 都按 1.25 倍收费。

对于持续累积历史记录的 agent，越线会在会话中途静默发生。触发越线的那一轮，会为携带的所有历史轮次支付溢价。之后的每一轮都会继续支付，直到上下文被压缩。

模型能力会在同一阈值处突变吗？

不会。我们专门做了测试，因为价格分档很容易被误解为能力边界，但两者并不是一回事。我们选择了两个在 256K 处分档的 Qwen 模型，在 5 个深度位置埋入带有每次运行随机代码的单行事实，也就是 salted needle。关闭 thinking 后，在 243k、269k 和 320k token 三种长度下，每个模型都实现了 30 次中 30 次正确召回。延迟随长度近似线性增长，而不是在阈值处跳变，qwen3.7-plus 的中位延迟分别为 15.2 s、17.0 s 和 20.5 s。更难的任务是统计整份日志中植入的 K 个罕见事件，结果确实会随长度下降：qwen3.7-plus 的发现比例从 128k 时的 74%，降到 192k 时的 60%、243k 时的 58%，以及 320k 时的 45%。这种下降在价格阈值前很早就已开始，阈值两侧的数据点仍位于同一条下降趋势线上。

Anthropic 的官方文档给这种渐进效应起了名字：随着 token 数量增加，准确率和召回率会下降，“这种现象称为 context rot（上下文腐化）”。这种效应确实存在，而且是连续变化的，与价格阈值无关。

如何让请求保持在阈值以内？

限制输入，不要限制输出。分档依据是请求的输入长度，因此 max_tokens 这个输出上限对此没有作用。真正有效的是限制客户端发送内容的配置。这些配置分布在 4 个层面。

下表按层级列出可以限制 prompt 的配置。“可控制档位”表示该配置接受绝对 token 数，因此可以设置在价格阈值略下方。按 context window 比例生效的配置只能保证不超过模型的上下文窗口，而上下文窗口和价格阈值不是同一个数字。

这张表说明了两点。第一，编码 agent 使用分级计价模型时，compaction window 是把价格断崖变成摘要的关键配置。它必须使用绝对 token 数，并设置在阈值略下方，不能简单按 1M context window 的比例设置。第二，最常见的两个“安全”配置，Responses 的 truncation: "auto" 和聚合网关的 middle-out，保护的是模型窗口。对于采用分档价格的 Gemini 和 GPT-5.6，模型窗口是 1M，而价格会在 200,000 或 272,000 token 处变化。因此，它们可以防止请求失败，却无法阻止请求越过价格阈值。

不要指望缓存帮你留在阈值以内。 Prompt caching 可以降低账单，但不会改变 Google 模型的分档判断，因为缓存读取也按相同的长度档位计价：150k 的缓存前缀加 60k 的新上下文，仍然是 210k prompt，并会作为整体计费。预配置容量则完全绕开这个问题，因为预配置吞吐量单元（PTU）按小时收费，与 token 数量无关。如果越线确实值得，就应主动越线。前面的测试表明，模型不会在阈值处突然变差，因此决策只取决于新增上下文是否值得让整次请求承担 2 倍、3 倍，或最高档 6.7 倍的价格。

Synthorai 如何处理

长度分档本质上是一个费率条件，因此网关也按费率条件处理。模型的价格卡可以包含一组按输入 token 边界索引的档位。每个请求根据自身 prompt 长度选择档位，再按供应商相同的规则，对请求中的所有 token 计价。前面的 qwen3.5-plus 账单正是通过这套机制计算的。usage 记录会将 prompt token 数和价格版本与计费金额一起保存，因此可以把账单还原为“该请求越过了阈值”。请求实际采用的计价档位可以从 usage 记录里查到，而不只存在于价格表里。

常见问题

长上下文的更高费率是否只对超过阈值的 token 收取？

不是。所有公开说明规则的供应商都会对整次请求重新计价：Google 写的是“所有 token（输入和输出）都按长上下文费率收费”，OpenAI 写的是“整次请求”，xAI 写的是“请求中的所有 token”，Alibaba 写的是“请求中的所有 token 均按对应档位的单价计费”。prompt 即使只比阈值多 1 个 token，之前的每个 token 也都要支付溢价。

API 网关会传递长上下文分档价格吗？

会，至少我们的测试结果如此。通过一家大型聚合网关测试时，9 个采用分档价格的模型在越过供应商阈值后，都按供应商的更高费率收费，而模型页面只显示单一价格。分档规则存在于网关的价格元数据中，不在页面上。元数据也可能漏掉供应商的某个档位，例如 qwen3-coder-plus 在 256K 以上的档位就没有被包含。

max_tokens 能让请求保持在价格阈值以内吗？

不能。max_tokens 限制的是输出，而档位由输入长度决定。有效的配置是限制 prompt 的配置，例如 agent 中的压缩窗口或 token 上限（Claude Code /autocompact、Codex model_context_window）、API 的压缩触发器，或发送请求前在客户端截断上下文。

模型质量会在价格阈值处下降吗？

我们的测试中没有。对两个采用分档价格的 Qwen 模型测试时，needle recall 在 256K 阈值两侧都是满分。计数任务的表现则随长度逐渐下降，在边界处没有跳变。分档价格是商业规则；上下文越长，能力下降确实存在，但变化是连续的。

价格和计费语义取自 2026-09-01 抓取的供应商价格页面；agent 和 API 配置取自 2026-09-02 的链接文档；账单测试在 2026-09-01 至 2026-09-03 期间完成，关闭 thinking，使用 salted prompt，每个聚合网关测试点运行两次。价格会变化，在将阈值写入计费代码前，请检查链接中的最新来源。

相关阅读：计费单位实用指南（本文深入讨论的修正因子层）、token 用量结构、Prompt caching 详解、缓存最低门槛实测。

← 返回博客