模型蒸馏、训练与推理、CANN 架构及 NVIDIA GPU 集群设计

峻熙2002

163人浏览 · 2026-11-06 11:32:22

峻熙2002 · 2026-11-06 11:32:22 发布

一、今日学习概述

今天主要围绕 AI Infra 的核心技术体系，学习了五个重要内容：

模型蒸馏技术与原理（Knowledge Distillation）
模型训练与推理的区别（Training vs Inference）
CANN 架构与核心组件
AI 算力生态及软硬件协同体系
NVIDIA GPU 服务器架构及集群组网

这五部分知识并不是孤立存在的，而是共同构成了现代 AI 基础设施的重要技术链路。

随着大语言模型参数规模不断增长，单台服务器、单张 GPU 已经很难满足大型模型的训练和部署需求。企业需要考虑的不仅是如何获得更强的计算能力，还包括如何降低模型部署成本、提高硬件利用率、优化多卡通信效率，以及如何将大量计算资源组织成稳定、高效的 AI 集群。

从整体架构来看，一个完整的 AI Infra 系统可以分成以下几个层次：

技术层次	核心技术	解决的问题
模型层	蒸馏、量化、剪枝	如何降低模型计算成本
计算任务层	训练、推理、分布式计算	如何组织计算任务
软件栈层	CUDA、CANN、编译器、算子库	如何调用和优化硬件
硬件层	CPU、GPU、HBM、NVLink	如何提供计算和存储能力
网络层	InfiniBand、RoCE、RDMA	如何实现高速数据交换
集群管理层	调度、监控、存储、运维	如何管理大规模算力资源

今天的学习重点，就是理解这些技术之间的关系，以及它们如何共同影响 AI 系统的性能。

二、模型蒸馏技术与原理：如何让大模型的知识迁移到小模型？

2.1 为什么需要模型蒸馏？

随着大语言模型的发展，模型参数规模不断增加。

从早期的几亿参数，到几十亿、数百亿，甚至更大规模的模型，模型能力得到了明显提升，但与此同时也带来了非常高的计算和部署成本。

例如，一个大型模型在部署时，通常需要考虑：

模型权重需要占用多少显存？
推理时需要多少 GPU？
每秒能够处理多少 Token？
单次请求需要消耗多少计算资源？
如何满足大量用户同时访问？
如何降低推理服务的总体拥有成本（TCO）？

假设有一个 70B 参数的大模型。

如果使用 FP16 精度，仅模型权重就需要大约：
$M=70\times10^9\times2$
$M=140\times10^9\text{ Bytes}$

换算后约为 140 GB（十进制）。

这还没有计算 KV Cache、运行时工作空间和其他显存开销。

如果直接使用这样的模型提供服务，就需要配置多张 GPU，或者采用其他模型切分和显存管理技术。

对于一些业务场景而言，并不一定需要如此庞大的模型。

例如：

企业内部知识问答。
文本分类。
智能客服。
简单代码辅助。
边缘设备上的 AI 推理。

这些场景可能只需要一个规模较小、响应速度更快的模型。

于是就产生了一个问题：

能不能让小模型学习大模型的知识，同时尽可能保留大模型的能力？

模型蒸馏就是解决这一问题的重要技术。

2.2 什么是知识蒸馏？

知识蒸馏（Knowledge Distillation，KD）是一种模型知识迁移技术。

其核心思想是：

利用一个已经训练好的大型模型作为教师模型（Teacher Model），通过它产生的预测结果、内部特征或其他监督信息，指导一个规模较小的学生模型（Student Model）进行训练。

最终让学生模型在参数量、显存占用和计算成本更低的情况下，尽可能接近教师模型的表现。

模型蒸馏通常包含两个角色。

1. 教师模型（Teacher Model）

教师模型通常具有较大的参数规模和较强的表达能力。

主要负责：

提供训练监督信号。
生成软标签。
提供中间层特征。
提供推理结果或解释过程。
指导学生模型学习。

教师模型一般在蒸馏阶段保持参数冻结，不参与学生模型的梯度更新。

2. 学生模型（Student Model）

学生模型通常规模较小，结构可以与教师模型不同。

主要负责：

学习教师模型提供的知识。
学习真实训练数据中的规律。
通过损失函数不断优化自身参数。
在有限资源下尽可能逼近目标能力。

例如：

假设教师模型有 70B 参数，学生模型有 7B 参数。

通过蒸馏训练，可以将教师模型在特定任务上的知识迁移到学生模型中。

需要注意，参数量缩小十倍，并不意味着能力一定保持不变。实际蒸馏效果取决于教师模型能力、学生模型容量、训练数据质量、蒸馏方法和训练过程。

2.3 硬标签与软标签：蒸馏为什么有效？

理解知识蒸馏，需要先理解 Hard Label 和 Soft Label。

假设现在有一个图像分类任务，需要判断图片属于猫、狗还是鸟。

传统监督学习使用真实标签：

类别	Hard Label
猫	1
狗	0
鸟	0

模型只知道正确答案是猫。

但是，它无法直接从这个标签中知道猫与狗之间是否存在相似特征。

而教师模型可能输出：

类别	Soft Label
猫	0.75
狗	0.20
鸟	0.05

这个概率分布提供了更多信息。

例如：

教师模型认为图片有 20% 的概率属于狗，说明图片中可能存在一些与狗相似的特征。

学生模型不仅学习正确答案，还能学习教师模型对其他类别的判断关系。

这种类别之间的相似性信息，也可以称为暗知识（Dark Knowledge）。

知识蒸馏的重要价值就在于：

传统监督学习主要告诉模型正确答案，而知识蒸馏进一步告诉学生模型教师是如何判断的。

2.4 Softmax 与温度参数 Temperature

在知识蒸馏中，温度参数是一个非常重要的概念。

首先，模型输出层通常会产生一组 Logits。

Logits 是经过神经网络计算得到的原始分数，还不是概率。

为了将它们转换成概率分布，需要使用 Softmax 函数。

普通 Softmax 公式：
$P_i=\frac{e^{z_i}}{\sum_j e^{z_j}}$

加入温度参数后：
$P_i^T= \frac{e^{z_i/T}} {\sum_j e^{z_j/T}}$

其中：

$(z_i)$ ：第 i 个类别的 Logit。
$(T)$ ：温度参数。
$(P_i^T)$ ：经过温度调整后的概率。
$(j)$ ：所有类别的索引。

温度参数主要影响概率分布的平滑程度。

当：

(T=1)：相当于普通 Softmax。
(T>1)：概率分布更加平滑，低概率类别的信息更容易体现出来。
(0<T<1)：概率分布更加尖锐，模型更加集中于高概率类别。

例如，教师模型原始输出经过 Softmax 后可能是：
$P=[0.90,0.08,0.02]$

提高温度后，概率可能变成：
$P^T=[0.65,0.25,0.10]$

这里的数值仅用于说明温度的作用。

可以看到，温度提高后，学生模型能够获得更加丰富的类别关系信息。

需要注意，温度并不是越高越好。温度过高可能使不同类别之间的概率差异变得过于微弱，反而损失有用信息。

2.5 模型蒸馏的核心损失函数

知识蒸馏通常将真实标签监督和教师模型监督结合起来。

主要包含两部分。

1. Hard Loss

Hard Loss 用于衡量学生模型预测结果与真实标签之间的差异。

常见形式是交叉熵损失：
$L_{\text{hard}}=CE(y,P_s)$

其中：

$(y)$ ：真实标签。
$(P_s)$ ：学生模型预测的概率分布。
$(CE)$ ：交叉熵损失。

2. Soft Loss

Soft Loss 用于衡量教师模型和学生模型输出分布之间的差异。

通常使用 KL 散度：
$L_{\text{soft}}= T^2D_{KL}(P_t^T\parallel P_s^T)$

其中：

$(P_t^T)$ ：教师模型经过温度调整后的概率分布。
$(P_s^T)$ ：学生模型经过温度调整后的概率分布。
$(D_{KL})$ ：KL 散度。
$(T^2)$ ：用于补偿温度缩放对梯度幅度的影响。

最终损失函数：
$L=\alpha L_{\text{hard}} +(1-\alpha)L_{\text{soft}}$

其中：

$(\alpha)$ ：真实标签损失的权重。
$(1-\alpha)$ ：蒸馏损失的权重。

通过调整权重，可以控制学生模型对真实标签和教师知识的学习程度。

2.6 模型蒸馏的不同实现方式

知识蒸馏并不只有一种方式。

根据教师模型向学生模型传递知识的位置和形式，可以分为以下几类。

1. 基于响应的蒸馏（Response-based Distillation）

这是最经典的蒸馏方式。

教师模型将最终输出的 Logits 或概率分布提供给学生模型。

学生模型通过匹配教师模型的输出，学习其预测能力。

优点：

实现简单。
不需要访问教师模型内部结构。
适合不同结构模型之间的知识迁移。

2. 基于特征的蒸馏（Feature-based Distillation）

这种方式不仅学习教师模型的最终输出，还会学习中间层的特征表示。

