MI50 32G 跑大模型：Ubuntu 驱动安装与推理部署避坑指南

1. 为什么我选择 MI50 32G 来跑大模型

1.1 一张被低估的“矿渣”计算卡

MI50 这张卡在二手市场上的价格一直很魔幻。它是 AMD 在 2018 年前后推出的数据中心级加速卡，基于 Vega 20 核心，7nm 工艺，HBM2 显存，32G 版本的理论带宽能到 1TB/s 左右。这个显存容量放在今天，跑 7B、13B 甚至部分 34B 的量化模型都绰绰有余，而价格往往只有同显存容量专业卡的零头。

我最初注意到它，是因为手头有一台闲置的塔式服务器，想拿来做一个本地的推理节点。需求很明确：显存要大、能塞进标准机箱、功耗别太离谱、驱动能跑起来。MI50 32G 恰好卡在这个交叉点上。它不像消费级显卡那样显存捉襟见肘，也不像 newer 的专业卡那样价格劝退。对于想折腾本地大模型部署、又不想在硬件上砸太多预算的人来说，这是一个非常现实的选项。

但现实很快给了我一巴掌。MI50 是 AMD 的数据中心卡，官方驱动栈是 ROCm，而 ROCm 在 Ubuntu 上的安装体验，和 NVIDIA 那套 CUDA 生态比起来，完全是两个世界。网上关于 MI50 的资料零散、过时、互相矛盾，很多教程默认你用的是官方支持的 Instinct 系列，或者干脆是 Radeon VII 这种消费卡改的。真正从零开始、在 Ubuntu 上把 MI50 驱动跑通、再部署大模型的完整记录，少得可怜。

所以这篇东西，就是把我踩过的坑、试过的方案、最终跑通的路径，原原本本记下来。目标读者是那些手里有 MI50（或者类似的老 AMD 计算卡）、想在 Ubuntu 上跑本地大模型、但被驱动和框架折腾得头大的人。我会尽量把每一步的“为什么”讲清楚，而不是只丢一堆命令让你抄。

1.2 大模型本地部署对硬件的真实需求

在聊驱动之前，先得把需求理清楚。本地部署大模型，到底吃的是什么资源？

第一是显存容量。模型权重、KV Cache、中间激活值，全都要塞进显存。一个 7B 的模型，FP16 精度下光权重就占 14G 左右，加上推理时的 KV Cache 和框架开销，16G 显存勉强够用，32G 就从容很多。如果是 13B 模型，FP16 需要 26G 以上，32G 卡刚好能跑，但量化到 INT8 或 INT4 之后，显存压力会小很多。MI50 的 32G HBM2，在这个维度上是很有优势的。

第二是显存带宽。大模型推理是典型的 memory-bound 任务，算力往往不是瓶颈，数据搬运才是。MI50 的 HBM2 带宽在 1TB/s 级别，虽然比不上 newer 的 HBM3，但比同价位的 GDDR6 消费卡强不少。这意味着在 token 生成速度上，它不会太难看。

第三是软件生态。这是 MI50 最大的短板。AMD 的 ROCm 生态在推理框架的支持上，远不如 CUDA 成熟。vLLM、llama.cpp、Ollama 这些工具，对 ROCm 的支持程度参差不齐，有些需要自己编译，有些干脆跑不起来。所以选 MI50 之前，得先接受一个现实：你不是在用一个“开箱即用”的方案，而是在做一个需要折腾的项目。

第四是功耗和散热。MI50 是 300W 级别的卡，被动散热设计，通常需要服务器风道或者自己加涡轮风扇。放在塔式机箱里，散热得专门处理，不然分分钟过热降频。

把这四点摆在一起，MI50 32G 的定位就很清楚了：显存和带宽有优势，生态和散热是短板。适合愿意花时间折腾、追求性价比的人，不适合想要即插即用的人。

2. Ubuntu 系统准备与 MI50 驱动安装的完整路径

2.1 系统版本选择：为什么是 Ubuntu 22.04

