LLM 运行机制：Token、上下文窗口与采样参数怎么影响输出

大模型为什么会对简单算术翻车？为什么同一个问题问两次答案不同？为什么它偶尔一本正经地胡说八道？这些”玄学现象”在运行机制层面都有确定解释。这篇教程从 Tokenization、自注意力、Next Token Prediction 三个底层机制讲起，再讲采样参数与对齐训练如何塑造你最终看到的输出。

它解决什么问题

不理解运行机制时，LLM 是个黑盒：Prompt 只能靠玄学调试，参数只能照抄别人的配置，出了问题不知道往哪排查。理解机制之后，很多困惑会自然消散：

为什么模型会被”9.11 和 9.9 哪个大”难住？因为它看到的不是数字，而是被切碎的 Token 片段。
为什么长文档中间的约束容易被忽略？因为注意力的利用并不均匀，窗口也不等于”有效记忆”。
为什么温度设得很低输出仍有波动？因为采样只是解码的一环，服务端实现与模型版本也会引入差异。
为什么模型有时谄媚、有时过度拒绝？这往往是对齐阶段塑造的行为倾向，与知识本身无关。

核心原理

Tokenization：模型看到的不是文字

模型不能直接处理字符。文本先被 Tokenizer 切成 Token 序列，每个 Token 对应词表里的一个 ID，再查表变成向量进入网络。切分粒度既不是字也不是词，而是”统计上高频的片段”。

主流子词算法 BPE（Byte Pair Encoding）的直觉很朴素：从最小单元出发，反复把语料中出现最频繁的相邻片段合并成新片段，直到词表达到目标大小。训练完成后，高频词被整体保留为一个 Token，低频词则继续拆成更碎的子词。这个机制带来两个直接后果：

Token 与字数没有固定换算。英文大致 1 Token 对应 3~~4 个字符，中文常见 1~~2 个汉字一个 Token；生僻字、代码、多语言混排都会偏离经验值。预算阶段可以用经验值粗估，对账必须以 API 返回的 usage 为准。
模型的认知单元是片段而非语义。数字可能被切成奇怪的几段，拼写、算术、精确匹配类任务因此天然吃亏；词表覆盖差的罕见串会被拆得很碎，处理质量也随之下降。

另外，BOS、EOS、工具调用标记等特殊 Token 对用户不可见，却同样占用上下文窗口——精确计数时别手算，用官方 Tokenizer 工具。

自注意力：每个 Token 权衡所有 Token

Transformer 的核心是自注意力（Self-Attention）。不堆公式，一句话概括：预测下一个 Token 之前，序列里每个位置都会回头把所有位置权衡一遍，决定谁与当前预测最相关。

直觉上，每个 Token 拿着一个”我在找什么”的询问（Query），去匹配其他 Token”我是什么”的标签（Key），匹配度越高，就把对方携带的信息（Value）越多地汇聚过来。处理”动物没有过马路，因为它太累了”时，”它”这个位置会给”动物”远高于”马路”的注意力权重，代词指代由此被消解。多组注意力头并行工作，有的盯语法结构、有的盯指代、有的盯邻近位置，分工在训练中自发形成。

这个设计的代价同样明确：每个位置要与所有位置交互，计算量随序列长度平方增长。这就是长上下文又贵又慢的根源，也是 KV Cache、FlashAttention、滑动窗口注意力等优化存在的理由——它们压缩开销，但没有消除平方级复杂度的本质。

训练目标：Next Token Prediction

预训练的目标简单到令人意外：给定前面所有 Token，预测下一个 Token。模型在海量文本上反复做这道填空题，预测错了就调整参数，直到预测得足够准。

生成时是同一逻辑的镜像：模型输出词表上的概率分布，从中选一个 Token 追加到序列末尾，再以新序列为基础预测下一个，循环往复，直到产出结束标记或触及长度上限。这就是自回归生成——你看到的整段回答，其实是成千上万个单步预测串起来的结果。

深入机制

为什么”预测下一个词”能涌现出能力

一个看似机械的目标，为什么能训出会推理、会编程、会翻译的模型？关键在于：要把下一个词预测得足够准，模型被迫内化文本背后的一切规律。