例如：

教师模型某一层输出一个特征向量，学生模型对应层也产生特征向量。

通过特征匹配损失，让学生模型学习教师模型的内部表示。

优点：

能够利用更多中间层信息。
适合需要迁移深层特征的任务。

挑战：

教师和学生模型的结构可能不同。
特征维度可能不一致。
通常需要额外的映射层或适配模块。

3. 基于关系的蒸馏（Relation-based Distillation）

这种方式关注不同样本、特征或层之间的关系。

例如：

教师模型认为样本 A 与样本 B 的特征距离较近，而与样本 C 的距离较远。

学生模型需要学习类似的关系结构。

这种方法能够迁移教师模型对数据整体关系的理解。

2.7 大语言模型中的蒸馏

在大语言模型领域，蒸馏的应用方式更加丰富。

例如：

使用教师模型生成高质量问答数据。
使用教师模型生成推理过程或解释数据。
让学生模型学习教师模型的 Token 分布。
利用教师模型生成的偏好数据进行训练。
将多个教师模型的能力整合到学生模型中。

需要区分：

教师模型生成问答数据，再使用这些数据训练学生模型，属于广义的知识迁移或数据蒸馏实践；严格来说，它与直接匹配教师模型 Logits 的经典蒸馏并不完全相同。

例如：

教师模型生成一批高质量的网络知识问答数据。

学生模型通过 SFT 学习这些问答样本，逐渐具备类似的任务处理能力。

这种方式可以降低训练数据构建成本，但学生模型能否真正学会教师模型的能力，还取决于数据覆盖范围、质量和训练方法。

2.8 蒸馏、量化与剪枝的区别

这三个技术经常同时出现在模型压缩和推理优化中，但解决的问题不同。

技术	核心思想	主要优化目标
知识蒸馏	教师向学生迁移知识	模型能力迁移
模型量化	降低数值表示精度	显存和计算成本
模型剪枝	删除冗余参数或结构	模型规模和计算量

例如：

一个 70B 模型可以通过蒸馏训练得到一个 7B 学生模型。

随后，可以进一步将 7B 模型从 FP16 量化到 INT8 或 INT4。

这样可以从模型规模和数值精度两个方向降低部署成本。

但是，蒸馏并不保证小模型一定能够保留教师模型的全部能力；量化也可能带来精度损失，需要通过实际评测确定效果。

2.9 从 AI Infra 角度理解模型蒸馏

模型蒸馏不仅仅是算法问题，它还会影响整个基础设施的资源规划。

例如：

假设一个企业需要部署一个大型语言模型，服务大量内部用户。

如果直接部署大型教师模型，可能需要多台 GPU 服务器。

如果通过蒸馏得到较小的学生模型，可能可以：

降低单个模型实例的显存占用。
减少单个推理实例需要的 GPU 数量。
提高同一台服务器能够部署的模型实例数量。
降低推理服务的硬件投入。
减少部分业务场景下的推理延迟和能耗。

但最终是否能够降低整体成本，还需要结合并发量、吞吐量、精度要求和模型服务架构进行评估。

本节总结：

模型蒸馏的核心不是简单地缩小模型，而是通过知识迁移，让较小模型学习大型模型的能力。

从 AI Infra 的角度看，它直接影响模型部署规模、GPU 资源需求、显存规划和推理成本，是模型优化与算力基础设施之间的重要连接点。

三、模型训练与推理：为什么两者需要不同的算力架构？

3.1 模型训练与推理的本质区别

模型训练（Training）和模型推理（Inference）是大模型生命周期中两个不同的阶段。

训练负责让模型学习知识、优化参数。

推理负责使用已经训练好的参数完成实际计算。

虽然两者都需要执行神经网络前向计算，但在计算流程、显存需求、网络通信和性能目标方面存在明显差异。

模型训练

训练的核心过程：

输入训练数据。
执行前向传播。
计算预测结果与真实结果之间的损失。
执行反向传播。
计算模型参数的梯度。
使用优化器更新模型参数。
进入下一轮训练。

训练过程中，模型参数会不断发生变化。

参数更新的基本数学表达式：
$\theta_{t+1}= \theta_t-\eta\nabla_\theta L(\theta_t)$

其中：

$(\theta_t)$ ：当前模型参数。
$(\theta_{t+1})$ ：更新后的模型参数。
$(\eta)$ ：学习率。
$(L)$ ：损失函数。
$(\nabla_\theta L)$ ：损失函数对参数的梯度。

实际训练通常使用 AdamW 等优化器，而不只是简单的梯度下降。

模型推理

推理阶段不再进行常规的模型参数更新。

系统将输入数据送入训练好的模型，执行前向计算，最后输出结果。

例如：

用户输入：

"请解释什么是 AI Infra。"

系统首先将文本转换为 Token，然后输入模型。

模型根据已有参数计算下一个 Token 的概率分布，选择或采样 Token，并不断重复这一过程，直到生成完整回答。

需要注意，推理阶段的模型权重通常保持不变，但运行过程中仍然会有激活值、KV Cache 和临时工作空间的变化。

3.2 训练阶段的计算与显存组成

在大模型训练过程中，显存占用远远不只是模型权重。

通常需要考虑以下几部分：

1. 模型权重（Model Weights）

用于保存神经网络参数。

2. 梯度（Gradients）

反向传播过程中计算得到的梯度，用于更新模型参数。

3. 优化器状态（Optimizer States）

以 AdamW 为例，通常需要保存一阶矩和二阶矩估计。

4. 激活值（Activations）

前向传播过程中产生的中间结果，需要在反向传播时用于梯度计算。

5. 临时工作空间（Workspace）

矩阵计算、算子执行和其他运行时操作可能需要额外的显存空间。

因此，训练显存可以抽象表示为：
$M_{\text{train}}= M_{\text{weights}}+ M_{\text{gradients}}+ M_{\text{optimizer}}+ M_{\text{activations}}+ M_{\text{workspace}}$

这只是逻辑上的显存组成模型，实际占用还会受到混合精度、参数分片、激活检查点和内存分配策略等影响。

以 AdamW 和混合精度训练为例

假设模型参数量为 7B。

在一种典型的混合精度训练配置中，可以使用以下近似估算：

显存组成	近似单参数占用
FP16/BF16 模型权重	2 Bytes
FP32 主权重副本	4 Bytes
FP32 梯度	4 Bytes
Adam 一阶矩	4 Bytes
Adam 二阶矩	4 Bytes
合计	18 Bytes

那么：
$M=7\times10^9\times18$
$M=126\times10^9\text{ Bytes}$

约为 126 GB（十进制）。

这里还没有包含激活值、临时工作空间和其他运行时开销。

实际训练配置可能使用不同的数据类型和优化器实现，因此不能将 18 Bytes 当成所有训练任务的固定标准。

这个例子说明：

大模型训练的显存需求，通常远远高于只存放模型权重时的需求。

3.3 推理阶段的显存组成

推理阶段通常不需要保存训练所需的梯度和优化器状态。

但对于大语言模型，还需要考虑 KV Cache。

推理显存可以抽象为：
$M_{\text{infer}}= M_{\text{weights}}+ M_{\text{KV Cache}}+ M_{\text{activations}}+ M_{\text{workspace}}$

其中：

Model Weights：模型权重。
KV Cache：历史 Token 对应的 Key 和 Value 缓存。
Activations：前向计算产生的中间数据。
Workspace：运行时工作空间。

KV Cache 为什么重要？

Transformer 模型在生成 Token 时，需要利用之前 Token 的注意力信息。

如果每生成一个 Token，都重新计算之前所有 Token 的 Key 和 Value，就会产生大量重复计算。

因此，推理系统会缓存之前计算得到的 Key 和 Value。

这就是 KV Cache。

KV Cache 能够减少重复计算，但也会占用大量显存。

其占用规模与以下因素有关：

Batch Size。
上下文长度。
Transformer 层数。
KV Head 数量。
Head Dimension。
KV Cache 数据类型。

一个常见的近似估算公式为：
$M_{\text{KV}}= 2\times L\times B\times S\times H_{\text{KV}} \times D_{\text{head}}\times Q$

其中：

$(L)$ ：Transformer 层数。
$(B)$ ：Batch Size。
$(S)$ ：缓存 Token 数量。
$(H_{\text{KV}})$ ：Key/Value Head 数量。
$(D_{\text{head}})$ ：每个 Head 的维度。
$(Q)$ ：每个元素占用的字节数。
2：分别表示 Key 和 Value。

例如：

假设模型有 32 层，8 个 KV Heads，每个 Head 维度为 128，Batch Size 为 1，缓存 8192 个 Token，使用 FP16。

那么：
$M_{\text{KV}}= 2\times32\times1\times8192 \times8\times128\times2$
$M_{\text{KV}}=1,073,741,824\text{ Bytes}$

约为 1 GiB。

这还没有考虑分页管理、对齐、分片和其他实现开销。

由此可以看出，长上下文推理对显存容量提出了很高的要求。

3.4 训练与推理的核心性能差异

