LLM推理基础：从Transformer到生产级性能指标

在构建生产级LLM推理系统之前，必须深入理解模型推理的底层机制。Transformer架构决定了计算模式，自回归生成定义了请求处理方式，KV Cache决定了显存占用与吞吐上限，而预填充与解码两个阶段的差异直接决定了延迟与吞吐的优化策略。本章将系统拆解这些核心概念，并建立一套可量化的性能指标体系，为后续的推理优化、高可用架构设计打下坚实基础。

2.1 Transformer架构与自回归生成机制

核心原理：解码器架构与因果注意力

生产级LLM推理系统所服务的模型，绝大多数基于Transformer解码器架构。与编码器-解码器架构不同，纯解码器模型（如系列、LLaMA系列）使用因果注意力掩码（Causal Attention Mask），确保每个位置只能关注到当前位置及其之前的。这一设计从根本上决定了推理的串行特性：第N个的生成必须等待前N-1个全部计算完成。

自回归生成（Autoregressive Generation）是LLM推理的核心范式。模型将文本生成视为一个逐步预测问题：给定输入序列，预测下一个的概率分布，采样得到后将其拼接到输入序列末尾，继续预测下一个，直到生成结束符（EOS）或达到最大长度。这种机制虽然简单，但带来了两个关键工程挑战：一是无法并行生成整个序列，二是每一步都需要重新计算注意力。

判断方法：理解计算模式

• 矩阵乘法维度：在预填充阶段，输入是一个完整的序列（如512个），可以一次性并行计算所有位置的注意力；在解码阶段，每次只输入1个，但需要与KV Cache中所有历史计算注意力。
• 计算密集 vs 内存密集：预填充阶段是计算密集型（Compute-bound），GPU算力利用率高；解码阶段是内存密集型（Memory-bound），受限于显存带宽而非算力。
• 批处理影响：解码阶段可以通过批处理（Batch）同时处理多个请求，但每个请求的序列长度不同，需要动态管理KV Cache。

案例拆解：一个简单的文本生成请求

假设用户输入"请介绍一下Transformer"，模型需要生成一段回答。整个过程如下：

1. 输入处理：将用户输入分词为序列，如["请", "介绍", "一下", "Transformer"]，长度为4。
2. 预填充阶段：模型并行处理这4个，计算每层的注意力、FFN，生成初始的KV Cache，并预测第5个的概率分布。
3. 采样：从概率分布中采样得到第5个，如"是"。
4. 解码阶段：将"是"作为输入，与KV Cache一起计算，预测第6个，如此循环。
5. 终止条件：当生成为"<EOS>"或达到max_tokens限制时停止。

在这个例子中，预填充阶段只执行1次，而解码阶段可能执行数百次。如果生成200个，解码阶段占总计算量的98%以上，但每个的计算量远小于预填充阶段。

常见误区与总结

2.2 KV Cache：推理性能的关键瓶颈

核心原理：缓存注意力计算的中间结果

在自回归生成过程中，每个在计算注意力时都需要与之前所有的Key和Value进行交互。如果不做缓存，每生成一个新，都需要重新计算之前所有的Key和Value矩阵，计算复杂度为O(N²)，其中N为序列长度。KV Cache的核心思想是：在预填充阶段计算并存储所有的Key和Value矩阵，在解码阶段直接复用，避免重复计算。

KV Cache的显存占用公式为：2 × L × N × S × D × 2字节（FP16精度），其中L为层数，N为注意力头数，S为序列长度，D为每个头的维度。以LLaMA-7B为例（L=32, N=32, D=128），当序列长度为2048时，单请求KV Cache占用约512MB显存。这意味着一个80GB的A100 GPU，最多只能同时处理约150个并发请求（不考虑模型权重和其他开销）。

判断方法：评估KV Cache的优化空间

实战场景：KV Cache的显存规划

假设我们需要在一台8×A100（80GB）的GPU服务器上部署LLaMA-13B模型（权重约26GB），目标并发请求数为64，最大序列长度为4096。计算KV Cache需求：

