【上下文窗口】1M 到底能装多少内容：9 个模型实测，token 数差 1.56 倍（2026）

上下文窗口是模型在一次请求里能处理的 token 上限，输入和输出加在一起算。

单位：       token，不是字数也不是字符数（英文大约 4 个字符 1 token，但会浮动）
范围：       单次请求；不是记忆，不跨请求保留
谁占用它：   system prompt、完整历史、工具定义、工具返回、推理过程、回复本身
常见大小：   老款或便宜的模型 200K，当前主力旗舰 1M
2026 最大：  1,131,072（Qwen 3.8 Max）；整数 1,000,000 是 1M 这一档的下限
超了会怎样： HTTP 400，没有输出；不会悄悄截断
它不告诉你： 模型在窗口最远端能不能准确用上信息

上下文窗口到底是什么？

它是单次 API 请求的 token 预算。 模型读进去的和写出来的，全部要塞进这一个数字里。

API 是无状态的，不记得上一次调用。每一轮你的程序都要把整段对话重新发一遍，上下文窗口限制的就是这次重发的内容加上即将生成的回复能有多大。

所以它和记忆是两回事。某个聊天产品跨会话还记得你的名字，是把这段文字存在了别处，每次请求再贴回窗口里。

哪些内容会占用上下文窗口？

请求里的一切，加上响应里的一切。 大家容易忘掉的，往往正是最占地方的：

• system prompt。 每一轮都算一次，不是每个会话算一次。
• 完整消息历史。 你重发的每一轮用户消息和助手回复。
• 工具定义。 每个声明出来的工具的名字、描述和 JSON schema。Claude 还会为此加一段按模型不同的 tool-use system prompt，Opus 5 是 286 token，Opus 4.7 要 675。
• 工具返回。 agent 循环里通常是最大的一项，一次目录列表或接口返回动辄几千 token。
• 推理 token。 开了思考的模型，推理过程照样计费，哪怕文本不返回给你。
• 回复本身。 所以 max_tokens 和上下文窗口是联动的：请求把空间占满、不给输出留位置，回复就会被截断。

最后一条最容易翻车。Claude Opus 5 默认开着思考，一个在老模型上刚好够用的请求，换过来可能写到一半就没空间了。

各个模型的上下文窗口有多大？

1M token 是主流的天花板，而出现次数最多的规格其实是 256K。 2026-08-12 的 ofox 目录里 119 个文本模型，25 个是 256K，22 个是 1M。

旗舰这一档，按各家官方公布的数字：

两点值得注意。Qwen 3.8 Max 是这一组里公布窗口最大的；Kimi K3 是唯一一个最大输出等于整个窗口的模型，理论上一次回复能写满一百万 token。DeepSeek V4 Flash 的输出排第二，384,000，是这一档大多数模型的三倍，做长文档生成而不是长文档阅读的人会在意这个数。另外，所谓的「1M」其实是九个不同的数字，从整 1,000,000 到 1,131,072，还没开始实测就已经差了 13%。

数字的出处也提醒一句。网关目录和厂商文档不总是对得上：2026-08-12 ofox 目录把 Grok 4.20 标成 2,000,000，而 xAI 自家的模型文档写的是 1,000,000。上表用的是厂商口径。数字关键的时候，回厂商页面核一遍。

同样是 1M token，为什么各家能装的不一样？

因为 token 不是固定长度的文本，而分词器之间的差距比大多数人以为的大。 我们把同一篇 2,638 字符的英文文档（420 个单词，一份故障复盘）通过同一个端点发给 9 个模型，直接读响应里的 prompt_tokens。

实测于 2026-08-12。同样的输入，差 1.56 倍。Claude Opus 5 之所以是异常值，是因为 Anthropic 在文档里写明 Claude 4.7 及之后换了新分词器，同样的文本 token 数「大约多 30%」。

两张表合起来看，标称窗口就不再是那个有用的数字了。同一篇 420 词的文档，各家实际能装下几份：

这些模型标称都在 1M 上下，装同一篇文档的真实容量差了 1.60 倍。

这个比例换一类内容就变，别把上面的数字搬到别的场景。换成一份 TypeScript 文件，差距是 1.53 倍，最省的变成 GLM-5.2 而不是 Grok。换成中文散文，差距拉大到 1.88 倍，两个 Claude 模型都接近一个汉字一个 token，那份样本上是 1.00 字符每 token，Grok 则是 1.87。这只是一次采样，不是规律：换一段标点更密的中文，同样这两个模型是 0.98 和 0.96 字符每 token，也就是有些字符不止吃一个 token。输入是代码或者非英文，就自己测，别靠估。

实操结论：拿你自己的内容，在你正在挑的那几个模型上测一遍。 一次 max_tokens: 1 的请求就能拿到 prompt_tokens，几乎不花钱。

