昨天面试官问我：一个 Prompt 进入大模型后，内部到底发生了什么？

Fri, 06 Mar 2026 03:44:58 +0000

昨天面试时，面试官抛给我一道很典型的问题：

“描述一下一个请求 prompt 经过 LLM 直到返回结果，这中间的推理过程，越详细越好。”

这类题看起来开放，实际上很考验基本功。

因为它不是在问你会不会背几个名词，而是在看你是否真的理解：

●一个请求在系统里是怎么流动的

●进入模型之后到底算了什么

●为什么大模型是一个 token 一个 token 地往外生成

●为什么会有 prefill、decode、KV cache、sampling 这些概念

●为什么工程侧还要引入 batching、FlashAttention、continuous batching 之类的优化

如果回答得太浅，就会变成泛泛而谈；如果一上来就扎进公式，又很容易失去结构。

我后来复盘了一下，觉得这道题最好的答法，不是“想到哪说到哪”，而是按一条完整链路去讲：服务层怎么处理请求，LLM 内部怎么做前向计算，生成阶段又是如何一步步产出结果的。这也是 GPT-3 所代表的自回归语言模型在推理时的基本工作方式：它不会在一次请求里更新参数，而是在固定权重下做前向传播，并逐 token 预测后续内容

一个高分回答，最好先把整体框架立住

如果让我在面试里先用一句话概括，我会这样回答：

一个 prompt 从输入到输出，大体会经历 6 个阶段：请求封装、tokenization、推理调度、prefill、decode、结果反解码返回。其核心本质是：模型先并行“读懂”整段输入，建立上下文状态和 KV cache，然后再进入自回归生成循环，每次只预测下一个 token。这种“自回归 + 不做本次梯度更新”的推理方式，正是 GPT 类语言模型的基本范式；而 Transformer 则提供了它内部 attention 和前馈网络的计算骨架。

这句话为什么重要？

因为它先把系统层和模型层分开了，也先把prefill和decode分开了。很多人答这道题失分，不是因为不会，而是因为把所有层次混在一起，听起来就没有脉络。

第一阶段：用户输入的 Prompt，并不是模型真正看到的内容

我们在聊天框里看到的是自然语言，但模型真正接收到的，通常不是这段原始文本本身。

在送入模型之前，服务层一般会先把 system、user、assistant 等多轮消息按固定模板组织起来，再补上一些特殊标记。随后，文本会经过 tokenizer，被切成 token 序列。像 OpenAI 开源的 tiktoken 就明确说明，它是一个用于模型的 BPE tokenizer。也就是说，对模型来说，文本首先会被变成一串离散的 token IDs，而不是“句子”本身。

这一层很多人容易忽略，但它很关键。

因为后面所有推理，都是建立在 token 序列上的。你输入的是一句中文、一段英文、还是一段代码，对模型来说，第一步都得先转换成 token IDs。

第二阶段：请求不会立刻进模型，而是先进入推理服务和调度层

在真实工程系统里，一个请求到达后，通常不会马上冲进 GPU 执行。

它往往还要经过一层推理服务框架，比如 TGI、vLLM 这一类系统。它们会负责请求排队、动态 batching、缓存管理、流式返回等工作。Hugging Face 的 TGI 文档明确把 continuous batching、token streaming、Flash Attention、Paged Attention 等列为核心特性；而 Transformers 的 continuous batching 文档也说明，这种动态调度的目的是提高 GPU 利用率、降低延迟，并允许请求在每一步动态加入和退出批次。

所以，从系统视角看，链路通常是这样的：

用户输入 → prompt 模板展开 → tokenization → 请求调度 / batching → 送入模型

这一步的意义在于：

模型推理不是单个请求的“裸跑”，而是和其他请求一起，由推理引擎统一组织和优化的。

