AMD ROCm云实例15分钟部署Gemma4开源模型实战

先交代背景。一直在做开源大模型部署相关的事，手头的项目经常需要把各种开源权重跑起来，N 卡好是好，但价格和显存卡的太狠了，所以我对 AMD 的路线一直有关注。这次跟着 Datawhale 和 AMD 的活动，在云上开了一台带 ROCm 环境的 AMD 实例，目标是 15 分钟内把 Gemma4 部署出来。Gemma4 是 Gemma 系列最近一版开源权重，我不打算吹它的榜单成绩，我更关心的是它能不能在 AMD ROCm 云实例上快速跑起来。

说实话，看到“15 分钟”这个时间预算，一开始我是有点怀疑的。毕竟只要在本地部署过大模型的人都懂，这一路上光是装驱动、配环境、拉权重，任何一个环节报错都能轻松吃掉一下午。但既然这次任务就是“把 AMD ROCm 云实例挖个底朝天”，我就认认真真开了一台实例，从控制台到跑通 API 全部走了个遍。结论先放这里：15 分钟部署到能聊天，是真的做得到的，但前提是你走对的路线、踩对的前提条件一个都不能少。这篇就把我的完整操作、选型逻辑、踩过的坑和最后的优化方案全部写下来。无论你现在想部署的是 Gemma、DeepSeek、Qwen 还是其他开源模型，这套流程基本可以无脑平移。

1. 先回答那个最关键的问题：15 分钟到底靠不靠谱

1.1 为什么大多数人会觉得“15 分钟部署”是标题党

“本地部署大模型”这几个字这两年都快被说烂了，但真正想跑通一套服务，拆开来看其实是一长串步骤：装显卡驱动、装 ROCm 计算库、装 Python 推理环境、下载模型权重、启动推理框架、调显存和 KVCache、开端口接 API。任何一个步骤报错，等待你的就是以小时计的排查时间。

尤其是 AMD 的 ROCm 生态，社区里一直流传着一句话：安装两小时，部署五分钟。以前的 ROCm 确实是出了名的难伺候，驱动要手动匹配内核版本，PyTorch 要装特定的 nightly 版本，很多开源模型推理框架对 AMD 的支持也不完整。所以当我看到“15 分钟部署”这个目标时，第一反应是真的觉得不靠谱。

但这一次不一样。我仔细拆了一下整个部署链路，发现 15 分钟这个数字不是拍脑袋吹出来的，而是把流程压缩到极致后的真实时间预算。关键就在于“复用现成环境”，而不是“从零开始配置”。

1.2 我把流程拆成四段，发现确实塞得下

先看整体时间分布，我会在后面的章节里把每一段具体怎么操作都写清楚。

这个时间线能成立，核心秘密有三个：第一，实例镜像里已经预装了 ROCm 运行时，我不用自己碰驱动和底层库；第二，模型权重用的是现成的 GGUF 量化版，不需要现场拿原始权重去转换；第三，推理框架用的是 Ollama 这种自动适配 ROCm 后端的工具，安装完直接就能用。

1.3 三个前提条件，缺一个时间就要翻倍

先说结论：如果你不满足下面三个条件，那“15 分钟部署”确实就是不靠谱的标题党。我在这次实操中把每一个假设都验证过一遍。

第一个前提，实例镜像里必须有 ROCm 运行时。如果云平台给你的是裸 Ubuntu 系统，光安装 ROCm 工具链和依赖库就要花掉半个多小时，这还没算驱动和内核模块的适配问题。所以选实例的时候，“预装 ROCm 环境”这个选项几乎是必须的。

第二个前提，模型必须是现成的量化权重。Gemma4 这种规模的模型，原始 FP16 权重几十个 GB，就算下载下来，推理时显存开销也是巨大的。量化后的 GGUF 格式权重，比如 Q4_K_M 级别，体积能少一半以上，而且 Ollama 这类框架直接支持，不需要你做任何格式转换。

第三个前提，不要自己写推理脚本。我看到不少新手喜欢照着 HuggingFace 的 Transformers 示例代码往上冲，装一堆 Python 依赖、处理 tokenizer、写生成循环，一套下来调试时间根本无法估计。直接用 Ollama 或者 vLLM 这类成熟框架，把部署问题收敛到 API 层面，快得多。

