第一天：环境配置的“下马威”

刚把那张二手的 Instinct MI250X 插进工作站，满怀期待地准备迎接 ROCm 7.x 的新时代，结果现实立刻给了我一记响亮的耳光。按照官方文档敲完安装命令，兴冲冲地运行 python -c "import torch; print(torch.cuda.is_available())"（哦不对，在 AMD 这边得是 torch.rocm 相关检查），终端直接抛出一行刺眼的红色报错：RuntimeError: HIP compiler not found。

那一刻心态差点崩了。明明驱动装好了，rocm-smi 也能看到卡，为什么编译器就是找不到？翻遍了官方文档的“快速开始”章节，发现它默认假设你的环境变量完美无缺。但真实世界哪有这么理想？

问题定位：系统虽然安装了 ROCm 工具链，但默认的 $PATH 并没有包含 /opt/rocm/bin，更致命的是，PyTorch 在编译扩展时需要明确知道 hipcc 的位置。

解决实录：
别急着重装驱动，先检查环境变量。我在 ~/.bashrc 里补上了这几行，瞬间豁然开朗：

export PATH=/opt/rocm/bin:$PATH
export LD_LIBRARY_PATH=/opt/rocm/lib:$PATH
# 关键一步：显式指定架构，避免自动检测失败
export PYTORCH_ROCM_ARCH=gfx90a

保存后执行 source ~/.bashrc，再跑测试代码，那个熟悉的 True 终于打印出来了。如果你是在 DevCloud 或者非标准路径下部署，记得用 which hipcc 确认一下二进制文件的实际位置，不要盲目照搬网上的路径。

第三天：算子不支持的“至暗时刻”

环境通了，接下来就是跑大模型推理。我选用了社区热度很高的 vLLM 项目，想着它能最大化显存利用率。结果加载模型到一半，程序直接崩溃，日志里躺着一行让人头大的错误：RuntimeError: 'addmm' is not implemented for 'Half' on ROCm 或者类似的算子缺失报错。

这是因为某些特定的 PyTorch 算子在 ROCm 的特定版本或特定 GPU 架构上还没有完全落地，尤其是涉及到 FP16 混合精度计算时。官方预编译的 wheel 包为了通用性，往往裁剪掉了一些边缘情况的支持。

避坑指南：
这时候千万别怀疑自己的代码逻辑，问题出在编译参数上。对于 Instinct 系列显卡，特别是 gfx90a 架构，必须在构建 vLLM 或 PyTorch 扩展时强制开启对应的架构支持。

我是通过重新构建 vLLM 解决的，命令如下：

pip uninstall vllm -y
PYTORCH_ROCM_ARCH=gfx90a pip install vllm --no-build-isolation

如果还是报错，可能需要从源码编译 PyTorch。这步很痛苦，但没办法。在 setup.py 配置中，确保 TORCH_CUDA_ARCH_LIST（ROCm 下同理）包含了你的显卡算力值。对于 MI250X，gfx90a 是必须的；如果是最新的 MI300 系列，则可能需要 gfx942。记住，不要相信自动检测，手动指定是最稳妥的。

第五天：显存分配失败的“玄学”

好不容易跑通了推理，想试试多卡并行。启动脚本刚运行，还没看到第一个 token 输出，进程就被 OOM Killer 干掉了，系统日志里冷冷地写着：HSA_ERROR: Out of memory 或者 hipErrorOutOfMemory。

奇怪的是，rocm-smi 显示显存明明还有大量剩余。这就是 ROCm 早期版本中常见的显存碎片化问题，或者是 HIP 运行时对显存管理的策略过于保守，导致无法分配连续的大块显存给 KV Cache。

实战调整：
这个问题不能硬扛，得通过调整启动参数来“哄”着运行时工作。针对 vLLM，有几个关键参数能救命：

1. 限制 GPU 内存利用率：默认值往往太激进。

   python -m vllm.entrypoints.api_server \
     --model <your_model> \
     --gpu-memory-utilization 0.85 \
     --block-size 16
   

   将 gpu-memory-utilization 从默认的 0.9 降到 0.85 甚至 0.8，留出一点缓冲空间给内核开销，往往能奇效般地解决 OOM。

2. 调整 Block Size：在某些场景下，将 block-size 设置为 16 或 32 比默认的 8 更能减少碎片。

3. 禁用部分优化：如果依然不稳定，尝试关闭 PagedAttention 的一些激进特性，或者在环境变量中设置 HSA_FORCE_FINE_GRAIN_PCIE=1，强制细化 PCIe 粒度，虽然可能轻微影响带宽，但换来了稳定性。

尾声：踩坑是为了更好地前行

这一周下来，屏幕前的报错日志从最初的“天书”变成了现在的“老朋友”。从 HIP 编译器路径的缺失，到算子支持的架构指定，再到显存分配的精细调优，每一个红色的 Error 背后，都是 ROCm 生态正在快速迭代的证明。

其实，很多问题的解法并不复杂，关键在于不要被官方的“完美文档”束缚住手脚。真实的开发环境总是充满变量，学会阅读报错堆栈，理解 HIP 运行的底层逻辑，比单纯复制粘贴命令更重要。现在，看着终端里不断刷新的生成内容，那些熬夜查文档、改环境变量的日子，似乎也变得有价值起来。如果你也在 ROCm 的路上遇到了类似的拦路虎，不妨停下来看看日志，答案往往就藏在那些被忽略的细节里。