企业官网建设流程全解析

看到“15 分钟部署 Gemma 4”这一串字，我第一反应是：又是个标题党吧？结果自己上手把 AMD ROCm 云实例从选型、开实例、装环境到跑通推理完整走了一遍，发现 15 分钟还真不是吹的——前提是你别自己给自己挖坑。这篇文章就是我挖了整个过程的记录，把 ROCm 软件栈、云实例背后的调度逻辑、部署工具链的选型、以及我实测踩过的那些坑，全部摊开讲清楚。

这篇内容适合谁？如果你是 Datawhale 和 AMD 活动的参与者，拿到免费算力额度后不知道从哪里下手；或者你手上刚好有 AMD GPU，想跑通大模型推理但被 ROCm 文档绕得头大；再或者你只是好奇“AMD GPU 跑大模型到底能不能打”，那这篇都值得看完。我会尽量把底层逻辑讲明白，而不是只给你一串复制粘贴的命令。

1. 这个项目到底在做什么：需求拆解与方案选型

1.1 为什么是 Gemma 4，为什么是 ROCm

先说选型逻辑。Gemma 系列是 Google 出的轻量级开放模型，主打单机单卡可部署，对显存要求相对友好。拿它来验证 AMD ROCm 的推理链路，是一个很聪明的选择——GPU 厂商、模型厂、开发者三方各取所需：AMD 需要一个明星模型来证明 ROCm 生态成熟度，Google 需要更多硬件平台来扩大模型影响力，而开发者只需要一个能跑、能改、能上生产的模型。

ROCm 全称是 Radeon Open Compute Platform，是 AMD 对标 NVIDIA CUDA 的 GPU 计算软件栈。在过去几年里，ROCm 的生态成熟度确实和 CUDA 有差距，但这两年变化非常明显：PyTorch 官方版本直接支持 ROCm，vLLM 也有 ROCm 后端，Ollama 通过 OpenCL/HIP 也能跑。换句话说，AMD GPU 上跑大模型推理，已经从“折腾半天可能还跑不起来”进化到了“按标准流程走基本能通”。

这个项目本质上是在做一件事：验证“AMD ROCm 云实例 + Gemma 4 推理部署”这条链路的可行性，并沉淀出一条可复现的部署路径。整篇文章最核心的价值不是那 15 分钟，而是这 15 分钟背后所有的环境认知和避坑经验。

1.2 云实例选型：显存、带宽与性价比的三角博弈

AMD ROCm 云实例并不是只有一种规格，云厂商通常提供的是基于 Instinct 系列加速卡的实例。我这次实测下来，遇到的实例类型大致有这些：

选型的时候你会遇到一个很现实的矛盾：同一家云厂商给的 MI300X 实例可能只有一个规格，但不同区域、不同可用区的库存情况完全不同。我的建议很直接：能选 MI300X 就选 MI300X，显存 192GB 意味着你完全不需要考虑序列长度裁剪问题，7B 模型跑 32K 上下文都很轻松。如果只有 MI210，那就把模型量化到 4bit 或 8bit，控制 batch size，效果也不会差。

我还想提醒一点：云实例和裸金属服务器承载的 GPU 驱动逻辑不太一样。云实例通常通过虚拟机直通或者容器化方式把 GPU 暴露给用户，你看到的/dev/kfd和/dev/dri设备是虚拟化层映射过来的。这意味着你在本地裸机上折腾的那套内核模块编译过程，在云实例上基本不需要碰，但也因为虚拟化层的存在，有些硬件信息会被过滤掉——这部分后面我会详细讲。

1.3 “15 分钟”背后的部署逻辑：预置镜像 + 脚本化

15 分钟这个数字不是拍脑袋定的。它的核心逻辑是：部署不需要从零开始编译任何东西。AMD 官方和云厂商合作提供的 ROCm 镜像里，驱动、ROCm 用户态库已经全部预装好了，你要做的其实只有三件事：拉起容器、拉模型权重、启动推理服务。

