你是不是也有过这种经历跟AI连续聊了半小时它突然把你几个小时前提的需求忘得一干二净同一个问题把某个参数调了一下输出就从一本正经变成了天马行空。这些问题归根结底都绕不开三个词Token、上下文、采样参数。无论你是刚接触大模型的新手还是已经在本地部署过Qwen、Llama这些开源模型的玩家只要你用过ChatGPT、Claude这类产品或者玩过Ollama、LM Studio、Dify你其实每天都在跟这三件事打交道。这篇文章不绕弯子直接从运行机制层面把它们拆开讲清楚Token到底是什么、上下文窗口到底怎么运作、采样参数改了会发生什么以及在真实项目和日常使用中你会踩到哪些坑、怎么排查。文章里不会有太多教你“怎么复制粘贴Prompt”的内容而是尽量解释底层逻辑让你以后遇到问题能自己判断方向。1. LLM到底在做什么一个不断“猜下一个词”的概率机器1.1 先建立一个正确的心理模型大语言模型LLM本质上是一个自回归语言模型。自回归这个词听着吓人翻译成大白话就是它每次只生成一个Token生成的时候回头看一眼已经生成的内容然后猜下一个Token最可能是哪个再把猜出来的结果接到自己“已经看到的内容”队列里继续猜下一个。整个过程就是一个接一个地填空直到满足停止条件。这个“猜下一个Token”的模式决定了我们对LLM的大部分使用方式都可以简化成一句话你给它的信息上下文决定了它能“看到”什么你选的采样参数决定了它在候选答案里怎么“冒风险”。所有关于“模型为什么答得这么好/这么蠢”的讨论追到最底层都是这句话。但这并不意味着理解到这个程度就够了。现代模型动辄几十亿、上百亿参数结构是多层Transformer在海量数据训练后这种简单的“猜词”任务会逼着模型形成对语法、知识、逻辑关系的大量隐性编码。所以你会觉得它好像在“思考”其实它只是在用统计规律做一个概率极高的猜测。理解这一点对后面调参很有帮助——你越清楚它在算什么就越知道改哪个旋钮能改变什么。1.2 训练阶段和推理阶段必须分开看很多人会把“模型怎么能记住这么多知识”和“为什么我的对话它记不住”混在一起。实际上LLM的知识和“记忆”来自两个完全不同的阶段。训练阶段模型在海量文本里学习参数知识被压缩进模型权重。这是离线过程花的是训练时的算力和时间不是我们日常使用时的成本。推理阶段模型加载权重之后对用户输入做一次前向计算生成输出。你花掉的Token、消耗的显存、等待的时间主要都发生在这一步。我们日常谈论的“上下文”“采样参数”“Token计费”全部发生在推理阶段。所以当你问“为什么模型有时候知道有时候不知道”大概率不是模型训练时没学会而是你这次的提示词、上下文、参数共同作用的结果。模型端决定能力上限推理端的工程决定你能把能力用出来几分。1.3 为什么这个简单机制看起来像“智能”这里说一点我自己的理解。语言本身承载了大量人类推理的结构而Transformer又通过注意力机制让模型能够回溯前文里相对关键的信息。所以当模型在海量语料里训练过后“预测下一个Token”这个任务实际上就在强迫它形成各种隐式的知识表示和推理路径。这也是“LLM能对话”的底层基础。但这也带来了一个副作用如果你给模型的信息不完整、有歧义或者自相矛盾它依然会“自信地”预测下一个Token因为机制上它必须给出一个答案。所以你会发现很多翻车现场不是模型变笨了而是输入本身有问题。这也是为什么“上下文工程”越来越重要后面我会专门展开说。2. TokenLLM世界里的基本计量单位2.1 Token到底是什么一句话Token是模型处理和生成文本的最小单位而不是我们习惯的“字”或“词”。模型看不懂人类语言它只能处理数字。为了让文本变成数字需要先把文本切成一段段小碎片再给每个碎片分配一个编号对应词表里的一个下标这个过程叫分词英文叫Tokenization。不一样的是英文里常见的短单词经常是一个Token比如“apple”可能整体就是1个Token但一个长单词可能被拆成两三个Token。中文又是另一种局面因为中文不像英文用空格天然分词而且汉字在BPE这类分词算法训练时经常与相邻字组合所以一个汉字在很多模型里并不是稳定地等于1个Token。常见的情况是一个中文常用字大约占0.6到1.5个Token具体取决于模型的词表设计。为了让模型能处理任意文本分词算法还要照顾到空格、标点、数字、Unicode等边界情况。比如标点符号经常单独占一个Token一个空格甚至也可能占一个Token。别小看这些“隐藏Token”当你写了一大段排版复杂的Markdown、代码块、表格时格式字符也在消耗你的上下文空间。2.2 为什么中文的Token经常比英文“更贵”先看一个很直观的对比。以常见模型的分词器为例具体数字会因为模型词表不同而有差异但趋势是一致的英文“How are you?”通常在3到5个Token之间常用词覆盖好标点单独占位。中文“你好吗”在不同模型里可能是3个Token有些模型会把常用词整体编码成一个Token有些则拆成单字。一个不常见的中文人名往往会被切成三四个甚至更多Token而一个常见英文单词“information”整体可能只是一个Token。所以同样的语义量中文文本通常比英文文本消耗更多Token。这背后是BPE字节对编码及其变体的特性英文语料在预训练里占比高词表对英文覆盖更好中文是“字少、词多”单字信息密度高但分词器很难为所有常见词都分配独立Token只能更多依赖字和字节的组合。输入示例常见模型Token数大致范围说明hello world1-3 Token英文常用词覆盖好今天天气不错5-8 Token中文常按字或词组切分一段含标点和空格的英文单词数额外Token空格、标点各占位一段中文长文汉字数乘以1到1.5实操估算建议值另一个容易让人忽略的点是同一个模型的不同版本、不同公司训练的分词器对同样一段中文的切分结果可能差很多。比如Qwen系列和Llama系列的中文Token效率就完全不同后者处理中文经常更费Token这也是你在选择模型时可以考虑的一个指标。2.3 Token直接决定你的API账单很多人第一次看API账单时都会被吓到为什么短短几千字对话就花了这么多钱因为计费是按Token计算的而且通常是“输入Token 输出Token”双重计费。举个例子假设某个模型的价格是输入每百万Token收1元、输出每百万Token收3元各平台差异很大仅示意。一次问答如果带了2万Token的历史记录光输入成本就占了不小比例。如果你在做RAG知识库问答每次提问都把整篇长文档塞进去上下文Token会迅速累积账单自然水涨船高。这里有一个很容易混淆的概念需要说清楚热搜里常出现“免费Token”“Token失效”很多新手以为是同一个Token。其实“免费Token”只是平台赠送试用额度的说法本质是“有一定Token量的免费用量”而“Token失效”在绝大多数报错里指的是登录鉴权领域的JWT Access Token过期或交换失败跟大模型里的Token不是一回事。别被形形色色的报错信息带偏先分清你说的Token是哪个Token。2.4 实操如何查看和估算Token你在使用API时通常可以在接口返回的usage字段里看到本次请求消耗的具体数量比如prompt_tokens、completion_tokens、total_tokens。这是最准确的数字。如果你在本地跑开源模型分词器是打包在模型里的你想估算自己文本的Token数最直接的办法是使用模型对应的Tokenizer库。Hugging Face生态里可以用transformers库加载AutoTokenizer来数TokenOpenAI生态里有tiktoken。这些都是几行代码就能跑的活儿。如果你只是日常聊天不想折腾代码粗略估算也够用中文场景下可以按“1个汉字大约等于1到1.5个Token”来估算英文场景按“1个英文单词大约等于1.2到1.5个Token”来估算。注意这只是经验值最终要以你实际用到的模型分词器为准。还有一个小技巧别让模型自己数Token模型并没有可靠的“数Token”能力它只是学了个大概。3. 上下文模型的工作记忆边界3.1 什么是上下文窗口上下文窗口是指模型在一次生成里最多能“看到”的Token数量。它既包括你当前输入的提示词也包括之前多轮对话的历史记录多轮对话API里历史消息都会被拼进上下文还包括系统提示词、工具定义、检索到的知识片段等。用一个生活化的类比上下文窗口就像你办公桌上能摊开的纸张数量。你能摊开的纸越多可以参考的材料就越多回答问题时依据的信息就更全。但问题在于摊开的纸本身占据桌面空间而桌子空间有限满了之后不能再加纸。对LLM来说超过窗口之后要么报错要么自动截断最前面的内容。所以“上下文”不是白给的资源它是一块需要精打细算的“桌面空间”。很多人抱怨模型“记性差”往往是这块桌面空间被浪费了而不是模型本身不行。3.2 为什么模型会“忘记”你之前说的话这是高频困惑我明明在前面十几轮里把需求说清楚了为什么它聊着聊着就忘了原因主要有三个。第一长对话超过了上下文窗口。平台或框架会自动对历史消息做截断通常从最早的消息开始丢。你说过的话被丢掉了模型当然“忘了”。第二系统提示词、角色设定、检索到的RAG内容可能已经占用了大量窗口留给对话历史的实际空间比你想象的小。比如系统提示词有2000 Token你每轮问答两三分钟就聊了3000 Token几轮下来窗口就吃满了。第三注意力机制是概率性的。离当前问题太远的信息参与计算时权重通常更弱所以模型的表现会越来越倾向于只看最近的几轮。这不是“删除”更像是“被淹没”。理解这三点之后你就能明白为什么“多轮对话里无限堆积历史”是不可取的方案。3.3 “超长上下文”不是免费的你可能会想既然模型支持128K、200K上下文那我直接全塞进去不就行了技术上可以但工程上代价很大。注意力机制的复杂度大约是O(n²)n是序列长度。序列翻倍计算量大致变成四倍。推理时还需要为每个Token缓存Key和Value也就是KV Cache序列越长缓存占用的显存也线性增长。所以一个7B小模型如果你把上下文强行拉到32K甚至128K显存会快速告急。说得直白一点很多时候不是模型记不住是你的机器扛不住。还有一个模型本身的限制小参数模型即使宣称支持超长上下文它对长距离信息的利用能力也可能不如大模型。注意力权重在超长序列里容易慢慢涣散模型“能处理长文本”和“能处理好长文本”是两回事。所以你会看到生产环境里处理长文档时主流方案依然是分段、摘要、检索而不是一股脑全塞给模型。3.4 实操本地Ollama部署的Qwen2.5:7b记不住上下文怎么办搜索热词里出现了一个很典型的场景“本地Ollama部署的Qwen2.5:7b记不住上下文”。这几乎是每个本地部署玩家都会撞上的问题。先说排查顺序。第一确认Ollama的默认上下文长度。Ollama的默认num_ctx通常只有4096也就是说它一次只往模型里塞4096个Token。你聊几轮之后早期对话就被丢掉了。第二调整上下文长度。你可以在Modelfile里设置PARAMETER num_ctx 16384或更高然后重新构建模型也可以直接用/set parameter num_ctx 16384命令临时调整调用API时还可以传options.num_ctx。第三如果你的机器跑8K、16K上下文还是卡优先精简System Prompt控制每轮回复的长度让历史消息多撑几轮。第四注意一个容易被忽略的坑你查Qwen2.5的模型卡官方可能写着32K甚至128K上下文但Ollama并不会自动帮你把窗口设满必须显式指定。忘掉这一步你本地部署的模型永远只能用默认的短上下文。我给一个简单的参考7B模型跑4096上下文大概需要不到6GB显存跑16384上下文通常需要10GB以上具体取决于量化方式和实现跑32K上下文就要更高。显存不够时别硬撑试试GGUF低量化版本或者把上下文控制在8K以内。3.5 比“无脑加长上下文”更聪明的工程手段上下文压缩把历史对话定期总结成摘要塞回上下文里。本质是用几十个Token换几千个Token的“长期记忆”。RAG检索只把跟当前问题最相关的片段放进上下文而不是整篇文档。这是知识密集型应用的主流方案。滑动窗口本地推理时设置固定轮次只保留最近N轮对话。摘要记忆用一个小模型定期对历史做总结把摘要作为长期记忆的一部分。这些手段本质都是在“有限窗口里做取舍”。理解这一点你就能理解为什么现在“上下文工程”这个词会流行起来因为它是在解决一个真实存在的资源瓶颈问题。4. 采样参数决定输出风格的旋钮4.1 从概率分布到实际输出模型在预测“下一个Token”时会为词表里的每个候选Token计算一个分数logits分数越高代表模型认为这个Token越合适。但分数不能直接拿来选需要先通过softmax转成概率分布再把分布“调整”一下最后按调整后的概率采样得到结果。采样参数就是在这一步起作用的各种旋钮。不同平台的参数名略有差异但核心就那么几个temperature、top_p、top_k、frequency_penalty、presence_penalty。理解这些参数之前先记住一条总原则它们都是用来干预“随机性”的。有的让模型更保守有的让模型更奔放有的用来防止复读。你用好了模型输出质量上一个台阶用不好模型要么呆板得像复读机要么疯得像喝多了。4.2 temperature火候与“大胆程度”temperature控制的是概率分布的尖锐程度。你可以想象有一条曲线代表候选词被选中的概率temperature降低曲线变尖锐少数高概率Token被选中的机会大大增加输出越来越确定temperature升高曲线变平缓低概率Token也有机会冒出来输出更有创造性但更容易跑偏。实际操作中我常用的区间是这样的代码生成、JSON结构化输出、数学计算temperature尽量低0到0.3之间输出更可控能少很多莫名其妙的格式错误。通用对话、翻译、摘要0.3到0.7有一定灵活性又不至于失控。头脑风暴、创意写作、故事创作0.7到1.2甚至更高但要接受胡说八道率上升。一个很经典的坑是很多人以为temperature0就是“每次输出一模一样”。在绝大多数API里它确实接近贪心解码但因为采样还受其他参数影响并且有些实现里即使temperature0平台也会做微小的概率扰动所以仍然可能产生细微差异。如果你追求严格一致除了把temperature调到最低也要把top_p拉高比如接近1避免额外的截断导致随机变化。4.3 top_k与top_p限制候选范围的两种思路temperature管的是“高概率和低概率之间差距有多大”但模型可能给几万个Token都分配了一点概率。如果不加限制采样时就要从整个词表里抽效率低且质量不可控。于是有了两种截断方式。top_k只保留概率最高的K个Token其余全部设为零。比如top_k50就是只看前50个候选。top_p核采样按概率从高到低累加直到累计概率达到p比如0.9只在这个集合里采样。很多主流平台默认组合是temperature配合top_p一起用。我的建议是不要同时把temperature和top_p都拉得很低很极端那样输出会非常干。想增加创造性优先动temperaturetop_p保持在0.8到0.95之间比较稳妥。需要特别注意的是不同平台对“top_p”的默认值差异很大。有些默认为1有些默认为0.9。如果你发现两个平台用同样提示词跑出差异很大的结果先检查一下这些默认参数是不是不一样。4.4 frequency_penalty与presence_penalty两种“防复读”机制这两个参数都是对已经出现的Token做惩罚区别在于惩罚方式。presence_penalty只要某个Token在前面出现过就给它降权一次不管出现多少次。简单说就是“鼓励模型说新东西”。frequency_penalty惩罚力度跟Token出现的次数成正比。出现次数越多以后被选中的概率越低。适合压制“车轱辘话来回说”的现象。用法上frequency_penalty适合长文本生成比如写文章时防止同一句话反复出现presence_penalty适合开放对话、头脑风暴让模型主动换话题。但这俩也别拉满拉满的结果是模型为了“说新词”开始乱入不相关的内容看着新颖实际逻辑稀碎。还有一点容易忽略penalty参数的正负方向在部分平台上可能相反。有的平台用正值表示惩罚有的平台习惯用负值表示惩罚。同步代码或对比配置时先把符号确认清楚。4.5 不同任务的参数组合建议整理一张我比较常用的参考表以OpenAI系常见API参数范围为例其他平台名字类似任务场景temperaturetop_ppresence_penaltyfrequency_penalty代码生成/数据提取0~0.30.9~100翻译/摘要0.3~0.50.900通用对话0.70.90.30.3头脑风暴0.9~1.20.950.50长文创作0.7~0.90.950.30.5不要把这个表当成万能公式。不同模型对同一个参数的反应差异很大同一个模型的不同版本也会变化。最好的办法是写一个简单脚本固定提示词、批量跑不同参数把输出对比着看。这个方法比任何网上贴出的通用参数表都更可靠。5. 把三件事串起来一次完整生成过程的微观视角5.1 从输入到输出的完整链路做一个“纸上推演”用户输入一段中文问题模型本地或云端要经历什么第一步对输入文本做Tokenizer处理切成一串Token ID。第二步把这串Token ID和上下文窗口里已有的历史Token拼起来形成模型输入序列。第三步模型逐层做Transformer计算通过注意力机制计算序列里每个Token之间的关系找出与当前生成最相关的信息。第四步输出层得到所有候选Token的logits分数。第五步采样参数上场先做温度缩放再做top_p或top_k截断再叠加重复惩罚最后从概率分布里采样出第一个Token。第六步把这个Token追加到输入序列末尾重复第三步到第六步。第七步直到模型生成结束符或者达到最大输出长度停止。这个过程听着简单但对大模型来说每一个新Token的生成都意味着一次完整的前向计算而不是“想好了整段再输出”。所以你会感觉输出是一个字一个字蹦出来的。也因此输入越长每一步计算量越大输出越慢。有些平台按输出Token数量计费也跟这个机制有关系——你生成越多它计算越多。5.2 为什么“上下文工程”往往比“调参”更优先我把这条放在快结尾的重点很多人遇到模型输出不对第一反应是去调temperature、top_p但其实大部分问题出在上下文上。模型输出质量上限很大程度上由“它能看到的上下文”决定。如果你喂给它的信息本身缺失、矛盾、顺序混乱参数怎么调都救不回来。相反一组合适的System Prompt、几条排版整齐的示例、一段相关的背景资料对输出的提升往往比把temperature从1调到0.5明显得多。这就是“上下文工程”的核心思路组织输入信息让模型更容易发挥。典型的手法包括角色设定、Few-shot示例、把关键信息放在开头和结尾、避免矛盾信息、把复杂任务拆成多步。这些投入的性价比通常远高于反复试参数。我见过不少项目模型从7B换到70B效果提升有限但把提示词和数据处理流程重新梳理一遍之后同一个7B模型的回答质量发生了质变。这不是说大模型不重要而是说明很多团队在“模型端”投入了过多关注在“推理端”只花了极少的精力。5.3 一个实际案例输出不对时先查哪里分享一个我在项目里经常复用的排查顺序。先看输入模型拿到的上下文里最关键的需求是否清晰有没有被截断有没有把旧版本的需求和新版本的需求混在一起再看格式有没有要求JSON输出却不给示例有没有让模型从一段超长文本里抽取信息却没告诉它重点在哪然后看参数如果输出太跳降temperature如果太机械升temperature如果出现重复加频率惩罚。最后看链路日志里确认Token数量是否超了窗口、KV Cache是否溢出、模型加载的上下文配置是否生效。这个顺序可以把“调参焦虑”控制在一定范围内。先保证输入没问题再碰参数否则你在错误的方向上调半天最后只能得出“这个模型不行”的错误结论。6. 常见问题速查与踩坑实录6.1 一张速查表下表整理了我长期使用LLM过程中遇到的高频问题和排查方向现象可能原因排查/解决思路模型忘记前几轮说过的话超出上下文窗口历史被截断增大上下文长度如Ollama的num_ctx、精简System Prompt中文回答Token消耗特别快中文分词后Token数偏多估算时按1汉字约等于1到1.5 Token精简提示词输出总是重复同一句话缺少重复惩罚或temperature偏高提高frequency_penalty适当降低temperature输出天马行空、逻辑乱temperature或top_p过高降到0.7以下top_p设0.9左右风格死板像在复读temperature过低提到0.7到1.0加少量presence_penalty本地推理显存爆掉上下文太长导致KV Cache过大减小上下文长度或改用更小/更低量化的模型调用API报Token相关错误可能是鉴权Token失效也可能是超出上下文限制先区分是LLM Token还是JWT Token再查上下文和模型限制同一组参数在两个平台效果差异大默认参数不同或参数名语义有区别逐一核对字段默认值和正负方向6.2 几个亲身踩过的坑第一个坑本地Ollama部署时想当然地以为模型卡上写的“32K上下文”会自动生效。结果跑了几轮长对话后模型效果明显变差查了半天才发现是默认num_ctx只有4096。后来我在Modelfile里显式写死num_ctx问题才算解决。这个坑特别隐蔽因为模型本身并没有报错它只是“安静地截断”了。第二个坑做知识库问答时为了“让模型更聪明”我把整篇长文档全部塞进Prompt。结果文档5万Token一问一答就烧掉大几万Token的输入费用推理时间也明显变长。后来改成对文档做分块加向量检索只把相关片段塞进上下文效果反而更好成本和延迟都降下来了。这件事让我深刻理解了“少即是多”在上下文里的含义。第三个坑调temperature时踩过“只看参数不看任务”的坑。当时写创意文案我直接拉到1.5输出确实是天马行空但很多文案连产品名都能写错。从那以后我养成了一个习惯调参数之前先问自己这个任务允许模型“放飞自我”吗如果不允许temperature尽量别超过1.0。6.3 关于参数调整的一个实用习惯最后分享一个对我有用的习惯维护一份“参数动物园”笔记。每次换模型、换任务时我都是固定提示词加批量参数组合把输出记录下来归纳成“这个任务在这个模型上哪个参数区间效果最好”。等你跑的模型多了就会发现不同模型对同一个参数的反应差异很大网上别人推荐的参数只能当起点不能当终点。花半小时做一次参数对比实验往往能帮你省下后面几十个小时和模型“斗争”的时间。