LLM 基础机制：Token、上下文窗口和采样参数
LLM，也就是 Large Language Model，大语言模型。现阶段我们用到的很多 AI 能力，本质上都建立在 LLM 之上。Agent 也是如此，它并不是脱离 LLM 存在的东西，而是在 LLM 的基础上，加上了工具调用、记忆、规划、检索、执行等能力。
所以，想继续学习 AI Agent，不能只停留在“一问一答”的表面，还需要理解 LLM 的一些基础机制：它怎么处理文本、一次能看多少内容、为什么有时候回答稳定，有时候又很发散。
这篇文章先不聊 Transformer、Attention、训练、微调这些更底层的内容，而是从使用 LLM 时最常遇到的几个概念开始：
- Token
- 上下文窗口
- 采样参数
这些东西看起来基础，但真正理解之后，用 AI、调 Prompt、做 RAG、做 Agent，都会顺很多。
Token
字节 byte 是计算机中的一个计量单位。比如 ASCII 英文字母在 UTF-8 编码中通常占 1 个字节，而常见汉字在 UTF-8 中通常占 3 个字节，少数字符可能占 4 个字节。
但对于大模型来说，它并不是直接按“字节”或者“字符”来理解文本，而是会先把文本切分成一个个 Token。
可以简单理解为：
Token 是 LLM 处理文本时使用的基本计量单位。
它不完全等于一个字，也不完全等于一个词。一个 Token 可能是一个英文单词，也可能是一个英文单词的一部分；可能是一个汉字，也可能是几个汉字组合在一起。
比如拿中文举例，在某个模型的 Tokenizer 里：
你好可能只占 1 个 Token荆可能会被切成 2 个 Token- 一个中文名字，也可能因为切分规则不同，占用多个 Token
所以，“一段话有多少 Token”，不能只靠字符数判断，还要看具体模型使用的 Tokenizer。
不同模型的 Tokenizer 不太一样，中文、英文、标点、代码、空格、专有名词，都会影响最终的 Token 数量。
DeepSeek 文档里给了一个大概估算：
- 1 个英文字符 ≈ 0.3 个 Token
- 1 个中文字符 ≈ 0.6 个 Token
这个只能作为估算。真正计算时，还是要以对应模型的 Tokenizer 或 API 返回的 usage 为准。
我的理解是，训练数据在进入模型之前，会先被 Tokenizer 切分成 Token。模型并不是直接理解“完整句子”，而是在大量 Token 序列中学习它们之间的关系。后来我们看到的语义理解、上下文关联、语言生成能力，都是在这个基础上发展出来的。
暂不讨论图片、音频、视频这些多模态内容的 Token 用量，这些通常会有单独的计算方式。
上下文窗口
每个 LLM 都有自己的上下文窗口，也就是一次请求里最多能处理多少 Token。
这里要注意，不要把上下文窗口和 API 里的 max_tokens 混在一起。很多 API 里的 max_tokens 更常指的是“本次最多生成多少输出 Token”，而上下文窗口指的是“输入和输出加起来最多能容纳多少 Token”。不同厂商的参数命名可能不同，实际使用时还是要以对应 API 文档为准。
过去常见的上下文窗口有 8k、32k、128k、200k。现在一些新模型已经进入了 1M 上下文时代。
按 2026 年 7 月的公开资料看，一些模型已经支持非常长的上下文，例如：
- 128k～200k 级别：很多模型仍然在这个范围，已经足够处理大部分日常问答、摘要和短文档分析。
- 400k 级别：一些模型会提供更长的上下文，用来处理大型代码库或长文档。
- 1M 级别：GPT-5.5 API、Claude Opus 4.7、DeepSeek-V4 Preview、Qwen3.5-Plus 等模型，已经支持百万级上下文窗口。
不过这里要留意：同一个模型系列，不同版本、不同平台、不同 API 端，支持的上下文窗口可能不一样。所以具体开发时，最好以官方文档为准。
上下文窗口通常由 输入和输出共享。
比如一个模型的上下文窗口是 128k，如果输入已经占了 100k，那么留给模型输出的空间就不会太多。有些 API 还会单独限制最大输出 Token 数，所以实际可生成的长度也可能小于上下文里剩余的空间。
一次请求里，通常会占用上下文窗口的内容包括：
- System Prompt
- User Prompt
- 历史对话消息
- RAG 检索出来的内容
- 工具调用的 Schema
- 工具返回结果
- 图片、文档等多模态输入
- 格式要求，比如 JSON 结构、Markdown 符号等
如果是多轮对话，历史消息里也会包含之前 AI 的回复。也就是说，AI 上一轮说过的话，在下一轮请求里通常会作为历史上下文重新传给模型。
本轮 AI 正在生成的内容，则会占用输出 Token 预算。生成完成后，它才会成为下一轮请求里的历史上下文。
所以在做 AI 应用时，经常要控制历史消息长度。不能无限把所有聊天记录都塞给模型，否则很快就会撑满上下文窗口。
还有一个常见现象：
能读进去，不等于能记住。
上下文窗口很大，不代表模型一定能稳定利用里面的所有信息。内容越多，噪声越多，真正重要的信息反而可能被淹没。
长上下文模型里有一个很有名的问题，叫 Lost in the Middle，可以理解为“中间丢失”。相关研究观察到：模型对上下文开头和结尾的信息通常利用得更好，而重要信息放在中间位置时，表现可能会下降。
这也是为什么做 RAG 的时候，不是把所有文档一股脑塞进去就完事。更合理的做法通常是：
- 先检索出真正相关的内容
- 再把重要内容放在更容易被模型注意到的位置
- 控制上下文长度
- 减少无关信息
就像考试前老师划重点，划得越多，越没有重点。所有内容都是重点，最后就等于没有重点。
关于思考模式
现在很多模型都有“思考模式”或者 reasoning 能力。
这类模型在回答前，可能会先进行内部推理。不同厂商的实现方式不一样，有的会显示思考摘要，有的完全隐藏，有的会把 reasoning token 单独统计。
需要理解的是：
思考过程也会消耗模型的计算资源，在一些模型里还会占用输出 Token 或单独的 reasoning budget。
但这些隐藏的思考内容，通常不会完整作为下一轮对话的上下文传回模型。也就是说，用户看到的是最终回答，模型内部的完整推理过程一般不会原样进入下一轮历史消息。
具体是否计费、是否计入输出限制、是否保留在上下文中，要看模型厂商和具体 API 的实现。
采样参数：控制模型怎么选词
前面讲的 Token 和上下文窗口，更像是模型的“硬限制”：能处理多少、能看多少。
采样参数则决定了模型在生成内容时，怎么选择下一个 Token。
LLM 在生成回答时，本质上是一步一步生成的。每一步，它都会根据当前上下文，给所有可能的下一个 Token 打分，然后转成概率分布，再从里面选一个 Token 输出。
这个过程一直重复，直到生成完整回答。
采样参数控制的就是：
模型每一步到底是更保守地选择高概率 Token，还是更开放地允许低概率 Token 也有机会出现。
Temperature：控制随机程度
temperature 直译是“温度”，它控制的是输出从“确定”到“随机”的程度。
- 0.1～0.3：输出更稳定，模型更倾向于选择高概率 Token。适合结构化输出、代码生成和确定性要求较高的任务。
- 0.4～0.7：稳定性和多样性比较平衡。适合日常对话、翻译、摘要和解释类内容。
- 0.8～1.2：输出更发散，更有创造性。适合写作、起名字、头脑风暴和创意生成。
- 1.5 以上：随机性很强，输出可能变得不稳定。除非是刻意实验，一般不建议设置得这么高。
我的常用习惯是：
- 确定性要求较高的任务：
temperature = 0.1～0.3 - 日常对话 / 翻译 / 摘要：
temperature = 0.4～0.7 - 创意生成 / 头脑风暴：
temperature = 0.8～1.2
可以这样理解：
Temperature 越低，模型越像“保守选手”；Temperature 越高，模型越像“灵感选手”。
需要注意的是，低 Temperature 只会降低随机性，并不能保证事实一定正确。对于数学、事实查询和结构化输出，仍然需要合适的模型、清楚的 Prompt、结构化输出约束和必要的结果校验。有些推理模型也不开放 Temperature 等采样参数。
Top-p：动态划定候选范围
top_p 也叫核采样。
它控制的是：只从累计概率达到某个比例的候选 Token 里进行选择。
举个例子，top_p = 0.9 的意思是：
模型会先把所有候选 Token 按概率从高到低排序，然后从高到低累加概率，直到累计概率达到 90%。最后，只从这批候选 Token 里抽样，后面的低概率 Token 直接排除。
常见设置：
top_p = 1.0：基本不限制候选范围。top_p = 0.9：只保留累计概率较高的一批候选。top_p = 0.5：候选范围更小，输出通常更保守。
Top-p 的优点是候选池大小会动态变化。
如果模型对下一个 Token 很确定，可能只需要几个候选 Token 就能达到 90%。如果模型对下一个 Token 没那么确定，就会保留更多候选 Token。
Top-k：固定大小的候选范围
top_k 控制的是固定保留多少个候选 Token。
比如：
top_k = 50意思是只保留概率最高的 50 个 Token，后面的全部排除。
它和 Top-p 的区别是：
- Top-p 是按累计概率动态决定候选数量。
- Top-k 是固定保留前 k 个候选。
实际使用中，Top-p 更常见，因为不用提前猜 k 设多少合适。Top-k 在一些模型里会作为辅助参数，但不是所有模型或 API 都会开放这个参数。
Max Tokens：限制回答长度
max_tokens 常用来限制模型本次最多生成多少 Token。不同 API 也可能使用 max_output_tokens、max_completion_tokens 等名称。
注意，它限制的是输出长度，不是输入长度。
如果设置太小，回答可能会被截断。如果设置得比较大，只是给模型更高的输出上限，并不代表模型一定会把额度全部用完。
我的经验是：
- 简单问答：500～1000
- 普通解释：1000～2000
- 长文生成：2000+
- 结构化 JSON 输出：根据字段数量提前预估
这些数值只适合作为起点，具体还要根据模型、任务和输出语言调整。
模型实际用了多少 Token，通常可以从 API 返回的 usage 字段里看到。
这个字段很重要，因为它直接影响成本，也能帮助我们优化 Prompt 和上下文长度。
我的常用搭配
下面是我自己在支持这些参数的模型上比较常用的搭配。
追求稳定
适合代码结构、JSON 和确定性要求较高的任务：
temperature = 0.1
top_p = 0.2这类场景不需要模型太有创意，重点是稳定、少乱发挥。不过对于 JSON，最好还是配合模型提供的 Structured Outputs 或 JSON Schema，而不是只依赖采样参数。
日常使用
适合解释、翻译、摘要和普通问答：
temperature = 0.7
top_p = 1.0这类场景可以让模型自然一点，不用太死板。
追求创意
适合写作、头脑风暴和起名字：
temperature = 0.8
top_p = 0.9这类场景可以适当提高随机性，让模型多给一些不一样的表达。
不过要注意，很多模型文档都会建议：
不要同时大幅调整 Temperature 和 Top-p。
一般选一个作为主要调节参数就够了。两个都调得很极端，输出效果可能会变得奇怪。
小结
在我看来，LLM 可以先粗略理解成一个“超级猜词机”。
它每一步都在根据当前上下文，预测下一个 Token 的概率分布，然后一步步生成最终回答。
当然，“猜词机”只是一个方便理解的比喻。真实的 LLM 不是简单按词频接龙，而是基于大规模训练学到的参数，在上下文中预测下一个 Token 的概率分布。
这篇文章里，我们主要了解了三个基础概念：
- Token：模型处理文本的基本单位，也可以理解成 AI 世界里的“字数货币”。
- 上下文窗口：模型一次能处理多少内容，也就是它的“短期记忆容量”。
- 采样参数：控制模型输出风格的开关，决定它更保守还是更发散。
理解这些之后，再去看 Prompt Engineering、RAG、Agent、工具调用，就会清楚很多。
因为你会慢慢知道：
- 为什么 Prompt 太长会出问题
- 为什么上下文越多，回答不一定越好
- 为什么同一个问题，模型每次回答可能不一样
- 为什么结构化输出不能只依赖 Temperature
- 为什么 RAG 不是把所有文档塞进去就行
了解这些，用 AI 就不会觉得它只是一个神秘黑盒了。至少我们能大概判断：它为什么这次这么回答，以及我们应该怎么调整它。
参考：
喜欢这篇文章嘛，觉得文章不错的话，奖励奖励我！
评论