这和我们以前在 CUDA 环境里自己配驱动的习惯完全不同。很多人拿到 AMD 云实例第一反应是去装驱动，但云厂商预制的镜像比我手动装靠谱得多，卸载重装反而容易把内核模块弄坏。我这次就是一开始不信邪，自己折腾了 amdgpu-install，结果系统重启后 GPU 设备直接消失，最后只能从快照恢复。

所以 15 分钟能部署成功的前提，是把“环境准备”这个环节外包给云厂商的预置镜像，把“模型权重获取”外包给模型仓库，把“推理框架”外包给 vLLM 或 Ollama。你要做的，是像拼乐高一样把这几块积木拼起来，而不是自己烧制每一块积木。

2. ROCm 软件栈到底长什么样：核心细节与前置环境

2.1 从 amdgpu 到 PyTorch：ROCm 四层架构

想顺利部署，你得先理解 ROCm 在系统里是怎么串起来的。我习惯把它拆成四层来看：

• 第一层：内核驱动层amdgpu。这是 Linux 内核自带的 AMD GPU 驱动模块，负责显存分配、命令提交、中断处理。在云实例上你看不到它，但它一直在工作。
• 第二层：用户态运行时 ROCr 和控制层 ROCt。ROCr 提供 API 入口，ROCt 负责设备管理，可以理解为 CUDA Runtime 的对应物。
• 第三层：计算库，比如 hipBLAS、rocBLAS、rocFFT、MIOpen。这些是高性能算子库，PyTorch 自动调用它们来完成矩阵乘法和卷积。
• 第四层：框架层，比如 PyTorch for ROCm、vLLM ROCm backend、Ollama 的 HIP 后端。这一层才是你实际打交道的对象。

这个分层结构和 CUDA 是大致对应的：amdgpu 类似 nvidia 内核驱动，ROCr 类似 CUDA Runtime，hipBLAS 类似 cuBLAS，PyTorch for ROCm 就是你在 CUDA 上安装的那个 PyTorch 的 AMD 版本。所以你完全可以用 CUDA 那套心智模型来理解 ROCm，只是在容器里多留意工具差异。

有一点必须注意：ROCm 和 CUDA 的 API 是 HIP 兼容层串起来的。HIP 的全称是 Heterogeneous-Computing Interface for Portability，它提供了一组 API，既能编译到 CUDA 后端，也能编译到 ROCm 后端。这就意味着很多为 CUDA 写的算子代码可以通过 hipify 工具自动转换成 HIP 代码，大大降低了迁移成本。但代价是，HIP 这个抽象层偶尔会有性能损耗，而且在一些冷门算子上的支持度不如原生 CUDA。

2.2 云实例的前置环境：不折腾才是最好的折腾

云实例和本地裸机的最大区别在于：你对内核的管控能力非常弱。本地你可以改 GRUB 启动参数、重新编译内核模块、设置 IOMMU 参数，但云实例只能接受云厂商给你的基础环境。

所以我的建议是：拿到实例后，先花两分钟做一次基础巡检，确认三件事：

# 1. 确认 GPU 设备节点存在 ls -la /dev/kfd /dev/dri # 2. 确认 ROCm 用户态工具可用，能看到 GPU 状态 rocm-smi # 3. 确认 ROCm 版本和目标框架匹配 dpkg -l | grep rocm

这三个命令跑完，你心里就有底了。/dev/kfd是 AMD GPU 的 Compute 设备节点，类似 NVIDIA 的/dev/nvidia0；/dev/dri是渲染设备节点，通常对应显卡的驱动接口。这两个节点是容器启动时挂载进来的，只要它们存在且当前用户有权限访问，ROCm 就成功了一半。

说到权限，容器启动时需要挂载这两个设备并加入 video 组，否则你在容器外能跑，容器内就报 Permission denied。这个坑我在 3.1 节里会具体写。

