LLM 上下文长度详细介绍

1、概述

　　在《Token：大语言模型的“语言乐高”，一切智能的基石》与《LLM 输出配置 (LLM output configuration)》这两篇博文中介绍了LLM Token、最大输出长度、温度、Top-K、Top-P概念，这篇文章介绍下LLM 上下文长度。

2、上下文长度

2.1 上下文长度介绍

“上下文长度” 在技术领域实际上有一个专有的名词：Context Window，以 DeepSeek 为例：

可以看到无论是推理模型还是对话模型 Context Window 都是 64K ，这个 64K 意味着什么呢 ？请继续往下看。
如果我们要给 Context Window 下一个定义，那么应该是这样：
LLM 的 Context Window 指模型在单次推理过程中可处理的全部 token 序列的最大长度，包括：

1. 输入部分（用户提供的提示词、历史对话内容、附加文档等）
2. 输出部分（模型当前正在生成的响应内容）

这里我们解释一下，比如当你打开一个 DeepSeek 的会话窗口，开启一个新的会话，然后你输入内容，接着模型给你输出内容。这就是一个单次推理 过程。在这简单的一来一回的过程中，所有内容（输入+输出）的文字（tokens）总和不能超过 64K（约 6 万多字）。

你可能会问，那输入多少有限制吗？

有。《LLM 输出配置 (LLM output configuration)》这篇博文中，我们介绍了 “输出长度”，我们知道DeepSeek V3模型最长输出长度 8K，那么输入内容的上限就是：64K- 8K = 56K。

总结来说在一次问答中，你最多输入 5 万多字，模型最多给你输出 8 千多字。

你可能还会问，那多轮对话呢？每一轮都一样吗？

不一样。这里我们要稍微介绍一下多轮对话的原理。

2.2 多轮对话

仍然以 DeepSeek 为例，假设我们使用的是 API 来调用模型。

多轮对话发起时，服务端不记录用户请求的上下文，用户在每次请求时，需将之前所有对话历史拼接好后，传递给对话 API。

以下是个示例代码：

from openai import OpenAI

client = OpenAI(
    # 直接调用DeepSeek API需要充值，这里使用阿里云百炼提供的DeepSeek V3模型进行演示
    api_key="sk-1f005aa94357418ca6dc2fddaxxxxxx",
    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1"
)

# Round 1
messages = [{"role": "user", "content": "世界上最高的山是什么，只回答结果不用详细介绍?"}]
response = client.chat.completions.create(
    model="deepseek-v3",
    messages=messages
)

messages.append(response.choices[0].message)
print(f"Messages Round 1: {messages}")

# Round 2
messages.append({"role": "user", "content": "第二高的呢?"})
response = client.chat.completions.create(
    model="deepseek-v3",
    messages=messages
)

messages.append(response.choices[0].message)
print(f"Messages Round 2: {messages}")

在第一轮请求时，传递给 API 的 messages 为：

[
    {"role": "user", "content": "世界上最高的山是什么?"}
]

输出结果：

Messages Round 1: [{'role': 'user', 'content': '世界上最高的山是什么，只回答结果不用详细介绍?'}, ChatCompletionMessage(content='珠穆朗玛峰。', refusal=None, role='assistant', annotations=None, audio=None, function_call=None, tool_calls=None)]

在第二轮请求时：

1. 要将第一轮中模型的输出添加到 messages 末尾
2. 将新的提问添加到 messages 末尾

最终传递给 API 的 messages 为：

[
	{'role': 'user', 'content': '世界上最高的山是什么，只回答结果不用详细介绍?'},
	ChatCompletionMessage(content='珠穆朗玛峰。', refusal=None, role='assistant', annotations=None, audio=None, function_call=None, tool_calls=None),
	{'role': 'user', 'content': '第二高的呢?'}
]

输出结果：

[{'role': 'user', 'content': '世界上最高的山是什么，只回答结果不用详细介绍?'}, ChatCompletionMessage(content='珠穆朗玛峰。', refusal=None, role='assistant', annotations=None, audio=None, function_call=None, tool_calls=None), {'role': 'user', 'content': '第二高的呢?'}, ChatCompletionMessage(content='乔戈里峰。', refusal=None, role='assistant', annotations=None, audio=None, function_call=None, tool_calls=None)]

所以多轮对话其实就是：把历史的记录（输入+输出）后面拼接上最新的输入，然后一起提交给大模型。

那么在多轮对话的情况下，实际上并不是每一轮对话的 Context Window 都是 64K，而是随着对话轮次的增多 Context Window 越来越小。比如第一轮对话的输入+输出使用了 32K，那么第二轮就只剩下 32K 了，原理正如上文我们分析的那样。
到这里你可能还有疑问 ：不对呀，如果按照你这么说，那么我每轮对话的输入+输出 都很长的话，那么用不了几轮就超过模型限制无法使用了啊。可是我却能正常使用，无论多少轮，模型都能响应并输出内容。

这是一个非常好的问题，这个问题涉及下一个概念，我把它叫做 “上下文截断”

2.3 上下文截断

在我们使用基于大模型的产品时（比如 DeepSeek、腾讯元宝），服务提供商不会让用户直接面对硬性限制，而是通过 “上下文截断” 策略实现“超长文本处理”。（提升用户体验）

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

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

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

2.4 技术原理

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

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

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

3、上下文长度典型场景与应对策略

既然知道了最大输出长度和上下文长度的概念，也知道了它们背后的逻辑和原理，那么我们在使用大模型工具时就要有自己的使用策略，这样才能事半功倍。

（1）短输入 + 长输出

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

（2）长输入 + 短输出

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

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

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

4、总结

1. 上下文窗口（如 64K）是模型处理单次请求的硬限制，输入+输出总和不可突破；
2. 服务端通过上下文截断历史 tokens，允许用户在多轮对话中突破 Context Window限制，但牺牲长期记忆。（注意：“上下文截断” 是工程层面的策略，而非模型原生能力 ，我们在使用时无感，是因为服务端隐藏了截断过程。（提升用户体验））