LLM核心机制拆解：Token、上下文窗口与采样参数实战指南

先坦白一个事儿：我最早做 LLM 应用时，最懵的不是提示词，也不是模型选型，而是一堆看着眼熟的术语——Token、上下文、温度。明明每个词单独看都认识，连在一起却搞不清它们怎么影响模型输出。更尴尬的是，我曾在群里看到有人报了这么个错：“Invalid token”，然后在文档里翻“一个中文等于多少 token”，翻了一下午也没解决，因为那根本不是同一个“token”。

这就是我想写这篇拆解的原因。模型不神秘，它的运行机制说到底就三根支柱：输入怎么被切分（Token）、模型能记住多少（上下文）、输出怎么变得“像人话”（采样参数）。把它们全部理解透了，无论是做 RAG、写 Agent、还是只是在 Cursor 或 Claude Code 里省点额度，你都比 90% 的“会用”的人强。我尽量用交流和踩坑的口吻写，不堆术语，但该深的地方也得挖到根上。

1. Token：LLM的输入货币与文本切分逻辑

1.1 为什么是“Token”而不是“字”或“词”

先解决最基础的问题：模型读入的不是文字，而是数字。任何 Transformer 架构的语言模型，第一步都是把文本映射成一个整数序列，这些整数再查表得到向量。Token 就是“文本切分的最小单位”，它既不是字母，也不完全是词，而是介于两者之间的一种子词单元。

主流模型用的切分算法叫 BPE（Byte Pair Encoding，字节对编码），核心思路很直白：先按单个字符（或字节）拆，然后反复统计文本里出现频率最高的相邻字符对，把它们合并成一个新符号，直到达到预设的词表大小。举个例子，单词 “lower” 可能不用拆，但 “lowest” 会被切成 “low” + “est”。这样做的妙处是：常见词用一个 token 搞定，罕见词拆成若干子词也能拼出来，词表大小可以控制在几万到十几万，既不会因为词表太大撑爆显存，也不会因为不认识生词直接摆烂。

你可以把 BPE 理解成乐高：每个 token 是一块积木，词频高的积木块大一点，生僻的积木块小一点，但它一定能拼出你想表达的东西。这也是为什么模型能处理拼写错误、自创词、混合语言——因为它在字符和词之间的粒度上做匹配，而不是死记硬背一个固定词表。

1.2 Token与计费、限额、性能的真实关系

理解 token 之后，你才算真正看懂了 LLM 的计价器和限速器。各家 API 的计费单位无一例外是“每百万 token 多少钱”，不是按字符，不是按请求次数，而是按模型真正“读入+写出”的 token 总量。也就是说，同样的需求，不同语言、不同表达方式，花的钱可以差很多。

我给你一个非常直观的量级感受（以典型中英文文本近似估算）：

注意中文的消耗。因为 BPE 是基于常见的英文语料统计的，中文这种字符密度高、信息密度也高的语言，平均每个字会被拆成接近两个 token。所以你会发现同一个意思，用中文写和用英文写，计价完全不同。这不是模型“歧视”中文，而是词表构建时的统计偏好决定的。理解了这一点，你在做成本控制时就会意识到：提示词写精炼，远不是少几个字那么简单，而是在控制 token 数量。

还有一个被忽略的性能维度：生成速度。自回归模型是一个 token 一个 token 往外蹦的，输出 1000 token 意味着要跑 1000 次前向推理，每次都要做完整矩阵运算。所以输出 token 上限（比如常见的 max_tokens）不只是防止花钱失控，还直接影响你等多久能看到结果。很多“AI 回答到一半停了”的场景，不是模型傻了，而是你设置的输出上限到了。

1.3 中文场景下的Token消耗怪现象

我在实际项目里观察到几个中文场景的怪现象，新手不踩一次很难醒悟：

