大模型到底在算什么：从"预测下一个词"讲起

我最早接触大模型时的困惑很朴素：它到底是不是在"查表"？为什么同一个问题问两遍答案不一样？后来把推理这条链路手动拆开走了一遍，很多模糊的地方才落地。这篇是我自己的一份备忘。

一、它真的只做一件事：给下一个 token 打分

不管模型多大，推理时做的事情只有一件——在当前位置上，对整个词表算一个打分，这个分数叫 logit。分数经过 softmax 变成概率分布，然后按某种规则挑一个 token 出来，接到原文后面，再把新序列整个喂回去，重复一遍。

所以它不是在"组织语言"，也不是在"想清楚再说"。它就是一直在做同一道单选题：下一个词最可能是什么。一段连贯的回答，是这个动作重复几百次的累积结果。

token 不是字，也不是词

模型处理的单位是 token，由分词器（主流是 BPE 类算法）切出来。经验上，英文一个 token 大约是 0.75 个单词；中文在不同分词器下差别不小，一个汉字大致对应 1 到 2 个 token。所以"这个模型支持 128K 上下文"里的 K，是 token 的 K，不是字的 K，中文实际能装下的字数要打折看。

我一开始常犯的错误是按字数估算长度，结果频繁超窗口。后来统一改成"估 token 一律往大了估"，就再没踩过。

二、温度不是"聪明程度"，是"敢不敢选第二个"

采样环节里最常提到的两个参数：

• temperature：softmax 之前把 logit 除以一个数。温度趋近 0，分布变尖，几乎总是选分数最高的那个，输出稳定但容易死板、复读；温度调高，分布被压平，低分 token 也有机会被选中，输出更"有创意"，也更容易跑偏。
• top-p（核采样）：按概率从高到低累加，累到超过 p 就截断，只在这一小撮候选里选。p=0.9 的意思是"只在覆盖了 90% 概率质量的那部分候选里挑"。

一句话记法：要事实、要格式稳定，温度和 top-p 一起往下调；要发散，只调 top-p 通常比单拉温度安全。

同一个问题两次答案不同，不是模型"心情不好"，就是这一层在起作用。温度设为 0 时，同输入同输出基本可复现——这也是我做对比实验时一定会先把温度钉死的原因。

三、参数规模意味着什么：一笔内存账

"7B""70B"里的 B 是 billion，指权重个数。7B ≈ 70 亿个参数。每个权重存成半精度（fp16/bf16）要 2 字节，所以光权重就是 7 × 10⁹ × 2 ≈ 14 GB，还没算上下文。

实际部署时很少用 fp16 跑，因为显存装不下。GGUF 这类格式做量化，把权重压到 4 bit 附近，等效约 0.5～0.6 字节/参数，7B 就落到 4～5 GB。代价是能力有损失，中文和数学这类对精度敏感的任务掉得比英文翻译更明显。

量级记住就够了：权重占用 ≈ 参数量 × 每参数字节数。具体数字换一张卡就换一套读数，别照抄别人的评测。

四、KV 缓存：为什么长对话越聊越慢

自回归生成时，第 n 步要给前面所有 token 算注意力。如果每步都从头算一遍，代价是平方级的，谁也受不了。工程上的办法是把前面 token 的 Key/Value 张量缓存下来，新 token 只需要算自己那一份，再和缓存做注意力——这就是 KV 缓存。

它的直接后果有三个，我当时是踩过才明白的：

1. 显存占用不只看模型大小，还看上下文长度。KV 缓存随"层数 × 注意力头维度 × 序列长度 × 精度字节数"线性增长，序列一长，它可能比模型权重还能吃显存。所以"模型只有 4 GB，我有 8 GB 应该够"这种推断经常不成立。
2. 解码阶段是访存瓶颈，不是算力瓶颈。每生成一个 token 都要把全部权重过一遍，算力大量闲置，所以首 token 慢（要处理完整段提示）和后续 token 匀速慢，是两个不同的问题，优化方向也不一样。
3. 重复前缀可以省下来，也就是各家推理引擎做的 prompt cache。但它是缓存，不会扩大窗口上限。

五、那它为什么会胡说

这是最容易误解的一点，我自己的理解是这样：

模型被训练去最大化"下一个 token 的似然"。语言上的流畅，和事实上的正确，在训练目标里根本不是同一件事。当训练数据里"某个说法后面常跟着某个说法"时，它就会顺着产出，哪怕那个说法是错的。它没有一个"我不知道"的内建出口——因为"我不知道"在语料里出现的位置，和一句自信的假话在语料里出现的位置，对它来说都只是统计模式。

几个常见的加重因素：

• 冷门知识在语料里稀疏，模型倾向于用高频句式把它"补齐"，看起来通顺，实质是编。
• 提示里的预设会直接影响输出。问"为什么 X 会导致 Y"，即使 X 根本不会导致 Y，模型也倾向于给出一个解释。
• 长上下文里的信息它未必用上。喂进去不等于读到了，也不等于它信。

所以我在用这类系统时给自己定了两条纪律：凡是它会自信给出具体数字、条款、接口参数的场景，一律要求它给出可核查的出处；拿不出出处的，当作候选假设，不当作结论。这条比任何提示词技巧都有用。

六、留几个我自己还没想明白的

写在这里提醒自己继续查：所谓"涌现能力"到底有多少是评测指标的阶跃造成的错觉；上下文里信息的利用是否真的存在"中间段落被忽略"的稳定偏好，还是任务相关的；以及长上下文的检索型评测，究竟测的是理解还是找词。这几个问题我目前看到的答案互相矛盾，先记着。