超出上下文窗口会发生什么？

返回 HTTP 400，没有输出，不会悄悄截断。 我们故意给一个 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 兼容端点一般返回 400，错误码类似 context_length_exceeded。
• Claude 可能是正常结束这一轮，但 stop_reason 给的是 model_context_window_exceeded，这和 max_tokens 截断是两码事，代码里要单独分支处理。

两种都得接住。窗口填满导致的提前结束，和 max_tokens 给小了导致的提前结束，不是同一个问题，修法也不一样。

上下文窗口越大越贵吗？

有时候是，完全看厂商。 2026 年有两种计价方式在跑：

• 统一价。 Anthropic 整个 1M 窗口按标准价计费，没有长上下文溢价，90 万 token 的请求和 9 千 token 的请求单价相同。
• 超过 200K 换档。 Gemini 3.1 Pro 在 prompt 越过 200K 之后，输入从每百万 $2 涨到 $4，输出从 $12 涨到 $18。Grok 4.20 在同一个门槛上，输入 $1.25 涨到 $2.50，输出 $2.50 涨到 $5.00。

所以标价更便宜的模型，做长文档反而可能更贵。工作负载经常越过 200K 的话，比价之前先看有没有档位跳变；另外我们那篇提示缓存怎么算账不管你落在哪一档都还叠加生效。

标称窗口等于真正能用的窗口吗？

不等于，这是整页最重要的一条提醒。 模型能接收 1M token，不代表它能可靠地找到你埋在第 80 万 token 的那句话。

所有公开模型的检索准确率都会随距离下降，差距有多大是 benchmark 的问题，不是规格表的问题。这块我们单独写过：LLM 上下文窗口：超过 200K 之后的真实准确率，里面讲了 RULER、MRCR v2 和 NoLiMa 到底测的是什么。

把标称窗口当成「API 最多接收多少」的上限，把 benchmark 数字当成「模型能用好多少」的参考。

窗口就这么大，怎么塞下更多内容？

下面这几件事都不会把窗口变大，只会让你在里面花得更少。 按收益从大到小：

1. 提示缓存。 稳定的前缀（system prompt、工具定义、你反复追问的那份文档）命中缓存后，在 Anthropic 和另外几家大约按输入价的 10% 计费，具体折扣各家不同，有的更深。重复调用的场景里这是最大的一根杠杆，它改的是成本，不是容量。
2. Compaction。 对话逼近上限时由服务端把前面的轮次压成摘要，让长时间跑的 agent 会话继续走下去，而不是直接报错。
3. Context editing。 把过期的工具结果和旧的推理块从上下文里清掉。agent 循环撑爆窗口主要靠工具输出，不是靠对话，我们的 Claude Code token 优化那篇专门讲了编程 agent 这一类。
4. 按内容挑分词器。 上面两张表已经说明，光这一个决定就值 1.6 倍的有效容量，其他优化还没开始做。

不开九个账号，怎么横向比 token 数？

要比得准，就得把同一个请求发给不同厂商的模型，而每家通常意味着各自的 key、各自的 SDK、各自的账单。 摩擦就在这儿：没人为了估个容量去开九个账号，于是这个问题最后往往靠经验法则回答，而不是靠实测。

上面这些模型都讲同一套 OpenAI 兼容的 HTTP 格式，所以一个客户端加一层模型 ID 循环就够了。发 max_tokens: 1，读 prompt_tokens，模型根本不写回答，这次测量的成本不到一分钱。

from openai import OpenAI

client = OpenAI(base_url="https://api.ofox.ai/v1", api_key="YOUR_OFOX_KEY")
text = open("your_document.txt").read()

for model in [
    "anthropic/claude-opus-5",
    "openai/gpt-5.6-sol",
    "google/gemini-3.1-pro-preview",
    "moonshotai/kimi-k3",
    "z-ai/glm-5.2",
]:
    r = client.chat.completions.create(
        model=model, max_tokens=1,
        messages=[{"role": "user", "content": text}],
    )
    n = r.usage.prompt_tokens
    print(f"{model:32} {n:>7,} tokens   {len(text)/n:.2f} chars/token")

这一页上所有的测量数字都是这段循环跑出来的。按窗口大小挑模型之前，拿自己的内容跑一遍：按上面的证据，标称数字在两个方向上都可能差到 1.6 倍。

参考信息来源

• Claude 文档：上下文窗口
• Claude 定价页，含分词器说明
• Claude 文档：提示缓存
• Claude 文档：compaction
• Gemini API 定价
• xAI：Grok 4.20 模型卡
• OpenAI：GPT-5.6 Sol 模型卡
• ofox 模型目录