AI · LLM · Context Window · Theorem 3 · Measurement

容量是测量值，不是百万token的口号

「百万token」是API接受的上限，而非模型能用好多少。同一份文档在一个旗舰模型里能多放1.6倍。

作者 Everythink Studio team2026年8月13日3 分钟阅读

容量是测量值，不是百万 token 的口号

模型卡片上的「1M tokens」一行，是 API 愿意接受的上限，而非模型能用好多少的保证。2026 年 8 月，ofox.ai 把同一份 420 词的英文文档发给九个旗舰模型，在完全相同的文本上测出 1.56 倍的 token 数差异——Grok 4.20 为 614 token，Claude Opus 5 为 957。标称窗口是卡片上的断言；真实容量是测量值，而根据 Theorem 3，一项属性当且仅当其机制被实现且正在测量时才得到保证。这里的机制是 tokenizer 加上检索准确率曲线，二者都不出现在标题数字里。

上下文窗口究竟是什么

上下文窗口是单次 API 请求的 token 预算。模型读到的一切和它写出的一切都必须装进一个数字，而 API 是无状态的——它不记得上一次调用。每个回合你的应用都要重发整段对话，而窗口就是这次重发加上即将到来的回复允许有多大。

这就是为什么窗口在任何有用意义上都不是记忆。一个聊天产品看似跨会话记得你的名字，其实是把那段文本存在某处，再在每次请求时粘回窗口里。持久性住在你的应用里，不在模型里。

什么算进窗口

请求里的一切，加上响应里的一切。人们忘掉的部分通常是最贵的：

系统 prompt。 每个回合都计数，而非每会话一次。
完整消息历史。 你重发的每个先前用户与助手回合。
工具定义。 你声明的每个工具的名称、描述与 JSON schema。在 Claude 上它们还会附带一个按模型区分的工具使用系统 prompt，从 Opus 5 的 286 token 到 Opus 4.7 的 675。
工具结果。 往往是 agent 循环里最大的单项；一个目录列表或一条 API 响应可以到数千 token。
推理 token。 在开启思考的模型上，推理会被计数并计费，即使文本不返回给你。
回复本身。 这就是为什么 max_tokens 与上下文窗口会相互制约：一个没给输出留空间的请求会被截断。

「1M tokens」是九个不同的数字

[UNIQUE INSIGHT] 标称窗口是 API 愿意接受的上限，而非模型能用好多少——两者之间的差距是基准测试问题，不是卡片问题。决定真实容量的机制是 tokenizer 加上检索准确率曲线，二者都不出现在标题数字里。

在 ofox.ai 于 2026-08-12 编目的九个旗舰模型中，「1M」分解为九个不同的整数：从一个整数 1,000,000（Claude Opus 5、Grok 4.20、DeepSeek V4 Flash）到 1,131,072（Qwen 3.8 Max）。这是你还没测量任何东西之前的 13% 差距。在完整的 119 个文本模型目录里，最常见的窗口是 256K（25 个模型），22 个在 1M。

关于这些数字来源的一点提醒。网关目录与厂商文档并不总是一致：2026-08-12 ofox 目录把 Grok 4.20 列为 2,000,000，而 xAI 自己的模型文档写的是 1,000,000。诚实的比较用厂商数字，并且当数字重要时你去查厂商页面。卡片是断言；厂商文档是更强的断言；在你内容上测到的 prompt_tokens 是唯一能回答你问题的那个。

相同输入上的 1.56 倍差距

更深的意外是：tokenizer——而非窗口数字——才是承重机制。ofox 把同一份 2,638 字符的英文文档（一份 420 词的服务事后复盘）通过一个端点发给九个模型，并读取每个响应的 prompt_tokens：

Grok 4.20：614 token（4.30 字符/token）
GPT-5.6 Sol：626（4.21）
GLM-5.2：632（4.17）
DeepSeek V4 Flash：634（4.16）
Gemini 3.1 Pro：684（3.86）
Claude Opus 4.6：698（3.78）
Qwen 3.8 Max：706（3.74）
Kimi K3：716（3.68）
Claude Opus 5：957（2.76）

相同输入上 1.56 倍的差距。Claude Opus 5 是离群值，因为 Anthropic 文档说明 Claude 4.7 及以后使用一个更新的 tokenizer，对相同文本产生大约多 30% 的 token。

把两张表合起来看，标称窗口就不再是那个有用的数字。同一份 420 词文档实际能装下的份数，从 Claude Opus 5 的 1,045 份到 GPT-5.6 Sol 的 1,677 份——在全都标称「约 1M」的模型上是 1.60 倍的差距。

这个比例在不同内容类型上并不恒定。在一份 TypeScript 文件上差距是 1.53 倍，而 GLM-5.2 比 Grok 更省。在中文散文上差距扩大到 1.88 倍，两个 Claude 模型都落在接近每个汉字一个 token，而 Grok 是 1.87。把这些当样本，别当规则：在第二段标点更多的中文段落上，同样的两个模型落到 0.98 和 0.96 字符/token，意思是有些字符成本超过一个 token。如果你的输入是代码或非英文，去测量它，别假设。

