大语言模型推理核心：Prefill与Decode阶段解析

概念定义

大语言模型（LLM）的推理过程，是指模型在完成训练后，接收用户输入的提示词并生成最终响应的计算过程。这一过程并非单一维度的计算，而是由两个特性截然不同的核心阶段组成：Prefill（预填充）阶段与 Decode（解码）阶段。

• Prefill（预填充）阶段：也常被称为“提示处理”阶段。在这一阶段，推理引擎需要将用户输入的完整提示词（Prompt）并行送入模型，计算并存储所有输入Token对应的Key和Value矩阵。这个过程本质上是对初始上下文的并行编码。
• Decode（解码）阶段：即自回归生成阶段。在此阶段，模型利用Prefill阶段计算并缓存的历史KV矩阵，结合当前步新生成的Token，逐个计算并输出下一个Token，直到生成结束符或达到最大长度限制。

尽管这两个阶段在同一个神经网络的权重参数下运行，但它们对底层硬件资源（如GPU算力、显存带宽）的需求却呈现出截然相反的特性。

背景与价值

理解Prefill与Decode的二元性，是进行大模型推理优化和基础设施选型的前提。传统的深度学习模型（如图像分类网络）在推理时，计算图通常是静态的，算力消耗与输入大小呈线性关系。然而，大语言模型采用自回归生成机制，导致其推理过程是一个动态扩展的过程。

如果不区分这两个阶段进行统筹优化，会导致严重的资源浪费或性能瓶颈。例如，如果在Decode阶段依然采用类似Prefill的大规模并行计算方式，会导致GPU算力大量闲置；反之，如果硬件架构设计只偏向某一阶段的特性，就无法实现整体吞吐量与首字响应时间的平衡。因此，业界主流的推理优化技术（如KV Caching、FlashAttention、连续批处理、推测解码等）无一不是基于对这两个阶段特性的深刻洞察而设计的。

核心组成与工作原理

为了深入理解这两个阶段，我们需要从底层计算流程和资源消耗特征的角度进行拆解。

1. Prefill阶段：计算密集型的并行编码

在Prefill阶段，模型一次性接收整个输入序列（例如用户的一段长文本提问）。此时，多个Token的矩阵乘法操作可以高度并行化。

• 计算特性：高度计算密集。由于输入序列较长，矩阵乘法的规模较大，GPU的算力单元（如CUDA Core或Tensor Core）能够被充分利用。
• 显存与带宽特性：虽然需要生成大量的KV矩阵并写入显存，但由于计算量极大，计算耗时掩盖了显存写入耗时。此时，系统的瓶颈在于算力，而非显存带宽。
• 关键产出：生成并缓存初始的KV Cache。这些缓存将在后续的Decode阶段被反复读取。

2. Decode阶段：内存带宽密集型的自回归生成

在Decode阶段，模型每次只生成一个新Token，然后将这个新Token作为输入，再生成下一个。这是一种严格的串行过程。

• 计算特性：计算稀疏。由于每次只处理一个Token，矩阵乘法的维度极小，GPU庞大的算力单元往往处于“饥饿”状态，计算单元利用率极低。
• 显存与带宽特性：高度内存带宽密集。每生成一个Token，模型都需要将整个历史序列的KV Cache从显存读取到计算单元中。随着生成序列越来越长，需要读取的数据量越来越大，而实际进行的计算量却很小。此时，系统的瓶颈完全转移到了显存带宽上。
• 关键挑战：如何高效地管理和读取不断增长的KV Cache，减少显存带宽压力。

可以用以下伪代码来示意这两个阶段的逻辑分离：

# 伪代码示意：LLM 推理核心流程
def llm_inference(input_ids, model_weights, max_gen_len):
    # 阶段1：Prefill (预填充)
    # 一次性计算所有输入Token的KV矩阵
    kv_cache = compute_kv_cache(input_ids, model_weights)
    # 获取初始的logits并预测第一个输出Token
    current_token = generate_next_token(input_ids, kv_cache, model_weights)
    output_tokens = [current_token]
    # 阶段2：Decode (解码)
    # 自回归逐个生成Token
    for _ in range(max_gen_len - 1):
        if current_token == EOS_TOKEN:
            break
        # 仅计算当前新Token的KV，并追加到缓存中
        new_kv = compute_kv_for_single_token(current_token, model_weights)
        kv_cache.append(new_kv)
        # 基于完整KV Cache预测下一个Token
        current_token = generate_next_token(current_token, kv_cache, model_weights)
        output_tokens.append(current_token)
    return output_tokens