ROCm 对 Ubuntu 版本的支持是有明确矩阵的。截至我写这篇记录的时候，ROCm 6.x 官方支持 Ubuntu 22.04 和 24.04，但对 MI50 这种老卡，支持情况要复杂一些。MI50 基于 Vega 20，属于 GFX906 架构，在 ROCm 的官方支持列表里，它的状态是“有限支持”——也就是说，能跑，但不在最优先的优化范围内。

我试过 Ubuntu 24.04，遇到了一些依赖库版本冲突的问题，主要是内核版本和 ROCm 驱动模块的兼容性。Ubuntu 22.04 的 5.15 内核和 ROCm 6.x 的搭配相对成熟，社区里成功的案例也更多。所以我的建议是：如果你是从零开始，直接上 Ubuntu 22.04 LTS，别追新。

安装系统本身没什么好说的，常规 U 盘启动、分区、设置用户。有几个点需要注意：

• 分区时给/留至少 100G，ROCm 和相关工具链占空间不小。
• 如果打算用 Docker 跑推理框架，/var/lib/docker最好单独挂一块盘。
• 安装时勾选“安装第三方软件”，省得后面自己补显卡固件。

系统装完之后，第一件事是更新源、升级现有包：

sudo apt update && sudo apt upgrade -y sudo apt install -y build-essential git cmake wget curl

这些基础工具后面编译 ROCm 组件和推理框架时都会用到，先装上省事。

2.2 内核与固件的前置处理

MI50 需要正确的固件才能被系统识别。Ubuntu 22.04 默认的linux-firmware包里已经包含了 AMD Vega 20 的固件，但版本可能偏旧。我遇到过系统能识别卡、但rocminfo里显示固件版本不匹配的情况，推理时性能异常。

检查固件是否加载：

sudo dmesg | grep -i amdgpu | grep -i firmware

如果看到amdgpu: failed to load firmware之类的报错，就需要手动更新固件。可以从 kernel.org 的 linux-firmware 仓库拉最新的amdgpu固件文件，放到/lib/firmware/amdgpu/下，然后重建 initramfs：

sudo update-initramfs -u sudo reboot

另一个容易忽略的点是 IOMMU。如果主板开启了 IOMMU，MI50 在某些主板上会出现直通或初始化问题。可以在内核启动参数里加amd_iommu=on iommu=pt，或者干脆先关掉 IOMMU 排除干扰。我个人的经验是，单卡推理场景下，关掉 IOMMU 能减少不少玄学问题。

还有 Resizable BAR。MI50 对 ReBAR 的支持不完整，如果主板默认开启，可能导致驱动加载失败或者显存识别异常。进 BIOS 把 ReBAR 关掉，或者设成 4G 以下解码，能避开一批坑。

2.3 ROCm 安装：官方源 vs 手动编译

ROCm 的安装方式主要有两种：用 AMD 官方 apt 源，或者手动下载 deb 包安装。官方源的好处是依赖自动处理，坏处是版本更新快，有时候新版本反而对老卡不友好。

我最终用的是 ROCm 6.0.2，通过官方源安装。步骤大致如下：

# 添加 ROCm 源 wget https://repo.radeon.com/rocm/rocm.gpg.key -O - | sudo apt-key add - echo 'deb [arch=amd64] https://repo.radeon.com/rocm/apt/6.0.2 jammy main' | sudo tee /etc/apt/sources.list.d/rocm.list # 安装核心包 sudo apt update sudo apt install -y rocm-hip-sdk rocm-opencl-sdk rocm-smi-lib

装完之后，把当前用户加入render和video组：

sudo usermod -aG render,video $USER

然后配置环境变量。在~/.bashrc里加上：

export PATH=$PATH:/opt/rocm/bin:/opt/rocm/hip/bin export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/rocm/lib:/opt/rocm/lib64 export HSA_OVERRIDE_GFX_VERSION=9.0.6

最后这个HSA_OVERRIDE_GFX_VERSION是关键。MI50 的 GFX 架构是 9.0.6，但很多 ROCm 组件默认按 9.0.0 或 9.0.2 来编译，不覆盖的话会出现“unsupported GPU”或者 kernel 加载失败。这个变量是让运行时把 MI50 当成 9.0.6 来处理，实测下来能解决大部分兼容性问题。

