CUDA 应用迁移到 AMD ROCm 需要做什么

概述

CUDA应用迁移到AMD ROCm并不是把NVIDIA驱动替换成AMD驱动。迁移范围可能涉及深度学习框架、CUDA运行时、自定义C++/CUDA扩展、数学库、NCCL通信、容器、构建系统、监控和性能调优。

最稳妥的路径是先盘点依赖，优先使用已经原生支持ROCm的框架和模型；只有自定义CUDA代码再使用HIP和HIPIFY转换。转换后还必须进行正确性、性能、多卡通信和长期稳定性回归。

第一步：判断迁移范围

迁移前应将应用拆分为多个层次。不同层次的迁移工作量差异很大。

层次	常见内容	迁移难度
业务层	Python服务、API、数据流程	通常较低
框架层	PyTorch、TensorFlow、JAX、vLLM等	取决于官方ROCm支持
模型层	权重、量化、Tokenizer和推理配置	中等，需要验证精度和内核
扩展层	自定义CUDA算子、FlashAttention、量化插件	通常较高
库依赖	cuBLAS、cuDNN、cuFFT、NCCL等	取决于对应ROCm库
底层代码	inline PTX、设备特性、手写Kernel	高，需要人工重写和调优
运维层	容器、监控、Kubernetes、CI/CD	中等，需要重建镜像和流程

迁移前需要盘点什么

• 应用使用的CUDA、cuDNN、NCCL和驱动版本。
• PyTorch、TensorFlow或推理框架版本。
• 所有自定义.cu、.cuh和C++扩展。
• FlashAttention、bitsandbytes、AWQ、GPTQ等第三方插件。
• 是否包含inline PTX或依赖NVIDIA特定硬件特性的代码。
• 是否依赖闭源CUDA库、二进制插件或无源码组件。
• 单卡、多卡、跨节点和Kubernetes部署方式。
• 当前模型正确性、性能和稳定性基线。

没有源码的CUDA二进制通常无法通过HIPIFY解决。若关键插件只提供CUDA二进制，需要寻找ROCm版本、替代实现或联系供应商。

优先使用原生ROCm框架

如果应用主要由Python和标准框架算子组成，应先尝试官方ROCm版本，而不是立即改写源码。ROCm对PyTorch的支持已经合入上游PyTorch，但ROCm和PyTorch有各自的发布周期，必须使用兼容矩阵中的组合。

• 安装AMD官方或框架官方提供的ROCm容器。
• 加载原始模型并运行单卡正确性测试。
• 检查算子是否回退到CPU或出现未实现错误。
• 验证混合精度、量化和注意力实现。
• 再评估是否需要修改自定义扩展。

HIP与HIPIFY分别做什么

HIP是面向AMD GPU的C++运行时API和Kernel语言，其接口风格与CUDA相近。HIPIFY是将CUDA源码转换为HIP源码的工具集合。

• hipify-clang：基于Clang AST解析CUDA代码，适合结构复杂、需要明确错误报告的项目。
• hipify-perl：基于规则转换，使用方便，但对宏、命名空间和复杂语法的处理能力有限。
• hipcc/amdclang++：用于编译转换后的HIP代码。

HIPIFY只负责语法和API转换，不会自动保证算法正确、性能达标，也不会完整改造CMake、Bazel或其他构建系统。

建议的代码迁移流程

1. 在原NVIDIA环境中固定代码版本并通过全部测试。
2. 使用HIPIFY扫描项目，生成不支持API和转换统计。
3. 先转换小型核心模块，再逐步扩大范围。
4. 调整头文件、Kernel启动语法、编译参数和构建脚本。
5. 替换或接入对应的ROCm数学库。
6. 处理warp、共享内存、原子操作和设备属性差异。
7. 在单卡环境完成单元测试和结果比对。
8. 开展性能分析和Kernel调优。
9. 再进入多卡RCCL和跨节点测试。

hipify-clang source.cu -- -I/path/to/cuda/includes > source_hip.cpp
hipcc source_hip.cpp -o application

