开头经常有读者在后台问我LLM 到底是怎么“读懂”我输入的那段话的为什么我多问几句它的回答就变飘了为什么有人说“上下文塞太满会爆”背后到底爆的是什么我一般会把问题拆成三件事讲Token、上下文窗口、采样参数。这三者构成了所有大语言模型运行机制的底层骨架也是你排查一切 LLM 使用困惑——比如输出被截断、回答文不对题、越聊越傻、API 账单莫名飙升——时最先要检查的三个地方。这篇文章我会用一篇完整的长文把这三块彻底拆开每一块都讲清楚“它是什么、底层怎么运作、实际使用中最容易踩什么坑”最后再给一套我自己实测过的参数配置建议和问题排查表。不管你是刚开始用 ChatGPT/Claude 的普通用户还是在自己接 API 做应用开发的工程师这篇文章都能帮你省下大量试错时间。1. Token为什么它是计费单位也是“理解”的最小颗粒1.1 语言模型不识字只认数字要理解 Token你先得接受一个事实大语言模型并不像人一样“读字”。它接收和输出的全部内容本质上都是数字序列。那文字怎么变成数字中间这层转换就是 Token 化Tokenization。Token 可以粗略理解成“把一段文本切成若干个小块每个小块对应一个唯一 ID”。这个 ID 就是模型词汇表Vocabulary里的一个编号。比如英文单词the可能是一个 Token中文的“深”可能是一个 Token“度”又是一个 Token。模型处理文本时实际上是在处理一串 Token ID——你可以把它想象成把一整篇文章拆成了乐高积木里的一个个标准颗粒模型学的就是这些颗粒之间的排列规律和组合概率。这里有个容易误解的地方Token 不是“词语”也不完全是“字”。它是一种分词算法切出来的结果边界由词频和字节组合决定。同一个句子用不同的分词器Tokenizer切得到的结果可能完全不一样。目前主流模型用的基本都是 BPEByte Pair Encoding字节对编码或其变体核心逻辑就是从字节级别开始反复合并出现频率最高的相邻片段最后形成一个词表。1.2 中英文 Token 消耗差异为什么中文“更贵”很多刚接触 API 的同学会有一个疑惑为什么同样意思的一句话用中文问比用英文问消耗的 Token 数要多这不是心理作用而是分词器的真实行为。原因很简单绝大多数模型的词表是以英文为主构建的英文单词在 BPE 合并中能形成大量高频完整词块一个 Token 往往就能覆盖一个常见单词比如token、model、context都是一整个 Token。但中文没有天然空格分词分词器在处理中文时绝大多数单字只能独立成 Token高频双字词有时能合并成一个但整体而言平均一个汉字大约要消耗 0.6 到 1 个 Token——也就是说一句 100 个汉字的句子消耗的 Token 数量往往多于同样信息量的英文句子。这对开发者的直接影响是在做 API 计费预估和成本优化时不能按“字数”去估算必须按 Token 数估算。我在实际项目中习惯的做法是在代码里缓存一份tiktoken或对应模型的分词器离线表每次请求前先对本轮要发送的内容做一次本地计数这样既能做成本预警也能提前发现“会不会超过上下文限制”。这个习惯帮我省下的冤枉钱保守估计也有几千块了。1.3 token 失效、token 用量、token 上限三种“token”别混淆搜索热词里反复出现“token 失效”“token 用量”“已达到输出 token 上限”“token exchange failed”这类说法。这里其实混了三件完全不同的东西我一次性帮大家理清第一是语言模型 Token就是上面说的文本最小单元它是模型计费和上下文长度计算的单位。第二是接口鉴权 Token比如你调用某个 API 时拿到的 Access Token、JWT或者登录时返回的会话 Token。这类 Token 是字符串凭证用于身份验证和权限控制跟模型本身一毛钱关系都没有。你在各种工具里遇到的 “sign-in could not be completed: token exchange failed”“your access token could not be refreshed”说的都是这类鉴权凭证失效或刷新失败对应的解决方式是重新登录、检查 API Key 权限、刷新凭证而不是去调模型参数。第三是输出上限max_tokens。这是模型生成回答时的最大 Token 数限制。后面讲采样参数的时候我会专门展开。把这三者分开你排查问题时就能少走 70% 的弯路。很多人一看报错带 “token” 两个字就跑去改模型的 temperature 参数这完全是在错误的方向上使劲。1.4 控制 Token 用量的几个实操技巧既然 Token 直接等于钱也有很多人问“AI 编码如何指定上下文了”“Claude Code 如何用省 Token”我分享几个亲测有效的做法压缩历史记录不是每次请求都把全部对话历史发过去。对一段超过 N 轮的对话我会用“摘要最近几轮原文”的结构替代完整历史相当于让模型记笔记而不是每次重读整本小说。这一步能把长对话的 Token 消耗降低 40% 到 60%。精简系统提示词系统提示词每请求都会重复计费精炼表达、去掉冗余修饰能实打实省钱。一句话能说清楚的要求不要写满半屏。善用结构化输入用 Markdown 或 JSON 格式组织内容让模型更快理解你的意图减少因误解导致的反复追问和重试。按需设置 max_tokens如果只需要模型输出几个关键词或代码片段就把输出上限设小一点防止它“自由发挥”写篇小作文白白烧掉额外 Token。2. 上下文窗口模型的“工作记忆”与它的物理边界2.1 什么是上下文窗口为什么它会影响回答质量上下文窗口Context Window指的是模型在处理一次请求时最多能“同时看到”的 Token 数量。它相当于模型的工作记忆空间既包括你输入的提示词、历史对话、参考文档也包括模型正在生成的回答。如果说 Token 是模型理解世界的“词汇颗粒”上下文窗口就是模型在特定时刻能摆在桌面上的所有卡片数量。桌面就这么大能摆的卡片有上限一旦超出模型就必须丢弃或忽略一些卡片。这里有一个重要的认知模型的“长期记忆”并不存在。它每次回答都只基于这次请求送入上下文窗口的内容。关掉对话窗口之后模型不会记得你除非你每次把需要它记住的信息重新放进上下文里。这也是为什么很多人觉得“同一个问题换个新对话问模型就变傻了”——不是模型变了而是上下文里没有承载之前对话的信息。上下文窗口为什么是个硬限制因为 Transformer 架构的核心是注意力机制Attention它需要计算输入序列中任意两个 Token 之间的关系。这个计算量随序列长度呈平方级增长。窗口越长显存占用和计算延迟都急剧上升。所以厂商在模型设计和部署时会对上下文长度做一个明确的硬边界比如 128K、200K 等。2.2 超过上下文限制到底会发生什么四种后果很多人搜“Claude 超过上下文限制会怎么样”我来系统说清楚。不同产品对超限的处理方式不一样但底层逃不出四种情况直接报错API 请求返回错误提示输入超过上下文限制。这是最“干净”的失败方式至少你知道原因了。自动截断有些应用会静默丢弃对话历史中最旧的内容只保留最近的部分。后果是模型“失忆”忘了你最开始提的需求回答变得莫名其妙。回答截断模型正在生成时达到输出 Token 上限回答中断在半句话上。很多产品会提示“已达到输出 token 上限回答被截断发送‘继续’可让模型接续”。这说明前面的输入已经占用了大量窗口留给输出的空间不够了。成本飙升后失败部分系统在超限时自动丢弃中间内容但保留首尾比如保留系统提示词和最近对话通过摘要压缩来硬塞进窗口但这通常意味着你要额外付出摘要生成的 Token 成本。我在本地跑开源模型时最常遇到的是第二种和第三种。尤其在用长文档做问答时如果把十几页文档一次性塞进上下文模型要么报错要么生成到一半就断了。后来我给自己定了一条红线输入内容不要超过上下文窗口的三分之一。留出足够空间给模型输出和推理回答质量会稳定很多。2.3 上下文工程比“调参”更值得投入的方向最近有一个词很火叫“上下文工程”Context Engineering。热词里也有“上下文建设 亮点”“上下文数据流图的分解”等说法。在我看来上下文工程不是玄学而是研究如何把有限上下文窗口的价值发挥到最大——在窗口受限的前提下哪些信息该放进去、以什么顺序放、用什么格式放直接决定模型输出的上限。这个方向最常见的落地方式是 RAG检索增强生成。原理不复杂你有一个很大的知识库但不可能全部塞进上下文于是先根据用户问题做一次检索只把最相关的几段内容拿出来拼到提示词里再把拼好的内容送给模型。这样既绕开了上下文窗口的限制又让模型“基于资料回答”显著减少幻觉。我做过一个内部知识库问答系统最初就是一股脑把所有相关文档拼接起来送进模型结果上下文频繁超限回答质量也差。后来改成 RAG 流程先向量检索 Top 5 相关片段每段控制在 500 字以内拼完后整体不超过 3000 Token。同样的知识库回答准确率肉眼可见地提升了上下文超限的报错也几乎绝迹。另一个被低估的上下文工程技巧是信息顺序。模型对上下文不同位置的敏感度不一样开头primacy effect和结尾recency effect的信息更容易被模型记住中间部分容易被忽略。我习惯把最关键的要求放在系统提示词里反复强调把最新指令放在用户消息末尾长文档只取核心段落放在中间偏后位置。这个细节在长文档问答场景下提升效果相当明显。2.4 AI 编码场景下怎么“给上下文”才省力又有效热词里有一类高频问题“Cursor 怎么把上下文给到 AI”“AI 编码如何指定上下文”。做 AI 辅助编程的同学应该都有体会代码文件越长越容易把不相关的代码塞给模型既浪费 Token 又稀释注意力。我的经验是显式圈定上下文而不是把整个仓库交给 AI。在 Cursor、Claude Code、Codex CLI 这类工具里尽量不要用那种“自动获取全部文件”的模式而是手动指定当前任务涉及的文件、函数或类。比如你要改某个模块的接口就把这个接口的定义、调用它的几个关键位置、对应的测试用例给到模型其他无关模块一概不写进上下文。还有个不少人忽略的点让模型先输出“对问题的理解”再输出代码。这在编码场景中特别有用。你可以要求模型先把任务拆解成要点、列出改动文件清单确认无误后再生成具体实现。这本质上是在上下文里建立“共识区”避免模型越过需求直接写代码导致方向跑偏。这个习惯也帮我在代码评审时省了大量返工时间。3. 采样参数决定模型“性格”的旋钮3.1 从概率到文本模型是怎么“选”下一个词的前面讲了模型如何把文本变成 Token但模型真正神奇的地方在于它能预测下一个 Token 是什么。具体来说模型会根据当前上下文为词表中的每个 Token 计算一个分数Logits再通过 Softmax 函数转成概率分布。然后在这个概率分布上用不同的策略选出“下一个 Token”。这里的关键是模型天然不是一个“只会选最大概率”的机器。它在概率分布上做“采样”也就是带有一定随机性。采样参数就是控制这个随机性方式和强度的旋钮。我常用一个比喻模型像一个知识渊博但有点选择困难症的人。如果让他每次都说最标准、最保险的答案他会比较无聊如果给他一点自由发挥的空间他可能会说出很有创意的观点但也可能跑题。采样参数就是用来调节他“无聊”和“跑题”之间平衡的。3.2 核心采样参数逐个拆解temperature、top_p、top_k、惩罚项这一节是很多人“调了半天参数没感觉”的重灾区。我给每个参数一个清晰的定义附上使用建议。temperature温度最核心的随机性参数取值范围通常是 0 到 2。温度越低概率分布越尖锐模型越倾向选高概率 Token温度越高低概率 Token 也有机会被选中输出更多样、更有“创造力”。数学上它是把 Logits 除以温度值后再做 Softmax。当 temperature0 时概率分布尖锐到极限模型每次都选最高概率的 Token输出几乎完全确定。经验值需要稳定事实回答的场景用 0 到 0.3创意写作、头脑风暴用 0.7 到 1.0再高就容易胡言乱语了。top_k只从概率最高的前 K 个 Token 里采样其余全部排除。比如 top_k50就是先把概率排前 50 的 Token 挑出来再按各自概率采样。它的作用是防止模型偶尔抽中一个概率极低的冷门 Token。实际操作中top_k 通常设 40 到 50 是比较稳的区间。太小的 top_k 会让输出变得保守太大则失去了限制的意义。top_p核采样从累计概率超过 p 的最小 Token 集合里采样。比如 top_p0.9就把概率从高到低累加直到累加值超过 0.9然后在这一组 Token 中采样。它的逻辑是“只在高概率的候选里做选择”比 top_k 更动态因为候选数量会随概率分布的形状变化。标准做法是top_p 和 temperature 只调其中一个不要两个同时大幅调整否则容易互相打架输出变得难以控制。frequency_penalty频率惩罚对已经出现过的 Token 施加减分出现次数越多分越低从而降低模型重复同一词汇的概率。适合需要减少复读机效果的场景。范围通常是 -2 到 2正值代表惩罚重复负值反而鼓励重复。我一般设 0.3 到 0.6 就够用了太大会让句子变得生硬不连贯。presence_penalty存在性惩罚只要某个 Token 出现过就给一次固定减分跟出现次数无关。作用是鼓励模型谈论新话题、引入新概念。它和 frequency_penalty 的差别在于frequency 惩罚“反复说”presence 惩罚“说过就减分”。两者可以同时使用但要注意整体输出风格的变化。3.3 为什么模型“有幻觉”采样参数和幻觉得关系热词里有一条“大模型能力边界幻觉、上下文、温度”直接把幻觉和温度并列很有洞察。幻觉的本质原因很复杂包括训练数据噪声、模型压缩、知识截止日期等但采样参数是幻觉的直接触发器之一——如果你把 temperature 调得过高模型就会在低概率 Token 上“放飞自我”一本正经地编造事实。我在实际测试中遇到过非常典型的例子用同一个事实类问题分别测试 temperature0.1 和 temperature0.9前者回答准确率在 9 成以上后者虽然偶尔有惊艳表达但错误率也明显上升。如果你在做客服问答、知识库问答这类对准确性要求极高的场景我的建议是 temperature 不要超过 0.3最好在 0.1 到 0.2 之间。但有一点要提醒temperature0 并不能完全消除幻觉。因为模型“知道什么”和“确认什么”在训练时就固定了采样参数只是决定它能否说出不那么确定的内容。就算设置为 0模型也可能在知识盲区上编一个听起来合理的答案。要真正减少幻觉必须回到上下文工程——给它可靠的参考资料让它在有限范围内作答。3.4 “让模型不输出思考过程”这个需求怎么用参数满足热词里有一条“dify llm 怎么让模型不输出思考过程”这也是很多人问过的。首先要分清模型是否真的“会思考再输出”。现在很多推理模型比如带 reasoning 能力的模型默认会在回答前输出一段内部推理过程这在某些产品里是显式的会出现在界面上占用你的输出 Token。怎么让它不输出思考过程没有单一的采样参数能完全开关这个行为但我有几个亲测有效的方法一是修改系统提示词明确要求“只输出最终答案不要展示推理步骤不要解释过程”。多数模型会听话省掉那部分冗长的思考文本。二是在 API 层面关闭推理输出。不少平台提供reasoning或thinking相关开关把详细推理内容关掉只保留最终结果。如果你用的是这类能力优先找这个开关而不是调 temperature。三是把输出上限调低。如果模型的思考过程很长而你把 max_tokens 设置得较小推理过程就可能被截断最终答案自然变短。这个方法比较粗暴不推荐因为它可能让最终答案也一起被砍掉。四是换用非推理模型。如果你的任务不需要复杂推理只是想快速拿到答案直接选用不带推理能力的模型反而响应更快、成本更低。不要什么任务都上最强模型。3.5 max_tokens 与输出截断的实战经验“已达到输出 token 上限回答被截断”这个问题我估计被它坑过的人不在少数。要解决它得先搞清楚上下文窗口 输入 Token 输出 Token。当你请求时系统会预留出 max_tokens 这个输出额度剩下的才给输入用。如果输入太长留给输出的空间自然就少了。我踩过的一个具体坑是在一个长文档问答系统里用户上传一篇 5000 Token 的文档我把 max_tokens 设成 2000上下文窗口是 8000看起来没问题。但系统提示词、对话历史、检索结果加起来其实已经超过 6000 Token实际留给输出的只有不到 2000而模型生成到一半就到达上限回答被截断。后来我做了两道防线一是在发送前计算整个输入的长度如果接近上限就自动压缩历史或提示用户二是把 max_tokens 根据任务类型动态设置——摘要类任务给 1500 到 2000选择题给 200 到 500代码生成给 2000 以上。另一个技巧是遇到模型回答到一半断了不要重新问一遍直接发“继续”或“接着上文继续”让模型接着已有的回答继续生成。这也是热词里“发送‘继续’可让模型接续”的用法来源。但要注意“继续”也占用上下文和输出额度如果输入已经把窗口占满了继续也救不回来这时候只能先精简输入或手动拆分任务。4. 三者联动从一次生成事故看参数协作与排查思路4.1 一个真实的失败案例复盘今年早些时候我帮朋友排查一个 AI 写作助手的问题用户上传一篇约 1 万字的营销长文要求模型“改写成更有吸引力的版本”结果模型频繁报错偶尔成功但输出质量也很差。我打开日志一看问题一目了然整个请求的输入 Token 已经接近 1.5 万而上下文窗口是 8000系统自动截断了文档开头部分同时 temperature 被前端写死成 0.95为了“更有创意”导致模型在信息不全的情况下高随机性地发挥max_tokens 设的是 4096窗口又不够用经常生成一半就被截断。三个参数同时出问题结果就是输入被截断→模型看不到全文→高温度放飞自我→输出又被截断。用户看到的就是“报错答非所问生硬结尾”的三连击。修复方案也简单把文档拆分成长文分段改写每次只处理 3000 字左右temperature 从 0.95 降到 0.7max_tokens 设置为 1500让每次输出都能完整包含改写结果和必要的上下文总结。改完之后同样一篇长文处理时间变短了输出质量也稳定了。这个案例说明了一个重要原则Token、上下文、采样参数不是三个独立旋钮它们是一条生产链上的三个环节。任何一个环节出问题都可能让整体效果崩掉。4.2 常见问题速查表一图定位问题源头很多人来问我“为什么我的模型回答越聊越笨”时我给的排查思路就是先查这三个维度。整理成一个速查表方便你对照自己的情况快速定位现象最先排查的环节常见原因解决思路回答中断、半截话上下文窗口max_tokens输入太长挤占输出空间max_tokens 设太小压缩输入、降低文档长度、动态调整 max_tokens上下文报错超限上下文窗口输入超过模型硬限制精简提示词、做历史摘要、改用 RAG 检索回答越来越笨、前后矛盾Token 消耗上下文窗口历史对话被截断模型“失忆”缩短对话轮次、保留最近关键信息、每轮重建上下文天马行空、胡说八道采样参数temperature 过高降到 0.1 到 0.3或在接入层开启检索引用输出重复、复读机采样参数缺少频率惩罚temperature 过低加 frequency_penalty 0.3 到 0.6适当提高 temperature输出保守、缺乏创意采样参数temperature 过低适中调高到 0.7 到 1.0注意配合 top_pAPI 报错 token 失效/未授权接口鉴权凭证过期、权限不足重新登录、刷新 token、检查 API Key 权限账单费用超标Token 用量发送大量冗余内容、超长历史、高 max_tokens精简每次请求、启用上下文压缩、缓存响应你在排查时可以按“先查上下文窗口是否充足→再查采样参数是否合理→最后查接口鉴权和配额”这个顺序来。90% 的异常都能在第三步之前解决。4.3 一套可以直接抄的 LLM 应用参数配置最后分享一套我在多个实际项目中验证过的配置模板覆盖几类最常见的任务。注意这是起点不是终点具体到你的场景还需要微调。任务类型temperaturetop_ptop_kfrequency_penaltymax_tokens关键上下文策略知识库问答RAG0.10.3400.0500-1000只送入检索到的 Top 5 段落创意写作/头脑风暴0.90.9500.41500-3000提供写作方向示例不设限代码生成0.20.5400.02000明确函数签名、输入输出、约束条件摘要总结0.30.6450.3800-1500传入全文或拆分分批摘要客服对话0.20.4400.5500保留最近 5 轮对话用户订单信息翻译0.10.3400.01000-2000保留原文和被翻译的部分提供术语表这套模板的关键思路是事实类任务温度低创意类任务温度高输出长度按任务实际需要而不是越大越好。至于 top_k 和 top_p我建议新手先用 top_p 就够了top_k 作为辅助微调手段不要一上来两个参数都乱动。4.4 优化收益最大化的个人心得把“每次请求”当一份精心准备的简报踩过足够多的坑之后我发现真正拉开使用效果差距的往往不是选哪款模型或调哪个参数而是一个视角的转变把每次发给模型的请求当成一份给高管的简报——信息经过筛选、按优先级排序、控制篇幅、目标明确。这意味着你在写提示词时要想清楚几个问题模型需要哪些信息才能完成这个任务这些信息以什么顺序给最不容易被忽略哪些信息其实是干扰项可以省略执行标准应该用多少 token 能说清当你的思维从“我要把能想到的都告诉模型”转变成“我要让模型在有限上下文里最高效地完成任务”Token 成本、上下文超限、输出截断这些问题都会自动缓解。另外我始终建议你在本地维护一份自己的“提示词模板库”和“参数配置记录”。每次测试完一组任务就把用的参数、输入长度、输出质量、成本记下来。积累一段时间后你会形成一套属于自己的“手感”到那时再回头看什么 temperature、top_p它们不再是抽象的概念而是你手里的工具。 一文搞懂LLM三大核心：Token、上下文窗口与采样参数
开头经常有读者在后台问我LLM 到底是怎么“读懂”我输入的那段话的为什么我多问几句它的回答就变飘了为什么有人说“上下文塞太满会爆”背后到底爆的是什么我一般会把问题拆成三件事讲Token、上下文窗口、采样参数。这三者构成了所有大语言模型运行机制的底层骨架也是你排查一切 LLM 使用困惑——比如输出被截断、回答文不对题、越聊越傻、API 账单莫名飙升——时最先要检查的三个地方。这篇文章我会用一篇完整的长文把这三块彻底拆开每一块都讲清楚“它是什么、底层怎么运作、实际使用中最容易踩什么坑”最后再给一套我自己实测过的参数配置建议和问题排查表。不管你是刚开始用 ChatGPT/Claude 的普通用户还是在自己接 API 做应用开发的工程师这篇文章都能帮你省下大量试错时间。1. Token为什么它是计费单位也是“理解”的最小颗粒1.1 语言模型不识字只认数字要理解 Token你先得接受一个事实大语言模型并不像人一样“读字”。它接收和输出的全部内容本质上都是数字序列。那文字怎么变成数字中间这层转换就是 Token 化Tokenization。Token 可以粗略理解成“把一段文本切成若干个小块每个小块对应一个唯一 ID”。这个 ID 就是模型词汇表Vocabulary里的一个编号。比如英文单词the可能是一个 Token中文的“深”可能是一个 Token“度”又是一个 Token。模型处理文本时实际上是在处理一串 Token ID——你可以把它想象成把一整篇文章拆成了乐高积木里的一个个标准颗粒模型学的就是这些颗粒之间的排列规律和组合概率。这里有个容易误解的地方Token 不是“词语”也不完全是“字”。它是一种分词算法切出来的结果边界由词频和字节组合决定。同一个句子用不同的分词器Tokenizer切得到的结果可能完全不一样。目前主流模型用的基本都是 BPEByte Pair Encoding字节对编码或其变体核心逻辑就是从字节级别开始反复合并出现频率最高的相邻片段最后形成一个词表。1.2 中英文 Token 消耗差异为什么中文“更贵”很多刚接触 API 的同学会有一个疑惑为什么同样意思的一句话用中文问比用英文问消耗的 Token 数要多这不是心理作用而是分词器的真实行为。原因很简单绝大多数模型的词表是以英文为主构建的英文单词在 BPE 合并中能形成大量高频完整词块一个 Token 往往就能覆盖一个常见单词比如token、model、context都是一整个 Token。但中文没有天然空格分词分词器在处理中文时绝大多数单字只能独立成 Token高频双字词有时能合并成一个但整体而言平均一个汉字大约要消耗 0.6 到 1 个 Token——也就是说一句 100 个汉字的句子消耗的 Token 数量往往多于同样信息量的英文句子。这对开发者的直接影响是在做 API 计费预估和成本优化时不能按“字数”去估算必须按 Token 数估算。我在实际项目中习惯的做法是在代码里缓存一份tiktoken或对应模型的分词器离线表每次请求前先对本轮要发送的内容做一次本地计数这样既能做成本预警也能提前发现“会不会超过上下文限制”。这个习惯帮我省下的冤枉钱保守估计也有几千块了。1.3 token 失效、token 用量、token 上限三种“token”别混淆搜索热词里反复出现“token 失效”“token 用量”“已达到输出 token 上限”“token exchange failed”这类说法。这里其实混了三件完全不同的东西我一次性帮大家理清第一是语言模型 Token就是上面说的文本最小单元它是模型计费和上下文长度计算的单位。第二是接口鉴权 Token比如你调用某个 API 时拿到的 Access Token、JWT或者登录时返回的会话 Token。这类 Token 是字符串凭证用于身份验证和权限控制跟模型本身一毛钱关系都没有。你在各种工具里遇到的 “sign-in could not be completed: token exchange failed”“your access token could not be refreshed”说的都是这类鉴权凭证失效或刷新失败对应的解决方式是重新登录、检查 API Key 权限、刷新凭证而不是去调模型参数。第三是输出上限max_tokens。这是模型生成回答时的最大 Token 数限制。后面讲采样参数的时候我会专门展开。把这三者分开你排查问题时就能少走 70% 的弯路。很多人一看报错带 “token” 两个字就跑去改模型的 temperature 参数这完全是在错误的方向上使劲。1.4 控制 Token 用量的几个实操技巧既然 Token 直接等于钱也有很多人问“AI 编码如何指定上下文了”“Claude Code 如何用省 Token”我分享几个亲测有效的做法压缩历史记录不是每次请求都把全部对话历史发过去。对一段超过 N 轮的对话我会用“摘要最近几轮原文”的结构替代完整历史相当于让模型记笔记而不是每次重读整本小说。这一步能把长对话的 Token 消耗降低 40% 到 60%。精简系统提示词系统提示词每请求都会重复计费精炼表达、去掉冗余修饰能实打实省钱。一句话能说清楚的要求不要写满半屏。善用结构化输入用 Markdown 或 JSON 格式组织内容让模型更快理解你的意图减少因误解导致的反复追问和重试。按需设置 max_tokens如果只需要模型输出几个关键词或代码片段就把输出上限设小一点防止它“自由发挥”写篇小作文白白烧掉额外 Token。2. 上下文窗口模型的“工作记忆”与它的物理边界2.1 什么是上下文窗口为什么它会影响回答质量上下文窗口Context Window指的是模型在处理一次请求时最多能“同时看到”的 Token 数量。它相当于模型的工作记忆空间既包括你输入的提示词、历史对话、参考文档也包括模型正在生成的回答。如果说 Token 是模型理解世界的“词汇颗粒”上下文窗口就是模型在特定时刻能摆在桌面上的所有卡片数量。桌面就这么大能摆的卡片有上限一旦超出模型就必须丢弃或忽略一些卡片。这里有一个重要的认知模型的“长期记忆”并不存在。它每次回答都只基于这次请求送入上下文窗口的内容。关掉对话窗口之后模型不会记得你除非你每次把需要它记住的信息重新放进上下文里。这也是为什么很多人觉得“同一个问题换个新对话问模型就变傻了”——不是模型变了而是上下文里没有承载之前对话的信息。上下文窗口为什么是个硬限制因为 Transformer 架构的核心是注意力机制Attention它需要计算输入序列中任意两个 Token 之间的关系。这个计算量随序列长度呈平方级增长。窗口越长显存占用和计算延迟都急剧上升。所以厂商在模型设计和部署时会对上下文长度做一个明确的硬边界比如 128K、200K 等。2.2 超过上下文限制到底会发生什么四种后果很多人搜“Claude 超过上下文限制会怎么样”我来系统说清楚。不同产品对超限的处理方式不一样但底层逃不出四种情况直接报错API 请求返回错误提示输入超过上下文限制。这是最“干净”的失败方式至少你知道原因了。自动截断有些应用会静默丢弃对话历史中最旧的内容只保留最近的部分。后果是模型“失忆”忘了你最开始提的需求回答变得莫名其妙。回答截断模型正在生成时达到输出 Token 上限回答中断在半句话上。很多产品会提示“已达到输出 token 上限回答被截断发送‘继续’可让模型接续”。这说明前面的输入已经占用了大量窗口留给输出的空间不够了。成本飙升后失败部分系统在超限时自动丢弃中间内容但保留首尾比如保留系统提示词和最近对话通过摘要压缩来硬塞进窗口但这通常意味着你要额外付出摘要生成的 Token 成本。我在本地跑开源模型时最常遇到的是第二种和第三种。尤其在用长文档做问答时如果把十几页文档一次性塞进上下文模型要么报错要么生成到一半就断了。后来我给自己定了一条红线输入内容不要超过上下文窗口的三分之一。留出足够空间给模型输出和推理回答质量会稳定很多。2.3 上下文工程比“调参”更值得投入的方向最近有一个词很火叫“上下文工程”Context Engineering。热词里也有“上下文建设 亮点”“上下文数据流图的分解”等说法。在我看来上下文工程不是玄学而是研究如何把有限上下文窗口的价值发挥到最大——在窗口受限的前提下哪些信息该放进去、以什么顺序放、用什么格式放直接决定模型输出的上限。这个方向最常见的落地方式是 RAG检索增强生成。原理不复杂你有一个很大的知识库但不可能全部塞进上下文于是先根据用户问题做一次检索只把最相关的几段内容拿出来拼到提示词里再把拼好的内容送给模型。这样既绕开了上下文窗口的限制又让模型“基于资料回答”显著减少幻觉。我做过一个内部知识库问答系统最初就是一股脑把所有相关文档拼接起来送进模型结果上下文频繁超限回答质量也差。后来改成 RAG 流程先向量检索 Top 5 相关片段每段控制在 500 字以内拼完后整体不超过 3000 Token。同样的知识库回答准确率肉眼可见地提升了上下文超限的报错也几乎绝迹。另一个被低估的上下文工程技巧是信息顺序。模型对上下文不同位置的敏感度不一样开头primacy effect和结尾recency effect的信息更容易被模型记住中间部分容易被忽略。我习惯把最关键的要求放在系统提示词里反复强调把最新指令放在用户消息末尾长文档只取核心段落放在中间偏后位置。这个细节在长文档问答场景下提升效果相当明显。2.4 AI 编码场景下怎么“给上下文”才省力又有效热词里有一类高频问题“Cursor 怎么把上下文给到 AI”“AI 编码如何指定上下文”。做 AI 辅助编程的同学应该都有体会代码文件越长越容易把不相关的代码塞给模型既浪费 Token 又稀释注意力。我的经验是显式圈定上下文而不是把整个仓库交给 AI。在 Cursor、Claude Code、Codex CLI 这类工具里尽量不要用那种“自动获取全部文件”的模式而是手动指定当前任务涉及的文件、函数或类。比如你要改某个模块的接口就把这个接口的定义、调用它的几个关键位置、对应的测试用例给到模型其他无关模块一概不写进上下文。还有个不少人忽略的点让模型先输出“对问题的理解”再输出代码。这在编码场景中特别有用。你可以要求模型先把任务拆解成要点、列出改动文件清单确认无误后再生成具体实现。这本质上是在上下文里建立“共识区”避免模型越过需求直接写代码导致方向跑偏。这个习惯也帮我在代码评审时省了大量返工时间。3. 采样参数决定模型“性格”的旋钮3.1 从概率到文本模型是怎么“选”下一个词的前面讲了模型如何把文本变成 Token但模型真正神奇的地方在于它能预测下一个 Token 是什么。具体来说模型会根据当前上下文为词表中的每个 Token 计算一个分数Logits再通过 Softmax 函数转成概率分布。然后在这个概率分布上用不同的策略选出“下一个 Token”。这里的关键是模型天然不是一个“只会选最大概率”的机器。它在概率分布上做“采样”也就是带有一定随机性。采样参数就是控制这个随机性方式和强度的旋钮。我常用一个比喻模型像一个知识渊博但有点选择困难症的人。如果让他每次都说最标准、最保险的答案他会比较无聊如果给他一点自由发挥的空间他可能会说出很有创意的观点但也可能跑题。采样参数就是用来调节他“无聊”和“跑题”之间平衡的。3.2 核心采样参数逐个拆解temperature、top_p、top_k、惩罚项这一节是很多人“调了半天参数没感觉”的重灾区。我给每个参数一个清晰的定义附上使用建议。temperature温度最核心的随机性参数取值范围通常是 0 到 2。温度越低概率分布越尖锐模型越倾向选高概率 Token温度越高低概率 Token 也有机会被选中输出更多样、更有“创造力”。数学上它是把 Logits 除以温度值后再做 Softmax。当 temperature0 时概率分布尖锐到极限模型每次都选最高概率的 Token输出几乎完全确定。经验值需要稳定事实回答的场景用 0 到 0.3创意写作、头脑风暴用 0.7 到 1.0再高就容易胡言乱语了。top_k只从概率最高的前 K 个 Token 里采样其余全部排除。比如 top_k50就是先把概率排前 50 的 Token 挑出来再按各自概率采样。它的作用是防止模型偶尔抽中一个概率极低的冷门 Token。实际操作中top_k 通常设 40 到 50 是比较稳的区间。太小的 top_k 会让输出变得保守太大则失去了限制的意义。top_p核采样从累计概率超过 p 的最小 Token 集合里采样。比如 top_p0.9就把概率从高到低累加直到累加值超过 0.9然后在这一组 Token 中采样。它的逻辑是“只在高概率的候选里做选择”比 top_k 更动态因为候选数量会随概率分布的形状变化。标准做法是top_p 和 temperature 只调其中一个不要两个同时大幅调整否则容易互相打架输出变得难以控制。frequency_penalty频率惩罚对已经出现过的 Token 施加减分出现次数越多分越低从而降低模型重复同一词汇的概率。适合需要减少复读机效果的场景。范围通常是 -2 到 2正值代表惩罚重复负值反而鼓励重复。我一般设 0.3 到 0.6 就够用了太大会让句子变得生硬不连贯。presence_penalty存在性惩罚只要某个 Token 出现过就给一次固定减分跟出现次数无关。作用是鼓励模型谈论新话题、引入新概念。它和 frequency_penalty 的差别在于frequency 惩罚“反复说”presence 惩罚“说过就减分”。两者可以同时使用但要注意整体输出风格的变化。3.3 为什么模型“有幻觉”采样参数和幻觉得关系热词里有一条“大模型能力边界幻觉、上下文、温度”直接把幻觉和温度并列很有洞察。幻觉的本质原因很复杂包括训练数据噪声、模型压缩、知识截止日期等但采样参数是幻觉的直接触发器之一——如果你把 temperature 调得过高模型就会在低概率 Token 上“放飞自我”一本正经地编造事实。我在实际测试中遇到过非常典型的例子用同一个事实类问题分别测试 temperature0.1 和 temperature0.9前者回答准确率在 9 成以上后者虽然偶尔有惊艳表达但错误率也明显上升。如果你在做客服问答、知识库问答这类对准确性要求极高的场景我的建议是 temperature 不要超过 0.3最好在 0.1 到 0.2 之间。但有一点要提醒temperature0 并不能完全消除幻觉。因为模型“知道什么”和“确认什么”在训练时就固定了采样参数只是决定它能否说出不那么确定的内容。就算设置为 0模型也可能在知识盲区上编一个听起来合理的答案。要真正减少幻觉必须回到上下文工程——给它可靠的参考资料让它在有限范围内作答。3.4 “让模型不输出思考过程”这个需求怎么用参数满足热词里有一条“dify llm 怎么让模型不输出思考过程”这也是很多人问过的。首先要分清模型是否真的“会思考再输出”。现在很多推理模型比如带 reasoning 能力的模型默认会在回答前输出一段内部推理过程这在某些产品里是显式的会出现在界面上占用你的输出 Token。怎么让它不输出思考过程没有单一的采样参数能完全开关这个行为但我有几个亲测有效的方法一是修改系统提示词明确要求“只输出最终答案不要展示推理步骤不要解释过程”。多数模型会听话省掉那部分冗长的思考文本。二是在 API 层面关闭推理输出。不少平台提供reasoning或thinking相关开关把详细推理内容关掉只保留最终结果。如果你用的是这类能力优先找这个开关而不是调 temperature。三是把输出上限调低。如果模型的思考过程很长而你把 max_tokens 设置得较小推理过程就可能被截断最终答案自然变短。这个方法比较粗暴不推荐因为它可能让最终答案也一起被砍掉。四是换用非推理模型。如果你的任务不需要复杂推理只是想快速拿到答案直接选用不带推理能力的模型反而响应更快、成本更低。不要什么任务都上最强模型。3.5 max_tokens 与输出截断的实战经验“已达到输出 token 上限回答被截断”这个问题我估计被它坑过的人不在少数。要解决它得先搞清楚上下文窗口 输入 Token 输出 Token。当你请求时系统会预留出 max_tokens 这个输出额度剩下的才给输入用。如果输入太长留给输出的空间自然就少了。我踩过的一个具体坑是在一个长文档问答系统里用户上传一篇 5000 Token 的文档我把 max_tokens 设成 2000上下文窗口是 8000看起来没问题。但系统提示词、对话历史、检索结果加起来其实已经超过 6000 Token实际留给输出的只有不到 2000而模型生成到一半就到达上限回答被截断。后来我做了两道防线一是在发送前计算整个输入的长度如果接近上限就自动压缩历史或提示用户二是把 max_tokens 根据任务类型动态设置——摘要类任务给 1500 到 2000选择题给 200 到 500代码生成给 2000 以上。另一个技巧是遇到模型回答到一半断了不要重新问一遍直接发“继续”或“接着上文继续”让模型接着已有的回答继续生成。这也是热词里“发送‘继续’可让模型接续”的用法来源。但要注意“继续”也占用上下文和输出额度如果输入已经把窗口占满了继续也救不回来这时候只能先精简输入或手动拆分任务。4. 三者联动从一次生成事故看参数协作与排查思路4.1 一个真实的失败案例复盘今年早些时候我帮朋友排查一个 AI 写作助手的问题用户上传一篇约 1 万字的营销长文要求模型“改写成更有吸引力的版本”结果模型频繁报错偶尔成功但输出质量也很差。我打开日志一看问题一目了然整个请求的输入 Token 已经接近 1.5 万而上下文窗口是 8000系统自动截断了文档开头部分同时 temperature 被前端写死成 0.95为了“更有创意”导致模型在信息不全的情况下高随机性地发挥max_tokens 设的是 4096窗口又不够用经常生成一半就被截断。三个参数同时出问题结果就是输入被截断→模型看不到全文→高温度放飞自我→输出又被截断。用户看到的就是“报错答非所问生硬结尾”的三连击。修复方案也简单把文档拆分成长文分段改写每次只处理 3000 字左右temperature 从 0.95 降到 0.7max_tokens 设置为 1500让每次输出都能完整包含改写结果和必要的上下文总结。改完之后同样一篇长文处理时间变短了输出质量也稳定了。这个案例说明了一个重要原则Token、上下文、采样参数不是三个独立旋钮它们是一条生产链上的三个环节。任何一个环节出问题都可能让整体效果崩掉。4.2 常见问题速查表一图定位问题源头很多人来问我“为什么我的模型回答越聊越笨”时我给的排查思路就是先查这三个维度。整理成一个速查表方便你对照自己的情况快速定位现象最先排查的环节常见原因解决思路回答中断、半截话上下文窗口max_tokens输入太长挤占输出空间max_tokens 设太小压缩输入、降低文档长度、动态调整 max_tokens上下文报错超限上下文窗口输入超过模型硬限制精简提示词、做历史摘要、改用 RAG 检索回答越来越笨、前后矛盾Token 消耗上下文窗口历史对话被截断模型“失忆”缩短对话轮次、保留最近关键信息、每轮重建上下文天马行空、胡说八道采样参数temperature 过高降到 0.1 到 0.3或在接入层开启检索引用输出重复、复读机采样参数缺少频率惩罚temperature 过低加 frequency_penalty 0.3 到 0.6适当提高 temperature输出保守、缺乏创意采样参数temperature 过低适中调高到 0.7 到 1.0注意配合 top_pAPI 报错 token 失效/未授权接口鉴权凭证过期、权限不足重新登录、刷新 token、检查 API Key 权限账单费用超标Token 用量发送大量冗余内容、超长历史、高 max_tokens精简每次请求、启用上下文压缩、缓存响应你在排查时可以按“先查上下文窗口是否充足→再查采样参数是否合理→最后查接口鉴权和配额”这个顺序来。90% 的异常都能在第三步之前解决。4.3 一套可以直接抄的 LLM 应用参数配置最后分享一套我在多个实际项目中验证过的配置模板覆盖几类最常见的任务。注意这是起点不是终点具体到你的场景还需要微调。任务类型temperaturetop_ptop_kfrequency_penaltymax_tokens关键上下文策略知识库问答RAG0.10.3400.0500-1000只送入检索到的 Top 5 段落创意写作/头脑风暴0.90.9500.41500-3000提供写作方向示例不设限代码生成0.20.5400.02000明确函数签名、输入输出、约束条件摘要总结0.30.6450.3800-1500传入全文或拆分分批摘要客服对话0.20.4400.5500保留最近 5 轮对话用户订单信息翻译0.10.3400.01000-2000保留原文和被翻译的部分提供术语表这套模板的关键思路是事实类任务温度低创意类任务温度高输出长度按任务实际需要而不是越大越好。至于 top_k 和 top_p我建议新手先用 top_p 就够了top_k 作为辅助微调手段不要一上来两个参数都乱动。4.4 优化收益最大化的个人心得把“每次请求”当一份精心准备的简报踩过足够多的坑之后我发现真正拉开使用效果差距的往往不是选哪款模型或调哪个参数而是一个视角的转变把每次发给模型的请求当成一份给高管的简报——信息经过筛选、按优先级排序、控制篇幅、目标明确。这意味着你在写提示词时要想清楚几个问题模型需要哪些信息才能完成这个任务这些信息以什么顺序给最不容易被忽略哪些信息其实是干扰项可以省略执行标准应该用多少 token 能说清当你的思维从“我要把能想到的都告诉模型”转变成“我要让模型在有限上下文里最高效地完成任务”Token 成本、上下文超限、输出截断这些问题都会自动缓解。另外我始终建议你在本地维护一份自己的“提示词模板库”和“参数配置记录”。每次测试完一组任务就把用的参数、输入长度、输出质量、成本记下来。积累一段时间后你会形成一套属于自己的“手感”到那时再回头看什么 temperature、top_p它们不再是抽象的概念而是你手里的工具。