每张模型卡上都写着"200K 上下文"或"1M 上下文"之类的数字。它看起来像容量参数，就像磁盘空间。其实它更接近你在每一次请求里都要花掉的预算——而花掉它的大部分并不是你打的那些字。
数字最后核对日期：2026 年 8 月 26 日。
上下文长度是什么
模型没有记忆。每次调用，你都要把整段对话重新发一遍——系统提示、之前的每一轮、所有附件——它会在写下一个字之前把这些全部读完。
上下文长度就是这一整包的最大尺寸，以 token 计。token 是一小块文本，在英语中大约是四分之三个词。
所以它不是存储。它是模型能摊开你文件的那张桌子的大小，每次请求都重新清空。
今天的真实上限
| 上下文长度 | 该量级的模型 |
|---|---|
| 32,768 | Qwen 2.5 Coder 32B |
| 200,000 | Claude Haiku 4.5 |
| 262,144 | Kimi K2.7 Code |
| 400,000 | 整个 GPT-5 家族，包括每个 Codex 变体 |
| 1,000,000 | Claude Opus 5、Claude Sonnet 5、Qwen3 Coder Flash 和 Plus |
| 1,048,576 | Gemini 2.5 与 3.x 家族、DeepSeek V4 Pro |
有两点值得留意。
一百万 token 大约是 75 万个词——好几本长篇小说。几乎没有哪个应用需要这么多，而那些觉得需要的，通常是检索出了问题，而不是上下文不够。
1,048,576 就是 2²⁰，不是市场部凑的整数。某家厂商写正好 1,000,000，那是四舍五入过的；写 1,048,576，那是在报告真实的缓冲区大小。
每个文本模型的 token 价格和上下文长度都在聊天模型页。
真正把它填满的是什么
这是模型卡不会告诉你的部分。Anthropic 的文档公布了几个最简请求的准确 token 数，很有教益：
| 发送了什么 | 输入 token |
|---|---|
| 五个词的系统提示加两个词的消息 | 14 |
| 九个词的问题加 一个 工具定义 | 403 |
| 一张图片加 "Describe this image" | 1,028 |
| 一个 PDF 加 "Please summarize this document." | 2,188 |
一个工具定义要花大约 390 个 token。 带二十个工具的智能体，在用户还没输入任何内容之前，就已经花掉了自己窗口里约 8,000 个 token——而且每次请求都要付。
一张图片约一千个 token。 二十张截图就是 20,000。
而且对话本身在长大。 第 10 轮驮着第 1 到 9 轮。开头觉得很小的聊天，到结尾会是请求里最大的那部分。
所以一个"200K 上下文"的模型，放在带十五个工具、一段长系统提示和几张截图的智能体里，并不是从 200K 起步的。它从远低于此的地方起步，而且每一轮都在缩水。
陷阱：同样的文字不是同样的 token 数
上下文长度以 token 计量，而 token 在不同模型之间并不是一个稳定单位。
Anthropic 自己的文档写明，Claude 4.7 及以后使用了更新的分词器，其中"同样的输入文本产生的 token 比早期模型多约 30%"。
这意味着：在旧模型上量到 15 万 token 的提示词，在新模型上可能是 19.5 万左右——同样的字，多占三成窗口，多花三成钱。如果你曾按某个模型给文档处理流水线定过尺寸，后来换了模型，先重新量一遍，别默认还装得下。
厂商给了你核对的办法。Anthropic 的 token 计数接口调用免费。用你打算实际运行的那个模型去数。
用完了会怎样
不是优雅降级。视厂商而定，你会拿到一个错误、一段被截断的输入，或者被悄悄丢掉的历史——第三种最危险，因为模型会基于一段它已经看不全的对话，自信地作答。
三条出路，按工作量从小到大：
裁剪。 丢掉或概括最旧的几轮。最省事，聊天场景通常够用。
缓存。 如果你上下文里大块的部分是固定前缀——一段长系统提示、一份参考文档——提示缓存能让厂商把它存下来，重新读取时只收一小部分费用。这不会把窗口变大，但能拿掉填满它的绝大部分成本。
检索。 别再把整个语料都发过去，只发相关的部分。工程量更大，但这是唯一一种不会随着数据增长而变糟的做法。
去够一个更大的上下文窗口是第四个选项，通常也最贵——因为那个窗口里的每一个 token，你每次请求都要付。
窗口更大是不是更贵
按 token 算不是。同一个请求，1M 上下文的模型不会比 200K 的按更高费率计费；Claude Sonnet 5 是每百万输入 token 2.00 美元，你发五百个 token 还是五十万个都一样。
但是 更大的窗口让人容易花得更多，因为它把本该拦住你的那个报错拿掉了。用 2.00 美元每百万的价格填满一百万 token 的窗口，就是每次请求 2.00 美元——如果那个请求是每月发生五万次的一轮聊天，这笔账很快就会变得严肃。
无论哪种情况，纪律都一样：能发多少就发多少，而不是允许多少就发多少。
简版
- 上下文长度是一次请求的最大尺寸，以 token 计，不是记忆。
- 今天的上限从约 33K 到约 1M；绝大多数生产场景在低端就绰绰有余。
- 工具定义（每个约 390 token）、图片（约 1,000）、PDF（约 2,000）和重新发送的历史，比你的提示词填得快得多。
- 同样的文字在不同模型上是不同的 token 数——换模型时重新核对。
- 更大的窗口按 token 算并不更贵。它只是让你更容易多花一些。
在 ElliSekiz 上继续了解
把上下文长度和 token 价格并排比较。 聊天模型页列出了每个文本模型及其输入与输出费率。
然后量一量你自己的提示词。 每个模型页都有 playground——在给任何东西定尺寸之前，先跑一次真实请求，读一读真实的 token 数。
来源
- OpenRouter models API，
https://openrouter.ai/api/v1/models（上下文长度，读取于 2026-08-26） - Anthropic — Token counting（有据可查的示例计数、分词器变更、免费计数接口）