一文了解大模型关键参数：Token、上下文长度与输出限制

随着人工智能技术的飞速发展，大型语言模型（LLM）已成为推动这一领域前进的关键力量。为了更好地掌握和利用LLM技术，对其核心参数的理解显得尤为重要。本文将深入探讨大型语言模型中的三大关键参数：Token、上下文长度以及最大输出长度。这些参数不仅决定了模型的性能和限制，也为我们提供了优化和应用LLM的新视角。

Token是什么

Token是大型语言模型 (LLM) 处理自然语言文本时的基本单位，可以将其理解为模型能够识别和处理的最小语义单位。 尽管可以粗略地将 Token 类比为 “字” 或 “词”，但更准确地说，Token 是模型进行文本分析和生成的基础 building block。

在实际应用中，Token 与字数之间存在着一定的换算关系。 一般而言：

• 1 个英文字符 ≈ 0.3 个 Token
• 1 个中文字符 ≈ 0.6 个 Token

因此，我们可以近似地认为，通常情况下一个汉字可以被视为一个 Token。

正如上图所示，当我们将文本输入 LLM 时，模型首先会将文本切分成 Token 序列，然后再对这些 Token 序列进行处理，最终生成我们期望的输出结果。 下图生动地展示了文本 Token 化的过程：

最大输出长度

以DeepSeek系列模型为例，我们可以观察到不同型号的模型都设定了最大输出长度的限制。

上图中，deepseek-chat 模型对应 DeepSeek-V3 版本，而 deepseek-reasoner 模型则对应 DeepSeek-R1 版本。 无论是推理模型 R1 还是对话模型 V3，它们的最大输出长度都被设定为 8K。

考虑到一个汉字约等于一个 Token 的近似换算关系，8K 的最大输出长度可以被理解为： 模型在单次交互中最多能够生成约 8000 个汉字。

最大输出长度的概念相对直观易懂，它限定了模型在每次响应中能够产生的最大文本量。 一旦达到这个限制，模型将无法继续生成更多的内容。

上下文长度

上下文长度，在技术领域也被称为 Context Window， 是理解 LLM 能力的关键参数。 我们继续以 DeepSeek 模型为例进行说明：

如图所示，无论是推理模型还是对话模型，DeepSeek 的 Context Window 均为 64K。 那么，64K 的上下文长度究竟意味着什么呢？

要理解上下文长度，我们需要先明确其定义。 上下文窗口 (Context Window) 指的是大型语言模型 (LLM) 在单次推理过程中能够处理的最大 Token 数量总和。 这个总和包括两个部分：

(1) 输入部分： 用户提供的所有输入信息，例如提示词 (Prompt)、历史对话记录、以及任何附加的文档内容等。
(2) 输出部分： 模型当前正在生成和返回的回复内容。

简而言之，当我们与 LLM 进行一次交互时，从我们输入问题开始，到模型给出回复结束，这整个过程被称为 “单次推理”。 在这次推理过程中，所有输入和输出的文本内容 (以 Token 计数) 总和不能超过 Context Window 的限制，对于 DeepSeek 模型而言，这个限制就是 64K， 约合 6 万多个汉字。

您可能想知道，那么输入内容是否有限制呢？ 答案是肯定的。 正如前文所述，模型的上下文长度为 64K，而最大输出长度为 8K。 因此，在单轮对话中，输入内容的最大 Token 数量理论上为上下文长度减去最大输出长度，即 64K – 8K = 56K。 总结来说，在一次问答交互中，用户最多可以输入约 5 万 6 千字的内容，模型最多输出约 8 千字。

多轮对话

在实际应用中，我们经常会与 LLM 进行多轮对话。 那么，多轮对话又是如何处理上下文的呢？ 以 DeepSeek 为例，当发起多轮对话时，服务端默认不保存用户的对话上下文。 这意味着，在每次新的对话请求中，用户需要将包括历史对话记录在内的所有内容拼接在一起，作为输入信息传递给 API。

为了更清晰地说明多轮对话的机制，以下是一个使用 DeepSeek API 进行多轮对话的 Python 代码示例：

from openai import OpenAI
client = OpenAI(api_key="<DeepSeek API Key>", base_url="https://api.deepseek.com")
# Round 1
messages = [{"role": "user", "content": "What's the highest mountain in the world?"}]
response = client.chat.completions.create(
model="deepseek-chat",
messages=messages
)
messages.append(response.choices[0].message)
print(f"Messages Round 1: {messages}")
# Round 2
messages.append({"role": "user", "content": "What is the second?"})
response = client.chat.completions.create(
model="deepseek-chat",
messages=messages
)
messages.append(response.choices[0].message)
print(f"Messages Round 2: {messages}")

在第一轮对话请求时，传递给 API 的 messages 参数内容如下：

[
{"role": "user", "content": "What's the highest mountain in the world?"}
]

在第二轮对话请求时，需要：
(1) 将上一轮对话中模型的输出添加到 messages 列表的末尾；
(2) 将用户的新提问也添加到 messages 列表的末尾。

因此，在第二轮对话中，传递给 API 的 messages 参数将包含以下内容：

