@NVIDIAAI: 随着AI模型在规模和能力上不断增长,塑造模型与其大小同等重要。我们正在推出…
摘要
NVIDIA推出关于AI模型协同设计(AI Model Co-Design)的系列内容,解释模型维度如何影响GPU性能,以及LLM部署中吞吐量与交互性之间的权衡。第一篇文章提供了设计硬件友好型LLM的实用入门指南,以提升系统吞吐量和用户响应速度。
查看缓存全文
缓存时间: 2026/07/14 04:23
随着AI模型在规模和能力上持续增长,塑造模型的方式与其大小同等重要。
我们正在推出一个关于AI模型协同设计的新系列,探索模型与硬件之间的协同效应。第一篇博文重点介绍模型维度如何影响GPU性能,以及正确的设计选择如何同时提高系统吞吐量和每个用户的响应速度。
您可以在此处阅读:https://nvda.ws/452Idiy
AI模型协同设计:硬件友好的LLM设计
来源:https://developer.nvidia.com/blog/ai-model-co-design-hardware-friendly-llm-design/?linkId=100000430616047 AI性能归结为三个维度:
- 准确性: 模型推理和产生输出的能力
- 吞吐量: 数据中心每秒可以生成的token数
- 交互性: 模型对用户的响应感,主要由延迟决定
部署必须平衡三者:如果响应缓慢,高准确性就是浪费;如果每个用户的体验都卡顿,原始吞吐量也意义不大。因此,实用系统需要同时优化准确性、吞吐量和交互性。
本文重点讨论吞吐量和交互性,以及模型设计选择如何在不对准确性造成损害的前提下塑造这两者(我们会在出现准确性权衡时标注出来)。
在保持准确性不变的情况下,问题变成了一个二维帕累托前沿:改善一个指标通常以牺牲另一个为代价。目标是推动整个前沿向外扩展,最大化曲线下的面积(见下图1)。
折线图显示系统吞吐量(token/秒)随着交互性(token/秒/用户)提升而下降,目标是推动权衡曲线向外扩展。图1. 系统吞吐量与交互性的帕累托前沿 我们将从LLM开始,这是当今最突出的AI工作负载。这种权衡有两个视角:系统部署者,优先考虑集群吞吐量(token/秒),以及用户,看重更低的第一个token延迟和token间延迟。token间延迟的倒数就是token/秒/用户,数值越高表示响应性越好。
一次响应的模式是:提示 → [第一个token延迟] → 第一个token → [token间延迟] → 下一个token,依此类推。
本文是为希望自己的模型能在现代硬件上良好运行的模型开发者准备的一份实用入门指南。思路很简单:与硬件对齐的模型不仅运行更快,而且扩展性更好、成本更低、采用范围更广。
首先,考虑部署情况,它沿两个轴变化(见下图2)。
四个饼图显示LLM执行时间在GEMM、注意力、通信和其他层之间的分配,因上下文长度以及面向延迟还是吞吐量的服务而异。图2. 不同工作负载区域(水平轴)和服务目标(垂直轴)下的延迟分解 工作负载的范围从短上下文到长上下文,服务目标从面向吞吐量(最大化token/秒)到面向延迟(最小化响应时间);很多情况介于两者之间。
每种象限需要不同的优化:长上下文、面向吞吐量的服务大部分时间花费在注意力上,而面向延迟的服务通过增加模型并行性来缩短注意力和FFN,代价是通信和固定开销。短上下文、面向吞吐量的服务在注意力和FFN之间时间分配更均匀,并且可以从并行性(如专家并行性)中获益。
阿姆达尔定律适用:优化某一部分只能带来与该部分运行时间成比例的好处。如果注意力占运行时间的77%,调整前馈层只能带来微小的增益;注意力的路径才是投入精力能见效的地方。了解你的工作区域就能知道该把精力放在哪里。
本文给出一些简单的经验法则,让你能尽早做出这些决策,让任何想从硬件中获得最大收益但并非系统工程师的人都能受益。本系列的每一章将针对硬件感知设计的不同维度,帮助你避免计算瓶颈、在数据中心规模上实现无摩擦部署、使设计与你的用例匹配、并在实践中进行扩展。
设计更智能。部署更快。扩展更广。让我们开始吧。
硬件友好的LLM线性层维度设定
https://developer.nvidia.com/blog/ai-model-co-design-hardware-friendly-llm-design/?linkId=100000430616047#hardware-friendly_dimensioning_of_linear_layers_in_llms
Transformer的一个关键设计选择是其宽高比:模型宽度与层数(\(L\))之间的平衡。在解码器风格的模型中,这些因素主导着计算和内存如何在堆栈中分布。宽度本身由两个维度设定:隐藏维度(\(H\))和MLP层中的中间投影维度(\(H’\))。
\(H\)、\(H’\)和\(L\)共同决定了模型如何整齐地映射到并行策略以及它在GPU上的扩展效果。本文探讨这三个选择如何影响吞吐量、交互性和可扩展性,并密切关注线性层。
算术强度的重要性
https://developer.nvidia.com/blog/ai-model-co-design-hardware-friendly-llm-design/?linkId=100000430616047#role_of_arithmetic_intensity
在任何硬件上,可实现性能都受到屋顶线模型(Roofline Model)的限制。工作负载落在哪里取决于其算术强度,定义为每移动一个字节内存所执行的计算操作数。
算术强度低的工作负载受限于内存带宽(内存受限);算术强度高的工作负载受限于设备的峰值计算吞吐量(FLOPS)(计算受限)。当目标是最大吞吐量(每秒token数)时,你需要将工作负载推入计算受限区域,以便充分利用硬件的全部数学能力。
对延迟敏感的推理则相反,它运行在低并发度下并且是内存受限的,因此减少内存访问时间可以降低响应延迟。
性能随算术强度上升的屋顶线图,在内存受限区域上升,然后越过脊点后在计算受限峰值处趋于平坦。图3. 屋顶线模型。在脊点以下,工作负载受限于内存带宽;在脊点以上,受限于设备的峰值计算吞吐量。工作负载的算术强度(每字节操作数)决定了它落在哪个区域 提高每字节操作数的一个直接方法是增加批次大小,但模型形状也很重要。让我们看看\(H\)和\(H’\)如何决定一个GEMM是计算受限还是内存受限。在单个设备上运行时,\(H\)和\(H’\)设定了以下形式的GEMM的形状:
\(C = AB\)
按照典型线性代数库中使用的惯例,\(A\)是一个大小为\(M × K\)的矩阵(\(M\)行,\(K\)列),\(B\)是\(K × N\)。乘积\(C\)有\(M × N\)个输出,每个输出是一个长度为\(K\)的点积,需要\(M × N × K\)个融合乘加(FMA)。由于每个FMA是2次FLOP(一次乘法,一次加法),所以开销为:
\(\text{FLOPs} = 2 × M × N × K\)
\(\text{读取字节} = M × K × \text{bytes}_A + N × K × \text{bytes}_B\)
\(\text{写入字节} = M × N × \text{bytes}_C\)
其中\(\text{bytes}_{A,B,C}\)是由所用精度设定的每个元素的字节数。以\(A\)为输入,\(B\)为权重,下表1将token数(\(\text{Tokens} = \text{concurrency} × \text{sequence length}\))、\(H\)和\(H’\)映射到每个线性层的GEMM的\(M\)、\(N\)和\(K\)。
| 层名称 | 投影(输入→输出) | GEMM M | GEMM N | GEMM K |
|---|---|---|---|---|
| Q/K/V 输入线性 | H→ 3H | Tokens | 3H | H |
| 注意力输出线性 | H→H | Tokens | H | H |
| FFN-1(上投影) | H→H′ | Tokens | H′ | H |
| FFN-2(下投影) | H′ →H | Tokens | H | H′ |
| 表1. 以Tokens、H和H’表示的Transformer块中线性层的GEMM维度(M、N、K) |
考虑一个情况,每个GEMM都是“正方形”,\(\text{Tokens} = H’ = H\)。那么单个GEMM执行\(2H^{3}\)次FLOP,同时移动约\(3H^{2}\)个元素的内存,因此算术强度随\(H\)增长。实际后果是:当\(H\)或\(H’\)较小时,即使token维度很大,GPU花在移动数据上的时间也会比例更高,做数学运算的时间较少。
作为一个具体例子,取FFN-2,故意设\(H’=512\)且\(H=8192\),在GB300上使用4位输入和8位输出。如下表2所示,即使在较大的token数量(高GEMM-M)下,这一层仍然内存受限,由数据移动主导;写入成本占主导地位,因为输出是FP8而输入是FP4,并且小的缩减维度使GEMM保持内存受限。
| M (Tokens) | \(N\) | \(K\) | 计算 (μs) | FP4读取 (μs) | FP8写入 (μs) |
|---|---|---|---|---|---|
| 256 | 8192 | 512 | 0.14 | 0.30 | 0.26 |
| 2048 | 8192 | 512 | 1.15 | 0.37 | 2.10 |
| 16384 | 8192 | 512 | 9.16 | 0.89 | 16.8 |
| 表2. GB300上FFN-2(\(N\) = 8192,\(K\) = 512)的理论每GEMM持续时间,假设FP4峰值计算为15 PFLOPS,峰值内存带宽为8 TB/s。在每种token数下,内存时间都超过计算时间,因此该层始终处于内存受限状态 |
图4中的图显示了在GB300硅片上的情况。使用NVFP4 GEMM并将token维度(GEMM-M)固定为较大的8192,我们扫描缩减维度(GEMM-K)(左侧图)和投影维度(GEMM-N)(右侧图)。在这两种情况下,当扫描的维度很小时,吞吐量急剧下降,证明小的\(N\)或\(K\)导致硬件利用率不足。(\(N\)和\(K\)对应不同的层取决于\(H\)或\(H’\);见上表1。)
两条折线图显示GB300上的NVFP4 GEMM吞吐量随K(左)和N(右)维度增长而上升并趋于饱和,当它们很小时则急剧下降。图4(左)。GB300上的NVFP4 GEMM吞吐量与缩减维度\(K\)的关系(\(M\) = 8192,\(N\) = 9728固定)。在\(K\) ≈ 6144附近饱和;达到持续吞吐量的80%需要\(K\) > 3072。图4(右)。GB300上的NVFP4 GEMM吞吐量与投影维度\(N\)的关系(\(M\) = 8192,\(K\) = 8448固定)。在\(N\) ≈ 6144附近饱和;达到持续吞吐量的80%需要\(N\) > 2560 这对模型设计者来说是一个重要的点:模型维度对于饱和计算的重要性与批次大小同样重要。
准则1: 对于固定参数的模型,倾向于接近方形的权重矩阵,避免使投影或缩减维度太小。
但仅凭大小还不够。为了达到高的张量核心利用率,GEMM的维度还必须干净地映射到底层的分块几何上;对齐不良会导致分块量化,即使算术强度很高也会降低吞吐量。
GPU如何执行GEMMs
https://developer.nvidia.com/blog/ai-model-co-design-hardware-friendly-llm-design/?linkId=100000430616047#how_gpus_execute_gemms%C2%A0
GPU通过将输出矩阵分割成多个分块(tile),每个分块由一个流式多处理器(SM)计算,来执行GEMM。在最近的GPU上,SM不必单独工作;它们可以协作处理一个更大的分块:通过clusterMMA,两个相邻的SM共同处理一个分块,而协作网格阵列(Cooperative Grid Array, CGA)允许整个SM组作为一个集群一起工作。
协作提高了数据复用,但也扩大了有效分块的大小,因此维度必须是一个更大值的倍数才能保持对齐。当一个维度不是该有效分块的倍数时,边缘分块只有部分被填充,但仍然会启动并运行完整分块的计算;未使用的(填充)部分不做有用功,浪费周期并降低吞吐量。图5说明了这一点:对于一个256×128的基分块、clusterMMA和一个4×2的CGA,以细粒度步长扫描GEMM-N时,当N是256(来自clusterMMA的2×128)或512(来自CGA的2×256)的倍数时,会出现局部吞吐量峰值。
锯齿状图表显示GB300上的NVFP4 GEMM吞吐量在GEMM-N是256或512的倍数时达到峰值,在之间则下降。图5. GB300上交付吞吐量的分块量化效应,测量时使用了强制使用256×128分块、clusterMMA和4×2 CGA的核函数,作用于M×N输出矩阵 为了避免这种浪费,选择模型维度时,应使其是分块大小的大倍数并与GPU缓存线宽度对齐。128的倍数是安全、可移植的下限;256(clusterMMA)或512(CGA)的倍数则与更大的协作分块对齐,并捕获最多的吞吐量。
准则2: 至少使模型维度是128的倍数,以与GPU分块大小和缓存线宽度对齐,并优先选择256或512,以匹配由clusterMMA和CGA形成的更大分块。
宽模型比深模型更硬件友好
https://developer.nvidia.com/blog/ai-model-co-design-hardware-friendly-llm-design/?linkId=100000430616047#wider_models_are_more_hardware-friendly_than_deeper_models
对于固定的参数预算,宽模型通过更高的权重复用和更短的顺序关键路径,提供比深模型更高的算术强度和更低的延迟。这使得宽模型对于面向吞吐量和面向延迟的服务目标都有优势。
也就是说,宽高比也会影响模型质量:深度有助于表示能力,因此存在一个有用的宽度-深度区间,而非“越宽越好”。只在准确性允许的范围内倾向于宽度,而不是仅仅为了加宽模型而剥离层。
准则3: 当有选择时,优先选择更少但更大的操作,而不是许多较小的操作;这可以最大化算术强度并提高硬件利用率,从而有利于吞吐量和交互性。换句话说,宽Transformer模型比深模型更硬件友好。
量化作为性能杠杆
https://developer.nvidia.com/blog/ai-model-co-design-hardware-friendly-llm-design/?linkId=100000430616047#quantization_as_a_performance_lever
量化同时有利于计算受限和内存受限的工作,因为它能同时提高数学吞吐量并减少内存流量。Blackwell系统支持NVFP4以及其他位宽格式如FP8和FP16/BF16(见下图6)。
GB300上密集张量核心吞吐量的条形图:FP16/BF16约为2.5 PFLOPS,FP8为5 PFLOPS,FP4为15 PFLOPS。图6. 不同数据类型下的密集张量核心吞吐量
NVFP4专为平衡模型准确性和速度而设计;它为每个16值微块应用细粒度的FP8(E4M3)缩放因子,再加上每个张量的二级FP32缩放因子。这种分层缩放显著减少了量化误差,同时保持了4位计算的速度,使得NVFP4能在广泛的LLM工作负载中紧密匹配更高精度的准确性(见下图7,DeepSeek-R1)。
分组条形图显示DeepSeek-R1在NVFP4下的准确性与FP8基线相比,在七个基准测试中均保持在约一个点以内。图7. DeepSeek-R1在NVFP4下的准确性与FP8基线非常接近,在大多数基准测试中保持在约一个点以内,在SciCode、Math-500和AIME 2024上匹敌或超过FP8 NVIDIA提供端到端的工具使这一点变得实用:TensorRT模型优化器 (https://github.com/NVIDIA/Model-Optimizer) 和LLM压缩器 (https://github.com/vllm-project/llm-compressor) 支持训练后量化(PTQ)、量化感知训练(QAT)和高级校准,将模型量化为NVFP4的同时最小化准确性损失。
其结果是,大多数矩阵乘法密集的操作,例如t
相似文章
@sohailmo: 如果你阅读并理解所有这些概念,你就掌握了推理优化基础知识的80/20
NVIDIA 推出了一系列关于 AI 模型协同设计的文章,从模型维度如何影响 GPU 性能开始,作者称这涵盖了推理优化基础知识的80/20。
@rickawsb: 英伟达也认为存储是比gpu更大的瓶颈 — nvda最新文章解读 NVIDIA 最新发布的《AI Model Co-Design》是一篇介绍 TensorRT-LLM 和 Blackwell 的技术文章, 但也是一份未来几年大模型设计和 A…
本文深入解读NVIDIA最新发布的《AI Model Co-Design》文章,指出在AI推理场景中,存储(内存带宽、权重读取)已取代GPU算力成为主要瓶颈,并阐述了TensorRT-LLM和Blackwell架构围绕Roofline模型的设计策略,强调减少数据移动比提升计算能力更为关键。
单GPU微调的高效异构协同设计
SlideFormer 提出了一种异构协同设计,用于在单GPU上进行全参数LLM微调,利用GPU/CPU/RAM/NVMe及其层滑动引擎和优化的Triton内核,在单张RTX 4090上实现对123B+模型的微调,吞吐量显著提升。
@akshay_pachaar: NVIDIA可能刚刚解决了LLM中最大的权衡问题。每个LLM都让你在速度和品质之间做出选择。自回归…
NVIDIA推出了TwoTower,这是一种在扩散语言模型中解耦上下文表示和去噪的方法,在30B MoE主干上实现了2.42倍的吞吐量,同时保留了98.7%的自回归质量。
大小真的重要吗?(LLMs vs. SLMs)
讨论了大语言模型(LLMs)与小语言模型(SLMs)之间的权衡,质疑在生产用例中是否总是需要更大的模型,并探讨了AI部署的未来。