为什么我会坚持选 AMD 而不是老老实实去租 N 卡，这里也顺带说清楚。现在公共云上的 N 卡实例价格已经到了一种离谱的程度，特别是大显存型号，按小时计费都能让人肉疼。而 AMD 的云实例往往用同样的预算能拿到更大的显存，对跑中等规模开源模型来说，显存就是硬通货。ROCm 生态经过这几年的补课，PyTorch、Ollama、vLLM 这些核心工具都已经有了官方支持，很多基于 CUDA 的部署教程只需要改几个环境变量就能平移过来。可以说，现在已经到了认真考虑 AMD 路线的合适时间节点。

2. 选实例：显存、镜像、磁盘，哪一个都不能拍脑袋

2.1 先算显存账，不然实例开下来也是白开

部署大模型的硬门槛永远是显存。Gemma4 这种规模的模型，如果跑 FP16 原始精度，单是权重就能把几十 GB 显存吃掉，再加上 KVCache 和运行时开销，显存压力非常大。所以实际部署时基本都是走量化路线。

一般来说，显存的最低需求可以用这个粗略公式估算：显存需求约等于 权重大小乘以 1.2，再加上 2GB 左右的上下文缓冲，最后再多留 20%-30% 余量。举个例子，如果某个模型量化后权重是 16GB，那么最稳的显存配置大概需要 25GB 以上。

我这次开的实例是单卡 64GB 显存的 AMD 实例，跑的是 4-bit 量化权重，上下文默认 8K，整个过程非常宽松。如果你的预算是 32GB 显存的实例，跑 7B-14B 量级的量化模型也没有问题，但再往上就建议用更小的量化位宽，或者降低上下文长度。

这里必须多说一句：显存永远不嫌多。很多人只盯着权重大小看，忽略了上下文长度和并发请求数都会显著扩大显存占用。尤其是 OpenAI 兼容 API 一开，多个人同时提问的时候，每个请求都会独立占一块 KVCache，显存水位直接被拉起来。预算允许的话，尽量往大显存选。

2.2 系统镜像怎么选，决定了你后面是 5 分钟还是 50 分钟

选实例的时候，系统镜像和 GPU 型号是同等重要的决策点。我的建议是，优先选择云平台提供的“预装 ROCm”镜像，其次选择官方推荐的 ROCm Docker 镜像。不要为了“干净”去选裸系统，后面所有环境问题都会变成你自己的时间黑洞。

ROCm 的版本也要注意和卡型匹配。AMD 的 MI200 系列对应 gfx90a 架构，MI300 系列对应 gfx942 架构，消费级的 RX 7000 系列则是 gfx1100 等编号。不同 ROCm 版本对架构的支持程度不一样，如果版本和卡型不对齐，常见的报错就是驱动加载不了，或者 HSA 层初始化失败，后面全是乱码式的错误信息。

可以把 ROCm 理解成“AMD 的驱动加计算库全家桶”，它的版本会直接影响设备节点、运行时库和框架层的兼容性。云平台预置镜像一般已经帮你把匹配关系处理好了，直接选最高版本的预装镜像通常没错。

2.3 磁盘和网络，往往才是 15 分钟计划的真正风险点

很多人把注意力全放在 GPU 上，结果部署时卡在了磁盘和网络这两个不起眼的环节。模型权重下载是整个流程中耗时最多的一段，如果实例系统盘只有几十 GB，拉一个几十 GB 的模型下去，磁盘满了直接前功尽弃。系统盘至少要有 100GB 可用空间，最好再配一个独立的数据盘。

我这次的做法是先把 Ollama 的模型目录软链到数据盘，避免把系统盘写满。具体命令很简单：

mkdir -p /data/ollama ln -sfn /data/ollama /root/.ollama

注意执行时机，一定要在安装 Ollama 和拉取模型之前做，否则模型已经下到系统盘，再迁移就是浪费时间。网络方面，如果你的网络环境访问模型仓库速度不理想，最有效的办法是先配置国内可用的镜像源，或者直接选择云平台上带有“模型缓存”的实例，把下载时间直接从分钟级压到秒级。

3. 开机后的四步自检：先确认你拿到的 AMD 实例真的能用

3.1 第一步：用 lspci 确认 GPU 是否真的直通进来了