想预测”巴黎是__的首都”后面的词，必须内化地理知识；想预测 Python 代码的下一行，必须内化语法、API 习惯与算法逻辑；想预测数学证明的下一步，必须内化推理链条。文本是世界的压缩投影，预测下一个 Token 就是在反向学习投影背后的世界模型。当模型与数据规模越过某个阈值，一些未被显式训练的能力——上下文学习（In-context Learning）、思维链推理——表现出”涌现”特征：小模型上几乎为零，大模型上突然出现。

但要保持清醒：涌现不等于理解。模型学到的本质是条件概率的极致拟合，它知道”什么词通常跟在什么词后面”，却没有内置的真假判断模块。幻觉不是 bug，而是这一目标的必然副产品——对不知道的内容，它同样会流畅地给出”最像正确答案”的续写。

采样：温度与 top-p 如何塑造输出

模型每步产出的是概率分布，不是唯一答案。从分布里挑哪个 Token，由解码策略决定。

Temperature（温度） 在概率归一化前缩放原始分数：低温放大高分选项的优势，分布变”尖”，输出趋于确定；高温拉平差距，长尾选项也能中签，输出更发散。T=0 通常被当作贪婪解码处理，即每步取概率最高者。

Top-p（核采样） 换了思路：不动分布形状，直接砍候选池。把候选按概率从高到低累加，累计达到阈值 p 就截断，只在这个”核”里采样。分布集中时池子自动收窄，分布平坦时池子自动放宽，比固定保留 k 个候选的 top-k 更能适应不同步态。

两者常组合使用：温度决定”多敢冒险”，top-p 决定”最多冒多大的险”。结构化提取用低温换确定性，创意写作用中高温放大多样性——但任何参数组合都替代不了 Schema 与服务端校验。

对齐流水线：预训练 → SFT → RLHF

预训练模型只是”续写机器”：你问”番茄炒蛋怎么做”，它可能续写”这是知乎上的热门问题，已有 300 个回答”。要变成助手，还要过两道关：

SFT（监督微调）：用人工编写的”指令—回答”样本微调，让模型学会”被提问时应该作答”这个交互范式，同时注入格式、语气与任务处理的先验。
RLHF（人类反馈强化学习）：先让人类对多个候选回答排序，训练奖励模型（Reward Model），再用强化学习让模型向”人类更偏好”的方向偏移——更有帮助、更诚实、更无害。实践中也有 DPO 等跳过显式奖励模型的偏好优化变体。

这条流水线解释了模型的很多”脾气”：爱说”作为 AI 助手”、对敏感话题过度拒绝、偶尔迎合用户的错误前提——这些是对齐塑造的倾向，而非预训练知识的反映。

工程实践

Token 预算按机制做：窗口要容纳系统提示、工具定义、历史消息、检索片段和输出预留，先估算各部分占比，再用真实 usage 校准；预留不足时按”砍检索片段 → 压缩历史 → 摘要长字段”的顺序腾挪。
长上下文不是免费午餐：注意力成本随长度平方增长，塞得越多越贵越慢，且中间位置的信息利用率天然偏低——关键约束放开头或结尾，别埋在正中间。
采样参数按任务分层：结构化任务低温（0~0.3），分析评审类中温，创意类高温；推理模型对采样参数的支持范围各不相同，以目标 API 文档为准，不要跨供应商照搬。
识别截断信号：finish_reason=length 说明输出被生成上限拦腰截断，结构化场景必须标记并把推理 Token 一起纳入排查，半成品 JSON 绝不能交给下游。

对比与权衡

维度	低温采样（T≈0）	高温采样（T≥0.8）
输出确定性	高，多次调用结果接近	低，每次差异明显
适用任务	结构化提取、分类、代码	创意写作、头脑风暴
典型风险	可能陷入重复循环	格式漂移、内容失控
配合手段	Schema + 服务端校验	后处理过滤 + 人工筛选

维度	预训练	SFT	RLHF
目标	学会语言与世界知识	学会指令遵循与交互格式	对齐人类偏好
数据	海量无标注文本	人工编写的指令—回答对	人类排序与偏好信号
产出	续写机器	能对话的助手雏形	有用且相对无害的助手