10. Domestic AI Chips Overview | 算力现状与替代方案 (AI Chips Overview)
难度： Medium | 标签： 系统架构, 异构算力, 拓展阅读 | 目标人群： 核心 Infra 与算子开发
在真实的大模型基建环境中，虽然 NVIDIA 的硬件体系长期占据主导地位，但随着全球供应链的变化和算力需求的多样化，各类异构 GPU（如 AMD、国内新兴的高性能 GPGPU 厂商）在智算中心的部署比例正逐步上升。 对于 AI Infra 工程师而言，了解主流 GPU 的架构特点以及跨硬件平台的生态适配策略，是一项非常重要的架构设计能力。
先抓一组量级直觉：
| 平台 | 显存 | 带宽 | FP16 Tensor 算力 | 软件生态 |
|---|---|---|---|---|
| NVIDIA H100 SXM | 80 GB | 3.35 TB/s | 1,979 TFLOPS | CUDA，成熟 |
| AMD MI300X | 192 GB | 5.3 TB/s | 2,614.9 TFLOPS（带稀疏） | ROCm / HIP，追赶中 |
| Google TPU v5 系列 | 按版本不同 | 按版本不同 | 按版本不同 | XLA / JAX，专用 |
| 国产 GPGPU（典型） | 32-64 GB | 1-2 TB/s | 100-300 TFLOPS 量级 | 生态仍在打磨 |
这里的核心结论不是“哪家纸面规格最高”，而是“硬件规格、软件栈成熟度和分布式通信稳定性需要一起看”。
本节如何和后续章节配合
这一节同样不单独配 Notebook，它更像 Chapter 1 的扩展阅读：
- 先看本文，建立不同算力路线、软件栈和迁移成本的直觉
- 再回看 Chapter 1 前面的 GPU、通信、编译和异构调度章节，理解它们为什么决定迁移难度
- 如果后面要做多平台部署，这一页负责告诉你有哪些硬件路线可选，前面的章节负责告诉你迁移时哪里最容易出问题
这节的目标不是让你给所有国产芯片排优劣，而是让你能判断：迁移是算子对齐问题、通信问题，还是数值对齐问题。
相关阅读:
本节为纯理论与常识科普，暂无强关联的代码实战，推荐作为基石阅读。
Q1：除了 NVIDIA 体系这一重要参照，目前在数据中心和智算集群中还有哪些重要的 GPU/GPGPU 路线？
点击展开查看解析
除了大家都熟知的 NVIDIA (A100/H100 + CUDA 生态) 之外，工业界中目前主要有以下几条具有代表性的算力路线：
AMD 生态 (如 MI300X):
- 架构特点：拥有极高的显存容量和内存带宽，其底层架构 (CDNA) 同样为高度并行的 GPGPU 设计。
- 软件栈：ROCm (Radeon Open Compute) 平台。AMD 官方文档明确说明，ROCm 具备 HIP 和 CUDA-to-HIP 的迁移路径，能把一部分 CUDA 代码平移过去，但这不等于“低成本迁移”。在真实工程中，算子库、通信库和调试链路仍需要逐项验证。
高性能 GPGPU 新势力 (如摩尔线程 Moore Threads):
- 架构特点：采用全功能 GPU 架构（如 MUSA 架构），不仅强调 AI 训练和推理的算力，同时也兼顾传统的图形渲染与通用科学计算。
- 软件栈：提供兼容主流深度学习框架的软硬件平台。需要注意的是，这类平台的硬件规格与软件栈成熟度通常不同步，生产环境前需要做充分验证。
专攻全精度算力的新兴 GPGPU (如沐曦 MetaX):
- 架构特点：同样走高性能通用 GPU (GPGPU) 路线，通常强调提供完整的高低精度算力（如 FP64/FP32 到 FP16/INT8 等）。
- 定位：旨在打造能够较平滑接入现有 AI 训练集群和高性能计算 (HPC) 节点的通用加速核心。这里更稳妥的判断方式是把它们视作“可选项”，而不是“可替代 NVIDIA 的即插即用方案”。
定制化 ASIC/NPU 路线 (如 Google TPU 或部分专有 AI 芯片):
- 架构特点：放弃如图形处理等无关功能，内部核心往往是一个巨大的矩阵乘法阵列（如 TPU 的 Systolic Array 脉动阵列）。
- 定位：在特定的网络结构或编译图下能达到极高的计算效率，但通用性不如 GPGPU。
风险提示：新兴 GPGPU 产品在硬件规格上正在快速追赶，但软件栈（编译器成熟度、算子库完备性、分布式通信稳定性）与 NVIDIA 的 CUDA 生态仍有明显差距。生产环境部署前需要做充分验证，不要只看 TFLOPS。
Q2：作为 Infra 工程师，将大模型训练任务从现有的 NVIDIA 集群迁移到其他异构 GPU 平台时，主要的技术挑战是什么？
点击展开查看解析
跨硬件平台的迁移从来不是简单的“换张显卡”，它涉及整个软件系统栈的重构。核心的技术挑战集中在以下三个层面：
1. 底层算子对齐与计算图融合 (Kernel Alignment & Graph Fusion)
- 原生 PyTorch 的大模型代码深度绑定了特定硬件优化的算子（例如严重依赖 NVIDIA PTX 汇编的
FlashAttention或xFormers）。- 痛点：目标异构 GPU 可能暂时缺乏同等优化水平的手工算子。如果回退到用基础小算子（如单独调用加法、乘法）拼接，会导致明显的 Memory Bound 问题。
- 解法：通常需要依赖 AI 编译器（如支持多后端的 OpenAI Triton、Apache TVM 或厂商自研编译器）在计算图层面进行算子融合 (Operator Fusion) 和目标机器码的自动生成。
- 迁移成本直觉：如果只是纯 Python / 高层 PyTorch 模型，很多代码几乎可以直接跑；但只要碰到自定义 CUDA kernel、FlashAttention、xFormers、Apex 这类强依赖 CUDA 的算子，往往就会进入“重写 / 替代 / 调参”阶段。工程上常见的改动量通常是数百到数千行，迁移周期可能是数周到数月，具体取决于自定义算子和测试覆盖度。
2. 集合通信库的替换 (Collective Communication)
- 万卡规模的大模型训练通常非常依赖高效的网络通信原语（如 NVIDIA 的 NCCL）。
- 痛点：异构 GPU 平台通常需要提供功能上可替代、性能上尽量接近 NCCL 的通信库（例如针对其私有互联协议优化的通信实现）。
- 解法：该通信库需要尽量兼容 PyTorch 的
torch.distributed协议。否则，在执行张量并行 (TP) 的前反向同步或 ZeRO-3 的参数切片拉取时，可能引发严重阻塞，甚至出现网络死锁。 - 补充说明：通信库不是“能跑就行”，还要看拓扑感知、带宽利用率和故障恢复能力。单纯把 NCCL 替换掉，不意味着性能就能自动对齐。
3. 算术精度与数值对齐 (Numerical Alignment)
- 不同厂商的硬件在底层乘加运算 (FMA) 单元的设计上存在微小差异（例如不同的硬件舍入策略、是否原生支持 BF16、对 NaN/Inf 的处理逻辑等）。
- 痛点：在百亿参数的深层网络中，微小的数值计算差异可能会被逐层放大，最终导致迁移后的训练 Loss 不收敛，或者在训练中期频繁出现数值尖峰 (Spike)。
- 解法：要求 Infra 团队具备极强的调试追踪能力，建立自动化的逐层对齐机制，找出偏离标准浮点模型 (Golden Reference) 的具体网络层或算子并进行修正。
Q3：如果真的要评估“该不该迁移”，应该怎么做决策？
点击展开查看解析
可以把问题拆成“值得迁移吗”和“能不能稳定迁移”两层：
| 场景 | 倾向 |
|---|---|
| 成本敏感、想降低单机采购压力 | 可以评估迁移 |
| NVIDIA 供给不稳定或有供应链风险 | 可以评估迁移 |
| 主要是推理部署，且模型结构相对稳定 | 可以评估迁移 |
| 追求较高训练性能 | 通常先保留 NVIDIA 主力 |
| 依赖大量第三方 CUDA 库 | 暂缓迁移 |
| 团队没有足够的算子 / 通信调试资源 | 暂缓迁移 |
⚠️ 常见误区
- 硬件规格高，不代表训练速度一定更快；软件栈成熟度同样重要
- CUDA 代码通过工具自动转换，不代表就能直接稳定上线
- ROCm / HIP 具备迁移能力，但不等于完全兼容所有边界情况
- 国产 GPGPU 不能被简单视为 NVIDIA 的无缝替代品
- TPU 并不是“覆盖所有任务”，它更适合特定模型和编译图