异构硬件生态——CPU/DPU/NPU 的集群角色 / Roles of CPUs, DPUs, and NPUs in Heterogeneous Clusters
📅 创建时间：2026-06-03 🏷️ 标签：#AI-Infra #集群侧 #异构 #DPU #NPU #CPU #NVIDIA-Grace 📚 前置知识：[[01-gpu-cluster-hardware]]（GPU 集群硬件架构）[[00-cluster-infra-overview]]（集群全景） 📚 相关知识：[[03-gpu-virtualization]]（虚拟化）[[04-job-scheduling]]（调度）[[../training-infra/01-gpu-hardware]]（GPU 硬件基础）
场景：GPU 集群里，CPU 成了新的瓶颈
┌─────────────────────────────────────────────────────────────┐
│ │
│ ML 工程师的困惑： │
│ │
│ 64 张 H100 训练集群，MFU 只有 45%。 │
│ GPU 利用率 100%，显存使用正常，NCCL 通信也正常。 │
│ │
│ Profiler 显示： │
│ → GPU Compute：100%（满载） │
│ → DataLoader：平均等待 2.3 秒/步 │
│ → CPU Data Preprocessing：瓶颈在 CPU │
│ │
│ 根因分析： │
│ → 作业配置：batch_size_per_gpu=8，seq_length=8192 │
│ → CPU 预处理每条样本需要 Tokenizer + Padding │
│ → 64 个 CPU 核心同时处理，互相争抢内存带宽 │
│ → CPU 成了瓶颈，GPU 在等数据 │
│ │
│ 这是"异构"问题： │
│ GPU 再强，也需要 CPU 的配合，CPU 慢了，GPU 也跑不满。 │
│ │
└─────────────────────────────────────────────────────────────┘第1节：GPU 集群中的 CPU 角色
CPU 在集群中的职责
┌─────────────────────────────────────────────────────────────┐
│ CPU 在 GPU 集群中的核心职责 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. 控制平面（Control Plane）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 调度器（Slurm/Kubernetes）→ CPU 执行 │ │
│ │ 作业启动 / 资源分配 / 健康检查 │ │
│ │ CPU 负载低，不易成为瓶颈 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 2. 数据预处理（Data Preprocessing）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ DataLoader → CPU 预处理 → GPU 输入 │ │
│ │ Tokenizer / Augmentation / Format Conversion │ │
│ │ ⚠️ 高频瓶颈：CPU 跟不上 GPU 的数据消费速度 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 3. 存储 IO（Storage I/O）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Checkpoint 读写 / 数据集加载 │ │
│ │ CPU 参与内存拷贝和压缩（如果启用了压缩） │ │
│ │ ⚠️ Checkpoint 可能成为瓶颈 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 4. 梯度更新（Optimizer Step）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ ZeRO-3 的 optimizer step 部分计算 │ │
│ │ Adam 动量更新 / 权重衰减 │ │
│ │ CPU 参与比例低（主要在 GPU 上计算） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘CPU-GPU 互联架构演进
┌─────────────────────────────────────────────────────────────┐
│ CPU-GPU 互联架构演进 │
├─────────────────────────────────────────────────────────────┤
│ │
│ PCIe 时代（V100/A100 主流）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ CPU (x86) ←── PCIe 4.0 ×16 ──→ GPU (HBM2e) │ │
│ │ 64 GB/s 900 GB/s │ │
│ │ │ │
│ │ 问题：CPU-GPU 带宽 < GPU 显存带宽的 1/14 │ │
│ │ 后果：CPU 预处理后的数据传输成为瓶颈 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ NVLink + CpuPaired（过渡）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ CPU (x86) ←── PCIe ──→ NVSwitch ←── NVLink ──→ GPU │ │
│ │ ↑ │ │
│ │ CpuPaired：CPU 和 GPU 配对，减少跨 NUMA 访问 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Grace-Hopper Superchip（新时代）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ ┌──────────┐ ┌──────────┐ │ │
│ │ │ Grace │ ←── NVLink-C2C ──→ │ Hopper │ │ │
│ │ │ CPU │ 900 GB/s (双向) │ GPU │ │ │
│ │ │ 72核 │ │ H100 │ │ │
│ │ └──────────┘ └──────────┘ │ │
│ │ │ │ │ │
│ │ ↓ ↓ │ │
│ │ LPDDR5 HBM3 │ │
│ │ 500 GB/s 3.35 TB/s │ │
│ │ │ │
│ │ 优势：CPU-GPU 带宽提升 10x，数据预处理不再瓶颈 │ │
│ │ 适用：大模型推理、数据密集型训练 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ GH200：2 个 Grace + 1 个 Hopper，CPU 带宽 = GPU 显存带宽 │
│ │
└─────────────────────────────────────────────────────────────┘第2节：DPU——网络的智能卸载
DPU 的定位
┌─────────────────────────────────────────────────────────────┐
│ DPU（Data Processing Unit）的定位 │
├─────────────────────────────────────────────────────────────┤
│ │
│ DPU 是什么： │
│ → 一种新型智能网卡，将网络/存储/安全功能从 CPU 卸载 │
│ → NVIDIA BlueField 系列是 DPU 的代表 │
│ → 可以理解为"网卡 + ARM CPU + 加速器"的组合 │
│ │
│ 为什么需要 DPU： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 传统模式：CPU 处理网络协议栈 │ │
│ │ → 30% CPU 核心处理网络（10Gbps+ 时） │ │
│ │ → 安全处理（TLS/加密）占用更多 CPU │ │
│ │ → CPU 没空处理业务逻辑 │ │
│ │ │ │
│ │ DPU 模式：CPU 卸载给 DPU │ │
│ │ → DPU 处理网络协议栈、RDMA、安全 │ │
│ │ → CPU 专注业务计算 │ │
│ │ → GPU 专注模型计算 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘BlueField DPU 架构
┌─────────────────────────────────────────────────────────────┐
│ NVIDIA BlueField-3 DPU 架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ BlueField-3 DPU │ │
│ │ │ │
│ │ ┌─────────────────────────────────────────────┐ │ │
│ │ │ ARM Cores（16 核） │ │ │
│ │ │ ← 运行 DOCA SDK，卸载网络/安全/存储 │ │ │
│ │ └──────────────────┬──────────────────────────┘ │ │
│ │ │ │ │
│ │ ┌─────────────────┴──────────────────────────┐ │ │
│ │ │ 硬件加速引擎 │ │ │
│ │ │ ├── RDMA 加速（GPUDirect RDMA） │ │ │
│ │ │ ├── 加密引擎（IPSec / TLS / AES-XTS） │ │ │
│ │ │ ├── 存储加速（NVMe-oF / vTPM） │ │ │
│ │ │ └── 流量解析（DPI / regex） │ │ │
│ │ └──────────────────┬──────────────────────────┘ │ │
│ │ │ │ │
│ │ ┌─────────────────┴──────────────────────────┐ │ │
│ │ │ ConnectX-7 Network Ports（2× 400Gbps） │ │ │
│ │ └─────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │ │
│ └──► PCIe 5.0 ←──────► Host CPU/GPU │
│ │
│ DPU 在集群中的位置： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Host CPU/GPU ←── PCIe ──► BlueField DPU ←── IB/ETH ──► 网络 │ │
│ │ │ │
│ │ DPU 接管： │ │
│ │ → RDMA 端点管理（降低 CPU 负载） │ │
│ │ → GPUDirect Storage（直接存储访问） │ │
│ │ → 网络安全（微分段、防火墙） │ │
│ │ → 云原生网络（CNI 插件卸载） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘DPU 的集群价值
┌─────────────────────────────────────────────────────────────┐
│ DPU 为 GPU 集群带来的价值 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. GPUDirect RDMA 增强： │
│ → BlueField 作为 RDMA 代理，减轻 Host CPU 参与 │
│ → 存储流量和网络流量分离（双 DPU 架构） │
│ → 预估效果：CPU 网络开销降低 70% │
│ │
│ 2. GPUDirect Storage： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 无 DPU：GPU HBM ──CPU 内存中转──► 存储服务器 │ │
│ │ 有 DPU：GPU HBM ──DPU──► 存储服务器（RDMA） │ │
│ │ │ │
│ │ Checkpoint 写入速度提升：5-10x │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 3. 安全隔离： │
│ → DPU 提供硬件级网络微分段 │
│ → 每个 Pod 有独立的网络安全策略 │
│ → 多租户场景下安全性大幅提升 │
│ │
│ 4. 成本考量： │
│ → BlueField-3 每块 $2,000-$4,000（取决于配置） │
│ → 如果能节省 30% 的 CPU 资源（可用于更多作业）， │
│ 实际上是在用 DPU 的钱换 CPU 的钱 │
│ │
└─────────────────────────────────────────────────────────────┘第3节：NPU 与异构集群调度
NPU 生态概览
┌─────────────────────────────────────────────────────────────┐
│ 主要 NPU 生态对比 │
├─────────────────────────────────────────────────────────────┤
│ │
│ │ NPU │ 厂商 │ 架构 │ 内存 │ 生态 │
│ ├──────────────┼──────────┼───────────┼─────────┼──────────┤
│ │ NVIDIA GPU │ NVIDIA │ Ampere/ │ HBM │ CUDA │
│ │ (A/H/B系列) │ │ Hopper/ │ │ +cuDNN │
│ │ │ │ Blackwell │ │ +TensorRT│
│ ├──────────────┼──────────┼───────────┼─────────┼──────────┤
│ │ Ascend 910B │ 华为 │ DaVinci │ HBM │ CANN │
│ │ │ │ v2 │ │ +MindSpore│
│ ├──────────────┼──────────┼───────────┼─────────┼──────────┤
│ │ Google TPU │ Google │ v5/v5e │ HBM │ JAX/ │
│ │ │ │ 脉动阵列 │ │ TPU Runtime│
│ ├──────────────┼──────────┼───────────┼─────────┼──────────┤
│ │ AMD Instinct│ AMD │ CDNA 3 │ HBM │ ROCm │
│ │ (MI300X) │ │ │ │ +MIOpen │
│ └──────────────┴──────────┴───────────┴─────────┴──────────┘
│ │
│ 选择考量： │
│ → NVIDIA：生态最完整，工具链成熟（主流选择） │
│ → Ascend：国产化要求，中国市场 │
│ → TPU：Google Cloud 专属，JAX 生态 │
│ → AMD MI300X：HBM 容量大，适合大模型推理 │
│ │
└─────────────────────────────────────────────────────────────┘华为 Ascend 的 HCCL 通信库
┌─────────────────────────────────────────────────────────────┐
│ HCCL vs NCCL：华为 Ascend 的集群通信 │
├─────────────────────────────────────────────────────────────┤
│ │
│ NCCL（NVIDIA）： │
│ → 专用于 NVIDIA GPU │
│ → 通信原语：all_reduce / all_gather / broadcast / reduce │
│ → 拓扑感知：NVLink / PCIe / IB │
│ → 生态：DeepSpeed / Megatron / PyTorch DDP 均可集成 │
│ │
│ HCCL（华为 Ascend）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 定位：Ascend NPU 的集群通信库（NCCL 的对标） │ │
│ │ │ │
│ │ 通信原语：与 NCCL 完全一致 │ │
│ │ → all_reduce / all_gather / broadcast / reduce │ │
│ │ │ │
│ │ 拓扑感知：HCCS（NPU 直连） │ │
│ │ → 910B: HCCS × 24，300 GB/s per pair │ │
│ │ → 跨服务器：RoCE v2 / IB │ │
│ │ │ │
│ │ 框架支持： │ │
│ │ → MindSpore（华为原生） │ │
│ │ → PyTorch（Ascend 适配版） │ │
│ │ → 计划支持 DeepSpeed（Ascend 版本） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 异构集群的通信挑战： │
│ → NVIDIA GPU + Ascend NPU 混合集群：无法用单一通信库 │
│ → 解法：作业级别隔离（要么全 NVIDIA，要么全 Ascend） │
│ → 趋势：大型云厂商通常选择单一硬件路线 │
│ │
└─────────────────────────────────────────────────────────────┘第4节：异构集群的统一调度
异构调度的挑战
┌─────────────────────────────────────────────────────────────┐
│ 异构集群调度的核心挑战 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 挑战 1：不同加速器的性能指标不可比 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ NVIDIA H100：FP8 算力 3958 TFLOPS │ │
│ │ Huawei Ascend 910B：FP16 算力 512 TFLOPS │ │
│ │ AMD MI300X：FP8 算力 1307 TFLOPS │ │
│ │ │ │
│ │ 问题：不同厂商的 TFLOPS 不能直接比较 │ │
│ │ → 不同精度格式（FP8/FP16/FP32） │ │
│ │ → 不同架构（SIMT vs 脉动阵列） │ │
│ │ → 不同内存带宽（影响实际 MFU） │ │
│ │ 解法：标准化基准（Transformer 算子作为基准） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 挑战 2：内存不共享 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ H100：80GB HBM │ │
│ │ Ascend 910B：64GB HBM │ │
│ │ MI300X：192GB HBM（CPU+GPU 统一内存） │ │
│ │ │ │
│ │ 问题：跨加速器的流水线并行（PP）无法实现 │ │
│ │ → TP/DP 可以跨加速器（通信接口标准化了） │ │
│ │ → PP 需要相同内存布局，跨厂商几乎不可能 │ │
│ │ 解法：作业级别隔离，或者同一作业只用一种加速器 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 挑战 3：通信库不兼容 │
│ → NCCL ≠ HCCL ≠ RCCL（AMD）≠ OneCCL（Intel） │
│ → 跨厂商集合通信（AllReduce）没有统一标准 │
│ → 解法：UCX 作为高层抽象，底层自动选择合适的通信库 │
│ │
└─────────────────────────────────────────────────────────────┘Kubernetes 异构调度配置
yaml
# Kubernetes 异构集群调度
# 节点打标（Node Labels）
apiVersion: v1
kind: Node
metadata:
labels:
hardware/nvidia.com/gpu: "true"
hardware/nvidia.com/gpu.count: "8"
hardware/nvidia.com/gpu.memory: "80GB"
hardware/nvidia.com/gpu.model: "H100-SXM5"
---
apiVersion: v1
kind: Node
metadata:
labels:
hardware/ascend.com/npu: "true"
hardware/ascend.com/npu.count: "8"
hardware/ascend.com/npu.memory: "64GB"
hardware/ascend.com/npu.model: "Ascend-910B"
# 作业调度到特定加速器
apiVersion: v1
kind: Pod
metadata:
name: nvidia-training-pod
spec:
nodeSelector:
hardware/nvidia.com/gpu: "true"
containers:
- name: trainer
image: pytorch/pytorch:2.1.0-cuda12.1
resources:
limits:
nvidia.com/gpu: "8"
---
apiVersion: v1
kind: Pod
metadata:
name: ascend-training-pod
spec:
nodeSelector:
hardware/ascend.com/npu: "true"
containers:
- name: trainer
image: ascend-mindspore:2.0
resources:
limits:
ascend.com/npu: "8"第5节：Grace-Hopper Superchip——CPU-GPU 融合的新范式
GH200 的设计理念
┌─────────────────────────────────────────────────────────────┐
│ GH200：CPU 和 GPU 的新关系 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 传统架构：CPU 和 GPU 是两个独立芯片 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ CPU Socket 1 ←── PCIe ──→ GPU 0, GPU 1, GPU 2 │ │
│ │ CPU Socket 2 ←── PCIe ──→ GPU 3, GPU 4, GPU 5 │ │
│ │ │ │
│ │ 问题：跨 NUMA 访问延迟高，带宽受限 │ │
│ │ 最佳实践：让 GPU 和它的"配对 CPU"在同一边 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ GH200 架构：CPU 和 GPU 在同一芯片包 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ ┌─────────────────────────────────────────────┐ │ │
│ │ │ Grace CPU（72核）←→ Hopper GPU (H100) │ │ │
│ │ │ NVLink-C2C：900 GB/s 双向带宽 │ │ │
│ │ └─────────────────────────────────────────────┘ │ │
│ │ │ │ │ │
│ │ ↓ ↓ │ │
│ │ LPDDR5 HBM3 │ │
│ │ 500 GB/s 3.35 TB/s │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 关键数字： │
│ → CPU-GPU 带宽（900 GB/s）≈ GPU 显存带宽的 1/4 │
│ → 远超 PCIe（64 GB/s）13x │
│ → CPU 预处理的数据可以直接"流"给 GPU，无 PCIe 瓶颈 │
│ │
│ 适用场景： │
│ → 大模型推理（数据预处理和推理可以更流水线化） │
│ → 需要频繁 CPU-GPU 数据交换的训练（如 MoE） │
│ → 内存受限场景（Grace 提供额外 480GB LPDDR5） │
│ │
└─────────────────────────────────────────────────────────────┘升华：异构是未来，但管理是挑战
┌─────────────────────────────────────────────────────────────┐
│ 异构集群的工程哲学 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. 异构是趋势，但不是万能药： │
│ → CPU/GPU/DPU/NPU 各司其职，系统复杂度增加 │
│ → 异构带来的性能收益必须大于管理成本 │
│ │
│ 2. CPU 从"主角"变成"配角"，但仍是关键配角： │
│ → GPU 再强，也需要 CPU 提供数据 │
│ → 数据预处理瓶颈是 GPU 集群中最常见的效率问题之一 │
│ │
│ 3. DPU 把"网络的苦活"揽走了： │
│ → 未来的 GPU 集群，DPU 将是标配 │
│ → 安全、网络、存储卸载 = 更多 CPU 资源给业务 │
│ │
│ 4. 跨厂商异构集群仍不成熟： │
│ → NCCL ≠ HCCL ≠ RCCL，集合通信不互通 │
│ → 短期内单一厂商路线更实际 │
│ │
│ 一句话总结： │
│ 异构集群让每种硬件做自己最擅长的事， │
│ 但代价是调度、监控、故障处理的复杂度成倍增加。 │
│ │
└─────────────────────────────────────────────────────────────┘"AI 可查 vs 必须理解"清单
AI 可查：
✅ BlueField DPU 的 DOCA SDK API 文档
✅ Ascend 910B vs 910 的具体差异
✅ GH200 的 BIOS 配置参数
✅ AMD ROCm 对 MI300X 的具体支持情况
必须理解：
🔴 CPU 在 GPU 集群中的四大职责（控制平面 / 预处理 / 存储 IO / 优化器）
🔴 为什么 PCIe 是 CPU-GPU 通信的瓶颈（带宽差距 14x）
🔴 DPU 的定位：卸载网络/存储/安全，让 CPU 专注业务
🔴 Grace-Hopper Superchip 如何用 NVLink-C2C 解决 CPU-GPU 带宽问题
🔴 异构集群调度的三大挑战（性能不可比 / 内存不共享 / 通信库不兼容）
🔴 为什么跨厂商异构集群（NVIDIA + Ascend）短期内仍不现实学习状态：🟡 开始学习