先坦白一个事儿我最早做 LLM 应用时最懵的不是提示词也不是模型选型而是一堆看着眼熟的术语——Token、上下文、温度。明明每个词单独看都认识连在一起却搞不清它们怎么影响模型输出。更尴尬的是我曾在群里看到有人报了这么个错“Invalid token”然后在文档里翻“一个中文等于多少 token”翻了一下午也没解决因为那根本不是同一个“token”。这就是我想写这篇拆解的原因。模型不神秘它的运行机制说到底就三根支柱输入怎么被切分Token、模型能记住多少上下文、输出怎么变得“像人话”采样参数。把它们全部理解透了无论是做 RAG、写 Agent、还是只是在 Cursor 或 Claude Code 里省点额度你都比 90% 的“会用”的人强。我尽量用交流和踩坑的口吻写不堆术语但该深的地方也得挖到根上。1. TokenLLM的输入货币与文本切分逻辑1.1 为什么是“Token”而不是“字”或“词”先解决最基础的问题模型读入的不是文字而是数字。任何 Transformer 架构的语言模型第一步都是把文本映射成一个整数序列这些整数再查表得到向量。Token 就是“文本切分的最小单位”它既不是字母也不完全是词而是介于两者之间的一种子词单元。主流模型用的切分算法叫 BPEByte Pair Encoding字节对编码核心思路很直白先按单个字符或字节拆然后反复统计文本里出现频率最高的相邻字符对把它们合并成一个新符号直到达到预设的词表大小。举个例子单词 “lower” 可能不用拆但 “lowest” 会被切成 “low” “est”。这样做的妙处是常见词用一个 token 搞定罕见词拆成若干子词也能拼出来词表大小可以控制在几万到十几万既不会因为词表太大撑爆显存也不会因为不认识生词直接摆烂。你可以把 BPE 理解成乐高每个 token 是一块积木词频高的积木块大一点生僻的积木块小一点但它一定能拼出你想表达的东西。这也是为什么模型能处理拼写错误、自创词、混合语言——因为它在字符和词之间的粒度上做匹配而不是死记硬背一个固定词表。1.2 Token与计费、限额、性能的真实关系理解 token 之后你才算真正看懂了 LLM 的计价器和限速器。各家 API 的计费单位无一例外是“每百万 token 多少钱”不是按字符不是按请求次数而是按模型真正“读入写出”的 token 总量。也就是说同样的需求不同语言、不同表达方式花的钱可以差很多。我给你一个非常直观的量级感受以典型中英文文本近似估算文本类型Token 消耗量约1 个英文字母0.25 ~ 0.3 token约4个字母一个 token1 个英文单词1 ~ 2 token1 个汉字1.5 ~ 2.5 token常见中文一句话约十几到几十 token1 段标准 Python 代码50行150 ~ 300 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 CacheToken 是输入的基本单位上下文窗口就是模型“一回合里能看到的 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 是聪明还是像个失忆的金鱼。我的经验可以浓缩成三条原则越靠近末尾的信息越重要。很多模型对中间部分的注意力权重会降低这是注意力机制在长序列下的通病。所以关键指令、核心问题要放在 prompt 的后面背景资料放在前面。系统提示词要精简到“只讲原则不讲细节”。常见错误是系统提示词写了上千字把范例、禁忌、格式说明全堆进去挤占了宝贵的上下文空间。实际上系统提示词更适合放你是谁、目标是什么、输出格式是什么、绝对不能做什么。历史对话要压缩或摘要。多轮对话场景里你可以定期把前面的对话交给模型浓缩成一段摘要然后只保留最近两三轮的完整对话和那份摘要。这样既保住了上下文连贯性又不会让历史记录无限膨胀。这本质上是用一层“摘要缓存”换 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.2logits 被放大本来概率高的 token 变得更高概率低的基本没戏输出更确定、更保守。温度 1.0如 1.5logits 被压缩概率高的 token 和概率低的 token 之间的差距变小低概率 token 更容易被选中输出更多样、更大胆。用人话说温度像是一个“hype 程度调节器”。温度低模型像一个严谨的秘书怎么稳妥怎么写温度高模型像一个头脑风暴的创意者什么离谱词都敢蹦。这也就是为什么热词里“大模型能力边界幻觉、上下文、温度”会被并排提及——温度调高就是这样幻觉概率会显著上升因为那些原本概率很低的“编造项”被抬上了台面有机会被选中了。场景推荐温度原因代码生成0 ~ 0.3代码需要确定性牵一发动全身JSON/结构化输出0 ~ 0.2格式错了下游代码直接崩文案改写/翻译0.3 ~ 0.7保持基本语义又保留表达余地头脑风暴/故事创作0.8 ~ 1.2需要多样性和跳跃性广告文案/创意生成1.0 ~ 1.4越意想不到越有效3.3 Top-P、Top-K与重复惩罚把输出拉到“合理范围”温度负责改变概率分布的“形状”但还漏了一个问题有些低概率 token 被抬起来后可能产生语法错误、逻辑断裂甚至胡言乱语。这时候就需要 Top-P 和 Top-K 这种“过滤器”。Top-K 是一个简单粗暴的截断只从概率最高的 K 个 token 里选K 之外的一律不参与采样。比如 Top-K50就相当于强行让模型在“最可能成为下一个词的 50 个候选”里做选择。缺点是 K 是固定值不同上下文里合理候选数量其实不一样所以很多人更爱用 Top-P。Top-P也叫核采样nucleus sampling逻辑是动态的从概率最高的 token 开始往下一个一个累加直到累计概率达到你设定的阈值 P然后把所有没加进来的低概率 token 全部踢掉再从剩下的候选里按比例采样。比如 P0.9意味着模型会“覆盖至少 90% 的概率质量”剩下的尾部 10% 全不要。这样在预测明确的时候候选项很少很确定在预测模糊的时候候选项多有发挥空间。它比 Top-K 更聪明的地方在于候选数量是随上下文变化的不是一刀切。还有一个容易被忽略的“重复惩罚”参数frequency penalty / presence penalty。它会在每生成一个 token 时对已经出现过的 token 的概率做一次惩罚防止模型陷入重复循环。做长文本生成时如果模型开始“车轱辘话来回说”多半就是这两个参数没调好。总结一下三个参数的定位对比参数作用位置一句话理解temperature概率分布缩放控制“胆量”top_p候选集合过滤控制“视野范围”frequency/presence penalty生成后动态调整控制“复读机倾向”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、上下文、采样参数这些机制并不复杂复杂的是它们在不同场景下互相牵制。把这几条主线捋清楚后面遇到任何新模型、新工具、新框架你都能很快抓住重点、定位问题而不是在报错信息里瞎转。