1. 为什么我盯上了 AMD ROCm 云实例跑 Gemma4第一次看到“15 分钟部署 Gemma4”这个说法我的反应是要么是标题党要么是有人把坑全踩完了只留了条捷径。大模型部署这件事尤其是换到 AMD 的 ROCm 生态上从来不是“复制三行命令就完事”的活儿。但 Datawhale 和 AMD 联合推的这个方向确实让我来了兴趣——因为过去一年里我身边太多人想跑开源模型卡在“买不到合适的显卡”和“云上 GPU 太贵”这两件事上。AMD 的云实例如果能用而且 ROCm 的软件栈已经成熟到能撑起 vLLM 这种推理框架那这就是一条值得认真挖的路。先说清楚这篇东西是给谁看的。如果你手里有一台装了 AMD 显卡的机器或者你打算租一台 AMD 的云实例来跑大模型推理又或者你只是好奇 ROCm 到底能不能干活、vLLM 在非 NVIDIA 平台上跑起来是什么体验那这篇就是写给你的。我会把从实例选型、环境确认、ROCm 验证、vLLM 安装到 Gemma4 模型加载的完整链路拆开讲包括我实际踩到的坑和最后跑通的那套配置。核心关键词就几个Datawhale、AMD、ROCm、Gemma4、vLLM整篇内容围绕它们展开不跑题。有一点要先说明Gemma4 这个模型本身在公开渠道的权重获取和版本命名上不同时间点可能有差异我下面讲的是基于“拿到模型权重后如何在 ROCm vLLM 环境里把它跑起来”这条主线。如果你手上的模型版本号跟我写的不完全一致流程和思路是一样的参数按实际情况调整就行。2. 部署前的整体思路与方案选型2.1 为什么是 ROCm vLLM 这套组合先把方案选型的逻辑讲透不然你照着敲命令也是懵的。ROCm是 AMD 对标 CUDA 的开放计算平台。它的角色相当于“让 AMD 显卡能跑通用计算任务”的底层软件栈包含驱动、运行时、编译器、数学库这一整套。过去大家吐槽 ROCm 生态差主要是两个原因一是支持的显卡型号少二是框架适配滞后。但这两年情况变了ROCm 6.x 之后对主流推理框架的支持明显跟上来了尤其是 vLLM 这种社区活跃度极高的项目AMD 官方和社区都在推。vLLM是目前开源圈里做 LLM 推理服务最顺手的框架之一。它的核心卖点是 PagedAttention 和连续批处理continuous batching翻成人话就是显存利用率高、并发吞吐强。你如果只是自己玩一玩用 transformers 直接 generate 也行但只要你想要一个能对外提供 API、能同时接多个请求、显存不浪费的推理服务vLLM 基本是首选。那为什么不用别的我对比过几种常见路径方案优点在 AMD 上的现实问题transformers 直接推理简单、无额外依赖吞吐低、显存浪费、不适合做服务llama.cppCPU/GPU 混合、量化方便ROCm 后端支持有但配置繁琐服务化能力弱Text Generation Inference功能全官方对 ROCm 支持不如 vLLM 直接vLLM吞吐高、API 标准、社区活跃需要 ROCm 版本匹配装错就报错所以结论很明确在 AMD 平台上做正经的模型推理服务vLLM 是当前性价比最高的选择。前提是你把 ROCm 环境搞对。2.2 云实例选型别一上来就挑最贵的租云实例跑模型最容易犯的错是“先挑最强的卡”。我一开始也这么想后来发现没必要。选型要看三个维度显存、显存带宽、ROCm 支持程度。Gemma4 这个量级的模型如果你跑的是 7B 到 9B 参数区间的版本FP16 精度下权重大概占 14GB 到 18GB加上 KV Cache 和运行时开销24GB 显存是起步线40GB 以上会舒服很多。如果你打算跑更大的版本或者做量化显存需求另算。AMD 云实例上常见的加速卡我实际接触过的几类Instinct MI 系列数据中心级显存大、带宽高ROCm 支持最完整适合正经部署。Radeon Pro 系列工作站卡显存中等ROCm 支持较好。消费级 Radeon便宜但 ROCm 官方支持列表里不一定有容易踩坑。我的建议是优先选官方 ROCm 支持列表里明确列出的型号。别图便宜选了个不在列表里的卡后面驱动和框架对不上排查能耗掉你一整天。云厂商的实例页面一般会标注显卡型号选之前去 ROCm 官方文档的兼容性矩阵里对一眼这一步花两分钟能省你两小时。2.3 15 分钟这个时间账怎么算标题说 15 分钟我实测下来如果你满足以下前提15 分钟是能跑通的实例已经开机系统是 Ubuntu 22.04 或 24.04ROCm 已经预装好很多 AMD 云镜像自带模型权重已经下载到本地或者能快速拉到网络通畅pip 装包不卡。如果这四条有一条不满足时间就得往上加。比如你自己从零装 ROCm光驱动和依赖就能折腾半小时以上。所以“15 分钟”指的是环境就绪后的部署时间不是从裸机开始。这一点得说清楚不然容易误导人。3. 环境确认与 ROCm 状态检查3.1 第一步永远是确认显卡和驱动登录实例后别急着装东西先把家底摸清楚。第一条命令rocminfo | head -50这条命令会输出 ROCm 运行时识别到的设备信息。如果你看到类似Agent 2下面跟着Name: gfx90a或者gfx1100这样的字段说明 ROCm 已经认到卡了。如果这条命令直接报command not found那说明 ROCm 没装或者没在 PATH 里得先解决这个。紧接着确认驱动版本cat /opt/rocm/.info/version这个文件里写的是 ROCm 的版本号比如6.2.0。记住这个号后面装 vLLM 的时候要对应。还有一个很多人会忽略的检查lsmod | grep amdgpu确认amdgpu内核模块已经加载。如果这条没输出说明驱动层面就有问题后面全白搭。提示有些云实例的镜像里 ROCm 装在非标准路径rocminfo找不到不代表没装。可以先find / -name rocminfo 2/dev/null找一下再把它所在目录加进 PATH。3.2 用 PyTorch 做一次最小验证ROCm 装好了不代表 PyTorch 能用。装 vLLM 之前我习惯先用一个干净的 PyTorch 环境做最小验证这样出问题能快速定位是 ROCm 的锅还是 vLLM 的锅。python3 -c import torch; print(torch.__version__); print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))注意这里用的是torch.cuda不是笔误。ROCm 版的 PyTorch 在 API 上兼容 CUDA 命名torch.cuda.is_available()返回True就说明 PyTorch 认到了 AMD 显卡。如果返回False八成是装成了 CPU 版或者 CUDA 版得卸了重装 ROCm 版。装 ROCm 版 PyTorch 的正确姿势是从官方源装pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.2这里的rocm6.2要跟你实际的 ROCm 版本对上。版本对不上轻则 warning重则直接崩。3.3 显存和算力的快速摸底再跑一个简单的矩阵运算确认算力真的用上了import torch a torch.randn(4096, 4096, devicecuda) b torch.randn(4096, 4096, devicecuda) c a b torch.cuda.synchronize() print(c.sum().item())如果这段跑完没报错而且你能在另一个终端用rocm-smi看到显卡利用率飙升那说明整条计算链路是通的。rocm-smi相当于 AMD 版的nvidia-smi看显存占用、温度、功耗都靠它。4. vLLM 在 ROCm 上的安装与配置4.1 安装方式的选择pip 还是源码vLLM 在 AMD 上的安装我试过两条路pip 直接装和源码编译。结论是——优先用官方提供的 ROCm 预编译 wheel除非你有特殊需求。pip 装的话官方文档给的命令大致是这样pip install vllm --extra-index-url https://wheels.vllm.ai/rocm/这个extra-index-url是关键它指向的是 vLLM 为 ROCm 编译的 wheel 仓库。如果你不加这个pip 会去默认源拉一个 CUDA 版的 vLLM装完 import 就报错。源码编译适合两种情况一是你要改 vLLM 源码做定制二是预编译 wheel 跟你的 ROCm 版本不匹配。编译过程比较吃时间而且对系统依赖要求高新手不建议一上来就走这条路。4.2 版本匹配这件事必须较真我踩过最深的坑就是版本不匹配。具体表现是vLLM 装上了import 也过了但一加载模型就报HIP error或者invalid device function。这类错误十有八九是 vLLM 编译时用的 ROCm 版本跟你运行时的版本不一致。所以装之前把这三个版本号对齐组件查看命令要求ROCmcat /opt/rocm/.info/version记下主版本号PyTorchpython3 -c import torch; print(torch.version.hip)跟 ROCm 主版本一致vLLMpip show vllm选对应 ROCm 版本的 wheeltorch.version.hip这个字段很多人不知道它能直接告诉你 PyTorch 是针对哪个 HIP 版本编译的。如果这个值跟你的 ROCm 版本对不上先解决 PyTorch再装 vLLM。4.3 环境变量别小看这几行ROCm 环境下有几个环境变量对 vLLM 的稳定性影响很大我建议直接写进~/.bashrcexport HIP_VISIBLE_DEVICES0 export ROCR_VISIBLE_DEVICES0 export PYTORCH_HIP_ALLOC_CONFexpandable_segments:True第一条和第二条是限定可见的显卡多卡机器上尤其重要避免 vLLM 乱认卡。第三条是显存分配策略expandable_segments能缓解显存碎片问题跑长上下文的时候不容易 OOM。还有一个可选但很有用的export VLLM_USE_ROCM1有些 vLLM 版本需要这个显式声明才会走 ROCm 路径。如果 import 后行为异常加上它试试。注意环境变量改完记得source ~/.bashrc或者重开终端不然不生效。我就干过改完变量直接跑、结果没生效、排查半天的蠢事。5. Gemma4 模型加载与推理服务启动5.1 模型权重的准备Gemma4 的权重获取渠道这里不展开假设你已经拿到了模型文件目录结构大致是gemma4-model/ ├── config.json ├── tokenizer.json ├── tokenizer_config.json ├── model-00001-of-0000X.safetensors ├── ...确认两件事一是config.json里的architectures字段vLLM 靠它识别模型类型二是权重的分片数量跟 index 文件对得上。如果权重下载不完整vLLM 加载到一半会报safetensors相关的错。5.2 启动命令的拆解最简启动命令长这样python3 -m vllm.entrypoints.openai.api_server \ --model /path/to/gemma4-model \ --dtype float16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000逐个参数解释--model模型目录路径指向你放权重的地方。--dtype float16精度。ROCm 上 FP16 支持最成熟BF16 在部分卡上也能跑但 FP16 更稳。--max-model-len最大上下文长度。这个值直接决定 KV Cache 占多少显存别一上来就拉满先给个保守值跑通再说。--gpu-memory-utilization显存利用率上限。0.9 意味着允许 vLLM 用 90% 的显存留一点给系统。--port服务端口。启动过程中终端会打印一堆日志重点看这几行模型加载进度、KV Cache 分配了多少 block、服务监听的地址。如果卡在加载阶段不动多半是显存不够或者权重有问题。5.3 显存不够怎么办几个实用调整如果启动时报 OOM按这个顺序调降--max-model-len从 8192 降到 4096 甚至 2048KV Cache 需求直接减半。降--gpu-memory-utilization从 0.9 降到 0.8给系统留更多余量。用量化vLLM 支持 AWQ、GPTQ 等量化格式如果模型有量化版本显存需求能降到 FP16 的一半左右。开张量并行多卡的话加--tensor-parallel-size 2把模型切到两张卡上。我实测下来Gemma4 的 9B 级别模型在 24GB 显存的卡上max-model-len设 4096、gpu-memory-utilization设 0.85是能稳定跑起来的。再往上加就得看具体卡的余量了。5.4 服务验证curl 一把梭服务起来后用标准的 OpenAI 兼容接口测一下curl http://localhost:8000/v1/completions \ -H Content-Type: application/json \ -d { model: /path/to/gemma4-model, prompt: 用一句话解释什么是张量并行, max_tokens: 128, temperature: 0.7 }如果返回了正常的 JSON 且choices里有文本恭喜链路通了。如果报错看错误信息里的关键词model not found是模型路径问题CUDA out of memoryROCm 下也会这么报是显存问题HIP error是底层环境问题。6. 常见问题与排查技巧实录6.1 问题速查表现象可能原因排查方向rocminfo无输出ROCm 未装或 PATH 不对检查/opt/rocm是否存在补 PATHtorch.cuda.is_available()为 False装了 CPU/CUDA 版 PyTorch重装 ROCm 版import vllm 报错wheel 版本与 ROCm 不匹配核对版本号重装对应 wheel加载模型时 OOM显存不足降 max-model-len 或用量化推理结果乱码tokenizer 不匹配检查 tokenizer 文件是否完整服务启动后无响应端口被占或防火墙换端口检查监听地址HIP error: invalid device function编译架构与运行卡不匹配确认 ROCm 支持该卡型号6.2 几个我踩过的坑坑一多卡机器上 vLLM 认错卡。有一次实例上有两张卡我只想用其中一张结果 vLLM 默认把两张都占了导致另一张卡上的任务被挤掉。解决办法就是前面说的HIP_VISIBLE_DEVICES显式指定用哪张。坑二max-model-len设太大导致启动慢。KV Cache 是按max-model-len预分配的你设 32768vLLM 启动时就要预留对应显存启动时间会明显变长甚至直接 OOM。我的经验是先用小值跑通确认服务正常后再逐步往上调找到显存能承受的上限。坑三pip 源混用导致装错版本。系统里如果同时配了多个 pip 源装 vLLM 时可能从错误的源拉到 CUDA 版。装完一定要pip show vllm看一眼确认来源和版本对。坑四忘记source环境变量。这个前面提过但真的很容易忘。改完.bashrc不 source等于没改。6.3 性能调优的几个方向跑通之后如果想压榨性能可以从这几个角度入手批处理大小vLLM 的连续批处理是自动的但你可以通过--max-num-seqs控制并发序列数调大能提升吞吐但吃显存。KV Cache 精度vLLM 支持 FP8 的 KV Cache能省显存但要看 ROCm 版本是否支持。张量并行多卡时用--tensor-parallel-size能跑更大的模型但卡间通信有开销不是越多越好。我个人的经验是单卡能跑通就别急着上多卡多卡的通信开销和配置复杂度会吃掉一部分收益。先把单卡调优到位再考虑横向扩展。7. 关于这套方案的一些个人体会AMD ROCm 跑 vLLM 这件事两年前我会劝你别折腾现在我的态度变了。ROCm 6.x 之后主流推理框架的适配确实上了一个台阶vLLM 在 AMD 卡上的表现已经能撑起生产级的推理服务。当然它跟 CUDA 生态比还有差距主要体现在文档完善度和社区问答的丰富度上——你遇到问题时能搜到的现成答案比 NVIDIA 平台少。但这恰恰意味着现在把 ROCm 这套链路摸熟的人在团队里是有稀缺价值的。Datawhale 和 AMD 推这个方向我觉得意义就在这儿把门槛降下来让更多人愿意试。15 分钟部署不是终点是个起点。跑通之后你可以往上叠 RAG、叠 Agent、叠多模型路由这些在 vLLM 的 OpenAI 兼容接口之上都是顺理成章的事。最后分享一个小技巧如果你在云实例上反复部署建议把整个环境打包成 Docker 镜像。vLLM 官方有 ROCm 版的 Dockerfile基于它改一改把模型权重挂载进去下次换实例直接拉镜像启动比重新配环境快得多。我自己维护了一个基础镜像从开机到服务可用实测能压到 5 分钟以内。