环境初始化权限与驱动的双重校验拿到一台预装好 AMD Instinct GPU 的 DevCloud 实例很多开发者习惯直接跳进 Docker 或者开始 pip install这往往是后续“环境地狱”的根源。在 Ubuntu 22.04 LTS 环境下ROCm 7.x 对内核的依赖非常明确但最容易被忽视的是用户组权限。系统安装完成后第一件事不是装驱动而是确认当前用户是否拥有调用 GPU 硬件的资格。ROCm 的内核驱动通过/dev/kfd和/dev/dri设备节点暴露接口默认情况下普通用户是无权访问的。如果跳过这一步后续所有涉及 GPU 的计算任务都会报Permission denied或者静默失败。执行以下命令将当前用户加入video和render组sudousermod-aGvideo,render$USER注意执行完必须重启系统sudo reboot否则组策略不会生效。这是无数人踩过的坑别试图用newgrp临时切换重启是最稳妥的方案。重启后不要急着验证 PyTorch先用原生工具链检查驱动状态。运行rocm-smi如果能看到清晰的显卡列表、温度、功耗以及显存使用率说明内核态驱动工作正常。如果输出为空或报错检查/dev/kfd是否存在。紧接着运行rocminfo重点查看输出的Agent信息确认识别到的架构代码如gfx90a对应 MI250Xgfx942对应 MI300X与你手中的硬件型号一致。这一步能提前规避 80% 因架构不匹配导致的“非法指令”错误。源码编译架构代码与依赖陷阱虽然 PyTorch 提供了预编译的 ROCm 版本但在生产环境中为了获得针对特定架构的最佳算子性能源码编译是必经之路。这也是整个流程中最容易“翻车”的环节。首先创建一个干净的 Conda 环境避免污染系统 Python。安装构建依赖时除了常规的ninja、wheel务必确认编译器版本。ROCm 7.x 通常对 GCC 11 或 Clang 15 支持最好版本过高可能导致链接错误。最关键的步骤在于设置环境变量。在编译 PyTorch 之前必须显式指定PYTORCH_ROCM_ARCHexportPYTORCH_ROCM_ARCHgfx942# 根据 rocminfo 结果替换为你的架构代码exportMAX_JOBS$(nproc)# 利用多核加速编译如果忽略这个变量PyTorch 可能会编译成通用版本或者错误的架构版本运行时直接崩溃且没有任何友好的错误提示只会抛出一个神秘的Illegal instruction。接着开始编译gitclone--recursivehttps://github.com/pytorch/pytorch.gitcdpytorch# 切换到稳定的 release 分支例如 v2.4.0gitcheckout v2.4.0 python setup.pyinstallPyTorch 编译完成后验证环节同样有讲究。在 ROCm 环境下虽然部分接口兼容 CUDA 命名但建议使用torch.rocm.is_available()或直接尝试分配张量到cuda设备取决于具体版本的别名映射来测试。接下来是 vLLM 的编译。vLLM 强依赖 Triton 编译器必须确保安装的 Triton 版本与当前 PyTorch 后端严格匹配否则会出现严重的段错误。在安装 vLLM 时同样需要传入 HIP 路径exportHIP_PATH/opt/rocm pipinstallvllm --no-build-isolation遇到kernel not found或链接报错时大概率是缓存问题。清理build/目录和__pycache__重新指定架构代码编译通常能解决问题。不要盲目升级依赖库有时候回退到一个稳定的 Triton 版本比追逐最新版更有效。显存优化与服务启动实战环境就绪后真正的挑战在于如何让大模型跑起来且不爆显存。vLLM 的核心优势在于 PagedAttention 技术它将 KV Cache 的管理粒度细化到了块级别极大地减少了显存碎片。但在 AMD 平台上参数的微调依然关键。启动服务时--gpu-memory-utilization是最敏感的参数。很多文档建议设为 0.95但在实际生产中我建议控制在0.90 到 0.92之间。ROCm 驱动本身需要一定的显存开销用于上下文切换和缓冲区留得太少极易导致瞬时峰值触发 OOM内存溢出让服务直接崩溃。针对显存碎片化可以通过--block-size调整。对于长文本场景较大的 block size如 32 或 64能减少管理开销而对于短文本高并发场景较小的 block size 利用率更高。此外如果模型支持开启--quantization fp8不仅能减半显存占用还能显著提升推理吞吐前提是确认当前 ROCm 版本已完整支持该量化算子。下面是一个典型的启动命令示例假设我们要部署一个 70B 的模型并使用双卡并行vllm serve /path/to/model\--host0.0.0.0\--port8000\--tensor-parallel-size2\--gpu-memory-utilization0.90\--block-size16\--dtypebfloat16启动过程中密切观察日志。当看到 “Uvicorn running on…” 且没有显存报错时服务才算真正拉起。此时可以用curl发送一个简单的请求测试curlhttp://localhost:8000/v1/completions\-HContent-Type: application/json\-d{model: your-model, prompt: Hello, max_tokens: 10}如果返回流畅且延迟在预期范围内恭喜你已经跨过了最难的门槛。后续只需结合benchmark_serving.py进行压力测试根据 RPS 和 TTFT 指标微调--max-num-seqs即可。从权限配置到源码编译再到显存调优这套流程虽然繁琐但一旦跑通AMD 平台的高性价比优势便能真正转化为生产力。200小时GPU算力已就位快来领取https://marketing.csdn.net/questions/Q2604140858304426315?utm_sourceAIpaper