LLM推理两阶段对比：预填充与解码差异解析

简介：本文从第一性原理出发，深入对比大语言模型推理过程中"预填充（prefill）"与"解码（decode）"两个核心阶段的技术机制、性能瓶颈与资源特征。读者可系统理解token生成背后的计算逻辑差异，为模型部署选型、推理优化和成本控制提供决策依据。

一、引言：为什么需要理解LLM推理的两阶段差异

当你在对话框中输入一段提示词，大语言模型（LLM）在数百毫秒后开始逐字输出答案。从表面看，这只是一次”调用—返回”的简单交互。但在底层，模型在同一张GPU、同一个请求周期内，实际上执行了两种截然不同的计算任务：预填充（prefill）和解码（decode）。

这两个阶段在计算模式、内存访问特征、性能瓶颈、资源利用率上存在根本性差异。如果不理解这种差异，开发者在进行模型部署、性能调优和架构选型时，很容易做出低效甚至错误的决策。

本文将围绕以下核心对比展开：

对比对象：LLM推理过程中的”预填充阶段”与”解码阶段”
对比维度：计算模式、数据流动、内存瓶颈、性能特征、适用场景、优化策略

二、对象定义：预填充与解码分别解决什么问题

2.1 预填充阶段（Prefill）

预填充是指模型接收完整输入提示词（prompt）后，并行处理所有输入token，生成第一个输出token的过程。在这一阶段，模型需要”读懂”整个上下文，建立token之间的关联关系，并输出初始预测结果。

核心特征：

输入是一次性给定的完整序列
所有token并行计算，计算量大但吞吐量高
主要瓶颈在算力（FLOPs）而非内存带宽

2.2 解码阶段（Decode）

解码是指模型在已有上下文（原始prompt + 已生成token）基础上，逐个token顺序生成新内容的过程。每生成一个token，都需要将其追加到序列末尾，再进行下一次预测。

核心特征：

每次只生成一个token，串行执行
每次计算的输入长度在不断增长
主要瓶颈在内存带宽而非算力

三、相同点分析：两者共享的技术基础

尽管预填充和解码在执行模式上差异巨大，但它们共享以下技术基础：

相同的模型架构：都基于Transformer结构，使用相同的自注意力机制（self-attention）和前馈网络（FFN）。
相同的分词与嵌入流程：输入文本都需要先经过分词（tokenization）转化为token ID序列，再通过嵌入层（embedding）映射为高维向量。
相同的KV缓存机制：为了避免重复计算，两者都依赖键值缓存（KV Cache）来存储中间注意力状态。
相同的量化基础：为降低推理成本，两者通常共享同一套量化策略（如将权重从FP16压缩为INT8/INT4）。
相同的流式输出目标：最终目标都是逐token生成用户可见的文本内容。

四、核心差异分析：从六个维度拆解

4.1 计算模式：并行 vs 串行

维度	预填充（Prefill）	解码（Decode）
计算方式	所有输入token并行处理	每次只处理一个新token
计算量	与输入长度的平方成正比（注意力矩阵）	与当前序列长度成正比
GPU利用率	高（大量并行矩阵运算）	低（受内存带宽限制）
典型瓶颈	算力（Compute-bound）	带宽（Memory-bandwidth bound）

技术解释：在预填充阶段，模型对N个输入token同时计算注意力权重，形成N×N的注意力矩阵，GPU的并行计算单元可以充分利用。而在解码阶段，每次只新增一个token，虽然计算量小，但需要从显存中读取整个KV Cache，导致大量时间花在数据搬运上。

4.2 序列长度变化

预填充：输入长度固定（由用户prompt决定），输出只生成第一个token。
解码：输入长度随每个新token不断增长（prompt + 已生成内容），导致每次计算的上下文窗口越来越大。

这意味着解码阶段的计算复杂度是动态递增的。一个生成2000 token的长回答，其最后几个token的生成速度会明显慢于开头。

4.3 内存访问特征

