一次请求的旅程：从按下回车到看到字

这一篇把前九篇的名词串成一条线。看懂这条线，大多数「为什么慢/为什么贵/为什么答非所问」都能自己定位。

第 1 步：拼装上下文

程序把你的输入、对话历史、系统提示、检索到的资料拼成一大段文本。这一步决定了模型能看到什么——它看不到的东西，后面无论多强都不会出现在答案里。（对应「上下文窗口与记忆」）

第 2 步：分词

文本被切成 token（模型眼里的单位）。中文常一字 1～2 token，代码和专有名词更容易被切碎。token 数决定后续所有计算量与费用。（对应「术语地图」「成本与速度」）

第 3 步：读入（prefill）

模型把整段 token 一次性过一遍网络，为每个位置算出中间结果并存进 KV cache。这一步是并行的，所以再长的上下文也不是按比例变慢，但它决定「第一个字要等多久」。上下文越长，等得越久。

第 4 步：逐 token 生成（decode）

从这一刻起，模型每次只产出一个 token，然后把它接回输入再算下一个。串行，这就是生成速度的上限来源。KV cache 让每一步不必从头重算，但省不掉「一个一个写」这件事。（对应「术语地图」里的 KV cache）

第 5 步：采样

模型对下一个 token 给出概率分布，采样策略决定选哪个：温度低 → 倾向选最高概率，稳定重复；温度高 → 允许选冷门候选，多样但更容易错。top-p/top-k 是先砍掉长尾候选再抽。（对应「术语地图」）

第 6 步：停止条件

遇到结束标记、达到长度上限、或命中你设的停止词，就停。被截断通常是「长度上限设太小」，不是「它不想说了」。

第 7 步：反分词与流式输出

token 变回文字，通常边生成边推给你（流式）。所以你看到字是一段段冒出来的——它真的是一段段生成的，不是先想好整段再显示。

第 8 步：计费与日志

输入 token + 输出 token 分别计费；服务端可能留存日志（取决于条款）。（对应「数据与合规边界」）

这条线解释了什么

现象	在哪一步
长对话越来越贵、越来越慢	第 1、3 步：历史被重发
资料给了却没用上	第 1 步：位置或挤占问题
回答到一半断掉	第 6 步：长度上限
同一个问题每次答案不同	第 5 步：采样
首字等很久但出字很快	第 3 步慢、第 4 步快
换小模型省钱但推理变差	第 3、4 步省了，能力也降了

自检：随便挑一个你遇到的 LLM 问题，能不能指出它发生在第几步？能指出，就说明这一档你过关了。