1. 先搞清楚ROCm 10 和我过去认识的 ROCm 有什么不同看到 AMD ROCm 10 这个版本号时我这种从 ROCm 3.x 一路手动补丁装到 6.x 的“老折腾”多少是有点怀疑的。以前在 AMD 平台上跑 AI最痛苦的不是卡而是“环境比模型还难装”。 ROCm、HIP、MIOpen、显卡驱动、PyTorch 版本之间稍微错开一点后面就能浪费一整天。这次把环境整体切到带 ROCm.AI 的 ROCm 10 完整栈后我的第一感觉是AMD 终于不是只给你一堆零件而是给了你一套像样的、为 AI 场景拼装好的开发体验。如果你手里有 AMD 显卡想在本地跑 PyTorch、Transformer 这类模型或者被 CUDA 生态绑得难受这篇文章应该能帮你少走不少弯路。接下来我会把 ROCm 和 ROCm.AI 的关系拆开讲再从零走一遍环境搭建、核心代码编写、模型运行、性能监控和问题排障把我实际踩过的坑和判断方法都放到里面。1.1 ROCm.AI 是名字升级还是真换了一套东西先说结论ROCm 和 ROCm.AI 不是同一个层次的概念。ROCm 是 AMD 开源 GPU 计算平台的“总称”包括驱动层、KFD 内核模块、LLVM 编译器后端、HIP 编程模型、各种数学库、调试和性能工具。而 ROCm.AI 是站在 ROCm 之上的 AI 软件栈通常会把 HIP 编译器、rocBLAS、hipBLASLt、MIOpen、MIGraphX、RCCL 这些和大模型、卷积、矩阵运算强相关的组件打包在一起并且针对 PyTorch、JAX、vLLM 这类 AI 框架做版本对齐。很多人在网上吐槽“ROCm 太难装”其实吐槽的不是底层驱动而是历史上组件之间依赖太散。今天装一套 PyTorch明天换个库可能就要手动去翻一个叫librocblas.so的东西是不是缺了。ROCm.AI 的出发点就是尽量解决这种碎片化。到了 ROCm 10 这个版本AI 相关组件的版本被集中管理安装器也能一次把推理、训练常用库都拉进来。给我的感觉像以前做嵌入式开发要自己拼交叉编译链现在人人都有现成 SDK 了。从这个角度看ROCm 10 并不是简单把版本号跳到 10而是把“AI 原生开发体验”当成核心设计目标。也就是你拿到一块 AMD 显卡装好环境后第一反应应该是“我可以直接写 PyTorch 或者 HIP 了”而不是“我该去哪找驱动、库和示例代码”。1.2 为什么说“AI 原生”是个实打实的变化你如果以前只用过 NVIDIA CUDA可能不太理解“AI 原生”有什么可吹的。CUDA 发展了十几年深度学习框架基本上把 CUDA 当作第一优先适配目标。AMD 的 ROCm 早期更多服务传统 HPC也就是 MPI、OpenMP、科学计算那一挂。那类程序的特点是编译一次跑很久动态分支少对形状固定的 kernel 优化非常执着。但 AI 工作负载不太一样。深度学习中你会频繁碰到动态 shape、小算子、PyTorch 的 eager 模式、即时编译甚至要跑很多融合 kernel。一个 AI 框架能否在 AMD 上跑出效率取决于底层库和编译器能不能“适应”这种碎片化的计算模式。ROCm.AI 要做的就是把底层库、框架支持、容器镜像和编译器后端都对齐到 AI 场景上。我用 ROCm 10 跑 PyTorch 模型时的感受是过去那种“明明检测到了 GPU但算子一个接一个退回 CPU”的诡异情况明显减少了。另一个很典型的变化是安装完rocm、hipruntime、mllib等相关组件后系统里自带的支持库完整度比以前高很多。你不需要为了一个模型再去网上搜某个.so文件放到/opt/rocm/lib。1.3 对开发者来说真正值得关注的几个变化我觉得有三类变化最能影响日常使用。第一组件版本号统一安装路径更明确。第二HIP 与 PyTorch 的适配窗口更对齐跨版本踩坑变少。第三验证工具更完整rocm-smi和新的amd-smi都在持续更新能看到 GPU 利用率、显存、温度这些关键状态。但这不意味着 ROCm 10 是“不用学习就能无缝迁移”。比如很多框架里依然写着torch.cuda、CUDA_VISIBLE_DEVICES这会在后面详细讲。很多人第一次看见这些名字会觉得很奇怪我们不是在 AMD 平台吗为什么还会有 CUDA这是历史遗留也是现实我们需要把它理解清楚否则很容易在迁代码时被误导。2. 在 AMD 平台从零搭环境这一次我终于不用“接十五个补丁”如果你之前从来没在 Linux 上装过 ROCm那我建议你直接按照完整的标准流程来。别一上来就学我当年从某个博客复制一段安装命令装完发现版本对不上再手动 patch 半天然并卵。2.1 硬件支持与系统准备ROCm 10 对硬件有明确的官方支持范围但总有人拿它跑不在列表里的老显卡。我的原则是如果你是科学计算或者 AI 开发用途优先看官方支持矩阵而不是只看“这卡是不是 AMD”。消费级 Radeon 显卡这几年在 ROCm 下的可用性提升不少但小众型号和过老架构依然可能没有 tuned kernel跑起来表现会差很多。系统方面我建议用 Ubuntu 22.04 或 24.04 LTS。不是其他发行版不能跑而是 AMD 官方容器的基准、社区帖子、CUDA 迁移参考大多建立在 Ubuntu LTS 上。出了问题你能搜到更多案例。确认系统信息的几个命令可以先敲一遍lspci | grep -i radeon uname -a df -h /命令本身不难重点是提前确认内核版本和磁盘空间。ROCm 相关包非常占空间完整安装可能需要几十 GB别装到一半才想起/满了。若你以前装过旧版 ROCm 或者尝试过某些社区脚本我强烈建议先清理干净否则后续很容易出现库版本冲突。所谓清理不只是apt remove而是把/opt/rocm残留、amdgpu内核模块和 PyTorch 的旧 ROCm wheel 残留都处理掉。官方提供安装器后这部分工作已经简化但仍然不能跳过。2.2 安装 ROCm 10 SDK 与驱动在当前版本下最稳妥的方式是使用 AMD 官方仓库里的amdgpu-install安装器。命令我以自己常用的一套为例完整参数以你下载到的安装器版本为准sudo apt update sudo apt install amdgpu-install sudo amdgpu-install --usecaserocm,hipruntime,mllib sudo usermod -aG video,render $USER其中rocm是主体hipruntime提供 HIP 运行时mllib会把机器学习常用的 rocBLAS、MIOpen 一类库一起装好。你需要记住一点安装 ROCm 时不要只为了“能编译 HIP”装最小集因为你后面跑 AI 时大概率需要这些数学库缺了再去补很容易触发 ABI 不匹配。安装器跑完后最好重启一次系统确保amdgpu内核模块加载的是新版本。重启后可以看看id groups /opt/rocm/bin/rocm-smi hipcc --version如果你的用户不在video和render组里rocm-smi会报权限错误PyTorch 也无法访问 GPU。这是我见过最高频的新手问题比版本不匹配还常见。有些教程会让你直接export HIP_VISIBLE_DEVICES0或者用sudo跑那只能临时绕过真正要解决的是组权限。2.3 Docker 方式适合只想用现成 AI 镜像的人如果你不只是想开发而是想直接跑现成的推理服务、LLM 框架Docker 容器往往比裸机装环境更省心。ROCm 10 的官方容器和社区镜像已经把驱动的依赖、库、PyTorch 环境打好了你只要把宿主机 GPU 设备映射进去docker run -it --rm \ --device/dev/kfd --device/dev/dri \ --group-add video --group-add render \ rocm/dev-ubuntu-24.04:latest跑起来后用容器内的rocm-smi验证 GPU 是否可见。容器方式的优点是可重复、可分享缺点是如果你要在上面做底层性能调优会感觉隔了一层。所以我的习惯是双轨并行日常试验用容器写驱动级代码或者排查算子问题时回到宿主机。注意无论选哪种方式都别把宿主机上的/opt/rocm随意映射进 RO关键词不同版本的容器里。硬映射有时能跑但更多时候会产生“系统 APT 包版本和容器内库版本打架”的麻烦。3. 核心开发体验写代码、跑模型时真正感受到的 AI 原生环境装好只是第一步接下来才是最关键的在 ROCm 10 上写代码到底是一种什么体验。我会从三层来说分别是 HIP 底层编程、PyTorch 框架层、以及真实模型运行。3.1 在 ROCm 10 上写第一个 HIP 程序HIP 是 AMD 在 ROCm 生态里对标 CUDA 的编程模型语法上和 CUDA 有很强的相似性尤其适合有过 GPU 编程基础的人。下面是一个典型的 HIP vector add 示例我会把入口、显存分配、kernel 启动和校验都写完整#include hip/hip_runtime.h #include iostream #include vector __global__ void vec_add(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 1 20; std::vectorfloat h_a(n, 1.0f); std::vectorfloat h_b(n, 2.0f); std::vectorfloat h_c(n, 0.0f); 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)); hipMemcpy(d_a, h_a.data(), n * sizeof(float), hipMemcpyHostToDevice); hipMemcpy(d_b, h_b.data(), n * sizeof(float), hipMemcpyHostToDevice); int block 256; int grid (n block - 1) / block; vec_addgrid, block(d_a, d_b, d_c, n); hipMemcpy(h_c.data(), d_c, n * sizeof(float), hipMemcpyDeviceToHost); float max_error 0.0f; for (int i 0; i n; i) { max_error fmax(max_error, fabs(h_c[i] - 3.0f)); } std::cout max error: max_error std::endl; hipFree(d_a); hipFree(d_b); hipFree(d_c); return 0; }编译运行也很直接hipcc -O2 vec_add.cpp -o vec_add ./vec_add我在 ROCm 10 上编译这个示例时基本不需要设置额外路径因为hipcc已经从/opt/rocm里找到了 HIP 头文件和运行时库。新手容易踩的坑是直接把文件命名成.cu然后用hipcc去编看到报错后一头雾水。hipcc是根据文件后缀决定编译流程写 HIP 代码建议使用.cpp或者.hip.cpp。如果你是从 CUDA 代码迁移可以先跑hipify-perl做一次初转再人工修剩下不兼容的部分。3.2 PyTorch 的 ROCm 版本与 torch.cuda 兼容接口对大多数 AI 开发者来说真正高频写的不是 HIP而是 PyTorch。在 AMD 平台跑 PyTorch需要安装 ROCm 版 PyTorch wheel。关键问题是ROCm 版的 PyTorch 里你查设备时会发现torch.cuda.is_available()返回True甚至torch.device(cuda)也在跑。这不是 AMD 在“骗你”而是 PyTorch 内部的 device 抽象历史遗留。PyTorch 在最早期把 GPU 后端统一命名为 CUDA后来 HIP 后端为了保持调用方代码兼容也继续沿用torch.cuda这个入口。所以你在 AMD 平台看到cuda字样并不代表模型跑在 NVIDIA 上底层实际走的是 HIP/ROCm。我用一个简单脚本验证import torch print(torch:, torch.__version__) print(hip:, torch.version.hip) print(cuda available:, torch.cuda.is_available()) print(device name:, torch.cuda.get_device_name(0)) x torch.randn(3, 3, devicecuda) y torch.randn(3, 3, devicecuda) z x y print(result device:, z.device)输出里torch.version.hip是否非空是最直接的判断依据。如果你明明装了 AMD 驱动torch.cuda.is_available()却返回False不要急着怀疑显卡坏了先查一下你安装的 PyTorch wheel 到底是 CPU 版本还是 ROCm 版本。很多人从 PyTorch 官网默认下载链接拿到的包是 CPU 版或 CUDA 版放到 AMD 机器上当然检测不到设备。CUDA_VISIBLE_DEVICES这个环境变量在 ROCm 版 PyTorch 里也能用它的作用是控制 PyTorch 可见哪块 GPU。如果你在多卡服务器上跑任务ROCm 通常也能识别 RDMA 等价变量ROCR_VISIBLE_DEVICES但实际使用中不少框架只读取前者。最省事的做法是两者都设置成同一张卡别让它们互相冲突。3.3 小模型实测完整跑一次生成式模型的推理环境验证完后我通常会拿一个小规模生成模型做端到端测试。这样既能验证 MIOpen、rocBLAS 这些库真的被调用到了也能观察显存、温度等在真实负载下的表现。下面这段代码用的是 HuggingFace Transformers假设你已经把模型权重下载到本地。示例里我用 Qwen 0.5B 这种较小模型方便普通消费级显卡直接跑import torch from transformers import AutoTokenizer, AutoModelForCausalLM device cuda model_name Qwen/Qwen2.5-0.5B-Instruct tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name).to(device) prompt 请用一句话解释什么是 GPU inputs tokenizer(prompt, return_tensorspt).to(device) with torch.no_grad(): outputs model.generate( inputs.input_ids, max_new_tokens64, do_sampleFalse ) print(tokenizer.decode(outputs[0], skip_special_tokensTrue))第一次跑的时候不要因为卡顿几秒就以为是死机。ROCm 的 MIOpen 在遇到新的卷积或 attention 形状时可能做自动调优调优结果会缓存到本地后面执行会快很多。如果你发现同一个模型第一次跑很慢、第二次明显变快那不是玄学是缓存生效了。从这段代码的体验看ROCm.AI 栈在框架层的“原生感”已经比早期好很多。至少你不需要为了在 AMD 显卡上跑 HuggingFace 模型去改模型源码也不用担心torch.compile、model.forward这些常见写法动不动就掉到 CPU。4. 性能与稳定性别只看显存占用这类指标才是关键刚接触 GPU 计算的人最容易犯的错就是用显存占用来判断“显卡到底在不在 working”。显存占用高只能说明数据放上去了不代表计算单元在跑。要判断 AI 程序是否真的吃满 AMD 显卡你需要同时看 GPU 利用率、功耗、温度和显存带宽使用情况。4.1 用 rocm-smi 观察实时状态在 ROCm 10 上最快的方法还是rocm-smi --showtemp --showuse --showmeminfo vram这段命令会输出 GPU 温度、核心利用率和 VRAM 使用量。如果模型在跑GPU utilization 应接近 100%温度也会维持在一个稳定区间。如果你看到显存占用很大但 GPU utilization 只有个位数那基本说明程序在等待数据、反复同步或者某个子算子落到了 CPU。另一个常用命令是rocm-smi --showpower用来查看当前功耗。GPU 功耗上不去但利用率很高可能是模型太小、决策开销大功耗拉满但利用率波动很大可能是显存带宽或者数据加载成了瓶颈。针对大模型推理几个重要的观察点包括是否开了足够长的序列、是否反复分配释放临时张量、是否因为显存碎片导致无法使用更大的 batch。4.2 几个影响 AI 性能的隐藏开关在 AMD 平台上跑 PyTorch有几种性能相关开关经常被忽略。第一个是HSA_OVERRIDE_GFX_VERSION这个环境变量会把 ROCm 视为你当前 GPU 架构的外层覆盖到其他 gfx 版本。一些内核库或预编译 wheel 如果没有包含你当前架构的 kernel用它可以强行跑通。但我不建议在 ROCm 10 上“前置设好”这个变量。只有当程序报类似gfx1100 not found或 “Machine model is not supported” 的错而且你能确认库编译时针对的是另一款架构再通过类似下面的方式尝试export HSA_OVERRIDE_GFX_VERSION11.0.0 python3 your_model.py设置后如果模型能跑但性能很低不要惊讶因为你是让本来不匹配的 kernel 去执行未必走了最佳实现。真正想要效率还是要找官方支持或重新编译对应库。第二个容易被忽视的是 MIOpen 调优缓存。前面说过MIOpen 第一次可能自动找最快算子这个搜索可能耗时很长。如果你的任务有很多不同 shape自动调优反复触发会导致训练过程看起来像是“卡住”。常见做法是确认缓存目录~/.cache/miopen是否有执行权限以及在跑生产任务前先跑一轮小的 warm-up让缓存生成好。第三个是 NUMA 相关设置。如果你的机器是多路 CPUPCIe 设备可能挂在特定 NUMA 节点上。ROCm 编程里可以通过ROCR_VISIBLE_DEVICES固定在某张卡上同时保持进程在对应 NUMA 节点避免跨节点访问显存造成额外延迟。这个高级优化在裸机摸爬阶段可以不管但遇到“单卡没问题多卡性能无法线性扩展”时可以查一下。4.3 显存不够、空转和自己怎么定位AMD 显卡和 NVIDIA 一样torch.cuda.OutOfMemoryError在 ROCm 生态里也会出现。很多人以为这是“显存不够”导致的无解问题其实优先该做的是减小 batch size、开启 gradient checkpointing、把中间张量显式释放。还有一点经常被忽略PyTorch 的缓存分配器会占用显存但不一定立即释放代码跑完后再看显存占用依然很高是正常现象。空转问题比较麻烦。比如运行一个大模型时GPU utilization 不稳但 CPU 使用率又没到 100%这往往是 kernel launch 太频繁或者模型在 CPU 端有大量 Python 逻辑。要定位可以用rocm-smi和日志结合也可以把模型切到torch.compile模式观察是否因为编译图减少了 Python 层开销而提升。ROCm 10 对torch.compile的支持比旧版更主动值得尝试。5. 踩坑实录ROCm 10 的常见问题与解决速查我再怎么说得轻松实际使用时一定会遇到各种奇怪问题。这里把我在 ROCm 10 环境里遇到过的、以及身边人问得比较多的坑整理成速查表方便你对着排查。现象大概率原因解决思路重启后rocm-smi提示权限不足用户没加入 video/render 组sudo usermod -aG video,render $USER后重新登录hipcc命令找不到SDK 没装入 PATH或只装了底层驱动安装完整 rocm/hipruntime 组件检查/opt/rocm/binPyTorch 检测不到 GPU安装的是 CPU 版或 CUDA 版 wheel安装对应 ROCm 版 PyTorch用torch.version.hip验证容器里看不到/dev/kfd容器启动时没映射设备增加--device/dev/kfd --device/dev/dri第一次跑模型非常慢MIOpen 在做自动调优或正在编译 kernel等待完第一次或提前 warm-up 生成缓存训练中途刷新率低、GPU 掉卡驱动不稳定、过热或功耗问题先看 dmesg 中 amdgpu 报错检查温度和电源关掉手动超频跑旧项目时报gfx架构不支持预编译库未覆盖当前架构临时设置HSA_OVERRIDE_GFX_VERSION后续换用匹配库反复出现版本相关.so找不到安装时漏了 mllib / 数学库补齐--usecaserocm,hipruntime,mllib或改用官方容器5.1 驱动超时、GPU Hang 的定位思路很多 AMD 桌面显卡用户第一次跑 AI 时都会说“驱动超时了”。在 Windows 上那是图形驱动的 Timeout Detection Delay 机制在起作用它对长时间计算容易做出“显卡无响应”的判断。而在 Linux 上跑 ROCm更多情况是dmesg里出现amdgpu GPU reset一类的报错。遇到 GPU Hang先别重装按顺序做三件事。第一立刻看一眼日志sudo dmesg -T | grep -i amdgpu | tail -50 journalctl -k -f第二判断是在什么负载下触发的。如果只在跑某个大模型时出现优先怀疑显存不足、瞬时功率过高、或者某个自定义算子把 GPU 跑崩了。如果待机也掉那才考虑内核模块或电源问题。第三实验性地降低负载把 ROCm 10 AI原生开发：AMD GPU环境搭建与PyTorch实战指南
1. 先搞清楚ROCm 10 和我过去认识的 ROCm 有什么不同看到 AMD ROCm 10 这个版本号时我这种从 ROCm 3.x 一路手动补丁装到 6.x 的“老折腾”多少是有点怀疑的。以前在 AMD 平台上跑 AI最痛苦的不是卡而是“环境比模型还难装”。 ROCm、HIP、MIOpen、显卡驱动、PyTorch 版本之间稍微错开一点后面就能浪费一整天。这次把环境整体切到带 ROCm.AI 的 ROCm 10 完整栈后我的第一感觉是AMD 终于不是只给你一堆零件而是给了你一套像样的、为 AI 场景拼装好的开发体验。如果你手里有 AMD 显卡想在本地跑 PyTorch、Transformer 这类模型或者被 CUDA 生态绑得难受这篇文章应该能帮你少走不少弯路。接下来我会把 ROCm 和 ROCm.AI 的关系拆开讲再从零走一遍环境搭建、核心代码编写、模型运行、性能监控和问题排障把我实际踩过的坑和判断方法都放到里面。1.1 ROCm.AI 是名字升级还是真换了一套东西先说结论ROCm 和 ROCm.AI 不是同一个层次的概念。ROCm 是 AMD 开源 GPU 计算平台的“总称”包括驱动层、KFD 内核模块、LLVM 编译器后端、HIP 编程模型、各种数学库、调试和性能工具。而 ROCm.AI 是站在 ROCm 之上的 AI 软件栈通常会把 HIP 编译器、rocBLAS、hipBLASLt、MIOpen、MIGraphX、RCCL 这些和大模型、卷积、矩阵运算强相关的组件打包在一起并且针对 PyTorch、JAX、vLLM 这类 AI 框架做版本对齐。很多人在网上吐槽“ROCm 太难装”其实吐槽的不是底层驱动而是历史上组件之间依赖太散。今天装一套 PyTorch明天换个库可能就要手动去翻一个叫librocblas.so的东西是不是缺了。ROCm.AI 的出发点就是尽量解决这种碎片化。到了 ROCm 10 这个版本AI 相关组件的版本被集中管理安装器也能一次把推理、训练常用库都拉进来。给我的感觉像以前做嵌入式开发要自己拼交叉编译链现在人人都有现成 SDK 了。从这个角度看ROCm 10 并不是简单把版本号跳到 10而是把“AI 原生开发体验”当成核心设计目标。也就是你拿到一块 AMD 显卡装好环境后第一反应应该是“我可以直接写 PyTorch 或者 HIP 了”而不是“我该去哪找驱动、库和示例代码”。1.2 为什么说“AI 原生”是个实打实的变化你如果以前只用过 NVIDIA CUDA可能不太理解“AI 原生”有什么可吹的。CUDA 发展了十几年深度学习框架基本上把 CUDA 当作第一优先适配目标。AMD 的 ROCm 早期更多服务传统 HPC也就是 MPI、OpenMP、科学计算那一挂。那类程序的特点是编译一次跑很久动态分支少对形状固定的 kernel 优化非常执着。但 AI 工作负载不太一样。深度学习中你会频繁碰到动态 shape、小算子、PyTorch 的 eager 模式、即时编译甚至要跑很多融合 kernel。一个 AI 框架能否在 AMD 上跑出效率取决于底层库和编译器能不能“适应”这种碎片化的计算模式。ROCm.AI 要做的就是把底层库、框架支持、容器镜像和编译器后端都对齐到 AI 场景上。我用 ROCm 10 跑 PyTorch 模型时的感受是过去那种“明明检测到了 GPU但算子一个接一个退回 CPU”的诡异情况明显减少了。另一个很典型的变化是安装完rocm、hipruntime、mllib等相关组件后系统里自带的支持库完整度比以前高很多。你不需要为了一个模型再去网上搜某个.so文件放到/opt/rocm/lib。1.3 对开发者来说真正值得关注的几个变化我觉得有三类变化最能影响日常使用。第一组件版本号统一安装路径更明确。第二HIP 与 PyTorch 的适配窗口更对齐跨版本踩坑变少。第三验证工具更完整rocm-smi和新的amd-smi都在持续更新能看到 GPU 利用率、显存、温度这些关键状态。但这不意味着 ROCm 10 是“不用学习就能无缝迁移”。比如很多框架里依然写着torch.cuda、CUDA_VISIBLE_DEVICES这会在后面详细讲。很多人第一次看见这些名字会觉得很奇怪我们不是在 AMD 平台吗为什么还会有 CUDA这是历史遗留也是现实我们需要把它理解清楚否则很容易在迁代码时被误导。2. 在 AMD 平台从零搭环境这一次我终于不用“接十五个补丁”如果你之前从来没在 Linux 上装过 ROCm那我建议你直接按照完整的标准流程来。别一上来就学我当年从某个博客复制一段安装命令装完发现版本对不上再手动 patch 半天然并卵。2.1 硬件支持与系统准备ROCm 10 对硬件有明确的官方支持范围但总有人拿它跑不在列表里的老显卡。我的原则是如果你是科学计算或者 AI 开发用途优先看官方支持矩阵而不是只看“这卡是不是 AMD”。消费级 Radeon 显卡这几年在 ROCm 下的可用性提升不少但小众型号和过老架构依然可能没有 tuned kernel跑起来表现会差很多。系统方面我建议用 Ubuntu 22.04 或 24.04 LTS。不是其他发行版不能跑而是 AMD 官方容器的基准、社区帖子、CUDA 迁移参考大多建立在 Ubuntu LTS 上。出了问题你能搜到更多案例。确认系统信息的几个命令可以先敲一遍lspci | grep -i radeon uname -a df -h /命令本身不难重点是提前确认内核版本和磁盘空间。ROCm 相关包非常占空间完整安装可能需要几十 GB别装到一半才想起/满了。若你以前装过旧版 ROCm 或者尝试过某些社区脚本我强烈建议先清理干净否则后续很容易出现库版本冲突。所谓清理不只是apt remove而是把/opt/rocm残留、amdgpu内核模块和 PyTorch 的旧 ROCm wheel 残留都处理掉。官方提供安装器后这部分工作已经简化但仍然不能跳过。2.2 安装 ROCm 10 SDK 与驱动在当前版本下最稳妥的方式是使用 AMD 官方仓库里的amdgpu-install安装器。命令我以自己常用的一套为例完整参数以你下载到的安装器版本为准sudo apt update sudo apt install amdgpu-install sudo amdgpu-install --usecaserocm,hipruntime,mllib sudo usermod -aG video,render $USER其中rocm是主体hipruntime提供 HIP 运行时mllib会把机器学习常用的 rocBLAS、MIOpen 一类库一起装好。你需要记住一点安装 ROCm 时不要只为了“能编译 HIP”装最小集因为你后面跑 AI 时大概率需要这些数学库缺了再去补很容易触发 ABI 不匹配。安装器跑完后最好重启一次系统确保amdgpu内核模块加载的是新版本。重启后可以看看id groups /opt/rocm/bin/rocm-smi hipcc --version如果你的用户不在video和render组里rocm-smi会报权限错误PyTorch 也无法访问 GPU。这是我见过最高频的新手问题比版本不匹配还常见。有些教程会让你直接export HIP_VISIBLE_DEVICES0或者用sudo跑那只能临时绕过真正要解决的是组权限。2.3 Docker 方式适合只想用现成 AI 镜像的人如果你不只是想开发而是想直接跑现成的推理服务、LLM 框架Docker 容器往往比裸机装环境更省心。ROCm 10 的官方容器和社区镜像已经把驱动的依赖、库、PyTorch 环境打好了你只要把宿主机 GPU 设备映射进去docker run -it --rm \ --device/dev/kfd --device/dev/dri \ --group-add video --group-add render \ rocm/dev-ubuntu-24.04:latest跑起来后用容器内的rocm-smi验证 GPU 是否可见。容器方式的优点是可重复、可分享缺点是如果你要在上面做底层性能调优会感觉隔了一层。所以我的习惯是双轨并行日常试验用容器写驱动级代码或者排查算子问题时回到宿主机。注意无论选哪种方式都别把宿主机上的/opt/rocm随意映射进 RO关键词不同版本的容器里。硬映射有时能跑但更多时候会产生“系统 APT 包版本和容器内库版本打架”的麻烦。3. 核心开发体验写代码、跑模型时真正感受到的 AI 原生环境装好只是第一步接下来才是最关键的在 ROCm 10 上写代码到底是一种什么体验。我会从三层来说分别是 HIP 底层编程、PyTorch 框架层、以及真实模型运行。3.1 在 ROCm 10 上写第一个 HIP 程序HIP 是 AMD 在 ROCm 生态里对标 CUDA 的编程模型语法上和 CUDA 有很强的相似性尤其适合有过 GPU 编程基础的人。下面是一个典型的 HIP vector add 示例我会把入口、显存分配、kernel 启动和校验都写完整#include hip/hip_runtime.h #include iostream #include vector __global__ void vec_add(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 1 20; std::vectorfloat h_a(n, 1.0f); std::vectorfloat h_b(n, 2.0f); std::vectorfloat h_c(n, 0.0f); 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)); hipMemcpy(d_a, h_a.data(), n * sizeof(float), hipMemcpyHostToDevice); hipMemcpy(d_b, h_b.data(), n * sizeof(float), hipMemcpyHostToDevice); int block 256; int grid (n block - 1) / block; vec_addgrid, block(d_a, d_b, d_c, n); hipMemcpy(h_c.data(), d_c, n * sizeof(float), hipMemcpyDeviceToHost); float max_error 0.0f; for (int i 0; i n; i) { max_error fmax(max_error, fabs(h_c[i] - 3.0f)); } std::cout max error: max_error std::endl; hipFree(d_a); hipFree(d_b); hipFree(d_c); return 0; }编译运行也很直接hipcc -O2 vec_add.cpp -o vec_add ./vec_add我在 ROCm 10 上编译这个示例时基本不需要设置额外路径因为hipcc已经从/opt/rocm里找到了 HIP 头文件和运行时库。新手容易踩的坑是直接把文件命名成.cu然后用hipcc去编看到报错后一头雾水。hipcc是根据文件后缀决定编译流程写 HIP 代码建议使用.cpp或者.hip.cpp。如果你是从 CUDA 代码迁移可以先跑hipify-perl做一次初转再人工修剩下不兼容的部分。3.2 PyTorch 的 ROCm 版本与 torch.cuda 兼容接口对大多数 AI 开发者来说真正高频写的不是 HIP而是 PyTorch。在 AMD 平台跑 PyTorch需要安装 ROCm 版 PyTorch wheel。关键问题是ROCm 版的 PyTorch 里你查设备时会发现torch.cuda.is_available()返回True甚至torch.device(cuda)也在跑。这不是 AMD 在“骗你”而是 PyTorch 内部的 device 抽象历史遗留。PyTorch 在最早期把 GPU 后端统一命名为 CUDA后来 HIP 后端为了保持调用方代码兼容也继续沿用torch.cuda这个入口。所以你在 AMD 平台看到cuda字样并不代表模型跑在 NVIDIA 上底层实际走的是 HIP/ROCm。我用一个简单脚本验证import torch print(torch:, torch.__version__) print(hip:, torch.version.hip) print(cuda available:, torch.cuda.is_available()) print(device name:, torch.cuda.get_device_name(0)) x torch.randn(3, 3, devicecuda) y torch.randn(3, 3, devicecuda) z x y print(result device:, z.device)输出里torch.version.hip是否非空是最直接的判断依据。如果你明明装了 AMD 驱动torch.cuda.is_available()却返回False不要急着怀疑显卡坏了先查一下你安装的 PyTorch wheel 到底是 CPU 版本还是 ROCm 版本。很多人从 PyTorch 官网默认下载链接拿到的包是 CPU 版或 CUDA 版放到 AMD 机器上当然检测不到设备。CUDA_VISIBLE_DEVICES这个环境变量在 ROCm 版 PyTorch 里也能用它的作用是控制 PyTorch 可见哪块 GPU。如果你在多卡服务器上跑任务ROCm 通常也能识别 RDMA 等价变量ROCR_VISIBLE_DEVICES但实际使用中不少框架只读取前者。最省事的做法是两者都设置成同一张卡别让它们互相冲突。3.3 小模型实测完整跑一次生成式模型的推理环境验证完后我通常会拿一个小规模生成模型做端到端测试。这样既能验证 MIOpen、rocBLAS 这些库真的被调用到了也能观察显存、温度等在真实负载下的表现。下面这段代码用的是 HuggingFace Transformers假设你已经把模型权重下载到本地。示例里我用 Qwen 0.5B 这种较小模型方便普通消费级显卡直接跑import torch from transformers import AutoTokenizer, AutoModelForCausalLM device cuda model_name Qwen/Qwen2.5-0.5B-Instruct tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name).to(device) prompt 请用一句话解释什么是 GPU inputs tokenizer(prompt, return_tensorspt).to(device) with torch.no_grad(): outputs model.generate( inputs.input_ids, max_new_tokens64, do_sampleFalse ) print(tokenizer.decode(outputs[0], skip_special_tokensTrue))第一次跑的时候不要因为卡顿几秒就以为是死机。ROCm 的 MIOpen 在遇到新的卷积或 attention 形状时可能做自动调优调优结果会缓存到本地后面执行会快很多。如果你发现同一个模型第一次跑很慢、第二次明显变快那不是玄学是缓存生效了。从这段代码的体验看ROCm.AI 栈在框架层的“原生感”已经比早期好很多。至少你不需要为了在 AMD 显卡上跑 HuggingFace 模型去改模型源码也不用担心torch.compile、model.forward这些常见写法动不动就掉到 CPU。4. 性能与稳定性别只看显存占用这类指标才是关键刚接触 GPU 计算的人最容易犯的错就是用显存占用来判断“显卡到底在不在 working”。显存占用高只能说明数据放上去了不代表计算单元在跑。要判断 AI 程序是否真的吃满 AMD 显卡你需要同时看 GPU 利用率、功耗、温度和显存带宽使用情况。4.1 用 rocm-smi 观察实时状态在 ROCm 10 上最快的方法还是rocm-smi --showtemp --showuse --showmeminfo vram这段命令会输出 GPU 温度、核心利用率和 VRAM 使用量。如果模型在跑GPU utilization 应接近 100%温度也会维持在一个稳定区间。如果你看到显存占用很大但 GPU utilization 只有个位数那基本说明程序在等待数据、反复同步或者某个子算子落到了 CPU。另一个常用命令是rocm-smi --showpower用来查看当前功耗。GPU 功耗上不去但利用率很高可能是模型太小、决策开销大功耗拉满但利用率波动很大可能是显存带宽或者数据加载成了瓶颈。针对大模型推理几个重要的观察点包括是否开了足够长的序列、是否反复分配释放临时张量、是否因为显存碎片导致无法使用更大的 batch。4.2 几个影响 AI 性能的隐藏开关在 AMD 平台上跑 PyTorch有几种性能相关开关经常被忽略。第一个是HSA_OVERRIDE_GFX_VERSION这个环境变量会把 ROCm 视为你当前 GPU 架构的外层覆盖到其他 gfx 版本。一些内核库或预编译 wheel 如果没有包含你当前架构的 kernel用它可以强行跑通。但我不建议在 ROCm 10 上“前置设好”这个变量。只有当程序报类似gfx1100 not found或 “Machine model is not supported” 的错而且你能确认库编译时针对的是另一款架构再通过类似下面的方式尝试export HSA_OVERRIDE_GFX_VERSION11.0.0 python3 your_model.py设置后如果模型能跑但性能很低不要惊讶因为你是让本来不匹配的 kernel 去执行未必走了最佳实现。真正想要效率还是要找官方支持或重新编译对应库。第二个容易被忽视的是 MIOpen 调优缓存。前面说过MIOpen 第一次可能自动找最快算子这个搜索可能耗时很长。如果你的任务有很多不同 shape自动调优反复触发会导致训练过程看起来像是“卡住”。常见做法是确认缓存目录~/.cache/miopen是否有执行权限以及在跑生产任务前先跑一轮小的 warm-up让缓存生成好。第三个是 NUMA 相关设置。如果你的机器是多路 CPUPCIe 设备可能挂在特定 NUMA 节点上。ROCm 编程里可以通过ROCR_VISIBLE_DEVICES固定在某张卡上同时保持进程在对应 NUMA 节点避免跨节点访问显存造成额外延迟。这个高级优化在裸机摸爬阶段可以不管但遇到“单卡没问题多卡性能无法线性扩展”时可以查一下。4.3 显存不够、空转和自己怎么定位AMD 显卡和 NVIDIA 一样torch.cuda.OutOfMemoryError在 ROCm 生态里也会出现。很多人以为这是“显存不够”导致的无解问题其实优先该做的是减小 batch size、开启 gradient checkpointing、把中间张量显式释放。还有一点经常被忽略PyTorch 的缓存分配器会占用显存但不一定立即释放代码跑完后再看显存占用依然很高是正常现象。空转问题比较麻烦。比如运行一个大模型时GPU utilization 不稳但 CPU 使用率又没到 100%这往往是 kernel launch 太频繁或者模型在 CPU 端有大量 Python 逻辑。要定位可以用rocm-smi和日志结合也可以把模型切到torch.compile模式观察是否因为编译图减少了 Python 层开销而提升。ROCm 10 对torch.compile的支持比旧版更主动值得尝试。5. 踩坑实录ROCm 10 的常见问题与解决速查我再怎么说得轻松实际使用时一定会遇到各种奇怪问题。这里把我在 ROCm 10 环境里遇到过的、以及身边人问得比较多的坑整理成速查表方便你对着排查。现象大概率原因解决思路重启后rocm-smi提示权限不足用户没加入 video/render 组sudo usermod -aG video,render $USER后重新登录hipcc命令找不到SDK 没装入 PATH或只装了底层驱动安装完整 rocm/hipruntime 组件检查/opt/rocm/binPyTorch 检测不到 GPU安装的是 CPU 版或 CUDA 版 wheel安装对应 ROCm 版 PyTorch用torch.version.hip验证容器里看不到/dev/kfd容器启动时没映射设备增加--device/dev/kfd --device/dev/dri第一次跑模型非常慢MIOpen 在做自动调优或正在编译 kernel等待完第一次或提前 warm-up 生成缓存训练中途刷新率低、GPU 掉卡驱动不稳定、过热或功耗问题先看 dmesg 中 amdgpu 报错检查温度和电源关掉手动超频跑旧项目时报gfx架构不支持预编译库未覆盖当前架构临时设置HSA_OVERRIDE_GFX_VERSION后续换用匹配库反复出现版本相关.so找不到安装时漏了 mllib / 数学库补齐--usecaserocm,hipruntime,mllib或改用官方容器5.1 驱动超时、GPU Hang 的定位思路很多 AMD 桌面显卡用户第一次跑 AI 时都会说“驱动超时了”。在 Windows 上那是图形驱动的 Timeout Detection Delay 机制在起作用它对长时间计算容易做出“显卡无响应”的判断。而在 Linux 上跑 ROCm更多情况是dmesg里出现amdgpu GPU reset一类的报错。遇到 GPU Hang先别重装按顺序做三件事。第一立刻看一眼日志sudo dmesg -T | grep -i amdgpu | tail -50 journalctl -k -f第二判断是在什么负载下触发的。如果只在跑某个大模型时出现优先怀疑显存不足、瞬时功率过高、或者某个自定义算子把 GPU 跑崩了。如果待机也掉那才考虑内核模块或电源问题。第三实验性地降低负载把