计算所严明玉团队新作： Attention 并非永远是瓶颈，多 GPU 并不一定更快

首页 » 计算所严明玉团队新作： Attention 并非永远是瓶颈，多 GPU 并不一定更快

随着大语言模型逐渐走向真实应用，推理阶段的性能问题正在成为制约落地的关键因素。

模型规模不断增大、上下文持续拉长，再加上 RAG、MoE 等新用法的引入，使得延迟、吞吐和能耗不再只是“调一调参数”的问题，而是直接影响系统架构和算力成本的核心挑战。

围绕这些问题，来自中国科学院计算所的严明玉团队，联合中国电信云计算研究院、浙江实验室和北京大学的研究者，在论文《A Systematic Characterization of LLM Inference on GPUs》中，对大语言模型在 GPU 上的推理行为进行了系统研究。

不同于以往侧重单一模型、单一算子或局部优化的研究路径，严明玉团队从系统和硬件协同的视角出发，通过大规模实验，对大语言模型在 GPU 上的推理行为进行了全面刻画，试图从根本上回答一个长期困扰工程实践的问题：大模型推理为什么会呈现出现在这样的性能特征。

这项工作并没有直接给出如何优化的现成答案，而是首先建立了一套统一、可解释的性能认知框架，将 Prefill 与 Decode 的差异上升为系统级的基本规律，并在不同模型规模、不同硬件平台以及 MoE、RAG 等新型推理范式下进行了验证。

在这一框架下，推理延迟、资源利用率和能耗不再是孤立的指标，而是随着工作负载和系统配置发生有规律的变化。这种从现象出发、最终回到系统根因的研究方式，使得这项工作更像是在为大模型推理建立一张可理解、可推演的性能全景图，而不是提供某个场景下的经验结论。

论文链接：https://arxiv.org/pdf/2512.01644v1

文章目录

一次对大模型推理性能的系统性拆解

严明玉团队的这项工作通过大量有组织的实验，系统地总结了大语言模型在推理阶段的性能规律，而不是停留在零散的经验观察上。研究团队发现，LLM 的推理过程在本质上可以分成两个完全不同的阶段，而且这种差异并不是靠优化就能消除的。

具体来说，第一个阶段是 Prefill 阶段，主要任务是一次性处理用户输入的 prompt。这个阶段可以并行执行，核心计算是大规模矩阵乘法，因此计算量大、算得很满，GPU 的计算单元利用率很高，整体性能主要受限于算力本身。

第二个阶段是 Decode 阶段，用来逐个生成输出 token。由于生成过程是一步一步进行的，每一步都需要访问已经缓存的上下文信息（KV Cache），实际计算量不大，但内存访问非常频繁，因此性能瓶颈从算力转移到了内存带宽和访问延迟上。

在此基础上，论文进一步指出，推理过程中到底是 Prefill 慢还是 Decode 慢，并不是固定的，而是取决于具体的输入和输出情况。当输入较短时，虽然每一步 Decode 的计算不多，但需要执行很多步，因此 Decode 往往成为主要耗时部分。

而当输入变长时，Prefill 阶段需要处理的 token 数迅速增加，其计算量增长更快，在超过某个长度之后就会反过来成为整体延迟的主要来源。这种从 Decode 主导到 Prefill 主导的转变说明，性能瓶颈更多是由工作负载决定的，而不是模型本身天生慢在哪。

如果进一步拆到模型内部的算子层面，研究团队发现瓶颈同样不是固定的。在常见的上下文长度下，Prefill 阶段的主要时间往往花在前馈网络（FFN）上，但在上下文特别长的情况下，由于注意力计算的复杂度增长更快，Attention 会逐渐成为主要瓶颈。

Decode 阶段的情况则和模型规模有关：对于较小的模型，频繁访问 KV Cache 的 Attention 更容易成为瓶颈；而对于大模型，由于前馈网络权重更大，FFN 的内存加载成本反而更突出。这说明，单纯地说 Attention 是瓶颈或 FFN 是瓶颈都是不准确的，必须结合所处阶段、上下文长度和模型规模来判断。雷峰网(公众号：雷峰网)