拿到实例后我做的第一件事不是急着装东西，而是先做环境自检。这一步非常关键，它可以帮你把后面所有的失败收敛到“模型层”而不是“环境层”。

第一步是确认 GPU 设备是否真的透传到了这台虚机。执行：

lspci | grep -i amd

正常情况下，输出里能看到类似“Advanced Micro Devices, Inc. [AMD]”的条目，对应 VGA 兼容控制器或 3D 控制器。如果你执行完完全没有输出，那就说明 GPU 并没有成功直通进来，常见原因就两个：云平台的 GPU 直通设置有问题，或者 amdgpu 内核模块没有加载。有人经常会在这步卡住，看到无反应就以为是驱动没装，实际上先要确认硬件层面的设备能看到。

如果 lspci 能看到 GPU 但系统提示驱动模块没加载，可以尝试：

modprobe amdgpu

执行完再看一次设备节点，就能确认内核层是否已经把 AMD 驱动挂载起来了。

3.2 第二步：检查 ROCm 依赖的设备节点

ROCm 底层依赖两个设备路径，一个是 /dev/kfd，一个是 /dev/dri 目录。执行：

ls -l /dev/kfd /dev/dri

正常情况下，/dev/kfd 会存在，/dev/dri 目录下会有 card0、renderD128 这类条目。/dev/kfd 是 ROCm 跟内核交互的核心接口，如果这个路径不存在，说明 ROCm 的内核层没有起来，HSA 应用全部都会报错。如果只看到 /dev/dri 而没有 /dev/kfd，驱动加载了一半的迹象很明显。

3.3 第三步：用 rocminfo 确认你的 gfx 架构编号

如果前面两步都正常，接着用 rocminfo 看详细架构信息：

rocminfo | grep gfx

输出里会出现类似 gfx90a、gfx942、gfx1100 这样的编号。记住这个编号，它对你后面排错特别重要。因为某些 ROCm 版本对特定架构没有内置二进制支持，部署时如果报“is not supported by current ROCm”，就可以用这个编号去做兼容覆盖，我在第 5 章会详细讲。

3.4 第四步：用 rocm-smi 确认显存和温度

最后用 rocm-smi 看一下显存、温度和功耗状态：

rocm-smi

正常情况下能看到显卡的显存总量、当前占用、温度、功耗等数据。如果显存信息读不出来，或者温度数据明显异常，说明传感器或驱动层有问题。把自检结果整理一下，方便对号入座：

四步自检都过了，后面部署就踏实了。如果哪一步出问题，强烈建议在控制台层面调整完实例配置再继续，而不是耗在系统里打地鼠。

4. 15 分钟部署实录：Ollama + Gemma4 + Open WebUI 一条龙

4.1 为什么首选 Ollama

环境确认没问题后，正式进入部署环节。我这次的第一选择是 Ollama，没有自己写 Python 推理脚本。原因有三个。第一，Ollama 在 Linux 上安装后会自动检测 AMD GPU 并启用 ROCm 后端，不需要我手动处理复杂的编译参数；第二，Ollama 的模型仓库直接提供各类开源模型的 GGUF 量化权重，拉下来就能跑；第三，它自带 OpenAI 兼容 API，后面接什么工具都方便。

安装和启动命令非常简单：

curl -fsSL https://ollama.com/install.sh | sh ollama serve &

然后拉取 Gemma4 的权重。我这次拉的是官方默认的较大指令版本，如果你的显存比较紧张，可以拉更小尺寸或者更极端的量化位宽。模型标签以 Ollama 仓库里实际显示的为准，不同版本命名会略有差异，但流程完全一样。

ollama pull gemma4

拉完之后用交互模式验证一下：

ollama run gemma4

直接在命令行里输入问题，能出回答说明模型已经跑起来了。如果你习惯用 API，Ollama 默认监听在 11434 端口，可以直接用 curl 测：

curl http://localhost:11434/api/generate -d '{"model": "gemma4", "prompt": "你好，用一句话介绍你自己"}'

我实测下来的生成速度大致在每秒 40 到 60 个 token 之间，首次返回延迟 1 到 2 秒，这个体感已经很接近商业 API 在轻负载场景下的表现了。

4.2 Docker 部署 Ollama 的备选姿势