另外，云实例的镜像通常预装了某个特定版本的 ROCm，比如 5.7 或 6.x。你在装 PyTorch 的时候必须选择对应的索引地址，比如 ROCm 6.2 对应pip install torch --index-url https://download.pytorch.org/whl/rocm6.2。版本不对最常见的问题就是算子编译失败或推理结果错误，所以开工前先记好这个版本号。

2.3 部署工具链选型：ollama、vLLM 还是 Transformers

跑 Gemma 4 推理，工具链主要就是三条路线，选哪一条取决于使用场景。我整理了一份对比：

三条路线我都实际跑了一遍，说下直观感受。Ollama 是最省心的，装好之后一条ollama pull gemma4:7b就能把模型拉下来，然后ollama run gemma4:7b直接开聊。它的缺点是不好精细控制采样参数，分布式弦、多模态输入这些能力也弱一些。

vLLM 是生产环境的首选。它支持 PagedAttention，显存利用率和吞吐都远超朴素 Transformers。我在 AMD 实例上用 vLLM 部署 Gemma 4，能直接兼容 OpenAI 风格的/v1/completions接口，后续接前端应用非常丝滑。如果你会部署 DeepSeek 的 vLLM 流程，那 Gemma 4 基本就是换一个模型名的问题。

Transformers 路线适合做深度调试。你可以直接拿到 logits、可以调试 attention mask、可以改 Top-P 采样逻辑。但如果你只是为了对外提供服务，别走这条路——它对短文本生成的效率利用率远不如 vLLM，尤其在多并发场景下差距极其明显。

3. 15 分钟实操全过程：从空实例到推理接口

3.1 开实例前的准备工作清单

很多人部署失败，不是因为命令不对，而是因为开始之前少做了几步准备。我把自己的开实例前清单分享出来：

• 确认区域有目标实例库存，比如 MI300X 是否有可用的 Spot 或按需实例；
• 选镜像的时候优先选“ROCm 预装”的 Ubuntu 22.04 或 24.04 镜像，不要选最小化系统；
• 磁盘给 200GB 以上，模型权重 + tokenizer + 运行库很容易超过 100GB，尤其是你还要拉一个 7B 模型的 fp16 权重；
• 开完实例立即创建快照。这一步极其重要，部署是一个不断试错的过程，快照可以让你随时回退到零状态；
• 记录下 SSH 登录方式和密钥路径，云实例的默认登录用户一般是ubuntu，不要习惯性地用 root。

此外，我强烈建议在开实例之前先想清楚你要跑什么规模的模型。如果你的目标只是“跑通”，那用 7B 模型 + 量化足矣；如果目标是“支撑一定并发访问”，那硬件规格就要相应提高。这个决策影响后续所有参数设置，提前想清楚能省很多时间。

3.2 核心部署步骤：从登录到模型拉取

接下来就是 15 分钟的正题了。我直接贴出这次从空实例到跑通推理的完整步骤，每一步都有注释说明。

第 1 步：登录实例，确认环境

ssh ubuntu@<实例IP> rocm-smi

rocm-smi能正确列出 GPU 型号、显存、温度和驱动版本，说明 ROCm 栈已经就绪。如果这一步报错，后面任何操作都先不要做，排查完环境再说。

第 2 步：启动带 ROCm 支持的容器

docker run -it --rm \ --device=/dev/kfd \ --device=/dev/dri \ --group-add video \ --ipc=host \ --shm-size=16G \ --security-opt seccomp=unconfined \ rocm/vllm:latest

这里要解释几个关键参数：--device=/dev/kfd和--device=/dev/dri是把 AMD GPU 设备映射进容器；--group-add video是让容器内进程拥有访问渲染节点的权限；--ipc=host和--shm-size是因为 PyTorch 多进程 DataLoader 依赖共享内存，太小会报错；seccomp=unconfined则是避免系统调用被容器安全策略拦截。这些参数少了哪一个，都可能在某个奇怪的阶段报错。