对比维度	Training	Inference
核心目的	学习和更新参数	使用模型生成结果
参数状态	更新	通常固定
前向传播	需要	需要
反向传播	需要	通常不需要
梯度	需要	不需要
优化器状态	需要	不需要
KV Cache	通常不是标准训练的主要显存组成	自回归推理的重要组成
主要性能目标	训练吞吐量	延迟、吞吐量和成本
典型通信	梯度、参数和激活交换	模型分片及 KV 数据交换

3.5 大模型推理的两个关键阶段：Prefill 与 Decode

大语言模型推理并不是一次简单的前向计算。

它通常包含两个重要阶段。

1. Prefill：预填充阶段

Prefill 负责处理用户输入的 Prompt。

例如用户输入一段 2000 Token 的文本。

模型会对这 2000 个 Token 进行计算，生成对应的 Key 和 Value，并存入 KV Cache。

这一阶段具有较高的并行计算特征。

因为输入 Token 可以在符合注意力依赖关系的条件下并行处理，所以通常更容易发挥 GPU 的矩阵计算能力。

关键指标：

TTFT（Time To First Token），即从请求进入系统到生成第一个 Token 的时间。

2. Decode：解码阶段

Decode 负责逐 Token 生成输出。

例如模型已经处理完 Prompt，现在需要继续生成：

"AI Infra 是人工智能基础设施……"

模型每次生成一个 Token，都需要读取模型权重、访问历史 KV Cache，并计算下一个 Token。

这个阶段通常具有较强的访存压力。

特别是在 Batch Size 较小的情况下，GPU 可能无法充分发挥矩阵计算能力。

关键指标：

TPOT（Time Per Output Token），即生成后续输出 Token 的平均耗时。

Prefill 与 Decode 对比

维度	Prefill	Decode
主要任务	处理输入文本	生成输出 Token
计算方式	多 Token 并行处理	自回归逐 Token 生成
主要压力	计算能力	显存带宽、KV Cache 访问
重要指标	TTFT	TPOT
优化方向	提高计算吞吐量	降低访存和调度开销

这里需要强调：Prefill 并非完全不受显存带宽限制，Decode 也并非只受显存带宽限制。实际瓶颈取决于模型结构、批量大小、序列长度、硬件和推理引擎。

3.6 为什么需要 Prefill 和 Decode 分离？

在传统推理部署中，同一批 GPU 既处理 Prompt，也负责生成 Token。

但这两个阶段的资源需求不同。

当大量请求同时进入系统时：

Prefill 可能占用大量计算资源。
Decode 需要持续访问 KV Cache。
不同请求的输入长度和输出长度存在较大差异。
两个阶段之间可能出现资源争用。

因此，一些大规模推理系统采用 Prefill-Decode Disaggregation（PD 分离）架构。

核心思想是：

将 Prefill 和 Decode 分别部署到不同的 GPU 资源池中。

其基本流程：

用户请求进入 Prefill 集群。
Prefill 集群处理输入 Prompt。
生成 KV Cache。
将 KV Cache 传输到 Decode 集群。
Decode 集群继续生成 Token。
将生成结果返回用户。

这种方式可以根据两种任务的资源特点分别配置 GPU 数量。

但是，PD 分离也会引入 KV Cache 跨节点传输成本，需要高速网络、缓存管理和合理的调度机制。

3.7 训练场景下的并行计算技术

当模型无法放入单张 GPU，或者训练时间过长时，就需要采用分布式训练。

主要有以下几种并行方式。

1. 数据并行（Data Parallelism，DP）

数据并行的核心思想：

每张 GPU 保存一份模型副本，但处理不同的训练数据。

例如：

有 4 张 GPU，每张 GPU 都保存相同模型。

每张 GPU 分别处理不同的数据批次。

完成前向传播和反向传播后，通过 AllReduce 等通信操作同步梯度。

然后各 GPU 更新模型参数。

优点：

实现相对简单。
适合模型能够放入单卡的场景。
能够提高整体训练吞吐量。

挑战：

需要同步梯度。
通信开销可能限制扩展效率。
模型副本会占用较多显存。

2. 张量并行（Tensor Parallelism，TP）

张量并行将模型中的矩阵计算拆分到多张 GPU 上执行。

例如：

一个大型矩阵乘法可以按列或按行切分，让不同 GPU 分别完成部分计算。

最后通过通信操作合并计算结果。

优点：

可以分担单卡计算和显存压力。
适合大型 Transformer 模型。
能够利用高速 GPU 互联。

挑战：

GPU 之间通信频繁。
对 NVLink 等高速互联有较高要求。
拓扑设计会影响实际性能。

3. 流水线并行（Pipeline Parallelism，PP）

流水线并行将模型不同层分配到不同 GPU。

例如：

GPU 0：模型第 1～8 层。
GPU 1：模型第 9～16 层。
GPU 2：模型第 17～24 层。
GPU 3：模型第 25～32 层。

数据依次经过不同 GPU，形成流水线计算。

优点：

可以分散模型权重。
适合层数较多的大模型。

挑战：

可能出现流水线空闲时间。
需要合理划分 Micro-batch。
阶段之间存在激活值通信。

4. 专家并行（Expert Parallelism，EP）

专家并行主要用于 MoE（Mixture of Experts，混合专家）模型。

MoE 模型通常包含多个专家网络，通过 Router 选择部分专家处理当前 Token。

专家并行将不同专家部署在不同 GPU 上。

当 Token 被路由到其他 GPU 的专家时，就需要通过网络进行数据交换。

因此，MoE 模型对 All-to-All 通信有较高要求。

5. 三维并行与混合并行

实际大模型训练通常不会只使用一种并行策略。

而是结合 DP、TP、PP，有时还会结合 EP。

例如：
$N_{\text{GPU}}=DP\times TP\times PP$

假设：

DP = 4。
TP = 8。
PP = 2。

那么：
$N_{\text{GPU}}=4\times8\times2=64$

需要 64 张 GPU。

这只是一个基础的三维并行配置示例。实际 MoE 和混合并行还需要考虑 EP、上下文并行等维度，以及并行组之间的资源分配。

3.8 从 AI Infra 角度理解训练与推理

训练和推理对基础设施的要求不同，因此服务器规划也不能简单地采用同一套标准。

训练集群重点关注：

GPU 计算能力。
HBM 容量和带宽。
GPU 之间的 NVLink 带宽。
多服务器之间的 RDMA 通信。
集合通信效率。
数据存储和读取能力。
长时间运行的可靠性。

推理集群重点关注：

模型权重显存占用。
KV Cache 容量。
Prefill 计算吞吐量。
Decode 访存效率。
请求调度和动态批处理。
首 Token 延迟和 Token 间延迟。
单位 Token 成本。
服务并发量。

本节总结：

训练关注如何高效地学习和更新参数，推理关注如何高效地使用参数。

理解两者的计算特征，才能正确进行 GPU 服务器选型、显存规划、网络设计和算力资源调度。

四、CANN 架构与核心组件：昇腾如何完成 AI 计算？

4.1 CANN 是什么？

CANN 全称为 Compute Architecture for Neural Networks，即神经网络计算架构。

它是华为昇腾 AI 计算生态中的核心软件基础设施。

可以将 CANN 理解为连接上层 AI 框架和底层昇腾 AI 处理器的软件平台。

为什么需要这样的平台？

假设开发者使用 PyTorch 编写了一个 Transformer 模型。

模型中包含：

矩阵乘法。
Attention。
Softmax。
LayerNorm。
激活函数。
其他自定义计算。

这些操作本质上都是计算任务。

但是，PyTorch 中的计算描述并不等于昇腾硬件能够直接执行的底层指令。

中间还需要经过框架适配、计算图处理、算子编译、任务调度和设备执行等过程。

CANN 就是承担这些工作的关键软件体系。

它向上支持 AI 框架，向下连接昇腾 AI 处理器。

4.2 CANN 的整体软件架构

从逻辑上看，CANN 可以拆分为以下几个主要部分：

AI 框架适配。
图引擎（GE）。
编译器。
算子库。
Runtime 运行时。
HCCL 通信库。
AscendCL 编程接口。
开发与性能调优工具。

这些组件并不是完全独立运行的，而是共同构成一个完整的软件执行体系。

4.3 AI 框架适配层

AI 框架适配层主要负责连接上层 AI 框架。

例如：

PyTorch。
MindSpore。
TensorFlow。

在昇腾平台上，PyTorch 可以通过对应的适配组件 Torch-NPU 等与 CANN 体系协同工作。

框架适配层的核心任务是：

将上层框架中的算子和计算逻辑转换成底层能够处理的计算任务。

例如：

开发者使用 PyTorch 编写：

output = torch.matmul(input_a, input_b)

从开发者角度看，只是执行了一次矩阵乘法。

但是在底层，还需要确定：

输入数据存储在哪里？
使用什么数据类型？
采用什么矩阵计算实现？
如何分配计算资源？
是否可以进行算子融合？
如何将计算任务提交给 NPU？

这就是框架适配和底层计算体系需要解决的问题。