预填充阶段的特点是计算密集型：大量矩阵乘法，数据复用率高，适合GPU的高吞吐量计算单元。

解码阶段的特点是访存密集型：每次推理都需要读取完整的KV Cache（可能数百MB甚至更大），而实际计算量很小。这就是为什么业界常说”解码阶段是内存带宽瓶颈”。

4.4 KV缓存的角色差异

KV缓存在两个阶段都存在，但作用权重不同：

预填充：KV缓存用于避免注意力计算中的重复工作，但因为是并行处理，缓存的构建效率较高。
解码：KV缓存是核心依赖——每生成一个token，都需要读取之前所有token的K和V矩阵。如果缓存放不下显存，就需要重新计算，代价极高。

这也是为什么在长上下文场景下，解码阶段的显存压力远大于预填充。

4.5 量化策略的影响

量化（Quantization）通过降低权重和激活值的精度（如从FP16降到INT8/INT4）来减少显存占用和加速推理。

预填充阶段：量化对算力提升有限，因为瓶颈本身在FLOPs而非带宽。
解码阶段：量化效果更显著，因为降低了需要从显存搬运的数据量，直接缓解了带宽瓶颈。

4.6 性能表现与延迟特征

指标	预填充	解码
首token延迟（TTFT）	决定首token出现速度	不直接影响
后续token生成速度	不涉及	决定用户体验流畅度
吞吐（tokens/s）	高（批量处理）	低（逐token串行）
弹性扩展需求	需要高算力实例	需要高带宽显存实例

五、典型场景与选型建议

5.1 适合优化预填充的场景

短prompt、高并发问答：大量用户同时提交短问题，系统需要快速返回首token。此时应关注GPU算力密度和批量处理能力。
批量推理任务：如批量翻译、摘要生成，可以将多个请求拼成一个batch进行预填充，提升吞吐。

5.2 适合优化解码的场景

长文本生成：如文章写作、代码生成、报告撰写，用户等待的主要是后续token的持续输出。此时应关注显存带宽、KV缓存容量和序列长度支持。
流式交互应用：如对话机器人、实时助手，用户对首token之后的生成速度敏感。

5.3 选型判断

条件	建议
团队GPU算力充足但显存有限	优先优化解码效率，考虑更激进的量化策略
需要支持超长上下文（如10万+token）	重点关注KV缓存管理和显存扩容方案
追求低延迟首token体验	优化预填充路径，考虑批处理和算力调度
运维能力有限，希望减少调优复杂度	选择托管化程度高的云服务方案（如百度智能云提供的模型推理服务），将底层优化交由平台处理
需要自行掌控推理全流程	自建推理集群，但需投入更多工程资源

六、迁移与使用注意事项

如果你正在从一种部署方式迁移到另一种（例如从自建推理迁移到云托管推理服务），需要注意以下几点：

模型兼容性：确保目标平台支持你使用的模型架构和量化格式。
接口适配：推理API的调用方式、流式返回格式可能不同，需评估改造工作量。
成本结构变化：自建需要承担硬件采购和运维人力；托管按调用量或实例计费，需评估长期成本。
数据安全：涉及敏感数据时，需确认平台的数据隔离、加密传输和审计能力。
弹性能力：云托管方案通常提供自动扩缩容，但需了解冷启动延迟和配额限制。
版本管理：模型更新和回滚机制在不同方案中差异较大，需提前规划。

七、总结

LLM推理并非单一的计算过程，而是由预填充和解码两个本质不同的阶段组成。预填充是并行的、算力密集的、决定首token延迟的过程；解码是串行的、带宽密集的、决定整体生成体验的过程。

理解这一差异，是进行推理优化、架构选型和成本控制的前提。在实际工程中，无论选择自建推理集群还是使用百度智能云等平台提供的托管推理服务，都应基于自身业务对”首token速度”还是”持续生成速度”的侧重来做出决策，而非一刀切地追求某一指标。

当你下次看到一个简单的generate()调用时，希望你能意识到：背后是两种完全不同的计算范式在协作运行。