[
{"role": "user", "content": "What's the highest mountain in the world?"},
{"role": "assistant", "content": "The highest mountain in the world is Mount Everest."},
{"role": "user", "content": "What is the second?"}
]

由此可见，多轮对话的本质是将历史对话记录 (包括用户的输入和模型的输出) 拼接在最新的用户输入之前，然后将拼接后的完整对话内容一次性提交给 LLM。

这意味着，在多轮对话的场景下，每一轮对话的 Context Window 并非始终保持 64K 不变，而是会随着对话轮数的增加而逐渐减小。 例如，如果第一轮对话的输入和输出总共使用了 32K Token，那么在第二轮对话中，可用的 Context Window 就只剩下 32K 了。 其原理与上述分析的上下文长度限制一致。

您可能还有疑问： 如果按照这种机制，每轮对话的输入和输出都很长，那么岂不是用不了几轮对话就会超出模型限制？ 但实际使用中，即使进行多轮对话，模型也似乎能够正常响应。

这是一个非常好的问题， 这就引出了另一个关键概念： “上下文截断”。

上下文截断

当我们使用基于 LLM 的产品 (例如 DeepSeek、智谱清言 等) 时，服务提供商通常不会直接将 Context Window 的硬性限制暴露给用户，而是采用 “上下文截断” (Context Truncation) 策略，以实现对超长文本的处理。

举例来说：模型原生支持 64K，但用户累计输入+输出已达 64K ，当用户再进行一次请求（比如输入有 2K）时就超限了，这时候服务端仅保留最后 64K tokens 供模型参考，前 2K 被丢弃。对用户来说，最后输入的内容被保留了下来，最早的输入（甚至输出）被丢弃了。

这就是为什么在我们进行多轮对话时，虽然还是能够得到正常响应，但大模型会产生 “失忆” 的状况。没办法，Context Window 就那么多，记不住那么多东西，只能记住后面的忘了前面的。

这里请注意，“上下文截断” 是工程层面的策略，而非模型原生能力 ，我们在使用时无感，是因为服务端隐藏了截断过程。

总结一下，关于上下文长度、最大输出长度和上下文截断，我们可以得到以下结论：

• 上下文窗口（如 64K）是模型处理单次请求的硬限制，输入+输出总和不可突破；
• 服务端通过上下文截断历史 tokens，允许用户在多轮对话中突破 Context Window限制，但牺牲长期记忆；
• 上下文窗口限制是服务端为控制成本或风险设置的策略，与模型能力无关。

各模型参数对比

不同模型厂商对于最大输出长度和上下文长度的参数设置有所不同。 下图以 OpenAI 和 Anthropic 为例，展示了部分模型的参数配置：

上图中，Context Tokens 就是上下文长度，Output Tokens 是最大输出长度。

技术原理

为什么要有这些限制呢？从技术的角度讲比较复杂，我们简单说一下，感兴趣的可以顺着关键词再去探索一下。

在模型架构层面，上下文窗口是硬性约束，由以下因素决定：

1. 位置编码的范围：Transformer 模型通过位置编码（如 RoPE、ALiBi）为每个 token 分配位置信息，其设计范围直接限制模型能处理的最大序列长度。
2. 自注意力机制的计算方式：生成每个新 token 时，模型需计算其与所有历史 token（输入+已生成输出） 的注意力权重，因此总序列长度严格受限。KV Cache 的显存占用与总序列长度成正比，超过窗口会导致显存溢出或计算错误。

典型应用场景与应对策略

理解最大输出长度和上下文长度的概念及其背后的技术原理至关重要。 掌握这些知识后，用户在使用大模型工具时应制定相应的策略，以提升使用效率和效果。 以下列举了几种典型的应用场景，并给出了相应的应对策略：

短输入 + 长输出

• 场景：输入 1K tokens，希望生成长篇内容。
• 配置：设置 max_tokens=63,000（需满足 1K + 63K ≤ 64K）。
• 风险：输出可能因内容质量检测（如重复性、敏感词）被提前终止。

长输入 + 短输出

• 场景：输入 60K tokens 的文档，要求生成摘要。
• 配置：设置 max_tokens=4,000（60K + 4K ≤ 64K）。
• 风险：若实际输出需要更多 tokens，需压缩输入（如提取关键段落）。

多轮对话管理
规则：历史对话的累计输入+输出总和 ≤ 64K（超出部分被截断）。
示例：

• 第1轮：输入 10K + 输出 10K → 累计 20K
• 第2轮：输入 30K + 输出 14K → 累计 64K
• 第3轮：新输入 5K → 服务端丢弃最早的 5K tokens，保留最后 59K 历史 + 新输入 5K = 64K。

综上，Token、上下文长度和最大输出长度是大型语言模型中不可或缺的三个关键参数。它们各自扮演着重要的角色，共同影响着模型的性能和效果。通过深入理解这些参数，我们能够更有效地利用LLM技术，推动人工智能领域的持续发展。无论是在学术研究还是实际应用中，对这些参数的精准把控都将为我们带来更多的机遇和突破。