GPT-6.1 Sol 上下文窗口：1,050,000 个 Token、922,000 线，以及 272,000 断崖

供应商为GPT-6.1 Sol提供的模型页面（查阅于 2026 年 10 月 7 日）声称其上下文窗口为 1,050,000 个 token，最大输出为 128,000 个 token。同一个页面在其 URL 后追加.md所得到的机器可读形式中，还带有渲染页面从不打印的第三个数字：最大输入 token 数为 922,000。GPT-6 Sol——即 6.1 于 2026-09-29 发布时所接替的模型——在自己的页面上公布了完全相同的一对上限数字，并在其自身的 markdown 形式中写有同样的 922,000 这一行。我们自己的openai/gpt-6-sol模型卡将窗口记为 1,050,000 个 token，输出上限记为 128,000，并在其规格栏中将前者显示为“1M”，而在同一页面下方的对比表格中，同一个模型却印作“1.1M”。

所以这些页面确实不一致，而且值得精确说明它们如何不一致。厂商渲染出的规格条给出了窗口和输出上限，却没有给出输入上限。厂商针对同一模型的 Markdown 文档则把这三项都给出了。任何依据渲染页面来估算请求规模的人，所依据的约束都比厂商公布的少一个，而缺失的那一个，正是决定请求能否容纳的数字。

三个数字，三个来源，还有一次无人记载的减法。

以下是每个编号及其来源文件，均读取于2026年10月7日。

• 1,050,000 上下文窗口——gpt-6.1-sol 的供应商模型页面，在渲染后的规格条及其 Markdown 形式中都是如此，gpt-6-sol 的页面上也是同一数字。我们的目录为 openai/gpt-6-sol 和 openai/gpt-6-luna 返回的也是这个值，其中该字段被记录为 1,050,000，而不是四舍五入后的值。

• 128,000 最大输出 token 数——同一个页面、同样两种形式，两代皆然。我们卡片上的字段显示为 128,000；界面显示则舍入为"128K"。

• 922,000 最大输入 Token —— 这是供应商 gpt-6-sol 模型页面及其 gpt-6.1-sol 页面的 markdown 形式。它既不在任一页面渲染出的条带中，也不在我们为该模型设置的目录字段里，该字段只到上下文窗口和输出上限为止。

这三个数字在算术上彼此一致：922,000 加 128,000 正好等于 1,050,000。供应商自己的推理指南描述了使这一等式有意义的机制，却从未在模型页面上把总和算出来——它说，推理 token “仍然占用模型的上下文窗口空间”，而如果生成的 token “达到上下文窗口限制或你设置的 max_output_tokens 值”，响应返回时就会被标记为不完整。一个由输入和输出共享的窗口，就是这样一个窗口：其输入上限等于窗口减去输出预留量。

这种解读得到了佐证，而非被证实，值得把两者区分开来。有据可查的是 1,050,000 的窗口、128,000 的输出上限，以及 922,000 的最大输入。属于推断的则是：其中哪一项才是最先触发的限制。这一推断对所有预留了全部输出额度的请求成立，而对任何没有这样做的请求都不成立——把 max_output_tokens 设为 4,000，1,046,000 个输入 token 并不会明显被拒绝。在厂商把这项减法写进这些数字所载的那个页面之前，就把这一配对视为预算的形态，而不是硬性的准入规则，并且要依据计数接口来验证，而不是依据一篇博客文章。

上下文不是代价：迈向 272,000 token 的一步

更大的窗口是一种容量声明。它不是成本声明，而在这个系列上，两者在一条有据可查的分界线上分道扬镳。供应商的定价页面用一句话说明了规则：输入 token 超过 272K 的提示，整个请求按输入与缓存费率的 2 倍、输出费率的 1.5 倍计价。同一页面对其两列的定义是：“短上下文：≤272K 输入 token。长上下文：>272K 输入 token。”

阅读单词 full 时要仔细。这个档位不会对越过界线的 token 额外收费——它会对一切重新定价，包括第一个 token。而且这并不是 6.1 的改动：同样的规则、同样的阈值也适用于 GPT-6 Sol，这正是为什么这个断崖必须归因于档位，而不是这次发布。

按照 GPT-6.1 Sol 公布的价格费率，让同一个长上下文作业在两边各跑一遍，并让前缀已经驻留在缓存中，这样缓存写入费用就不会干扰对比：

• 240,000 个输入 token（200,000 个缓存，40,000 个新增），6,000 个输出 — 新增输入 40,000 个，按每百万 $2.00 计为 $0.080；缓存输入 200,000 个，按 $0.10 计为 $0.020；输出 6,000 个，按 $10.00 计为 $0.060。总计 $0.160。