4.4 GE：Graph Engine 图引擎

GE 是 CANN 中的重要组件。

它主要负责计算图的构建、解析、优化和执行管理。

什么是计算图？

一个神经网络可以看成由多个计算节点和数据依赖关系组成的有向图。

例如：

输入数据 → 矩阵乘法 → 激活函数 → 归一化 → 输出。

其中：

节点代表计算操作。
边代表数据依赖关系。

GE 可以对计算图进行优化。

常见优化方向包括：

1. 算子融合

将多个连续的计算操作合并为一个更高效的执行单元。

例如：

原本需要多次启动计算 Kernel，并将中间结果写入显存。

经过融合后，可以减少部分中间数据搬运和 Kernel Launch 开销。

2. 内存复用

如果两个计算阶段不需要同时保留某些中间数据，就可以复用相关内存空间。

这样可以降低显存占用。

3. 图优化

通过分析计算依赖关系，优化执行顺序和任务组织方式。

4. 子图优化

针对计算图中的局部结构进行优化，提高整体执行效率。

需要注意，GE 的具体功能和执行路径会根据 CANN 版本、模型运行模式和开发接口有所不同。

4.5 算子库：AI 计算的基础单元

算子（Operator）是神经网络计算的基本组成单位。

例如：

MatMul：矩阵乘法。
Conv：卷积。
Softmax：归一化概率计算。
LayerNorm：层归一化。
Attention：注意力计算。

为什么算子库如此重要？

因为 AI 模型的计算效率，很大程度上取决于底层算子的实现效率。

同样一个矩阵乘法：

如果使用普通的通用计算实现，可能无法充分利用 AI 芯片的矩阵计算单元。

如果使用针对硬件架构优化的实现，就可以更好地利用计算单元、片上存储和数据搬运能力。

因此，算子库需要针对硬件特点进行优化。

CANN 体系提供了相应的算子加速库。

当现有算子无法满足业务需求时，开发者还可以使用 Ascend C 等方式开发自定义算子。

4.6 Ascend C：昇腾算子开发语言

Ascend C 是面向昇腾 AI 处理器的算子开发编程语言。

它主要用于开发和优化底层计算算子。

为什么需要自定义算子？

假设某个大模型使用了特殊的 Attention 计算结构。

如果现有算子没有充分适配该结构，就可能产生：

多次 Kernel Launch。
不必要的数据搬运。
中间显存占用过高。
硬件计算单元利用率不足。

通过自定义算子，可以根据硬件特点优化计算过程。

Ascend C 的主要价值在于：

提供面向昇腾硬件的编程能力。
支持高效的数据搬运与计算组织。
帮助开发者实现硬件亲和的算子。
提高特定模型结构的运行效率。

对于 AI Infra 工程师而言，理解算子开发的价值非常重要。

因为模型运行慢，并不一定是 GPU 或 NPU 算力不足，也可能是算子实现和数据访问方式不合理。

4.7 编译器：将计算描述转换为硬件可执行任务

编译器是 AI 软件栈中的关键组件。

它负责将上层计算描述转换成底层硬件可以执行的代码或任务。

在 CANN 体系中，编译相关能力包括图编译、算子编译以及毕昇编译器等。

编译优化通常涉及：

计算图优化。
算子代码生成。
数据布局优化。
指令选择。
内存访问优化。
并行执行规划。

可以将其理解为：

开发者描述需要计算什么，编译器负责研究如何在硬件上更高效地完成这些计算。

这与传统 CPU 编译器的目标有相似之处，但 AI 编译还需要处理张量运算、计算图和专用加速器的硬件特性。

4.8 Runtime：运行时管理

Runtime 负责管理模型和算子真正执行时的资源。

主要功能包括：

Device 管理。
Context 管理。
Stream 管理。
内存管理。
Kernel 管理。
Event 同步。
任务执行。
设备状态管理。

这里重点理解三个概念。

Device：设备管理

负责设备初始化、设备状态查询和设备资源管理。

Context：上下文管理

可以理解为设备计算任务的运行环境。

不同执行任务可以在相应的上下文中完成管理。

Stream：任务流管理

Stream 可以理解为设备上的逻辑执行队列。

通过多个 Stream，可以组织不同任务的执行，并在满足依赖关系时实现计算和数据传输的重叠。

例如：

CPU 可以提前提交下一批数据传输任务，而 NPU 同时执行上一批计算任务。

合理组织任务流，有助于提高设备利用率。

4.9 AscendCL：昇腾计算开放编程接口

AscendCL 是昇腾计算开放编程接口。

它为开发者提供了一套应用开发 API。

主要包括：

设备管理。
Context 管理。
Stream 管理。
内存管理。
模型加载和执行。
算子加载和执行。
Graph 管理。
数据处理相关接口。

可以把 AscendCL 理解为开发者访问昇腾计算能力的重要接口层。

例如，开发者可以使用 AscendCL 完成：

初始化计算环境。
选择并打开 NPU 设备。
创建 Context 和 Stream。
分配输入输出内存。
加载模型。
提交计算任务。
获取模型执行结果。
释放相关资源。

4.10 HCCL：昇腾分布式通信库

HCCL 全称为 Huawei Collective Communication Library。

它是昇腾平台的重要集合通信库。

在多卡、多机训练中，单个 NPU 无法独立完成所有任务。

不同 NPU 之间需要交换梯度、参数、特征和中间计算结果。

HCCL 主要负责提供高性能通信能力。

常见通信操作包括：

通信操作	主要作用
AllReduce	多设备归约后，每个设备获得相同结果
AllGather	收集各设备数据并分发完整数据
ReduceScatter	归约后将结果切分分发
Broadcast	将一个设备的数据广播给其他设备
AlltoAll	各设备之间进行数据交换
Send/Receive	点对点数据通信

例如，在数据并行训练中：

每张 NPU 分别计算本地梯度。
各设备通过 AllReduce 进行梯度归约。
每张 NPU 获得相同的全局梯度结果。
各设备使用相同梯度更新参数。

HCCL 的意义不仅是实现数据传输，更重要的是根据硬件拓扑和通信算法，尽可能提高通信效率。

4.11 CANN 的完整执行链路

现在将前面这些组件串联起来。

假设开发者需要在昇腾平台上部署一个大语言模型。

整体流程可以理解为：

第一步：模型开发

使用 PyTorch 或 MindSpore 构建模型。

第二步：框架适配

通过相应框架适配组件，将模型计算转换成昇腾平台能够处理的计算任务。

第三步：计算图处理

GE 对计算图进行解析、优化和执行管理。

第四步：算子编译

编译器将算子和计算图转换成适合底层硬件执行的形式。

第五步：资源管理

Runtime 管理设备、内存、Stream 和计算任务。

第六步：算子执行

通过算子库或自定义算子完成具体计算。

第七步：硬件执行

昇腾 AI 处理器执行实际计算任务。

第八步：多卡通信

如果涉及分布式训练，则通过 HCCL 等通信组件实现设备间数据交换。

整体逻辑可以概括为：

AI 框架 → 框架适配 → GE 图引擎 → 编译优化 → Runtime → 算子执行 → Ascend NPU。

多卡、多机任务则需要额外结合 HCCL 完成通信。

4.12 从 AI Infra 角度理解 CANN

CANN 的价值不仅在于提供接口。

它真正解决的是上层 AI 计算任务如何映射到底层昇腾硬件的问题。

例如：

一个模型在 NPU 上运行速度较慢，可能存在以下原因：

框架适配不完整。
某些算子没有高效实现。
计算图优化不足。
内存访问效率较低。
Stream 调度不合理。
多卡通信开销过大。

这意味着，排查 AI 计算性能问题时，不能只关注芯片理论算力，还需要分析整个软件执行链路。

本节总结：

CANN 是昇腾 AI 计算生态中的核心软件基础设施。

GE 负责计算图管理和优化，编译器负责计算任务编译，算子库提供高性能计算实现，Runtime 管理执行资源，AscendCL 提供应用开发接口，HCCL 负责分布式通信。

这些组件共同决定模型能否在昇腾硬件上高效运行。

五、AI 算力生态：为什么芯片性能不等于实际 AI 性能？

5.1 AI 算力生态的真正含义

AI 算力生态不是简单地将 GPU、CPU 和服务器放在一起。

它是由硬件、驱动、编译器、算子库、运行时、AI 框架、模型、推理引擎和集群管理系统组成的完整技术体系。

可以把它理解为一个分层的软件与硬件生态。

例如：

开发者编写了一个大模型。

模型需要通过 AI 框架进行训练。

框架需要调用底层算子。

算子需要经过编译和优化。

编译后的计算任务需要运行时管理。

最终，GPU 或 NPU 执行实际计算。

如果是分布式训练，还需要通信库和高速网络。

因此，AI 算力生态中的任何一层出现问题，都可能影响最终的计算性能。

5.2 AI 算力生态的六层架构

第一层：硬件基础设施层

主要包括：

CPU。
GPU。
NPU。
HBM。
DDR。
PCIe。
NVLink。
高速网卡。
交换机。
存储设备。

