1. 写在前面LLM 不是“懂你”只是一场概率的精密计算搞懂 LLM大语言模型运行机制绕不开三个词Token、上下文、采样参数。我刚入行那几年整天和文本分类、序列标注打交道后来做大模型应用才发现很多人用 API 的时候连最基本的“为什么同一个提示词每次结果不一样”都没搞明白。网上资料要么太学术张嘴就是 Transformer 自注意力机制要么太碎片教你调参但完全不讲原理。这篇文章想做的事很简单把 LLM 从你输入一句话到生成一句话的完整链路拆开讲清楚 Token 是怎么切分文本的、上下文窗口到底意味着什么、采样参数又是如何影响最终输出的。不堆公式但会把关键的计算逻辑和工程考量讲透配合大量实操案例和踩坑记录。适用人群很广正在用 Claude、GPT 系列、DeepSeek 或其他大模型 API 做应用的开发者想优化提示词效率的产品经理以及想搞懂“幻觉”“温度过高”这些词到底怎么回事的深度用户。文章里的所有内容都是我实际跑过、验证过的不是抄文档。2. LLM 的基础认知从“查表”到“下一个词预测”2.1 大模型到底在做什么很多人对大模型有一种误解觉得它像一个超级智能体在“理解”你的问题之后去知识库里检索答案。实际完全不是这么回事。LLM 在推理时只做一件事根据当前已有的文本预测下一个最合适的 Token。说得再直白一点它就是一个极其复杂的“成语接龙”游戏。比如你输入“床前明月”它要预测下一个字或词最可能是什么。训练的过程就是给它看海量文本让它反复练习这种预测把数万亿参数调到一个合适的状态。所以你会看到一种现象LLM 对事实性问题的回答有时候像背书有时候又像在编故事。因为它本质上不是查到了“北京是中国的首都”这条记录而是在词与词的分布概率中把“北京”“中国”“首都”这几个 Token 的高概率序列给“接”出来了。2.2 为什么“上下文”决定了模型能力上限模型每次处理文本能“看到”的范围是有限的这个范围就叫上下文窗口。窗口越大它能参考的信息越多回答质量通常越好。但上下文不等于“无限记忆”这一点后面会详细展开。理解“预测下一个 Token”这个核心逻辑之后你对很多现象的困惑就会迎刃而解为什么有时候模型会“忘记”你对话开头提到的细节因为那是几千 Token 之前的内容早出了视野范围。为什么一次性塞给它 50 页文档它反而会答错一些简单问题因为注意力被稀释了。为什么同样的提示词多问几次答案会不一样因为采样过程中有随机性。下面我从 Token 开始一层层剥开。3. TokenLLM 世界的最小计量单位3.1 什么是 Token它如何切分文本Token 可以理解为模型处理文本时的最小原子单位。它可能是一个完整的英文单词也可能是一个单词的一部分甚至可能只是一个标点符号或一个空格。拿“Hello, world!”举例常见切法可能是这样“Hello”1 个 Token“,”1 个 Token“world”1 个 Token“!”1 个 Token但如果是“unbelievable”这种长单词可能会被切成“un”“believ”“able”三部分。这是由 BPE字节对编码这类子词切分算法决定的。中文的情况更特殊。因为中文字符信息密度高一个汉字往往就对应一个或半个 Token。同样一段话中文消耗的 Token 数量通常比英文少但意思能完整表达。我在测试不同模型时发现同一个问题中文回答的 Token 数大约只有英文回答的 60% 到 70%成本差异很明显。3.2 中英文 Token 计费的差异与省钱策略既然每个模型按 Token 计费那么搞清楚怎么“省 Token”就是实打实地省钱。拿我现在常用的几个模型举例场景英文 Token 数中文 Token 数差异“请用简短的语言总结以下文章”约 12 Token约 9 Token中文省 25%一篇 1000 字的中文技术博客约 1500 Token约 900 字对应约 900 Token取决于分词效果一份 10 页 PDF 提取要点约 5000 Token约 3200 Token中文更省省钱策略方面我的经验是能用中文提问就不要用冗长的英文模板虽然模型都能理解但 Token 消耗不同。减少不必要的重复描述比如“请你作为一个专业的、经验丰富的、资深的……”这种套话每次都会多烧几十个 Token对结果影响不大。系统提示词尽量精简把核心约束格式要求、禁止事项放在最前面后面跟任务描述。3.3 Token 溢出后的表现与规避方法Token 溢出是指输入内容超出了模型上下文窗口上限。这时候模型通常会直接报错或者截断输入导致输出质量断崖式下降。我在处理长文档时遇到过几次这种情况典型表现是模型只回答了文档开头部分的内容或者干脆不响应。后来我养成了一个习惯在调用 API 前先估算 Token 数给内容预留 20% 的缓冲空间。规避方法也很直接先对长文档做摘要提取只保留关键段落。分段处理把大任务拆成几个小任务逐段喂给模型。用向量数据库做检索先召回相关片段再交给模型回答。4. 上下文记忆的边界与知识的取舍4.1 上下文窗口的本质不是“越大越好”现在主流模型的上下文窗口做得越来越大从最早的 2K、4K到现在的 128K、200K 甚至更大。看起来是进步但引入了一个新问题模型在长上下文里注意力会“稀释”对中间部分内容的关注度明显低于开头和结尾。这个现象有个专门的名字叫“Lost in the Middle”。我做过实测给模型塞一段 80K Token 的文档让它回答问题当答案内容位于文档开头时准确率接近 95%位于文档中间时掉到 70% 左右位于结尾时又回升到 85% 左右。所以不要盲目迷信大窗口。如果你的任务对准确性要求极高管理上下文比扩容窗口更重要。4.2 上下文工程的三个层次精简、结构、检索所谓上下文工程就是主动控制模型“能看到什么、先看到什么、看不到什么”。我的实践经验可以归纳为三个层次第一层精简。删除无关的闲聊、重复的示例、多余的修饰词只保留任务所需的最小信息集。这能显著降低 Token 成本同时减少干扰。第二层结构。把关键信息放在上下文的最前面系统提示词位置和最后面用户输入末尾。模型对这两个位置的信息记忆最牢中间部分要放次要信息。第三层检索。当信息量超出窗口时不要全文喂给模型而是用 RAG检索增强生成的方式先根据问题把最相关的几段内容检索出来再拼接到上下文里。这样既保证了信息完整又控制住了 Token 数。4.3 上下文管理实战Claude 的超限处理方案有人问过我“Claude 超过上下文限制会怎么样”这里分两种情况。一种是 API 调用时直接超出 max_tokens 或上下文上限会返回错误码提示你减小输入。另一种是在 Claude 桌面端或 Web 端使用时超过限制后系统会提示“内存不足”对话可能会被强制截断。我的做法是给 Claude 设置“自动摘要层”每当对话超过一定轮次就让模型把之前的核心结论压缩成几条简短笔记然后清空那部分原始对话。相当于给模型配了一个“外接硬盘”需要时再把完整信息调出来。具体做法是写一个脚本在对话历史达到 80% 上下文窗口时自动触发一次摘要把摘要放回上下文中然后丢弃旧的轮次。实测下来这种“滚动摘要”方式能有效延长对话的可持续轮次质量损失控制在可接受范围内。4.4 视觉和结构文档的上下文处理现在很多模型支持多模态输入图片、PDF、表格都能处理。但很多人忽略了一点图片到底消耗多少 Token不同模型差别很大。以 Claude 为例一张普通分辨率的图片大概消耗 1000 到 1500 Token。如果一张图上有很多文字Token 消耗还会更高。所以我处理扫描版 PDF 时通常会先做 OCR 转成文本再喂给模型而不是直接传图片。后者效果不稳定而且 Token 消耗是前者的好几倍。另外Markdown 格式对喂给 LLM 的内容特别友好。结构化的标题、列表、表格模型解析效率远高于纯文本。我在自定义 API 工具时规定所有输入必须先整理成 Markdown 格式再送入模型输出质量有明显提升。5. 采样参数输出的“温度”与“个性”从哪里来5.1 Temperature不是“聪明度”而是“冒险度”在众多采样参数里最出名的就是 Temperature温度。很多人误以为调高温度会让模型更聪明恰恰相反温度控制的是模型在预测下一个 Token 时的“冒险程度”。用一个接地气的类比来解释模型在每一步其实都算出了一个概率分布——下一个 Token 候选 A 的概率是 70%B 是 20%C 是 10%。如果温度设为 0模型永远选概率最高的 A输出稳定、严谨、可预测。温度调高相当于给概率分布“抹平”了一些B 和 C 被选中的概率上升输出变得更加多样、有创造性。具体数值的影响我实测下来温度值输出风格适用场景0.0 - 0.3稳定、严谨、几乎无变化代码生成、SQL 查询、事实回答0.4 - 0.7平衡、自然、略带变化日常对话、邮件撰写、摘要0.8 - 1.0多样、有创意、不可控头脑风暴、文案创意、故事生成大于 1.0发散严重、容易胡说不推荐除非你刻意追求混乱5.2 Top_p 和 Top_k概率的“筛选器”与 Temperature 同样重要但常被忽视的是 Top_p核采样和 Top_k 参数。Top_k 的逻辑最简单只从概率最高的 K 个 Token 里选。K 越大可选范围越大输出越多样K 越小越集中、越稳定。比如 K1 时模型就固定选概率最高的那一个效果等同于温度设为 0 的贪心解码。Top_p 是另一种筛选方式按概率从高到低排列 Token累计概率达到 p 时就把这些 Token 都作为候选。比如 p0.9意味着候选集覆盖了概率分布中 90% 的可能性。这种做法比 Top_k 更灵活因为如果分布很集中候选集自然就小分布很松散候选集就大。实操经验是Temperature 和 Top_p 最好搭配使用不要同时调太高。我通常的做法是需要稳定的场景比如解析 JSON把温度设为 0.1、Top_p 设为 0.3需要创意文案时温度设为 0.8、Top_p 保持默认或降到 0.9 防止跑偏。5.3 其他采样参数的调试心得惩罚、窗口与停止符除了上述两个参数还有几个容易被忽略但影响明显的frequency_penalty频率惩罚每出现一次 Token就降低它下一次被选中的概率。值越大模型越不容易重复同一个词。适合写长文、生成代码时防止陷入重复循环。presence_penalty存在性惩罚只要 Token 出现过一次就降低它的概率。频率惩罚是“越出现越打压”存在性惩罚是“出现过就打压”。前者对重复更敏感后者对多样性更敏感。max_tokens最大生成长度这个看似简单但很多人会低估它。如果生成内容被截断模型不报错而是直接输出一段“半句话”。检查时很难发现异常实际上已经影响了下游任务。stop停止序列指定一个或多个字符串模型生成到该字符串时就停下来。这在结构化输出里非常有用比如让模型生成完一个 JSON 对象后遇到“}”就停止避免多余内容。5.4 采样参数的“玄学”边界什么情况下调参也没用必须泼一盆冷水采样参数不是万能的。有些问题调参根本解决不了。比如你让模型回答一个它“知识”里根本没有的事实性问题温度调到 0 也没用它依然会用听起来很自信的口吻编一个答案。这就是“幻觉”的根源。再比如你给模型的任务本身指令模糊调任何参数都不会让输出变好。正确的做法是先优化系统提示词把任务边界说清楚再考虑调参。还有一类情况是上下文里的信息互相矛盾导致模型无所适从。这时候调参是在“五十步笑百步”不如把上下文清理干净、信息统一。我踩过最大的一个坑有一个文本分类任务模型输出一直不稳定我以为是温度太高一路调到 0结果还是偶尔出错。最后定位到问题出在提示词里给了太多相似的示例模型分不清类别边界。换成更明确的分类标准和少而精的示例之后问题立刻解决。调参解决不了的往往是提示词或数据的问题不是参数的问题。6. 参数联动实践一个完整项目的调优记录6.1 从任务出发反向确定参数组合拿我最近做的一个“长文档自动日报生成”项目来举例。这个任务的要求是输入一份 2000 字左右的项目周报输出 5 条核心进展每条不超过 50 个字同时给出风险提示。这个任务的语境是“总结”特殊性在于信息密度要保留、语气要客观、输出格式必须稳定。所以我的参数设定是Temperature0.2低保证事实准确Top_p0.5压缩候选空间max_tokens300预留足够空间但不过量stop空让模型自然结束核心原因很简单日报是给团队和管理层看的准确性远高于文采。如果我在这里把温度调高模型可能会发挥出“创造力”加入原周报中不存在的细节弄出一份看似丝滑但失真严重的汇报——这是我在早期版本里真实遇到过的。6.2 实际运行效果与调优迭代第一版实测输出能看但有两个问题第一部分条目超过 50 字限制第二有一条“风险提示”是模型自己编的原文中压根没有提到。针对第一个问题我在提示词里硬性加入“每条必须控制在 40 字以内”同时把 temperature 降到 0.1。针对第二个问题我在提示词里加了“风险提示必须严格基于原文内容没有提到就写‘无’”然后把 Top_p 从默认 0.9 降到 0.4。修改后重新跑 50 条样本格式合规率从 82% 提升到 96%编造内容从 5 条降到 1 条。那 1 条后来排查发现是输入文档里包含“潜在风险”四个字模型理解成了“有风险”并放大表述。这是语义层面的问题单纯调参已经无法解决需要在提示词里更严格地定义“风险”的判定标准。6.3 项目代码片段一个最小可复现的调用示例以上调优逻辑我封装成了一个简单的 Python 函数。以下代码基于 OpenAI 风格 API如果你用 Claude 或 DeepSeek参数名几乎一样改成对应 SDK 即可from openai import OpenAI # 初始化客户端base_url 按实际服务商设置 client OpenAI( api_keyyour-api-key, base_urlhttps://your-endpoint ) def generate_summary(context_text: str) - str: # 根据任务场景定义参数模板 params { model: your-model-name, temperature: 0.1, top_p: 0.4, max_tokens: 300, } # 系统提示词定义角色 输出规范防止模型自由发挥 system_prompt ( 你是一个项目助理负责从周报中提取核心进展。\n 输出要求\n 1. 每条核心进展不超过40字。\n 2. 风险提示必须基于原文未提及则输出“无”。\n 3. 使用编号列表不要额外解释。 ) response client.chat.completions.create( **params, messages[ {role: system, content: system_prompt}, {role: user, content: context_text} ] ) return response.choices[0].message.content注意几个容易踩的细节如果 API 不支持 top_p它会忽略这个参数但不报错所以不要完全依赖参数生效最好先用一条测试样本验证。max_tokens 别设得太小否则长文本任务会“半截话”但设得太大如果模型生成到一半就结束了剩下的 token 额度也不会退。不同服务商的 SDK 可能在参数命名上有差异比如有的叫 top_p有的叫 nucleus_sampling接入前先看文档。7. 常见踩坑与排查指南7.1 关于 Token 的常见问题与解决方案现象可能原因解决办法API 返回 context length exceeded输入超出窗口上限压缩内容、分段处理、用摘要替代生成结果突然中断max_tokens 设置过小增大 max_tokens费用异常偏高系统提示词过长、历史消息未清理精简提示词、实现滑动窗口中英文回答长度差异大分词器特性不同设计提示词时用对应语言的常见表达Token 相关的坑大多出在“估算”环节。建议在测试阶段就把每次请求的输入输出 Token 数打印出来做一份统计表用数据指导优化而不是凭感觉猜。7.2 模型上下文常见的“假故障”很多人一看到模型答非所问就怀疑是参数出了问题其实很可能是上下文里的问题。两种最典型的情况第一种上下文信息过载。你一上来就把 100 页文档全塞进去问一个埋在第 80 页里的细节。模型不是“不听话”是它真的“没看全”。这种情况下加温度的调参毫无意义正确做法是缩小输入范围或启用检索。第二种上下文顺序不当。系统提示词、用户问题、参考文档的顺序会影响模型注意力。经验是“指令放最前数据放中间问题放最后”这样模型在生成时会优先参考最近的“问题”和开头定义的“指令”效果比随便拼接好很多。7.3 采样参数调试的“最小改动原则”最后分享一个我常用的调试原则一次只改一个参数改完立刻用固定样本集回归。我见过很多人调参时四个参数一起动结果效果变差了却不知道是哪个参数拖的后腿。正确做法是建立一份包含 10 到 20 条代表性输入的测试集。固定其他参数只调整目标参数记录输出质量变化。找到最优区间后再调整下一个参数。最后做一次组合验证确保参数之间没有互相打架。这个流程听起来笨拙但对生产环境特别管用。至少能让你在模型升级或更换时快速定位“为什么以前没问题的提示词现在不行了”。8. 写在最后的实战心得这个领域有个很有趣的现象工具迭代飞快但底层原理相对稳定。无论是 Cluade 也好GPT 也好还是各种开源模型Token 切分、上下文窗口、采样解码这套逻辑基本一致。把底层理解透了换模型的时候只需要微调提示词和参数不用推翻重学。我个人这几年攒下的三个核心经验供参考第一省 Token 就是省钱但不要为了省 Token 牺牲任务质量。合理做法是先保证正确性再逐步压缩提示词找到质量与成本的最优平衡点。第二上下文工程比采样参数重要得多。一个清晰、结构化的提示词配合智能的上下文管理效果远胜于盲目调高温度或 top_p。参数只是微调提示词才是主战场。第三一定要建立自己的测试集。不要凭一两次的输出效果来判断模型好坏要用固定输入、固定指标去评估。否则你很难判断“这次调参到底有没有用”。最后再分享一个小技巧如果你在做代码生成把 temperature 调到 0.1 以下top_p 调到 0.3 以下输出会稳定到一个让你惊讶的程度。这个组合是我在写结构化 JSON 解析时踩过无数坑之后沉淀下来的“保命参数”建议你直接试。
LLM推理机制全解析：Token、上下文窗口与采样参数调优实战
1. 写在前面LLM 不是“懂你”只是一场概率的精密计算搞懂 LLM大语言模型运行机制绕不开三个词Token、上下文、采样参数。我刚入行那几年整天和文本分类、序列标注打交道后来做大模型应用才发现很多人用 API 的时候连最基本的“为什么同一个提示词每次结果不一样”都没搞明白。网上资料要么太学术张嘴就是 Transformer 自注意力机制要么太碎片教你调参但完全不讲原理。这篇文章想做的事很简单把 LLM 从你输入一句话到生成一句话的完整链路拆开讲清楚 Token 是怎么切分文本的、上下文窗口到底意味着什么、采样参数又是如何影响最终输出的。不堆公式但会把关键的计算逻辑和工程考量讲透配合大量实操案例和踩坑记录。适用人群很广正在用 Claude、GPT 系列、DeepSeek 或其他大模型 API 做应用的开发者想优化提示词效率的产品经理以及想搞懂“幻觉”“温度过高”这些词到底怎么回事的深度用户。文章里的所有内容都是我实际跑过、验证过的不是抄文档。2. LLM 的基础认知从“查表”到“下一个词预测”2.1 大模型到底在做什么很多人对大模型有一种误解觉得它像一个超级智能体在“理解”你的问题之后去知识库里检索答案。实际完全不是这么回事。LLM 在推理时只做一件事根据当前已有的文本预测下一个最合适的 Token。说得再直白一点它就是一个极其复杂的“成语接龙”游戏。比如你输入“床前明月”它要预测下一个字或词最可能是什么。训练的过程就是给它看海量文本让它反复练习这种预测把数万亿参数调到一个合适的状态。所以你会看到一种现象LLM 对事实性问题的回答有时候像背书有时候又像在编故事。因为它本质上不是查到了“北京是中国的首都”这条记录而是在词与词的分布概率中把“北京”“中国”“首都”这几个 Token 的高概率序列给“接”出来了。2.2 为什么“上下文”决定了模型能力上限模型每次处理文本能“看到”的范围是有限的这个范围就叫上下文窗口。窗口越大它能参考的信息越多回答质量通常越好。但上下文不等于“无限记忆”这一点后面会详细展开。理解“预测下一个 Token”这个核心逻辑之后你对很多现象的困惑就会迎刃而解为什么有时候模型会“忘记”你对话开头提到的细节因为那是几千 Token 之前的内容早出了视野范围。为什么一次性塞给它 50 页文档它反而会答错一些简单问题因为注意力被稀释了。为什么同样的提示词多问几次答案会不一样因为采样过程中有随机性。下面我从 Token 开始一层层剥开。3. TokenLLM 世界的最小计量单位3.1 什么是 Token它如何切分文本Token 可以理解为模型处理文本时的最小原子单位。它可能是一个完整的英文单词也可能是一个单词的一部分甚至可能只是一个标点符号或一个空格。拿“Hello, world!”举例常见切法可能是这样“Hello”1 个 Token“,”1 个 Token“world”1 个 Token“!”1 个 Token但如果是“unbelievable”这种长单词可能会被切成“un”“believ”“able”三部分。这是由 BPE字节对编码这类子词切分算法决定的。中文的情况更特殊。因为中文字符信息密度高一个汉字往往就对应一个或半个 Token。同样一段话中文消耗的 Token 数量通常比英文少但意思能完整表达。我在测试不同模型时发现同一个问题中文回答的 Token 数大约只有英文回答的 60% 到 70%成本差异很明显。3.2 中英文 Token 计费的差异与省钱策略既然每个模型按 Token 计费那么搞清楚怎么“省 Token”就是实打实地省钱。拿我现在常用的几个模型举例场景英文 Token 数中文 Token 数差异“请用简短的语言总结以下文章”约 12 Token约 9 Token中文省 25%一篇 1000 字的中文技术博客约 1500 Token约 900 字对应约 900 Token取决于分词效果一份 10 页 PDF 提取要点约 5000 Token约 3200 Token中文更省省钱策略方面我的经验是能用中文提问就不要用冗长的英文模板虽然模型都能理解但 Token 消耗不同。减少不必要的重复描述比如“请你作为一个专业的、经验丰富的、资深的……”这种套话每次都会多烧几十个 Token对结果影响不大。系统提示词尽量精简把核心约束格式要求、禁止事项放在最前面后面跟任务描述。3.3 Token 溢出后的表现与规避方法Token 溢出是指输入内容超出了模型上下文窗口上限。这时候模型通常会直接报错或者截断输入导致输出质量断崖式下降。我在处理长文档时遇到过几次这种情况典型表现是模型只回答了文档开头部分的内容或者干脆不响应。后来我养成了一个习惯在调用 API 前先估算 Token 数给内容预留 20% 的缓冲空间。规避方法也很直接先对长文档做摘要提取只保留关键段落。分段处理把大任务拆成几个小任务逐段喂给模型。用向量数据库做检索先召回相关片段再交给模型回答。4. 上下文记忆的边界与知识的取舍4.1 上下文窗口的本质不是“越大越好”现在主流模型的上下文窗口做得越来越大从最早的 2K、4K到现在的 128K、200K 甚至更大。看起来是进步但引入了一个新问题模型在长上下文里注意力会“稀释”对中间部分内容的关注度明显低于开头和结尾。这个现象有个专门的名字叫“Lost in the Middle”。我做过实测给模型塞一段 80K Token 的文档让它回答问题当答案内容位于文档开头时准确率接近 95%位于文档中间时掉到 70% 左右位于结尾时又回升到 85% 左右。所以不要盲目迷信大窗口。如果你的任务对准确性要求极高管理上下文比扩容窗口更重要。4.2 上下文工程的三个层次精简、结构、检索所谓上下文工程就是主动控制模型“能看到什么、先看到什么、看不到什么”。我的实践经验可以归纳为三个层次第一层精简。删除无关的闲聊、重复的示例、多余的修饰词只保留任务所需的最小信息集。这能显著降低 Token 成本同时减少干扰。第二层结构。把关键信息放在上下文的最前面系统提示词位置和最后面用户输入末尾。模型对这两个位置的信息记忆最牢中间部分要放次要信息。第三层检索。当信息量超出窗口时不要全文喂给模型而是用 RAG检索增强生成的方式先根据问题把最相关的几段内容检索出来再拼接到上下文里。这样既保证了信息完整又控制住了 Token 数。4.3 上下文管理实战Claude 的超限处理方案有人问过我“Claude 超过上下文限制会怎么样”这里分两种情况。一种是 API 调用时直接超出 max_tokens 或上下文上限会返回错误码提示你减小输入。另一种是在 Claude 桌面端或 Web 端使用时超过限制后系统会提示“内存不足”对话可能会被强制截断。我的做法是给 Claude 设置“自动摘要层”每当对话超过一定轮次就让模型把之前的核心结论压缩成几条简短笔记然后清空那部分原始对话。相当于给模型配了一个“外接硬盘”需要时再把完整信息调出来。具体做法是写一个脚本在对话历史达到 80% 上下文窗口时自动触发一次摘要把摘要放回上下文中然后丢弃旧的轮次。实测下来这种“滚动摘要”方式能有效延长对话的可持续轮次质量损失控制在可接受范围内。4.4 视觉和结构文档的上下文处理现在很多模型支持多模态输入图片、PDF、表格都能处理。但很多人忽略了一点图片到底消耗多少 Token不同模型差别很大。以 Claude 为例一张普通分辨率的图片大概消耗 1000 到 1500 Token。如果一张图上有很多文字Token 消耗还会更高。所以我处理扫描版 PDF 时通常会先做 OCR 转成文本再喂给模型而不是直接传图片。后者效果不稳定而且 Token 消耗是前者的好几倍。另外Markdown 格式对喂给 LLM 的内容特别友好。结构化的标题、列表、表格模型解析效率远高于纯文本。我在自定义 API 工具时规定所有输入必须先整理成 Markdown 格式再送入模型输出质量有明显提升。5. 采样参数输出的“温度”与“个性”从哪里来5.1 Temperature不是“聪明度”而是“冒险度”在众多采样参数里最出名的就是 Temperature温度。很多人误以为调高温度会让模型更聪明恰恰相反温度控制的是模型在预测下一个 Token 时的“冒险程度”。用一个接地气的类比来解释模型在每一步其实都算出了一个概率分布——下一个 Token 候选 A 的概率是 70%B 是 20%C 是 10%。如果温度设为 0模型永远选概率最高的 A输出稳定、严谨、可预测。温度调高相当于给概率分布“抹平”了一些B 和 C 被选中的概率上升输出变得更加多样、有创造性。具体数值的影响我实测下来温度值输出风格适用场景0.0 - 0.3稳定、严谨、几乎无变化代码生成、SQL 查询、事实回答0.4 - 0.7平衡、自然、略带变化日常对话、邮件撰写、摘要0.8 - 1.0多样、有创意、不可控头脑风暴、文案创意、故事生成大于 1.0发散严重、容易胡说不推荐除非你刻意追求混乱5.2 Top_p 和 Top_k概率的“筛选器”与 Temperature 同样重要但常被忽视的是 Top_p核采样和 Top_k 参数。Top_k 的逻辑最简单只从概率最高的 K 个 Token 里选。K 越大可选范围越大输出越多样K 越小越集中、越稳定。比如 K1 时模型就固定选概率最高的那一个效果等同于温度设为 0 的贪心解码。Top_p 是另一种筛选方式按概率从高到低排列 Token累计概率达到 p 时就把这些 Token 都作为候选。比如 p0.9意味着候选集覆盖了概率分布中 90% 的可能性。这种做法比 Top_k 更灵活因为如果分布很集中候选集自然就小分布很松散候选集就大。实操经验是Temperature 和 Top_p 最好搭配使用不要同时调太高。我通常的做法是需要稳定的场景比如解析 JSON把温度设为 0.1、Top_p 设为 0.3需要创意文案时温度设为 0.8、Top_p 保持默认或降到 0.9 防止跑偏。5.3 其他采样参数的调试心得惩罚、窗口与停止符除了上述两个参数还有几个容易被忽略但影响明显的frequency_penalty频率惩罚每出现一次 Token就降低它下一次被选中的概率。值越大模型越不容易重复同一个词。适合写长文、生成代码时防止陷入重复循环。presence_penalty存在性惩罚只要 Token 出现过一次就降低它的概率。频率惩罚是“越出现越打压”存在性惩罚是“出现过就打压”。前者对重复更敏感后者对多样性更敏感。max_tokens最大生成长度这个看似简单但很多人会低估它。如果生成内容被截断模型不报错而是直接输出一段“半句话”。检查时很难发现异常实际上已经影响了下游任务。stop停止序列指定一个或多个字符串模型生成到该字符串时就停下来。这在结构化输出里非常有用比如让模型生成完一个 JSON 对象后遇到“}”就停止避免多余内容。5.4 采样参数的“玄学”边界什么情况下调参也没用必须泼一盆冷水采样参数不是万能的。有些问题调参根本解决不了。比如你让模型回答一个它“知识”里根本没有的事实性问题温度调到 0 也没用它依然会用听起来很自信的口吻编一个答案。这就是“幻觉”的根源。再比如你给模型的任务本身指令模糊调任何参数都不会让输出变好。正确的做法是先优化系统提示词把任务边界说清楚再考虑调参。还有一类情况是上下文里的信息互相矛盾导致模型无所适从。这时候调参是在“五十步笑百步”不如把上下文清理干净、信息统一。我踩过最大的一个坑有一个文本分类任务模型输出一直不稳定我以为是温度太高一路调到 0结果还是偶尔出错。最后定位到问题出在提示词里给了太多相似的示例模型分不清类别边界。换成更明确的分类标准和少而精的示例之后问题立刻解决。调参解决不了的往往是提示词或数据的问题不是参数的问题。6. 参数联动实践一个完整项目的调优记录6.1 从任务出发反向确定参数组合拿我最近做的一个“长文档自动日报生成”项目来举例。这个任务的要求是输入一份 2000 字左右的项目周报输出 5 条核心进展每条不超过 50 个字同时给出风险提示。这个任务的语境是“总结”特殊性在于信息密度要保留、语气要客观、输出格式必须稳定。所以我的参数设定是Temperature0.2低保证事实准确Top_p0.5压缩候选空间max_tokens300预留足够空间但不过量stop空让模型自然结束核心原因很简单日报是给团队和管理层看的准确性远高于文采。如果我在这里把温度调高模型可能会发挥出“创造力”加入原周报中不存在的细节弄出一份看似丝滑但失真严重的汇报——这是我在早期版本里真实遇到过的。6.2 实际运行效果与调优迭代第一版实测输出能看但有两个问题第一部分条目超过 50 字限制第二有一条“风险提示”是模型自己编的原文中压根没有提到。针对第一个问题我在提示词里硬性加入“每条必须控制在 40 字以内”同时把 temperature 降到 0.1。针对第二个问题我在提示词里加了“风险提示必须严格基于原文内容没有提到就写‘无’”然后把 Top_p 从默认 0.9 降到 0.4。修改后重新跑 50 条样本格式合规率从 82% 提升到 96%编造内容从 5 条降到 1 条。那 1 条后来排查发现是输入文档里包含“潜在风险”四个字模型理解成了“有风险”并放大表述。这是语义层面的问题单纯调参已经无法解决需要在提示词里更严格地定义“风险”的判定标准。6.3 项目代码片段一个最小可复现的调用示例以上调优逻辑我封装成了一个简单的 Python 函数。以下代码基于 OpenAI 风格 API如果你用 Claude 或 DeepSeek参数名几乎一样改成对应 SDK 即可from openai import OpenAI # 初始化客户端base_url 按实际服务商设置 client OpenAI( api_keyyour-api-key, base_urlhttps://your-endpoint ) def generate_summary(context_text: str) - str: # 根据任务场景定义参数模板 params { model: your-model-name, temperature: 0.1, top_p: 0.4, max_tokens: 300, } # 系统提示词定义角色 输出规范防止模型自由发挥 system_prompt ( 你是一个项目助理负责从周报中提取核心进展。\n 输出要求\n 1. 每条核心进展不超过40字。\n 2. 风险提示必须基于原文未提及则输出“无”。\n 3. 使用编号列表不要额外解释。 ) response client.chat.completions.create( **params, messages[ {role: system, content: system_prompt}, {role: user, content: context_text} ] ) return response.choices[0].message.content注意几个容易踩的细节如果 API 不支持 top_p它会忽略这个参数但不报错所以不要完全依赖参数生效最好先用一条测试样本验证。max_tokens 别设得太小否则长文本任务会“半截话”但设得太大如果模型生成到一半就结束了剩下的 token 额度也不会退。不同服务商的 SDK 可能在参数命名上有差异比如有的叫 top_p有的叫 nucleus_sampling接入前先看文档。7. 常见踩坑与排查指南7.1 关于 Token 的常见问题与解决方案现象可能原因解决办法API 返回 context length exceeded输入超出窗口上限压缩内容、分段处理、用摘要替代生成结果突然中断max_tokens 设置过小增大 max_tokens费用异常偏高系统提示词过长、历史消息未清理精简提示词、实现滑动窗口中英文回答长度差异大分词器特性不同设计提示词时用对应语言的常见表达Token 相关的坑大多出在“估算”环节。建议在测试阶段就把每次请求的输入输出 Token 数打印出来做一份统计表用数据指导优化而不是凭感觉猜。7.2 模型上下文常见的“假故障”很多人一看到模型答非所问就怀疑是参数出了问题其实很可能是上下文里的问题。两种最典型的情况第一种上下文信息过载。你一上来就把 100 页文档全塞进去问一个埋在第 80 页里的细节。模型不是“不听话”是它真的“没看全”。这种情况下加温度的调参毫无意义正确做法是缩小输入范围或启用检索。第二种上下文顺序不当。系统提示词、用户问题、参考文档的顺序会影响模型注意力。经验是“指令放最前数据放中间问题放最后”这样模型在生成时会优先参考最近的“问题”和开头定义的“指令”效果比随便拼接好很多。7.3 采样参数调试的“最小改动原则”最后分享一个我常用的调试原则一次只改一个参数改完立刻用固定样本集回归。我见过很多人调参时四个参数一起动结果效果变差了却不知道是哪个参数拖的后腿。正确做法是建立一份包含 10 到 20 条代表性输入的测试集。固定其他参数只调整目标参数记录输出质量变化。找到最优区间后再调整下一个参数。最后做一次组合验证确保参数之间没有互相打架。这个流程听起来笨拙但对生产环境特别管用。至少能让你在模型升级或更换时快速定位“为什么以前没问题的提示词现在不行了”。8. 写在最后的实战心得这个领域有个很有趣的现象工具迭代飞快但底层原理相对稳定。无论是 Cluade 也好GPT 也好还是各种开源模型Token 切分、上下文窗口、采样解码这套逻辑基本一致。把底层理解透了换模型的时候只需要微调提示词和参数不用推翻重学。我个人这几年攒下的三个核心经验供参考第一省 Token 就是省钱但不要为了省 Token 牺牲任务质量。合理做法是先保证正确性再逐步压缩提示词找到质量与成本的最优平衡点。第二上下文工程比采样参数重要得多。一个清晰、结构化的提示词配合智能的上下文管理效果远胜于盲目调高温度或 top_p。参数只是微调提示词才是主战场。第三一定要建立自己的测试集。不要凭一两次的输出效果来判断模型好坏要用固定输入、固定指标去评估。否则你很难判断“这次调参到底有没有用”。最后再分享一个小技巧如果你在做代码生成把 temperature 调到 0.1 以下top_p 调到 0.3 以下输出会稳定到一个让你惊讶的程度。这个组合是我在写结构化 JSON 解析时踩过无数坑之后沉淀下来的“保命参数”建议你直接试。