异构推理硬件：ROCm、Intel 与国产 NPU 适配实践

驱动因素：
□ 供应：高端 GPU 供给紧张，排队周期长
□ 成本：单一供应商溢价，采购与运维成本高
□ 政策：信创与国产化要求（特定场景必须国产）
□ 场景：边缘/端侧需要低功耗专用加速器
□ 竞争：多供应商议价与冗余

代价：
□ 软件栈碎片化：每家的编译器、运行时、算子库都不同
□ 迁移成本：CUDA 生态深度绑定，迁移要重写/重编
□ 算子缺口：新算子在新硬件上常常没有实现
□ 工具链成熟度：调试、profiling 工具远不如 CUDA

异构推理的真实收益点：
□ 把「非核心负载」迁到异构硬件 → 释放 GPU 给核心业务
□ 特定算子（如 INT8/稀疏）在专用硬件上性价比更高
□ 边缘场景用专用 NPU 换功耗
□ 供应链冗余：不被单一供应商锁定

主流异构推理硬件：
□ NVIDIA GPU（A100/H100/L40S 等）
  - 生态最成熟（CUDA），本文作为基线对照
□ AMD Instinct（MI300X / MI250 等）
  - ROCm 软件栈，显存大是主要卖点
□ Intel Gaudi（Gaudi2/3）
  - 专为训练/推理设计，oneAPI + SynapseAI
□ Intel GPU（数据中心 Max 系列）
  - oneAPI，适合推理与媒体处理
□ 国产 NPU：昇腾（Ascend）、寒武纪（MLU）、
  燧原、壁仞、摩尔线程等
  - 各自 CANN/自研软件栈，政策场景主力
□ 专用加速：TPU 类、FPGA、边缘 NPU

关键差异维度：
□ 计算精度支持：FP16/BF16/INT8/FP8/INT4
□ 显存容量与带宽：大模型推理的硬门槛
□ 互联：NVLink / Infinity Fabric / 自研互联
□ 软件栈成熟度：算子覆盖、编译器、调试工具
□ 生态兼容：能否复用 PyTorch/vLLM 等生态

选型决策：
□ 通用大模型推理 + 生态优先 → NVIDIA
□ 大显存 + 成本敏感 → AMD MI 系列
□ 高性价比推理 + Intel 生态 → Gaudi
□ 国产化要求 → 昇腾等国产 NPU
□ 边缘低功耗 → 专用 NPU

ROCm 软件栈构成：
□ HIP：类 CUDA 的编程接口（C++ 方言）
□ hipBLAS/rocBLAS：BLAS 库（对应 cuBLAS）
□ MIOpen：深度学习原语（对应 cuDNN）
□ RCCL：集合通信（对应 NCCL）
□ rocPRIM/hipCUB：并行原语（对应 CUB）
□ rocprof：性能分析（对应 nsight）

HIP 的迁移策略：
□ HIP 是「CUDA 的方言」：大部分 API 一一对应
□ hipify 工具：自动把 CUDA 源码转成 HIP
□ 头文件替换：#include <cuda_runtime.h> → <hip/hip_runtime.h>
□ 内核语法几乎一致（__global__、blockIdx 等）
□ 但性能调优要重做（wavefront 大小、共享内存 bank）

# 用 hipify 自动迁移 CUDA 源码
hipify-clang kernel.cu -o kernel.hip.cpp
# 或 Python 侧：PyTorch 的 ROCm 版本直接替换包
pip install torch --index-url https://download.pytorch.org/whl/rocm6.0

# 环境检查
rocm-smi            # 对应 nvidia-smi
rocminfo            # 设备信息
hipcc --version     # 编译器版本

迁移的坑：
□ wavefront 是 64 线程（CUDA warp 是 32）→ 调优参数全变
□ 共享内存 bank 宽度不同 → 冲突模式不同
□ 部分 CUDA 库无直接对应 → 需自研或降级
□ 驱动/内核版本匹配严格（ROCm 对内核版本敏感）
□ 算子覆盖：新模型的新算子常常缺实现

Gaudi 的特点：
□ 专为 AI 训练/推理设计（非通用 GPU 架构）
□ 内置矩阵乘法引擎（MME）+ 张量核心（TPC）
□ 集成 RDMA 网卡（RoCE）→ 多卡扩展便宜
□ 大显存 HBM（Gaudi2 96 GB，Gaudi3 更高）
□ 软件栈：SynapseAI + Habana 驱动

oneAPI 的定位：
□ 跨架构统一编程模型（CPU/GPU/FPGA/加速器）
□ SYCL：C++ 单源异构编程（对标 CUDA/HIP）
□ oneDNN：深度学习原语库
□ oneCCL：集合通信
□ 目标：一套代码跑多种 Intel 硬件

# PyTorch 在 Intel GPU / Gaudi 上的使用
import torch
# Intel GPU（XPU）
device = "xpu"
x = torch.randn(1024, 1024, device=device)
# Gaudi（HPU）
import habana_frameworks.torch as ht
device = "hpu"
model = model.to(device)

Gaudi 的适配要点：
□ 迁移成本主要在算子：非标准算子可能缺实现
□ Habana 提供 PyTorch 适配层（habana_frameworks）
□ vLLM/TGI 有 Gaudi 后端分支
□ 优势场景：大 batch 推理、显存密集
□ 生态工具链相对年轻

华为昇腾（Ascend）：
□ 硬件：昇腾 910（训练/推理）、310（边缘）
□ 软件栈：CANN（对标 CUDA 的完整栈）
  - ACL：运行时接口
  - GE：图引擎（Graph Engine）
  - AscendCL：应用编程接口
  - MindSpore / PyTorch 适配（torch_npu）
□ 编程模型：偏向「图模式」，算子由图编译器调度

