硬件友好型AI模型协同设计中的LLM优化
评估AI性能需平衡准确性、吞吐量与交互性。硬件友好的LLM设计应优先选择更宽的模型,维度至少为128的倍数,并利用NVFP4等低精度量化提升效率。专家并行与注意力数据并行可有效提高吞吐量,降低延迟。
评估AI性能,实际上只需关注三个关键维度:准确性、吞吐量和交互性。
- 准确性:模型推理结果与输出内容的质量表现。
- 吞吐量:整个数据中心每秒钟能够生成的Token数量。
- 交互性:用户实际感受到的响应速度,核心衡量指标是延迟。
实际部署时必须兼顾三者。如果算得快但结果不准,毫无价值;如果精准度极高却需要等待很久,同样不可接受。因此,实用的系统必须在准确性、吞吐量和交互性之间找到最佳平衡点。
本文将重点探讨吞吐量与交互性,分析模型设计上的选择如何影响这两项指标,同时尽量不牺牲准确性(当然,在涉及准确性取舍的地方,我们也会明确指出)。
首先将准确性作为一个固定变量,问题就转化为一个二维帕累托前沿:改善一个指标,通常要以牺牲另一个为代价。我们的目标是推动整个帕累托前沿向外扩展,最大化曲线下的面积(如图1所示)。
我们从当前最主流的AI工作负载——大语言模型(LLM)开始分析。这个权衡存在两个视角:一个是系统部署者,他们优先考虑整个集群的吞吐量(tokens/sec);另一个是用户,他们更关注较低的首次Token延迟和Token间延迟。Token间延迟的倒数就是每个用户每秒的Token数,这个值越高,意味着响应越快。
一次典型的请求响应流程如下:提示词 → [首次Token延迟] → 第一个Token → [Token间延迟] → 下一个Token,以此类推。
本文是为那些希望自己的模型能在现代硬件上高效运行的模型开发者准备的实用指南。核心思想很简单:与硬件设计对齐的模型,不仅跑得更快,而且更容易扩展、成本更低、应用范围也更广。
首先,我们来看部署的“地貌”,它主要沿着两个轴变化(如图2所示)。
工作负载覆盖从短上下文到长上下文,服务目标则从吞吐量优先(最大化tokens/sec)到延迟优先(最小化响应时间)。当然,很多场景都处于两者之间。
不同的象限需要不同的优化策略:长上下文、吞吐量优先的推理,大部分时间花在注意力机制上;而延迟优先的推理,通过添加模型并行来缩短注意力和FFN的计算时间,但代价是增加了通信和固定开销。短上下文、吞吐量优先的推理,时间在注意力和FFN上的分布更均匀,这时可以受益于大规模并行化(比如专家并行)。
这里必须时刻牢记阿姆达尔定律:优化一个部分,其效果取决于该部分占用的时间比例。如果注意力机制占了77%的运行时间,那么优化前馈网络层带来的收益微乎其微;真正的功夫要花在注意力路径上。搞清楚自己处于哪个“体制”,才能知道该往哪里使劲。
本文会提供一些简单的经验法则,让你在早期就能做出这些关键决策,无需成为系统工程师也能榨干硬件性能。本系列后续的每一章,都会针对硬件感知设计的另一个维度,帮你避免计算瓶颈、实现数据中心级别的无缝部署、让设计匹配实际用例,并最终实现规模化应用。
设计得更聪明,部署得更快,扩展得更广。让我们开始吧。
LLM线性层的硬件友好型维度设计
Transformer设计的一个关键选择是它的“宽高比”:即模型宽度(隐藏维度H)和层数(L)之间的平衡。在Decoder-only风格的模型中,这两个因素主导了计算和内存在整个堆栈中的分布。而宽度本身又由两个维度决定:隐藏维度(H)和MLP层中的中间投影维度(H')。
H、H'和L这三个参数,共同决定了模型在并行策略上的映射是否干净,以及在多GPU上的扩展效率。本文会聚焦于这些选择如何影响吞吐量、交互性和可扩展性,特别是线性层部分。
算术强度的重要性
在任何硬件上,能达到的性能上限都由“屋顶线模型”决定。一个工作负载落在哪个位置,取决于它的算术强度,也就是每移动一个字节的内存,能执行多少次计算操作。
算术强度低的工作负载,性能受限于内存带宽(内存瓶颈);算术强度高的,则受限于设备的峰值计算能力(计算瓶颈)。当目标是最大化吞吐量(每秒Token数)时,就需要把工作负载推到计算瓶颈区域,让硬件的全部数学计算能力都派上用场。
而对延迟敏感的推理则恰恰相反,它以低并发运行,属于内存瓶颈,所以减少内存访问时间才是降低响应延迟的关键。
提高每字节操作数的一个直接方法是增大Batch Size,但模型形状也同样重要。我们来看看H和H'是如何决定一个GEMM(通用矩阵乘法)是计算瓶颈还是内存瓶颈的。在单设备上运行时,H和H'决定了GEMM的形状,其形式为:
C = A B
按照线性代数库的惯例,A是大小为M x K(M行,K列)的矩阵,B是K x N。结果C有M x N个输出,每个输出是长度为K的向量点积,需要M x N x K次融合乘加操作(FMA)。每次FMA是2次FLOP(一次乘法,一次加法),所以计算成本是:
FLOPs = 2 x M x N x K
读取字节数 = M x K x bytes_A + N x K x bytes_B
写入字节数 = M x N x bytes_C
其中bytes_A, B, C是每个元素占用的字节数,由精度决定。不太严谨地讲,把A当作输入,B当作权重,下面的表1展示了Token数、H和H'如何映射到每个线性层GEMM的M、N和K。
| 层名称 | 投影 (in → out) | 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′ |
考虑一个理想情况,每个GEMM都是“方阵”,即Token数 = H' = H。那么,一个GEMM需要执行2H³次FLOP,同时移动大约3H²个内存元素,因此算术强度随着H的增大而增大。实际后果是:当H或H'较小时,即使Token维度很大,GPU也会花更多时间在搬运数据而不是做数学运算上。
举个具体的例子,FFN-2层,假设H'=512,H=8192,在GB300上使用4-bit输入和8-bit输出。如表2所示,即使Token数(GEMM-M)很大,这个层依然是内存瓶颈,被数据搬运所主导。写入成本尤其高,因为输出是FP8,而输入是FP4,并且较小的缩减维度(K)使得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 |
图4的图表直观地展示了在GB300芯片上的情况。使用NVFP4 GEMM,并将Token维度(GEMM-M)固定在较大的8192,我们分别扫描缩减维度(GEMM-K,左图)和投影维度(GEMM-N,右图)。在这两种情况下,当被扫描的维度很小时,吞吐量都会急剧下降,这证实了较小的N或K会导致硬件利用率不足(N和K根据层不同,对应H或H',参见上面的表1)。
这对模型设计者来说是一个重要的启示:模型维度与Batch Size同样重要,都能影响计算单元的饱和程度。
准则1: 对于固定参数量的模型,应优先选择近似方形的权重矩阵,避免让投影或缩减维度变得太小。
但光有尺寸还不够。要想达到高Tensor Core利用率,GEMM的维度还必须能干净地映射到底层分块(tiling)几何结构上;对齐不良会导致分块量化,即使算术强度很高,吞吐量也会下降。
GPU如何执行GEMM
GPU执行GEMM的方式是将输出矩阵分割成若干个图块,每个图块由一个流式多处理器(SM)计算。在较新的GPU上,SM可以协同工作:通过clusterMMA,两个相邻的SM可以联手处理一个更大的图块;而协作网格阵列(CGA)则允许一组SM作为一个集群协同工作。
协作提高了数据复用率,但同时也放大了有效图块的尺寸,因此维度必须是更大值的倍数才能保持对齐。当一个维度不是有效图块的倍数时,边缘的图块会部分填充,但仍然会启动并运行一个完整图块的计算量;未使用的部分(填充区域)不产生任何有用功,浪费了计算周期并降低了吞吐量。图5展示了这一点:使用256x128的基础图块、clusterMMA和4x2的CGA,精细扫描GEMM-N,当N是256(来自clusterMMA的2x128)或512(来自CGA的2x256)的倍数时,会产生局部吞吐量峰值。
为了避免这种浪费,应选择图块尺寸的大倍数,并与GPU缓存线宽度对齐的模型维度。以128的倍数为最低基准是安全且可移植的;256(clusterMMA)或512(CGA)的倍数则与更大的协作图块对齐,能捕获最大吞吐量。
准则2: 模型维度至少应为128的倍数,以对齐GPU图块尺寸和缓存线宽度;如果能做到256或512的倍数则更佳,以匹配由clusterMMA和CGA形成的更大图块。
更宽的模型比更深的模型更“友好”
在固定参数量的预算下,更宽的模型通过更高的权重复用和更短的顺序关键路径,提供了更高的算术强度和更低的延迟。这使得更宽的模型在吞吐量优先和延迟优先的服务目标下都更具优势。
当然,宽高比也会影响模型质量:深度有助于提升模型的表征能力,因此存在一个有用的宽度-深度区间,而不是“越宽越好”。应该在不牺牲准确性的前提下尽量增加宽度,而不是为了把模型变宽而削减层数。
准则3: 在可以选择的情况下,优先选择更少但更大的操作,而不是更多且更小的操作。这能最大化算术强度并提高硬件利用率,从而在吞吐量和交互性两方面都受益。换句话说,更宽的Transformer模型比更深的模型对硬件更友好。
量化:性能的杠杆
量化对计算瓶颈和内存瓶颈的工作都有帮助,因为它能同时提高数学吞吐量和减少内存流量。Blackwell系统支持NVFP4以及其他位宽格式,如FP8和FP16/BF16(见图6)。
NVFP4是专门为平衡模型精度和速度而设计的;它对每个16值的微块应用细粒度的FP8(E4M3)缩放,并加上一个每张量的二级FP32缩放。这种分层缩放显著减少了量化误差,同时保持了4-bit计算的速度,使得NVFP4在广泛的LLM工作负载中(如图7所示,DeepSeek-R1)能够紧密匹配更高精度的准确率。
NVIDIA提供了端到端的工具使这一切变得可行:TensorRT Model Optimizer和LLM Compressor支持训练后量化(PTQ)、量化感知训练(QAT)和高级校准,可以将模型量化为NVFP4,且精度损失极小。
因此,大多数以矩阵乘法为主的操作,比如线性层,都可以充分利用NVFP4提高吞吐量,同时保持模型保真度。想了解更多关于低位宽训练的信息,可以查阅 Pretraining Large Language Models with NVFP4 (NVIDIA Research, 2025)。
准则4: 在网络中引入计算密集的操作时,应考虑它们是否能在部署时进行量化。设计能从低精度执行中受益的层,是充分发挥现代GPU性能的关键。
大规模专家并行提升吞吐量
在吞吐量优先的推理服务中,目标很简单:用最少的GPU,尽可能快地服务尽可能多的用户。由于大多数最先进的LLM现在都是混合专家模型(MoE),一个非常有效的方法是专家并行(EP):将注意力部分进行数据并行,并将FFN专家分布到不同的GPU上。
对注意力使用数据并行(DP)规避了张量并行(TP)的一个关键限制:即合并部分结果所需的昂贵的AllReduce操作。该开销会随着并发度增加而拖累吞吐量,使得TP在此场景下表现不佳。DP注意力可以更自然地扩展:增加GPU直接提高了全局并发度,而更高的并发度意味着MoE FFN中的GEMM-M更大。
假设Token是均匀路由的:
GEMM-M = (全局并发度 x top-k) / 专家数
其中,全局并发度是每GPU并发Token数乘以GPU数量,top-k是每个Token激活的专家数(DeepSeek-R1为8),专家数是专家总数(DeepSeek-R1为256)。因为GEMM-M随并发度增长而增长,随模型稀疏性增大而缩小,所以提高并发度是稀疏MoE模型实现高GEMM利用率的关键,而由于每GPU的并发度受限于KV缓存大小,因此跨更多GPU进行专家并行是提高它的主要杠杆。
即使每个专家的有效Batch(其GEMM-M)很小,无论是由于并发度有限还是Token路由不均衡,拓宽专家并行仍然在两个方面有帮助:
- 通过聚合带宽实现更快的执行: 将专家分布到更多GPU上,增加了加载专家权重的有效内存带宽,从而减少了端到端的FFN延迟。
- 减少每GPU内存占用: 每个GPU只存储一部分专家,释放了内存,从而可以增加每GPU的有效并发度,更好地饱和计算。
专家并行确实带来了两个挑战:all-to-all通信开销和专家负载不均衡。但NVIDIA在TensorRT-LLM中的Wide-EP特性解决了这两个问题:
- 高性能的all-to-all内核,可在Blackwell多节点NVLink系统上扩展专家并行;
- 一个自适应负载均衡器,能根据实时负载模式重新分配专家流量,以在Token和专家分布不平衡的情况下保持稳定。
更多细节,请参考TensorRT-LLM的专家并行扩展文档。对于吞吐量优先的MoE部署,关键杠杆就是专家并行。
准则5: 拥有大量专家、结构复杂且稀疏的MoE模型,只要采用正确的并行策略(尤其是广泛扩展专家并行),仍然可以实现高吞吐量。
为流水线并行而设计
当将预填充和解码分离时,流水线并行就变得相关了。对于某些模型大小、流量模式和延迟目标,这可以是一种有效的推理服务策略。我们在 Beyond the Buzz: A Pragmatic Take on Inference Disaggregation (NVIDIA Research, 2025) 中进行了分析:使用不同的模型分区来运行预填充和解码,可以让两者各自独立地优化和扩展,从而提高整体吞吐量。
对于预填充,在保持高吞吐量的同时降低首次Token延迟(FTL),尤其是在长上下文场景下,需要激进的并行化。分块流水线并行(CPP)非常适合这种情况:它将模型层切分到多个GPU上,同时将输入上下文分割成多个块,在流水线中流动(如图8所示)。
这使得预填充工作节点能够在严格的FTL预算内处理长序列,而无需诉诸宽张量并行(如图9所示)。
CPP只有在流水线阶段平衡时才能发挥效果;不平衡的阶段会引入流水线气泡,导致一些GPU空闲。保持阶段平衡的一个有效方法是,构建具有可重复层模式的模型,以便均匀切分。
准则6: 设计具有规则、可重复层模式的模型,使其易于切分成平衡的流水线阶段。这使模型非常适合分块流水线并行,从而在满足严格的首次Token延迟目标的同时,实现更高的吞吐量。
混合并行策略:满足延迟优先的服务目标
到目前为止,我们主要关注吞吐量。延迟优先的服务遵循不同的约束条件。更低的延迟意味着每个GPU的工作量更少(更低的并发度),或者需要更多的GPU。然而,缩小Batch Size最终只能减少注意力延迟:FFN延迟会变成内存瓶颈,因为当GEMM-M缩小时,GEMM-N和GEMM-K的维度仍然很大,使得权重矩阵的读取成为瓶颈。
在这个低并发度的场景下,注意力和FFN应该被独立地并行化。FFN通过将权重分布到多个GPU上来加速,可以使用TP、EP或TP×EP。TP更适合具有大专家的粗粒度MoE模型,而EP则更适合细粒度MoE模型,因为后者的较小H'在TP下会产生低效的小GEMM。
相比之下,注意力受益于TP和KV并行。然而,TP的扩展上限不超过KV头的数量;超过这个限制,KV缓存就必须被复制,引入冗余工作。由于现代MQA/GQA/MLA模型只有很少的KV头,这很快就会成为瓶颈。Helix并行(NVIDIA Research, 2025)通过将KV缓存在序列维度上进行分片,然后在FFN中复用相同的GPU进行TPxEP,从而克服了这个问题。TensorRT-LLM支持Helix。尽管这些混合方案引入了额外的通信,但Blackwell NVL72的高带宽NVLink架构吸收了大量成本,其余部分可以与计算重叠。
准则7: 设计模型和部署方案时,应将注意力和FFN的并行化解耦,这样扩展GPU就能通过战略性地瞄准主要瓶颈来改善交互性。
下一步行动
在你设计下一个模型时,不妨把这些准则当作一份设计清单:
- 保持维度接近方形,并对其到128(最好是256)的倍数
- 优先考虑宽度而非深度
- 为低精度(NVFP4)执行而设计模型
- 使用规则、可重复的层模式,以便于干净地映射到流水线并行
像这样的小选择,能够显著提高GPU利用率,从相同的硬件上获得更快的推理、更高的吞吐量和更好的交互性。
要将它们付诸实践,可以探索使用NVIDIA TensorRT Model Optimizer进行NVFP4量化,以及使用TensorRT-LLM实现专家并行、流水线并行和Helix并行。
你是一名 AI 行业编辑,请围绕下面这条热点输出一份资讯解读:
热点:硬件友好型AI模型协同设计中的LLM优化要求:
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题
游乐网为非赢利性网站,所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系youleyoucom@outlook.com。
相关热点网易有道在2026世界人工智能大会上展示了其AI耳机OpenPods,该产品能够支持十几种语种实时语音同传、录音转写并生成结构化纪要和思维导图。目前已实现量产,预计8月正式发布,未来还将面向全球市场销售。
二代豆包手机努比亚NaviXUltra在外观与智能体能力上均有升级。其类玻璃UI可联动豆包执行多任务并自动排队,具备主动记忆能力,越用越聪明。团队聚焦交互、架构与硬件优化,解决了安全隐私等工程化问题。
在WAIC2026上,奕行智能发布业界首个RISC-VAI算力超节点方案,基于自研Epoch芯片与ELink高速互联,突破算力墙与生态墙。同步推出KernelFab算子智造中枢,Agent驱动算子开发从周级迈入天级,并启动VISA开源计划,实现国产AI算力全栈自主可控。
用万兴天幕生成促销主视觉的核心是让折扣数字突出。通过文生图、局部重绘、图生图及AI配色锁定促销氛围,借助构图辅助线与文字优先渲染强化视觉层级,最后用高清修复锐化文字,确保冲击力。
- 日榜
- 周榜
- 月榜
热点快看