• 300,000 输入 token（260,000 缓存，40,000 新增），6,000 输出——该请求现已越过临界线，因此所有费率都会变化：新增输入 40,000 按 $4.00 计算为 $0.160；缓存输入 260,000 按 $0.20 计算为 $0.052；输出 6,000 按 $15.00 计算为 $0.090。总计 $0.302。

输入 token 多出 25%，账单却大了 89%。把同一组对比放到 GPT-6 Sol 上跑，这个形态依然成立，只是斜率更陡——线下是 $0.180，线上是 $0.354，因为旧款价目表 $0.20 的缓存费率，所处的位置与 6.1 的长上下文缓存费率相同。这个临界点是一个台阶，而不是一道斜坡，而验证这一点最省钱的办法，就是只超出它一丝一毫。一个完全未命中缓存的 271,000 token 请求，配 1,000 个输出 token，费用为 $0.552；到了 273,000 token，费用就是 $1.107。输入 token 只多了 0.7%，花的钱却是 2.01 倍。把那个请求削掉 2,000 token，账单就从 $1.107 降到 $0.552——不到输入量的百分之一，成本却减半。

本节的内容并不是说 GPT-6.1 Sol 的窗口很大，而是说这个窗口大到足以触及一个边界，而触及该边界的代价超过了窗口大小本身所能换来的东西。

究竟是什么占满了 1,050,000 个 token？

上下文预算由六部分构成，而且它们的可缓存性并不相同。以下是一个示例性的 240,000 token 智能体请求中各部分的大致占比；这些比例出自我们自己的测算，而可缓存性规则则来自供应商当天查阅的提示缓存指南。

• 由提供商注入的系统内容与请求格式——在你的消息之前渲染，按输入计费，并被明确排除在最小可缓存长度之外。它不归你控制，也不归你删减。

• 你的开发者和系统指令，约 6,000 个 token。可缓存。这是前缀的开头部分，因此此处的改动会导致其后的所有内容失效。

• 工具定义与模式，托管工具界面大约需要 14,000 个 token，再加上你的函数。这部分可缓存，却是前缀中最脆弱的部分：指南将工具定义、描述、模式、排序以及针对特定工具的指令列为会移动前缀边界的内容。

• 检索到的语料库，约 180,000 个 token。可缓存，且是其中最大的一项。只有当它在多次调用之间字节级稳定时，才值得缓存——每次请求都重新组装的语料库，就是一个全价语料库。

• 累积的对话记录——包括先前的轮次和工具结果——约 30,000 个 token，且仍在增长。可一直缓存到最新的变更之前；本轮到达的工具结果是按全费率计费的全新输入。

• 推理令牌 —— 生成产生，从不缓存，按输出计费。它们会占用上下文窗口，并且在响应体中不可见。

从那份列表中可以直接得出两条运维方面的说明。首先，缓存条目存放在单台机器上：指南称，请求可以复用某个前缀，“仅当它到达一台持有尚未过期的匹配条目的机器时”，并且溢出路由大约在每分钟超过 15 个请求时开始。一个在你的代码中保持稳定的前缀，在生产环境中仍可能未命中。其次，最小可缓存前缀为 1,024 个可见输入 token，隐藏的系统 token 不计入其中——因此，无论其周围的请求有多大，一个很小的系统提示词都不是可缓存前缀。

输出上限是一项独立的预算，而不是额外加的一份。

128,000 的最大输出 token 数并不意味着能得到 128,000 个 token 的答案。推理指南明确指出，max_output_tokens 限制的是模型生成的总量，“包括推理 token、可见输出 token 以及不可见的格式 token”，并且推理 token 按输出计费，同时还会占用上下文窗口的空间。

这使得截断成为一项设计决策，而非边缘情况，因为它的失败方式就是如此。当生成达到上限时，响应会返回状态 incomplete 和原因 max_output_tokens——指南警告说，这可能“在任何可见的输出 token 产生之前发生，这意味着你可能在没有收到可见响应的情况下，仍需为输入和推理 token 付费”。一个把整个窗口都花在输入上、而把输出预留交给运气的预算，就是一种可能为完整的长上下文请求计费、却返回调用方无法解析的内容的预算。供应商自身的初始建议是，在你仍在衡量一个提示实际需要多少时，至少预留 25,000 个 token 用于推理和输出。

GPT-6.1 Sol 将这一点锐化，而这是该版本中少数真正为 6.1 独有的表述之一。其推理力度阶梯依次为 low、medium、high、xhigh 和 max，且不支持 none 和 minimal 设置。GPT-6 Sol 接受全部六种。因此，在 6.1 上没有任何设置能关闭推理开销，默认值为 medium，而预算的输出侧永远不会是免费的。

缓存输入减半，在窗口最宽处读取