这一层决定基础计算、数据存储和数据传输能力。

第二层：驱动与设备管理层

负责硬件初始化、设备识别、内存管理和设备控制。

例如：

NVIDIA Driver。
CUDA Driver。
Ascend Driver。
设备管理相关组件。

这一层是操作系统与计算设备之间的重要连接。

第三层：编译器与运行时层

负责将计算任务映射到底层硬件。

NVIDIA 生态中常见：

CUDA Runtime。
CUDA Compiler。
PTX。
TensorRT 相关执行能力。

昇腾生态中常见：

CANN。
Ascend Runtime。
毕昇编译器。
GE。

这一层决定计算任务如何被组织和执行。

第四层：算子与通信库层

算子库主要负责具体计算。

通信库主要负责多设备之间的数据交换。

NVIDIA 生态：

cuBLAS。
cuDNN。
NCCL。
TensorRT。

昇腾生态：

算子库。
Ascend C。
HCCL。
ATB。

这一层对模型执行效率影响非常大。

第五层：AI 框架与模型层

AI 框架主要提供模型开发、训练和推理接口。

例如：

PyTorch。
TensorFlow。
MindSpore。
JAX。

模型则包括：

LLM。
Vision Model。
Multimodal Model。
Recommendation Model。
Speech Model。

这一层决定系统要完成什么 AI 任务。

第六层：AI 应用与服务层

主要包括：

大模型 API 服务。
企业知识库。
AI Agent。
智能客服。
代码生成。
图像识别。
智能搜索。
自动驾驶。

这一层直接面向业务用户。

5.3 主流 AI 算力生态对比

当前主流 AI 计算平台主要包括 NVIDIA、华为昇腾、AMD 和 Google TPU 等。

平台	核心硬件	软件生态	主要特点
NVIDIA	GPU	CUDA、cuDNN、TensorRT、NCCL	成熟的 GPU 计算生态
华为昇腾	Ascend NPU	CANN、MindSpore、HCCL	面向昇腾硬件的软硬件体系
AMD	GPU	ROCm、HIP、MIOpen	开放的软件与 GPU 计算生态
Google	TPU	XLA、JAX、TensorFlow	面向 AI 计算的专用加速平台

不同平台的底层架构和软件接口存在差异。

因此，模型从一个平台迁移到另一个平台时，可能需要进行：

算子适配。
数据类型适配。
模型图转换。
编译配置调整。
性能调优。
分布式通信适配。

这也是异构算力平台建设中经常遇到的问题。

5.4 为什么软件生态如此重要？

假设现在有两款 AI 加速芯片。

A 芯片理论算力为 1000 TFLOPS。

B 芯片理论算力为 800 TFLOPS。

从理论计算能力来看，A 芯片更强。

但如果 A 芯片缺少成熟的算子库、框架适配和编译优化，而 B 芯片拥有更加完善的软件生态。

在实际模型运行中，B 芯片可能反而取得更好的性能。

原因在于：

理论算力只是硬件的计算能力上限，并不代表实际应用能够完全利用这些计算资源。

实际性能还会受到：

算子实现效率。
内存访问效率。
数据搬运开销。
Kernel Launch 开销。
编译器优化能力。
通信效率。
任务调度效率。

等因素影响。

因此，可以将实际性能理解为：
$P_{\text{actual}} \leq P_{\text{theoretical}}$

实际性能通常无法达到理论峰值。

5.5 Roofline Model：理解计算瓶颈

Roofline Model 是分析计算性能的重要模型。

它将计算能力和内存带宽联系起来。

核心公式：

$\min(P_{\text{peak}},B\times AI)$

其中：

$(P_{\text{attainable}})$ ：可达到的计算性能。
$(P_{\text{peak}})$ ：硬件理论峰值算力。
$(B)$ ：内存带宽。
$(AI)$ ：Arithmetic Intensity，算术强度。

算术强度定义：
$AI=$ 计算操作数 $/$ 数据搬运字节数

它表示每搬运一个字节的数据，能够完成多少计算操作。

根据算术强度，可以将计算任务分成两类。

1. Compute-bound（计算受限）

当任务的计算量很大，而数据搬运相对较少时，性能主要受到计算单元限制。

这类任务需要更强的计算能力。

2. Memory-bound（访存受限）

当任务需要频繁访问显存，而实际计算量相对较少时，性能主要受到内存带宽限制。

这类任务需要更高的内存带宽和更好的数据访问效率。

例如：

大规模矩阵乘法通常更容易表现出计算密集型特征。

而大模型 Decode 阶段在低 Batch Size 下，可能更容易受到显存带宽限制。

Roofline 模型能够帮助我们理解为什么某些任务无法充分利用 GPU 理论算力。

5.6 AI Infra 工程师需要关注哪些生态问题？

在真实项目中，选择 AI 算力平台不能只看 GPU 或 NPU 的型号。

还需要关注：

模型是否能够正常运行。
AI 框架是否兼容。
常用算子是否有高性能实现。
编译器是否能够进行有效优化。
是否支持混合精度计算。
多卡通信是否成熟。
分布式训练是否稳定。
推理引擎是否能够充分利用硬件。
是否具有完善的监控和调试工具。
是否能够满足企业级部署与运维要求。

本节总结：

AI 算力生态的竞争不仅是硬件性能的竞争，更是软件、工具链、通信能力和应用适配能力的综合竞争。

真正优秀的 AI 算力平台，需要让模型、框架、编译器、算子和硬件形成完整的协同体系。

六、NVIDIA GPU 服务器架构：从单机多卡到机架级计算

6.1 为什么需要 GPU 服务器？

在传统服务器中，CPU 通常负责大部分计算任务。

但深度学习模型包含大量矩阵运算和张量运算，CPU 在这类大规模并行任务中可能无法满足性能需求。

GPU 具有大量并行计算单元，能够同时处理大量数据，因此成为现代 AI 计算的重要硬件。

但是，一张 GPU 的计算能力和显存容量仍然有限。

当模型规模继续增长，就需要：

多张 GPU 协同工作。
多台服务器共同计算。
高速 GPU 互联。
高速服务器间网络。
大规模存储系统。

这就是 GPU 服务器和 AI 集群出现的原因。

6.2 NVIDIA GPU 服务器的核心组成

一台典型的数据中心 GPU 服务器主要包括以下组件。

1. CPU：主机处理器

CPU 负责：

操作系统运行。
任务调度。
数据预处理。
GPU 任务提交。
系统资源管理。
外部设备管理。

在 GPU 服务器中，CPU 通常承担 Host 端控制和通用计算任务。

2. GPU：AI 计算核心

GPU 主要负责：

矩阵乘法。
卷积计算。
Attention。
神经网络训练。
模型推理。

NVIDIA 数据中心 GPU 中包含大量计算单元和 Tensor Core。

Tensor Core 专门针对矩阵运算和深度学习计算进行优化，支持多种数据精度。

3. HBM：高带宽显存

HBM 用于保存 GPU 计算所需的数据。

例如：

模型权重。
激活值。
梯度。
KV Cache。
临时计算数据。

HBM 的两个重要指标：

显存容量：

决定 GPU 能够容纳多少模型数据。

显存带宽：

决定 GPU 能够以多快的速度读取和写入数据。

对于大模型推理而言，显存容量和带宽都非常重要。

4. PCIe：主机与设备之间的重要互联

PCIe 是服务器内部的重要高速总线。

常见连接对象：

CPU。
GPU。
网卡。
NVMe SSD。
其他 PCIe 设备。

例如：

CPU 可以通过 PCIe 向 GPU 传输数据。

网卡也可以通过 PCIe 与 CPU 或 GPU 所在的数据传输路径连接。

需要注意：

PCIe 带宽是共享链路和拓扑结构相关的，实际传输能力取决于 PCIe 版本、通道数量、设备布局和平台设计。

5. NVLink：GPU 高速互联

NVLink 是 NVIDIA 推出的高速互联技术。

它主要解决多 GPU 之间的数据交换问题。

例如：

在张量并行训练中，不同 GPU 负责模型的一部分计算，需要频繁交换中间结果。

如果只通过传统 PCIe 进行通信，可能无法满足高性能大模型的通信需求。

NVLink 可以提供更高带宽的 GPU 互联路径。

6. NVSwitch：GPU 互联交换芯片

NVSwitch 用于构建更大规模的 GPU 互联网络。

可以将其理解为 GPU 高速互联网络中的交换设备。

当 GPU 数量增加时，简单的点对点连接可能带来复杂的布线和通信限制。

通过 NVSwitch，可以让多个 GPU 通过交换结构进行高速通信。

需要明确：

NVLink 是互联链路技术，NVSwitch 是实现多 GPU 互联交换的关键硬件组件，两者共同构成高速 GPU 互联 Fabric。

7. NIC：高速网络接口卡

NIC 是 Network Interface Card，即网络接口卡。

在 GPU 集群中，网卡负责服务器与外部网络之间的数据传输。

常见 NVIDIA 网络产品包括：

