硬件加速新时代：CUDA vs. ROCm vs. oneAPI的开发生态对比

最近几年，硬件加速的战场越来越热闹了。以前搞GPU计算，大家基本只有CUDA一个选择，但现在AMD的ROCm和Intel的oneAPI也杀进来了，特别是oneAPI，它不只是一个GPU方案，而是想统一CPU、GPU、FPGA甚至其他加速器。我踩过不少坑，今天就来聊聊这三个生态的真实体验和选型思路。

CUDA：老牌霸主，生态无敌但锁死NVIDIA

CUDA是我最早接触的，说实话，它的成熟度至今无人能敌。从cuBLAS、cuDNN到TensorRT，几乎每个深度学习框架都优先支持CUDA。如果你手头有NVIDIA显卡，直接装驱动和CUDA Toolkit就能跑起来。

安装CUDA的典型步骤（以Ubuntu 22.04为例）：

# 添加NVIDIA官方仓库
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.0-1_all.deb
sudo dpkg -i cuda-keyring_1.0-1_all.deb
sudo apt-get update

# 安装CUDA Toolkit 12.x
sudo apt-get install -y cuda-toolkit-12-4

# 验证安装
nvcc --version
nvidia-smi

实战中，CUDA最让我舒服的是nvcc编译器和Nsight调试工具。写一个简单的向量加法：

#include <cuda_runtime.h>
#include <stdio.h>

__global__ void vecAdd(float *a, float *b, float *c, int n) {
    int i = blockIdx.x * blockDim.x + threadIdx.x;
    if (i < n) c[i] = a[i] + b[i];
}

int main() {
    int n = 1024;
    float *d_a, *d_b, *d_c;
    cudaMalloc(&d_a, n * sizeof(float));
    cudaMalloc(&d_b, n * sizeof(float));
    cudaMalloc(&d_c, n * sizeof(float));
    // ... 初始化数据，调用kernel
    vecAdd<<<(n+255)/256, 256>>>(d_a, d_b, d_c, n);
    cudaDeviceSynchronize();
    cudaFree(d_a);
    cudaFree(d_b);
    cudaFree(d_c);
    return 0;
}

编译运行：

nvcc -o vecadd vecadd.cu
./vecadd

踩坑提示：CUDA版本和显卡驱动一定要匹配，否则会出现“CUDA driver version is insufficient”的报错。建议用nvidia-smi查看支持的CUDA最高版本，再安装对应的Toolkit。

ROCm：AMD的逆袭，但兼容性是个坑

ROCm是AMD对标CUDA的方案，口号是“HIPify”你的CUDA代码——意思是你写的CUDA代码稍微改改就能跑在AMD显卡上。理论上很美好，但实际体验……我试过用ROCm 5.7跑一个PyTorch模型，结果发现某些算子根本不存在，得自己写hip实现。

安装ROCm（以Ubuntu 22.04 + RX 7900 XTX为例）：

# 添加ROCm仓库
wget -q -O - https://repo.radeon.com/rocm/rocm.gpg.key | sudo apt-key add -
echo 'deb [arch=amd64] https://repo.radeon.com/rocm/apt/5.7.1 jammy main' | sudo tee /etc/apt/sources.list.d/rocm.list
sudo apt-get update

# 安装ROCm核心包
sudo apt-get install rocm-hip-libraries rocm-dev

# 验证
hipconfig --full

写一个HIP版本的向量加法（几乎和CUDA一样）：

#include <hip/hip_runtime.h>
#include <stdio.h>

__global__ void vecAdd(float *a, float *b, float *c, int n) {
    int i = blockIdx.x * blockDim.x + threadIdx.x;
    if (i < n) c[i] = a[i] + b[i];
}

int main() {
    int n = 1024;
    float *d_a, *d_b, *d_c;
    hipMalloc(&d_a, n * sizeof(float));
    hipMalloc(&d_b, n * sizeof(float));
    hipMalloc(&d_c, n * sizeof(float));
    // ...
    vecAdd<<<(n+255)/256, 256>>>(d_a, d_b, d_c, n);
    hipDeviceSynchronize();
    hipFree(d_a);
    hipFree(d_b);
    hipFree(d_c);
    return 0;
}

编译：

hipcc -o vecadd_hip vecadd_hip.cpp
./vecadd_hip

踩坑提示：ROCm对显卡型号非常挑剔，比如RX 6000系列（RDNA2）支持较好，但RX 7000系列（RDNA3）在早期ROCm版本中经常崩溃。另外，ROCm的docker镜像比本地安装稳定得多，我强烈建议用rocm/pytorch镜像：

