LLM：一台逐 token 续写的压缩机

它到底在做什么

大语言模型（LLM）的核心任务可以写得很朴素：给定已经出现的 token $x_1, x_2, \ldots, x_t$ ，估计下一个 token 的分布：

P(x_{t+1}\mid x_1, x_2, \ldots, x_t)

$x_i$ 是第 $i$ 个 token；竖线表示“在前文条件下”； $P$ 不是唯一答案，而是词表每个候选的概率。模型选出一个 token，把它接回输入，再做下一轮。聊天、写代码和长篇推理，表面差异很大，底层都由这个循环逐步展开。

预训练让模型阅读大量样本并反复纠正预测误差。为了更好地预测，它不得不把语法、事实共现、代码模式和某些推理规律压进参数。这像把互联网规律压成一组巨大的函数，而不是把原文逐页存进数据库。

因此模型可能重构出正确知识，也可能生成“语言上顺滑、事实上错误”的内容。参数记忆没有 URL、更新时间和事务一致性；需要当前事实时，搜索工具比要求模型凭记忆更可靠。

模型看见真实下一个 token，计算预测分布与目标的差距（loss），再用反向传播微调数十亿到数千亿个参数。这个阶段昂贵、批量、吞吐优先。

你发出请求后，服务读取已经训练好的参数，做前向计算，生成 token。普通 API 调用不会因为一次对话就永久改写基础模型。上下文让模型“在本次请求里记得”，但超过上下文窗口或新建会话，这份临时状态就不再自动存在。

参数可以看成模型学到的可调旋钮。更多参数通常带来更大表达容量，但不会自动保证更可信、更会用工具或更低延迟。MoE 更进一步：模型保存很多专家参数，但每个 token 只激活一部分，用“总容量大、单步激活少”交换路由与分布式通信的复杂度。

Grok-1 的“314B”指总参数规模；“每 token 选 2/8 专家”说明其前馈部分是稀疏激活。314B 总参数不等于每生成一个 token 都做一个 314B 稠密模型的全部计算，但 Attention、路由、被选专家及其他层仍要执行，不能简单除以四就得到精确激活参数。

上下文窗口像模型摊在桌上的工作区。窗口更大，可以同时查看更长的代码、文档和对话，但代价包括更多 Attention 计算、更大的 KV Cache 和更高输入费用。它也不保证模型能同等精确地使用窗口每个位置的信息。

Grok-1 公开配置是 8,192 token；Grok-1.5 发布时声明 128K；Grok 3 发布时声明 1M；Grok 4 Fast API 发布时声明 2M。这是能力演进的外部规格，不能反推出它们共用相同位置编码或 Attention 实现。

要准确续写代码，模型需要隐式追踪变量和语法；要续写论证，需要关联前提与结论；要回答问题，需要在参数与上下文之间匹配模式。规模、数据和后训练把这些局部预测能力组合起来，出现看似高层的技能。

但“会生成推理步骤”不等于“每一步都真实可靠”。工程上更稳妥的做法是：让模型拆解任务，让工具提供可验证结果，让程序验证结构与权限，让人复核高风险结论。