上下文窗口计算 在线规划Token预算工具
规划128k和1M上下文窗口的Token预算，实时查看使用占比和压缩建议，估算API成本，适合大模型应用开发和提示词设计。
更新于 2026-08-16
相关工具
功能特性
- 基于 js-tiktoken（cl100k_base）的实时 Token 估算：与 GPT-4 系列模型同族的分词器
- 内置上下文窗口预设：GPT-5.6 Luna 1M、Claude Sonnet 5 1M、Gemini 3.6 Flash 1M、Grok 4.20 2M，含 128k/200k 档位与自定义窗口大小
- 诚实标注的中文估算：CJK 文本按每字 1.5-2 Token 经验折算，估算结果明确标注为近似值
- 消息占比进度条：一眼看清文本占上下文窗口的百分比
- 剩余空间显示：窗口溢出前还剩多少 Token 一目了然
- 基于规则的压缩建议：识别超长列表、重复行、过多样例与无结构长文
- 每条建议附带预计可省 Token 区间，帮你判断改写是否值得
- 文本量换算：直接回答「128k 窗口能放多少字」，中文字数与英文词数都有
- 多消息模式：每行一条消息，逐条显示占窗口比例与累计总量
- 字符数、词数、行数与 Token 数并列统计，完整掌握文本规模
- 纯浏览器本地计算：提示词与代码不会上传到任何服务器
使用方法
- 1把文本粘贴或输入到输入区，Token 数、字符数与词数会随输入实时更新。
- 2点击模型预设按钮设定上下文窗口：GPT-5.6 Luna 1M、GPT-5.3 Chat 128k、Claude Sonnet 5 1M、Claude Opus 4.5 200k、Gemini 3.6 Flash 1M、DeepSeek V4 Flash 1M 或 Grok 4.20 2M。
- 3选择「自定义」并输入窗口大小，适合上下文限制特殊的模型，或只想为窗口的一部分做预算。
- 4观察进度条：低于 50% 安全，50-80% 警示，80-100% 危险，超过 100% 文本将放不进去。
- 5规划长文档是否放得下：发送前先粘贴草稿文章、报告或规范，检查它占窗口的比例。
- 6评估对话历史占比：粘贴完整聊天记录，看多轮对话消耗了多少窗口，然后裁掉最早的轮次。
- 7估算 API 成本预算：用 Token 数乘以供应商每 1M Token 的价格，估算单次调用的费用。
- 8开启多消息模式，每行放一条消息，每行都有独立的 Token 数、占比与累计值。
- 9阅读结果下方的压缩建议，会标记长列表、重复行、过多样例与无分段长文，并给出预计可省 Token 数。
- 10试试示例按钮（长文章、聊天记录、代码片段），直观了解不同类型内容对 128k 窗口的消耗。
常见问题
128k 或 1M 窗口能放多少字？
粗略换算：英文约 0.75 词 / Token，中文约 1.5-2 字 / Token。128k 窗口大约可放 9 万-10 万英文词，或约 6.5 万-8.5 万中文字。1M 窗口大约可放 70 万-75 万英文词，或约 50 万-67 万中文字。以上均为估算，实际取决于文本内容与模型分词器。
Token 数是怎么算的？
英文与代码使用 js-tiktoken 的 cl100k_base 分词器（GPT-4 系列模型同族）编码，结果与真实 API 数值非常接近。中文按字符数经验折算，每字按 1.5-2 Token 估算，属于近似值而非精确计数。结果下方的说明会标注当前使用的方法。
估算在不同模型下准确吗？
对 OpenAI 模型（cl100k/o200k 分词器家族，GPT-4 至 GPT-5 系列），英文与代码的计数与 API 实际数值非常接近。Claude、Gemini、DeepSeek 使用不同分词器，实际计数可能有几个百分点的差异。中文估算采用经验换算，不确定性更大。
上下文窗口满了会怎样？
超出窗口的文本无法被处理。视供应商与调用方式而定，超出的部分可能被拒绝或静默截断；在多轮对话中，模型会优先遗忘最早的消息。提前把预算控制在限制以内是唯一可靠的规避方法。
不同模型的上下文窗口怎么对比？
GPT-5.6 Luna 为 1M，GPT-5.3 Chat 为 128k，Claude Sonnet 5 为 1M，Claude Opus 4.5 为 200k，Gemini 3.6 Flash 为 1M，Grok 4.20 为 2M。窗口更大并不总是更好：长上下文通常单次调用成本更高，且模型对输入中段内容的注意力可能下降。
压缩建议可靠吗？
压缩建议基于规则启发式：工具统计列表行数、重复行、示例关键词与段落结构，再给出一个合理的节省区间。区间是粗略估计，实际收益取决于你的内容。请把它们当作提示，而非保证。
能用来估算 API 成本吗？
可以作为起点：用 Token 数乘以供应商每 1M Token 的价格即可。但价格随模型、地区、缓存命中与折扣档位变化，请以官方定价页为准。本工具有意不内置价格，因为价格变动频繁。
多消息模式怎么用？
打开「多消息」开关，在输入区每行放一条消息。进度条下方的表格会逐条显示每条消息的 Token 数、占窗口百分比与累计总量。这与真实请求一致：系统提示、历史对话与用户消息共享同一个窗口。
为什么中英文 Token 数差别这么大？
英文平均约 4 个字符一个 Token（约 0.75 词），而中文每个字需要 1.5-2 个 Token。相同内容用中文书写会消耗明显更多的 Token，也就意味着更高的 API 成本。
上下文窗口和显存（VRAM）有关系吗？
对 API 模型（GPT、Claude、Gemini）没有直接关系：显存在供应商的服务器上。对本地模型（Ollama、llama.cpp），KV 缓存随上下文长度增长，可能耗尽 GPU 显存，这正是本地部署常把窗口限制在模型标称最大值以下的原因。本工具预算的是 Token 和文本量，不是显存，本地部署请对照模型的上下文设置与你的 GPU 内存。
Claude 当前的上下文窗口是多大？
截至本快照，预设覆盖 Claude Sonnet 5（100 万 Token）与 Claude Opus 4.5（20 万 Token）。窗口上限随模型发布变化，不同套餐和 API 档位也可能不同，正式调用前请到 Anthropic 官方文档核对最新数值。
窗口占用多少比较合适？
要留给模型回复空间：输出 Token 同样占用窗口。对长时间运行的对话，建议把占用控制在 50%-70% 以下，这样既留出回复空间，也为分词器差异保留缓冲。
提示词太长了，应该先砍掉什么？
先删最旧的对话轮次：它们和你现在问的事情关系最小。然后去掉重复的示例和冗长的系统指令，一个代表性示例胜过三个差不多的。如果历史记录确实有用，用一段话概括后再放回去，而不是直接删掉。本页的压缩建议会标出具体候选（长列表、重复行、示例过多）并给出预估节省量。
长对话反复撑爆上下文，怎么重置又不丢上下文？
用「总结后继续」的流程：让模型把对话浓缩成一段简短总结，记录已定的决策、约束和未决问题，把总结作为新的开场消息粘贴回去，在新窗口里继续。本页可以事先估算总结的 Token 成本：如果不到窗口的 10%，后面对话的空间就很充裕。
估算的 Token 数和 API 账单对不上，误差有多大？
英文和代码用 cl100k_base 估算，与 OpenAI API 实际值通常只差几个百分点，账单层面差异很小。中文是薄弱环节：1 字 1.5-2 Token 是经验折算，真实值可能差 20-30%，长文档就是几千 Token 的出入。要精确数字，提交前用模型自己的分词器（tiktoken）核对。
选错了模型预设，估算结果还有意义吗？
Token 数本身不变：各预设用的分词器相近；但百分比和进度条会变，因为它们除以的是预设的窗口大小。窗口是 128k 就选 128k；用自定义窗口就填准确数值。只看原始 Token 数的话，预设几乎无所谓；看预算占用的话，它决定了你处在窗口的 40% 还是 90%。