简介：在部署大语言模型时，推理性能往往不达预期。本文从系统视角出发，对比LLM推理中Prefill与Decode两个阶段的计算特征、资源瓶颈与优化侧重点，帮助开发者理解首token延迟与生成速度背后的技术原因，并为推理系统设计与选型提供判断依据。
很多团队在部署大语言模型时，会遇到一类看似矛盾的现象：显卡利用率并不低，但用户感觉响应很慢；或者首字延迟尚可，一旦开始输出，生成速度却明显下降。进一步观察还会发现，有些请求在等待队列中停留很久，有些请求则长时间占用计算资源，导致整体吞吐难以提升。
这些问题的根源往往不在模型本身，而在推理系统的设计。常见的做法是把一次完整的LLM推理当作同一种计算负载来处理，但事实上，一个大语言模型从接收提示词到完整输出答案，经历了两种截然不同的计算阶段。工程实践中，通常将这两个阶段分别称为Prefill和Decode。二者在计算模式、资源瓶颈和优化目标上差异显著，如果把它们混在一起调度，很难兼顾延迟、吞吐和硬件利用效率。
理解Prefill与Decode的差异，是部署与优化大语言模型推理服务的基础。本文将从计算过程、性能特征、资源瓶颈和系统优化方案等角度，对这一组核心概念进行对比分析。
Prefill阶段发生在模型接收用户输入的瞬间。用户提交的一段提示词，会首先经过分词器切分成多个token。Prefill要做的事情，就是把这些token一次性送入模型，逐层完成所有矩阵运算，并在这个过程中计算出后续生成所需的中间状态，也就是常说的KV Cache。
这个阶段的核心特征是“并行处理”。因为提示词的全部token在进入模型时已经确定，所以模型可以对它们同时进行计算。对于Transformer结构而言，注意力机制会对整个序列做相关性计算，其计算量随序列长度呈超线性增长。提示词越长，Prefill阶段耗时越明显。
如果把注意力计算抽象来看，当序列长度为N时，注意力矩阵的规模是N×N，相关的乘法运算量会随着N的增大急剧上升。这意味着Prefill阶段本质上是一个“算力密集型”任务，它需要GPU在短时间内完成大量矩阵乘法。
Decode阶段从模型开始输出第一个新token时启动。与Prefill不同，Decode是一个严格串行的过程：模型每生成一个token，就将这个token追加到已有序列末尾，再以更新后的序列为上下文预测下一个token。这个过程循环往复，直到满足停止条件。
Decode阶段每一步只需要计算“新来的这1个token”对应的Query、Key和Value，然后与已有的KV Cache进行交互。单步计算量很小，但问题在于步数很多。如果模型需要输出800个token，Decode就要循环800次。
每一次循环都涉及对KV Cache的读写。KV Cache存储的是每一层、每个注意力头、每个历史位置的Key和Value向量。随着生成序列变长，KV Cache的体量持续增加，每一步Decode都需要访问这一大块数据。因此，Decode阶段的核心瓶颈往往不在GPU算力，而在内存带宽——数据搬运的速度决定了token的生成速度。
尽管Prefill和Decode差异很大，但二者服务于同一个目标：完成一次高质量的语言生成。它们共同构成了自回归生成的完整链路，并且共享同一套模型权重和网络结构。
从数据流角度看，Prefill是Decode的前提。没有Prefill阶段计算出的KV Cache，Decode就无法开始。反过来，Decode是Prefill的目的——用户提交提示词，是为了获得模型后续的生成结果。二者在时间轴上前后衔接，在资源使用上也共享同一份显存和同一套计算单元。
Prefill的计算模式接近于传统的深度学习前向推理：数据一次性进入，各层之间顺序执行，但层内的token之间可以高度并行。这使得Prefill天然适合GPU的大规模并行架构，容易把计算单元“喂饱”。
Decode的计算模式则更接近循环推理：每一轮只处理一个新token，计算量小，但必须重复执行。GPU的并行优势在单步计算中几乎发挥不出来，反而是内存子系统的吞吐能力决定了整体速度。
Prefill的主要瓶颈在算力。当提示词较长时，注意力矩阵的计算规模迅速膨胀，GPU的浮点运算单元会处于高负载状态。此时优化的关键是如何更高效地利用算力，比如通过批处理把多个请求的Prefill阶段合并执行。
Decode的主要瓶颈在带宽。每一步只需要对新token做少量计算，但需要频繁读取和写入KV Cache。随着并发请求增多和生成长度增加，显存带宽会成为制约吞吐的关键资源。此时即使GPU算力有空闲，也无法转化为更快的生成速度。
Prefill阶段的耗时直接决定了“首token延迟”，即用户从提交请求到看到第一个输出token的时间。这个指标对交互体验影响很大，尤其是在对话、代码补全等场景中，用户对“模型开始响应”的等待时间非常敏感。
Decode阶段的效率则决定了“生成速度”，通常以每秒生成token数来衡量。这个指标影响的是用户阅读体验的整体节奏。生成速度过慢会让用户感觉模型“卡顿”，即使首token很快，整体满意度也会大打折扣。
在Prefill阶段，如果调度合理，GPU的计算单元可以达到较高的利用率。因为大量token同时进入模型，矩阵运算的规模足够大，能够充分利用GPU的并行能力。
在Decode阶段，GPU的利用率通常较低。每一步的计算量太小，无法填满所有计算单元，而等待数据从显存搬运到计算单元的过程中，大量计算资源处于闲置状态。
| 对比维度 | Prefill阶段 | Decode阶段 |
|---|---|---|
| 主要任务 | 处理输入提示词，建立KV Cache | 逐token生成输出 |
| 计算模式 | 大批量并行矩阵运算 | 小步长串行循环 |
| 核心瓶颈 | GPU算力 | 显存带宽 |
| 单次计算量 | 与输入长度相关，量级较大 | 每次仅计算1个token，量级小 |
| 循环次数 | 一次完成 | 等于输出token数 |
| 关键影响指标 | 首token延迟（TTFT） | 生成速度（tokens/s） |
| GPU利用率 | 通常较高 | 通常较低 |
| 优化方向 | 提高并行度、批量处理 | 降低KV Cache访问成本 |
在短提示词、长输出的场景中，例如创意写作或长文生成，Prefill阶段的耗时可忽略不计，整个请求的耗时几乎完全由Decode决定。此时优化的重点应该放在如何提升单步Decode的速度，以及如何降低KV Cache的读写开销。
在长提示词、短输出的场景中，例如文档摘要或信息抽取，Prefill阶段的耗时占比会显著上升。如果提示词包含数千甚至数万token，Prefill的算力消耗可能远超Decode。此时需要关注的是如何高效处理长序列输入。
在多轮对话场景中，两个阶段交替出现。每一轮对话的输入既包含历史上下文，也包含用户新增内容。随着对话轮次增加，Prefill需要处理的序列越来越长，同时KV Cache也在持续累积，两个阶段的压力都在上升。这种场景对系统的综合调度能力提出了更高要求。
如果让同一个GPU同时处理Prefill和Decode两种负载，容易出现资源冲突。Prefill型负载希望尽可能多地占用计算单元，而Decode型负载需要持续的内存带宽。二者混合时，可能出现两种情况：要么Prefill任务占满计算资源，导致Decode任务等待，表现为生成过程出现间歇性停顿；要么Decode任务持续占用带宽，Prefill任务无法获得足够的计算资源，首token延迟被拉高。
一种常见的工程实践是将两种负载在系统层面进行拆分。具体来说，为Prefill和Decode分别配置不同的资源池，或者在同一资源池内进行差异化的调度策略。这样做的目的是让每种负载都获得最适合它的硬件资源，避免相互干扰。
这种拆分并不简单。它要求推理系统具备请求级的调度能力，能够识别每个请求当前处于哪个阶段，并在不同资源池之间合理分配。此外，KV Cache的传递也是一个工程难点——Prefill阶段计算出的KV Cache需要被Decode阶段高效访问，这涉及数据搬运和显存管理。
对于需要自建推理服务的团队，首先应该评估自身工作负载的特征。如果业务场景中提示词普遍较长，应重点关注Prefill的算力优化；如果输出内容普遍较长，则应优先解决Decode的带宽瓶颈。
在资源规划上，可以考虑为两类负载配置不同算力密度的硬件。例如，将算力更强的设备用于Prefill密集型场景，将内存带宽更充裕的设备用于Decode密集型场景。这种异构部署方式有助于在成本与性能之间取得更好的平衡。
对于托管类推理服务的选择，团队应关注服务方在调度策略上的设计。一个值得考察的指标是：该服务是否能够根据请求特征动态调整资源分配，是否对长文本输入和长文本输出有差异化的处理路径。
Prefill与Decode是大语言模型推理中两个性质迥异的阶段。Prefill负责“理解输入”，是算力密集型任务，影响首token延迟；Decode负责“生成输出”，是带宽密集型任务，影响生成速度。二者的差异不在于模型本身，而在于计算模式和资源需求的不同。
理解这种差异，是进行推理系统优化的前提。将二者混为一谈的部署方式，往往会导致资源利用不均衡和用户体验波动。而在系统层面将两类负载合理拆分、差异化调度，则是提升整体推理效率的关键方向。无论是自建服务还是选择托管方案，这一分析框架都能帮助团队做出更符合实际情况的技术决策。