大模型基础概念:Token、参数和上下文窗口
Token、参数和上下文窗口是理解大模型输入、输出与调用限制的基础概念。本文说明 Token 序列、采样参数和上下文窗口限制,帮助入门读者规划大模型调用。

Token、参数和上下文窗口分别解决什么问题
Token 是大语言模型处理文本的基本单位。文本通常会先被转换成 Token 序列,再交给模型处理。
上下文窗口是模型在一次推理或单次请求中能够处理的 token 长度上限。它决定了一次调用里最多能放入多少提示词、历史消息、用户输入、参考材料,以及需要为输出预留多少空间。
本文中的“参数”,重点指大模型调用时常见的采样参数,例如 Temperature 和 Top-p。它们会影响模型生成回答时选择候选内容的策略,而不是用来扩大上下文窗口。
可以把一次大模型调用理解为一个容量有限的工作台:Token 是放到工作台上的基本文本颗粒,上下文窗口是工作台的容量上限,采样参数则影响模型在生成回答时更稳妥还是更发散。
| 概念 | 主要解决的问题 | 影响对象 | 常见误区 |
|---|---|---|---|
| Token | 文本如何被模型读取和计算 | 输入、输出、历史消息、提示词 | 把 Token 简单等同于字数或单词数 |
| 上下文窗口 | 一次请求最多能容纳和处理多少内容 | 单次调用的 token 上限 | 认为窗口可以在调用时随意突破 |
| 采样参数 | 模型生成时如何选择候选片段 | 输出稳定性、随机性、发散度 | 认为它可以扩大上下文窗口 |
判断一次大模型调用是否可行,不能只看用户问题有多长,还要同时考虑 Token 数量、上下文窗口上限、历史消息、系统提示词和预留输出空间。
Token 如何从文字变成模型可以处理的序列
大模型通常不是直接处理人看到的字符、句子或段落,而是先把文本转换为 Token 序列。Token 可以理解为模型使用的最小文本单元,但它不等同于一个汉字、一个英文单词或一个标点。
同一句话在不同模型或不同分词方式下,可能被切分成不同数量的 Token。对入门使用者来说,不必掌握每一种切分细节,但需要记住一点:只要内容进入模型上下文,通常就会消耗 Token。
Token 与输入、输出和成本的关系
Token 不只影响模型能读多少内容,也会影响输出长度和调用成本的估算。一次请求中常见会消耗 Token 的内容包括:
- 系统提示词:例如角色设定、规则边界、输出格式要求。
- 历史消息:多轮对话中已经发生过、仍被保留的上下文。
- 当前输入:用户本次提交的问题、文档、表格或任务说明。
- 检索材料:知识库片段、长文档节选或外部事实材料。
- 模型输出:模型生成的回答也需要占用 token 预算。
| 内容部分 | 是否消耗 Token | 说明 |
|---|---|---|
| 系统提示词 | 是 | 用来约束模型行为和回答格式 |
| 历史对话 | 是 | 多轮对话越长,占用越多 |
| 用户当前问题 | 是 | 本次任务的主要输入 |
| 检索材料或长文档 | 是 | 长文本任务中常见的主要消耗来源 |
| 模型回答 | 是 | 需要提前预留输出空间 |
上下文窗口为什么会限制一次请求能放多少内容
上下文窗口是模型一次推理过程中可接收并处理的输入 token 序列最大长度,也常被工程上理解为单次请求可处理内容的硬限制。它通常用 4K、8K、32K、128K tokens 等形式表示,具体数值取决于模型设计和接口规则。
上下文窗口一般在模型架构设计阶段就已经确定,不能在某一次调用中临时突破。也就是说,如果一次请求需要处理的内容超过模型可处理范围,就需要压缩、拆分、摘要或调整任务流程。
输入和输出是否都算入上下文限制
不同模型和 API 对上下文窗口、最大输入、最大输出的表述可能不同。有的资料会把上下文窗口定义为可接收的输入 token 上限,也有常见工程表述会把输入和输出总量一起纳入限制。
因此,实际规划时不应把全部空间都留给输入。更稳妥的做法是:
- 先估算系统提示词和固定模板占用。
- 再估算历史消息、检索材料和当前问题占用。
- 最后为模型回答预留足够输出空间。
- 具体上限以所使用模型的接口文档和实际返回规则为准。
长上下文模型可以容纳更多内容,但上下文窗口仍然是有限资源。窗口更大并不代表可以忽略任务结构、材料筛选和输出预算。
一次调用中哪些内容会占用上下文窗口
一次大模型调用中,占用上下文窗口的通常不只是用户刚输入的那一句话。系统提示词、历史消息、当前用户输入、检索材料以及输出预算,都会影响可用空间。
多轮对话尤其容易出现这个问题。随着对话轮次增加,历史消息会不断挤占上下文窗口,留给当前问题、补充材料和回答的空间就会变少。如果任务需要较长答案,还必须提前为输出预留 token。
Token 预算规划表
| 预算项 | 作用 | 规划建议 |
|---|---|---|
| 固定系统提示词 | 设定角色、边界、格式 | 尽量清晰,不堆叠无关规则 |
| 历史消息 | 保留对话上下文 | 删除或摘要与当前任务无关的历史 |
| 检索材料 | 提供外部事实或文档片段 | 优先放入最相关片段,而不是整篇全文 |
| 当前用户问题 | 描述本次任务目标 | 明确输入、输出和约束 |
| 预留输出长度 | 给模型生成回答使用 | 长文、表格、JSON 等结构化输出应预留更多空间 |
长文本任务的处理思路
对于长文档总结、知识库问答、多轮对话和结构化生成任务,可以优先做三件事:
- 删除与当前目标无关的历史内容。
- 压缩或摘要过长的背景材料。
- 在输入前确定回答长度和输出格式,避免把窗口全部用于输入。
采样参数如何影响模型回答的稳定性和发散度
Temperature 和 Top-p 属于采样参数,用来影响模型选择候选片段的策略。它们不是输入文本本身,也不是上下文窗口大小,而是控制模型生成输出时更稳定还是更发散的设置。
在实际调用中,可以把采样参数理解为输出风格和随机性的调节器。较低随机性的设置通常更适合事实问答、分类、抽取和格式稳定的任务;较高随机性的设置更适合创意写作、方案发散和头脑风暴类任务。
| 设置倾向 | 输出特点 | 更适合的任务 | 需要注意 |
|---|---|---|---|
| 较低随机性 | 更稳定、变化较小 | 问答、信息抽取、结构化输出、规则改写 | 可能不够发散 |
| 较高随机性 | 更多变化、更开放 | 写作、创意命名、头脑风暴、方案探索 | 可能增加不稳定性 |
需要注意,本文讨论的参数是调用时常见的采样参数,不是模型权重、模型规模等意义上的参数。采样参数可以改变生成策略,但不能解决上下文超限问题;如果输入太长,仍然需要压缩、拆分或调整任务设计。
把三者放在同一次大模型调用中理解
一次大模型调用可以按流程理解:文本先被切分为 Token,系统提示词、历史消息和用户输入进入上下文窗口,模型再根据采样参数设置生成输出。输出本身也需要预留空间,因此 token 预算和参数设置要一起规划。
| 调用环节 | 发生了什么 | 需要关注的概念 |
|---|---|---|
| 准备提示词 | 写入系统规则、任务要求和输出格式 | Token、上下文窗口 |
| 加入历史消息 | 提供多轮对话背景 | Token、上下文窗口限制 |
| 放入当前输入 | 提交问题、文档或检索材料 | Token 序列、输入长度 |
| 设置生成参数 | 配置 Temperature、Top-p 等 | 采样参数 |
| 生成回答 | 模型输出文本 | 输出预算、输入输出总和限制 |
常见问题的排查方向
| 现象 | 优先检查什么 | 可能的处理方式 |
|---|---|---|
| 长文放不进去 | 输入 Token 是否超过窗口或接口限制 | 分段、摘要、筛选关键片段 |
| 回答被截断 | 是否预留了足够输出空间 | 减少输入、缩短回答目标或分步生成 |
| 多轮对话效果变差 | 历史消息是否占用过多窗口 | 压缩历史、保留关键状态 |
| 输出不稳定 | 采样参数是否过于发散 | 降低随机性,明确格式约束 |
| 结构化输出不完整 | 输入太长或输出预算不足 | 简化字段、分步生成、预留输出空间 |
面向实践的检查清单和常见误区
在规划一次大模型调用前,可以用下面的清单快速检查 Token、参数和上下文窗口是否被合理处理。
调用前检查清单
- 是否把系统提示词、历史消息、检索材料和当前问题都计入 token 预算?
- 是否为模型输出预留了足够空间,而不是把上下文窗口全部用于输入?
- 是否确认所用模型的上下文窗口、最大输入和最大输出规则?
- 是否删除了与当前任务无关的历史对话和背景材料?
- 是否根据任务类型设置了合适的 Temperature、Top-p 等采样参数?
- 是否把长文本任务拆成了可处理的阶段,例如摘要、抽取、问答或分段生成?
常见误区
| 误区 | 正确理解 |
|---|---|
| Token 就是字数 | Token 是模型处理文本的基本单位,不能简单等同于字数、字符数或单词数 |
| 上下文窗口越大,回答一定越好 | 更大的窗口能容纳更多内容,但回答质量仍取决于材料相关性、提示词和任务设计 |
| 采样参数可以解决输入超长 | 采样参数影响生成策略,不能扩大上下文窗口 |
| 多轮对话只看当前问题长度 | 历史消息也会占用窗口,长对话需要摘要或裁剪 |
| 只估算输入,不考虑输出 | 输出也需要预算,尤其是长答案和结构化结果 |
对于入门使用者,最实用的判断方法是:先估算内容会变成多少 Token,再确认是否放得进上下文窗口,最后根据任务目标调整采样参数。三者分别对应文本表示、容量限制和生成策略,放在一起理解,才能更稳定地规划大模型调用。