上礼拜我趁着 Datawhale 社区和 AMD 的联动活动拿到了一台 ROCm 云实例的试用额度。本来只是想顺手把 Gemma4 跑起来截个图交差结果一上手就停不下来了——从裸机状态的驱动安装、容器环境搭建到 vLLM 服务正式对外提供接口我掐表算了下从 SSH 登进去到第一个 token 吐出来十五分钟出头。这篇文章就是这次完整部署的记录。我尽量把每一步的命令、参数、排查思路都交代清楚目标是让完全没碰过 AMD GPU 云实例的人也能照着在十五分钟内把 Gemma4 跑起来。这次实操涉及的核心链条是Datawhale 社区的活动背景 AMD ROCm 云实例 Gemma4 模型 vLLM 推理框架。这四个东西单独拎出来都不算新但组合在一起尤其是放在 ROCm 生态里公开的踩坑记录其实比 CUDA 少得多。所以我写这篇主要就是想填补这个空白。1. 动手之前这套方案到底在解决什么问题1.1 为什么是 ROCm 云实例而不是直接租 CUDA先说个最直接的问题为什么不直接用 NVIDIA 的 CUDA 实例答案很简单一是成本二是生态多样性需求。ROCm 云实例在同样显存规格下通常比同等 CUDA 实例便宜不少很多团队也在主动做多云、多芯片的容灾预案不能把所有推理负载都绑死在单一厂商的生态里。ROCm 是 AMD 开源的 GPU 计算平台对标的就是 CUDA。过去几年它最大的问题是文档稀碎、兼容性玄学但最近这一两年进步非常明显。PyTorch 官方有 ROCm 版本的 wheelvLLM 也有对应的预构建镜像跑开源大模型已经不是“能不能跑”的问题而是“怎么跑得稳”的问题。不过话说回来ROCm 云实例的坑依然存在而且因为是云端环境很多坑和本地不一样。比如本地显卡你能随便折腾驱动云实例万一驱动装崩了恢复手段就少很多。所以这篇文章里的每一个命令我都建议你按顺序来别跳步。1.2 部署工具选型vLLM、Ollama、Transformers 怎么挑Gemma4 这种开源大模型部署方式其实就那么几条路。我整理了一下直接说结论工具优点缺点适合场景Ollama安装简单一条命令拉模型起服务对新模型的支持有滞后性能调优空间小个人尝鲜、本地快速验证Transformers灵活度高方便改代码做实验部署性能一般高并发吞吐上不去调试模型、做研究和二次开发vLLM吞吐高有 OpenAI 兼容接口社区活跃配置项多初次上手有一点学习成本生产环境、多用户服务化部署我自己这次用的是 vLLM而且是基于预构建镜像跑的。理由很简单目标是在十五分钟内搞定而且后续我还想压测它的并发能力。Ollama 虽然更快上手但对 Gemma4 这种刚发布的模型官方仓库适配往往没那么快遇到问题只能等更新。vLLM 的启动参数更透明出了问题也容易定位。1.3 十五分钟目标的底气从哪来十五分钟这个数字听起来很紧但本质上不是玄学而是把整个流程拆开算账。我当时的预估是这样的SSH 登录检查环境大约两分钟拉取带 ROCm 支持的 vLLM 镜像约三分钟从 ModelScope 下载 Gemma4 模型权重大概六分钟最后启动服务加验证请求四分钟。加起来正好是十五分钟左右。这里有一个关键认知慢的大部分时间其实花在模型文件传输上。所以我把模型下载这件事挪到了线程前面让它和镜像拉取并行进行。换句话说所谓“十五分钟部署”靠的是预构建镜像、模型缓存、脚本化操作这三板斧不是单纯的运气好。2. 云实例上的完整部署流程一步步照着做2.1 环境确认先判断 GPU 到底有没有被系统看到拿到实例后第一件事不是急着装驱动而是先确认系统到底认不认识这张 AMD 显卡。我连上去之后先跑了一个最基础的命令lspci | grep -i amd正常情况下你会看到类似Advanced Micro Devices, Inc. [AMD] ... VGA compatible controller这样的输出。但这只是第一步它只能说明 PCIe 层面有设备不代表 ROCm 运行时能用。所以我接着又跑了两条rocm-smi rocminfo如果这两条命令不存在说明驱动和 ROCm 用户态库还没装。如果存在但报错说明驱动有问题。我当时的情况是lspci能看到 GPU但rocm-smi找不到命令属于典型的“硬件已识别软件栈未安装”状态。接下来就是装驱动。AMD 官方提供了一个集成工具amdgpu-install它会帮你把内核驱动、ROCm 库、编译工具链一次搞定。我用的是这个命令sudo amdgpu-install --usecaserocm这条命令会从 AMD 的软件源拉取对应 ROCm 版本的包。装完之后重启一次实例或者重新加载内核模块再跑rocm-smi就能看到 GPU 的负载、温度、显存占用情况了。注意amdgpu-install的版本必须和你后续使用的 PyTorch/vLLM 镜像的 ROCm 版本对应上。比如你用 ROCm 6.2 的镜像驱动侧的 ROCm 库也最好是 6.2.x否则很容易出现“框架识别不到 GPU”这种诡异问题。2.2 搭建容器环境用官方镜像避开编译地狱驱动装好之后第二步是准备推理环境。我直接用了 Docker原因就一个不想自己编译 vLLM。自己编译 vLLM 在 ROCm 平台上少则四十分钟多则两小时而且中间会遇到各种依赖缺失的问题特别消磨耐心。先确认 Docker 装好了docker --version然后拉取带 ROCm 标识的 vLLM 镜像。不同镜像仓库的 tag 规则不一样我用的是rocm/vllm这个系列的镜像拉取命令大致如下docker pull rocm/vllm:latest镜像拉下来之后启动容器前有一个非常关键的变量要确认HSA_OVERRIDE_GFX_VERSION。这个变量是 ROCm 生态特有的东西简单说就是如果你的显卡架构比较新而 ROCm 运行时还不认识它你可以通过这个变量手动指定一个它认识的架构版本号来“骗”过去。不同 GPU 对应不同的值一定要先去 AMD 官方文档查清楚自己实例显卡对应的 gfx 代号和推荐值。我当时启动容器用的是类似这样的命令docker run -it --rm \ --device/dev/kfd \ --device/dev/dri \ --group-add video \ --ipchost \ -v /data/models:/models \ -p 8000:8000 \ rocm/vllm:latest bash这里几个参数值得说明一下。/dev/kfd和/dev/dri是 ROCm 访问 GPU 必须透传的设备节点--group-add video是为了让容器内的用户能拿到 GPU 权限-v /data/models:/models是把宿主机上的模型目录挂载进去这样模型下载一次多个容器都能复用。2.3 模型获取与启动 vLLM 服务模型文件我推荐从 ModelScope 下载速度比直接从境外源拉要稳定得多。先安装依赖pip install modelscope然后写一行命令下载模型modelscope download --model google/gemma-4-12b /data/models/gemma-4-12b如果没有 ModelScope 账号或者遇到限流也可以用hf-mirror.com这个社区镜像站export HF_ENDPOINThttps://hf-mirror.com huggingface-cli download google/gemma-4-12b --local-dir /data/models/gemma-4-12b下载完成后模型目录里会看到config.json、*.safetensors这些文件。确认文件都在之后就可以启动 vLLM 的 OpenAI 兼容 API 服务了python -m vllm.entrypoints.openai.api_server \ --model /data/models/gemma-4-12b \ --served-model-name gemma4 \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000启动日志里会出现一连串加载权重的进度条。当看到类似Application startup complete的日志时说明服务已经就绪。这一步在整个流程里大概是耗时最长的因为模型文件在显存里做 warm up会花一两分钟。参数作用我的建议--tensor-parallel-size多卡并行切分张量单卡就填 1多卡按卡数填--max-model-len最大上下文长度先填 8192 试水显存够再往上加--gpu-memory-utilization单卡显存利用率上限0.85-0.95 比较稳妥别贪到 1.02.4 接口验证用 curl 和 Python 跑通第一次对话服务起来之后先不要急着上复杂工具用 curl 确认基础功能是通的。我直接调/v1/chat/completions接口curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: gemma4, messages: [{role: user, content: 你好介绍一下你自己}], max_tokens: 128 }如果返回的 JSON 里带choices和content字段说明整条链路已经通了。这时候别说十五分钟二十分钟都算慢的。为了再确认一下不是单次请求的运气好我又写了个简单的 Python 脚本做并发测试确保服务在压力下不会直接崩from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) prompts [用一句话解释 ROCm 是什么, 讲个关于程序员的笑话, 写一首五言绝句] for p in prompts: resp client.chat.completions.create( modelgemma4, messages[{role: user, content: p}], max_tokens64 ) print(resp.choices[0].message.content)这代码没什么玄机核心就是验证 vLLM 暴露的接口和 OpenAI SDK 完全兼容后续接任何基于 OpenAI 协议的聊天前端都不会有障碍。3. 翻车记录我在部署时踩过的那些坑3.1 lspci 查不到 AMD GPU先别急着重装系统有一个坑我差点陷进去刚拿到实例的时候执行lspci | grep -i amd居然没有输出。我当时心里一咯噔以为是实例分配出问题了。后来排查才发现根本不是设备不存在而是系统自带的 pci.ids 数据库太久没更新AMD 显卡的厂商 ID 没被识别出来所以lspci把设备归类成了“unknown”而不是“AMD”。解决方式很简单更新一下 pci 数据库sudo update-pciids再跑一次lspci | grep -i amd设备就现形了。这个坑特别值得纪念因为它提醒我一个很重要的排查原则云实例上报的硬件问题先怀疑工具再怀疑驱动最后才怀疑平台分配。3.2 驱动版本与 ROCm 库错配的连锁反应有一次我图省事直接用了系统源里的旧版amdgpu-dkms然后装了个新版的 ROCm 库结果 Python 里怎么都检测不到 GPU。当时我在容器里跑import torch print(torch.version.hip) print(torch.cuda.is_available())输出结果是torch.cuda.is_available()返回 False。这个并不代表物理 GPU 有问题而是内核驱动和用户态库的版本不匹配导致 HIP runtime 初始化失败。我的解法是把之前装的驱动包彻底清掉然后用amdgpu-install重新装一套统一的版本。注意先执行sudo amdgpu-uninstall再重新走一遍sudo amdgpu-install --usecaserocm。这个过程看起来多花了三分钟但实际上比手工一个个调包省了半小时不止。经验总结在 ROCm 平台上版本一致性是最重要的。官方工具链虽然笨重但它保证的是内核模块、用户态库、编译器三者之间的配合关系。不要自己混搭版本那是给自己挖坑。3.3 模型下载慢、显存不够怎么办我实测下来最大的时间开销就是模型文件传输。Gemma4 的权重动辄几十 GB哪怕是走 ModelScope 这种国内镜像也要几分钟。遇到下载慢的问题我的经验是优先用modelscope download这个工具自带断点续传中途断网不用从头再来。次选hf-mirror.com环境变量方案适合已经习惯huggingface-cli的用户。不要在同一个 shell 会话里同时跑下载和编译任务磁盘 I/O 会被抢。至于显存不够那就更常遇见了。24GB 的卡听着不小但如果你直接把--max-model-len开到 32768显存分分钟爆掉。我当时的处理方式是先看 vLLM 的启动日志里面会明确提示推荐的最大上下文长度然后按推荐值下调。再不行就换量化版模型比如 AWQ 或者 GPTQ 的 4bit 版本显存占用能砍掉一半以上。3.4 本机 AMD 驱动问题与云实例环境别混为一谈最近网上能看到不少关于 AMD 驱动的各种搜索词什么“AMD Software 右键菜单怎么关闭”“amd auto-detect and install tool 是干什么的”“amd disable current limiter”之类的。这些基本都是 Windows 本机消费级显卡的驱动管理体验问题和云端 ROCm 部署完全是两码事。但我发现它们背后有一个共同的排查逻辑看一个 GPU 是否“正常工作”永远要分两层看。第一层是操作系统层面能不能识别设备第二层是计算框架层面能不能调用设备。本机上方不方便看的是系统托盘里的驱动控制面板云实例上没有图形界面就得靠lspci、rocm-smi、rocminfo这几个命令行工具。所以我的建议是别把本机折腾 AMD 驱动的经验硬搬到云端。云实例上不需要什么图形化控制面板也不需要右键菜单更不存在笔记本功耗电流限制这种问题。云端统一用命令行处理反而干净利落。4. 让它更快更稳几条可以直接用的实战经验4.1 预构建镜像怎么选才不容易翻车官方预构建镜像省去了大量编译时间但选不好容易踩 ABI 不兼容的坑。核心原则是镜像的 ROCm 版本和宿主机驱动版本的 ROCm 版本必须落在同一个大版本内。比如宿主机驱动是 ROCm 6.2那就优先选 tag 里带rocm6.2的镜像别硬拉一个rocm6.3的试。ROCm 的小版本之间有时候 ABI 是兼容的但没必要冒这个险。我当时是先docker pull前用rocm-smi --version看了一眼宿主机 ROCm 版本再决定拉哪个 tag整个流程就没出过兼容性故障。4.2 量化级别怎么挑衡量质量与速度如果你卡在显存边缘量化是绕不开的话题。我这次也做了几个对比测试把不同方案的显存占用和速度感受整理了一下方案显存占用速度感受适用场景FP16 原版最高快但显存吃紧显卡显存充裕时AWQ 4bit约为原版一半基本无损体验24GB 卡跑中等模型GGUF Q4_K_M更小加载快极限配置或 CPU 推理个人观点是先用 FP16 确认模型本身运行正常再切换到量化版去测实际业务效果。不要一上来就量化不然出了问题你根本分不清是模型权重损失还是推理框架的问题。4.3 从一次性部署变成长期服务systemd OpenAI 接口如果你要把这个服务跑长期而不是用完就关实例那建议把启动流程托管给 systemd。我用的是下面这个简单方案写一个/etc/systemd/system/gemma4.service[Unit] DescriptionGemma4 vLLM Service Afterdocker.service [Service] ExecStart/usr/bin/docker start -a gemma4-container Restartalways RestartSec10 [Install] WantedBymulti-user.target这样只要实例不销毁服务就会一直挂着。配合 vLLM 的 OpenAI 兼容接口前端接 open-webui 之类的东西也方便基本就是改一下 base_url 的事。4.4 把十五分钟压到五分钟的一键脚本思路前面说的流程如果走熟了其实还能更快。核心思路就是把固定动作全部脚本化。我当时写了一个setup.sh内容大致包括更新 pci 数据库、检查 ROCm 驱动、拉取指定 tag 镜像、下载模型、启动容器。后续再开新实例的时候直接运行这个脚本中间等镜像和模型的时间都是自动的人不盯着也行。再一个技巧是把模型目录单独挂载到云盘或对象存储而不是放系统盘。这样每次开新实例模型文件直接挂载进去连下载这一步都省了。从零到服务就绪压到五分钟是完全可行的。这次实际跑下来我个人最大的体会是ROCm 生态没有网上说的那么难用关键是版本一致性保持好路径就顺很多。十五分钟部署 Gemma4 这件事本质上不是“AMD 变简单了”而是预构建镜像、模型镜像站、容器化这些基础设施已经成熟到可以让普通人忽略底层差异了。如果你手里正好有一个 AMD GPU 的云实例试用机会我建议别犹豫直接拿它当主力试一次推理部署。踩过两三个坑之后你会对 GPU 计算栈的层次有比 CUDA 时代更清晰的理解。