如果你不想污染宿主机环境，用 Docker 化部署也完全可行。AMD 容器和 N 卡容器有一个关键区别：N 卡环境通常要加 --gpus all，但 AMD 环境走的是设备透传，必须显式指定 /dev/kfd 和 /dev/dri。正确的启动方式是：

docker run -d \ --name ollama-rocm \ --device=/dev/kfd \ --device=/dev/dri \ -v /data/ollama:/root/.ollama \ -p 11434:11434 \ ollama/ollama:rocm

把数据目录挂载到 /data/ollama，这样模型和容器生命周期解耦，删容器也不会丢权重。这一步我专门列出来，是因为太多人拿着 N 卡的习惯来跑 AMD 容器，上来就加 --gpus all，结果设备透传根本没生效，服务一直报找不到 GPU。

4.3 把可视化面板挂上去：Open WebUI

模型跑通命令行之后，下一步当然是要有个好看的聊天界面。Open WebUI 是目前最主流的开源可视化方案，跟 Ollama 配合得非常好，这一步本质就是起一个 Docker 容器，然后把 Ollama 的地址告诉它。

docker run -d \ -p 3000:8080 \ -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \ --add-host host.docker.internal:host-gateway \ --name open-webui \ --restart always \ ghcr.io/open-webui/open-webui:main

浏览器打开宿主机的 3000 端口，注册一个本地账号，进去之后在模型选择列表里选中 Gemma4，就能像用 ChatGPT 一样开始对话了。整个操作不到两分钟，可视化问题算是彻底解决。

到这里，15 分钟的时间线是完全成立的。我实测从实例开通到 Open WebUI 界面能聊天，整个过程就是 15 分钟左右，前提是模型仓库下载速度快。

5. 踩坑实录：这四个问题，任何一个都能吃掉你的 15 分钟

5.1 显卡不被 ROCm 识别：HSA_OVERRIDE_GFX_VERSION 的用处

第一个高发问题，是 Ollama 启动后报错，提示当前架构不受 ROCm 支持。现象大概长这样：

amdgpu: gfx1100 is not supported by current ROCm

为什么会出现这个问题？因为 ROCm 的运行时库里，针对不同 gfx 架构的预编译二进制不是全量包含的，某些消费级显卡或比较新的架构不在预编译列表里。解法是设置一个兼容覆盖变量：

export HSA_OVERRIDE_GFX_VERSION=11.0.0

注意这个 11.0.0 不是固定的，要按你第 3 章自检时看到的实际 gfx 编号来填。比如 gfx900 系列填 9.0.0，gfx1100 系列填 11.0.0。设完环境变量后重启 Ollama 服务就能识别到 GPU。

这里要特别提醒：这个变量是覆盖底层架构检测逻辑，不是万能钥匙。能跑起来不代表性能最优，但至少解决了“完全用不了”的问题。

5.2 报错不是 CUDA OOM，而是 HSA 内存分配失败

第二个坑和显存有关，但报错信息和 CUDA 生态完全不同。跑长上下文或多轮对话时，服务可能直接挂掉，日志里出现类似 HSA_STATUS_ERROR_OUT_OF_RESOURCES 的信息。第一次见这种错误容易懵，因为它不像 CUDA OOM 那么直白。

原因分析下来，基本就是 KVCache 把显存吃满了。模型权重之外，每一条对话的上下文都会占用显存，上下文长度越长、并发请求越多，KVCache 的占用就越大。解决思路也比较直接：降低并发数，缩短上下文长度。Ollama 可以通过环境变量控制：

export OLLAMA_CONTEXT_LENGTH=8192

设置完重启服务，问题就消失了。如果你用的是 vLLM，那就调 --max-model-len 参数，道理一样。

5.3 模型权重下载卡住：数据盘和镜像源缺一不可

第三个坑发生在拉权重的环节。几十 GB 的模型文件，下载时间长还能忍，就怕下到一半断掉，又要重新来。而且如果你把模型默认放在了系统盘，下载过程中系统盘空间被写满，整个实例都可能变得不可用。

我的做法是，先把模型目录软链到数据盘，这一步在第 2 章已经写过。网络方面的优化，主要是选择访问速度更快的镜像源。如果你部署的任务对时效性要求很高，直接在云平台选一台带模型缓存的实例是最省事的。

5.4 重启实例后 GPU 设备消失：驱动模块没随开机加载