我们上一阶段说的 tokenization ，严格来说，不属于 Transformer 前向推理本身，模型只接收 input_ids。但在现代推理服务里，tokenizer 往往和 serving 引擎绑定在一起，所以工程上看起来像是推理引擎在处理原始字符串。像 vLLM 就同时支持 text prompt 和 pre-tokenized prompt，两种模式都能跑。

用户通常把原始字符串发给后端；后端中的推理服务通常持有 tokenizer，先把字符串编码成 token IDs，再交给模型执行 prefill/decode。只有在某些架构下，tokenization 才会提前在客户端或独立预处理层完成。

第三阶段：进入模型后，token 会先变成向量表示

真正进入 LLM 后，第一步不是“开始回答”，而是把 token IDs 映射成高维向量。

这一步叫 embedding lookup。每个 token 都会查一张巨大的 embedding 表，得到自己的向量表示。到这时，模型才真正进入连续空间的数值计算。Transformer 的基础论文《Attention Is All You Need》所定义的，就是这样一种基于 attention 的序列建模方式。

不过只有 token 向量还不够，因为模型还得知道“谁在前、谁在后”。

早期 Transformer 使用位置编码，后来很多大模型会用 RoPE（Rotary Position Embedding）。RoPE 的核心价值，是把位置信息融入 attention 计算中，让模型在处理 token 时同时保留相对位置信息。

第四阶段：真正的“推理核心”发生在一层层 Transformer Block 里

这是这道题最核心的部分。

如果面试官说“越详细越好”，你就必须把 Transformer Block 讲清楚。

一个典型的 decoder-only LLM，每一层大体都会做两件事：

●第一，Self-Attention

●第二，FFN / MLP（前馈网络）

中间再配合残差连接和归一化。Transformer 论文给出的主体结构就是这样。

你可以把它想成：

●attention 负责“读群聊”

●FFN 负责“自己想一想、整理一下”

Self-Attention 在干什么？

可以把它理解成：当前位置的 token，要去看上下文里哪些 token 最相关。

模型会把当前隐藏状态投影成 Query、Key、Value 三组向量，然后通过 Query 和所有 Key 的相似度算出注意力权重，再对 Value 做加权求和。Transformer 论文把它定义为 Scaled Dot-Product Attention。

对于生成式语言模型，还有一个必须强调的点：causal mask。

也就是当前位置只能看见自己和前面的 token，不能偷看未来。这一点决定了模型天然是自回归生成的：它永远只能基于已有上下文，去预测下一个 token。GPT-3 论文里所讨论的 few-shot/in-context learning，本质上也是建立在这种自回归预测机制之上的。

关于 Q、K、V，可以简单这样理解：

Q = 我现在想找什么

K = 每个词身上贴的“索引标签”

V = 每个词真正携带、可被取走的信息。

最通俗的比喻是“图书馆检索”：

你现在脑子里有一个问题，这就是 Q（Query）；书架上每本书卡片上的主题标签，是 K（Key）；书里真正的内容，是 V（Value）。系统先拿你的问题 Q 去和所有标签 K 比一比，看看“像不像、相关不相关”；相关度高的那些书，它们的内容 V 就会被更多地取出来，最后合成当前这一步该看的信息。Transformer 论文对 attention 的定义，本质上就是“一个 query 对一组 key-value 对做匹配，输出是 values 的加权和”。

FFN 又在干什么？

如果说 attention 负责“从上下文搬运信息”，那么 FFN 更像是“对当前位置做进一步加工”。

它不会跨位置交互，而是对每个 token 的表示单独做非线性变换，把特征进一步提纯和增强。Transformer 论文把它称为 position-wise feed-forward network。

所以一个 Transformer Block 可以粗略理解成：

先决定我该关注上下文里的谁，再把取回来的信息做一轮更深的特征变换

注意在整个流程中，prefill 和 decode 阶段，都要做 self-attention 和 FFN。

但要分清楚：“都要做”不等于“做法完全一样”。

