从 CUDA 到 HIP：用 HIPify 实现代码自动化迁移

手里握着 AMD 显卡，面对满网的"CUDA 教程”却无从下手，这是很多开发者转向 ROCm 生态时的第一道坎。其实，AMD 的 HIP（Heterogeneous-compute Interface for Portability）编程模型与 CUDA 高度相似，绝大多数情况下，只需将代码中的 cuda 前缀替换为 hip，即可在 AMD GPU 上运行。手动修改成千上万行代码显然不现实，这时候，AMD 官方提供的 HIPify 工具就成了我们的“救命稻草”。

对于有 CUDA 开发基础的朋友来说，迁移的核心痛点不在于理解逻辑，而在于如何高效、准确地完成语法层面的“翻译”。今天我们就聚焦于代码迁移环节，聊聊如何利用 hipify-clang 将现有的 C++ CUDA 代码一键转换为 HIP 格式，并处理那些自动化工具搞不定的“硬骨头”。

核心利器：hipify-clang 命令行实战

在 ROCm 工具链中，hipify-clang 是目前最推荐的转换工具。它基于 Clang 编译器前端，不仅能进行简单的文本替换，还能理解 C++ 的语法结构，因此比早期的 hipify-perl（基于正则表达式）更加精准，尤其适合处理复杂的模板和宏定义。

假设你有一个标准的 CUDA C++ 文件 vector_add.cu，实现了简单的向量加法：

#include <cuda_runtime.h>
#include <iostream>

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

int main() {
    float *d_a, *d_b, *d_c;
    cudaMalloc(&d_a, 100 * sizeof(float));
    cudaMalloc(&d_b, 100 * sizeof(float));
    cudaMalloc(&d_c, 100 * sizeof(float));
    
    vectorAdd<<<1, 100>>>(d_a, d_b, d_c, 100);
    
    cudaFree(d_a);
    cudaFree(d_b);
    cudaFree(d_c);
    return 0;
}

在安装了 ROCm 环境的 Linux 终端中，转换过程极其简单，只需一条命令：

hipify-clang vector_add.cu -o vector_add_hip.cpp

执行后，生成的 vector_add_hip.cpp 会发生如下变化：

• 头文件 #include <cuda_runtime.h> 自动变为 #include <hip/hip_runtime.h>。
• 内存分配函数 cudaMalloc 变为 hipMalloc。
• 内核启动语法 <<<...>>> 被保留（HIP 兼容此语法），但上下文已适配 HIP 运行时。
• cudaFree 变为 hipFree。

这就是 HIPify 的魅力：它完成了 90% 以上的机械性工作，让你能迅速看到代码在 AMD 架构上运行的希望。

自动转换后的“遗留问题”与人工介入

虽然 hipify-clang 很强大，但它并非万能。在实际的大模型项目（如 SGLang、LLaMA-Factory 的底层算子）迁移中，自动转换后往往还需要人工介入。主要涉及以下两类情况：

1. 特定库函数的映射缺失
CUDA 生态中有许多专用库，如 cuBLAS、cuDNN、NCCL 等。HIPify 能将 cublasSgemm 转换为 hipblasSgemm，但前提是你要确保项目中已经链接了正确的 ROCm 库（如 rocBLAS）。如果代码中使用了某些 CUDA 特有的高级特性或非标准 API，转换工具可能会直接跳过或留下注释标记。此时，你需要手动查阅 AMD 的移植指南，将其替换为 MIOpen 或 RCCL 的对应调用。

2. 编译配置与路径依赖
自动转换只改代码内容，不改构建系统。如果你的项目使用 CMake 或 Makefile，其中硬编码的 nvcc 编译器路径、-arch=sm_80 等 NVIDIA 专属标志，都需要手动调整为 hipcc 和对应的 AMD 架构标志（如 --offload-arch=gfx908）。此外，某些项目可能通过 Python 脚本动态加载 CUDA 库，这部分逻辑也需要针对性修改，确保加载的是 HIP 运行时库。

编译测试：快速定位残留依赖

代码转换完成后，不要急着跑业务逻辑，第一步必须是编译测试。这是检验迁移是否彻底的最快方法。

使用 hipcc 编译器尝试编译生成的 HIP 文件：

hipcc vector_add_hip.cpp -o vector_add_hip.out

如果编译成功，恭喜你已经迈过了大半门槛。如果报错，请重点关注以下几类信息：

• 未定义的引用（undefined reference）：通常意味着缺少了对应的 ROCm 库链接，或者函数名转换不完全。
• 未知的类型名称：可能是某些 CUDA 特有的类型（如 cudaStream_t 的某些扩展用法）未被正确映射。
• 无效的架构参数：检查构建脚本中是否还残留着针对 NVIDIA GPU 的计算能力设置。

通过编译器的报错堆栈，你可以迅速定位那些未能自动转换的“顽固分子”，将精力集中在真正需要逻辑调整的少数模块上，而不是盲目地全篇审查。

复杂项目的批处理与目录结构迁移

真实的大模型项目往往包含数百个 .cu 文件，分布在复杂的目录结构中。逐个运行命令显然不现实。我们可以编写一个简单的 Shell 脚本来批量处理：

#!/bin/bash
# 遍历当前目录下所有 .cu 文件并进行转换
find . -name "*.cu" | while read file; do
    output_file="${file%.cu}_hip.cpp"
    echo "Converting $file to $output_file..."
    hipify-clang "$file" -o "$output_file"
done

对于像 SGLang 或 TileLang 这样的大型项目，建议在转换前先备份整个源码目录。转换后，除了检查 C++ 源文件，还要留意 Python 绑定部分（pybind11 等），确保它们引用的扩展模块名也已同步更新。

从 CUDA 到 ROCm 的迁移，本质上是一次技术栈的“平移”而非“重写”。借助 HIPify 工具链，我们极大地降低了这一过程的门槛。虽然在算子优化和极端场景下仍需人工打磨，但对于大多数通用计算任务，这套自动化流程已经足够成熟。一旦跑通了第一个 Hello World，你会发现 AMD 显卡的高性价比优势将在大模型训练与推理中释放巨大潜力。

200小时GPU算力已就位，快来领取：https://marketing.csdn.net/questions/Q2604140858304426315?utm_source=AIpaper