Transformer推理既然是串行的，为什么还要拼GPU性能？
Transformer 推理既然是串行的，为什么还要拼 GPU 性能？
这是一个在刚接触大语言模型（LLM）底层机制时极易产生的疑惑。既然模型生成文本时必须等前一个词出来才能预测下一个词，这种看似串行的过程，究竟是如何榨干GPU算力的？不同显卡之间的性能鸿沟又是由什么决定的？
要理清这个问题，我们需要把Transformer的推理过程掰开揉碎来看。
串行的表象与并行的内核
Transformer的推理过程其实包含两个截然不同的阶段。首先是预填充阶段（Prefill），模型会把输入的Prompt一次性全部“吃”进去并完成并行计算，这一步极其高效。紧接着就是大家最熟悉的解码阶段（Decode），也就是模型开始往外“蹦字”的环节。
在时间轴上，解码阶段确实是严格串行的。 模型必须生成第1个Token，才能依据它去生成第2个Token。
玄机隐藏在生成“单一Token”的这个瞬间。预测下一个词的过程，本质上是拿当前状态的向量与模型内部庞大的权重矩阵进行相乘。 假设模型的维度是 ，它包含了几百上千亿个参数，这一步的底层数学运算就是极其庞大的向量-矩阵乘法（Vector-Matrix Multiplication，例如 ）。这种海量的乘加运算完全可以被拆解成无数个微小的计算任务，这正是硬件发挥并行计算能力的舞台。
为什么这项工作必须交给GPU
理解了底层运算逻辑，CPU和GPU的定位差异就非常清晰了。
CPU的设计初衷是处理极其复杂的逻辑控制和分支预测。它拥有数量不多但单体性能极强的核心，就像几位顶尖的数学家，非常擅长解答复杂的微积分或者统筹规划问题。让几位数学家去完成几百亿次十以内加减乘除的纯体力活，显然大材小用且效率低下。
GPU的设计路线则完全相反，主打“高吞吐与大力出奇迹”。它内部集成了成千上万个相对简单的流处理器和专门针对张量运算优化的核心。面对生成Token时所需的庞大矩阵运算，GPU的几万个核心可以一拥而上，在一个时钟周期内把被切分成无数小块的矩阵同时算完。这就是为什么CPU算一个词可能要卡顿几秒，而GPU一秒钟就能流畅输出几十个词的根本原因。
显卡之间的算力较量究竟在拼什么
这就引出了最核心的问题。既然GPU都能做矩阵切分并行计算，为什么不同级别的显卡在推理速度上会有天壤之别？这其实涉及大模型推理中最反直觉的一个硬件瓶颈。
在单人对话这种Batch Size为1的解码阶段，决定生成速度的最关键指标往往不是单核或多核的绝对算力（FLOPS），而是显存带宽（Memory Bandwidth）。
为了算出哪怕只是一个Token，GPU都必须把模型几十GB的权重数据从显存（VRAM）中完整读取一遍，然后输送给计算核心。因为计算核心处理乘加运算的速度实在太快了，绝大部分时间它们都在“干等”数据通过数据总线传过来。这种现象在工程上被称为访存密集型任务（Memory-bound），也就是俗称的“内存墙”。
普通的消费级旗舰显卡使用的是GDDR系列显存，带宽通常在 1 TB/s 上下。而像H100这样的顶级计算卡采用的是HBM高带宽内存，通道宽度和传输速率呈指数级提升，带宽可以飙升到 3.35 TB/s 以上。这也是为什么即使两张卡的理论算力纸面差距没有那么悬殊，顶级计算卡依然能凭借宽阔的数据传输通道在吐字速度上形成降维打击。
当然，如果你是在服务器端同时为几百个用户提供服务，情况就会发生反转。系统会把众多请求打包成批处理（Batching），此时的运算会从向量-矩阵乘法膨胀为矩阵-矩阵乘法。任务属性就会随之转变为计算密集型（Compute-bound），此时GPU的极限算力以及专用的张量核心数量就会重新夺回决定权，成为维持高并发吞吐量的关键。此外，应对多用户并发还需要维护庞大的KV Cache上下文缓存，这直接考验着GPU的显存容量底线。
总而言之，Transformer的Token生成看似是一条单行道，但铺设这条道路的每一块砖，都需要极度并行的算力来浇筑。在单机单用户的场景下拼的是搬运砖块的速度（显存带宽），而在高并发的业务场景下，拼的则是工厂同时生产砖块的规模（算力与显存容量）。