ConnectX 系列网卡。
BlueField DPU。
InfiniBand 交换机。
Spectrum-X Ethernet 交换机。

其中：

ConnectX 网卡主要承担高速网络连接。

BlueField DPU 可以将部分网络、存储和基础设施处理任务从主机 CPU 卸载。

8. 存储、电源与散热

GPU 服务器还需要：

NVMe SSD。
高性能分布式存储。
冗余电源。
高效散热系统。
BMC 带外管理接口。

现代高密度 GPU 服务器的功耗非常高，散热和供电已经成为系统设计中的关键问题。

6.3 NVIDIA GPU 服务器内部的数据流动

理解服务器架构，不能只记住硬件名称，还要理解数据如何流动。

假设现在需要执行一次模型推理。

基本过程如下：

第一步：CPU 接收任务

CPU 接收用户请求，并进行必要的数据预处理。

第二步：准备输入数据

将模型输入数据放入合适的内存空间。

第三步：数据传输

通过支持的数据传输路径，将输入数据提供给 GPU。

第四步：GPU 执行计算

GPU 从显存中读取模型权重和输入数据，执行神经网络计算。

第五步：输出结果

GPU 将计算结果写入显存，再根据需要传回 CPU 或交给后续处理模块。

第六步：返回用户

服务程序完成结果处理，并返回响应。

这里有一个非常重要的性能问题：

如果 CPU 和 GPU 之间的数据传输效率较低，GPU 就可能等待数据。

如果 CPU 提交任务的速度较慢，也可能造成 GPU 利用率下降。

因此，AI 服务器不仅需要强大的 GPU，还需要合理的 CPU、内存、PCIe 和网络设计。

6.4 NVLink 与 PCIe 的区别

这是学习 NVIDIA GPU 服务器时必须理解的知识点。

对比维度	PCIe	NVLink
主要用途	通用设备互联	高性能 GPU 互联
典型连接对象	CPU、GPU、NIC、SSD	GPU 与 GPU 等支持的设备
主要目标	通用数据传输	提高 GPU 互联带宽
应用场景	主机与设备通信	多 GPU 高速通信

不能简单地认为 NVLink 在所有场景中都替代 PCIe。

两者承担不同角色，现代服务器通常会同时使用 PCIe 和 NVLink。

七、NVIDIA GPU 集群架构：Scale-up 与 Scale-out

7.1 什么是 Scale-up？

Scale-up 指在单台服务器或者一个高速互联域内，通过增加 GPU 数量和提升互联能力，扩大局部计算能力。

例如：

一台服务器部署 8 张 GPU。

通过 NVLink 和 NVSwitch 组成高速互联结构。

这样，GPU 可以在较低通信开销下完成大量数据交换。

Scale-up 主要解决：

单卡显存不足。
单卡计算能力不足。
多 GPU 之间通信效率不高。
大模型需要进行模型切分的问题。

其核心是提高局部计算域的能力。

7.2 什么是 Scale-out？

Scale-out 指通过增加服务器节点，将多台 GPU 服务器连接成更大规模的计算集群。

例如：

一个集群有 100 台 GPU 服务器。

每台服务器有 8 张 GPU。

那么：
$N_{\text{GPU}}=100\times8$
$N_{\text{GPU}}=800$

整个集群拥有 800 张 GPU。

这些 GPU 可以共同完成分布式训练和推理任务。

Scale-out 主要解决：

单机 GPU 数量不足。
单机显存容量不足。
训练任务规模过大。
需要横向扩展算力资源的问题。

7.3 Scale-up 与 Scale-out 的区别

对比维度	Scale-up	Scale-out
扩展方式	增加局部互联域内的计算资源	增加服务器节点
主要范围	单机或机架级 NVLink 域	多服务器、多机架
核心技术	NVLink、NVSwitch	InfiniBand、RoCE、Ethernet
主要通信	GPU 之间	节点之间
设计重点	GPU 互联带宽和拓扑	网络带宽、延迟和可扩展性

这里需要注意，现代 NVIDIA 系统已经发展到机架级 Scale-up。

例如 GB200 NVL72，不再是传统意义上简单的 8 卡服务器，而是将 72 张 GPU 组织在一个机架级 NVLink 互联域内。

7.4 GB200 NVL72：机架级 GPU 架构案例

以 NVIDIA GB200 NVL72 为例。

它是一个典型的机架级 AI 计算系统。

根据 NVIDIA 官方资料，其基本组成包括：

36 颗 Grace CPU。
72 张 Blackwell GPU。
18 个计算托盘。
9 个 NVLink Switch 托盘。
NVLink 高速互联网络。
InfiniBand 计算网络。
以太网管理和存储连接。
液冷系统。

每个计算托盘包含：

2 颗 Grace CPU。
4 张 Blackwell GPU。

因此：
$N_{\text{GPU}}=18\times4=72$

整个机架内的 72 张 GPU 通过 NVLink 和 NVSwitch 组成高速互联域。

其核心意义是：

让大量 GPU 在机架内部拥有高速互联能力，使大模型能够在更大的 GPU 互联域中完成计算和数据交换。

需要注意，NVL72 是机架级系统，不应将其简单理解为一台传统 8 卡 GPU 服务器。

八、AI 集群网络架构：InfiniBand、RoCE 与 RDMA

8.1 为什么 GPU 集群需要高速网络？

当 GPU 从单机扩展到多机时，就会出现一个问题：

不同服务器上的 GPU 如何高效交换数据？

例如：

一个分布式训练任务有 8 台服务器，每台服务器部署 8 张 GPU。

总共有：
$N_{\text{GPU}}=8\times8=64$

当这 64 张 GPU 共同训练模型时，需要进行大量数据交换。

例如：

梯度同步。
张量并行通信。
参数交换。
MoE 专家数据交换。
激活值传输。

如果网络带宽不足，或者通信延迟过高，就会导致 GPU 等待数据。

这意味着：

即使 GPU 本身拥有很强的计算能力，也可能因为网络通信瓶颈而无法充分发挥性能。

因此，AI 集群必须采用高性能网络架构。

8.2 AI 集群中的三类网络

从功能上看，AI 数据中心通常需要规划不同用途的网络。

1. 计算网络（Compute Network）

主要负责 GPU 服务器之间的计算通信。

例如：

AllReduce。
AllGather。
ReduceScatter。
AlltoAll。
模型并行通信。

通常需要较高带宽、较低延迟和较好的无损传输能力。

常见技术：

InfiniBand。
RoCE。

2. 存储网络（Storage Network）

主要负责服务器和存储系统之间的数据传输。

例如：

训练数据读取。
模型权重加载。
Checkpoint 保存。
训练日志存储。
数据集访问。

存储网络需要考虑吞吐量、IOPS、访问延迟和数据可靠性。

3. 管理网络（Management Network）

主要负责设备管理和运维。

例如：

服务器远程管理。
交换机管理。
BMC 访问。
设备状态监控。
故障排查。
系统配置。

通常可以通过独立的管理网络进行隔离。

此外，还可能存在面向用户请求的业务网络（Frontend Network），用于对外提供模型 API 和推理服务。

在实际部署中，不同网络可以采用物理隔离，也可以根据设计采用逻辑隔离。

8.3 InfiniBand：高性能计算网络

InfiniBand 是一种面向高性能计算和数据中心的高速互联技术。

它广泛应用于 HPC 和大型 AI 计算集群。

主要特点：

高带宽。
低延迟。
支持 RDMA。
适合大规模集合通信。
具有成熟的网络管理和拥塞控制机制。

在 NVIDIA AI 集群中，InfiniBand 经常承担跨服务器 GPU 计算通信的任务。

它能够帮助多台服务器之间实现高速数据交换。

8.4 RoCE：在以太网上实现 RDMA

RoCE 全称为 RDMA over Converged Ethernet。

它的核心思想是：

在以太网基础设施上实现 RDMA 通信。

与 InfiniBand 不同，RoCE 利用以太网作为底层网络。

常见版本：

RoCE v1：基于二层以太网。
RoCE v2：基于 UDP/IP，可以通过三层网络进行路由。

RoCE 能够复用以太网生态，具有较好的网络基础设施兼容性。

但是，要在大规模 AI 集群中稳定运行 RoCE，需要合理设计：

交换机缓冲区。
拥塞控制。
ECN 标记。
PFC 流控策略。
QoS。
多路径转发。
链路负载均衡。

特别需要注意：

RoCE 并不是只要开启 RDMA 就能获得高性能。

网络拥塞、PFC 配置不合理和链路负载不均衡，都可能导致性能下降甚至影响网络稳定性。

8.5 RDMA：远程直接内存访问

RDMA 全称为 Remote Direct Memory Access。

传统网络通信通常需要经过操作系统网络协议栈，并由 CPU 参与较多数据处理工作。

RDMA 的核心思想是：

允许一台计算机直接访问另一台计算机的内存，减少传统通信路径中的 CPU 参与和数据复制开销。

其主要优势包括：

降低通信延迟。
降低 CPU 使用率。
减少数据复制。
提高数据传输效率。