为什么各家按 token 计价不可直接比较

因为一个 token 不是固定数量的文本，按 token 计价不能直接比较。一家每 token 收费更低的厂商，如果它的 tokenizer 更密，可能按词算更贵。Anthropic 以标准费率对完整 1M 窗口计费，无长上下文溢价，所以一个 900K token 的请求每 token 成本与 9K 的相同。Gemini 3.1 Pro 在超过 200K 后从每百万输入 token 2 美元升到 4 美元，Grok 4.20 在同一阈值从 1.25 美元升到 2.50 美元。标题费率更便宜的模型，对长文档工作可能更贵，而 tokenizer 差异叠加在你落到的任何费率档之上。

一个读标价和标称窗口的预算比较读的是两个断言。一个在真实文档上测 prompt_tokens 并乘以适用档位费率的预算比较读的是一个测量值。前者是猜测；后者是一个你能据以开票的数字。

窗口不是可用上下文

最重要的提醒是：一个接受 1M token 的模型，不等于一个能可靠找到你埋在第 800,000 个 token 处那个事实的模型。检索准确率随距离衰减，对每个公开模型都如此，而这个差距的大小是基准测试问题，不是卡片问题。ofox 指向 RULER、MRCR v2 和 NoLiMa 作为真正测量它的基准：RULER 在合成上下文中以受控深度探测检索，MRCR v2 在长文档中追踪多跳检索，NoLiMa 测试当问题与证据之间的词面重叠被移除后模型是否仍能找到答案。这些分数没有一个出现在「1M 上下文」旁边的卡片上。

把标称窗口当作 API 愿意接受的上限，把基准数字当作模型能用好多少的指南。第一个数字是合同；第二个是测量值。一个接受一百万 token 但在 500K 深度以 60% 准确率检索的模型，其可用上下文远低于标称，而任何窗口都补不上这个缺口——只有不同的机制（路由、检索或重构）能。

机制是测量，不是规格

[ORIGINAL DATA] 在 Everythink，我们像对待任何被声称的属性一样对待上下文窗口：根据 Theorem 3，一项属性当且仅当其机制被实现且正在测量时才得到保证。「1M tokens」这行背后没有机制；你内容上的 prompt_tokens 才是机制。我们在选定厂商前测量，并在厂商发布新 tokenizer 时重新测量，因为标题数字曾在任一方向上偏离达 1.6 倍。

这是复测的纪律。tokenizer 不是物理学的稳定属性；它是一个软件制品，厂商可以用一个更新的、对相同文本多产生 30% token 的版本来替换它，正如 Anthropic 对 Claude 4.7 所做。当这发生时，你从旧 tokenizer 缓存的每条容量估计都错了同样的 30%，建立在它上面的每条成本估计也一样。被咬到的团队是那些测了一次、把数字写进配置文件再也没回来的人。保持诚实的团队按节奏复测，就像你会重新校准任何仪器一样。

这对我们不是新纪律。HAI Engine 自 2016 年即在生产中，而每次预测都分发给多个 Sisters——每一个是有自己人格和自己上下文预算决策的 typed AI agent——之后 Oracle 把它们的草稿合并成一个校准过的 ensemble。一次预测不是一个巨型 prompt；它是一组被路由的有界 prompt，而那个界是测量值，不是卡片上的一行。

[PERSONAL EXPERIENCE] 我们测量 agent 上下文预算已有一个十年，我们看到的最可靠的错误是团队按标称窗口选模型，然后在生产中发现真实负载比规格暗示的少装 35% 的文档。修复从来不是更大的窗口。修复是在你正在挑选的模型上测量你自己的内容——一次 max_tokens: 1 的请求返回 prompt_tokens，成本不到一分钱——然后据此路由。

路由先于检索

这跟「the space is the router」是同一个原则：在 Everythink，network→community→room 拓扑在任何东西响应之前先路由一个查询。你不会把整个世界倒进一个窗口然后指望模型在第 800,000 个 token 处找到正确的事实；你路由到持有相关上下文的 room，于是模型实际看到的窗口小、新、且被测量过。容量在成为检索问题之前先是路由问题，而检索在成为规格问题之前先是测量问题。

the 21 papers 把这编成法典。Theorem 3 不说「越大越好」；它说一项属性当且仅当保证它的机制在位且在测量时才成立。对于容量，那个机制是一个读你内容的 tokenizer 和一个在深度上读模型检索的基准。标称数字两者都不是。

客户主权靠测量运转

客户主权——你的 network、你的品牌、你的数据——对容量测量有一种隐含依赖。当你拥有 network→community→room 拓扑，你决定哪个上下文到达哪个 agent，而那个决策只和你的「装得下多少」估计一样好。一个信任卡片的主权运营者把真实决策交给了厂商的营销文案。一个测量自己语料库的主权运营者把路由决策留在内部，它属于的地方。这同样适用于 inclusion by design：一个在计量数据套餐上的低连接用户，最好由一个小而路由良好的窗口服务，而不是百万 token 的消防水带，而「小而路由良好」是一个只有你测量过才能做的测量。

在你拥有的窗口里装下更多

