上下文窗口可视化

关于上下文窗口可视化

你的文档能塞进哪个模型？粘贴论文、会议纪要或代码，或直接拖滑杆指定 token 数，本工具把 20 个主流模型的上下文窗口画成纯 CSS 条形图：已用百分比、放得下/超出、能装几份一目了然。从 Gemma 3 的 128K 到 Llama 4 Scout 的 10M，模型间的容量差距比多数人直觉大得多——一份 8K 的论文在所有模型里都不算事，一部 100K 的小说就会刷掉一批。窗口数据与 API 成本计算器同源，全部计算在浏览器本地完成。

常见问题

上下文窗口是不是越大越好？

不一定。超大窗口通常伴随更高的单价（尤其按长上下文档计费的模型），且多数模型在超长输入上的检索精度会下降——业界称之为「迷失在中间」。选型的合理思路是：文档加上预期输出能放下、留出对话余量即可；真要喂整库文本时，RAG 分块检索往往比硬塞窗口更准也更省。

为什么实际可用空间比标称窗口小？

标称窗口是输入+输出共享的总预算：系统提示词、多轮历史、工具调用的返回内容都在里面，输出还要预留生成空间。本工具的百分比只衡量「你的文档占窗口的比例」，把它当作容量标尺用即可，别当作账单预测。

粘贴文本得到的 token 数是精确的吗？

是按通用字符比率的即时估算（页面已标注），适合容量判断；要精确切分请用配套的 Tokenizer 可视化，它会加载 OpenAI 公开分词器逐段计数。两个工具定位不同、互相链接。