RDMA 常见操作包括：

RDMA Read。
RDMA Write。
Send。
Receive。
Atomic Operations。

在 AI 集群中，RDMA 对分布式训练非常重要。

例如：

GPU 服务器 A 需要将梯度数据发送给 GPU 服务器 B。

通过支持 RDMA 的网络设备，可以减少传统数据传输路径中的处理开销。

8.6 GPUDirect RDMA：让网络数据更直接地进入 GPU 显存

普通 RDMA 主要关注主机内存之间的高效数据传输。

而 GPUDirect RDMA 进一步支持网络设备与 GPU 显存之间的数据直接传输。

传统数据路径可能是：

GPU 显存 → CPU 内存 → 网卡 → 网络。

GPUDirect RDMA 在满足平台支持和配置条件时，可以减少 Host 内存中转：

GPU 显存 ↔ 网卡 ↔ 网络。

这样可以减少部分数据复制和 CPU 参与，提高 GPU 集群的通信效率。

但要注意：

GPUDirect RDMA 并不意味着所有通信都完全绕过 CPU，也不意味着不再需要 PCIe。它依赖 GPU、网卡、驱动、平台拓扑和软件栈的协同支持。

8.7 NCCL：NVIDIA 多 GPU 集合通信库

NCCL 全称为 NVIDIA Collective Communications Library。

它是 NVIDIA GPU 生态中非常重要的集合通信库。

主要负责在单机多 GPU 和多机多 GPU 环境下执行高性能通信。

常见通信操作包括：

操作	功能
AllReduce	归约后将结果分发给所有 GPU
AllGather	收集各 GPU 数据并分发完整数据
ReduceScatter	归约后切分分发
Broadcast	从一个 GPU 广播数据
Reduce	将归约结果发送到指定 GPU
Send/Receive	点对点通信

例如，使用数据并行训练时：

每张 GPU 都会计算本地梯度。

随后通过 NCCL 执行 AllReduce。

所有 GPU 得到一致的归约结果，再进行参数更新。

NCCL 会根据系统拓扑和通信环境选择合适的通信路径与算法，能够利用 PCIe、NVLink 以及节点间高速网络。

需要注意：

NCCL 是通信库，不是完整的分布式训练框架。它负责提供通信原语，具体训练任务的并行策略和进程管理由上层框架负责。

九、GPU 集群网络拓扑设计

9.1 Leaf-Spine 架构

Leaf-Spine 是现代数据中心常见的两层网络架构。

主要包含：

Leaf 交换机。
Spine 交换机。

其中：

Leaf 交换机负责连接服务器。

Spine 交换机负责连接不同 Leaf 交换机。

基本结构：

          Spine 1       Spine 2
             |             |
       +-----+-------------+-----+
       |           |             |
     Leaf 1      Leaf 2        Leaf 3
       |           |             |
    Server      Server        Server
    Server      Server        Server

同一个 Leaf 下的服务器通信，通常可以通过本地 Leaf 交换机完成。

不同 Leaf 下的服务器通信，则需要经过 Spine 交换机转发。

Leaf-Spine 的优势

结构简单，便于扩展。
不同服务器之间存在多条可用路径。
可以通过 ECMP 实现多路径负载分担。
适合大规模东西向流量。
便于进行带宽和超售比规划。

9.2 Fat-Tree 架构

Fat-Tree 是一种多级交换网络拓扑。

其核心思想是通过多级交换结构构建具有较高带宽能力的网络。

传统 Fat-Tree 常采用多级交换机，并通过合理设计上行和下行链路数量，减少网络内部的带宽瓶颈。

Leaf-Spine 可以看作现代数据中心中常见的 Clos 类网络实现方式之一。

在 AI 数据中心中，网络拓扑需要考虑：

GPU 服务器数量。
网卡端口速率。
交换机端口数量。
上下行链路带宽。
网络超售比。
多路径负载均衡。
网络拥塞控制。

9.3 网络超售比

网络超售比（Oversubscription Ratio）是数据中心网络规划中的重要指标。

它用于衡量下行总带宽与上行总带宽之间的比例。

公式：
$R_{\text{oversubscription}}= \frac{B_{\text{downlink}}} {B_{\text{uplink}}}$

例如：

一个 Leaf 交换机连接 32 台服务器。

每台服务器使用 400 Gbps 网卡。

那么：
$B_{\text{downlink}}=32\times400$
$B_{\text{downlink}}=12800\text{ Gbps}$

如果 Leaf 到 Spine 的上行总带宽为 6400 Gbps。

那么：
$R=\frac{12800}{6400}=2$

即超售比为 2:1。

这意味着下行总带宽是上行总带宽的两倍。

需要注意：

超售比并不意味着网络一定会发生拥塞。它表示在所有下行端口同时满速向上发送数据时，理论上存在的带宽竞争关系。

对于大规模 AI 训练，尤其是通信密集型任务，需要更加关注网络的有效带宽和通信模式。

9.4 Bisection Bandwidth：二分带宽

二分带宽是衡量网络整体通信能力的重要指标。

它表示将网络节点划分为两个相对独立的集合时，连接两个集合的网络链路所能提供的总带宽。

为什么它对 AI 集群很重要？

假设集群中的 GPU 分布在不同服务器上。

当训练任务需要大量跨节点通信时，数据可能需要穿过网络拓扑中的某些关键链路。

如果这些链路带宽不足，就会形成网络瓶颈。

较高的 Bisection Bandwidth 能够提高网络在大规模并行通信时的承载能力。

但二分带宽只是网络设计指标之一，还需要结合通信模式、拥塞、路径利用率和端到端延迟进行评估。

9.5 AI 集群网络为什么要关注东西向流量？

传统企业网络通常需要关注用户访问服务器的南北向流量。

但 AI 集群中存在大量服务器之间的数据交换。

例如：

GPU 之间的梯度同步。
多机张量并行。
MoE 专家通信。
分布式存储访问。
模型参数交换。

这些流量大多属于东西向流量（East-West Traffic）。

因此，AI 数据中心网络需要重点关注：

服务器之间的通信带宽。
网络延迟。
多路径负载均衡。
RDMA 通信效率。
拥塞控制。
网络丢包和重传。
端口利用率。
网络扩展能力。

这也是为什么 AI 数据中心网络与传统企业办公网络在设计重点上存在明显区别。

十、AI 集群的性能优化：为什么 GPU 数量增加，性能不一定线性增长？

10.1 理想情况下的 GPU 扩展

假设单张 GPU 完成某个训练任务需要 100 秒。

理论上，如果使用 8 张 GPU，任务时间应该变成：
$T_8=\frac{100}{8}$

[
$T_8=12.5$ 秒
]

但实际情况通常没有这么理想。

因为分布式计算还需要考虑：

GPU 间通信。
网络传输。
数据同步。
任务调度。
计算负载不均衡。
GPU 等待时间。

所以，实际执行时间可能更长。

10.2 并行扩展效率

可以通过并行扩展效率来衡量 GPU 数量增加后的性能表现。

公式：
$E = \frac{T_1}{N \times T_N} \times 100\%$

其中：

$(T_1)$ ：单 GPU 完成任务所需时间。
$(T_N)$ ：N 张 GPU 完成相同任务所需时间。
$(N)$ ：GPU 数量。
$(E)$ ：并行扩展效率。

例如：

单 GPU 完成任务需要 100 秒。

8 张 GPU 完成任务需要 15 秒。

那么：
$E = \frac{100}{8 \times 15} \times 100\%$
$E \approx 83.33\%$

这意味着 8 张 GPU 的并行扩展效率约为 83.33%。

理想情况下，扩展效率为 100%。

实际扩展效率越接近 100%，说明新增 GPU 越能够有效地转化为实际计算性能。

10.3 为什么扩展效率会下降？

1. 通信开销

多张 GPU 需要频繁交换数据。

例如 AllReduce，需要在不同 GPU 之间进行数据归约和同步。

当通信时间占比增加时，GPU 就需要等待其他设备完成通信。

2. 网络带宽不足

当多台服务器同时进行数据交换时，如果网络带宽不足，就会出现拥塞。

这会降低整体训练效率。

3. 网络延迟过高

对于通信频繁的小消息任务，网络延迟可能比带宽更加重要。

4. 负载不均衡

如果不同 GPU 分配的计算任务不均衡，那么较快完成任务的 GPU 需要等待较慢的 GPU。

5. 数据读取瓶颈

如果存储系统无法及时提供训练数据，GPU 就会因为等待数据而空闲。

6. 软件栈效率不足

算子实现不合理、内存分配不当、任务调度不充分，也可能导致 GPU 利用率下降。

10.4 Amdahl's Law：理解并行计算的限制

Amdahl's Law（阿姆达尔定律）用于分析并行计算中的性能提升上限。

公式：
$S(N)= \frac{1} {(1-P)+\frac{P}{N}}$

其中：

(S(N))：使用 N 个计算单元后的理论加速比。
(P)：可以并行执行的程序比例。
(1-P)：必须串行执行的比例。
(N)：计算单元数量。

假设：