典型场景与优化策略

在实际的云原生部署和企业应用中，针对这两个阶段的特性，通常会有不同的优化侧重点：

1. 首字延迟敏感型场景（如智能客服、交互式问答）：
   此类场景对Prefill阶段的耗时极其敏感。用户希望尽快看到第一个字。优化策略通常包括：采用计算密集型优化的注意力机制（如FlashAttention）来加速长Prompt的并行计算；通过分布式推理将长Prompt切分到多个计算节点上并行处理。

2. 高吞吐量生成场景（如文档摘要、长文翻译、批量内容生成）：
   此类场景生成的Token数量庞大，Decode阶段的耗时占主导。为了克服显存带宽瓶颈，常采用“连续批处理”技术，即在Decode过程中动态插入新的请求，让多个不同请求的Decode计算合并为一个较大的矩阵乘法，从而提高GPU算力利用率。此外，“推测解码”通过一个小模型快速生成候选Token，再由大模型并行验证，也是打破Decode串行瓶颈的有效手段。

相关概念区别：KV Caching的作用

在讨论Prefill与Decode时，不可避免地要提及KV Caching（键值缓存）技术。初学者有时会将其与这两个阶段混淆。

• 区别：Prefill和Decode是推理过程的时间阶段划分；而KV Caching是一种贯穿这两个阶段的数据存储与复用机制。
• 联系：在Prefill阶段，系统计算并“填充”KV Cache；在Decode阶段，系统“读取”并“追加”KV Cache。如果没有KV Caching，Decode阶段在生成每个新Token时都需要重新计算之前所有Token的KV，这将导致计算复杂度呈二次方增长，完全不具备实用性。KV Caching用空间换时间，将计算复杂度降为线性，但同时也带来了显存占用的巨大挑战。

使用注意事项

在选型、接入和运维大语言模型推理服务时，开发者与架构师需要重点关注以下问题：

1. 资源配比与硬件选型：
   由于Prefill偏算力、Decode偏带宽，不同的硬件架构（如不同型号的GPU或专用的推理加速卡）对这两个阶段的适应度不同。在企业选型时，如果业务以短输入长输出为主，应更关注显存带宽指标；如果以长输入短输出为主（如长文档分类），则应更关注峰值算力指标。

2. 显存管理与溢出风险：
   KV Cache随着序列长度和并发请求数的增加呈线性增长。在容器平台或云原生环境中部署时，极易出现显存溢出（OOM）导致服务崩溃。运维时需要结合模型的隐藏层维度、层数以及预期并发的最大序列长度，精确计算显存需求，并配置合理的批处理上限。

3. 调度策略的配置：
   主流的推理框架通常允许配置调度策略。例如，在某些场景下，将Prefill和Decode任务在物理上隔离到不同的计算资源池中运行（即分离式推理架构），可以避免长Prompt的Prefill计算阻塞正在进行的Decode任务，从而保障整体服务的稳定性与低延迟。在集成负载均衡与监控告警系统时，需要分别对Prefill耗时和Decode耗时进行指标采集与告警配置。

总结

大语言模型推理的Prefill（预填充）与Decode（解码）阶段，虽然共用一套模型权重，却展现出“计算密集”与“显存带宽密集”的二元对立特性。Prefill阶段负责高效处理输入上下文并建立KV Cache，决定了首字响应时间；Decode阶段则依赖KV Cache进行逐Token生成，决定了整体吞吐量。深入理解这两个阶段的运行机制与资源瓶颈，是实施KV Caching、批处理调度、分离式架构等高级推理优化技术的前提，也是企业构建高效、稳定且经济的LLM应用基础设施的基石。