这些没有一个把窗口变大；它们全都减少你在里面花掉的。按回报大致排序：

Prompt 缓存。 一个稳定前缀——系统 prompt、工具定义、你反复询问的文档——在 Anthropic 和其他几家厂商上，缓存命中时按大约 10% 的输入费率计费，尽管确切折扣各异且在某些厂商更深。这是重复调用最大的杠杆，它改变成本，不改变容量。
Compaction。 当对话接近上限时对先前回合做服务端摘要，让长 agent 会话继续运行而不是报错。
上下文编辑。 从记录里清除陈旧的工具结果和旧的推理块。Agent 循环被工具输出填满，比被对话填满更多。
为你的内容选对的 tokenizer。 如上面测量所示，这一项决策在任何其他优化之前就值最多 1.6 倍的有效容量。

前三个管理预算。第四个选择你对照哪个预算测量。四个都是机制；没有一个是卡片上更大的数字。

当你超出窗口会发生什么

你得到一个 HTTP 400 且没有输出。没有任何东西被静默截断。ofox 向一个 32,000 token 的模型发送了一个过大的请求并收到：

{"error":{"code":null,
  "message":"<400> InternalError.Algo.InvalidParameter: Range of input length should be [1, 30720]",
  "type":"invalid_request_error"}}

仔细读那个限制：模型标称 32,000，而强制输入上限是 30,720，余量留给输出。标称窗口是总数，不是你的输入配额，而强制数字可以低于营销数字。

错误形态因厂商而异，所以别在消息字符串上做模式匹配。OpenAI 兼容端点一般返回一个带 context_length_exceeded 风格代码的 400。Claude 可能反而以 stop_reason: "model_context_window_exceeded" 结束回合，这与 max_tokens 不同，需要你代码里自己的一个分支。两者都处理。一个因窗口填满而提前停止的响应，与一个因你 max_tokens 太小而停止的响应，不是同一种失败，修复也不同。

关键要点

标称窗口是 API 接受的上限，不是模型用好多少的保证。 真实容量是测量值，而测量值是 tokenizer 加上检索准确率曲线。
「1M tokens」是九个不同的数字，同一份 420 词文档在一个旗舰模型上比在另一个上多装 1.6 倍。按 token 计价在厂商之间不可比，除非按 tokenizer 密度调整。
测量你自己的内容。 一次 max_tokens: 1 的请求返回 prompt_tokens，成本不到一分钱。在按窗口大小选模型前在你的真实负载上跑它，并在厂商发布新 tokenizer 时重跑。
机制是测量，不是规格。 根据 Theorem 3，一项属性当且仅当其机制被实现且正在测量时才得到保证。「1M」这行没有机制；prompt_tokens 是机制。
路由先于检索。 别把世界倒进一个窗口。先路由到相关上下文——Everythink 的 network→community→room 拓扑是产品层面的同一原则——让模型看到的窗口小、新、且被测量过。

常见问题

上下文窗口和记忆是一回事吗？ 不是。上下文窗口是按请求计的，不持久。API 无状态：每个回合你重发整段对话，而窗口是一次请求可包含内容的上限。窗口外的任何东西都没了，除非你的应用存储它并再次发送。那些看似跨会话记得你的产品，是在把保存的文本重注入窗口，不是在调用模型记忆。

一百万 token 是多少词？ 对英文散文，大约 440,000 到 685,000 词——比常见经验法则承认的范围更宽。按 ofox 在同一文档上的测量，九个模型里八个落在每百万 token 587,000 到 684,000 词之间；Claude Opus 5 是偏低的离群值，约 439,000，因为它的更新 tokenizer。代码更密（约 2.4 到 3.6 字符/token），中文更密（0.9 到 1.9），所以同样的 1M 窗口装的少得多。

2026 年可用的最大上下文窗口是多少？ 1M token 是主流档的顶端。几家厂商略高于整数：Qwen 3.8 Max 在 1,131,072，GPT-5.6 在 1,050,000，Gemini、GLM 和 Kimi K3 在 1,048,576。在 2026-08-12 的 ofox 目录 119 个文本模型里，最常见的窗口是 256K（25 个模型），22 个在 1M。

为什么同一份文件在 Claude 上比在 GPT 上用更多 token？ 不同的 tokenizer。Anthropic 指出 Claude 4.7 及以后使用一个更新的 tokenizer，对相同文本比早期 Claude 多产生约 30% 的 token。在 ofox 的英文测试文档上，Claude Opus 5 用了 957 token，而 GPT-5.6 Sol 用了 626——相同输入上 1.53 倍的差异。没有哪里出错；模型只是计数方式不同，而按 token 计价在厂商之间不可比，除非为此调整。

我能增大一个模型的上下文窗口吗？ 不能。它由模型固定，没有参数能调高。你能改的是你花掉多少：prompt 缓存降低重发稳定前缀的成本，上下文编辑清除陈旧工具结果，compaction 摘要较早的回合。这些管理预算而非扩展它。

如果你想停止猜测容量并开始测量它，创建你的 network——在任何东西响应之前先路由的拓扑，让你的 agent 实际看到的窗口就是你测量过的那个。