一句话讲清「上下文窗口是什么 / 为什么是有限的 / 常见模型的上限是多少 / 超出后会怎样」——全程图解。
大语言模型（LLM）在一次推理中能「同时看到」的文本量是有限的，这个上限就叫 上下文窗口（Context Window）。它像一个固定大小的「工作台」—— 模型把对话历史、系统提示、你的新问题、以及它即将生成的回答，全部摆在这张台子上处理。
窗口里的文本按 Token（ token，模型的最小处理单元，约等于「词 / 字 / 子词」）来计量。
窗口上限通常用 「K / M 个 Token」表示，例如 128K ≈ 12.8 万个 token。
模型并不是直接「读字」，而是先把文本切成 Token 再喂给神经网络。不同语言、不同模型的切法不同：
同一段中文，1 个汉字可能就是 1 个 token，也可能被拆开；英文一个词可能是 1 个或多个 token。
英文约 1 token ≈ 0.75 单词；中文约 1 token ≈ 1~1.5 个汉字。所以 128K token ≈ 8~10 万汉字。
API 按「输入 token + 输出 token」分别计费。窗口越大、用得越满，成本越高。
窗口不是「越大就万事大吉」。即使上限很大，实际使用中仍有四类典型问题：
当输入内容（历史 + 系统提示 + 当前问题）超过窗口上限时，要么直接报错，要么「悄悄」丢掉最前面/最早的内容。被丢掉的往往是最早但可能重要的背景。
2023 年的研究（Lost in the Middle）发现：即便内容都在窗口内，模型对开头和结尾的信息利用率高， 对中间部分明显「走神」——关键信息放在长文本的腰上，模型反而容易答错。
即使没有硬截断，塞进太多无关内容也会让模型「分心」：指令遵循变差、事实准确性下降、开始编造。 业内把这种现象概括为 「长上下文 ≠ 会用长上下文」——很多模型的有效利用率远低于标称窗口。
Transformer 的自注意力机制，计算量大致随 token 数 平方级增长。 上下文翻倍，成本和延迟往往远不止翻倍。长窗口用满，账单会「指数级」跳。
下面是主流大模型的上下文窗口上限对比。由于数值跨度极大（从 16K 到 2M）， 横轴采用对数刻度，方便在同图里比较。
| 模型 | 上下文窗口（上限） | 输入计费档（参考） | 典型定位 |
|---|---|---|---|
| GPT-3.5 Turbo | 16K | 低 | 轻量、便宜 |
| GPT-4o / GPT-4 Turbo | 128K | 中 | 通用主力 |
| OpenAI o1 / o3（推理） | 200K | 较高 | 深度推理 |
| Claude 3 / 3.5 / 3.7 Sonnet | 200K | 中~高 | 长文档、代码 |
| Gemini 1.5 Pro / Flash | 1M（2M 可选） | 中 | 超长上下文 |
| Gemini 2.x（最大） | 2M | 中 | 超长上下文旗舰 |
| Llama 3.1 / 3.3 | 128K | 自托管免费 | 开源可私有部署 |
| DeepSeek V3 / R1 | 64K（128K 版） | 低 | 高性价比 |
| Qwen2.5（通义千问） | 128K | 低 | 中文友好开源 |
| Kimi（Moonshot） | 200K+ | 中 | 长文本对话 |
窗口上限通常指输入能放多少 token；但模型单次能生成的 token 数（输出上限）往往小得多—— 常见只有 4K~16K，少数到 64K。即使你给它 200K 的「阅读空间」，它一次也写不出 200K 的字。
短短几年，窗口从「几千」涨到「百万级」，本质上是对注意力机制和工程优化的持续突破。
面对「有限 + 中间迷失 + 成本高」三重约束，工程上有一套成熟的组合拳：
只把最相关的片段送进窗口，从根本上避免超长输入与中间迷失。
只保留最近 N 轮对话，更早的「滚出」窗口，控制长度与成本。
让模型把早期历史总结成短摘要，用摘要替代原文，腾出预算。
把知识存到向量库 / 数据库，需要时再取，突破单次窗口限制。
如整本手册、长代码库、大 PDF：优先 Gemini 1M~2M 或 Claude 200K； 更稳的做法是配合 RAG，别硬塞。
聊天机器人 / 客服：用 滑动窗口 + 摘要 控成本，避免历史无限膨胀。
高频调用：选 DeepSeek / Qwen / GPT-3.5 这类小窗口低价模型，靠架构补能力。
翻译整书 / 生成大报告：盯紧输出上限，用 分批 + 多轮 拼接，而非一次生成。