重启之后，用rocminfo验证：

rocminfo | grep -i "gfx"

如果输出里能看到gfx906相关的信息，说明驱动基本就位了。

2.4 验证驱动：rocminfo 与 rocm-smi 的正确读法

rocminfo能跑通，只是第一步。真正要确认卡能用，还得看rocm-smi和实际的计算测试。

rocm-smi

这个命令会列出所有 AMD GPU 的状态，包括温度、功耗、显存占用。如果 MI50 出现在列表里，且显存显示 32G 左右，说明驱动层面没问题。

但rocm-smi正常不代表计算能用。我遇到过rocminfo和rocm-smi都正常、但跑 HIP 程序时报hipErrorNoBinaryForGpu的情况。这时候需要确认 HIP 的架构支持：

hipconfig --platform

输出应该是hcc或amd。然后跑一个简单的 HIP 示例：

cd /opt/rocm/share/hip/samples/0_Intro/square make ./square

如果这个能跑出结果，说明 HIP 运行时是通的。这一步很重要，因为后面 vLLM 或 llama.cpp 的 ROCm 后端，底层都是走 HIP。

3. 大模型推理框架在 MI50 上的部署实操

3.1 llama.cpp 的 ROCm 编译与量化模型加载

llama.cpp 是我在 MI50 上跑通的第一个推理框架。它的 ROCm 后端相对成熟，编译过程也不算复杂。

先拉代码：

git clone https://github.com/ggerganov/llama.cpp cd llama.cpp

编译时开启 HIP 支持：

mkdir build && cd build cmake .. -DLLAMA_HIPBLAS=ON -DAMDGPU_TARGETS=gfx906 -DCMAKE_C_COMPILER=/opt/rocm/llvm/bin/clang -DCMAKE_CXX_COMPILER=/opt/rocm/llvm/bin/clang++ make -j$(nproc)

这里AMDGPU_TARGETS=gfx906必须指定，不然编译出来的二进制不包含 MI50 的 kernel。CMAKE_C_COMPILER指向 ROCm 自带的 clang，避免和系统 gcc 混用导致链接错误。

编译完成后，下载一个量化模型测试。我用的是一组 7B 的 Q4_K_M 量化模型，文件大小 4G 左右，显存占用很友好。

./main -m /path/to/model.gguf -p "你好，请介绍一下你自己" -n 128 -ngl 99

-ngl 99表示把所有层都放到 GPU 上。如果显存不够，可以调小这个值，让部分层留在 CPU。

实测下来，7B Q4 模型在 MI50 上能跑到 30-40 token/s 的生成速度，首 token 延迟在几百毫秒级别。这个成绩对于本地推理来说完全可用。

3.2 vLLM 的 ROCm 适配与常见报错

vLLM 是另一个我重点尝试的框架，因为它的吞吐量优化做得很好，适合做批量推理或者 API 服务。但 vLLM 对 ROCm 的支持，在 MI50 上要曲折得多。

vLLM 官方对 ROCm 的支持主要集中在 MI200 和 MI300 系列，MI50 不在官方测试矩阵里。直接pip install vllm装出来的版本，默认是 CUDA 后端，在 MI50 上跑不起来。

我的做法是从源码编译，指定 ROCm 后端：

git clone https://github.com/vllm-project/vllm cd vllm pip install -r requirements-rocm.txt python setup.py develop

编译过程中会遇到几个典型问题：

第一个是hipcc找不到。需要确保/opt/rocm/bin在 PATH 里，且hipcc能正常执行。

第二个是 flash-attention 的 ROCm 版本编译失败。vLLM 依赖 flash-attention 做注意力加速，但 ROCm 版的 flash-attention 对 gfx906 支持不完整。我的处理方式是先禁用 flash-attention，用 PyTorch 的原生注意力实现：

export VLLM_USE_FLASH_ATTN=0

第三个是HSA_OVERRIDE_GFX_VERSION必须在启动 vLLM 之前设置好，否则运行时会报no kernel image available。