●Prefill 把整段 prompt 一次性送进去。这时每一层都会对这批 token 做 masked self-attention，然后再过 FFN。因为整段 prompt 一开始就都已知，所以这一步可以在单个请求内部并行处理很多 token。Hugging Face 对 prefill 的描述也是：prefill 会处理整段输入，并建立 KV cache。

●Decode 开始一个 token 一个 token 往后生成。这时每生成一个新 token，它仍然要在每一层里经过：一次 self-attention，一次 FFN

decode 不是把旧 token 全部再跑一遍 attention 和 FFN。有了 KV cache 后，旧 token 的 K/V 会被缓存起来；新 token 到来时，只需要为这个新 token 计算当前层需要的表示，再和历史 K/V 做注意力计算，然后继续过 FFN。Hugging Face 官方缓存文档明确说了：后续生成时，只传入尚未处理的新 token，并把 key/value 写入和读取自 cache。

FFN 就是 Transformer 每层里、紧跟在 self-attention 后面的前馈网络，本质上是对每个 token 单独做的 MLP 加工。在标准 LLM 里，prefill 和 decode 两个阶段都要经过 self-attention 和 FFN；区别只是 prefill 处理整段已知 token，decode 只处理当前新 token，并复用历史 KV cache

第五阶段：Prefill——先把整段 Prompt “读完”

很多人会误以为模型一进来就开始逐字生成。

其实不是。生成前通常会先有一个很重要的阶段：Prefill。

Prefill 的意思是：

先把整段 prompt 一次性跑完整个前向过程。

在这个阶段，模型会为输入中的所有 token 计算各层隐藏状态，并且生成后面 decode 要用到的 KV cache。Hugging Face 的缓存文档明确指出，KV cache 会把注意力层中之前 token 产生的 key-value 对存下来，后续生成时直接复用，从而避免重复计算。

Prefill 的一个重要特点是：

它通常可以高度并行。

因为整段输入已经完整给定了，GPU 能把很多矩阵操作一起做完。所以 prefill 更像“先整体读题”，吞吐通常更高。vLLM 文档也明确把 prefill 归类为更偏 compute-bound 的阶段

你可以把 prefill 想象成一个正在考试的人，prefill 就是他正在读题，把题目先读到脑子里，填充好上下文，然后再开始做答（输出 token）

第六阶段：KV Cache——为什么不会每次都重算全文

这部分是面试里非常加分的点。

因为它体现你不只懂“算法”，还懂“推理为什么能跑得起来”。

如果没有 KV cache，那么每生成一个新 token，模型都要把整个历史上下文从头再算一遍，成本会非常高。

而有了 KV cache 后，历史 token 在每层 attention 中算出的 K 和 V 都会被缓存起来。下一个时间步只需要为新 token 计算新的 Query、Key、Value，再用新的 Query 去和历史缓存里的 Key 做匹配即可。Hugging Face 的官方文档把这一点解释得很清楚：KV cache 的目标就是消除重复计算，加速自回归生成。

一句话说明就是：

●没有 KV cache，像每次都重读整篇文章

●有 KV cache，则像前文已经做好笔记，现在只补最后一句。

为什么 KV cache 只缓存 K 和 V，而不缓存 Q？

一个东西值不值得缓存，不看它“重不重要”，而看它“后面还会不会再次被用到”。

KV cache 只缓存 K 和 V，不缓存 Q，不是因为 Q 不重要，而是因为 Q “只在当前这一步有用一次”；而 K、V 会在后面每一步继续被反复用到。这正是 Hugging Face 官方对缓存机制的解释：过去 token 的 K 和 V 可以缓存并复用，而在推理时，只需要“最后一个 token 的 query”来计算当前步的表示。

第七阶段：Decode——开始逐 token 生成答案

当 prefill 完成后，模型已经“读懂”了整段输入。