在性能可预测性方面，论文发现 Prefill 阶段的行为非常规律。它的执行时间几乎只由真正需要计算的输入 token 数量决定，而且二者之间呈现非常稳定的线性关系。这意味着，只要知道输入长度和缓存命中情况，就可以比较准确地预测 Prefill 的延迟，这对系统调度和资源规划非常有用。相比之下，Decode 阶段由于是逐步生成，并且受到采样和串行依赖的影响，性能波动更大，也更难提前预测。

在能耗分析中，论文给出了一个非常直观但重要的结论：整个推理过程消耗的能量，几乎全部来自 Decode 阶段。输入有多长，对总能耗影响很小，而输出生成了多少 token，几乎直接决定了能耗大小。同时，模型参数越多，总能耗也会随之增加。这说明，在真实系统中，如果想要降低推理能耗，限制输出长度往往比优化 Prefill 更有效。

在多 GPU 扩展实验中，研究团队发现并行化并不是在所有情况下都有效。Prefill 阶段由于计算量大，把计算分摊到多张 GPU 上通常能带来收益，但 Decode 阶段每一步计算都很小，多 GPU 之间的通信和同步反而会成为负担，导致性能提升不明显甚至变慢。因此，在 Decode 为主的场景下，使用单 GPU 或较轻量的流水并行往往更合适，这也打破了GPU 越多越快的直觉。

最后，论文还分析了新的推理范式。对于 MoE 模型，推理速度主要取决于每次实际参与计算的参数规模，而不是模型的总参数量，这带来了明显的性能优势，但同时，在 Decode 阶段会额外引入专家选择和调度的开销，使性能表现更加复杂。

对于 RAG 工作流，研究团队发现随着外部知识规模变大，系统瓶颈会从 GPU 推理转移到 CPU 侧的检索和内存访问上，形成新的性能限制。尽管推理流程变得更加复杂，但 Prefill 和 Decode 在性能上的根本差异依然存在，仍然是理解整体行为的关键。

面向系统理解的大模型推理实验框架

为了让结论更完整、也更容易理解，这篇论文在实验设计上采用了一种由浅入深的分析思路。研究团队并不是一开始就研究底层硬件细节，而是先观察整体推理性能表现，再逐步深入到 GPU 的执行和存储行为，最后把得到的规律放回到真实系统和新型推理场景中进行验证。雷峰网

在实验平台方面，论文同时使用了数据中心级的 GPU（A100）和边缘设备上的 GPU（Jetson AGX Orin）。这样做的目的，是检验前面总结出的性能规律是否只在高端服务器上成立，还是在算力和内存条件更受限的设备上同样适用。

模型选择上，研究团队覆盖了多种主流的 dense 模型（从 7B 到 32B），同时还引入了一个具有代表性的 MoE 模型，以观察不同参数规模和不同架构设计对推理性能的影响。为了保证对比公平，所有实验都在同一套推理框架和相同精度设置下进行，尽量减少实现细节带来的干扰。

在工作负载设计上，研究团队并没有简单地跑几组固定 benchmark，而是有针对性地设计了多种输入和输出组合。例如，有的任务输入短、输出长，有的输入长、输出短，还有真实对话数据和可控的合成数据。这样的设计是为了有意识地制造 Prefill 占主导或 Decode 占主导的不同场景，从而验证两阶段在不同条件下是否始终表现出不同的性能特征。

在性能分析方法上，论文采用了分层剖析的方式。首先在整体层面上，测量端到端的延迟、吞吐量和能耗，建立对系统行为的直观认识；接着在阶段和算子层面，分析 Prefill 和 Decode 各自占用了多少时间，以及不同算子在其中的作用；最后深入到硬件层面，通过 Roofline 模型、warp 停顿分析，以及缓存命中率和内存带宽使用情况，来判断性能究竟是受限于计算还是受限于内存。