哪个模型适合 100K token 的文档：上下文和输出限制

简短回答：一份 100K token 的文档可以在一次请求中放进这三个模型中的任何一个。真正区分它们的是文档周围剩余的空间。GLM-5.3-Flash 有 390K 上下文窗口，DeepSeek-V4-Flash 有 380K，并且最多可以写回 32,768 个 token，MiniMax-M2.7 有 180K。两项检查可以告诉你该用哪一个：文档和答案是否都装得进窗口，以及答案是否装得进模型的输出上限。

下面的限制是 CheapTokens 自己的限制，检查于 2026 年 11 月 1 日，当你调用 https://api.cheaptokens.dev/v1 时，你的请求就是按这些限制来衡量的。文档 展示了如何连接，定价 有完整的价格列表。

两步检查#

两条规则都使用你在发送任何内容之前就能知道的数字：

1. 输入 token + max_tokens ≤ 上下文窗口。文档和答案共用一个窗口。
2. max_tokens ≤ 模型的输出上限。

最后一列是窗口减去最长答案，K 按 1,000 计算：390,000 − 8,192 = 381,808；380,000 − 32,768 = 347,232；180,000 − 8,192 = 171,808。在实践中，你很少会要求尽可能长的答案，所以你的空间比那一列显示的更多。

下面是一个看起来真实的案例的检查。你有一份 200,000 token 的日志，想要一份 2,000 token 的分析：200,000 + 2,000 = 202,000。这能装进 390K 和 380K 窗口，但装不进 180K。同样的日志，同样的问题，三个模型中的一个已经出局。

你的文档到底有多大？#

页数是个糟糕的单位，token 才是真正的单位。假设一页英文大约 600 个 token（这是一个假设；真实页面大约在 500 到 700 之间）。那么一份 100K token 的文档就是 100,000 ÷ 600 ≈ 167 页。那是一份厚厚的合同或一份很长的年度报告，它能装进表中的每个模型，而且还有余量。

页数估算用于规划。在发送之前，用分词器计算 token，或者对英文使用大约每个 token 四个字符的粗略规则。每个模型都有自己的分词器，所以计数只是一个估计，请求之后响应中的 usage 字段会给出确切的数字。

在代码中运行检查#

这个脚本会对照上面的限制检查一份合同，发送它，并打印答案是如何结束的。先设置 CHEAPTOKENS_API_KEY，然后替换模型 id 来尝试其他模型。

import os
from openai import OpenAI

# context window, max answer tokens (CheapTokens, checked 1 Nov 2026)
LIMITS = {
    'zai-org/GLM-5.3-Flash': (390_000, 8_192),
    'deepseek-ai/DeepSeek-V4-Flash-0731': (380_000, 32_768),
    'MiniMaxAI/MiniMax-M2.7': (180_000, 8_192),
}

def fits(model, input_tokens, max_tokens):
    context, out_limit = LIMITS[model]
    return max_tokens <= out_limit and input_tokens + max_tokens <= context

client = OpenAI(
    base_url='https://api.cheaptokens.dev/v1',
    api_key=os.environ['CHEAPTOKENS_API_KEY'],
)

text = open('contract.txt', encoding='utf-8').read()
estimate = len(text) // 4   # rough: about 4 characters per token in English
model = 'zai-org/GLM-5.3-Flash'
max_tokens = 1500

if not fits(model, estimate, max_tokens):
    raise SystemExit('Does not fit: pick another model or split the text')

reply = client.chat.completions.create(
    model=model,
    max_tokens=max_tokens,
    messages=[
        {'role': 'system', 'content': 'Summarize contracts in 10 bullet points.'},
        {'role': 'user', 'content': text},
    ],
)
print(reply.choices[0].finish_reason)   # stop = ended on its own, length = cut by max_tokens
print(reply.usage.prompt_tokens, reply.usage.completion_tokens)

如果成功，第一行会打印 stop，第二行会显示输入和输出了多少 token。如果你看到 length，说明答案碰到了 max_tokens；这篇文章 解释了修复方法。如果请求因大小而被拒绝，请求过长：400 与 413 会详细说明。

一个 100K 任务要花多少钱#

假设你要总结合同。每份合同是 100,000 个 token，摘要大约 1,500 个 token（这是假设，请根据你的文件修改）。下面的表格是实时的：它会根据当前价格重新计算，并把 OpenRouter 的参考价放在我们的价格旁边。

这里文档是昂贵的一侧，因为你发送的远多于你收到的。对于这样一个任务，总费用在 GLM-5.3-Flash 上是 $0.0021，在 DeepSeek-V4-Flash 上是 $0.0017，在 MiniMax-M2.7 上是 $0.0052。把输入和输出加在一起计算，这三个模型都比 OpenRouter 便宜。价格按模型固定，没有高峰时段，所以夜间批处理的成本和白天一样。

现在把它扩展到你的日常用量。把滑块移到你自己的负载，然后读取总计：

当答案才是长的那部分#

摘要是简单的情况：短答案在哪里都装得下。当模型必须写很多内容时，麻烦就开始了。假设你有一份 20,000 token 的手册，你要求基于它写一份 6,000 token 的报告。这能装进每个模型（6,000 ≤ 8,192），实时表格会显示成本：

现在要求对同一份手册进行完整翻译。翻译的长度大约和原文一样长，所以你需要大约 20,000 个 token 的答案空间。把 max_tokens 设为 25,000：20,000 + 25,000 = 45,000，完全在 380K 窗口之内，并且 25,000 ≤ 32,768，所以 DeepSeek-V4-Flash 可以在一个答案中完成。这样一个单独的任务花费 $0.0023。对于答案上限为 8,192 个 token 的模型，把手册切成章节，然后一章一章地发送。

哪种适合你的情况#

如果你仍然不确定，用脚本运行一份真实文档，然后读取 usage。要按任务对这三个模型进行更广泛的比较，请参阅 GLM vs DeepSeek vs MiniMax，DeepSeek 页面 更详细地介绍了 DeepSeek-V4-Flash。