你跟 DeepSeek、通义、GPT 这类大模型聊过天，应该都见过那个画面------
问完问题，字是一个一个往外蹦的，像有人在你对面现想现说。
可模型没有意识，它不会现想现说。
你敲下回车的那一刻，它其实是在重复执行同一种生成过程。
我在《大模型推理时，到底在干一件什么事？》里讲过，一次推理其实分 Prefill 和 Decode 两步。那篇只是带过，这篇把每一步的输入、输出和节奏摊开讲。
Prefill：一口气把问题读进模型，吐出第一个 token
第一段叫 Prefill（预填充）。
它干的事很单纯：
把你整段提示词一次性送进模型，完成一次前向计算，并从最后一个位置得到第一个生成 token。
与此同时，还会为后面的 Decode 准备好 KV Cache。
说人话就是，模型先把你的问题从头读到尾，基于整段上下文，预测接下来生成哪个 token。
从"生成答案"这个视角看，你给的是 N 个输入 token，Prefill 最终先产出第一个生成 token。
所以为了方便理解，可以粗略看成 N 对 1。
它为什么叫"预填充"？
因为这一步会把读到的内容先整理、算好，并为后面的 Decode 准备好缓存，相当于先把饭盛好，后面才能一口一口吃。
Decode：一个接一个，吃到结束符才停
Prefill 给出第一个 token 之后，模型就进入 Decode（解码）阶段。
这一步的节奏完全变了：
上一步吐出来的 token，会被拿回来，作为这一轮新生成内容的一部分。
模型结合之前已经生成的上下文和 KV Cache，预测下一个 token。
每轮 Decode 新增处理的通常是 1 个 token，并预测下一个 token。
所以从生成粒度来看，Decode 可以粗略看成 1 对 1。
拿 "What is LLM inference" 这个提问串一下。
Prefill 读完整句话，假设这一次生成的第一个 token 是 LLM；
接着 Decode 上场：
把 "LLM" 喂回去，吐出 inference；
再喂 inference，吐出后面 "is the process of using a trained model to generate text" 里的下一个 token......一直这样接力。
模型这次的回答以 "LLM inference is..." 开头，所以前两个生成 token 恰好和问题里的词长得一样。
直到模型生成 EOS（End of Sequence，序列结束符），或者触发其他停止条件，才停下来。
你看到的"字一个一个蹦"，正是 Decode 阶段干的事。
一次 Prefill，加上多次 Decode
把上面两件事连起来，大模型一次生成的核心骨架其实就一句话：
一次 Prefill，加上多次 Decode。
Prefill 只跑一遍，负责处理完整输入、产生第一个生成 token，并准备好后续要用的缓存；
后面的 token，则由 Decode 一轮一轮地产生。
每轮 Decode 都会把新生成的 token 接入上下文，再预测下一个 token。
生成得越长，Decode 阶段通常就要执行越多轮。
小贴士：
你有时候会觉得模型"直接整段甩出来"，没有逐字蹦。
那只是前端显示策略不同------要么等模型全部生成完，再一次性把结果甩给你；要么边生成边往外吐。
底层没变，依然是自回归地一个 token 一个 token 生成的，区别只在于要不要走流式输出（streaming）。
两阶段之外，还有分词和持续调度
模型不直接读你的原始文字。
你的问题得先经过 Tokenize，才能变成模型真正处理的 token。
但在实际推理服务里，Tokenize 之后还不是简单地"直接跑模型"。
推理引擎会持续进行 Scheduling，根据请求状态、KV Cache、GPU 显存和计算资源等情况，决定这一轮调度哪些请求、处理多少 token，以及如何组织 Prefill 和 Decode 的计算。
也就是说，你以为的"模型推理"，背后其实是一整条流水线：
Tokenize → 持续调度 → Prefill / Decode 循环
每生成一个 token，都绕不开模型权重
还有一个容易被忽视的事实：
不管 Prefill 还是 Decode，每一步都要让模型的参数参与计算。
你下载模型时看到的 7B、8B，那个 B 是 Billion（十亿），7B 就是 70 亿个参数值。
圈内管这些参数叫 weights（权重）。
Prefill 要用这些权重处理整段输入；
Decode 每生成一个 token，也要再次使用这些权重完成一次前向计算。
这就意味着，参数量越大，每一步涉及的参数规模通常也越大，对计算和内存带宽的要求也往往更高。
小模型往往比大模型回得快，一个重要原因就是它每一步需要处理的参数规模更小。
当然，实际速度还会受到具体硬件和推理配置等因素影响。
推理引擎，本质就是把这两阶段组织起来
讲到这，结论就清楚了。
如果把问题简化到最核心的生成流程，推理引擎要做的，就是把 Prefill 和 Decode 这两类计算组织起来，再通过调度把它们串起来。
两阶段看着都叫"跑模型"，但干的活不太一样：
Prefill 是一次性把长输入跑完、顺手把缓存备好；
Decode 是反复跑单步、不断把新 token 追加进缓存。
这篇只把 Prefill 和 Decode 的接力关系拆了出来。
下一篇，我们把这整条流水线从 0 到 1 走一遍：
把本篇一带而过的 tokenize、scheduling 展开讲透，再补上 KV cache 预分配、embedding、detokenization，以及加载模型时到底在加载什么。