命令仅为示意。实际参数取决于项目头文件、编译选项、目标GPU架构和构建系统。

常见CUDA库如何对应

CUDA组件	ROCm/HIP对应方向	注意事项
CUDA Runtime/Driver	HIP Runtime/Driver API	接口相似但并非完全等价
cuBLAS	hipBLAS / rocBLAS	hipBLAS接口更接近CUDA，rocBLAS面向AMD优化
cuDNN	MIOpen	API和算法选择存在差异，不能只替换库名
cuFFT	hipFFT / rocFFT	检查数据布局、计划和精度支持
cuSPARSE	hipSPARSE / rocSPARSE	核对稀疏格式和API支持
cuRAND	hipRAND / rocRAND	随机序列和可复现性需要重新验证
CUB	hipCUB	部分模板和行为需核验
Thrust	rocThrust	检查算法和编译器兼容性
NCCL	RCCL	多卡与多节点集合通信，需要重新测拓扑和性能
Nsight	rocprofiler、rocTracer等ROCm工具	分析流程和指标名称不同

AMD文档将部分库分为hip前缀的兼容接口和roc前缀的AMD优化实现。选择哪一类取决于移植便利性和性能目标。

自定义CUDA算子最容易遇到什么问题

不要硬编码warpSize为32

AMD GPU的wavefront语义可能与NVIDIA warp不同。代码不应假设warpSize == 32，应使用运行时或编译期提供的设备属性，并检查shuffle、ballot和同步逻辑。

inline PTX不能自动转换

包含inline PTX的代码通常需要改为HIP内建函数、通用C++实现或AMD ISA对应实现。HIPIFY无法自动理解并重写PTX语义。

共享内存与访存模式需要重测

线程块大小、LDS使用、寄存器压力和显存访问合并规则可能不同。能够编译并不代表已经达到合理性能。

原子操作与同步

应检查原子操作的数据类型、内存顺序、同步范围和可见性，特别是依赖NVIDIA特定行为的代码。

构建系统需要独立处理

CMake、Bazel、setup.py和PyTorch C++ Extension的CUDA检测逻辑通常需要修改，不能依赖HIPIFY自动完成。

从NCCL迁移到RCCL

RCCL为AMD GPU提供多GPU和多节点集合通信，包括all-reduce、all-gather、reduce-scatter、all-to-all以及点对点通信。其API与NCCL相近，但实际性能取决于Infinity Fabric、PCIe、NIC、NUMA和网络。

• 确认框架已经使用RCCL后端，而不是错误回退。
• 验证单节点八卡P2P和集合通信。
• 将NIC与GPU按NUMA拓扑绑定。
• 多节点验证RoCE或InfiniBand RDMA。
• 分别测试all-reduce和MoE常用的all-to-all。
• 记录不同消息大小、GPU数量和节点数量的带宽。

NCCL在NVIDIA平台上的调优参数不能原样套用RCCL，需要根据AMD平台文档和实际拓扑重新设置。

容器与环境管理

建议通过容器锁定ROCm、框架和依赖，避免在宿主机上反复修改环境。容器镜像应记录GPU型号、OS、内核、ROCm、框架、编译器和应用版本。

• 从AMD或框架官方ROCm镜像开始，而不是直接修改CUDA镜像。
• 将模型、代码和数据与基础运行时镜像分层管理。
• 在CI中分别构建CUDA和ROCm镜像。
• 对每个镜像运行单元测试和最小模型测试。
• 生产升级采用灰度和可回退策略。
• Kubernetes环境需核对AMD GPU Operator和设备插件版本。

正确性回归怎么做

• 固定随机种子、输入数据和模型版本。
• 比较关键层输出、最终结果和误差范围。
• 分别验证FP32、BF16、FP16和量化结果。
• 检查随机数库迁移后的可复现性差异。
• 训练任务比较loss曲线、收敛和最终指标。
• 推理任务比较准确率、困惑度或业务质量。
• 覆盖异常输入、OOM、重启和错误恢复。

