企业官网建设流程全解析

如果你最近在搭 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 个能立刻落地的方案

这个问题我几乎每次分享都会被问到。我的默认处理顺序是这样的：

1. 换更长的窗口。现在很多模型宣称支持 100K、200K 甚至 1M 窗口，适合偶尔处理超大文档。但注意长窗口不一定便宜，也不一定"真能记那么牢"。
2. 做历史摘要。对话类场景最推荐：超过阈值就触发"请先总结前面内容"，把旧消息替换成摘要继续对话，既保住重要信息，又稳定控制 token。
3. 上 RAG。把大段资料切块存入向量库，每次只检索与本次问题最相关的几段塞进窗口，而不是在每次对话里硬塞整本书。
4. 拆任务。长文档一次性问不了，就按章节分批提问，再把各批次结果汇总给模型做二次分析。
5. 明确告诉模型"只根据最近 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 在 T=0.3 和 T=1.3 下，结果像两个人写的。

4.2 按任务类型调 Temperature：代码、对话、创作各有各的档位

我平时调参的出发点不是"找最聪明的值"，而是"这个任务允不允许出错"。

需要提醒的是，很多 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 高不少的天花板。

这张表能解释一个常见误解：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 高频问题与对应解法速查表

把大家问得最多的问题和我的处理思路整理一下：

6.2 三条最想带走的实战心得

第一，上线前先做小规模压测。不要只测试"能不能答对"，要测"答对的时候花了多少 token、用了多长窗口、随机性有多大"。把这三个值固化进代码里再调参，否则你根本不知道效果变好是运气还是调参调出来的。

第二，给 prompt 和维护文档加"版本"意识。我习惯在系统提示词最前面写一行注释，记录这是第几版、token 预算多少、上次修改的原因。等团队协作时，这习惯会救命。

第三，新模型发布后别急着换。每次换模型都要重新验证上下文窗口的实际有效长度、默认参数、计费模式。这三个东西变一个，线上效果都可能变样。

这套心得是我在多个项目里反复踩坑换来的。技术文档不会告诉你"到底该怎么选"，只会给你一串参数范围。我现在的习惯是：遇到新模型，先花半天把这四项都测一遍——token 估个价、窗口做压力测试、Temperature 跑几个温度档、MoE 的话再测一下显存和吞吐，然后才敢往线上放。这四个概念看着是基础，但基础不打牢，后期优化寸步难行。