直奔主题：AMD ROCm 云实例跑 Gemma4，15 分钟到底是噱头还是真能落地？
先说结论：15 分钟这个数字，如果你指的是从拿到一台裸的 AMD 云实例、到模型开始正常吐字，那是有可能做到的，但前提是你别踩我踩过的那些坑。这次是 Datawhale 和 AMD 联合组织的一次实操挑战，目标就是在 ROCm 云实例上把 Gemma4 跑起来。我原以为这就是个“装个驱动、拉个模型、起个服务”的流水账，结果从选实例到真正调通，前后折腾了大半天，把 ROCm 的脾气摸了个七七八八。
这篇文章不打算给你复述一遍官方文档，而是把我从零开始部署 Gemma4 的完整路径、踩过的坑、以及最终沉淀下来的可复用方案全部摊开。适合三类人看：一是刚接触 AMD GPU 云实例、以前只在 NVIDIA 上部署过大模型的同学；二是想用 Gemma4 做应用开发但不想被 CUDA 生态绑死的人；三是已经在 ROCm 上碰过壁、想知道自己是不是漏了某个关键环节的老手。
先说清楚，Gemma4 是 Google 开源的大语言模型系列，参数规模覆盖了从十几亿到几百亿的多个档位。它不像某些模型那样对显存极其挑剔，但也不是随便一台机器就能跑得舒服的。而 AMD 这边的软件栈 ROCm，近几年成熟度提升很明显，尤其是对 PyTorch 的原生支持和各种推理框架的适配，已经不像早年那样“装完驱动就黑屏”。但成熟归成熟，坑仍然存在，而且大部分坑都藏在环境变量、版本对齐、以及容器镜像的细节里。
1. 为什么这活儿值得干：AMD 在 AI 部署里成了“最熟悉的陌生人”
1.1 从 NVIDIA 到 AMD，部署思维要切换什么
大多数做模型部署的人，工作流已经被 CUDA 深深塑造了。nvidia-smi、CUDA_VISIBLE_DEVICES、pip install torch之后自动装 CUDA 版 PyTorch，这几乎是肌肉记忆。一旦换到 AMD 平台，第一个不适感来自“显卡叫法都不一样了”——在 ROCm 的世界里，GPU 不再叫NVIDIA GeForce，而是AMD Instinct或者消费级的Radeon，对应的工作台命令是rocm-smi。
更关键的是生态位差异。NVIDIA 成熟的TensorRT-LLM、FasterTransformer在 AMD 上要么不可用，要么有阉割版。但好消息是，AMD 选择了一条“兼容优先”的路线：你能跑 PyTorch 的地方，ROCm 大概率也能跑，只需在安装 PyTorch 时选择 ROCm 版本，模型权重完全复用，model.to('cuda')这种代码也不用改。毕竟 ROCm 在 API 层面做了大量 CUDA 兼容映射，很多算子直接走HIP（AMD 的 CUDA 对应层）就能跑起来。
我这次选的是云实例，而不是本地显卡，原因很简单：手头没有 AMD 卡，而且云实例的最大好处是“买错了可以换”。AMD 的云实例目前在多家云厂商都能开到，主流的是 Instinct MI210、MI250、MI300 系列，也有部分厂商提供 Radeon 系列的云主机。部署前的第一件事就是搞清楚自己手里的卡是什么型号、显存多大，这直接决定了你能跑哪个档位的 Gemma4。
1.2 15 分钟的承诺，实际拆解成几步
如果只看 Needs 的话，15 分钟大概可以拆成这样：5 分钟装驱动和 ROCm 核心组件，3 分钟拉模型权重（前提是网络够快），5 分钟起服务，2 分钟验证输出。但实际上每一步都可能暴雷。比如驱动版本和 ROCm 版本必须匹配，ROCm 版本又必须和 PyTorch 编译时用的版本一致，任何一个环节没对齐，轻则报个找不到设备的错，重则直接训练/推理时死机。
所以这篇文章的叙述顺序，其实就是我的实际操作顺序：选型 → 摸清环境 → 选部署路径 → 踩坑 → 找到最优方案。如果你想复现，建议跟着我的顺序走，而不是先跳到最后一步看结论。
2. 部署前的环境摸查：ROCm 云实例选型与裸机状态验证
2.1 实例选型：显存和架构怎么选
Gemma4 的众多尺寸里，最容易跑的是小尺寸版本（比如 2B、9B 这类量级），中等尺寸的 27B 需要 32GB 以上显存才舒服，最大的几个版本则直接瞄准了多卡场景。选实例之前先想清楚自己兜里有多少 VRAM。
我这次用的是 AMD Instinct MI210，单卡 64GB HBM2e，理论上 27B 版本的 Gemma4 量化成 8bit 之后可以塞进去。如果你的需求只是验证流程，2B 或 9B 版本配一张 16GB 的 Radeon 也够用。这里有个容易犯的错误：只看显存不看架构。ROCm 对消费级 Radeon 的支持不如 Instinct 完整，某些算子（比如 FlashAttention 的 ROCm 实现）在消费卡上可能走不了，只能用 fallback 路径，性能掉一半还多。预算允许的情况下，优先选 Instinct 系列，省心程度完全不一样。
2.2 开箱之后第一件事：验证 GPU 可见性
拿到云实例之后的第一件事，不是急着git clone模型仓库，而是用下面这串命令摸一遍底：
rocm-smi --showproductname && rocminfo | grep -E "Name|Marketing" | head -20这俩命令一个告诉你显卡型号和驱动版本，一个告诉你 ROCm 能不能正确枚举出 GPU。如果rocm-smi输出里没有你的显卡型号，或者rocminfo里看不到任何 GPU agent，后面的部署就别浪费时间了——这不是软件栈没配好，就是虚拟化层掉了 GPU 直通。
我当时拿到的是预装 Ubuntu 22.04 的镜像，默认带了 ROCm 5.7，但rocminfo却看不到 GPU，折腾了十分钟才发现是实例的 GPU 直通模式没开，重启也没用，最后是重新开了一台才解决。这个坑写在这里，希望你不用踩。
另外一个总被人忽视的命令是：
ls -l /dev/dri/renderD*ROCm 依赖/dev/dri下的 render 节点跟 GPU 通信，如果这个设备节点不存在，PyTorch 根本装不上，装上了也调用不了。云实例如果开了虚拟化遮蔽，这里经常是空的。看到renderD128之类的输出，才算过了第一关。
2.3 ROCm 版本身份确认：避免装完发现兼容性不对
AMD 的 ROCm 版本号机制和 CUDA 不太一样，ROCm 12.x 是主力版本，但 PyTorch 对 ROCm 的适配是分版本走的。你pip install torch的时候如果直接装默认的 CPU 版或者 CUDA 版，那 ROCm 就白装了。
最靠谱的做法是直接从 PyTorch 官方仓库装对应 ROCm 版本的包：
pip install torch torchvision --index-url https://download.pytorch.org/whl/rocm6.2前提是确认你的 ROCm 是 6.2 这个版本，可以用apt show rocm-core等方式查一下。不同 ROCm 大版本之间不能混用，强制混用会出现运行时报缺libamdhip64.so这种低级错误。简单来说，PyTorch 是前任房客，ROCm 是房东，两个人版本的约定没提前说好，住进去必然闹矛盾。
3. 三条部署路径实测：从自动化脚本到生产级服务的完整选择
部署方式我从简单到复杂捋了三套，实际也都跑了一遍：官方一键脚本、官方 TGI 容器、以及 vLLM 的 ROCm 分支。三套各有优劣，下面逐个说。
3.1 官方一键脚本：15 分钟部署的答案确实在这里
AMD 官方和 HuggingFace 合作，提供了一个专门针对 Gemma4 的部署脚本，位置在 AMDRadeonComputer 的 GitHub 仓库下（具体路径不时变动，建议搜gemma4-deployment-script）。这个脚本会自动检测 GPU 型号、安装依赖、拉取模型权重、最后启动一个推理服务。
我实际跑了一次，流程比我预想的顺。脚本执行过程中自动装了transformers、accelerate、bitsandbytes的 ROCm 适配版，并且用HSA_OVERRIDE_GFX_VERSION这个环境变量规避了消费级显卡在 ROCm 上的识别问题。说到这个环境变量，它是 AMD 解决“软件不认识新卡”问题的一把钥匙。比如当驱动版本比你卡的型号旧的时候，ROCm 会拒载，但你强制指定一个相近的架构版本，比如HSA_OVERRIDE_GFX_VERSION=9.0.0，它就能跑起来。代价是性能会有轻微折损，因为编译器不知道自己本质该用什么指令集，只能按照备用架构来编译。
不过这个脚本有个坑：它会从 HuggingFace Hub 下载模型，而如果你所在的网络环境访问 HF 不稳定，脚本会在下载阶段卡很久。我的建议是，如果你在这步卡了超过五分钟，先看看是不是网络问题，不要在加载权重那儿反复重试。
3.2 官方 TGI 容器：生产部署的正确打开方式
如果你想把这套东西做成能扛并发、有完整监控的服务，脚本方式不够，推荐直接用 HuggingFace TGI（Text Generation Inference）为 ROCm 构建的容器镜像。TGI 本身主要给 NVIDIA 优化，但 HuggingFace 官方也维护了 ROCm 版本的后端。
跑容器的命令大概是这样的：
docker run --rm --device=/dev/kfd --device=/dev/dri \ -e HSA_OVERRIDE_GFX_VERSION=9.0.0 \ -p 8080:80 \ ghcr.io/huggingface/text-generation-inference:latest-rocm \ --model-id google/gemma4-9b-it \ --max-input-tokens 2048 \ --max-total-tokens 4096注意开头那两个设备参数--device=/dev/kfd --device=/dev/dri，这哥俩是 ROCm 容器化的核心。忘了挂，容器里就完全看不到 GPU。这个命令拉的镜像是带rocm后缀的 tag，如果拉成默认的 NVIDIA 版本，TensorRT 会直接报错，或者程序干脆起不来。TGI 还支持持续批处理（continuous batching）和分页注意力（PagedAttention），同一卡上并发能力比裸跑 Transformers 好得多。
我实测下来，TGI 容器在 MI210 上跑 9B 版本的 Gemma4，批处理并发 16 个请求时，延迟仍保持在两位数毫秒量级，这个表现在生产环境里是完全可用的。
3.3 vLLM ROCm/Triton 路径：从--gpu-memory-utilization到权重量化的微调参数
除了 TGI，vLLM 也在社区推动下支持了 ROCm。安装方式是用官方提供的 Dockerfile 构建镜像，或者用pip install vllm-rocm这样的专用包。vLLM 在 ROCm 上默认启用 Triton 算子后端，这套东西跑 Gemma4 时对显存管理更精细，还能用 AWQ 量化格式减少显存占用。
启动命令长这样：
vllm serve google/gemma4-9b-it \ --quantization awq \ --gpu-memory-utilization 0.92 \ --max-num-seqs 32这里--gpu-memory-utilization 0.92的意思是让 vLLM 把 92% 的显存拿来做 KV Cache 和中间计算。留 8% 给推理框架本身和其他后台程序。之前我把这个值改成 0.98，结果并发一高就 OOM，进程直接被杀。不要贪，0.90 到 0.93 之间的值是最稳的。
vLLM 在 AMD 上跑还有一个独特优势：它的量化算子对 ROCm 的支持做得比较完整，AWQ 格式可以直接加载，不需要先转成 HF 的标准格式再跑。相比之下，TGI 的 ROCm 版对 AWQ 的支持还不太稳定，加载的时候偶尔会报算子上的错。
3.4 Ollama 作为本地验证的兜底路径
如果你只是想快速验证 Gemma4 能不能在 AMD 卡上跑，而不是做完整部署，Ollama 是最快的路径。它对 ROCm 的支持已经内置，几行命令就完事：
curl -fsSL https://ollama.com/install.sh | sh ollama run gemma4:9bOllama 会自动检测你的 ROCm 驱动并调用对应后端。但它有个天然缺点：作为推理服务，它不支持 PagedAttention 这类高级显存管理，并发能力弱，只适合本地模型验证或低并发场景。而且它对模型格式（GGUF）有依赖，Gemma4 官方的 GGUF 权重通常托管在社区账号下，拉取的时候注意核对哈希值。
我自己的判断是：验证选 Ollama，服务选 TGI，深度定制选 vLLM。这句话基本可以当结论记。
4. 实战踩坑实录：从环境变量到显存碎片崩溃的完整排查链路
4.1TORCH_BLAS_PREFER_HIPBLASLT与“假动作”算子
第一个坑来自环境变量TORCH_BLAS_PREFER_HIPBLASLT。看到这个名字你可能就明白了，它是让 PyTorch 的 BLAS 运算优先使用 HIP 的hipBLASLt库。这是一个针对 AMD EPYC + Instinct 平台做过矩阵运算级优化的底层库，理论上是好东西。但我跑 Gemma4 的生成过程时，开启这个变量后反而让每 token 的生成速度从 16 tokens/s 掉到了 11 tokens/s。
原因不复杂：hipBLASLt 只对特定尺寸的矩阵做了优化，Gemma4 在 2B 尺度上的矩阵形状比较“怪”，没落在优化区间里，于是走的反而是通用路径，性能反而不如默认的 rocBLAS。排查链路是这样的：先用export TORCH_BLAS_PREFER_HIPBLASLT=1把环境变量打开，跑一次基准；再unset掉，跑一次。对比数据之后关闭这个变量。
这类问题在 ROCm 上调优时特别常见，因为 AMD 生态里没有像 NVIDIA 那样成熟的autotune机制，优化路线经常是“默认路径平均好，但特定场景要手动关掉某条优化”。遇到性能不符合预期时，不要直接怀疑硬件，先把环境变量一个个过一遍。
4.2 显存碎片引发的进程崩溃：从日志到解决的完整链条
第二个坑是我这次调试里最头疼的。TGI 容器运行了大约二十分钟后，服务突然无响应，容器日志里反复出现HSA_STATUS_ERROR_OUT_OF_RESOURCES，翻译成人话就是“显存不够了”。但我用rocm-smi --showmeminfo vram查看时，显存占用量才 60% 左右，明明还有将近 20GB 空闲。
这就是典型的显存碎片化问题：某些算子申请大块连续显存，虽然总量够，但可用碎片无法满足。ROCm 的内存分配策略和 CUDA 不完全一样，碎片整理没有后者那么激进。排查思路是检查输出序列长度的分布——我那次并发请求里有几个超长生成的请求，它们在生成过程中逐渐抢占 KV Cache，把显存切成了很多不连续的小块，之后一个新请求需要申请大块连续内存时就失败了。
解决办法有三层。第一，设置--max-total-tokens，限制最长输出，避免单个请求无限膨胀；第二，改用 looping policy 的机制，比如 vLLM 的--size-based-eviction-policy，在内存压力大时踢掉不活跃会话；第三，实在不行就重启容器，但配合第一和第二层之后，我后面连续跑了几小时都没再出现这个崩溃。
写到这里真心建议：如果你要用 TGI 或 vLLM 跑长服务，压力测试不要只测短文本，显存碎片化不是测试的时候能看出来的，而是在服务持续运行一段时间后才会冒出来。
4.3 网络拉取慢：一个几乎影响所有人的阻塞点
还有一个不大不小的问题，基本人人都会碰到：拉取模型权重时，受网络环境影响，我这边从 HF Hub 下载 Gemma4 的权重，速率只有 2MB/s 左右。9B 模型 fp16 权重接近 18GB，按这个速度要等一个多小时，15 分钟部署直接变成笑话。
解决办法是把模型先放在对象存储里或者用镜像仓库预置。我在云实例上把权重放到本地 NVMe 之后，再启动镜像时直接挂载本地目录，完全不走外部网络。实际操作里就是给脚本传一个环境变量，比如HF_HOME=/local/model，或者用--model-id /local/model/gemma4-9b这种指向本地目录的参数。如果你所在环境的网络状况同样堪忧，强烈建议提前准备好这一步，不然其他环节再顺也白搭。
5. 实测结果与建议：不同场景该无脑选哪条路
5.1 三类部署路径在同一硬件上的对比
列一个我自己实测的对比表格，环境是 AMD Instinct MI210 单卡（64GB HBM2e），模型统一用 Gemma4 9B 指令版：
| 部署方式 | 启动耗时 | 首 token 延迟 | 吞吐（并发 8） | 显存管理 | 生产可用度 |
|---|---|---|---|---|---|
| Ollama | 2 分钟 | 350ms | 中等，约 60 tokens/s | 无高级管理 | 本地验证 |
| AMD 官方脚本 | 10 分钟 | 280ms | 中等 | 简单 | 快速演示 |
| TGI 容器 | 8 分钟（拉镜像） | 220ms | 高，约 180 tokens/s | PagedAttention | 推荐生产 |
| vLLM ROCm | 15 分钟（含构建） | 180ms | 最高，约 210 tokens/s | PagedAttention + AWQ | 推荐深度定制 |
吞吐数据受硬件和并发环境影响，不同镜像之间的差异会很大，但总体排序是有参考价值的：Ollama 胜在“拿到就能用”，TGI 胜在容器化一体化，vLLM 胜在极致性能和量化支持。
5.2 我个人的实操体会与后续扩展建议
说说走完这一圈之后的真实感受。AMD ROCm 现在已经不是“能不能跑”的问题，而是“怎么选路径”的问题。NVIDIA 生态的好处是路径极其单一，几乎所有人的指路牌都指向同一套工具，而 AMD 则给了你更多组合选择，但也意味着你必须自己花时间做判断。
第一次接触 AMD 卡的同学，如果问我最值得记的一条经验，我会说是：遇到奇怪错误先看版本对齐，再看环境变量，最后才怀疑硬件。ROCm 的报错信息算是友好的，但前提是你知道它说的 ABC 对应什么。HSA_OVERRIDE_GFX_VERSION和--device=/dev/kfd --device=/dev/dri这两个，分别搞定软件层和容器层，90% 的部署问题都逃不出这两个范围。
后续如果你进一步折腾，方向可以是：AMDX 固件路径上做多卡张量并行（Gemma4 几十 B 的版本多卡部署时，TP 切分地址读取的坑更多），还有就是在量化上下功夫，AWQ 与 GPTQ 在 ROCm 上的算子行为差异也挺明显。反正这一套跑顺了，后面再部署别的模型，大部分经验都是可以平移的。
还是那句话：15 分钟部署不是神话，但它属于准备充分的人。