docker run -it --device=/dev/kfd --device=/dev/dri --group-add=video rocm/pytorch:latest

oneAPI：Intel的“大一统”野心，但实际是缝合怪

oneAPI的口号是“跨架构统一编程模型”，用DPC++（基于SYCL）写一份代码，就能在Intel CPU、集成显卡、Arc独显甚至FPGA上跑。听起来很酷，但实际体验是：编译慢、报错信息晦涩、文档分散。我试过用oneAPI 2024.0在i7-13700H上跑一个矩阵乘法，结果发现CPU后端比直接写OpenMP慢了2倍。

安装oneAPI（以Ubuntu 22.04为例）：

# 添加Intel仓库
wget -O- https://apt.repos.intel.com/intel-gpg-keys/GPG-PUB-KEY-INTEL-SW-PRODUCTS.PUB | sudo apt-key add -
sudo add-apt-repository "deb https://apt.repos.intel.com/oneapi all main"
sudo apt-get update

# 安装basekit（包含DPC++编译器）
sudo apt-get install intel-basekit

# 设置环境变量
source /opt/intel/oneapi/setvars.sh

写一个SYCL版本的向量加法：

#include <sycl/sycl.hpp>
#include <iostream>

int main() {
    const int n = 1024;
    float *a = new float[n];
    float *b = new float[n];
    float *c = new float[n];
    for (int i = 0; i < n; i++) { a[i] = i; b[i] = i; }

    sycl::queue q;
    std::cout << "Device: " << q.get_device().get_info<sycl::info::device::name>() << std::endl;

    {
        sycl::buffer<float> buf_a(a, n);
        sycl::buffer<float> buf_b(b, n);
        sycl::buffer<float> buf_c(c, n);

        q.submit([&](sycl::handler& h) {
            auto acc_a = buf_a.get_access<sycl::access::mode::read>(h);
            auto acc_b = buf_b.get_access<sycl::access::mode::read>(h);
            auto acc_c = buf_c.get_access<sycl::access::mode::write>(h);
            h.parallel_for(n, [=](sycl::id<1> i) {
                acc_c[i] = acc_a[i] + acc_b[i];
            });
        });
    }

    for (int i = 0; i < 10; i++) std::cout << c[i] << " ";
    delete[] a; delete[] b; delete[] c;
    return 0;
}

编译运行：

icpx -fsycl -o vecadd_sycl vecadd_sycl.cpp
./vecadd_sycl

踩坑提示：oneAPI的SYCL实现有多个后端（Level Zero、OpenCL），默认可能选到CPU。要强制用GPU，得指定设备选择器。另外，Intel Arc显卡的驱动在Linux上仍然不稳定，建议先用Intel Iris Xe集成显卡测试。

三者的核心差异与选型建议

我整理了一个表格，方便对比：

特性	CUDA	ROCm	oneAPI
硬件支持	仅NVIDIA GPU	AMD GPU + 部分CPU	Intel CPU/GPU/FPGA
编程语言	CUDA C++	HIP C++（类似CUDA）	DPC++（基于SYCL）
库生态	极丰富（cuDNN, TensorRT）	中等（rocBLAS, MIOpen）	较少（oneDNN, oneMKL）
调试工具	Nsight, cuda-gdb	rocgdb, rocprofiler	Intel Advisor, VTune
安装难度	简单（apt/dnf）	中等（依赖显卡型号）	中等（环境变量麻烦）
性能	优秀（针对NVIDIA优化）	良好（AMD卡上接近CUDA 90%）	一般（CPU端不错，GPU端尚在追赶）

我的建议是：

如果你只想稳定跑深度学习：无脑选CUDA。PyTorch、TensorFlow的CUDA版本最成熟，遇到问题社区答案最多。
如果你有AMD显卡且想尝鲜：ROCm值得一试，但建议用Docker + 官方镜像，避免本地依赖冲突。另外，注意你的显卡是否在ROCm支持列表里（比如MI系列专业卡支持最好，消费级RX卡次之）。
如果你做异构计算或FPGA开发：oneAPI是唯一的选择，特别是Intel Cyclone系列FPGA。但做好心理准备，SYCL的学习曲线比CUDA陡峭，而且性能调优需要深入理解设备架构。

最后说一句，不要迷信“写一次代码到处跑”。实际项目中，我经常需要针对不同硬件写特定优化代码。CUDA的生态优势短期内无法被撼动，但ROCm和oneAPI的进步也很快——特别是oneAPI的SYCL 2020标准，如果Intel能解决编译器和驱动问题，未来可期。