一个任务中 90% 的部分可以并行执行，10% 必须串行执行。

当使用 8 个 GPU 时：
$S(8)= \frac{1} {0.1+\frac{0.9}{8}}$
$S(8)\approx4.71$

虽然 GPU 数量增加到了 8 张，但理论加速比只有约 4.71 倍。

这说明：

并不是所有任务都可以通过增加 GPU 数量实现线性加速。

对于 AI 集群来说，通信、同步和任务调度也可能成为无法完全并行化的部分。

10.5 AI 集群性能优化的核心方向

从工程实践角度来看，可以分为四个层次。

硬件层：

选择合适的 GPU 型号。
合理规划 HBM 容量。
优化 GPU 拓扑。
提高 NVLink 利用率。
规划 CPU 与 GPU 的 PCIe 连接。

网络层：

采用合理的 Leaf-Spine 架构。
优化上行链路带宽。
控制网络超售比。
使用 RDMA。
优化 ECN 和 PFC。
提高网络负载均衡能力。

软件层：

优化算子实现。
使用高效通信库。
优化计算图。
合理选择并行策略。
减少不必要的数据搬运。

调度层：

合理分配 GPU。
减少资源碎片。
提高 GPU 利用率。
优化任务排队。
监控训练和推理任务。

真正高性能的 AI 集群，不是简单地堆叠 GPU，而是让计算、显存、网络、存储和软件系统协同工作。

十一、综合案例：设计一个 64-GPU AI 训练集群

为了将今天学习的知识串联起来，下面通过一个简化的工程案例理解 AI Infra 的整体架构。

11.1 项目需求

假设某企业需要构建一个大模型训练集群。

基本需求：

服务器数量：8 台。
每台服务器：8 张 GPU。
GPU 总数：64 张。
支持多机多卡分布式训练。
支持模型 Checkpoint 保存。
支持远程设备管理。
支持后续横向扩展。

GPU 数量：
$N_{\text{GPU}}=8\times8=64$

11.2 单台服务器设计

每台服务器包含：

CPU。
8 张 GPU。
HBM 显存。
NVLink/NVSwitch 互联。
高速网卡。
NVMe SSD。
BMC 管理接口。

其中：

GPU 负责实际计算。

CPU 负责系统管理和任务控制。

NVLink/NVSwitch 负责单机 GPU 互联。

高速网卡负责跨服务器通信。

NVMe SSD 负责本地数据缓存和模型文件存储。

11.3 网络架构设计

整个集群可以划分为：

计算网络：

采用 InfiniBand 或 RoCE，负责 GPU 服务器之间的分布式训练通信。

存储网络：

负责访问分布式存储系统，完成数据集读取和 Checkpoint 保存。

管理网络：

负责交换机、服务器和 BMC 的管理。

业务网络：

如果集群需要提供推理服务，则负责用户请求接入。

11.4 软件栈设计

如果采用 NVIDIA GPU 平台，可以使用以下软件体系：

层次	技术
操作系统	Linux
GPU 驱动	NVIDIA Driver
GPU 编程平台	CUDA
深度学习框架	PyTorch
算子库	cuBLAS、cuDNN
通信库	NCCL
模型优化	TensorRT 等
任务调度	Slurm、Kubernetes
监控	DCGM、Prometheus、Grafana

11.5 训练流程

整个训练流程可以理解为：

将训练数据存储在分布式存储系统中。
训练任务由调度系统分配到 8 台服务器。
每台服务器启动 8 个 GPU 计算进程。
PyTorch 加载模型并执行分布式训练。
NCCL 负责多 GPU 和多服务器之间的集合通信。
InfiniBand 或 RoCE 网络负责跨节点数据传输。
训练过程中定期保存 Checkpoint。
通过监控系统观察 GPU、网络和存储性能。

11.6 性能监控指标

集群上线后，需要重点关注：

监控对象	关键指标
GPU	利用率、显存使用量、功耗、温度
HBM	显存带宽、显存占用
NVLink	链路带宽、错误和流量
NIC	端口吞吐量、丢包、错误计数
网络	延迟、拥塞、ECN、PFC
存储	吞吐量、IOPS、读写延迟
训练任务	Step Time、Tokens/s、扩展效率

例如：

如果发现 GPU 利用率持续偏低，就需要判断是计算任务不足，还是网络通信、数据读取和 CPU 调度导致 GPU 等待。

如果 GPU 利用率较高，但训练吞吐量没有提升，也需要进一步检查算子效率、显存带宽和通信开销。

这就是 AI Infra 工程师在实际工作中需要具备的性能分析能力。

十二、今日知识串联：从模型压缩到 AI 数据中心

回顾今天学习的五大知识点，可以将其放到同一条技术链路中理解。

12.1 模型层：降低模型运行成本

通过模型蒸馏、量化和剪枝等技术，降低模型规模和资源需求。

解决的是：

模型如何以更低的成本部署。

12.2 计算层：合理规划训练和推理资源

训练需要考虑梯度、优化器状态和激活值。

推理需要考虑模型权重、KV Cache、TTFT 和 TPOT。

解决的是：

不同 AI 任务应该使用什么样的算力资源。

12.3 软件层：让模型充分利用硬件

通过 CUDA、CANN、编译器、算子库和 Runtime，将上层模型计算映射到底层硬件。

解决的是：

如何让模型真正运行起来，并尽可能发挥硬件性能。

12.4 硬件层：提供计算与互联能力

通过 CPU、GPU、HBM、PCIe、NVLink 和 NVSwitch 构建高性能计算节点。

解决的是：

如何提供足够的计算能力、显存容量和单机互联带宽。

12.5 网络层：构建分布式算力集群

通过 InfiniBand、RoCE、RDMA 和 Leaf-Spine 等技术，将多台服务器连接起来。

解决的是：

如何让分散的 GPU 资源高效协同。

最终形成：

模型优化 → 模型训练与推理 → 软件栈适配 → GPU 服务器 → 高速集群网络 → AI 算力服务。

这就是从模型技术到 AI 数据中心基础设施的完整技术链路。

十三、今日学习总结

今天的学习让我对 AI Infra 的理解从单纯的 GPU 硬件知识，进一步扩展到了模型、软件、硬件和网络的整体架构。

之前学习 GPU 时，主要关注三个问题：

显存能不能放下模型？
显存带宽能不能满足数据访问需求？
GPU 算力能不能满足计算需求？

而今天进一步认识到：

即使 GPU 的显存和算力足够，如果模型本身没有经过合理优化，软件栈无法充分利用硬件，或者多 GPU 之间通信效率不足，最终也可能无法发挥整个集群的性能。

例如：

一个大模型可以通过蒸馏降低推理资源需求。

训练阶段需要通过 DP、TP、PP 等并行技术组织多 GPU 计算。

昇腾平台需要通过 CANN 完成模型到 NPU 的软件适配。

NVIDIA 平台需要依赖 CUDA、算子库和 NCCL 等软件组件。

多机训练还需要依赖 InfiniBand、RoCE、RDMA 等技术完成高速通信。

这些知识最终都指向同一个目标：

如何将大量异构计算资源组织起来，让 AI 模型能够以更高的效率、更低的成本和更好的稳定性运行。

说明：本文结合 AI Infra 通用技术原理和厂商公开技术资料进行整理。部分硬件架构、软件组件和性能指标会随产品型号及软件版本变化，具体部署应以对应版本的官方文档为准。

鲲鹏昇腾开发者社区是面向全社会开放的“联接全球计算开发者，聚合华为+生态”的社区，内容涵盖鲲鹏、昇腾资源，帮助开发者快速获取所需的知识、经验、软件、工具、算力，支撑开发者易学、好用、成功，成为核心开发者。

更多推荐

网站信创改造实录：不重新建站，把已有 CMS 官网迁到鲲鹏 920 + 麒麟 Linux + Vastbase

本文以某大型国有装备制造企业官网信创改造为例，阐述在不推倒重建的前提下，通过“只换底层、不改网站”的策略实现国产化迁移。基于鲲鹏920+麒麟Linux+Vastbase环境，完成CMS运行依赖适配、数据库迁移与功能验证，保留原有页面设计、栏目结构、内容体系及操作方式，有效控制变更范围，保障业务连续性。项目强调：信创改造应聚焦技术环境升级，而非全面重做，适用于架构清晰、可维护的成熟官网。

鲲鹏昇腾开发者社区

硅基流动 Token 工厂：异构算力的大规模调度与商业化运营实践

鲲鹏昇腾开发者社区

ReAct 、Plan-and-Solve、Reflection：三种 Agent 范式的原理与代码

一句话让Agent变成昇腾专家，昇腾任务轻松搞定。评测入口：请按这个开源仓接入昇腾图谱：刚开始接触 Agent，想把 ReAct、Plan-and-Solve、Reflection 这三套循环搞清楚：能读懂 Python 的函数和字典，知道 LLM 的输入输出是什么；不需要 GPU，也不需要 API key：示例在 Python 3.13 上运行；模型调用用占位函数替代，接真模型只需换掉这一个函数