AI 性能取决于三个维度：
- 准确率：模型推理和生成输出的表现
- 吞吐量：数据中心每秒能生成的 token 数量
- 交互性：模型对用户的响应速度，主要由延迟决定
部署必须平衡这三者：如果响应速度慢，再高的准确率也毫无价值；而如果每个用户的体验存在延迟，原始吞吐量再高也意义不大。因此，实际系统需要同时优化准确率、吞吐量和交互性。
本文聚焦于吞吐量和交互性，以及模型设计选择如何在不牺牲准确率的前提下影响这两者（文中会在出现准确率权衡时予以标注）。
在保持准确率不变的情况下，问题转化为二维帕累托前沿：改善其中一个维度通常会以牺牲另一个维度为代价。目标是将整个前沿向外扩展，最大化曲线下方的面积（见下文图 1）。
我们将从 LLM 入手，这是当今最突出的 AI 工作负载。该权衡存在两个视角：系统部署者优先考虑集群吞吐量（tokens/sec），而用户则更看重更低的首 token 延迟和 token 间延迟。token 间延迟的倒数即 tokens/sec/user，该值越高表示响应性越好。
一次响应的流程如下：prompt → [首 token 延迟] → 首 token → [token 间延迟] → 下一个 token，依此类推。
本文是为希望模型在现代硬件上运行良好的模型开发者准备的实用入门指南。核心理念很简单：与硬件对齐的模型不仅运行更快，还能更好地扩展、降低成本并实现更广泛的采用。
首先，考虑部署场景，它沿两个维度变化（见下文图 2）。
工作负载从短上下文到长上下文不等，服务目标从吞吐量导向（最大化 tokens/sec）到延迟导向（最小化响应时间）；许多场景介于两者之间。
每个象限需要不同的优化策略：长上下文、吞吐量导向的服务将大部分时间花费在注意力计算上，而延迟导向的服务则通过增加模型并行度来缩短注意力和 FFN 的计算时间，但会产生通信开销和固定开销。短上下文、吞吐量导向的服务在注意力和 FFN 之间分配时间更均衡，并且在大规模时可从并行性（如专家并行）中获益。
阿姆达尔定律在此适用：优化某个部分仅在该部分占用时间比例足够高时才有效。如果注意力占运行时间的 77%，那么调优前馈层只能带来边际增益；注意力路径才是值得投入的。了解你所处的场景，才能决定优化的重点。
本文为模型开发者提供简单的经验法则，帮助他们在早期做出决策，从而在无需成为系统工程师的情况下最大化硬件利用率。本系列的后续章节将针对硬件感知设计的不同维度展开，帮助你避免计算瓶颈、实现数据中心规模的无摩擦部署、匹配设计与使用场景，以及在实践中扩展。
更智能的设计。更快速的部署。更广泛的扩展。让我们开始吧。
LLM 中线性层的硬件友好维度设计
Transformer 的一个关键设计选择是其宽高比：模型宽度与层数（\(L\)）之间的平衡。在解码器风格的模型中，这些因素主导了计算和内存在整个网络中的分布。宽度本身由两个维度决定：隐藏维度（\(H\)）和 MLP 层中的中间投影维度（\(H’\)）。
同时，\(H\)、\(H’\) 和 \(L\) 还决定了模型如何清晰地映射到并行策略，以及它在 GPU 间的扩展性如何。本文将探讨这三个选择如何影响吞吐量、交互性和可扩展性，并重点关注线性层。
算术强度的作用
在任何硬件上，可实现的性能都受限于 roofline 模型。工作负载所处的位置取决于其算术强度，即每移动一字节内存所执行的计算操作数。
低算术强度的工作负载受内存带宽限制（内存受限）；高算术强度的工作负载受设备峰值计算吞吐量（FLOPS）限制（计算受限）。当目标是最大化吞吐量（每秒 token 数）时，你希望将工作负载推入计算受限区域，从而充分利用硬件的全部数学能力。
而对延迟敏感的解码则相反，它在低并发下运行且受内存限制，因此减少内存访问时间是降低响应延迟的关键。
提高每字节操作数的一种直接方法是增加批次大小，但模型形状也很重要。让我们来看看 \(H\) 和 \(H’\) 如何决定一个 GEMM 是计算受限还是内存受限。在单设备上运行时，\(H\) 和 \(H’\) 决定了形如以下的 GEMM 的形状：
\(C = AB\)
按照典型线性代数库的惯例，\(A\) 是大小为 \(M \times K\) 的矩阵（\(M\) 行，\(K\) 列），\(B\) 是 \(K \times N\)。乘积 \(C\) 有 \(M \times N\) 个输出，每个输出是长度为 \(K\) 的点积，需要 \(M \times N \times K\) 次融合乘加（FMA）。由于每次 FMA 为 2 FLOPs（一次乘法、一次加法），计算成本如下：
\(\text{FLOPs} = 2 \times M \times N \times K\)
\(\text{Read Bytes} = M \times K \times \text{bytes}_A + N \times K \times \text{bytes}_B\)
\(\text{Write Bytes} = M \times N \times \text{bytes}_C\)
其中 \(\text{bytes}_{A,B,C}\) 是由所用精度决定的每个元素的字节数。以 \(A\) 作为输入、\(B\) 作为权重，表 1（见下文）将 token 数量（\(\text{Tokens} = \text{concurrency} \times \text{sequence length}\))、\(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′ |
表 1. Transformer 块中线性层的 GEMM 维度（M、N、K），以 Tokens、H 和 H′ 表示
考虑一个所有 GEMM 均为“方阵”的情况，即 \(\text{Tokens} = H’ = H\)。单个 GEMM 执行 \(2H^{3}\) FLOPs，同时移动约 \(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\) | math (µs) | FP4 read (µs) | FP8 write (µ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。）
这对模型设计者来说是一个重要观点：模型维度与批次大小同样重要，都能影响计算饱和度。
准则 1： 对于固定参数量的模型，倾向于使用接近方阵的权重矩阵，避免使投影维度或归约维度过小。
但仅尺寸足够大还不够。要实现高 Tensor Core 利用率，GEMM 的维度还必须干净地映射到底层瓦片几何结构；对齐不良会导致瓦片量化，即使算术强度很高，吞吐量也会下降。
GPU 如何执行 GEMM
GPU 通过将输出矩阵拆分为瓦片来执行 GEMM，每个瓦片由一个流式多处理器（SM）计算。在较新的 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）的倍数时，会出现局部吞吐量峰值。
为避免这种浪费，请选择模型维度为瓦片尺寸的大倍数，并与 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 位计算的速度，使 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 现在大多是 Mixture-of-Experts (MoE) 模型，实现这一目标的一种高效方法是专家并行（EP）：对注意力使用数据并行，并将 FFN 专家分布到各 GPU 上。
对注意力使用数据并行（DP）避免了张量并行（TP）的一个关键限制——将部分结果合并所需的昂贵 AllReduce。该开销随并发度增长并拖累吞吐量，使 TP 在此场景下不适用。DP 注意力扩展更自然：增加 GPU 可直接提高全局并发度，而更高的并发度意味着 MoE FFN 中的 GEMM-M 更大。
假设均匀 token 路由：
\(\text{GEMM-}M = \frac{\text{global concurrency} \times \text{top-}k}{\#\text{experts}}\)
其中全局并发度是每 GPU 并发 token 数 × GPU 数量，top-k 是每个 token 激活的专家数（DeepSeek-R1 为 8），#experts 是专家总数（DeepSeek-R1 为 256）。由于 GEMM-M 随并发度增长、随模型稀疏度减小，推动并发度是稀疏 MoE 模型中实现高 GEMM 利用率的关键，而由于每 GPU 并发度受 KV 缓存占用限制，扩展 EP 到更多 GPU 是提高它的主要手段。
即使每个专家的有效批次（其 GEMM-M）较小（无论是由于并发度有限还是 token 路由不均衡），扩展 EP 仍能在两个方面提供帮助：
- 通过聚合带宽实现更快执行：将专家分布到更多 GPU 上，增加了加载专家权重可用的有效内存带宽，从而减少端到端 FFN 延迟。
- 减少每 GPU 内存占用：每个 GPU 仅存储部分专家，释放内存以提高每 GPU 有效并发度，更好地饱和计算。
EP 会带来两个挑战——全对全通信开销和专家负载不均衡，但 NVIDIA 的 Wide-EP 功能（在 TensorRT-LLM 中）解决了这两个问题：
- 可在 Blackwell 多节点 NVLink 系统上扩展 EP 的高性能全对全内核，以及
- 根据实时负载模式重新分配专家流量的自适应负载均衡器，以在偏斜的 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 数量。然而，缩小批次最终只会降低注意力延迟：FFN 延迟会变为内存受限，因为当 GEMM-M 缩小时，GEMM-N 和 GEMM-K 维度仍保持较大，导致 \(N \times K\) 矩阵的权重读取成为瓶颈。
在这种低并发度场景下，注意力和 FFN 应独立并行化。FFN 可通过 TP、EP 或 TP×EP 将权重分布到 GPU 上来加速。TP 适合具有大专家的粗粒度 MoE 模型，而 EP 更适合细粒度 MoE 模型，因为其较小的 \(H’\) 在 TP 下会产生低效的小 GEMM。
相比之下，注意力受益于 TP 和 KV 并行。然而，TP 的扩展仅限于 KV 头数量；超过该数量后，KV 缓存必须复制，引入冗余工作。由于现代 MQA/GQA/MLA 模型的 KV 头数量很少，这很快会成为瓶颈。Helix Parallelism（NVIDIA Research，2025）通过在注意力期间按序列维度对 KV 缓存进行分片，然后在 FFN 中重用同一批 GPU 进行 TPxEP 来克服这一限制。Helix 已在 TensorRT-LLM 中得到支持。虽然这些混合方案会引入额外通信，但 Blackwell NVL72 的高带宽 NVLink 结构可吸收大部分成本，剩余部分可与计算重叠。
准则 7：设计模型和部署以解耦注意力和 FFN 的并行化，从而通过战略性地针对主要瓶颈来扩展 GPU 以改善交互性。
后续步骤
在设计下一个模型时，请将这些准则视为设计检查清单：
- 保持维度接近方阵并对齐到 128（理想情况下 256）
- 优先选择宽度而非深度
- 为低精度（NVFP4）执行设计模型
- 使用规则、可重复的层模式，使其能干净地映射到流水线并行
诸如此类的小选择可以显著提高 GPU 利用率，从相同硬件中获得更快的推理、更高吞吐量和更好的交互性。
要将它们付诸实践，请探索 NVIDIA TensorRT Model Optimizer 以进行 NVFP4 量化，以及 TensorRT-LLM 以实现专家、流水线和 Helix 并行。
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.