GPT-6.1 卡片上唯一相对 GPT-6 Sol 发生变动的费率是缓存输入：从每百万 token 0.20 美元降至 0.10 美元；模型页面将其表述为未缓存输入费率的 5%，而厂商的缓存指南将其列为 0.05 倍这一档，相比之下，大多数 GPT-5.6 及更高版本的模型按 0.1 倍计。输入、缓存写入和输出在两张卡片上完全相同，长上下文倍率也完全相同。

对于本页所讨论的正是这种工作负载而言，该调整的正是这个计量项，原因在于长请求的构成方式，而不在于其规模。在上面那个 300,000 个 token 的任务中，输入 token 里有 260,000 个是缓存前缀——占该请求所发送全部内容的 87%。因此，缓存这一项是账单中最大的单项输入计量项，而这正是长上下文工作的普遍特性：你使用的窗口越长，其中已经发送过的前缀就越多。将该计量项减半，在这个请求上价值 0.052 美元。

而悬崖收回的，比减半给出的更多，就在同一个请求上。若按短上下文费率计价，它本应在线下支付，而同样的 30 万 token 任务在 GPT-6.1 Sol 上会花费 $0.166，而不是 $0.302——跨越成本为 $0.136，约等于这次发布中唯一改动的计费项所值的 2.6 倍。线上缓存费率显示为 $0.20，这在这个系列上并非新数字：它是 6.1 价目卡上标价的两倍，也恰好是本次发布前 GPT-6 Sol 对线下缓存读取所收取的价格。长上下文缓存工作负载收到了标价变动，随后又在边界处把它交还回去，而边界——不是模型——才是原因。

如何确定上下文预算的规模

作为一项流程，按各约束生效的顺序：

• 统计请求，不要估算它。将精确负载——包括工具、图像、文件等所有内容——POST 到 Responses API 上的输入 token 计数端点。指南直言不讳地说明了原因：计数包含消息角色和边界的格式 token，而这些 token 永远不会出现在你可以在本地进行分词的文本中，而且像“字符数除以四”这样的本地估算对图像、文件和 schema 并不准确。

• 先预留输出侧。选择 max_output_tokens 时，要记住它同时涵盖推理、可见输出和格式化，并且要从厂商的 25,000 token 缓冲开始，而不是从零开始。你的输入预算是窗口减去这部分预留，而九百二十二这个数字就是厂商对同一减法的版本。

• 在发送之前，先按272,000上下两侧给这个请求定价。 这个跨度足够大，以至于一个旨在刚好落在该线之下的请求和一个旨在刚好落在该线之上的请求，是不同的产品。

• 按稳定性排列前缀。先是指令，然后是工具 schema，再是语料库，最后是转录文本。凡是会在不同调用之间发生变化的内容，都应放在末尾——在那里，它代价只是一次前缀匹配，而不是整个缓存。

• 在期望缓存生效之前，先达到 1,024 个可见输入 token。低于该最小值时不会有任何内容被缓存，而且隐藏的提供商 token 不计入其中。

• 检查复用是否可行。前缀必须在 30 分钟的缓存生命周期内被复用，并且必须落在持有该条目的机器上；这两点在指南中均有说明，且都不是你的代码本身的属性。

• 任何模型或设置变更后都要重新测量。迁移到 GPT-6.1 Sol 会移除“关闭推理”的位置，从而改变推理 token 数量，因而也改变预算的输出侧——而对推理强度、工具、结构化输出模式或上下文管理的更改同样可能移动前缀边界，让你彻底失去缓存费率。

• 决定当任务无法再压缩时该怎么办。压缩是文档记载的出路：Responses 请求可以设置带压缩阈值的 context_management，服务器会用不透明的压缩条目替换较早的对话内容，从而以更少的 token 延续关键状态。这是预算决策，而不是免费的精简，因为指南指出压缩“会从第一个发生变化的 token 起阻止复用”——一次压缩操作会使其之后的整个前缀失效。

本页的计算从 GPT-6.1 Sol 所取代的那一代开始，而那一档正是如今可调用的：我们为 openai/gpt-6-sol 提供的卡片显示，上下文窗口为 1,050,000 token，最大输出为 128,000 token按 OpenAI 的标价、0% 加价 — 厂商的价格就是页面上的价格，厂商一旦调价，当天就会在此生效，而不是等到续约时。我们的卡片本身没有最大输入字段，因此该模型 922,000 token 这一数字必须来自厂商自己的文档，而本页自始至终采用的正是这一来源。卡片的用处在于容量测算：它所公布的窗口和输出上限，正是上文预算流程拿来相减的那两个数字，而下面那一档才是你在 6.1 仍属新秀时真正能拿来套用该流程的。它位于 https://www.orcarouter.ai/models/openai/gpt-6-sol。