即使编译成功，vLLM 在 MI50 上的性能也不如 llama.cpp 稳定。我遇到过显存泄漏、长序列推理时崩溃等问题。所以我的建议是：如果只是单路推理或者小规模服务，llama.cpp 更省心；如果要做高并发 API，vLLM 可以试，但要做好调优和排错的准备。

3.3 Ollama 在 MI50 上的可行性验证

Ollama 是最近很火的本地大模型工具，它的优势是模型管理方便、API 简单。但 Ollama 对 ROCm 的支持，在 MI50 上需要一些额外处理。

Ollama 默认会检测 ROCm 环境，如果rocminfo能识别到 GPU，它会尝试用 GPU 加速。但 MI50 的 gfx906 架构不在 Ollama 的默认支持列表里，需要手动设置：

export HSA_OVERRIDE_GFX_VERSION=9.0.6 export OLLAMA_GPU_OVERHEAD=0 ollama serve

然后拉一个模型测试：

ollama run qwen2:7b

实测下来，Ollama 在 MI50 上能跑，但性能不如直接用 llama.cpp。原因是 Ollama 的 ROCm 后端封装了一层，对 gfx906 的优化不够。如果追求极致性能，还是 llama.cpp 更直接；如果图方便，Ollama 也能用。

4. 避坑实录：那些让我熬夜的典型问题

4.1 驱动加载失败与内核模块冲突

最常见的问题就是amdgpu模块加载失败。表现是rocminfo报No GPU found，或者dmesg里一堆amdgpu: probe failed。

原因通常有几个：

一是内核版本太新或太旧。ROCm 6.0.2 对 5.15 和 6.2 内核支持较好，6.5 以上内核有时会出现模块签名或 API 变更导致的加载失败。解决办法是装linux-generic的 HWE 内核，或者降级到 5.15。

二是固件缺失。前面提过，检查dmesg里的 firmware 报错，手动补固件。

三是 IOMMU 或 ReBAR 干扰。进 BIOS 关掉相关选项，或者在启动参数里加amd_iommu=off。

四是之前装过 NVIDIA 驱动，残留的nouveau或nvidia模块和amdgpu冲突。用lsmod | grep -i nvidia检查，如果有残留，sudo apt purge掉相关包，再sudo update-initramfs -u。

4.2 HSA_OVERRIDE_GFX_VERSION 的玄学与真相

这个环境变量是 MI50 用户绕不开的。它的作用是告诉 ROCm 运行时，把当前 GPU 当成指定的 GFX 版本来处理。MI50 的物理架构是 gfx906，但很多 ROCm 库在编译时只包含了 gfx900、gfx908、gfx90a 等版本的 kernel，没有 gfx906 的。设置HSA_OVERRIDE_GFX_VERSION=9.0.6之后，运行时会用 gfx906 的 kernel，或者回退到兼容的版本。

但这里有个坑：不是所有场景下 9.0.6 都管用。有些框架编译时用的是 gfx908 的 kernel，这时候设成 9.0.6 反而会报错。我的经验是，先试 9.0.6，如果报no kernel image，再试 9.0.0 或 9.0.2。不同框架、不同编译选项，需要的值可能不一样。

另一个坑是这个变量必须在启动推理进程之前设置，且要 export 到环境里。写在脚本里、用env命令传递，或者直接在 shell 里 export，都可以，但不能在程序运行中途改。

4.3 显存识别异常与散热降频

MI50 的 32G 显存，有时候系统只能识别到 16G 或者更少。这通常是 ReBAR 或者 Above 4G Decoding 设置的问题。进 BIOS 把 Above 4G Decoding 打开，ReBAR 关掉，一般能解决。

散热是另一个大问题。MI50 是被动散热，原厂设计是放在服务器风道里的。如果塞进普通塔式机箱，没有强制风道，满载几分钟就会冲到 90 度以上，然后降频。我的做法是加一个涡轮风扇，用 3D 打印的导风罩对着卡尾吹，把热风从机箱后部排出去。实测能把满载温度压在 75 度左右，性能稳定很多。

rocm-smi可以实时看温度和功耗：

watch -n 1 rocm-smi