LLaMA-13B参数: L=40, N=40, D=128
单请求KV Cache = 2 × 40 × 40 × 4096 × 128 × 2B = 3.2GB
64并发请求总KV Cache = 3.2GB × 64 = 204.8GB
单GPU可用显存 = 80GB - 26GB(权重) - 10GB(预留) = 44GB
单GPU可承载请求数 = 44GB / 3.2GB ≈ 13个
实际需要GPU数 = 64 / 13 ≈ 5张

这个计算揭示了KV Cache对系统容量的决定性影响。如果使用GQA（假设4个Query共享1组KV），KV Cache可减少至0.8GB/请求，单GPU可承载55个请求，大幅提升系统吞吐。

常见误区与总结

2.3 预填充与解码阶段：两种计算模式的深度剖析

核心原理：计算特征与资源需求的差异

预填充阶段（Prefill）处理完整的输入序列，所有可以并行计算，GPU算力利用率高，但计算量大。解码阶段（Decode）每次只处理1个，计算量小，但需要频繁访问KV Cache，受限于显存带宽。这两个阶段的性能特征截然不同，需要分别优化。

从计算时间来看，预填充阶段的时间与输入序列长度成正比，解码阶段的时间与输出序列长度成正比。对于典型的对话场景（输入200 ，输出500 ），预填充可能只占总时间的10%-20%，但决定了用户感知的TTFT；解码阶段占80%-90%，决定了TPOT和整体吞吐。

判断方法：识别性能瓶颈

• 预填充瓶颈：如果TTFT过长，说明预填充阶段计算效率低。可能原因包括：输入序列过长、GPU算力不足、批处理策略不当。
• 解码瓶颈：如果TPOT过长，说明解码阶段内存带宽受限。可能原因包括：KV Cache访问效率低、Batch Size过大导致显存带宽饱和、模型权重加载开销大。
• 混合瓶颈：在实际系统中，预填充和解码阶段往往交织在一起。连续批处理（Continuous Batching）技术允许不同请求处于不同阶段，最大化GPU利用率。

案例拆解：连续批处理的实际效果

某AI公司部署了一个LLM推理服务，使用传统静态批处理（Static Batching）时，系统吞吐为200 tokens/s，平均TTFT为1.2秒，TPOT为80ms。切换到连续批处理（如vLLM实现）后：

1. 初始状态：10个并发请求，每个请求输入200 ，输出500 。
2. 静态批处理问题：所有请求必须等待最慢的请求完成后才能释放资源，导致GPU利用率不足50%。
3. 连续批处理优化：每个请求独立推进，完成一个请求后立即插入新请求，GPU利用率提升至85%以上。
4. 结果对比：吞吐提升至450 tokens/s，TTFT降至400ms，TPOT降至35ms。

这个案例说明，预填充和解码阶段的混合调度是提升系统效率的关键。连续批处理的核心价值在于：让预填充阶段的计算密集特性与解码阶段的内存密集特性互补，充分利用GPU资源。

常见误区与总结

2.4 推理性能关键指标：定义、测量与优化目标

核心原理：建立可量化的性能评估体系

生产级LLM推理系统需要一套完整的性能指标体系来指导容量规划、SLA制定和优化决策。核心指标包括：TTFT（Time To First ）、TPOT（Time Per Output ）、吞吐量（Throughput）和端到端延迟（End-to-End Latency）。这些指标相互关联，但优化目标可能冲突，需要根据业务场景权衡。

判断方法：指标测量与基准测试

实战场景：SLA制定与容量规划

某金融科技公司需要部署一个智能客服系统，要求：

• TTFT ≤ 300ms（用户等待感知阈值）
• TPOT ≤ 30ms（流式输出流畅度）
• 并发请求数 ≥ 100
• 平均输出长度 200

根据这些要求，计算所需GPU资源：

假设使用A100 80GB，单卡吞吐约2000 tokens/s（连续批处理）
单请求平均生成时间 = 200  × 30ms = 6s
单卡并发能力 = 2000 tokens/s / (200 /请求) = 10请求/秒
100并发请求所需吞吐 = 100 / 6s ≈ 16.7请求/秒
所需GPU数 = 16.7 / 10 ≈ 2张

但实际部署中还需要考虑TTFT约束。如果单卡同时处理10个请求，每个请求的预填充时间可能超过300ms。因此，需要增加GPU数量或优化预填充策略（如使用更小的Batch Size、模型并行等）。

常见误区与总结