ROCm 兼容性避坑指南有哪些？

说起ROCm的兼容性坑，我真是有一肚子苦水要倒。去年心血来潮想拿那块闲置的RX 6800 XT跑点深度学习，结果整整折腾了两个周末，差点把系统重装三遍。现在回想起来，那些踩过的雷其实完全可以避开，只是当时没人告诉我这些。

显卡型号是第一道鬼门关

AMD的ROCm有个特别反直觉的地方：不是越新的卡支持越好，反而是专业计算卡MI系列和特定消费级卡才有完整支持。我当初就是没查清楚，以为RX 6800 XT好歹是上代旗舰，总该稳吧？结果ROCm 5.4直接不认，升级到5.7才勉强能跑，但某些算子还是会偷偷回退到CPU执行，速度暴跌。

最坑的是AMD的支持列表更新慢得要命。RDNA3架构的RX 7000系列在ROCm 5.x时代基本属于"能用但别认真"的状态，论坛里一堆人报崩溃。我的建议是：买卡前先上GitHub的ROCm issues区搜一圈，看看有没有人成功跑通你的具体型号，别光看官方文档里的"支持"二字。

驱动和内核版本是隐形杀手

Linux内核版本不对，ROCm能装上去但跑起来各种诡异错误。我遇到过hipMalloc返回成功但数据全零的情况，排查了半天发现是5.15内核和ROCm 5.7的内存管理有冲突，降级到5.4 LTS才解决。现在我的习惯是：ROCm Docker镜像里跑什么内核，宿主机就尽量保持一致，别自作聪明追新。

还有就是mesa驱动和ROCm驱动的冲突。如果你之前装过桌面环境的显卡驱动，ROCm的rock-dkms模块可能会加载失败。我的做法是干脆用服务器版Ubuntu，纯命令行环境，省得图形驱动来捣乱。

PyTorch版本匹配是精细活

ROCm的PyTorch不是随便装个官方whl就能用的。ROCm 5.7对应PyTorch 2.1，5.6对应2.0，版本错配会出现各种HIP error或者更恶心的静默错误——模型能加载，训练loss正常下降，但保存下来的权重文件损坏，复盘时才发现中间某层根本没在GPU上跑。

我现在固定用rocm/pytorch的Docker镜像，tag精确到小数点后两位，再也不敢自己pip install torch了。镜像启动命令也有讲究，必须加--device=/dev/kfd --device=/dev/dri --group-add=video，少一个都可能权限不足。

算子缺失的自救方案

有些PyTorch操作在ROCm上就是不存在，比如某些变种的torch.scatter_或者特定的RNN实现。第一次遇到时我傻眼了，报错信息模棱两可，去搜发现GitHub上挂着open状态的issue。

现在的应对策略是：复杂模型先跑一遍torch.jit.trace，看能不能完整追踪；遇到不支持的算子，要么找替代实现（比如用torch.index_add换掉scatter），要么写个CPU fallback的wrapper。最狠的一次，我把一个自定义CUDA扩展用hipify工具转换，手动改了三十多行才编译通过——那感觉就像把英语作文机翻成日语再润色，处处是惊喜。

调试工具聊胜于无

ROCm的rocgdb比起cuda-gdb简直像半成品。断点能下，但变量经常显示<optimized out>，watchpoint一多就卡死。我现在调试主要靠printf大法，配合rocprof做性能分析，勉强能定位瓶颈。好消息是ROCm 6.0之后工具链改善不少，坏消息是我的RX 6000系列在6.0上又被降格为"社区支持"了。

说到底，ROCm适合愿意折腾、有明确AMD硬件在手、且模型不太复杂的人。如果你只是想复现个SOTA模型，NVIDIA仍然是唯一省心的选择。但要是像我一样，看着电费账单心疼，或者单纯想支持开源生态，这些坑踩过去之后，ROCm倒也算是个能用的选项——只是记得，多备份，常快照，遇到问题先怀疑兼容性。