第一个是“标点符号和格式的隐形消耗”。在 API 式交互里，模型生成的 markdown 格式、英文冒号、代码块标记都是实打实的 token。一些人不理解为什么让模型写一份简单的周报也烧了几百上千 token，打开 Token 计数器一看，一半被 ``` 和表格语法吃掉了。这不是 bug，任何字符都要按词表切分，而 tokenizer 不会因为它在渲染时好看就免费。

第二个是“重复上下文烧钱”。很多人做 Agent 时，习惯把一大段系统提示词 + 历史对话 + 检索结果一股脑全部塞进每次请求。初看没毛病，仔细一算：如果每轮请求携带 5000 token 的历史，循环 10 轮就是 5 万 token 的输入量，成本瞬间比一锤子买卖高一个数量级。这不是模型的问题，是使用方式的问题。

第三个是关于“输出 token 上限截断”的处理。许多模型的默认输出上限并不高，生成长篇代码或结构化长文时，写到一半就被硬截断。最土的解决方法是把 max_tokens 调大，但在很多工具里，这个值受上下文窗口限制，你调大输出就得压缩输入。另一个靠谱的办法是分段生成：要求模型先输出大纲，再按大纲一部分一部分地写；或者在截断后把现有内容作为输入，继续让它“接着写”。后者在热词里对应的就是“发送‘继续’可让模型接着说”的机制——本质上是把前文输出重新作为下一轮上下文的一部分。

2. 上下文窗口：模型能“记住”多少，以及超限后会发生什么

2.1 上下文窗口的工作方式：从Prompt到KV Cache

Token 是输入的基本单位，上下文窗口就是模型“一回合里能看到的 token 总数上限”。这个上限既包括用户输入的 prompt，也包括模型生成的输出，还包括系统提示词、tools 定义、历史消息等一切塞进请求里的内容。你每发一条消息，实际上是把整段内容重新交给模型处理。

为什么“重新处理”这个动作很关键？因为 Transformer 的注意力机制是全局的：模型需要把当前生成的每一个新 token，和上下文里所有旧的 token 都做一次注意力计算。为了不每次从头算起，工程上会缓存每个 token 经 Attention 计算后的 K 矩阵和 V 矩阵，这就是常说的 KV Cache。

KV Cache 非常吃显存。上下文窗口开得越长，要缓存的 K/V 就越多，推理成本也越高。这也是同一个厂商的模型，32K 上下文版本往往比 8K 版本调用更贵、速度更慢的根本原因。市面上有些号称“百万上下文”的模型，靠的是稀疏注意力、滑动窗口之类的近似优化，并不是每个 token 之间都保持全量注意力。理解这层之后，你就会明白一个反直觉的结论：上下文窗口大，不代表你该把什么都往里塞；同时，窗口大，也不必然代表模型对中间部分内容的“记忆力”就强。

2.2 超过上下文限制的两种表现：报错与被截断

“超过上下文限制会怎么样”这个话题，在各个工具的反馈里表现形式不太一样，拆开看无非两种：

第一种是请求前性报错。在把 prompt 发给模型之前，API 服务端先数一下输入 token 数，发现已经超过窗口限制，直接返回一个类似 “maximum context length exceeded” 的错误，请求根本不会进入生成阶段。这种报错最常见于长文档分析，你贴了一整本书进去，还没问问题就被拒了。

第二种是生成中途截断。如果你的输入没超限，但输入+输出加在一起超过了窗口上限，模型会边生成边计算剩余可用空间，一旦用尽，直接强行停止。这就是我们在很多聊天工具里见到的“已达输出上限，回答被截断”。如果你用的是官方聊天页面，往往会在后面加成“发送‘继续’可让模型接着说”；但如果你是调 API 拿原始返回，就得自己在代码里处理，用 last message 续传或者重新拼接上下文再发一次。

不要小看这个区别。我做过一个批量文档处理工具，第一次上线就翻车：人家传了一个 20 万字的 PDF，我的代码完全没检查输入长度，直接把文本塞进请求里，结果用户看到的全是报错而不是答案。后来我加了两个保险：调用前先跑一次 token 统计，超限就直接提示用户改传摘要或拆分文档；调用后检查 finish_reason，如果是 length 截断就自动触发第二轮续写。这俩保险的成本极低，但用户体验提升是质变。

2.3 上下文工程：不是把资料都塞给模型

既然窗口有限，怎么在有限空间里塞最有用的信息就成了一个专门的工程方向——很多人叫它“上下文工程”。别以为这是理论，它直接决定你的 Agent 是聪明还是像个失忆的金鱼。

我的经验可以浓缩成三条原则：

1. 越靠近末尾的信息越重要。很多模型对中间部分的注意力权重会降低，这是注意力机制在长序列下的通病。所以关键指令、核心问题要放在 prompt 的后面，背景资料放在前面。
2. 系统提示词要精简到“只讲原则，不讲细节”。常见错误是系统提示词写了上千字，把范例、禁忌、格式说明全堆进去，挤占了宝贵的上下文空间。实际上系统提示词更适合放：你是谁、目标是什么、输出格式是什么、绝对不能做什么。
3. 历史对话要压缩或摘要。多轮对话场景里，你可以定期把前面的对话交给模型浓缩成一段摘要，然后只保留最近两三轮的完整对话和那份摘要。这样既保住了上下文连贯性，又不会让历史记录无限膨胀。这本质上是用一层“摘要缓存”换 token 空间。

2.4 RAG与上下文工程怎么配合

RAG（检索增强生成）看起来是把外部知识塞进上下文，实际上它解决的不是“上下文窗口不够大”，而是“模型不知道/记不住外部知识”的问题。一个好用的 RAG 系统，不是把整篇文档拿去喂给模型，而是把文档拆成块（chunk）、向量化、建立索引，用户提问时检索出最相关的内容片段，拼进 prompt 里。

这里有一个非常实用的经验：不是检索结果越多越好。有些人做 RAG 时 top_k 设得很大，恨不得把 20 段相关文本全塞进上下文，结果模型被一堆重复、冗余、无关的边缘内容干扰，答案质量反而下降。一般建议是 top_k 取 3~6 段，每段控制在 200~500 token 以内，然后在大模型 prompt 里明确告诉它“根据提供的材料回答，材料没有的信息不要编”。这样既控制了 token 成本，也缓解了幻觉。

如果你把“上下文工程”和“RAG”放在一起看，本质就一句话：上下文窗口是你的工作台空间，RAG 是帮你精准地把工具从仓库里取出来放上工作台，而不是把整个仓库搬过来。

3. 采样参数：温度与Top-P是怎么控制生成结果的

3.1 softmax做底：从概率分布说起

聊采样参数之前，必须先搞清楚模型输出的“原材料”是什么。自回归语言模型每一步做的事情，其实是计算词表中每一个 token 成为“下一个 token”的概率。模型内部给每个候选 token 算出一个分数（logits），这些分数经过一个叫 softmax 的函数归一化，变成总和为 1 的概率分布。

默认情况下，模型应该选择概率最高的 token（贪心解码），但光这样会有一个严重问题：生成结果永远是同一个，而且很干巴、很机械。为了让人话更自然，模型需要在“按概率随机抽样”和“始终选最大概率”之间找一个平衡。采样参数的作用就是这个平衡器。

别被“采样”两个字吓到，它的本质就是：在每一步生成时，根据某种策略从概率分布里挑一个 token。温度、Top-P、Top-K 都会影响你这个“挑”的动作。

3.2 温度：越高越敢说，越低越保守

温度（Temperature）是最常见、也是最被人误解的参数。直觉上很多人觉得“温度越高越聪明”，完全错了。它的作用是通过对 logits 做缩放来改变概率分布的“形状”，实际机制是：在 softmax 之前，把所有 logits 除以温度值。

搞懂这个公式就搞懂了一切：

• 温度 = 1.0：什么都不变，按原分布采样。
• 温度 < 1.0（如 0.2）：logits 被放大，本来概率高的 token 变得更高，概率低的基本没戏，输出更确定、更保守。
• 温度 > 1.0（如 1.5）：logits 被压缩，概率高的 token 和概率低的 token 之间的差距变小，低概率 token 更容易被选中，输出更多样、更大胆。

用人话说：温度像是一个“hype 程度调节器”。温度低，模型像一个严谨的秘书，怎么稳妥怎么写；温度高，模型像一个头脑风暴的创意者，什么离谱词都敢蹦。这也就是为什么热词里“大模型能力边界：幻觉、上下文、温度”会被并排提及——温度调高就是这样，幻觉概率会显著上升，因为那些原本概率很低的“编造项”被抬上了台面，有机会被选中了。

3.3 Top-P、Top-K与重复惩罚：把输出拉到“合理范围”

温度负责改变概率分布的“形状”，但还漏了一个问题：有些低概率 token 被抬起来后，可能产生语法错误、逻辑断裂甚至胡言乱语。这时候就需要 Top-P 和 Top-K 这种“过滤器”。

Top-K 是一个简单粗暴的截断：只从概率最高的 K 个 token 里选，K 之外的一律不参与采样。比如 Top-K=50，就相当于强行让模型在“最可能成为下一个词的 50 个候选”里做选择。缺点是 K 是固定值，不同上下文里合理候选数量其实不一样，所以很多人更爱用 Top-P。

Top-P，也叫核采样（nucleus sampling），逻辑是动态的：从概率最高的 token 开始往下一个一个累加，直到累计概率达到你设定的阈值 P，然后把所有没加进来的低概率 token 全部踢掉，再从剩下的候选里按比例采样。比如 P=0.9，意味着模型会“覆盖至少 90% 的概率质量”，剩下的尾部 10% 全不要。这样在预测明确的时候，候选项很少，很确定；在预测模糊的时候，候选项多，有发挥空间。它比 Top-K 更聪明的地方在于：候选数量是随上下文变化的，不是一刀切。

还有一个容易被忽略的“重复惩罚”参数（frequency penalty / presence penalty）。它会在每生成一个 token 时，对已经出现过的 token 的概率做一次惩罚，防止模型陷入重复循环。做长文本生成时如果模型开始“车轱辘话来回说”，多半就是这两个参数没调好。总结一下三个参数的定位对比：

3.4 一个容易被忽略的实战细节：温度与提示词的互相影响

采样参数不是孤立起作用的，它和提示词之间有一个很微妙的“负反馈”关系。如果你给了一个极其详细、约束满满的提示词，即使温度调到 1.2，模型的发挥空间也很有限，因为可选的合理方向已经被压缩了。反过来，如果你提示词给的很开放，哪怕温度只有 0.5，模型也可能在多个合理方向里选一个不太稳定的路径。

所以我的调参流程一般是这样：先固定提示词，跑一批测试，看输出多样性是不是符合预期；如果太跳，我先不急着降温，而是先加强提示词里的约束条件，把不合规的方向禁止掉；然后才是调温度，把温度作为一种“精细微调”的手段。许多教程把温度当万能旋钮，其实它是“最后一步的旋钮”，前面还有提示词工程和结构化输出约束这两个更有效的工具。

另外现在的模型对温度的敏感度也不一样。有的新模型（尤其是指令微调得比较好的）对温度几乎不敏感，你调到 0.2 和 1.0 差别有限，这背后是因为指令遵循能力增强了，模型学会了在低温度下也保持表达多样性，在高温度下也不随便乱编。所以正确做法是：先用默认温度跑一版，再拿几个典型 case 做对比测试，而不是迷信某一组“标准参数”。

4. 别搞混：LLM的Token和API认证Token是两个东西

4.1 词元Token与令牌Token的混淆现场

这一章是我特意加的，因为实际踩坑的人太多了。搜索热词里有一堆“token exchange failed: token endpoint returned 403”、“sign-in could not be completed token exchange failed”、“jwt实现token续签”、“your access token could not be refreshed”之类的内容，和 LLM 机制里的“Token”根本不是一回事。

LLM 的 Token 是文本切分的最小单位，是“词元”；而认证体系里的 Token（如 JWT、OAuth access token）是“令牌”，是一串用于证明身份的加密字符串。一个管“文本怎么读”，一个管“你是谁”，只在英文拼写上一样。我见过有初学者拿着 “Invalid token” 的报错，去翻 tokenizer 文档算词元用量，完全是南辕北辙。你在调用 Claude、GPT、通义等模型的 API 时如果遇到 401/403 “token 相关”报错，绝大多数是认证问题——API key 过期、密钥写错、地区限制，和模型消耗了多少词元没有任何关系。

4.2 认证Token为什么“会过期”和“要不要续签”

身份认证 Token 有过期时间是有意为之的安全设计。以 JWT 为例，它由 Header、Payload、Signature 三部分组成，Payload 里有一个 exp 字段记录了过期时间，过期之后服务端会拒绝这个 Token。你可能会想：为什么不把过期时间设得无限长？因为 Token 一旦泄露，有效期越长，攻击者可以冒用的时间窗口就越大。过期时间是一个安全与体验的折中。

实际开发里更常见的是“双 Token 方案”：一个短期有效的 access token 用于业务请求（比如几分钟到几小时），一个长期有效的 refresh token 用于在 access token 过期后换新。你在很多工具里看到的 “your access token could not be refreshed, please log out and sign in again” 就是因为 refresh token 也失效了，客户端无法静默续期，只能让用户重新登录。

处理这类问题的排查路径我踩过坑，直接列给你参考：

• 先确认报错的是 API 业务 Token 还是 OAuth 登录 Token，前者看 API key 配置，后者看登录态和 refresh 流程。
• 检查系统时间。JWT 的签发和校验依赖时间戳，客户端本地时间跑偏会导致 Token 被判过期或“未生效”。我在项目里因为服务器时间差了几分钟排查了整整一下午，最后根源只是 NTP 同步没开。
• 检查密钥和签发者配置。很多自建服务的 JWT 校验失败是签名密钥（secret）没对上，或者 issuer/audience 校验不通过。
• 看 refresh 逻辑是否有并发问题。多个请求同时用同一个 refresh token 换新，可能触发后一个请求失败。

4.3 如何低成本避免“Token”二义性坑

最好的规避办法是：在团队交流和代码注释里直接区分开。写代码时变量名不要只写 token，我习惯用 chat_tokens（词元数）、auth_token（认证令牌）或 jwt_token 做区分；读报错时先看状态码和报错来源——如果是 openai/模型网关返回的，多半和词元/限额有关；如果是登录中间件/网关注册中心返回的，先往认证方向查。

还有一个容易踩的坑：项目里同时用到了模型服务的 API key 和自己业务系统的 JWT，日志里都叫“token”。排查线上事故时，你根本分不清那句 “Invalid token” 是客户端传来的 JWT 校验失败，还是后端调大模型 API 时密钥失效。哪怕只是把日志前缀加清楚（比如 auth_token_error 和 llm_token_error），都能省下好几个小时的排查时间。这些都是我在实际运维里用头发换来的经验。

5. 实践环节：一次完整的LLM接入与省Token排错复盘

5.1 我在接入编码助手和Agent时怎么管理上下文

这两年编码助手、Agent 工具特别火（比如 Claude Code、Codex CLI 之类），它们的底层逻辑就是把你的仓库文件、终端输出、历史操作塞进上下文，然后由一个模型统一调度。我自己的经验是：这类工具好不好用，核心不在模型强不强，在它对上下文的管理策略。

第一，让模型先读索引而不是全量读代码。很多工具支持 glob 规则，可以指定哪些文件该被完整读入、哪些文件只读摘要。我一般在项目根目录配好 ignore 规则，把 node_modules、构建产物、锁文件全部排除，再把入口文件和核心业务模块设为可全量读取。这样模型每次思考时不需要把整个仓库都载入上下文，省钱又提速。

第二，任务尽量拆小。我在实际使用中发现，让 Agent 一次性“重构整个模块并写测试”几乎必然翻车，因为上下文窗口容纳不下完整需求，中间任何一步出岔子，它就开始编。更稳妥的姿势是先让它列改动计划，你确认后再逐步执行，每一步把上一步的结果作为新的上下文输入。这看起来笨，实际上是在用显式的上下文管理换取可控性，本质还是回到第2章说的上下文工程。

第三，提前想好“不输出什么”。现在一些模型会输出自己的思考过程（reasoning），这些内容同样消耗 token。如果你只需要最终答案，可以在系统提示里明确要求其直接输出结果，不需要展示分析过程。有些工具还提供 reasoning effort 这样的参数，设成 low 或 none 能显著减少隐藏 token 消耗。这一条在你用“思考链模型”做成批任务时特别重要，一来省预算，二来输出更干净。

5.2 我踩过的三个“烧Token”大坑

认真说，我见过的大多数超预算事故，不是模型太贵，而是使用姿势没对。

第一个坑：多轮对话里反复携带大历史。我早期做聊天机器人，直接把所有历史消息全部带进每次请求，用户多聊几轮就开始要破产。后来改成“滑动窗口 + 摘要”方案：保留最近 3 轮完整消息，更早的对话每隔一段时间让模型生成一段摘要，新的请求带上摘要和最近几轮。效果几乎无损，成本直降一半以上。

第二个坑：RAG 检索结果没做去重和截断。知识库的向量检索经常召回高度相似甚至完全重复的文本段，如果不加惩罚或去重逻辑，这些重复内容会全部进入上下文，白白占用 token。我现在的做法是召回后按“相似度 + 来源去重 + 长度上限”做后期过滤，设置全局的材料 token 预算（比如最多 1500 token），超过就按分数截断。

第三个坑：工具调用的“死亡循环”。有些 Agent 在调用外部工具时会出现反复调同一个工具、每次都返回同样的错误，然后一直重试的情况。每次工具调用都要消耗一次模型请求的 token，几分钟烧掉几千上万 token 是很正常的。解决办法有两个：一是给 Agent 的循环设置最大步数，二是把工具的输入输出摘要化——例如工具返回一个 5000 行的 JSON，先让它摘要成 500 字，再丢给下游步骤。后者能砍掉大量的隐性 token。

5.3 处理“输出被截断”与“上下文超限”的通用兜底方案

最后分享一个我沉淀出来的通用兜底流程，不管你是用官方的聊天网页，还是自己的代码调用 API，都是同一个思路：

• 发请求前先估算 token。用对应模型的 tokenizer 把 prompt 跑一遍，超过窗口的 80% 就触发压缩流程：缩系统提示词、裁剪历史记录、或要求用户改传摘要。
• 生成之后检查 finish_reason。如果是 length，说明是输出截断而不是正常结束。此时把这段输出追加到消息历史里，发一条“继续”或直接让它“从刚才中断的地方继续输出”，就能把剩余内容补回来。
• 如果下次请求时发现整体仍然超限，优先丢历史，而不是丢当前输出。因为已经生成出来的内容是你最需要保住的，而相对陈旧的历史记忆可以通过摘要替代。

这个流程一开始需要写一点代码，但跑通之后就是“一劳永逸”的兜底。它能够覆盖大部分常见的上下文超限和输出截断问题，也顺带控制了 token 成本。

我在把这个流程应用到自己项目里之后，最明显的变化不是省了多少钱，而是用户不再隔三差五反馈“回答到一半就断了”。说到底，LLM 的 Token、上下文、采样参数这些机制并不复杂，复杂的是它们在不同场景下互相牵制。把这几条主线捋清楚，后面遇到任何新模型、新工具、新框架，你都能很快抓住重点、定位问题，而不是在报错信息里瞎转。