浮点计算顺序和库实现不同，结果未必逐位一致。项目需要提前定义可接受的数值误差和业务质量阈值。

性能回归怎么做

层次	建议指标
Kernel	执行时间、占用率、寄存器、LDS和显存吞吐
模型	首Token延迟、Tokens/s、训练step时间和显存占用
多卡	扩展效率、RCCL通信占比和GPU利用率
多节点	RDMA吞吐、集合通信和网络拥塞
系统	功耗、温度、频率、错误率和持续稳定性
业务	并发、P95/P99延迟、单位任务成本和质量

迁移目标不应只设为“成功运行”。需要建立CUDA原平台基线，再比较ROCm平台的正确性、吞吐、稳定性和成本。

是否需要维护CUDA和ROCm双版本

若产品需要同时支持NVIDIA和AMD，可以考虑使用HIP兼容接口、框架原生算子和统一上层Python代码，但底层优化可能仍需按平台分别维护。

• 上层业务和模型逻辑尽量共用。
• 通过编译条件隔离平台特定代码。
• 为CUDA和ROCm建立独立容器和CI流水线。
• 分别维护性能基线和兼容矩阵。
• 避免为了代码统一而牺牲关键Kernel性能。

哪些项目迁移风险较高

• 大量使用inline PTX和NVIDIA特定指令。
• 依赖无源码的CUDA闭源插件。
• 自定义算子数量多且缺少测试。
• 强依赖特定TensorRT插件或CUDA Graph实现。
• 多节点训练对NCCL行为和NVLink拓扑高度优化。
• 项目没有固定版本、测试和性能基线。

这类项目应先选择一个小型工作负载做迁移PoC，而不是直接采购大规模集群后再处理软件问题。

迁移交付检查清单

1. 完成CUDA依赖和源码盘点。
2. 确定目标AMD GPU、ROCm和OS版本。
3. 确认框架与模型支持。
4. 处理所有不支持的CUDA API和第三方插件。
5. 完成HIP代码和构建系统修改。
6. 替换数学库与NCCL通信。
7. 构建可复现容器。
8. 完成单元、正确性和性能测试。
9. 完成单卡、八卡和多节点回归。
10. 建立监控、日志、升级和回退流程。

赋创目前没有将AMD平台作为主要交付方向，也没有基于MI350系列形成内部实测结论。对于明确的ROCm迁移需求，可结合代码依赖、目标模型和服务器平台协助开展迁移范围与PoC方案评估。

常见问题

HIP是CUDA的直接替代品吗

不是完全的即插即用替代。接口较相似，但自定义Kernel、依赖库、构建系统和性能仍需检查。

HIPIFY能自动完成全部迁移吗

不能。它可以转换部分语法和API，但不会处理所有库、inline PTX、构建系统、正确性和性能问题。

PyTorch模型是否需要修改代码

只使用标准PyTorch算子的模型可能改动较少，但自定义CUDA扩展、量化库和注意力插件仍需核验。

NCCL可以直接在AMD GPU上使用吗

AMD多卡通信通常使用RCCL。框架可能保持相似接口，但底层库、拓扑和调优需要重新验证。

CUDA容器能直接改成ROCm容器吗

不能只替换基础镜像。驱动接口、框架包、库、编译器和设备插件均可能不同。

迁移后结果为什么不完全一致

不同GPU架构、数学库和浮点计算顺序会带来数值差异，应按预先定义的误差和业务质量阈值验收。

迁移项目最先应该做什么

先固定CUDA版本和基线，再盘点自定义CUDA、闭源库和框架依赖，选择代表性工作负载做PoC。

ROCm版本是不是越新越好

不一定。生产环境应使用目标GPU、操作系统、框架和OEM共同验证的版本组合。

方案咨询

需要把方案落到实际配置？

联系赋创获取算力、软件栈和交付路径建议。

咨询方案浏览指南