企业官网建设流程全解析

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 平台上做正经的模型推理服务，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 分钟是能跑通的：

1. 实例已经开机，系统是 Ubuntu 22.04 或 24.04；
2. ROCm 已经预装好（很多 AMD 云镜像自带）；
3. 模型权重已经下载到本地或者能快速拉到；
4. 网络通畅，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, device='cuda') b = torch.randn(4096, 4096, device='cuda') 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 版本跟你运行时的版本不一致。

所以装之前，把这三个版本号对齐：

torch.version.hip这个字段很多人不知道，它能直接告诉你 PyTorch 是针对哪个 HIP 版本编译的。如果这个值跟你的 ROCm 版本对不上，先解决 PyTorch，再装 vLLM。

4.3 环境变量：别小看这几行

ROCm 环境下有几个环境变量对 vLLM 的稳定性影响很大，我建议直接写进~/.bashrc：

export HIP_VISIBLE_DEVICES=0 export ROCR_VISIBLE_DEVICES=0 export PYTORCH_HIP_ALLOC_CONF=expandable_segments:True

第一条和第二条是限定可见的显卡，多卡机器上尤其重要，避免 vLLM 乱认卡。第三条是显存分配策略，expandable_segments能缓解显存碎片问题，跑长上下文的时候不容易 OOM。

还有一个可选但很有用的：

export VLLM_USE_ROCM=1

有些 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，按这个顺序调：

1. 降--max-model-len：从 8192 降到 4096 甚至 2048，KV Cache 需求直接减半。
2. 降--gpu-memory-utilization：从 0.9 降到 0.8，给系统留更多余量。
3. 用量化：vLLM 支持 AWQ、GPTQ 等量化格式，如果模型有量化版本，显存需求能降到 FP16 的一半左右。
4. 开张量并行：多卡的话加--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 memory（ROCm 下也会这么报）是显存问题，HIP error是底层环境问题。

6. 常见问题与排查技巧实录

6.1 问题速查表

6.2 几个我踩过的坑

坑一：多卡机器上 vLLM 认错卡。有一次实例上有两张卡，我只想用其中一张，结果 vLLM 默认把两张都占了，导致另一张卡上的任务被挤掉。解决办法就是前面说的HIP_VISIBLE_DEVICES，显式指定用哪张。

坑二：max-model-len设太大导致启动慢。KV Cache 是按max-model-len预分配的，你设 32768，vLLM 启动时就要预留对应显存，启动时间会明显变长，甚至直接 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 分钟以内。