如果你不想用 Docker，也可以直接在宿主机上装 ROCm 版的 PyTorch，但我个人的体验是 Docker 更干净——环境隔离好，坏了直接删了重建，不污染宿主系统。

第 3 步：拉取模型权重

这里有两个选择。如果网络条件好，直接用 HuggingFace 下载：

huggingface-cli download google/gemma-4-7b-it

如果从 HuggingFace 拉取一直超时，就改用 ModelScope 的镜像站。我这次实测中遇到 GitHub 和 HuggingFace 的连接不稳定，用 ModelScope 下载 Gemma 4 权重反而全程无压力。下载完成后把权重整理成这样的路径：

/path/to/gemma4/ config.json tokenizer.model model-00001-of-00002.safetensors model-00002-of-00002.safetensors

第 4 步：启动 vLLM 推理服务

python -m vllm.entrypoints.openai.api_server \ --model /path/to/gemma4 \ --dtype float16 \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --port 8000

如果你的路径下只有一份真实权重文件，指明路径就能直接用。--gpu-memory-utilization 0.9表示 vLLM 最多占用 90% 显存用于 KV cache，剩下 10% 留给计算缓冲。--tensor-parallel-size 1表示单卡推理，如果有多张卡且显存不够，可以调成 2 或 4。

第 5 步：验证推理接口

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "/path/to/gemma4", "messages": [{"role": "user", "content": "你好，请用一句话介绍你自己"}], "max_tokens": 128}'

能正常返回一段文本，说明部署已经打通。从这一步你可以接 Flask 应用、接前端、或者直接作为内网服务开放给其他业务调用。

3.3 资源测算与推理参数设定

部署成功只是起点，想让服务跑得稳，你还得学会估算显存占用。以 Gemma 4 7B 为例，我经常用一个简化公式来估算总量：

• FP16 权重占用 = 模型参数量 × 2 字节 ≈ 7B × 2B = 14GB；
• KV cache 占用 = 2 × 层数 × 隐藏维度 × 序列长度 × 2 字节。7B 模型层数 30 左右、隐藏维度 3584 左右，序列长度 4096 时，KV cache 约 1.8GB；序列长度拉到 8192 约 3.6GB；
• 推理过程的激活内存、临时计算结果，约 2~4GB。

也就是说，7B 模型在 fp16 下，序列长度 8192，最少需要 20GB 左右的显存，加上系统开销和建议预留，24GB 能跑但非常紧张，64GB（MI210）才是舒适区，192GB（MI300X）基本就是尽情用。

如果你只有 32GB 显存，我的建议是 8bit 量化后再上推理。8bit 权重从 14GB 降到 7GB，KV cache 占用不变，整体显存需求直接降到 12~14GB，各种余量都宽裕不少。量化精度损失在中短文本生成任务里基本无感，如果你还有 El Capitan 级别的超长代码生成需求，再考虑回退 fp16。

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

4.1 高频故障速查表

我把这次部署中遇到的高频问题整理成了一张速查表，你可以直接收藏用：

其中lspci | grep -i amd无反应是很多新手会吓一跳的问题。其实lspci查看的是 PCI 总线上的设备信息，云环境里虚拟化层对直通设备的暴露方式各有不同，看不到并不等于 GPU 不存在。你只要看/dev/kfd和rocm-smi的输出，就知道卡在不在、驱动通不通了。

这里还想提醒一个容易踩的坑：启动 vLLM 时如果模型路径写错，它会报No such file or directory，但有时不是找不到文件，而是权重分片文件不完整。云实例磁盘 IO 比你本地差很多，下载大文件时我建议加个校验和管理，比如对 safetensors 文件做一次ls -la确认文件大小与仓库里标注一致。

4.2 几个值得记住的避坑细节

