AI 性能归结为三个维度：
准确性：模型推理和生成输出的质量如何吞吐量：数据中心每秒能生成多少 token交互性：模型对用户的响应速度，主要由延迟决定
部署必须平衡这三者：如果响应缓慢，高准确性就白费了；如果每个用户的体验都很卡顿，原始吞吐量就意义不大。因此，实际系统会同时优化准确性、吞吐量和交互性。
本文重点关注吞吐量和交互性，以及模型设计选择如何在不牺牲准确性的前提下塑造这两者（我们会在出现准确性权衡时加以说明）。
在准确性固定的情况下，问题就变成了一个二维帕累托前沿：改善其中一个通常要以另一个为代价。目标是推动整个前沿向外移动，最大化曲线下的面积（见下方图 1）。
图 1. 系统吞吐量与交互性的帕累托前沿
我们将从 LLM 开始，这是当今最突出的 AI 工作负载。这种权衡有两个视角：系统部署者，优先考虑集群吞吐量（tokens/秒）；以及用户，看重更低的首 token 延迟和 token 间延迟。token 间延迟的倒数就是 tokens/秒/用户，数值越高意味着响应性越好。
单次响应看起来像这样：提示 → [首 token 延迟] → 首个 token → [token 间延迟] → 下一个 token，依此类推。
这是一份面向模型开发者的实用入门指南，帮助他们让模型在现代硬件上良好运行。思路很简单：与硬件相匹配的模型不仅能运行得更快，还能扩展得更好、成本更低，并获得更广泛的采用。
首先，考虑部署格局，它沿两个轴变化（见下方图 2）。
图 2. 不同工作负载模式（横轴）和服务目标（纵轴）下的延迟分解
工作负载从短上下文到长上下文不等，服务目标从面向吞吐量（最大化 tokens/秒）到面向延迟（最小化响应时间）不等；许多介于两者之间。
每个象限需要不同的优化：长上下文、面向吞吐量的服务大部分时间花在注意力上，而面向延迟的服务则增加模型并行来缩短注意力和 FFN，代价是通信和固定开销。短上下文、面向吞吐量的服务在注意力和 FFN 之间更均匀地分配时间，并且在大规模下可以从并行（如专家并行）中受益。
阿姆达尔定律适用：优化某一部分的帮助仅与其占用的时间成正比。如果注意力占运行时间的 77%，调整前馈层只能带来边际收益；注意力路径才是投入精力有回报的地方。了解你的模式就能知道该把重点放在哪里。
本文提供了一些简单的经验法则，帮助任何希望在不成为系统工程师的情况下，从硬件中获得最大收益的人尽早做出这些决策。本系列的后续每一章都将针对硬件感知设计的不同维度，帮助你避免计算瓶颈、在数据中心规模上无摩擦地部署、使设计与你的用例相匹配，并在实践中扩展。
更智能地设计。更快速地部署。更广泛地扩展。让我们开始吧。
LLM 中线性层的硬件友好维度设计
Transformer 的一个关键设计选择是其宽高比：模型宽度与层数（(L)）之间的平衡。在解码器风格的模型中，这些因素主导了计算和内存如何在堆栈中分布。宽度本身由两个维度决定：隐藏维度（(H)）和 MLP 层中的中间投影维度（(H’)）。
(H)、(H’) 和 (L) 共同决定了模型如何清晰地映射到并行策略上，以及它在 GPU 上的扩展能力。本文探讨这三个选择如何影响吞吐量、交互性和可扩展性，并重点关注线性层。
算术强度的作用
在任何硬件上，可达到的性能都受 roofline 模型限制。工作负载落在何处取决于其算术强度，即每移动一字节内存所执行的计算操作数。
算术强度低的工作负载受内存带宽限制（内存受限）；算术强度高的工作负载受设备峰值计算吞吐量（以 FLOPS 计）限制（计算受限）。当目标是最大吞吐量（每秒 token 数）时，你希望将工作负载驱动到计算受限区域，从而充分利用硬件的全部数学能力。
延迟敏感的解码则相反，它以低并发运行且受内存限制，因此减少内存访问时间才是降低响应延迟的关键。
图 3. Roofline 模型。在脊点以下，工作负载受内存带宽限制；在脊点以上，受设备峰值计算吞吐量限制。工作负载的算术强度（每字节操作数）决定了它属于哪个区域
提高每字节操作数的一种直接方法是增加批大小，但模型形状也很重要。让我们看看 (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{并发数} \times \text{序列长度})）、(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. transformer 块中线性层的 GEMM 维度（M、N、K），以 Tokens、H 和 H′ 表示
考虑每个 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 持续时间，假设 15 PFLOPS 峰值 FP4 计算和 8 TB/s 峰值内存带宽。在每个 token 数量下，内存时间都超过数学时间，因此该层始终受内存限制
下面的图 4 中的图表在 GB300 硅片上展示了这一点。使用 NVFP4 GEMM 并将 token 维度（GEMM-M）固定为较大的 8192，我们扫描归约维度（GEMM-K）（左图所示）和投影维度（GEMM-N）（右图所示）。在两种情况下，当被扫描的维度较小时，吞吐量急剧下降，证实较小的 (N) 或 (K) 会导致硬件利用率不足。（(N) 和 (K) 根据层对应 (H) 或 (H’)；参见上面的表 1。）
图 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：*对于固定参数模型，倾向于接近方形的权重矩阵，避免使投影或归约维度过小。
但仅靠尺寸还不够。要达到高 Tensor Core 利用率，GEMM 的维度还必须干净地映射到底层的分块几何结构上；对齐不佳会导致分块量化，即使算术强度很高，也会降低吞吐量。
GPU 如何执行 GEMM
GPU 通过将输出矩阵拆分为分块来执行 GEMM，每个分块由一个流式多处理器（SM）计算。在近期的 GPU 上，SM 不必单独工作；它们可以协作处理一个更大的分块：借助 clusterMMA，两个相邻的 SM 联合处理一个分块，而协作网格阵列（CGA）则让一整组 SM 作为一个集群协同工作。
协作提高了数据复用，但也扩大了有效分块，因此维度必须是更大值的倍数才能保持对齐。当某个维度不是该有效分块的倍数时，边缘分块只被部分填充，却仍会启动并运行相当于一个完整分块的计算量；未使用（填充）的部分不做有用功，浪费周期并降低吞吐量。图 5 说明了这一点：在 256×128 基础分块、clusterMMA 和 4×2 CGA 下，以细粒度步长扫描 GEMM-N 时，当 N 是 256（来自 clusterMMA 的 2×128）或 512（来自 CGA 的 2×256）的倍数时，会产生局部吞吐量峰值。
图 5. 分块量化对 GB300 上实际吞吐量的影响，使用强制采用 256×128 分块、clusterMMA 和 4×2 CGA 的内核在 M×N 输出矩阵上测量
为避免这种浪费，请选择分块尺寸的大倍数且与 GPU 缓存行宽度对齐的模型维度。128 的倍数是安全、可移植的下限；256（clusterMMA）或 512（CGA）的倍数与更大的协作分块对齐，可获得最大吞吐量。
准则 2：* 使模型维度至少为 128 的倍数，以与 GPU 分块尺寸和缓存行宽度对齐，并优先选择 256 或 512，以匹配由 clusterMMA 和 CGA 形成的更大分块。*
更宽的模型比更深的模型对硬件更友好
在固定参数预算下，更宽的模型通过更大的权重复用和更短的顺序关键路径，比更深的模型提供更高的算术强度和更低的延迟。这使得更宽的模型对吞吐量导向和延迟导向的服务目标都有利。
话虽如此，宽高比也会影响模型质量：深度有助于表征能力，因此存在一个有用的宽度与深度区间，而不是“越宽越好”。仅在准确率保持的前提下偏向宽度，而不是为了加宽模型而削减层数。
准则 3：* 在有选择时，优先选择更少、更大的操作，而不是许多更小的操作；这能最大化算术强度并提高硬件利用率，有利于吞吐量和交互性。换句话说，更宽的 Transformer 模型比更深的模型对硬件更友好。*
量化作为性能杠杆
量化同时提升数学吞吐量并减少内存流量，因此对计算受限和内存受限的工作都有帮助。Blackwell 系统支持 NVFP4 以及其他位宽格式，如 FP8 和 FP16/BF16（见下方图 6）。
图 6. 各数据类型下的密集 Tensor Core 吞吐量
NVFP4 专为平衡模型精度与速度而设计；它对每个 16 值微块应用细粒度的 FP8 (E4M3) 缩放，并对每个张量应用第二级 FP32 缩放。这种分层缩放显著降低了量化误差，同时保持 4 位计算的速度，使 NVFP4 在广泛的 LLM 工作负载中能够接近更高精度的准确率（见下方图 7，DeepSeek-R1）。
图 7. DeepSeek-R1 在 NVFP4 下的准确率与 FP8 基线非常接近，在大多数基准测试中相差约一个百分点以内，并在 SciCode、Math-500 和 AIME 2024 上达到或超过 FP8
NVIDIA 提供端到端工具使其切实可行：NVIDIA 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 路由均匀：
(\text{GEMM-}M = \frac{\text{global concurrency} \times \text{top-}k}{#\text{experts}})
其中 global concurrency 是每 GPU 并发 token 数 × GPU 数量，top-k 是* 每个 token 激活的专家数（DeepSeek-R1 为 8），#experts 是 *专家总数（DeepSeek-R1 为 256）。由于 GEMM-M 随并发量增长并随模型稀疏性缩小，提升并发量是在稀疏 MoE 模型中实现高 GEMM 利用率的关键，而由于每 GPU 并发量受 KV 缓存占用限制，在更多 GPU 上扩展 EP 是提高它的主要手段。
即使每个专家的有效批次（其 GEMM-M）很小，无论是由于并发受限还是令牌路由不均衡，扩大 EP 仍然在两个方面有所帮助：
- 通过聚合带宽实现更快的执行：将专家分布到更多 GPU 上，增加了用于加载专家权重的有效内存带宽，从而减少端到端 FFN 延迟。
- 减少每 GPU 内存占用：每个 GPU 只存储一部分专家，释放内存以提高每 GPU 的有效并发度，并更好地饱和计算。
EP 确实带来了两个挑战：全对全通信开销和专家负载不均衡，但 NVIDIA 在 TensorRT-LLM 中的 Wide-EP 功能解决了这两个问题：
- 高性能全对全内核，可在 Blackwell 多节点 NVLink 系统上扩展 EP，以及
- 自适应负载均衡器，根据实时负载模式重新分配专家流量，以在倾斜的令牌和专家分布下保持稳定。
有关详细信息，请参阅 TensorRT-LLM 关于专家并行扩展的文档。对于面向吞吐量的 MoE 部署，关键杠杆是专家并行。
*指南 5：*具有大量专家的复杂、稀疏 MoE 模型在采用正确的并行策略部署时仍能提供高吞吐量，最显著的是通过广泛扩展专家并行。
为流水线并行而设计
当您分离预填充和解码时，流水线并行变得相关，这可能是针对某些模型大小、流量模式和延迟目标的有效服务策略，正如我们在超越炒作：对推理分离的务实看法（NVIDIA Research，2025）中所分析的：使用不同的模型分区运行预填充和解码，可以让每个部分独立优化和扩展，从而提高整体吞吐量。
对于预填充，在减少首令牌延迟（FTL）的同时保持高吞吐量，尤其是在长上下文上，需要积极的并行化。分块流水线并行（CPP）非常适合这里：它将模型层拆分到 GPU 上，并将输入上下文分成块，这些块流经流水线（见下图 8）。
图 8. 分块流水线并行将令牌和层拆分到 GPU 上以进行流水线执行
这使得预填充工作器能够在严格的 FTL 预算内处理长序列，而无需诉诸于宽张量并行（见下图 9）。
图 9. 分块流水线并行在不牺牲吞吐量的情况下减少 FTL。示例：DeepSeek-R1 预填充在 256K 输入长度下，增加流水线并行大小可减少 FTL，而 tokens/s/GPU 大致保持不变
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 并行（NVIDIA Research，2025）通过在注意力期间沿序列维度分片 KV 缓存，然后在 FFN 中复用相同的 GPU 进行 TPxEP，克服了这一问题。Helix 已在 TensorRT-LLM 中支持。尽管这些混合方案引入了额外的通信，但 Blackwell NVL72 的高带宽 NVLink 架构吸收了大部分成本，而其余部分可以与计算重叠。
*准则 7：*设计模型和部署，将注意力和 FFN 并行化解耦，以便通过战略性地针对主要瓶颈来扩展 GPU 以提高交互性。
后续步骤
在设计下一个模型时，请将这些准则视为设计检查清单：
- 保持维度接近正方形并对齐到 128（理想情况下为 256）
- 优先选择宽度而非深度
- 为低精度（NVFP4）执行设计模型
- 使用规则、可重复的层模式，以便清晰地映射到流水线并行
诸如此类的小选择可以显著提高 GPU 利用率，从相同的硬件提供更快的推理、更高的吞吐量和更好的交互性。
要将这些付诸实践，请探索 NVIDIA Model Optimizer 进行 NVFP4 量化，以及 TensorRT-LLM 用于专家、流水线和 Helix 并行。