寒武纪（MLU）：
□ 软件栈：Neuware / Cambricon BANG
□ 支持 PyTorch（torch_mlu）

其他：燧原、壁仞、摩尔线程等各有自研栈

国产 NPU 适配的核心工作：
□ 1. 算子适配：把模型用到的算子映射到 NPU 算子库
  - 已有算子：直接映射
  - 缺失算子：用组合算子拼 或 写自定义算子
□ 2. 图转换：把 PyTorch 计算图转成 NPU 图
  - ONNX 作为中间表示是常见路径
  - 动态 shape 支持常常受限
□ 3. 精度对齐：与 GPU 结果逐层比对
□ 4. 性能调优：batch、内存、流水线

# PyTorch 昇腾适配的典型用法
import torch
import torch_npu            # 注册 NPU 后端
device = "npu:0"
model = model.to(device)
x = x.to(device)
# 注意：部分算子需在 NPU 上实现，否则回退 CPU

适配的难点：
□ 动态 shape：NPU 图编译常要求静态 shape → 需 padding/分档
□ 缺失算子：自定义算子开发成本高（要写 TBE/AscendC）
□ 精度差异：累加顺序不同 → 数值偏差 → 逐层对齐
□ 工具链：profiling、调试工具不如 CUDA 成熟
□ 版本绑定：CANN 与 torch_npu 版本强耦合

三层软件栈对照：
层级        NVIDIA          AMD            Intel         昇腾
算子库      cuBLAS/cuDNN    rocBLAS/MIOpen oneDNN        CANN 算子库
图编译      TensorRT        MIGraphX       OpenVINO/GE    GE 图引擎
运行时      CUDA Runtime    HIP Runtime    oneAPI RT      ACL Runtime
通信        NCCL            RCCL           oneCCL         HCCL

差异带来的实际问题：
□ 算子语义细节不同：边界处理、NaN 传播、舍入模式
□ 图优化策略不同：融合规则、内存复用策略
□ 动态 shape 支持不同：有的必须静态化
□ 精度默认值不同：FP16 累加方式、TF32 开关
□ 并发模型不同：流/队列语义

跨平台抽象层：
□ ONNX：模型交换的通用中间表示
□ MLIR：编译器基础设施，多后端代码生成
□ TVM：统一的算子编译与调度
□ 推理框架的多后端：Triton Server 后端插件

移植的工程化路径：
□ 优先用 ONNX 导出 → 各硬件厂商的转换工具
□ 算子缺口用「组合算子 + 自定义」补齐
□ 建立「逐层精度对齐」测试（与 GPU 基线比）
□ 性能回归测试纳入 CI

vLLM：
□ 以 CUDA 为主，ROCm 有官方支持
□ 其他后端（昇腾、Gaudi）多靠厂商分支/插件
□ 算子层（attention、GEMM）与硬件强相关

Triton Inference Server：
□ 天然多后端：TensorRT / ONNX Runtime / PyTorch / 自定义
□ 通过 backend 插件接入不同硬件运行时
□ 适合「同一服务暴露多种硬件」的场景
□ 见 Triton Server 篇

ONNX Runtime：
□ 多执行提供者（Execution Provider）：
  - CUDA EP、ROCm EP、OpenVINO EP、昇腾 EP 等
□ 模型统一用 ONNX → 换 EP 即换硬件
□ 抽象程度高，但性能不一定最优
□ 见 ONNX Runtime 篇

选型建议：
□ 追求极致性能 → 用厂商深度优化的路径（各硬件原生）
□ 追求可移植 → ONNX Runtime / Triton 多后端
□ 生产混合硬件 → Triton 统一服务层
□ 快速验证 → ONNX 导出 + 各厂商转换工具

性能参考（量级示意，非精确基准）：
□ 大模型推理吞吐：NVIDIA 仍领先，但 AMD/Intel 在追赶
□ 单位成本性价比：AMD/国产在特定场景有优势
□ 显存容量：AMD MI300X（192 GB）有优势
□ 多卡扩展：Gaudi 集成 RDMA，组网成本低
→ 具体数字随型号与软件版本快速变化，须实测

生产落地路径：
□ 1. 选一个「非核心、可容忍精度差异」的负载试点
□ 2. 用 ONNX 导出 → 目标硬件转换 → 精度对齐
□ 3. 建立 GPU 基线与异构硬件的双跑对比
□ 4. 逐步扩大流量比例，灰度切流
□ 5. 把性能与精度回归纳入 CI

成本模型：
□ 硬件采购成本（异构硬件往往更低）
□ 迁移成本（人力 + 时间，常常被低估）
□ 运维成本（新工具链、新故障模式）
□ 供应风险（多供应商冗余的价值）
→ 迁移成本必须计入 TCO，不能只看硬件单价

高频踩坑：
□ 算子缺失却静默回退 CPU → 性能暴跌（要检查是否回退）
□ 动态 shape 未处理 → 图编译失败或重编译
□ 精度未对齐 → 输出看似正常但质量下降
□ 版本不匹配（CANN/torch_npu、ROCm/内核）→ 各种诡异错误
□ 内存对齐要求不同 → 崩溃或性能差
□ 通信库（HCCL/RCCL）未正确配置 → 多卡 hang
□ 直接拿 GPU 的性能预期套异构硬件 → 落差大
□ 编译缓存未命中 → 每次启动重新编译，耗时极长

排查清单：
□ 算子覆盖报告：模型用了多少算子、命中多少
□ 回退检测：是否有算子回退到 CPU
□ 逐层精度对比：与 GPU 基线的最大/平均偏差
□ profiling：算子耗时分布（找瓶颈算子）
□ 版本矩阵：驱动、运行时、框架、算子库的兼容表
□ 编译缓存：是否命中、启动耗时