• 不要在云实例上手动装 ROCm 驱动套件。我试过用amdgpu-install卸载预装驱动，结果直接导致内核模块损坏，实例重启后 GPU 彻底失联，只能从快照恢复。预制镜像里的驱动是云厂商和 AMD 一起验证过的，它肯定不是最新版，但它能跑。
• 不要在宿主环境直接跑推理。在宿主环境里，你的 shell 前缀可能没有加载 ROCm 环境变量，运行 PyTorch 时报错率很高。直接在容器里跑才是最干净的路径。
• HIP_VISIBLE_DEVICES 和 CUDA_VISIBLE_DEVICES 不要混用。在 ROCm 环境里设置 CUDA_VISIBLE_DEVICES 是不会生效的，必须用 HIP 前缀。很多人从 CUDA 迁移过来在这里卡了很久。
• 快照是救命稻草。云实例不像本地机器，出了问题很难手动修复。开完实例的第一件事，一定是打快照。我这次折腾驱动失败，如果不是先打了快照，至少多花一个小时。

5. 性能调优与生产化扩展

5.1 从单次推理到并发服务

如果你只是想在本地跑一次问答，那 vLLM 部署完就能收工了。但如果你想给团队提供一个内部 AI 服务，就得把并发能力拉起来。

vLLM 最核心的机制是--max-num-seqs和--max-model-len。前者控制单次调度中最多并发处理的序列数，后者是每个序列的最大 token 长度。调高--max-num-seqs能提升吞吐，但显存占用也会随之上升。我这次在 MI300X 上部署 Gemma 4 7B，参数设置如下：

python -m vllm.entrypoints.openai.api_server \ --model /path/to/gemma4 \ --dtype float16 \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.95 \ --max-model-len 16384 \ --max-num-seqs 64 \ --port 8000

--max-num-seqs 64就表示同一时刻最多有 64 个请求共享一块 GPU 的 KV cache。实测下来，单机推理吞吐大约在 60~120 tokens/s 之间（具体取决于 prompt 长度和生成长度的比例），对比纯 Transformers 的串行推理，提升非常明显。

如果你有多张 GPU 卡，--tensor-parallel-size也可以设为 2 或 4，vLLM 会自动做张量并行切分。但要提醒一句：张量并行会引入通信开销，如果只是 7B 模型且显存足够单卡，设置成 1 通常是更高效的选择。大模型（比如 70B）才值得上多卡。

5.2 监控、量化与下一步扩展

部署完成之后，监控和迭代才是日常。我习惯用两个工具来监控：

1. rocm-smi看 GPU 占用、显存使用、温度和风扇；
2. 自建一个简单的 FastAPI 端点，记录每次推理的 latency 和 token 数，方便后续做容量规划。

对于量化，生产环境里我比较认同的核心思路不是影响输出质量优先，而是最优先考虑“显存换吞吐”。把模型从 fp16 换成 8bit 会让同样显存条件下可服务的并发数翻倍，很多时候比单纯换大卡更划算。但如果你的业务对生成质量非常敏感，量化前一定做一轮对比测试，别只看显存数字。

如果你本来就会部署 DeepSeek 类的模型，把 Gemma 4 换成任意一个开源 LLM 其实都是同一套流程。这个项目的下一步扩展方向可以是：接入 RAG 知识库，配合 Dify 这类低代码平台做私有化问答；或者把 vLLM 接口改成流式输出，配合前端做打字机效果。部署的骨架已经搭好，上面挂什么应用就看你业务想象力了。

最后再分享一个小技巧：在 AMD 云实例上部署任何模型，先花五分钟跑一遍rocm-smi，再跑一个极小的生成测试，确认 GPU 设备可见、推理链路通畅，再开始谈优化。我见过太多人一上来就把 70B 模型往里塞，最后 OOM 了还不知道去哪里定位问题。基础环境确认一次，后面所有模型的部署路径都稳定提速——比起在 CUDA 环境里踩过的各种驱动冲突，ROCm 现在这个状态已经算是省心的了。