> ## Documentation Index
> Fetch the complete documentation index at: https://se7en.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 第一章：介绍与 AI 系统概览

## 录屏回看

<iframe src="https://player.bilibili.com/player.html?bvid=BV1mxoFB9EWM&autoplay=0&high_quality=1" width="100%" height="480" scrolling="no" frameBorder="0" allowFullScreen />

***

## 本章概要

2024 年底，中国初创公司 DeepSeek 用 2048 块受出口管制限制的 H800 GPU，训练出了 671B 总参数、每个 token 激活 37B 参数的 MoE 模型 [DeepSeek-V3](https://github.com/deepseek-ai/DeepSeek-V3)。根据其[技术报告](https://arxiv.org/abs/2412.19437)，DeepSeek-V3 在语言理解、阅读理解和推理等多项标准化测试上接近甚至部分超过 GPT-4，而完整训练仅需 278.8 万 H800 GPU 小时。假设 H800 的租赁价格为每小时 2 美元，总训练成本仅为 **557.6 万美元**（该数字仅包含正式训练，不含前期架构探索和消融实验）。

随后推出的推理模型 [DeepSeek-R1](https://github.com/deepseek-ai/DeepSeek-R1) 进一步逼近 OpenAI o1 的水平。消息一出，NVIDIA 股价单日跌了约 17%，据 [路透社报道](https://www.reuters.com/technology/chinas-deepseek-sets-off-ai-market-rout-2025-01-27/)市值蒸发近 5930 亿美元，创下华尔街单只股票单日最大市值损失纪录。

作为对比，训练 GPT-4 估计花了约 **1 亿**美元，训练 Gemini Ultra 估计花了**约 1.9 亿**美元。在这个规模上，系统效率每提高一点，省下来的就不是小数目。而 DeepSeek 在硬件更受限的条件下，用不到 GPT-4 训练成本 **1/18** 的预算达到了相近效果，靠的正是硬件、软件和算法的协同设计。

本章先从 DeepSeek 在 H800 约束下的模型与系统优化讲起，包括 MoE 架构、DeepSeek-R1 以及 FlashMLA、DeepGEMM、DeepEP、3FS 等工程创新；再把视角扩展到万亿到百万亿参数模型面临的计算与内存瓶颈，以及 GB200、Vera Rubin 等机架式 AI 超级计算机如何提供系统级支撑；最后通过 FlashAttention、MLA 和低精度量化这些例子，说明大模型性能和成本的上限并不只取决于单个算法或单代 GPU，而取决于硬件、软件和算法能否围绕同一组瓶颈协同演进。

***

## 章节详解

### 1. DeepSeek：硬件受限下的极致优化

2024 年底，中国初创公司 DeepSeek 在没有最新 NVIDIA GPU 的情况下，训练出了接近前沿水平的大语言模型，震动了整个 AI 社区。

#### 1.1 硬件约束

由于美国出口管制，DeepSeek 无法获得顶级的 Blackwell（B200、B300）或完整版 Hopper（H100、H200）GPU，只能使用出口合规的 H800。下面这张表可以看出 H800 和其他型号的差距：

| 指标                                                                                      | [H800 SXM](https://chaoqing-i.com/upload/20231128/NVIDIA%20H800%20GPU%20Datasheet.pdf) | [H100 SXM](https://www.nvidia.com/en-us/data-center/h100/) | [H200 SXM](https://www.nvidia.com/en-us/data-center/h200/) | [B200](https://nvdam.widen.net/s/wwnsxrhm2w/blackwell-datasheet-3384703) | [B300](https://resources.nvidia.com/en-us-blackwell-architecture/blackwell-ultra-datasheet?ncid=pa-srch-goog-435826) |
| --------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------: | ---------------------------------------------------------: | ---------------------------------------------------------: | -----------------------------------------------------------------------: | -------------------------------------------------------------------------------------------------------------------: |
| **架构**                                                                                  |                                                                                 Hopper |                                                     Hopper |                                                     Hopper |                                                                Blackwell |                                                                                                            Blackwell |
| **FP64**                                                                                |                                                                               1 TFLOPS |                                                  34 TFLOPS |                                                  34 TFLOPS |                                                            **37 TFLOPS** |                                                                                                           1.2 TFLOPS |
| **FP64 Tensor Core**                                                                    |                                                                               1 TFLOPS |                                              **67 TFLOPS** |                                              **67 TFLOPS** |                                                                37 TFLOPS |                                                                                                           1.2 TFLOPS |
| **FP32**                                                                                |                                                                              67 TFLOPS |                                                  67 TFLOPS |                                                  67 TFLOPS |                                                            **75 TFLOPS** |                                                                                                        **75 TFLOPS** |
| **TF32 Tensor Core**                                                                    |                                                                             989 TFLOPS |                                                 989 TFLOPS |                                                 989 TFLOPS |                                                         **2,250 TFLOPS** |                                                                                                     **2,250 TFLOPS** |
| **FP16 Tensor Core**                                                                    |                                                                           1,979 TFLOPS |                                               1,979 TFLOPS |                                               1,979 TFLOPS |                                                         **4,500 TFLOPS** |                                                                                                     **4,500 TFLOPS** |
| **BF16 Tensor Core**                                                                    |                                                                           1,979 TFLOPS |                                               1,979 TFLOPS |                                               1,979 TFLOPS |                                                         **4,500 TFLOPS** |                                                                                                     **4,500 TFLOPS** |
| **FP8 Tensor Core**                                                                     |                                                                           3,958 TFLOPS |                                               3,958 TFLOPS |                                               3,958 TFLOPS |                                                         **9,000 TFLOPS** |                                                                                                     **9,000 TFLOPS** |
| **INT8 Tensor Core**                                                                    |                                                                             3,958 TOPS |                                                 3,958 TOPS |                                                 3,958 TOPS |                                                           **9,000 TOPS** |                                                                                                             307 TOPS |
| **FP4 Tensor Core**                                                                     |                                                                                      — |                                                          — |                                                          — |                                                        **18,000 TFLOPS** |                                                                                                    **18,000 TFLOPS** |
| **GPU Memory**                                                                          |                                                                                  80 GB |                                                      80 GB |                                                     141 GB |                                                                   180 GB |                                                                                                           **270 GB** |
| **GPU Memory Bandwidth**                                                                |                                                                              3.35 TB/s |                                                  3.35 TB/s |                                                   4.8 TB/s |                                                             **7.7 TB/s** |                                                                                                         **7.7 TB/s** |
| **[Multi-Instance GPU](https://www.nvidia.com/en-us/technologies/multi-instance-gpu/)** |                                                                                      7 |                                                          7 |                                                          7 |                                                                        7 |                                                                                                                    7 |
| **Interconnect**                                                                        |                                                  NVLink: 400 GB/s, PCIe Gen5: 128 GB/s |                      NVLink: 900 GB/s, PCIe Gen5: 128 GB/s |                      NVLink: 900 GB/s, PCIe Gen5: 128 GB/s |                                **NVLink: 1.8 TB/s**, PCIe Gen5: 128 GB/s |                                                                        **NVLink: 1.8 TB/s**, **PCIe Gen6: 256 GB/s** |

H800 在算力上与 H100 接近，但 **NVLink 互连带宽被砍到不到一半**（400 vs 900 GB/s）。与 B300 相比差距更为悬殊：**NVLink 带宽差 4.5 倍**（400 GB/s vs 1.8 TB/s），**显存容量差 3.4 倍**（80 vs 270 GB），**显存带宽差 2.3 倍**（3.35 vs 7.7 TB/s），**FP8 和 FP16 Tensor Core 算力差 2.3 倍**。

<Accordion title="峰值算力单位">
  **TFLOPS** = Tera Floating-Point Operations Per Second，即每秒万亿次浮点运算。

  * **T**（Tera）= $10^{12}$
  * **FL**（Floating-Point）= 浮点
  * **OPS**（Operations Per Second）= 每秒运算次数

  例如 H100 的 FP16 Tensor Core 峰值算力 1,979 TFLOPS，即每秒最多执行约 $1.979 \times 10^{15}$ 次 FP16 浮点运算。

  表格中 INT8 行用的是 **TOPS**（Tera Operations Per Second），因为整数运算不属于浮点运算，去掉了 FL。
</Accordion>

<Accordion title="数据精度">
  ### 精度格式一览

  GPU 规格表里会出现多种数值精度格式，它们决定了每个数字占多少位、能表示多大范围和多高精度。位数越少，每个周期能算的数越多，TFLOPS 越高，但精度越低。

  | 格式                                                                                                                                   |               位数（符号+指数+尾数） | 首次广泛使用                 | 应用场景                                                                                                                                                                                                                                                                                  |
  | ------------------------------------------------------------------------------------------------------------------------------------ | -------------------------: | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
  | **FP64**                                                                                                                             |                64（1+11+52） | 通用计算时代                 | 科学计算（HPC），AI 训练中几乎不用                                                                                                                                                                                                                                                                  |
  | **FP32**                                                                                                                             |                 32（1+8+23） | 通用计算时代                 | 早期深度学习默认精度；现在优化器（[AdamW](https://arxiv.org/abs/1711.05101)）状态仍保持 FP32                                                                                                                                                                                                                 |
  | **[FP16](https://arxiv.org/abs/1710.03740)**                                                                                         |                 16（1+5+10） | 2017（混合精度训练）           | 早期混合精度训练和推理，逐渐被 BF16 取代                                                                                                                                                                                                                                                               |
  | **[BF16](https://cloud.google.com/blog/products/ai-machine-learning/bfloat16-the-secret-to-high-performance-on-cloud-tpus)**         |                  16（1+8+7） | 2018（Google TPU）       | 当前最主流的训练精度，[Llama 3](https://arxiv.org/abs/2407.21783) 等均使用 BF16 训练                                                                                                                                                                                                                   |
  | **[TF32](https://developer.nvidia.com/blog/accelerating-ai-training-with-tf32-tensor-cores/)**                                       |                 19（1+8+10） | 2020（NVIDIA Ampere）    | Tensor Core 自动用 TF32 加速 FP32 矩阵乘法，无需改代码                                                                                                                                                                                                                                               |
  | **INT8**                                                                                                                             |                          8 | 2020（推理量化）             | 训练完成后将权重从浮点压缩为整数以节省显存和加速推理，[vLLM](https://docs.vllm.ai/en/latest/features/quantization/int8/)、[SGLang](https://sgl-project.github.io/advanced_features/quantization.html)、[TensorRT-LLM](https://github.com/NVIDIA/TensorRT-Model-Optimizer) 等主流推理框架均支持。在 Hopper 及之后的 GPU 上逐渐被 FP8 取代 |
  | **[FP8](https://arxiv.org/abs/2209.05433)**                                                                                          | 8（E4M3: 1+4+3；E5M2: 1+5+2） | 2022（NVIDIA Hopper）    | [DeepSeek-V3](https://arxiv.org/abs/2412.19437) 用 FP8 训练，Hopper 开始原生支持                                                                                                                                                                                                                |
  | **[FP4](https://developer.nvidia.com/blog/using-nvfp4-low-precision-model-training-for-higher-throughput-without-losing-accuracy/)** |                   4（1+2+1） | 2024（NVIDIA Blackwell） | Blackwell 开始支持训练和推理                                                                                                                                                                                                                                                                   |

  ### 浮点数的存储结构

  浮点数的存储结构与科学计数法相同，由 **符号位**、**指数** (exponent) 和 **尾数** (mantissa) 三部分组成：

  `(-1)^符号位 × 1.尾数 × 2^指数`

  * **指数位越多** → 能表示的数值范围越大，但不影响精度
  * **尾数位越多** → 有效数字越多、精度越高，但不影响范围

  以 FP32 存储 `4.8125` 为例：

  | 符号（1 bit） | 指数（8 bit）  | 尾数（23 bit）                |
  | --------- | ---------- | ------------------------- |
  | `0`       | `10000001` | `00110100000000000000000` |

  * **符号位** = `0`：表示这个数是正数。
  * **指数位** = `10000001`₂ = 129：FP32 存的不是“真实指数”，而是“真实指数 + 偏移量（bias）”。FP32 的指数有 8 位，所以偏移量是 $2^{8-1} - 1 = 127$。因此这里的真实指数 = 129 - 127 = 2。这样设计的好处是，指数即使有正有负，存进硬件后也始终是非负整数，便于存储和比较。其他格式同理：如果指数位为 $n$，偏移量通常是 $2^{n-1} - 1$。
  * **尾数位** = `0011010...`：这里只存小数部分，前面的 `1.` 默认省略不写（称为“隐含前导 1”）。所以完整尾数其实是 `1.001101`₂，换成十进制约为 1.203125。
  * **最终值** = $(+1) \times 1.203125 \times 2^{2}$ = **4.8125**。

  ### 低精度格式的缩放机制

  低精度格式（FP8、FP4）的刻度很粗，需要 scaling factor 来补偿。

  <Frame caption="FP8、MXFP8、NVFP4 缩放策略对比。E = exponent（指数），M = mantissa（尾数）">
    <img src="https://mintcdn.com/se7en/eaMJaPAQPjy6IQ-7/books/ai-systems-performance-engineering/images/ch01-comparison-fp8-mxfp8-nvfp4.png?fit=max&auto=format&n=eaMJaPAQPjy6IQ-7&q=85&s=d46b47327e80ce99f911adc48b1faaea" alt="Comparison of FP8, MXFP8, and NVFP4 low-precision formats" width="1846" height="682" data-path="books/ai-systems-performance-engineering/images/ch01-comparison-fp8-mxfp8-nvfp4.png" />
  </Frame>

  用称重类比：秤的刻度很粗，要称一批大小差别很大的物品——

  * **传统 FP8**：所有物品共用一个秤（per-tensor scaling），量程必须覆盖最重的东西，因此称很轻的物品时精度会明显变差
  * **MXFP8**：把物品分成很多小组（通常每 32 个一组），每组发一个秤，量程根据这组物品的大小单独调（per-block scaling）。重的一组用大量程，轻的一组用小量程，因此每组内部都能称得更准
  * **NVFP4**：秤的刻度更粗了（4 bit），只靠一个秤已经不够，所以要用两层秤：先给每个小组一个局部秤调组内相对大小（per-block E4M3 scaling），再给整批物品一个总秤校正整体范围（per-tensor FP32 scaling）

  精度越低，越需要更细粒度的缩放机制来补偿。

  **参考资料**

  * [Understanding the FP64, FP32, FP16, BFLOAT16, TF32, FP8 Formats](https://jeffreytse.net/computer/2024/12/09/understanding-the-fp64-fp32-fp16-bfloat16-tf32-fp8-formats.html) — 各种精度格式的位布局和对比
  * [Floating-Point 8: An Introduction to Efficient, Lower-Precision AI Training](https://developer.nvidia.com/blog/floating-point-8-an-introduction-to-efficient-lower-precision-ai-training/) — NVIDIA 官方 FP8 技术博客，解释 E4M3/E5M2 变体和 scaling 策略
  * [Accelerating AI Training with NVIDIA TF32 Tensor Cores](https://developer.nvidia.com/blog/accelerating-ai-training-with-tf32-tensor-cores/) — NVIDIA 官方 TF32 技术博客
  * [Using NVFP4 Low-Precision Model Training](https://developer.nvidia.com/blog/using-nvfp4-low-precision-model-training-for-higher-throughput-without-losing-accuracy/) — NVIDIA 官方 FP4 训练技术博客
  * [From FP8 LLM Training to Inference: Language AI at Scale](https://www.nvidia.com/en-us/on-demand/session/gtc25-s72799/) — GTC 2025 演讲，FP8 在大语言模型训练和推理中的实践
</Accordion>

<Accordion title="Sparse 与 Dense 矩阵乘法">
  **上面表格中 Tensor Core 峰值算力均为启用 sparse 加速后的数值，dense 模式下性能减半。** A100 是第一款在 Tensor Core 中内置硬件级 **2:4 结构化稀疏**支持的 GPU：**它将权重矩阵按每 4 个连续元素分组，每组只保留 2 个非零值。哪些值被置零由剪枝或稀疏训练算法决定，常见做法是保留绝对值较大的两个**，再将绝对值较小的两个置零并通过微调恢复精度；Tensor Core 负责利用这种固定的稀疏模式跳过零值计算，从而实现约 2 倍的矩阵乘法吞吐量提升。

  **Dense GEMM** 是标准矩阵乘法 $C = A \times B$，A（M×K）和 B（K×N）的所有元素都参与乘累加运算。

  **Sparse GEMM** 利用 2:4 稀疏格式对 A 矩阵进行压缩：

  * **只存储非零元素（数据量减半，K → K/2）以及一组 2-bit 索引记录非零元素在原始 4 个位置中的偏移。**
  * Tensor Core 根据索引从 B 矩阵的 K 个元素中选出对应的 K/2 个元素，只对它们做乘累加。

  <Frame caption="NVIDIA GPU 上 2:4（稀疏）矩阵乘法的示意图">
    <img src="https://mintcdn.com/se7en/eaMJaPAQPjy6IQ-7/books/ai-systems-performance-engineering/images/ch01-sparse-vs-dense-matrix-multiplication.png?fit=max&auto=format&n=eaMJaPAQPjy6IQ-7&q=85&s=8b1ccf4bed42c4537accd0be475f55ed" alt="Illustration of 2:4 (sparse) matrix multiplication on NVIDIA GPUs" width="1886" height="1032" data-path="books/ai-systems-performance-engineering/images/ch01-sparse-vs-dense-matrix-multiplication.png" />
  </Frame>

  **参考资料**

  * [Structured Sparsity in the NVIDIA Ampere Architecture](https://developer.nvidia.com/blog/structured-sparsity-in-the-nvidia-ampere-architecture-and-applications-in-search-engines/) — NVIDIA 官方博客，介绍 2:4 稀疏的硬件支持与应用
  * [Accelerating Sparse Deep Neural Networks](https://arxiv.org/abs/2104.08378) — NVIDIA 论文，系统评估 2:4 稀疏在各类网络上的精度影响，并给出剪枝与重训练的最佳实践
  * [Accelerating Neural Network Training with Semi-Structured (2:4) Sparsity](https://pytorch.org/blog/accelerating-neural-network-training/) — PyTorch 博客，动态稀疏训练的实现与加速效果
  * [Exploiting Ampere Structured Sparsity with cuSPARSELt](https://developer.nvidia.com/blog/exploiting-ampere-structured-sparsity-with-cusparselt) — cuSPARSELt 库的使用
</Accordion>

<Accordion title="SXM、HGX、NVL 是什么">
  **SXM：物理封装形态**

  SXM 是 NVIDIA 的高带宽插座式 GPU 模块封装。它不走标准 `PCIe` 插槽，而是把 GPU 直接安装到 `HGX` / `DGX` 底板上。在这类系统里，SXM GPU 通常配合 `NVLink` 和 `NVSwitch` 使用，因此往往有更高的供电、更强的散热，以及更高的 GPU 间互连带宽。

  **HGX：服务器主板 / 平台**

  HGX 是 NVIDIA 的多 GPU 服务器参考平台。常见的 `HGX H100` / `HGX H200` 底板会集成 8 块 SXM GPU，并通过 `NVSwitch` 把它们全互连。Dell、HPE、浪潮等厂商通常在 HGX 底板之外再配上 CPU、内存和网卡，组装成完整的 AI 服务器。

  **NVL：NVLink 互连版本**

  NVL 代表 NVLink，**H100 NVL 是把两块 H100 通过 NVLink 桥接焊在同一张 PCIe 大卡上，对外表现为单张卡**。 这样做的好处是：不需要安装专用 HGX 主板就能拿到 NVLink 互连和更大的显存（两张合计 188 GB HBM3），适合快速部署在现有服务器基础设施上，尤其适合 LLM 推理场景。 NVL 版的核心性能接近 SXM，但 NVLink 带宽略低（600 GB/s vs SXM 的 900 GB/s）。
</Accordion>

#### 1.2 DeepSeek-V3 的 MoE 架构

DeepSeek‑V3 是一个约 671B 参数的混合专家（MoE）模型，但每个输入 token 只会激活约 37B 参数：每层包含 1 个共享专家和 256 个路由专家，每个 token 从中选出 8 个路由专家，再加上共享专家，一共使用 9 个活跃专家。这样一来，激活参数量约占总参数的 5.5%，在保持大模型容量的同时显著降低了单 token 的实际计算开销。

<Tip>
  MoE 架构的核心优势：总参数量决定模型容量（"模型能学到多少知识"），而活跃参数量决定推理成本（"每次推理需要多少计算"）。这种解耦让 MoE 在相同计算预算下能训练出更大、更强的模型。
</Tip>

#### 1.3 DeepSeek-R1：推理模型

在 DeepSeek-V3 基础上，团队进一步构建了专门的推理模型 **DeepSeek-R1**，路线接近 OpenAI 的 o1/o3 系列。与依赖大量人工反馈做后训练不同，R1 采用了 DeepSeek 开创的“冷启动”策略：只使用少量监督数据，把重点放在**强化学习**上，直接将思维链推理能力嵌入模型。这种做法同时压低了训练成本和训练时间，也说明软件和算法设计足够聪明时，可以在相当程度上弥补硬件瓶颈。

#### 1.4 DeepSeek 工程创新

DeepSeek 的工程团队几乎把整条系统栈都做了针对 H800 约束的重优化：从 attention kernel、FP8 矩阵乘法和 MoE 通信，到专家负载均衡、双向流水线并行，再到底层文件系统。

| 项目                                                      | 简介                                                                                                 |
| ------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| **[FlashMLA](https://github.com/deepseek-ai/FlashMLA)** | 用 CUDA/CUDA C++ 实现的高性能 MLA attention kernel 库，针对 Multi-Head Latent Attention 优化解码计算和 KV cache 访问路径 |
| **[DeepGEMM](https://github.com/deepseek-ai/deepgemm)** | 轻量级 FP8 优化矩阵乘法库，在多种矩阵形状和小 batch 场景下，性能可与基于 CUTLASS 等深度调优实现持平甚至更优                                   |
| **[DeepEP](https://github.com/deepseek-ai/DeepEP)**     | 为 MoE/专家并行定制的高性能通信库，重点优化专家的 dispatch/combine all-to-all 通信，缓解专家并行通信瓶颈                              |
| **[EPLB](https://github.com/deepseek-ai/EPLB)**         | 基于冗余专家策略的负载均衡组件，通过复制高负载专家并分布到多块 GPU，上下两级调度缓解 MoE 训练中的负载不均                                          |
| **[DualPipe](https://github.com/deepseek-ai/DualPipe)** | 双向流水线并行算法，通过同时重叠前向/反向计算与跨节点通信，显著减少 pipeline bubble、提高大模型训练吞吐                                       |
| **[3FS](https://github.com/deepseek-ai/3FS)**           | 高性能分布式文件系统，为训练数据读取、checkpoint 及大规模 KV cache 提供统一的高吞吐存储 I/O 基础设施                                    |

这些项目全部来自 DeepSeek 2025 年 2 月的 Open Source Week，汇总在 [open-infra-index](https://github.com/deepseek-ai/open-infra-index) 仓库中。下面逐个展开。

### 2. 迈向百万亿参数模型

模型规模正在从千亿向万亿参数迈进。以下是 [2026 年主流开源 LLM](https://www.bentoml.com/blog/navigating-the-world-of-open-source-large-language-models) 中的千亿至万亿级模型（均为 MoE 架构）：

| 模型                                                            | 公司          |  总参数 | 活跃参数 |
| ------------------------------------------------------------- | ----------- | ---: | ---: |
| [Kimi-K2.5](https://github.com/MoonshotAI/Kimi-K2)            | Moonshot AI |   1T |  32B |
| [GLM-5](https://github.com/zai-org/GLM-5)                     | 智谱          | 744B |  40B |
| [DeepSeek-V3.2](https://github.com/deepseek-ai/DeepSeek-V3)   | DeepSeek    | 671B |  37B |
| [Qwen3.5-397B](https://huggingface.co/Qwen/Qwen3.5-397B-A17B) | 阿里          | 397B |  17B |
| [MiMo-V2-Flash](https://github.com/XiaomiMiMo/MiMo)           | 小米          | 309B |  15B |
| [gpt-oss-120b](https://github.com/openai/gpt-oss)             | OpenAI      | 117B | 5.1B |

#### 2.1 计算挑战

一个 dense 的 100 万亿参数模型，在约 29 万亿 token 上训练，需要约 **1.2 × 10²⁹ FLOPS**。这是一个天文数字——即使是 exascale 系统也需要数千年的 GPU 时间来完成一次训练。

<Accordion title="什么是 Exascale 系统">
  Exascale 系统指算力达到 $10^{18}$ FLOPS（1 exaFLOPS）的超级计算机。目前已有多台投入运行：

  | 系统                                              | 机构             |           峰值算力 |   年份 |
  | ----------------------------------------------- | -------------- | -------------: | ---: |
  | [Frontier](https://www.olcf.ornl.gov/frontier/) | 美国橡树岭国家实验室     | \~1.1 exaFLOPS | 2022 |
  | [Aurora](https://www.alcf.anl.gov/aurora)       | 美国阿贡国家实验室      |   \~2 exaFLOPS | 2024 |
  | [El Capitan](https://www.llnl.gov/el-capitan)   | 美国劳伦斯利弗莫尔国家实验室 |   \~2 exaFLOPS | 2024 |
</Accordion>

#### 2.2 内存挑战

以 FP16（每参数 2 字节）存储 100 万亿参数，仅模型权重就需要约 **182 TB** 显存。单块 B200 GPU 有 192 GB HBM3e，仅加载模型就需要约 **1,000 块 B200**（约 125 个 8-GPU 节点）。若使用 B300（288 GB），则需约 **700 块**。这还只是模型权重——不包括激活值内存、优化器状态和输入数据，实际需求更大。

<Accordion title="B200 / B300 显存口径说明">
  前面规格表里的 B200 / B300 采用的是 `HGX B200` / `HGX B300` 的单 GPU 口径，因此显存写成 180 GB 和 270 GB；这里这句沿用原书引用的 `DGX B200` / `DGX B300` 口径，因此写成 192 GB 和 288 GB。两者对应的是不同系统形态下的规格，所以数字不完全一致。可参考 [Blackwell Ultra Datasheet](https://resources.nvidia.com/en-us-blackwell-architecture/blackwell-ultra-datasheet?ncid=pa-srch-goog-435826) 和 [NVIDIA DGX B300 Datasheet](https://resources.nvidia.com/en-us-dgx-systems/dgx-b300-datasheet?ncid=pa-srch-goog-435826)。
</Accordion>

#### 2.3 MoE 是关键路径

LLM 的基本架构是 Transformer，由一系列 Transformer 模块像搭积木一样堆叠而成。每个模块内部有两个核心组件：

* **Attention**：负责词与词之间的相互关联（"这句话里哪些词和当前词有关"）
* **FFN**（Feed-Forward Network）：负责对每个词本身的深度理解（"这个词在当前语境下是什么意思"）

Dense 模型（如早期 GPT 系列）对每个 token 使用全部 FFN 参数，计算成本随参数量线性增长。在 LLM 中，**FFN 的参数量占了模型的约八成**。如果能让 FFN 稀疏化 10 倍，同等计算量下模型总参数就能翻约 8 倍。

**MoE 的核心做法是把每层的 FFN 替换为 N 个并列的独立 FFN（每个叫一个"专家"），由路由器（gating network）为每个 token 选出少量专家执行，将它们的输出加权合并后传入下一层，其余专家不参与计算。** 每个 token 只需经过少量专家的计算，而模型整体因为拥有 N 个专家，总知识容量远超同等计算量的 dense 模型。

<Frame caption="4 个专家中只有 Expert 4 被激活（高亮），其余 3 个不参与当前 token 的计算">
  <img src="https://mintcdn.com/se7en/eaMJaPAQPjy6IQ-7/books/ai-systems-performance-engineering/images/ch01-moe.png?fit=max&auto=format&n=eaMJaPAQPjy6IQ-7&q=85&s=a11c8e5f46297e653d338f6d1b81355b" alt="MoE sparse model illustration showing only one expert activated out of four" width="880" height="656" data-path="books/ai-systems-performance-engineering/images/ch01-moe.png" />
</Frame>

LLM 由多层 Transformer 堆叠而成，每一层都有自己独立的一组专家和路由器。一个 token 从输入到输出会逐层经过所有层，每层的路由器独立为它选择不同的专家：

<Frame caption="每层的路由器独立选择专家：Layer 1 选中 Expert 1，Layer 2 选中 Expert 3，Layer n 选中 Expert 2n">
  <img src="https://mintcdn.com/se7en/eaMJaPAQPjy6IQ-7/books/ai-systems-performance-engineering/images/ch01-moe-layer.png?fit=max&auto=format&n=eaMJaPAQPjy6IQ-7&q=85&s=53ad67b492c1ce35e39ed1c3cf5aa5c0" alt="MoE layers showing different experts activated at each layer" width="1456" height="638" data-path="books/ai-systems-performance-engineering/images/ch01-moe-layer.png" />
</Frame>

##### 2.3.1 从 Switch Transformer 到 DeepSeek MoE

[Switch Transformer](https://jmlr.org/papers/v23/21-0998.html)（Google, 2021）是最早的大规模实践，采用 top-1 路由（每个 token 只选 1 个专家），训练速度达到同等 dense 模型的 7 倍。但它有一个缺陷：**每个专家都要各自学一遍通用能力**（语义理解、语法处理等），大量参数容量浪费在重复学习上。

[DeepSeek MoE](https://arxiv.org/abs/2401.06066) 的改进是两个：

1. **共享专家**：划出一部分专家，所有 token 都经过它们，专门学习通用能力。其余专家只需在通用能力的基础上各自深耕专业领域。
2. **细粒度专家**：把每个专家的粒度做细、数量做多（DeepSeek-V3 用 256 个 routed expert 选 8 个），让专业分工更精细。

<Frame caption="左：dense 架构，每层使用单个 FFN。右：DeepSeek V3/R1 的 MoE 架构，MoE 层包含 1 个 shared expert + 256 个 routed expert，每个 token 只激活 9 个专家（1 个 shared + 8 个 routed），总参数 671B，活跃参数仅 37B。">
  <img src="https://mintcdn.com/se7en/eaMJaPAQPjy6IQ-7/books/ai-systems-performance-engineering/images/ch01-deepseek-moe.png?fit=max&auto=format&n=eaMJaPAQPjy6IQ-7&q=85&s=d0fc53c04c3a9b88a2c74d9cf5075b3f" alt="Comparison of dense architecture vs DeepSeek V3/R1 MoE architecture" width="5333" height="3000" data-path="books/ai-systems-performance-engineering/images/ch01-deepseek-moe.png" />
</Frame>

##### 2.3.2 MoE 推理优化

**1. 算子效率：更快的 CUDA kernel**

通用的 NCCL collective 对 MoE 的 all-to-all 通信模式并非最优。DeepSeek 的 [DeepEP](https://github.com/deepseek-ai/DeepEP) 提供了专门为 MoE 优化的高效 all-to-all 通信 kernel。Perplexity 开源的 [pplx-kernels](https://github.com/ppl-ai/pplx-kernels) 同样针对 MoE expert parallelism 场景，支持 NVLink、IBGDA、IBRC 等多种传输层，并在 kernel 层面提供通信与计算重叠的底层能力。

<Accordion title="IBGDA 与 IBRC">
  都是 InfiniBand 网络上 GPU 间的通信方式：

  * **IBGDA**（InfiniBand GPU-Direct Async）：GPU 直接向网卡发起 RDMA 操作，完全绕过 CPU，延迟最低
  * **IBRC**（InfiniBand Reliable Connection）：传统模式，需要 CPU 代理线程协调 GPU 和网卡之间的通信，延迟较高
</Accordion>

**2. 通信与计算并行（Dual Batch Overlap）**

**GPU 内部的计算单元（SM，Streaming Multiprocessor）和网络硬件（NIC 网卡、NVLink/InfiniBand 链路）是独立的**——SM 在执行 CUDA kernel 做矩阵乘法时，NIC 可以同时通过 DMA/RDMA 在 GPU 之间搬运数据，互不占用对方资源。

例如 [vLLM 的 Dual Batch Overlap（DBO）](https://docs.vllm.ai/en/latest/design/dbo/) 利用这一点，**将 batch 拆成两组 micro-batch 交替执行：一组的 token 在 SM 上做前向计算时，另一组的 token 正通过 NIC 做 MoE all-to-all 通信，让计算单元和网络通道同时满载。**

下面是一段 DeepSeek decode workload 的 profiling trace。未启用 DBO 时，MoE Dispatch/Combine 部分占据了大量时间，尽管实际计算负载很小。

<Frame caption="未启用 DBO：MoE Dispatch/Combine 的 collective communication 耗时远超实际计算。">
  <img src="https://mintcdn.com/se7en/eaMJaPAQPjy6IQ-7/books/ai-systems-performance-engineering/images/ch01-dbo-before.png?fit=max&auto=format&n=eaMJaPAQPjy6IQ-7&q=85&s=0cbb52aad0c6f5a8c97f536822dd1869" alt="GPU profiling trace before DBO showing sequential execution with idle GPU during MoE communication" width="1120" height="547" data-path="books/ai-systems-performance-engineering/images/ch01-dbo-before.png" />
</Frame>

启用 DBO 后，两个 micro-batch 线程交替执行：

* 线程 0 完成 dispatch（send + recv）后立刻让出给线程 1
* **线程 1 开始自己的 dispatch 通信，同时线程 0 收到的 token 在 SM 上做专家计算**
* 线程 1 完成 dispatch 后让回给线程 0 做 combine
* 线程 0 完成 combine 后让出给线程 1 做 combine，如此交替

在通信开销较高的场景（如 Wide EP 部署）中，这种交替执行显著提升了 GPU 利用率。

<Frame caption="启用 DBO：两个 micro-batch 线程交替执行 dispatch 和 combine，通信与计算重叠，GPU 利用率显著提升。">
  <img src="https://mintcdn.com/se7en/eaMJaPAQPjy6IQ-7/books/ai-systems-performance-engineering/images/ch01-dbo-after.png?fit=max&auto=format&n=eaMJaPAQPjy6IQ-7&q=85&s=3ce7c72cb69e96b0bd72f525988357ae" alt="GPU profiling trace after DBO showing interleaved execution of two microbatches with overlapped communication and computation" width="1150" height="349" data-path="books/ai-systems-performance-engineering/images/ch01-dbo-after.png" />
</Frame>

<Accordion title="MoE 在 Expert Parallelism 下的通信流程">
  当专家分布在多块 GPU 上时，每一层的 MoE 计算都需要经过 dispatch → 专家计算 → combine 三个阶段。其中 dispatch 和 combine 属于通信操作（通过 NIC/NVLink 在 GPU 间搬运数据），共四步：

  | 步骤                | 作用                            |
  | ----------------- | ----------------------------- |
  | **dispatch send** | 根据路由结果，把 token 发送到持有对应专家的 GPU |
  | **dispatch recv** | 接收其他 GPU 发来的 token            |
  | （专家计算）            | 本地 GPU 上的专家对收到的 token 做前向计算   |
  | **combine send**  | 把专家计算结果发回给 token 的来源 GPU      |
  | **combine recv**  | 接收专家计算结果，加权求和得到最终输出           |

  下图展示了两个 DP group 和 4 个专家之间的完整 dispatch → 专家计算 → combine 流程：

  <Frame caption="MoE Dispatch/Combine 流程：左侧 token 根据路由分发到各专家，中间专家独立计算，右侧结果发回来源并加权求和（⊕）">
    <img src="https://mintcdn.com/se7en/eaMJaPAQPjy6IQ-7/books/ai-systems-performance-engineering/images/ch01-moe-dispatch-combine.png?fit=max&auto=format&n=eaMJaPAQPjy6IQ-7&q=85&s=d3b0c91b8217360d770455bb451ebc2a" alt="MoE dispatch and combine flow across two DP groups and four experts" width="3840" height="2160" data-path="books/ai-systems-performance-engineering/images/ch01-moe-dispatch-combine.png" />
  </Frame>

  * **左侧 DISPATCH**：DP #0 有 3 个 token（0, 1, 2），DP #1 有 2 个 token（0, 1）。根据路由结果，token 被分发到 4 个专家（E #0 \~ E #3），一个 token 可能被发给多个专家
  * **中间 专家计算**：每个专家收到各自的 token 后独立做前向计算
  * **右侧 COMBINE**：专家计算结果沿箭头发回各自的来源 DP rank，⊕ 表示加权求和——同一个 token 被多个专家处理后，按路由权重合并为最终结果

  如果所有专家在同一块 GPU 上，就不需要这些通信。但大模型的专家太多（如 DeepSeek-V3 的 256 个），必须分散到多块 GPU，这四步通信不可避免。DBO 的作用就是通过交替执行两组 micro-batch 来隐藏这些通信延迟。
</Accordion>

**3. Wide-EP**

Expert Parallelism（EP）将 MoE 模型中的专家分配到多块 GPU 上，利用各设备的综合计算能力和内存带宽。小规模 EP 在每块 GPU 上部署多个专家，但 decode 阶段每个 token 只激活少量专家，**大部分专家每次只服务很少的 token，读一次权重却只做很少计算，算术强度低。**

[Wide EP](https://developer.nvidia.com/blog/scaling-large-moe-models-with-wide-expert-parallelism-on-nvl72-rack-scale-systems/) 将 EP 与 DP（Data Parallelism）结合，把专家分布到数十甚至上百块 GPU 上，每块 GPU 只持有少量专家。**来自多个 DP group 的 token 都路由到这些专家，每个专家服务更多 token，读一次权重服务更多计算，算术强度提升。**

<Frame caption="左：小规模 EP，每块 GPU 部署多个专家。右：Wide EP，专家分散到更多 GPU 上，每块 GPU 只持有少量专家">
  <img src="https://mintcdn.com/se7en/eaMJaPAQPjy6IQ-7/books/ai-systems-performance-engineering/images/ch01-wide-ep.gif?s=d077b7ce9d9a79242c427bb15591bced" alt="Comparison of small scale EP with multiple experts per GPU vs large scale Wide EP with fewer experts distributed across more GPUs" width="1280" height="720" data-path="books/ai-systems-performance-engineering/images/ch01-wide-ep.gif" />
</Frame>

实测数据：[NVIDIA 在 GB200 NVL72 上的基准测试](https://developer.nvidia.com/blog/scaling-large-moe-models-with-wide-expert-parallelism-on-nvl72-rack-scale-systems/)显示，EP32 比 EP8 的每 GPU 吞吐量提升 **1.8 倍**。

**4. EPLB（Expert Parallel Load Balancing）**

Wide EP 下，某些 EP rank 可能空闲，而其他 rank 在处理大量 token。为此，vLLM 集成了 DeepSeek 的 [EPLB](https://github.com/deepseek-ai/EPLB) 的分层和全局负载均衡策略。

工作方式：每次 MoE 前向传播记录每个 token 的负载分布，通过滑动窗口在各 EP rank 之间聚合统计数据。当达到重新均衡间隔时，负载均衡器计算新的逻辑-物理专家映射，并执行权重迁移（weight shuffle），使新的分配方案生效，无需重启模型。**对于被频繁选中的热门专家（hot expert），EPLB 会将其 clone 到多个 rank 上，让多块 GPU 共同分担该专家的负载。**

<Frame caption="EPLB：4 个 rank 各持有 2 个专家，MoE 层通过 All2All 通信协作。当某个专家成为热门专家时，EPLB 将其 clone 到多个 rank 上分担负载，避免单个 GPU 过载">
  <img src="https://mintcdn.com/se7en/eaMJaPAQPjy6IQ-7/books/ai-systems-performance-engineering/images/ch01-eplb.gif?s=663ef032b94d04c09d72c15d14d56ca6" alt="Expert Parallel Load Balancing animation showing expert distribution across 4 ranks with All2All communication" width="1080" height="608" data-path="books/ai-systems-performance-engineering/images/ch01-eplb.gif" />
</Frame>

#### 2.4 开源 MoE 模型一览

| 模型                                                                 | 公司          |   总参数 |  活跃参数 | Routed Expert | Shared Expert | 每 token 激活 Routed Expert |   年份 |
| ------------------------------------------------------------------ | ----------- | ----: | ----: | ------------: | ------------: | -----------------------: | ---: |
| [Mixtral 8x7B](https://huggingface.co/mistralai/Mixtral-8x7B-v0.1) | Mistral     | 46.7B | 12.9B |             8 |             0 |                        2 | 2023 |
| [DeepSeek-V3.2](https://huggingface.co/deepseek-ai/DeepSeek-V3.2)  | DeepSeek    |  671B |   37B |           256 |             1 |                        8 | 2025 |
| [gpt-oss-120b](https://huggingface.co/openai/gpt-oss-120b)         | OpenAI      |  117B |  5.1B |           128 |             0 |                        4 | 2025 |
| [MiMo-V2-Flash](https://huggingface.co/XiaomiMiMo/MiMo-V2-Flash)   | 小米          |  309B |   15B |           256 |             0 |                        8 | 2026 |
| [Kimi-K2.5](https://huggingface.co/moonshotai/Kimi-K2.5)           | Moonshot AI |    1T |   32B |           384 |             1 |                        8 | 2026 |
| [GLM-5](https://huggingface.co/zai-org/GLM-5)                      | 智谱          |  744B |   40B |           256 |             1 |                        8 | 2026 |
| [Qwen3.5-397B](https://huggingface.co/Qwen/Qwen3.5-397B-A17B)      | 阿里          |  397B |   17B |           512 |             1 |                       10 | 2026 |

**参考资料**

* [A Visual Guide to Mixture of Experts](https://newsletter.maartengrootendorst.com/p/a-visual-guide-to-mixture-of-experts) — 50+ 可视化图解 MoE 的工作原理
* [Mixture of Experts Explained](https://huggingface.co/blog/moe) — Hugging Face 博客，MoE 的训练技巧和推理优化
* [Mixture of Experts (MoEs) in Transformers](https://huggingface.co/blog/moe-transformers) — Hugging Face 2026 年更新版，MoE 在 transformers 库中的工程实践
* [Scaling Large MoE Models with Wide EP on NVL72](https://developer.nvidia.cn/blog/scaling-large-moe-models-with-wide-expert-parallelism-on-nvl72-rack-scale-systems/) — NVIDIA 技术博客，Wide EP + EPLB + GroupGEMM
* [vLLM Large Scale Serving: DeepSeek @ 2.2k tok/s/H200](https://vllm.ai/blog/large-scale-serving) — vLLM 博客，Wide EP + DBO + EPLB 的完整实践
* [Dual Batch Overlap 设计文档](https://docs.vllm.ai/en/latest/design/dbo/) — vLLM DBO 的实现细节
* [Efficient and Portable MoE Communication](https://www.perplexity.ai/hub/blog/efficient-and-portable-mixture-of-experts-communication) — Perplexity 博客，pplx-kernels 的设计与基准测试
* [7 分钟速通开源 MoE](https://www.youtube.com/watch?v=3d9qaeBrouA) — 中文视频，从省算力到负载均衡到推理优化的完整概览

### 3. 机架式 AI 超级计算机

NVIDIA 正在将 AI 基础设施从单块 GPU、单台服务器演进为**机架级系统**和 **POD 级超级计算机**。

#### 3.1 GB200 NVL72 (2024)

[GB200 NVL72](https://developer.nvidia.com/blog/nvidia-gb200-nvl72-delivers-trillion-parameter-llm-training-and-real-time-inference/) 是基于 Blackwell 架构的机架级 AI 超级计算系统，在单机架内提供 exaFLOP 级算力。它将 **36 颗 Grace CPU** 和 **72 块 Blackwell GPU** 整合在一个液冷机柜中，72 GPU 组成一个 NVLink 域，如同一块巨型 GPU。其核心构建单元是 GB200 Grace Blackwell Superchip——通过 NVLink-C2C 将两块 Blackwell Tensor Core GPU 与一颗 Grace CPU 互连。

<Frame caption="GB200 NVL72 机柜。左：正面（18 个计算托盘 + 9 个 NVLink switch 托盘）和背面。右：背面特写，NVLink 铜缆脊柱连接所有 72 块 GPU">
  <img src="https://mintcdn.com/se7en/eaMJaPAQPjy6IQ-7/books/ai-systems-performance-engineering/images/ch01-gb200-nvl72.png?fit=max&auto=format&n=eaMJaPAQPjy6IQ-7&q=85&s=d3c68e71955f958000c92e87a2f9f8c6" alt="NVIDIA GB200 NVL72 rack front and back view showing compute trays and NVLink cable spine" width="1920" height="1080" data-path="books/ai-systems-performance-engineering/images/ch01-gb200-nvl72.png" />
</Frame>

72 个通过 NVLink 连接的 Blackwell GPU 与 30 TB 统一内存集成在 130 TB/s 的计算架构中，在单个机架内构成一台 exaFLOP 级 AI 超级计算机。

<Accordion title="统一内存">
  GB200 NVL72 的 30.5 TB 快速访问内存由两部分组成：

  * **HBM3e（GPU 显存）**：72 块 GPU × 192 GB = 13.5 TB，直接供 GPU 计算使用
  * **LPDDR5X（CPU 内存）**：36 颗 Grace CPU 提供最高 17 TB

  两者通过 NVLink-C2C 构成统一内存空间（unified memory），GPU 可以访问 CPU 内存，CPU 也可以访问 GPU 显存。不过远端访问的延迟和带宽与本地不同，并非完全均匀——使用时建议通过 `cudaMemPrefetchAsync` 显式预取数据到本地，避免运行时因数据不在本地而触发缺页异常（page fault），导致 GPU 阻塞等待远端数据搬运。
</Accordion>

相比上一代 H100，GB200 NVL72 在推理、训练、能效和数据处理上都有代际提升：

| 场景     |        vs H100 | 说明                                                                                                     |
| ------ | -------------: | ------------------------------------------------------------------------------------------------------ |
| LLM 推理 |        **30×** | 第二代 Transformer Engine 支持 FP4，新一代 Tensor Core 引入 microscaling 格式，配合第五代 NVLink 将万亿参数语言模型的推理性能提升 30 倍    |
| LLM 训练 |         **4×** | 第二代 Transformer Engine 支持 FP8，配合第五代 NVLink（1.8 TB/s GPU 间互连）、InfiniBand 和 Magnum IO 实现大规模 LLM 训练 4 倍加速 |
| 能效     |        **25×** | 液冷提升计算密度、减少占地面积，并支持大规模 NVLink 域的高带宽低延迟 GPU 通信。同等功耗下性能 25 倍，同时减少水资源消耗                                   |
| 数据处理   | **18×** vs CPU | 利用高带宽内存、NVLink-C2C 和 Blackwell 专用解压引擎加速数据库查询                                                           |

<Tip>
  测试条件：TPOT 50 ms，TTFT 5,000 ms，输入 32,768 tokens，输出 1,024 tokens。对比方案：9 台 8 卡 HGX H100（风冷，400 Gb IB）vs 18 块 GB200 Superchip（液冷，NVL72），per GPU 性能对比。
</Tip>

#### 3.2 GB300 NVL72 (2025)

[GB300 NVL72](https://developer.nvidia.com/blog/inside-nvidia-blackwell-ultra-the-chip-powering-the-ai-factory-era/)（Blackwell Ultra）在同一机柜架构上升级：**显存从 192 GB 增至 288 GB HBM3e**，FP4 Tensor Core 密度提升 1.5 倍，Attention 性能提升 2 倍。

| 指标                    |     GB200（Blackwell） |  GB300（Blackwell Ultra） |
| --------------------- | -------------------: | ----------------------: |
| 制程                    |             TSMC 4NP |                TSMC 4NP |
| 晶体管                   |                 208B |                    208B |
| NVFP4 dense / sparse  |       10 / 20 PFLOPS |          15 / 20 PFLOPS |
| FP8 dense / sparse    |        5 / 10 PFLOPS |           5 / 10 PFLOPS |
| Attention 加速（SFU EX2） | 5 TeraExponentials/s | 10.7 TeraExponentials/s |
| HBM 容量                |         192 GB HBM3e |            288 GB HBM3e |
| HBM 带宽                |               8 TB/s |                  8 TB/s |
| NVLink 带宽             |             1.8 TB/s |                1.8 TB/s |
| 最大功耗（TGP）             |               1,200W |                  1,400W |

#### 3.3 Vera Rubin NVL72 (2026)

[Vera Rubin NVL72](https://www.nvidia.com/en-us/data-center/vera-rubin-nvl72/) 整合了 72 块 Rubin GPU、36 颗 Vera CPU、[ConnectX-9 SuperNIC](https://www.nvidia.com/en-us/networking/ethernet-adapters/) 和 [BlueField-4 DPU](https://www.nvidia.com/en-us/networking/products/data-processing-unit/)。通过 NVLink 6 实现机架内 scale-up，通过 [Quantum-X800 InfiniBand](https://www.nvidia.com/en-us/networking/products/infiniband/quantum-x800/) 或 [Spectrum-X Ethernet](https://www.nvidia.com/en-us/networking/spectrumx/) 实现跨机架 scale-out。

Vera Rubin NVL72 基于第三代 MGX 机架设计，可从上一代 Blackwell 平滑过渡。相比 Blackwell，训练仅需 **1/4 的 GPU 数量**，推理每百万 token 成本降至 **1/10**。

<Accordion title="MGX 机架架构">
  MGX（Modular GPU Accelerated）是 NVIDIA 的开放标准化机架架构，定义了机柜的机械尺寸、电源、冷却和线缆的统一规范。2024 年 NVIDIA 将 [GB200 NVL72 的设计贡献给了 Open Compute Project（OCP）](https://developer.nvidia.com/blog/nvidia-contributes-nvidia-gb200-nvl72-designs-to-open-compute-project/)。

  所有 NVL72 机柜（GB200、GB300、Vera Rubin）都基于 MGX 架构，共用相同的电源、冷却和机械规格，由 80+ 全球合作伙伴的供应链支撑。这意味着数据中心可以在不重新设计基础设施的前提下跨代升级——从 Blackwell 到 Vera Rubin 只需更换计算托盘，机柜外壳、冷却管路和电源母线保持不变。
</Accordion>

#### 3.4 [Vera Rubin POD](https://developer.nvidia.com/blog/nvidia-vera-rubin-pod-seven-chips-five-rack-scale-systems-one-ai-supercomputer/) (2026)

现代 Agentic AI 系统需要规划任务、调用工具、执行代码、检索数据，并在多个 AI Agent 之间协调连续的多步工作流。这些交互会产生大量推理 token、扩展 KV cache，并需要基于 CPU 的沙箱环境来测试和验证加速计算系统生成的结果，对 GPU、CPU、scale-up 域、scale-out 网络和存储都提出了低延迟、高吞吐的要求。

Vera Rubin POD 通过横跨计算、网络和存储的 7 种芯片极致协同设计，构建了最先进的 POD 级 AI 平台：**40 个机柜、1.2 × 10¹⁵ 个晶体管、近 20,000 块 NVIDIA 芯片、1,152 块 Rubin GPU、60 exaFLOPS、10 PB/s 总 scale-up 带宽**。

<Frame caption="Vera Rubin POD：40 个机柜组成一台 AI 超级计算机，包含 5 种专用机柜（NVL72、LPX、Vera CPU、BlueField-4 STX、Spectrum-6 SPX）">
  <img src="https://mintcdn.com/se7en/eaMJaPAQPjy6IQ-7/books/ai-systems-performance-engineering/images/ch01-vera-rubin-pod.png?fit=max&auto=format&n=eaMJaPAQPjy6IQ-7&q=85&s=16a5b678fed86bdd04e45a3bffda906c" alt="NVIDIA Vera Rubin POD consisting of 40 racks forming one AI supercomputer" width="1920" height="1080" data-path="books/ai-systems-performance-engineering/images/ch01-vera-rubin-pod.png" />
</Frame>

Vera Rubin POD 引入了 5 种全新的专用机架级系统，面向需要高吞吐、极低延迟推理、密集 CPU 沙箱和大规模上下文内存存储的 Agentic AI 工作负载。

<Frame caption="NVIDIA Vera Rubin POD：5 种机架级系统、1 台 AI 超级计算机、1 套 MGX 机架架构和生态系统">
  <img src="https://mintcdn.com/se7en/eaMJaPAQPjy6IQ-7/books/ai-systems-performance-engineering/images/ch01-vera-rubin-pod-5-racks.png?fit=max&auto=format&n=eaMJaPAQPjy6IQ-7&q=85&s=2996d271dcc18667bd6cc927bd8ca612" alt="Five rack types in Vera Rubin POD: NVL72, Groq 3 LPX, Vera CPU, BlueField-4 STX, Spectrum-6 SPX" width="953" height="510" data-path="books/ai-systems-performance-engineering/images/ch01-vera-rubin-pod-5-racks.png" />
</Frame>

**NVIDIA Vera Rubin NVL72：核心计算引擎**

Vera Rubin NVL72 是最新 [AI 工厂](https://www.nvidia.com/en-us/solutions/ai-factories/)的核心机架级计算引擎。72 块 Rubin GPU 和 36 颗 Vera CPU 通过大规模 NVLink 铜缆脊柱互连，如同一块巨型 GPU。它针对 AI 的四种 scaling law 设计：预训练、后训练、test-time scaling 和 agentic scaling，可针对复杂的 MoE 路由以及 AI 推理中计算密集型的上下文阶段进行优化。相比 Blackwell，训练性能提升 4 倍，推理性能/瓦提升 10 倍，每百万 token 成本降至 1/10。

**NVIDIA Groq 3 LPX：低延迟推理加速**

NVIDIA Groq 3 LPX 与 NVIDIA Vera Rubin 平台协同设计，旨在满足智能体 AI 对海量上下文和低延迟的需求，每个机架配备 256 个语言处理单元（LPU）。它与 Vera Rubin NVL72 搭配使用，消除了高速交互性与吞吐量之间的权衡。通过将高带宽、仅采用 SRAM 的 LPU 与拥有大容量 HBM 的 Rubin GPU 融合，系统在长上下文长度下实现了低延迟和高吞吐，在不牺牲系统吞吐量的前提下，大幅增强了万亿参数模型的用户交互体验。相较于 Blackwell，Vera Rubin NVL72 加 LPX 可为万亿参数模型带来高达 35 倍的 token 产出和高达 10 倍的收入机会。欲了解更多信息，请参见 [Inside NVIDIA Groq 3 LPX](https://developer.nvidia.com/blog/inside-nvidia-groq-3-lpx-the-low-latency-inference-accelerator-for-the-nvidia-vera-rubin-platform)。

**NVIDIA Vera CPU Rack：大规模智能体 AI 与强化学习**

NVIDIA Vera CPU Rack 在高密度液冷机架中集成了最多 256 颗 NVIDIA Vera CPU，提供可扩展且高能效的容量。单个机架可支持超过 22,500 个并发强化学习（RL）或智能体沙箱环境，从而最大化可用于测试、执行和验证 Vera Rubin NVL72 与 LPX 机架输出结果的环境数量。Vera CPU Rack 为大规模智能体 AI 与强化学习提供基础，相比传统机架级 CPU，效率提升 2 倍，速度提升 50%。欲进一步了解 Vera CPU 如何为 AI 工厂提供高性能带宽和高效率，详见 [NVIDIA Vera CPU Delivers High Performance, Bandwidth, and Efficiency for AI Factories](https://developer.nvidia.com/blog/nvidia-vera-cpu-delivers-high-performance-bandwidth-and-efficiency-for-ai-factories)。

**NVIDIA BlueField-4 STX：AI 原生存储**

[NVIDIA BlueField-4 STX](https://www.nvidia.com/en-us/data-center/ai-storage/stx/) 机架基于 NVIDIA BlueField-4 处理器构建，该处理器结合了 Vera CPU 与 ConnectX-9 SuperNIC，并通过 Spectrum-X Ethernet 网络实现横向扩展。

它承载 [NVIDIA CMX 上下文内存存储平台](https://www.nvidia.com/en-us/data-center/ai-storage/cmx/)。这是一类全新的 AI 原生存储基础设施，可在整个 POD 内无缝扩展 GPU 上下文容量，并通过将 KV cache 卸载到专用高带宽存储层来加速推理。CMX 针对海量上下文内存（KV cache）的存储与服务进行了优化，将临时推理上下文视为一种 AI 原生的共享数据类型，可在回合、会话和 Agent 之间重复使用。与传统存储方案相比，这可带来高达 5 倍的每秒 token 产出和高达 5 倍的能效提升。

**NVIDIA Spectrum-6 SPX：网络机架**

[NVIDIA Spectrum-6 SPX](https://www.nvidia.com/en-us/networking/spectrumx/) 网络机架将整个 POD 连接成一台超级计算机。Spectrum-6 SPX 网络机架专为加速 AI 工厂内的东西向与南北向流量而设计。它可配置为 [Spectrum-X Ethernet](https://www.nvidia.com/en-us/networking/spectrumx/) 或 [NVIDIA Quantum-X800 InfiniBand](https://www.nvidia.com/en-us/networking/products/infiniband/quantum-x800/) 交换机，在大规模部署下提供低延迟、高吞吐的机架间连接。

Spectrum-6 SPX 机架现集成了 102.4 Tb/s 的 Spectrum-6 交换机，该交换机提供 512 通道，并在单芯片和多芯片交换机形态中采用 200 Gb/s 的共封装光学（CPO）方案。这种硅光集成取代了可插拔光模块，在保证 AI 工作负载在计算与存储环境之间保持高度同步的同时，提供了最高的能效与可靠性、极低的时延和抖动，以及几乎完美的有效带宽。

<Accordion title="Spectrum‑X Ethernet 与 Quantum‑X800 InfiniBand 对比">
  [Spectrum‑X Ethernet](https://www.nvidia.com/en-us/networking/spectrumx/) 面向 AI 云和企业数据中心，是“为 AI 优化的以太网”。它在保留以太网开放生态（TCP/IP、RoCEv2 等）的前提下，针对大模型训练和推理做了拥塞控制、流量调度和端到端优化，优势是兼容现有基础设施、部署灵活，也更适合多租户场景。

  [NVIDIA Quantum‑X800 InfiniBand](https://www.nvidia.com/en-us/networking/products/infiniband/quantum-x800/) 面向极致性能需求的 800G InfiniBand 平台，主要服务于万亿参数级模型训练、HPC 和超大规模 AI 工厂。它强调超低时延、网络内计算（In-Network Computing）和强集体通信能力，更适合追求训练规模与性能上限的场景。
</Accordion>

#### 3.5 Vera Rubin Ultra (2027)

Vera Rubin Ultra 引入了一种全新的两层全互连 NVLink 拓扑，使开发者能够将 scale-up 扩展到 576 块 GPU。Vera Rubin Ultra NVL576 将由 8 个独立的 MGX NVL 机柜组成，每个机柜配备 72 块 Rubin Ultra GPU，并通过铜缆和直连光互连构成一个统一的 576-GPU NVLink 域。它将基于同一套 MGX 机架级生态系统构建，以实现最快的产品落地速度。

作为这一大规模多机柜 NVLink 拓扑的演示系统，Polyphe 是 NVIDIA 内部一个基于 GB200 的全功能原型，用于验证多机柜 NVL576 scale-up 架构。

<Frame caption="NVIDIA Polyphe 原型：一个基于 GB200 的全功能多机柜 NVL576 scale-up 系统">
  <img src="https://mintcdn.com/se7en/eaMJaPAQPjy6IQ-7/books/ai-systems-performance-engineering/images/ch01-vera-rubin-ultra.png?fit=max&auto=format&n=eaMJaPAQPjy6IQ-7&q=85&s=bed048cc729f9aab5142a668bc4b28c9" alt="NVIDIA Polyphe 原型，多机柜 NVL576 scale-up 系统" width="1296" height="629" data-path="books/ai-systems-performance-engineering/images/ch01-vera-rubin-ultra.png" />
</Frame>

#### 3.6 Feynman (2028)

为了扩展到 NVL576 之上，NVIDIA 将引入一款新的 MGX 机柜：NVIDIA Kyber。NVIDIA Kyber 是下一代 MGX NVL 机柜设计，**可将每个机柜内的 NVLink 域规模翻倍，容纳 144 块 GPU**。

<Frame caption="NVIDIA Kyber NVL1152">
  <img src="https://mintcdn.com/se7en/eaMJaPAQPjy6IQ-7/books/ai-systems-performance-engineering/images/ch01-feynman.png?fit=max&auto=format&n=eaMJaPAQPjy6IQ-7&q=85&s=c57fb4d6e1e9fff8c8ec85d93f48b7a5" alt="NVIDIA Kyber NVL1152 机架架构示意图" width="987" height="491" data-path="books/ai-systems-performance-engineering/images/ch01-feynman.png" />
</Frame>

NVIDIA Kyber 将使用类似的机柜间直连光互连，**扩展为大规模全互连的 NVL1152 超级计算机**。Kyber 为基于 NVIDIA Feynman 的下一代极致 scale-up AI 计算奠定基础。

Kyber 将首先随 Vera Rubin Ultra 以独立 NVL144 系统的形式推出，为客户提供 Vera Rubin Ultra NVLink scale-up 域的三种选择：NVL72、NVL144 和旗舰 NVL576。

**参考资料**

* [NVIDIA Vera Rubin POD: Seven Chips, Five Rack-Scale Systems, One AI Supercomputer](https://developer.nvidia.com/blog/nvidia-vera-rubin-pod-seven-chips-five-rack-scale-systems-one-ai-supercomputer)
* [Inside the NVIDIA Vera Rubin Platform: Six New Chips, One AI Supercomputer](https://developer.nvidia.com/blog/inside-the-nvidia-rubin-platform-six-new-chips-one-ai-supercomputer)
* [Inside NVIDIA Groq 3 LPX: The Low-Latency Inference Accelerator for the NVIDIA Vera Rubin Platform](https://developer.nvidia.com/blog/inside-nvidia-groq-3-lpx-the-low-latency-inference-accelerator-for-the-nvidia-vera-rubin-platform)
* [NVIDIA Unveils Rubin CPX: A New Class of GPU Designed for Massive-Context Inference](https://nvidianews.nvidia.com/news/nvidia-unveils-rubin-cpx-a-new-class-of-gpu-designed-for-massive-context-inference)
* [NVIDIA Rubin CPX Accelerates Inference Performance and Efficiency for 1M+ Token Context Workloads](https://developer.nvidia.com/blog/nvidia-rubin-cpx-accelerates-inference-performance-and-efficiency-for-1m-token-context-workloads)
* [英伟达将 Rubin CPX 从路线图移除，或以 Groq LPU 及 LPX 机架取代](https://www.expreview.com/104782.html)
* [Inside NVIDIA Blackwell Ultra: The Chip Powering the AI Factory Era](https://developer.nvidia.com/blog/inside-nvidia-blackwell-ultra-the-chip-powering-the-ai-factory-era/)

### 4. 协同设计（Co-design）

在计算领域，协同设计指的是编写对底层硬件特性有深刻认知的软件。在 AI 背景下，它更具体地意味着让算法、软件与硬件能力协同设计，以最大化性能；FlashAttention、MLA 和低精度量化正是三个典型例子。

#### 4.1 FlashAttention

真实系统里的经验反复说明，哪怕只是 GPU kernel 或内存访问模式上的小改动，也可能带来远超直觉的收益。FlashAttention 就是一个经典例子：它没有改变 Transformer 注意力的数学定义，而是以一种更贴近硬件的方式重写 attention 计算。它的核心做法是把 GPU 上的计算切成 tile，尽量减少对显存的读写次数，从而显著降低数据搬运开销并加快 attention 计算。

**[FlashAttention-1](https://arxiv.org/abs/2205.14135)（2022）** 首次把 attention 明确地当成一个 **I/O 问题**来处理。

要理解 FlashAttention 在优化什么，先看 GPU 内部的数据流动方式。

<Frame caption="GPU 内存层级与数据流：输入从 HBM 出发，搬入 SM 的 SRAM 进行计算，结果写回 HBM（A100 数据）">
  <img src="https://mintcdn.com/se7en/eaMJaPAQPjy6IQ-7/books/ai-systems-performance-engineering/images/ch01-hbm-sram.png?fit=max&auto=format&n=eaMJaPAQPjy6IQ-7&q=85&s=14605fd3cab597d92fab974bbda03375" width="1656" height="514" data-path="books/ai-systems-performance-engineering/images/ch01-hbm-sram.png" />
</Frame>

GPU 有两级存储：**HBM**（High Bandwidth Memory）容量大（A100 为 40 GB）但带宽相对有限（1.5 TB/s）；**SRAM**（片上共享内存）容量很小（A100 约 20 MB）但带宽极高（19 TB/s）。每个 CUDA kernel 的执行流程都是：从 HBM 读入数据 → 搬到 SRAM 计算 → 把结果写回 HBM。计算本身很快，瓶颈往往在 HBM 的读写上。

**标准 attention 的 I/O 瓶颈**

<Frame caption="Kernel fusion 前后对比：上方是标准实现，每步 kernel 之间 GPU 都在等 HBM 读写；下方融合后，计算连续执行，省掉了中间的 I/O 等待和 N×N 中间矩阵的 HBM 存储">
  <img src="https://mintcdn.com/se7en/eaMJaPAQPjy6IQ-7/books/ai-systems-performance-engineering/images/ch01-flashattention-kernel-fusion.png?fit=max&auto=format&n=eaMJaPAQPjy6IQ-7&q=85&s=83a5056a4f5b696f14dd7095af3f385d" width="1946" height="734" data-path="books/ai-systems-performance-engineering/images/ch01-flashattention-kernel-fusion.png" />
</Frame>

这张图上半部分展示的是标准 attention 的核心计算流程 $O = softmax(QK^T)V$。按图中的执行顺序，可以把标准 attention 理解成下面几步：

* **第 1 步**：从 HBM 读入 Q 和 K。
* **第 2 步**：在 SRAM 中做一次矩阵乘法，计算 $S = Q \cdot K^T$。
* **第 3 步**：把中间矩阵 $S$ 写回 HBM。
* **第 4 步**：再把 $S$ 从 HBM 读回。
* **第 5 步**：在 SRAM 中计算 $P = Softmax(S)$。
* **第 6 步**：把中间矩阵 $P$ 写回 HBM。
* **第 7 步**：再把 $P$ 和 V 从 HBM 读回。
* **第 8 步**：在 SRAM 中做第二次矩阵乘法，计算 $O = P \cdot V$。
* **第 9 步**：把输出矩阵 $O$ 写回 HBM。

问题在于，中间的 $N \times N$ 矩阵 $S$ 和 $P$ 都会被先写入 HBM、再从 HBM 读回。计算本身并不慢，真正昂贵的是这些大矩阵在 HBM 和 SRAM 之间来回搬运。

<Accordion title="N×N 中间矩阵的 I/O 开销">
  <Frame caption="矩阵形状一目了然：Q、K、V、O 都是 N×d，而中间的分数矩阵 S 和概率矩阵 P 都是 N×N。当 N 远大于 d 时，S 和 P 会比输入输出大得多。">
    <img src="https://mintcdn.com/se7en/eaMJaPAQPjy6IQ-7/books/ai-systems-performance-engineering/images/ch01-attention-read-write.png?fit=max&auto=format&n=eaMJaPAQPjy6IQ-7&q=85&s=330579b9c6146681bb717dcf05c3b173" alt="Attention matrix shapes showing Q, K, V, O as N by d and S, P as N by N" width="1694" height="734" data-path="books/ai-systems-performance-engineering/images/ch01-attention-read-write.png" />
  </Frame>

  在 attention 的核心计算流程里，我们真正需要的输入和输出都是 $N \times d$ 的矩阵（Q、K、V、O），但中间会额外产生两个 $N \times N$ 的矩阵：分数矩阵 $S$ 和概率矩阵 $P$。**$N$ 是序列长度，$d$ 是单个 attention head 的维度（通常为 64 或 128；例如 hidden size = 4096、num heads = 32 时，$d_{head} = 4096 / 32 = 128$）。当 $N$ 远大于 $d$ 时，这两个中间矩阵会比输入输出大得多**：

  | 序列长度 $N$ | 单个 $N \times N$ 矩阵元素数 | 输入 $N \times d$（$d=128$）元素数 |
  | -------- | --------------------: | --------------------------: |
  | 4,096    |               1,600 万 |                        52 万 |
  | 65,536   |                  43 亿 |                       838 万 |
</Accordion>

最直接的优化思路是 **kernel fusion**：把原本分开的 matmul、softmax、matmul 尽量融合起来，中间结果留在 SRAM 里，HBM 只做首尾两趟读写。

但直接融合有一个核心障碍：**softmax 无法分块计算**。

<Frame caption="计算 softmax 矩阵 P 的单个元素 p_ij，需要读取 S 矩阵中的整行向量 s_i 来算分母">
  <img src="https://mintcdn.com/se7en/eaMJaPAQPjy6IQ-7/books/ai-systems-performance-engineering/images/ch01-softmax.png?fit=max&auto=format&n=eaMJaPAQPjy6IQ-7&q=85&s=3dff9b3ed9e2eb0ced3663a5695651e9" width="700" height="505" data-path="books/ai-systems-performance-engineering/images/ch01-softmax.png" />
</Frame>

**Softmax 是按行计算的：每个元素 $p_{ij}$ 的分母 $\sum_j e^{s_{ij}}$ 需要该行所有元素。** 这意味着 softmax kernel 需要一次读到整行数据，无法像 matmul 那样用 block tiling 分块处理。Matmul 每次只需要一小块数据就能算出部分结果，softmax 却必须看到整行，两个 kernel 需要的数据粒度不同，所以无法直接融合。

<Accordion title="Softmax 的作用与计算过程">
  在 attention 中，$Q \cdot K^T$ 算出的 score 矩阵 $S$ 只是原始的相似度分数，数值范围不固定，可正可负。Softmax 的作用是把每一行转换成概率分布：所有值变为正数且加起来等于 1，表示当前 token 对其他各 token 的关注程度。

  以一行 score $s = [2, 4, 1, 3]$ 为例：

  ```
  步骤 1：对每个元素取 exp
    exp(2)=7.39, exp(4)=54.60, exp(1)=2.72, exp(3)=20.09

  步骤 2：求和（这就是分母，需要整行数据）
    sum = 7.39 + 54.60 + 2.72 + 20.09 = 84.79

  步骤 3：每个 exp 值除以 sum
    softmax = [7.39/84.79, 54.60/84.79, 2.72/84.79, 20.09/84.79]
            = [0.087, 0.644, 0.032, 0.237]
  ```

  结果表明：当前 token 把 64.4% 的注意力放在第 2 个 token 上，23.7% 放在第 4 个，其余两个各占不到 10%。

  关键问题在步骤 2：**分母需要整行所有元素的 exp 之和**。如果只看到一半数据（比如 block tiling 只载入了 $[2, 4]$），算出的分母是 $7.39 + 54.60 = 61.99$，和完整分母 $84.79$ 不同，结果就是错的。这就是 softmax 阻止 kernel fusion 的根本原因。

  实际实现中还有一个数值稳定性技巧：先减去最大值再取 exp（即算 $e^{x_i - \max(x)}$），防止 $e^{x_i}$ 在 $x_i$ 很大时溢出。这个最大值同样需要看到整行数据。
</Accordion>

**FlashAttention 的解法 — Online softmax**

**核心是把 softmax 分解成可递推的形式。** 假设向量 $x$ 被分成两块 $x^{(1)}$ 和 $x^{(2)}$，标准 softmax 需要一次看到所有元素，但 online softmax 可以先算第一块、再用第二块修正：

$m^{(1)} = \max(x^{(1)}), \quad \ell^{(1)} = \sum_i e^{x^{(1)}_i - m^{(1)}}$

$m^{(2)} = \max(m^{(1)},\, \max(x^{(2)})), \quad \ell^{(2)} = e^{m^{(1)} - m^{(2)}} \ell^{(1)} + \sum_i e^{x^{(2)}_i - m^{(2)}}$

**$m$ 跟踪全局最大值（数值稳定）**，**$\ell$ 跟踪 exp 求和（softmax 分母）。每来一块新数据，用 $e^{m_{old} - m_{new}}$ 修正旧的 $\ell$，再累加新块的 exp。**

输出 $O$ 也做同样的 rescaling：

$O^{(2)} = \frac{\ell^{(1)} e^{m^{(1)} - m^{(2)}}}{\ell^{(2)}} \cdot O^{(1)} + \frac{1}{\ell^{(2)}} \cdot \tilde{P}^{(2)} V^{(2)}$

其中 $\tilde{P}^{(2)}$ 是第二块的未归一化 attention 权重，$V^{(2)}$ 是与这块权重对应的 value 子矩阵。前面的 $e^{m^{(1)} - m^{(2)}}$ 是显式的 rescaling 因子：如果第二块引入了更大的最大值，就要先把第一块的输出缩放到新的基准上；只有当 $m^{(2)} = m^{(1)}$ 时，这一项才会退化为 1。

这个递推可以扩展到任意多块，每次只需要一小块数据在 SRAM 里就能推进，**数学上与标准 softmax 完全等价**。这样 softmax 就能和 matmul 在相同的 block tile 上融合执行。

<Accordion title="Rescaling 具体在做什么？">
  用 score 向量 $[2, 4, 1, 3]$ 分两块处理来说明。

  **处理第一块 $[2, 4]$**

  ```
  m₁ = 4（当前最大值，用于数值稳定）
  ℓ₁ = exp(2-4) + exp(4-4) = 0.135 + 1 = 1.135
  ```

  用这个局部 softmax 权重乘以 V 的第一块（即前两个 token 对应的 value 向量 $v_1, v_2$），得到临时输出 $O_1$。此时 $O_1$ 只按第一块做了归一化，对应的 softmax 分母还是局部的 $\ell_1 = 1.135$，还不是看到全部 token 后的最终答案。

  **处理第二块 $[1, 3]$**

  ```
  m₂ = max(4, 3) = 4（全局最大值没变）
  ℓ₂ = ℓ₁ + exp(1-4) + exp(3-4) = 1.135 + 0.050 + 0.368 = 1.553
  ```

  分母从 1.135 变成了 1.553。之前的 $O_1$ 是按旧分母 1.135 算的，现在需要修正：

  ```
  O₂ = (ℓ₁/ℓ₂) × O₁ + 新块的贡献
     = (1.135/1.553) × O₁ + ...
     = 0.731 × O₁ + ...
  ```

  $\ell_1 / \ell_2 = 0.731$ 是这个例子里的 **rescaling 系数**。它把 $O_1$ 等比缩小，补偿"分母变大了"这个事实，再加上第二块 token 的贡献。这里第二块的局部最大值是 3，但全局最大值仍然是 4，所以 $m_2 = \max(4, 3) = 4$，$e^{m_1-m_2} = e^{4-4} = 1$；rescaling 不再来自 max 基准的变化，而只来自 softmax 分母从 $\ell_1 = 1.135$ 扩大到 $\ell_2 = 1.553$。

  **对每个 query block，只维护一个当前输出块 $O_i$，并在 SRAM 中原地更新。** 每处理完一块新的 K/V 数据，就先用 rescaling 系数 $\left(\ell_{old} e^{m_{old}-m_{new}}\right)/\ell_{new}$ 修正旧输出，再加上当前块带来的局部贡献。等所有块遍历完成后，$O_i$ 就是该 query block 的最终输出。
</Accordion>

**算法流程**

<Frame caption="FlashAttention forward pass 的 tiling 动画：外层循环遍历 K、V 的分块（列方向），内层循环遍历 Q 的分块（行方向），每次迭代在 SRAM 内完成局部计算并滚动更新 O、m(x)、l(x)。蓝色 = 输入，黄色 = 中间结果（仅在 SRAM 中），绿色 = 输出">
  <img src="https://mintcdn.com/se7en/eaMJaPAQPjy6IQ-7/books/ai-systems-performance-engineering/images/ch01-flashattention-animation.gif?s=55799987c017adf9269bc081ed657253" width="1912" height="1062" data-path="books/ai-systems-performance-engineering/images/ch01-flashattention-animation.gif" />
</Frame>

Forward pass 用两层嵌套循环：外层遍历 K、V 的分块（索引 $j$），内层遍历 Q 的分块（索引 $i$）。每次迭代在 SRAM 内完成局部 $QK^T$、softmax、$PV$ 的融合计算，滚动更新输出 $O$ 和统计量 $m$、$\ell$。全程不把任何 $N \times N$ 矩阵写到 HBM，最终只写回 $O$（$N \times d$）和两个长度为 $N$ 的向量。

<Accordion title="为什么需要两层嵌套循环？">
  因为 SRAM 放不下完整的 Q、K、V。一个完整的 attention 要求每个 Q 行都和**所有** K 列算 score，再对**所有** V 行加权求和。如果只遍历 Q 的分块，每次处理一块 Q 时仍然需要把完整的 K 和 V 放在 SRAM 里 — 放不下。

  所以用两层循环：外层每次换一块 K、V，内层让所有 Q 块都和当前这块 K 算一次局部 score：

  ```python theme={null}
  for j in range(K 的块数):      # 外层：每次换一块 K_j, V_j
      载入 K_j, V_j 到 SRAM
      for i in range(Q 的块数):  # 内层：每块 Q_i 都和当前 K_j 算一次
          载入 Q_i 到 SRAM
          局部 score = Q_i · K_j^T
          局部 softmax + rescaling
          O_i += 局部权重 · V_j   # 滚动更新输出
  ```

  任意时刻 SRAM 里只有一块 Q\_i（$B_r \times d$）、一块 K\_j（$B_c \times d$）、一块 V\_j（$B_c \times d$）和对应的小块中间结果，远小于 $N \times N$。当外层循环走完所有 K 块后，每个 O\_i 都已经和全部 K 算过、被 rescaling 到了正确值。
</Accordion>

**性能结果**

<Frame caption="左：FlashAttention 将 5 个 kernel 融合为 1 个 fused kernel，速度提升 7.6 倍。右：显存占用对比，标准 PyTorch 在 4K 序列长度即 OOM，FlashAttention 在 64K 时仍比近似方法 LinFormer 省一半显存">
  <img src="https://mintcdn.com/se7en/eaMJaPAQPjy6IQ-7/books/ai-systems-performance-engineering/images/ch01-flashattention-improvement.png?fit=max&auto=format&n=eaMJaPAQPjy6IQ-7&q=85&s=5cfa39fd0ea28c9ef9de2ae7971de108" width="2000" height="703" data-path="books/ai-systems-performance-engineering/images/ch01-flashattention-improvement.png" />
</Frame>

FlashAttention 带来的收益非常直接：

* 同样的模型训练更快
* 同样的模型可以用更大的 batch size
* 同样的预算可以训练更大（通常也更好）的模型
* 可以训练更长上下文窗口的模型
* 可以在更小的 GPU 上训练模型

以 OpenWebText 数据集为例，GPT-2 small 在 8×A100 上的训练时间从 9.5 天缩短到 2.7 天，GPT-2 medium 从 21.0 天缩短到 6.9 天。

***

**FlashAttention-1 到 FlashAttention-4 的概览如下：**

| 版本                                                   | 年份   | 关键改进                                                                             | 性能                                                                       | 备注                                           |
| ---------------------------------------------------- | ---- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | -------------------------------------------- |
| [FlashAttention-1](https://arxiv.org/abs/2205.14135) | 2022 | 引入 I/O-aware 分块 attention；融合 softmax 与 matmul kernel；避免物化完整 attention 矩阵         | **attention 速度提升 2-4 倍**；显存占用最高降低 10 倍                                   | 第一版；支持实用长上下文；exact attention（非近似）            |
| [FlashAttention-2](https://arxiv.org/abs/2307.08691) | 2023 | 改进 warp / thread block 并行与 work partitioning；减少 non-matmul FLOPs                 | **相比 FA-1 再快约 2 倍**，长序列下更明显                                              | 支撑了很多长上下文 LLM；已广泛集成到训练和推理框架                  |
| [FlashAttention-3](https://arxiv.org/abs/2407.08608) | 2024 | Tensor Core 加速（FP8/BF16）；针对 Hopper GPU（如 H100）优化                                 | **相比 FA-2 最高再快 2 倍**；H100 达到 740 TFLOPS（75% 利用率）；FP8 误差降低 2.6 倍          | 面向 Hopper 的专门优化版本；把 WGMMA、TMA、FP8 等硬件能力真正用起来 |
| [FlashAttention-4](https://arxiv.org/abs/2603.05451) | 2026 | 针对 Blackwell 重写 pipeline；fully asynchronous MMA；减少 non-matmul 和 backward pass 流量 | B200 BF16 达到 1613 TFLOPS（71% 利用率）；相较 cuDNN 最高快 1.3 倍；相较 Triton 最高快 2.7 倍 | 面向 Blackwell；基于 CuTe-DSL 实现，继续针对新硬件重排瓶颈      |

**参考资料**

* [FlashAttention from First Principles](https://ai.gopubby.com/flashattention-from-first-principles-part-1-5a9f2407d739#bypass)
* [FlashAttention — Visually and Exhaustively Explained](https://ai.gopubby.com/flashattention-visually-and-exhaustively-explained-d6124670f7fb#bypass)
* [Flash Attention 2.0 with Tri Dao (author)!](https://www.youtube.com/watch?v=IoMSGuiwV3g\&t=2240s)
* [Flash Attention学习过程【详】解](https://www.bilibili.com/video/BV1FM9XYoEQ5)
* [ELI5: FlashAttention](https://gordicaleksa.medium.com/eli5-flash-attention-5c44017022ad)
* [Designing Hardware-Aware Algorithms: FlashAttention](https://www.digitalocean.com/community/tutorials/flashattention)
* [FlashAttention: Fast and Memory-Efficient Exact Attention With IO-Awareness](https://www.nvidia.com/en-us/on-demand/session/gtc24-s62546/)

***

#### 4.2 DeepSeek MLA

DeepSeek 的 MLA 算法以 NVIDIA GPU kernel 的形式实现，并于 2025 年开源，是软硬件协同设计的另一个例子。与 FlashAttention 类似，MLA 重新组织了 attention 计算，以更好地利用 NVIDIA 的内存层级和专用的 GPU Tensor Cores。这些优化使 MLA 能够更充分地利用受限的 H800 GPU 架构，以更低的成本实现更高的吞吐量，甚至在同样的 H800 系统上超过了 FlashAttention 的性能。

<Frame caption="MHA、GQA、MQA 和 MLA 的 KV cache 组织方式对比：MHA 每个 head 独立缓存 K/V，GQA 按组共享 K/V，MQA 所有 heads 共享一组 K/V，MLA 则缓存压缩后的 latent KV，并在使用时投影回各个 head。">
  <img src="https://mintcdn.com/se7en/eaMJaPAQPjy6IQ-7/books/ai-systems-performance-engineering/images/ch01-mha-gqa-mqa-mla.png?fit=max&auto=format&n=eaMJaPAQPjy6IQ-7&q=85&s=32f56734a1f2c8dc7a7921bebf3c6f60" alt="Comparison of MHA, GQA, MQA, and MLA showing different KV cache organizations during inference" width="2138" height="620" data-path="books/ai-systems-performance-engineering/images/ch01-mha-gqa-mqa-mla.png" />
</Frame>

**MHA (Multi-Head Attention)** 是标准 Transformer 里的注意力形式。每个 head 都有独立的 `W_Q^(i)`、`W_K^(i)`、`W_V^(i)`，每个头各自计算注意力，最后把所有头的输出拼接再投影回去。它的表达能力最完整，但 decode 阶段也必须为每个 head 缓存完整 K/V，因此 KV cache 最大。

**MQA (Multi-Query Attention)** 保留多个 query heads，但所有 heads 共享同一组 K/V。这样 KV cache 从 `h` 份降到 `1` 份，显著减轻显存占用和 HBM 读流量，推理速度通常更高；代价是不同 heads 看到的是同一套 K/V，表达能力往往弱于 MHA。

**GQA (Grouped-Query Attention)** 是 MHA 和 MQA 之间的折中。它把 `h` 个 query heads 分成 `g` 组，每组共享一套 K/V，因此总共有 `g` 份 K/V。它保留了更多头间差异，因此表达能力通常强于 MQA，但仍弱于每个 head 都独立持有 K/V 的 MHA。

**MLA（Multi‑Head Latent Attention）** 先把所有头的 K/V 合在一起做一次低维压缩，只把这个共享的 latent 表示写进 KV cache，然后在算注意力时，各个头再用自己的变换从同一个 latent 里解码出各自的 K/V。这样既大幅缩小了 KV cache 的体积，又保留了不同注意力头之间的差异，不像 MQA/GQA 那样只是简单地共用同一套 K/V。

| 机制      | KV cache 大小      | 推理效率                   | 表达能力                      | 核心操作                           |
| ------- | ---------------- | ---------------------- | ------------------------- | ------------------------------ |
| **MHA** | 最大，随 head 数线性增加  | 基线                     | 最高                        | 每个 head 独立 Q/K/V               |
| **MQA** | 最小，只有 1 份 K/V    | 最快或接近最快                | 通常弱于 MHA                  | 所有 query heads 共享同一组 K/V       |
| **GQA** | 中等，有 `g` 份 K/V   | 比 MHA 快                | 通常介于 MHA 和 MQA 之间         | query heads 分组，组内共享 K/V        |
| **MLA** | 显著减少，缓存低维 latent | 实践中通常快于 MHA，接近 GQA/MQA | 在 DeepSeek 实验中可接近甚至超过 MHA | K/V 低秩联合压缩 + head-specific 上投影 |

#### 4.3 低精度量化

**低精度量化** 也是协同设计的典型体现。Transformer 的普及和 FP8、FP4 这类低精度格式的兴起，推动 NVIDIA 增加了 Transformer Engine、面向低精度计算的 Tensor Core、FP4 支持和 microscaling；而这些硬件能力又反过来让研究者可以探索新的数值优化器和神经网络结构，形成持续迭代的正反馈。

## FAQ

<Accordion title="MoE 的核心价值是什么？">
  **MoE 的价值不是"比原来的小模型更省计算"，而是用"同样的计算量，换来了大得多的模型"。** 例如 DeepSeek-V3 有 671B 总参数，但每 token 只需 37B 的计算量；如果用 dense 架构达到同样的知识容量，每 token 需要 671B 的计算量，MoE 省了 18 倍。
</Accordion>

<Accordion title="FlashAttention 优化的到底是什么？">
  FlashAttention 降到 $O(N)$ 的是 **HBM 内存占用**，不是计算量。Attention 本身就是每个 token 和所有 token 算 score，$O(N^2)$ 的计算是省不掉的。

  |                | 计算量                  | HBM 内存   | HBM I/O        |
  | -------------- | -------------------- | -------- | -------------- |
  | 标准 attention   | $O(N^2 \cdot d)$     | $O(N^2)$ | $O(N^2)$       |
  | FlashAttention | $O(N^2 \cdot d)$（没变） | $O(N)$   | $O(N \cdot d)$ |

  标准实现把整个 $N \times N$ 的中间矩阵物化到 HBM，内存 $O(N^2)$。FlashAttention 虽然两层循环遍历了所有 $N^2$ 个 score，但任意时刻 SRAM 里只有一小块，算完就丢，HBM 里始终只存 Q、K、V、O（各 $N \times d$）和统计量 $m$、$\ell$（各长度 $N$），所以内存是 $O(N)$。速度提升来自 I/O 减少（少搬了大量数据），不是因为算得少了。
</Accordion>