如果看到Temperature超过 85 度，就得检查散热了。

4.4 常见问题速查表

5. 性能调优与长期使用的经验沉淀

5.1 量化精度与推理速度的平衡

在 MI50 上跑大模型，量化是绕不开的话题。FP16 精度下，7B 模型占 14G 显存，13B 占 26G，32G 卡跑 13B FP16 已经很勉强，加上 KV Cache 基本会 OOM。所以实际使用中，量化到 INT8 或 INT4 是常态。

llama.cpp 支持的量化格式很丰富，从 Q2_K 到 Q8_0 都有。我的测试结果是：

• Q4_K_M：速度和质量的平衡点，7B 模型生成速度 30-40 token/s，质量损失可接受。
• Q5_K_M：质量更好，速度略降，显存占用增加不多。
• Q8_0：质量接近 FP16，但显存占用翻倍，32G 卡跑 13B 会紧张。

对于 MI50 这种带宽相对充裕的卡，量化带来的速度提升不如显存节省明显。所以选量化的首要目标是“塞得下”，其次才是“跑得快”。

5.2 多卡并行的可能性与限制

MI50 支持多卡，但 ROCm 下的多卡并行，在推理框架里的支持并不完善。llama.cpp 可以通过-ngl和--tensor-split做层间拆分，但需要手动调参。vLLM 的 tensor parallel 在 ROCm 上对 gfx906 支持有限，我试过双卡跑 13B，能跑起来，但通信开销让吞吐量提升不明显。

如果手头有多张 MI50，我的建议是：单卡跑小模型，多卡各跑各的，做服务化部署，而不是强行做张量并行。这样稳定性和利用率都更高。

5.3 日常维护与监控脚本

长期跑推理服务，监控是必须的。我写了一个简单的脚本，定时记录 GPU 状态和推理日志：

#!/bin/bash while true; do echo "=== $(date) ===" >> /var/log/mi50_monitor.log rocm-smi --showtemp --showpower --showmemuse >> /var/log/mi50_monitor.log sleep 60 done

配合logrotate做日志轮转，避免磁盘写满。如果温度超过阈值，可以加个告警：

TEMP=$(rocm-smi --showtemp | grep -oP '\d+(?=\.\d+c)' | head -1) if [ "$TEMP" -gt 85 ]; then echo "GPU 温度过高: $TEMP" | mail -s "MI50 Alert" your@email.com fi

这些脚本不复杂，但能省去很多手动检查的麻烦。

5.4 我踩过的那些“文档没写”的坑

最后分享几个文档里不会写、但实际会遇到的坑。

第一个是电源。MI50 是 300W 卡，加上 CPU 和主板，整机功耗轻松上 500W。如果电源不够，满载时会直接关机或者重启。我一开始用 550W 电源，跑推理没问题，但一跑压力测试就断电。换成 750W 之后稳定了。所以电源余量一定要留够。

第二个是 PCIe 带宽。MI50 是 PCIe 4.0 x16 接口，但如果插在 PCIe 3.0 插槽上，带宽减半。对于推理来说，模型加载时会慢一些，但推理速度影响不大。不过如果做多卡通信，PCIe 带宽就很关键了。

第三个是系统时间。ROCm 的某些组件对系统时间敏感，如果时间不同步，编译或运行时会报证书错误。装个chrony或者systemd-timesyncd，保持时间同步。

第四个是用户组权限。装完 ROCm 之后，一定要把用户加入render和video组，然后重新登录。不然rocm-smi会报权限错误，或者只能看到部分信息。

第五个是 Python 环境。ROCm 的 PyTorch 轮子对 Python 版本有要求，3.10 和 3.11 支持最好。用 conda 或者 venv 建独立环境，别和系统 Python 混用，不然依赖冲突能折腾半天。

这些坑，每一个都让我多花了至少一个小时。写在这里，希望能帮你省下这些时间。MI50 这张卡，折腾归折腾，但跑通之后，32G 显存带来的从容感，是那些 8G、12G 消费卡给不了的。如果你也有一张，别急着出掉，花点时间把驱动和框架理顺，它能干的活比你想的多。