第四个问题发生在一次实例重启之后。当时 lspci 能看到 GPU，但是 /dev/kfd 不见了，Ollama 服务自然起不来。查了一圈发现，amdgpu 内核模块没有随开机自动加载。

解法是把驱动模块写进系统的模块加载配置里：

echo "amdgpu" >> /etc/modules-load.d/amdgpu.conf

保存后重启验证一次，确认 /dev/kfd 正常出现。这个问题很隐蔽，因为你不是每次重启都会留意设备节点状态，一旦没注意，后面排查环境问题会花上很多时间。

踩过这些坑之后我养成一个习惯：把部署时的关键版本号全部记录下来。Ollama 版本、ROCm 版本、模型标签、HSA_OVERRIDE_GFX_VERSION 的值，写进一个 README 文件，下次再部署直接按图索骥，避免重复踩雷。

6. 从“能跑”到“跑得爽”：vLLM 与部署模板固化

6.1 什么时候需要从 Ollama 换到 vLLM

Ollama 对个人调试和轻量并发已经够用，但如果你的目标是把模型服务化，接 API 给团队或者项目用，Ollama 就会开始显得吃力。高并发场景下，vLLM 凭借更高效的显存管理机制，能做到更高的吞吐量。

vLLM 对 ROCm 的支持这几年进步很明显，官方仓库直接提供 ROCm 镜像，部署逻辑和 CUDA 版本几乎一致，唯一需要注意的就是设备透传方式。

6.2 vLLM for ROCm 的完整部署命令

先拉取 ROCm 版本的 vLLM 镜像，然后启动服务：

docker run -d \ --name vllm-rocm \ --device=/dev/kfd \ --device=/dev/dri \ -v /data/models:/models \ -p 8000:8000 \ vllm/vllm-openai:rocm \ python -m vllm.entrypoints.openai.api_server \ --model /models/gemma4 \ --dtype bfloat16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000

这里再次强调，不要加 --gpus all，AMD 环境的设备透传靠的是 --device=/dev/kfd 和 --device=/dev/dri。服务起来后用 OpenAI 兼容接口验证：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "/models/gemma4", "messages": [{"role": "user", "content": "你好"}]}'

并发压测的话可以直接用 wrk 这类工具对 8000 端口打请求。实测下来，同样 8 个并发请求，Ollama 会开始排队，vLLM 则能把显存空闲空间吃满，吞吐差距非常明显。

6.3 把环境固化成模板：快照和初始化脚本

部署完一轮之后，我强烈建议你会回云平台创建镜像快照。这样下次需要再开一台实例时，直接选择自定义镜像，ROCm、Ollama、模型权重全都一步到位，恢复时间通常也就几分钟，比重新部署快得多。

如果想更进一步，可以写一个初始化脚本放到数据盘。脚本内容不复杂：

#!/bin/bash # AMD ROCm 实例初始化 modprobe amdgpu mkdir -p /data/ollama ln -sfn /data/ollama /root/.ollama export HSA_OVERRIDE_GFX_VERSION=11.0.0 export OLLAMA_CONTEXT_LENGTH=8192 ollama serve & ollama pull gemma4 docker run -d -p 3000:8080 \ -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \ --add-host host.docker.internal:host-gateway \ --name open-webui --restart always \ ghcr.io/open-webui/open-webui:main

把脚本保存成 setup.sh，每台新实例开机后执行一遍，人就可以离开了，回来就是一个可以直接用的环境。这种做法对于经常要反复开实例的人特别有用。

6.4 最后几句真心话

这次 AMD ROCm 云实例的完整体验，比我预想的要顺滑。ROCm 生态前几年的确有不少粗糙的地方，但现在文档、框架支持和社区活跃度都已经提升了很多，至少在“把开源模型跑起来”这件事上，AMD 不该被直接排除在选项之外。

如果你是从零开始，我的建议是先别急着上 vLLM。先拿 Ollama 把流程跑通，让模型能说话，再去纠结吞吐和并发。不要一上来就把环境搞得太复杂，部署这件事，稳定压倒一切。

另外记住一点：这套流程对 Gemma 系列适用，对 DeepSeek、Qwen 等开源模型同样适用。本质上就是“GGUF 权重加 ROCm 推理框架”的组合，换模型只是换一个拉取标签的问题。真正值钱的不是某条命令，而是排查问题的那套思路。