如果你最近在搭 AI 工具、调试提示词或者被领导点名研究大模型那你大概率已经见过这几个词Token、上下文窗口、Temperature、MoE。说实话我刚带项目那会儿这四个词也让我绕了不少弯子以为 Token 就是字数结果第一次对账账单比心理预期高了一截以为上下文窗口越大越省心结果塞了一堆聊天记录进去模型该忘的还是忘Temperature 更邪门同一个问题0.3 和 1.2 能给出两个物种的回答。至于 MoE第一次听人介绍总参数 47B、激活参数 13B的时候我差点以为对方在说绕口令。这篇就把这四个概念一次讲透。我尽量不堆论文术语用做产品、调接口、部署模型时真正会用到的视角来讲把背后的原理、估算方式、踩坑点都摊开。它适合正在用 API 做应用、准备私有化部署、或者想从会调用跨到懂原理的朋友。不管你是只想把接口调好还是要自己部署模型这四个概念都会直接影响你的效果、成本和稳定性。1. 先建立整体认知大模型到底是个什么机器1.1 大模型不是查资料是猜下一个词很多人以为大模型像个超级搜索引擎问它问题它就去数据库里把答案检索出来。实际完全不是这样。大模型本质上是一个条件概率预测器给它一段文本它预测接下来最可能出现的 token 是什么预测完一个把这个 token 接到原文后面再预测下一个。整个对话过程其实就是模型在源源不断地接龙。这个机制解释了很多奇怪现象。比如它为什么能写代码因为训练数据里有海量代码模型学会了看到 if 后面一般接什么它为什么偶尔会一本正经地胡说八道因为它本质上是在说这个位置最像真的答案是这句而不是在数据库里验证过。我经常跟同事开玩笑大模型不是一个记忆力超群的好学生而是一个看过无数范文、特别擅长续写的老手。理解这一点至关重要。因为后面所有概念——上下文窗口、Temperature、MoE——都是在回答同一个问题的不同侧面这个接龙机器用什么原料、能看多远、有多大胆、内部怎么分工。1.2 把四个概念放进一条流水线里看我给团队做培训的时候喜欢把这四个概念串成一条流水线Token 是原料。大模型不直接读字它把文本切成 token 再处理所以 token 的数量直接决定成本和长度。上下文窗口是工作台。工作台就那么大一次能摊开的原料有限。你塞进来的东西越多它当下能看到的内容越多但台面会被占满。Temperature 是操作员的性格。同样一堆原料保守的操作员永远只选最有把握的做法激进的操作员时不时会尝试点新花样。MoE 是车间架构。有的工厂是一个全能班组干所有活有的工厂是前台把单子分给各个专业班组MoE 就是后者的自动化版本。这四条线不是孤立的。比如你把上下文窗口顶满又调高了 Temperature模型很可能因为看得多、想法多而开始跑题你让 MoE 模型的某个专家长期空闲微调后模型反而可能变傻。后面每一节我都会穿插这种关联帮大家建立整体感而不是背几个孤立定义。2. Token大模型的字数统计到底怎么算2.1 为什么大模型不按汉字计数如果你在文档里看到本模型上下文长度 8K这里的 8K 指的是 token 数不是字数。分词器Tokenizer会把自然语言切分成模型认识的最小单位。英文里一个常见单词通常是一个 token比如 hello 是一个 token中文里因为信息密度高一个汉字常用 1 到 1.5 个 token生僻字还可能有特殊拆分。我刚开始也很不解中文一个字明明表意完整为什么要拆因为大模型的词表不是按人类字典设计的而是通过 BPE字节对编码这类算法从训练语料里统计出来的高频片段。代码里的常见关键字、英文常见词缀、中文里的常用字和词都会成为独立的 token。所以同样内容中英文表达的 token 数往往不一样同一句话换一个模型的分词器token 数也可能有偏差。这里给一个粗略估算标准虽然不是官方精确值但足够支撑日常评估不同模型的分词器有差异但偏差不会太夸张中文文本1 个汉字约等于 1 至 2 个 token常用字你、的、是通常是 1 个 token。英文文本1 个单词约等于 1 至 1.3 个 token。代码文本常见关键字会合并token 效率通常比自然语言高1 行简单代码约 3 至 6 个 token。比如一段 1000 字的中文产品介绍按 1.5 估算就是 1500 token 左右。如果模型按输入 token 计费那成本心里就有数了。提示做需求评估时用中文按 1.5 token/字、英文按 1.2 token/词估算基本不会出大错。真要精确还是得用对应模型的分词器把文本跑一遍。2.2 Token 数量决定账单输入输出都要算钱大模型计费、限流、上下文限制全都围绕 token 展开。一次 API 调用花的钱大致是费用 输入 token 数 × 输入单价 输出 token 数 × 输出单价这里有两件事必须注意。第一很多产品输入和输出 token 的价格不一样通常是输出更贵因为生成是一个 token 一个 token 地推理比并行处理输入要更耗算力。第二多轮对话时每一次新请求都会把之前的聊天记录全部拼进输入里重新计算不会因为上次算过就便宜。所以对话轮次越多你其实在反复为那些旧消息付费。我帮朋友做过一次调用量估算一个客服机器人平均每轮请求消耗 1200 个输入 token、300 个输出 token一天 1 万次调用那么一天输入消耗就是 1200 万 token、输出消耗是 300 万 token。按常见的输入百万 token 几十元、输出百万 token 上百元的价位一天几百到上千元很正常。很多团队看到账单才反应过来省 token 就是省钱而且是最直接的成本优化手段。2.3 压缩 Token 的几个立竿见影的手段我在项目里压 token 的体感非常明显。最常用的几条把固定不变的说明放到 system 提示词里并且尽量写短。能一句话说清的就不要用两句话。少样本示例只保留最典型的 1 至 2 个。很多人一上来贴 5 个例子效果没提升多少token 却翻倍。多轮对话做历史压缩。当聊天记录快满时让模型先把前面的内容总结成 100 字以内的摘要再带着摘要继续聊而不是原样搬运所有消息。批处理任务把公共字段名、公共背景写成一段常量在请求时直接引用避免每次拼重复文本。我自己做过一个日志分析工具最初把字段说明和示例贴在 prompt 里每次调用要 2200 个 token后来抽成公共配置加摘要降到 900 个 token。功能没降单次成本直接省了六成。在这种基础细节上多抠一抠比单纯换个便宜模型来得更实在。3. 上下文窗口大模型的工作台就那么大3.1 输入和输出共用一个窗口先搞清这件事上下文窗口是指模型单次能看到的最大 token 数量。很多人误以为 8K 窗口就是能输入 8K、再输出 8K实际是输入和输出加在一起不超过 8K。你 prompt 写了 7000 token那么模型最多只能生成 1000 token 的回复。这个误解造成的典型事故是输出截断句子停在半路看起来像模型突然傻了。窗口内的信息也不是一视同仁的。实验和实战都有一个共同观察模型对开头和结尾的内容把握最好对埋在中间的大段内容容易忽略研究者管这叫 lost in the middle。我做长文档问答的时候把关键结论放在文档末尾反而经常被漏掉放在对话末尾或者开头显著位置准确率立刻上来了。这块工作台不但有物理限制还有个注意力偏心的问题。3.2 窗口用完了怎么办5 个能立刻落地的方案这个问题我几乎每次分享都会被问到。我的默认处理顺序是这样的换更长的窗口。现在很多模型宣称支持 100K、200K 甚至 1M 窗口适合偶尔处理超大文档。但注意长窗口不一定便宜也不一定真能记那么牢。做历史摘要。对话类场景最推荐超过阈值就触发请先总结前面内容把旧消息替换成摘要继续对话既保住重要信息又稳定控制 token。上 RAG。把大段资料切块存入向量库每次只检索与本次问题最相关的几段塞进窗口而不是在每次对话里硬塞整本书。拆任务。长文档一次性问不了就按章节分批提问再把各批次结果汇总给模型做二次分析。明确告诉模型只根据最近 N 轮回复并在代码里裁掉更早的消息。简单粗暴但很有效。我一直强调窗口更像办公桌而不是仓库。你要做的是把最常用的东西摆在桌面上其余放回抽屉外置知识库而不是不停地换更大的桌子。3.3 长窗口没有那么神选型前先做压力测试有些朋友一看到支持 200K 上下文立刻把整个项目文档塞进去。实测下来往往发现响应变慢、成本升高但关键内容还是可能丢。原因是长文本对注意力机制的计算压力很大位置编码也要处理超长序列很多模型的有效长度其实低于宣传值。我在给项目选型时做过一次土味压力测试把一篇 5 万字的技术文档放在不同位置连续问 20 个问题看哪些信息能稳定答对。结果很说明问题即便用长窗口模型埋在文档中间的问题依然容易答错。所以选模型不要只盯着宣传页上的最大窗口要看它在你自己数据上的实际表现。至少准备一套和业务相近的测试集跑一轮再决定。4. Temperature让模型按部就班还是天马行空4.1 一个公式看懂 Temperature 在改什么大模型每生成一个 token都会给词表里每个候选算一个分数logit然后用 softmax 变成概率分布。Temperature 就是在这个环节介入的先把每个 logit 除以 T再做 softmax。P(token_i) exp(logit_i / T) / Σ exp(logit_j / T)T 等于 1 时是原样输出T 小于 1 会让原先的高分候选概率更高、低分候选概率更低模型变得派系分明更保守T 大于 1 则把概率抹平低分候选也有机会冒头输出就跳跃、更有创造力。举个例子。假设某位置上三个候选词的原始概率是 0.8、0.15、0.05。T 调到 0.2 后第一个候选接近 1.0几乎稳赢T 调到 1.2 后第二个、第三个候选被选中的概率明显上升回答就开始飘了。这也是为什么同一个 prompt 在 T0.3 和 T1.3 下结果像两个人写的。4.2 按任务类型调 Temperature代码、对话、创作各有各的档位我平时调参的出发点不是找最聪明的值而是这个任务允不允许出错。任务类型推荐 Temperature原因代码生成、SQL 编写0 至 0.3代码错了就是错了需要确定性和可复现性数学、数据抽取、JSON 输出0 至 0.2必须严格从原文提取不能自由发挥通用对话、文案草稿0.7 至 0.9保留一点变化又不太容易跑偏头脑风暴、故事创作1.0 至 1.3需要模型跳出常规适当冒一点险技术翻译0.3 以下术语要稳不能每轮译法不一样需要提醒的是很多 API 不允许把 Temperature 设为 0最小值可能是 0.01 或 0.1目的就是防止完全锁死。另外别只看 Temperature服务端的采样实现、随机种子、beam search 都会影响确定性。做自动化测试时最好把 max_tokens、Top-p 一起固定才能比较出参数变化带来的真实差异。4.3 和 Top-p、Top-k 搭配别同时开两个脑洞阀门除了 Temperature你还会在 API 文档里看到 Top-p 和 Top-k。Top-k 是只从前 k 个最高分候选里选Top-p 是不断往候选池里加 token直到累计概率超过 p。它们和 Temperature 是同一件事的三种旋钮都是控制候选池和池内的倾向性。我的建议是先固定 Top-p 在 0.9 左右保留大部分高概率候选、裁掉长尾再单独调 Temperature。尽量不要一边把 Temperature 调高一边把 Top-p 也放宽到 0.98 以上两个脑洞阀门同时打开输出会很快滑向胡言乱语。反过来如果你要绝对稳定就把 Temperature 调到最低Top-p 收紧到 0.8甚至可以固定随机种子。5. MoE大模型界的专家会诊模式5.1 什么是 MoE把大网络拆成一群专家MoE 的全称是 Mixture of Experts混合专家。它的核心思想是把模型内部的一部分结构通常是 FFN 层复制成多个专家子网络再添一个路由器。输入的一个 token 不用经过所有专家的手而是由路由器判断这个问题更像哪类然后只激活 top 2 或者 top k 个专家。打个比方一个全能型公司每个部门都能处理所有客户需求这是传统的 Dense稠密模型MoE 则是前台根据需求把单子分给对应部门——法务问题找法务、技术问题找技术没必要让所有部门都参与进来。训练的时候这些专家会自动分化有的擅长代码有的擅长数学有的擅长中文表达。目前很多大模型都用了 MoE 架构。你在开源社区里看到总参数量巨大但跑起来速度却不像那么大的模型大概率就是 MoE。这也是为什么 MoE 越来越受关注在有限的算力预算里它可以塞进更大的知识容量。5.2 总参数 vs 激活参数MoE 到底省了什么MoE 最核心的两个指标是总参数和激活参数。总参数是权重文件占用的量激活参数是处理一个 token 时真正参与计算的量。以开源社区常用的 Mixtral 8x7B 为例它由 8 个 7B 级别的专家组成加上共享部分总参数约 47B但因为每个 token 只激活其中 2 个专家激活参数只有约 13B。这意味着推理时的计算量接近一个 13B 的密集模型但表达能力理论上能摸到比 13B 高不少的天花板。模型类型总参数激活参数推理算力显存占用FP16Dense 13B13B13B全部计算约 26GBMoE 8x7B约47B约13B接近13B约94GB这张表能解释一个常见误解MoE 推理速度快但不代表它省显存。所有专家的权重都得加载到内存或显存里只是每个 token 不用全部算一遍。很多人第一次部署 MoE看到47B就以为和运行一个 47B 的 Dense 模型一样难。其实难点主要在于权重大、显存占用高而不是计算量本身。想单卡跑起来通常要做量化比如 GGUF 的 Q4/Q8或者用多卡分流。5.3 部署和微调 MoE三个容易踩的坑如果你不满足于调用 API而是想本地私有化部署 MoE 模型有几个坑我得提前帮你标出来。第一推理框架要选对。用原版 Transformers 直接跑 MoE速度会很难看因为吞吐优化不到位。建议优先用 vLLM、SGLang、TGI 这类对 MoE 做过优化的框架它们在显存调度、专家并行上都有专门处理。第二显存估算要按总参数算不能只看激活参数。量化的精度选择需要权衡一般 Q4 量化在效果和资源占用之间最容易平衡。第三微调时留意专家失衡。如果你只用某一类垂直数据做微调路由器可能把所有 token 都分给同几个专家其他专家长期闲下来最后模型整体能力反而会下降。训练时最好开启负载均衡损失或者保证微调数据的覆盖面。MoE 不是一个开箱即用更强的银弹。它适合预算有限、想把大模型能力塞进已有推理服务的场景如果只是个人实验先跑 Dense 小模型把流程打通再切 MoE 会更稳妥。6. 项目实战中的排错速查与经验沉淀6.1 高频问题与对应解法速查表把大家问得最多的问题和我的处理思路整理一下现象常见原因处理方法回答到一半突然断了输出 token 上限设得太小调大 max_tokens或压缩 prompt 给输出腾空间同样问题每次答案差很多Temperature 偏高降到 0.2 以下必要时固定随机种子多轮对话聊着聊着失忆上下文窗口被旧消息占满开启历史摘要滚动或换更长窗口模型生成明显跑题、放飞Temperature 和 Top-p 同时过高收敛参数T 降到 0.7 以内Top-p 收到 0.9本地部署 MoE 后爆显存按激活参数估算了显存按总参数算权重占用改用量化或多卡账单比预期高很多多轮历史 token 反复计费加日志统计每次调用的 token 数限制对话长度6.2 三条最想带走的实战心得第一上线前先做小规模压测。不要只测试能不能答对要测答对的时候花了多少 token、用了多长窗口、随机性有多大。把这三个值固化进代码里再调参否则你根本不知道效果变好是运气还是调参调出来的。第二给 prompt 和维护文档加版本意识。我习惯在系统提示词最前面写一行注释记录这是第几版、token 预算多少、上次修改的原因。等团队协作时这习惯会救命。第三新模型发布后别急着换。每次换模型都要重新验证上下文窗口的实际有效长度、默认参数、计费模式。这三个东西变一个线上效果都可能变样。这套心得是我在多个项目里反复踩坑换来的。技术文档不会告诉你到底该怎么选只会给你一串参数范围。我现在的习惯是遇到新模型先花半天把这四项都测一遍——token 估个价、窗口做压力测试、Temperature 跑几个温度档、MoE 的话再测一下显存和吞吐然后才敢往线上放。这四个概念看着是基础但基础不打牢后期优化寸步难行。