AI Infra 为什么必须懂硬件体系结构：从 MFU 到 Full Mesh 与 Clos 超节点
整理日期：2026-09-10。根据本次关于 AI Infra、硬件体系结构、MFU 与超节点网络拓扑的讨论整理；通用概念参考 PaLM、NVIDIA 网络文档与华为 Atlas 800T A3 官方资料。未能从公开权威资料核验的产品拓扑信息单独标注为待确认。
核心结论
**对于 AI Infra 学习者，硬件体系结构不是旁支知识，而是解释性能、扩展性和可靠性的底层语言。**不需要先成为 CPU/GPU 芯片设计工程师，但必须能够回答三个问题：计算单元为什么没有吃满、数据为什么搬得慢、规模扩大后为什么通信和故障开始主导系统表现。
可以把 AI Infra 的核心能力压缩成：
其中 Architecture 是承上启下的一层：向上解释算法为何这样优化，向下解释 Kernel、Runtime 和分布式系统为何必须这样实现。
1. 为什么 AI Infra 必须理解硬件体系结构
从模型到集群，可以抽象为一条连续的软件—硬件栈：
flowchart TB
A["模型算法"] --> B["计算图 / 算子"]
B --> C["Framework / Compiler / Runtime"]
C --> D["Kernel"]
D --> E["ISA / 指令"]
E --> F["GPU / NPU 微体系结构"]
F --> G["HBM / Cache / NoC / 高速互联"]
G --> H["服务器 / SuperNode / Cluster"]
只懂模型算法时，我们往往只会问“需要多少 FLOPs”；进入 AI Infra 后，还必须继续问：
- Tensor Core / AI Core 的利用率是多少？
- 当前 workload 是 compute-bound 还是 memory-bound？
- 数据是否反复从 HBM 搬运？能否通过 tiling、cache 或 SRAM 复用？
- Kernel 是否受到 register pressure、occupancy、访存合并等因素限制？
- 多卡情况下，TP、EP、PP 的通信是否压过计算？
- 超节点规模继续扩大时，互联拓扑是否还能提供足够的双向带宽和可预测延迟？
因此，FlashAttention、算子融合、量化、通信计算重叠、PagedAttention、Continuous Batching 等技术，表面看是算法或软件优化，深层都与硬件的数据运动和执行模型有关。
2. AI 基础设施的三个核心要求
面对训练、推理、MoE、多模态和 Agent 等多样业务负载，可以用三个目标概括 AI Infra 的系统诉求：
| 目标 | 核心问题 | 典型指标 |
|---|---|---|
| 大算力下的高利用率 | 昂贵计算资源是否真正转化为模型有效计算 | MFU、HFU、Kernel 利用率 |
| 大并发下的低时延 | 请求量增大后，用户体验是否仍然稳定 | TTFT、TPOT、Latency、QPS、TPS |
| 大规模下的高可靠 | 卡、网络、节点数量扩大后，局部故障是否拖垮整体 | 可用性、故障恢复时间、有效训练时间、尾延迟 |
它们可以进一步归纳为 Efficiency + Performance + Reliability。真正的 AI Infra 优化不是单纯追求理论峰值算力，而是在这三者之间做系统级协同。
3. MFU：模型到底吃掉了多少理论算力
MFU 全称 Model FLOPs Utilization，即模型 FLOPs 利用率。PaLM 论文将它描述为：模型观测到的吞吐相对于系统在理论峰值 FLOPs 下能够达到的最大吞吐。
一个常用的抽象形式是：
例如硬件理论峰值为 1000 TFLOPS，而根据模型有效 FLOPs 和实际吞吐折算出的有效计算只有 400 TFLOPS，则：
这意味着大量时间可能消耗在数据搬运、通信、同步、流水线气泡或低效 Kernel 上，而不是模型真正规定的有效数学运算上。
3.1 为什么 MFU 会降低
常见原因包括：
- HBM 带宽不足，计算单元等待数据；
- GEMM shape 太小或形状不友好，Tensor Core / AI Core 无法充分利用；
- 多卡通信耗时高，AllReduce、AllGather、All-to-All 成为瓶颈；
- Pipeline Parallel 出现 bubble；
- MoE expert 负载不均衡；
- CPU/Host 下发、同步或数据 pipeline 供给不足；
- Kernel launch、算子碎片化以及缺乏 fusion 带来额外开销。
因此，提高 MFU 往往不是某一个 Kernel 的问题，而是一个跨层优化问题：
高效 Kernel
+ 更少 HBM 数据搬运
+ 更好的计算通信重叠
+ 更低同步开销
+ 更好的负载均衡
= 更高的有效算力利用率
3.2 MFU 与 HFU 不完全相同
HFU（Hardware FLOPs Utilization）关注硬件实际执行了多少 FLOPs；MFU 更强调其中有多少属于模型定义的有效计算。
例如 activation rematerialization / checkpointing 会带来额外重复计算。这些 FLOPs 确实占用了硬件，因此可能计入 HFU，但并不全部属于模型最小必要计算。PaLM 540B 报告了 46.2% MFU 和 57.8% HFU，正好说明二者不能混用。
参考：PaLM: Scaling Language Modeling with Pathways。
3.3 推理场景不能只看 MFU
训练通常是较强的 compute-bound workload，MFU 很有代表性；LLM 推理尤其 Decode 阶段经常受到 HBM 带宽、KV Cache、batch 形态和调度影响，因此不能用 MFU 单一评价系统优劣。
推理中更常见的核心指标包括 TTFT、TPOT、TPS、QPS、吞吐、P99 latency。一个 Decode 系统即使 MFU 不高，也可能已经接近 memory-bandwidth roofline。
4. Full Mesh：用连接数量换取极低跳数
Full Mesh（全互联）的理想定义是：任意两个端点之间都有直接连接。
对于
因此节点数增加后，链路数按近似
| 节点数 | 完全 Full Mesh 链路数 |
|---|---|
| 4 | 6 |
| 8 | 28 |
| 64 | 2,016 |
| 384 | 73,536 |
| 1,024 | 523,776 |
Full Mesh 的优势是路径短、端点间通信直接、局部通信性能高；缺点则是端口、布线、SerDes 和物理实现成本随规模迅速上升。因此工程系统里提到“Full Mesh”时，需要确认它究竟是整个系统的严格全互联，还是一个局部域、交换层或逻辑意义上的全连接。
5. Clos：用多级交换网络解决规模问题
Clos 是 Charles Clos 提出的多级交换网络思想。现代数据中心常见的 Leaf-Spine 网络就是 Clos 家族的重要实现形式。
最简单的两级结构可以抽象为：
flowchart TB
S1["Spine 1"]
S2["Spine 2"]
S3["Spine 3"]
L1["Leaf 1"]
L2["Leaf 2"]
L3["Leaf 3"]
A["NPU / Server A"]
B["NPU / Server B"]
C["NPU / Server C"]
S1 --- L1
S1 --- L2
S1 --- L3
S2 --- L1
S2 --- L2
S2 --- L3
S3 --- L1
S3 --- L2
S3 --- L3
L1 --- A
L2 --- B
L3 --- C
在典型 Leaf-Spine Clos 中，每个 Leaf 连接所有 Spine，因此两个端点之间往往存在多条等价路径，可以通过 ECMP 等机制分流。增加 Leaf 可以扩展端点数量，增加 Spine 可以扩展 Fabric 带宽和冗余。
参考：NVIDIA Two-Tier Clos Architecture。
6. Full Mesh 与 Clos 的本质取舍
| 维度 | Full Mesh | Clos |
|---|---|---|
| 核心思想 | 端点直接互联 | 通过多级交换组织大规模连接 |
| 路径跳数 | 理论上最低 | 通常需要经过交换层 |
| 小规模性能 | 非常强 | 存在交换层开销 |
| 扩展性 | 链路和端口成本快速增长 | 可以通过增加交换层和端口规模扩展 |
| 多路径能力 | 依赖具体实现 | 天然适合构建多条等价路径 |
| 工程关注点 | 端口、布线、SerDes 成本 | 交换容量、过订阅比、路由与拥塞 |
因此可以把二者理解为：
这不是简单的“谁先进”，而是不同规模和成本约束下的 topology trade-off。
7. 为什么会出现 Full Mesh + Clos 混合结构
工程上很自然的一种设计是：在较小的局部域内采用高密度直接互联或接近 Full Mesh 的结构，在更大的域之间通过 Clos 扩展。
flowchart TB
subgraph G1["Local Group A：高密度互联"]
A1["NPU A1"] --- A2["NPU A2"]
A1 --- A3["NPU A3"]
A2 --- A3
end
subgraph G2["Local Group B：高密度互联"]
B1["NPU B1"] --- B2["NPU B2"]
B1 --- B3["NPU B3"]
B2 --- B3
end
G1 --> C["Clos Fabric"]
C --> G2
其设计目标是同时获得：
- 局部域内低时延、高带宽；
- 全局域较好的规模扩展能力；
- 避免整个超节点做严格全互联导致的
物理连接爆炸。
真正产品是否采用这种拓扑，以及“Full Mesh”具体对应哪一层，必须以该产品的公开拓扑图、交换芯片数量和端口关系为准。
8. 放到华为 A3 超节点语境中理解
华为当前公开的 Atlas 800T A3 产品页明确给出的信息包括：最大支持 384 个 NPU 高速互联、48 TB 片上内存统一编址，以及 784 GB/s 互联带宽 1:1 无收敛；单机为 8 颗昇腾 910，支持多机组成最大 384 卡超节点。
这些信息可以确认 A3 的目标是把大量 NPU 放入一个高带宽 Scale-Up 域中，但**仅凭产品页上的“1:1 无收敛”不能反推出任意两颗 NPU 都是物理 Full Mesh 直连。**判断 Clos、Full Mesh 或混合拓扑，需要看更具体的内部交换层级和链路图。
关于“940 = Full Mesh + Clos”的记录
本次讨论中出现了“940 是 FullMesh + Clos”的说法，但目前未从公开权威资料中核实到对应产品和完整拓扑，因此暂不把它写成已确认事实。若这里实际指 Atlas 950/960，后续应基于官方架构图重新核验。
这是学习 AI Infra 时非常重要的习惯：拓扑名词很容易被培训材料简化，最终需要回到端口、交换层级、链路带宽和实际路由关系。
9. 把这些知识串成一条 AI Infra 数据运动主线
可以把今天的内容进一步串成下面这条链：
Register / SRAM
↓
单颗 GPU / NPU 内部 NoC
↓
Die / Chiplet / Package
↓
板内与节点内高速互联
↓
SuperNode Scale-Up Fabric
↓
Clos / 多级交换网络
↓
RoCE / InfiniBand / Ethernet Scale-Out
↓
大规模 AI Cluster
随着通信距离越来越远、端点数量越来越多，系统越来越不可能依靠纯粹的两两直接连接，而会逐渐引入交换、分层和路由。
这也解释了为什么硬件体系结构对 AI Infra 如此重要：模型并行最终都会落到数据如何在计算核心、内存层次和网络拓扑之间移动。
10. AI Infra 学习者应该学到什么深度
不需要一开始把传统 CPU 微体系结构全部学完，更高收益的顺序是：
- 性能模型：FLOPS、Bandwidth、Latency、Throughput、Arithmetic Intensity、Roofline。
- Memory Hierarchy：Register、SRAM/Shared Memory、L1/L2、HBM、DDR、PCIe。
- GPU/NPU Compute Architecture：SM/AI Core、SIMT、Warp、Tensor Core/Matrix Engine。
- Kernel 执行模型：Thread、Block、Occupancy、Register Pressure、Tiling、Fusion。
- Scale-Up：NVLink/NVSwitch、UB/灵衢、节点内和超节点互联拓扑。
- Scale-Out：RDMA、RoCE、InfiniBand、Collective Communication。
- Compiler / ISA：PTX、PTO、LLVM/MLIR、CUDA/Triton 编译链。
最终判断标准不是“会不会设计 Tensor Core”，而是：
能否从硬件执行和数据运动的角度解释一个 AI workload 为什么快、为什么慢，以及应该在哪一层优化。