环境准备：别让基础依赖成了拦路虎
在 AMD 平台上折腾 PyTorch 源码编译，最让人头疼的往往不是复杂的算法逻辑，而是那些看似不起眼的环境依赖。很多开发者一上来就直接拉代码编译，结果报一堆找不到库的错误，半天才发现是基础工具链没装对。要想顺利跑通 ROCm 7.x 下的编译流程，第一步必须是把地基打牢。
首先，操作系统建议锁定在 Ubuntu 22.04 LTS 或更新版本，老内核对新硬件的调度支持实在不敢恭维。系统就绪后，别急着装 Python 包，先检查编译器版本。ROCm 7.x 对 GCC 和 Clang 有明确偏好，GCC 11 或 Clang 15 是目前验证过最稳妥的组合。你可以用gcc --version快速确认，如果系统默认版本不对，务必通过update-alternatives切换，否则后续链接阶段大概率会挂。
接下来是构建工具的安装顺序，这一步很有讲究。必须先安装ninja和wheel，再处理其他依赖。ninja能显著加速编译过程，尤其是在多核 CPU 上，而wheel则是打包生成的二进制文件所必需的。命令很简单：
sudoapt-getupdatesudoapt-getinstallninja-build python3-wheel还有一个容易被忽视的关键点是hipblaslt库。在 ROCm 7.x 中，这个库的版本必须与驱动严格匹配。如果版本冲突，编译时会报undefined reference错误。建议在安装 PyTorch 依赖前，先运行rocminfo确认当前驱动版本，然后去 AMD 官方源拉取对应版本的hipblaslt-devel包，千万别随便找个第三方 deb 包凑合，那简直是给自己埋雷。
最后，强烈建议使用 Conda 创建独立的虚拟环境。系统自带的 Python 环境往往混杂着各种全局包，极易引发依赖冲突。创建一个干净的 Python 3.10 环境，能让后续的报错排查难度降低一半。
核心步骤：架构变量决定生死
环境搭好后，终于到了重头戏：设置环境变量并启动编译。这里有一个绝对无法绕开的“生死线”——PYTORCH_ROCM_ARCH。这是整个编译过程中最关键的一步，也是绝大多数人踩坑的地方。
AMD GPU 的架构代号非常具体，比如 MI300 系列对应的是gfx942，MI250 是gfx90a。如果你在编译前没有显式指定这个变量，PyTorch 可能会默认编译成一个通用版本，或者错误地适配了其他架构。后果就是：编译过程看似成功，但一运行代码就报Illegal instruction（非法指令），程序直接崩溃。这种错误极其隐蔽，因为编译日志里通常不会有任何警告。
正确的做法是在激活 Conda 环境后，立即导出该变量。假设你使用的是 MI300X 显卡，命令如下：
exportPYTORCH_ROCM_ARCH=gfx942如果有多种架构的卡混用，可以用分号分隔，例如gfx90a;gfx942，但生产环境最好专卡专用。设置完这个变量后，还需要告诉编译器 HIP 的路径，通常 ROCm 安装在/opt/rocm，所以还要补充：
exportHIP_PATH=/opt/rocm一切就绪后，就可以开始克隆 PyTorch 源码了。记得使用--recursive参数拉取子模块，否则会因为缺少第三方库而失败。进入目录后，不要直接运行pip install .，那样太慢且容易中断。推荐设置MAX_JOBS环境变量来利用所有 CPU 核心加速编译：
exportMAX_JOBS=$(nproc)pipinstall-v.加上-v参数能看到详细的编译输出，一旦出错能立刻定位到是哪个算子出了问题。整个过程可能需要半小时以上，期间不要随意终止，否则清理缓存重新来过更浪费时间。
避坑实录：常见报错与急救方案
即便前面步骤都完美，编译过程中还是可能冒出一些奇怪的报错。根据实战经验，以下三个问题出现频率最高，准备好解决方案能帮你节省大量调试时间。
首先是链接器找不到 HIP 库。报错信息通常是ld: cannot find -lhip_runtime。这多半是因为LD_LIBRARY_PATH没包含 ROCm 的 lib 目录。临时解决可以在命令前加export LD_LIBRARY_PATH=/opt/rocm/lib:$LD_LIBRARY_PATH，但为了长治久安，最好把这行写入~/.bashrc并 source 生效。
其次是算子不匹配的段错误。如果在运行简单测试如import torch; print(torch.randn(10).to('cuda'))时直接 Segmentation Fault，大概率是之前提到的架构变量设错了，或者中间更换过显卡却没清理构建缓存。这时候别犹豫，直接执行rm -rf build/和python setup.py clean，彻底清除旧的二进制文件，然后重新指定正确的PYTORCH_ROCM_ARCH再次编译。
最后是Triton 依赖冲突。PyTorch 2.x 强依赖 Triton 编译器，而在 ROCm 环境下，Triton 的版本必须与 PyTorch 严格对应。如果 pip 自动安装了最新版 Triton，可能会导致内核编译失败。遇到这种情况，建议先去 PyTorch 官方发布的 wheel 索引页查找推荐的 Triton 版本号，强制安装特定版本，例如pip install triton==2.1.0（具体版本视 PyTorch 版本而定）。
编译完成后，务必做一次深度验证。除了基础的torch.cuda.is_available()（在 ROCm 中通常也兼容此接口），最好跑一个简单的矩阵乘法测试，观察rocm-smi中的 GPU 利用率是否飙升。如果利用率起来了且无报错，恭喜你，这套亲手编译的 PyTorch 已经可以在你的 AMD 显卡上全速奔跑了。
200小时GPU算力已就位，快来领取：https://marketing.csdn.net/questions/Q2604140858304426315?utm_source=AIpaper