接下来，系统会取最后一个位置的隐藏状态，通过输出层映射成整个词表上的 logits，也就是“下一个 token 的打分”。随后再通过 softmax 和解码策略，决定下一个 token 输出什么。Transformer 的输出逻辑与 Hugging Face 的生成文档都说明了这一点。

这里又有一个容易被问到的点：

下一个 token 是怎么选出来的？

并不是只有“选概率最大”这一种方式。常见解码策略包括 greedy、sampling、top-k、top-p 等。不同策略会影响文本的稳定性、多样性和创造性。Hugging Face 的生成策略文档对此有系统说明。

然后，流程进入一个循环：

●把刚生成的 token 接到上下文后面

●复用 KV cache

●只为这个新 token 跑一遍前向计算

●再得到新的 logits

●再生成下一个 token

这就是为什么你看到的大模型回答，总是一个 token 一个 token 流式地吐出来，而不是整段瞬间出现。

为什么“第一个字慢，后面快”？

这也是一个非常像面试 follow-up 的问题。

很多候选人知道 prefill 和 decode，但解释不清为什么两者速度特征不同。

vLLM 的优化文档明确提到，prefill 更偏 compute-bound，decode 更偏 memory-bound。

原因在于：prefill 可以把整段输入并行做大矩阵乘法，吃满 GPU 算力；而 decode 虽然每步只算一个 token，但它强依赖历史 KV cache，频繁访问显存，并且步骤之间有严格的顺序依赖。

这也是为什么工程上会有很多针对推理性能的优化，比如：

●FlashAttention：通过 IO-aware 的 attention 计算方式，减少显存读写

●continuous batching：动态调整批次，减少 GPU 空转

●chunked prefill / Paged Attention：改进长上下文和缓存管理效率

要注意，这些技术优化的是执行效率，不是模型的“语义本质”。模型本质上做的事情仍然是：基于已有上下文，反复预测下一个 token

我现在觉得，这道题最稳妥的回答方式，就是最后收束成一句话：

一个 LLM 请求的推理过程，本质上是：先把 prompt 模板化并 token 化，经由推理服务调度进入 GPU；模型通过 embedding 和多层 Transformer block 并行完成 prefill，建立上下文表示和 KV cache；随后进入 decode 循环，基于历史缓存逐 token 执行注意力、前馈网络和采样，直到生成结束，再把 token 序列反解码成文本返回。这条链路同时体现了 Transformer 的计算机制、自回归生成范式，以及现代推理系统在 batching、缓存和 attention kernel 上的工程优化

看起来都是推理引擎的活儿啊？

从整个流程上看，几乎都是推理引擎在负责，所以可以这么理解，但要再往前走半步：

●从“流程编排”角度看，LLM 本体确实很被动；

●从“核心计算与语义生成”角度看，LLM 才是全链路里最不可替代的部分。

如果把整个链路拆开，职责大致是这样的：

1.推理引擎 / serving 系统负责：接 HTTP 请求、做 tokenization / 输入处理、调度 batching、管理 KV cache、协调 GPU worker、流式返回结果、做一部分采样与系统优化。vLLM 的官方文档甚至把这几层写得很直白：最少会有 1 个 API server 负责 HTTP、tokenization 和输入处理，1 个 engine core 负责 scheduler 和 KV cache 管理，再加上 N 个 GPU worker 负责执行模型前向计算。

2.LLM 模型本体负责：对 input_ids 做 embedding，经过多层 Transformer block 的 self-attention 和 feed-forward network，输出 logits，也就是“下一个 token 的分数分布”。Transformer 论文给出的核心结构就是 attention + FFN；Transformers 文档也明确说 causal language modeling 本质上是在左侧上下文条件下做 next-token prediction，而模型输出里的 logits 是对词表中每个 token 的预测分数。

所以，**推理引擎决定“怎么高效地跑”，模型决定“到底生成什么”。**前者偏“编排与优化”，后者偏“语义计算与内容生成”

VLLM on 小盒子的技术分享