驱动安装后的“静默”陷阱设备节点与权限校验很多新手在按照官方文档敲完apt install后兴冲冲地运行推理脚本结果却报出Device not found或权限拒绝的错误。这时候千万别急着重装系统大概率是用户组权限没配置到位。ROCm 驱动虽然装上了但当前用户并没有操作 GPU 硬件的“钥匙”。最典型的症状是运行rocm-smi命令时没有任何输出或者提示权限不足。解决这个问题的动作非常简单但极易被忽略执行sudo usermod -aG video,render $USER将当前用户加入video和render这两个关键用户组。注意这一步做完必须重启系统才能生效仅仅重新登录终端是不够的。重启后再次运行rocm-smi如果能看到清晰的显卡列表、温度、功耗和显存占用信息说明内核态驱动已经正常接管硬件。此外还要顺手检查/dev/kfd和/dev/dri这两个设备节点是否存在。如果这两个文件缺失说明内核模块加载失败可能需要检查内核版本是否与 ROCm 7.x 匹配推荐 Ubuntu 22.04 LTS或者查看dmesg日志中是否有 AMDGPU 相关的报错。编译环境的“隐形杀手”架构代码与编译器版本当你信心满满地开始源码编译 PyTorch 或 vLLM 时可能会遇到编译成功但运行时直接报Illegal instruction非法指令的情况。这通常是因为编译过程中没有指定正确的 GPU 架构代码导致生成的二进制文件包含了当前硬件不支持的指令集。在 ROCm 环境下环境变量PYTORCH_ROCM_ARCH是生死线。你必须根据具体的显卡型号手动导出该变量。例如对于 MI300 系列通常需要设置为gfx942对于 MI250X则是gfx90a。如果不确定自己的卡对应什么代码可以先运行rocminfo | grep gfx查看系统识别到的架构名称然后将其填入环境变量exportPYTORCH_ROCM_ARCHgfx942另一个高频坑点是编译器版本。ROCm 7.x 对工具链比较挑剔GCC 11 或 Clang 15 是比较稳妥的选择。如果你的系统默认安装了 GCC 12 或更高版本链接阶段很可能会报错。建议使用update-alternatives切换系统默认编译器或者在编译命令中显式指定CC和CXX路径。依赖冲突引发的段错误Triton 与 HIP 路径在部署 vLLM 时很多人直接使用pip install vllm结果在加载模型时遭遇莫名其妙的段错误Segmentation Fault。这往往是因为 vLLM 强依赖的 Triton 编译器版本与当前安装的 PyTorch ROCm 后端不匹配或者是 HIP 库的路径没有被正确识别。首先确保在安装 vLLM 之前已经正确设置了HIP_PATH。通常情况下它应该指向/opt/rocmexportHIP_PATH/opt/rocmexportLD_LIBRARY_PATH$HIP_PATH/lib:$LD_LIBRARY_PATH其次Triton 的版本必须严格对应。不要盲目安装最新版 Triton最好参考 vLLM 官方文档中针对 ROCm 推荐的特定版本号。如果是在源码编译 vLLM建议加上--no-build-isolation参数让它直接使用环境中已安装的依赖避免 pip 自动拉取不兼容的隔离包。如果编译过程中报错找不到hipblaslt等库记得检查LD_LIBRARY_PATH是否包含了 ROCm 的 lib 目录这是链接器寻找动态库的唯一依据。显存管理的“最后一根稻草”OOM 与碎片化环境搭好了模型也加载了但一并发请求就崩溃报错CUDA out of memory在 ROCm 下同理。这是因为大模型推理对显存极其敏感而 vLLM 的 PagedAttention 机制虽然高效默认配置却可能过于激进。新手常犯的错误是将--gpu-memory-utilization设置为默认的 0.9 甚至更高。在 AMD 平台上建议保守一点将其设置为0.90到0.92之间。预留出的 8%-10% 显存是给驱动程序、操作系统以及瞬时峰值缓冲用的这点余量往往是防止服务崩溃的关键。另外显存碎片化也是隐形杀手。如果业务场景中请求的序列长度差异很大可以尝试调整--block-size参数。较小的 block size如 16能提高细粒度利用率适合短文本较大的 block size如 64则能减少管理开销适合长文本。通过benchmark_serving.py模拟真实流量观察不同配置下的显存水位找到那个既能跑满显存又不溢出的平衡点。多卡并行的通信迷局拓扑结构与进程绑核当单卡显存不够需要开启张量并行Tensor Parallelism时新的问题又来了多卡加速比远低于预期甚至不如单卡快。这通常是因为卡间通信走了低速通道或者 CPU 资源发生了争抢。在 ROCm 环境下务必确认所有参与计算的 GPU 位于同一 PCIe 根复合体下或者通过 Infinity Fabric 互联。可以使用rocm-smi --showtopo查看拓扑结构。如果卡片之间通信需要经过 CPU 桥接延迟会显著增加。此外进程绑核CPU Affinity常被忽视。默认情况下多个推理进程可能会抢占同一个 CPU 核心导致上下文切换开销巨大。建议使用numactl工具将每个推理进程绑定到对应的 NUMA 节点上。例如numactl--cpunodebind0--membind0python-mvllm.entrypoints.api_server...这样能确保每个 GPU 都有独立的 CPU 核心和内存通道支持从而在多卡场景下获得接近线性的吞吐提升。记住排查问题时先看rocm-smi的状态再查编译器架构最后调显存和拓扑这套流程能帮你避开 90% 的坑。200小时GPU算力已就位快来领取https://marketing.csdn.net/questions/Q2604140858304426315?utm_sourceAIpaper