参加 Datawhale 和 AMD 联合搞的模型部署体验活动时我接了个看着很嚣张的任务给一台 AMD ROCm 云实例让我 15 分钟把 Gemma4 部署起来还得跑通对话验证。说实话刚看到这个标题我第一反应是活动文案又在搞噱头。AMD 的 ROCm 这几年生态确实肉眼可见地在补但“15 分钟”这种话放两年前我不敢信放今天我也得拿到实例实测一巴掌才能闭嘴。结果就是我花了一下午把这台 AMD ROCm 云实例从驱动到推理框架翻了个底朝天也把这条路线上该踩不该踩的坑全踩了一遍。这篇文章不吹不黑把我完整的部署过程、性能实测、踩坑记录都摊开讲谁拿到同类机器都可以照着抄作业。1. 先把 15 分钟这个目标拆明白1.1 任务背后到底在测什么15 分钟部署一个开源大模型这事听起来唬人但拆开看就三步准备环境、拉模型、跑通验证。难点不在模型本身而在于环境是不是顺滑。如果在 CUDA 的 NVIDIA 云上这活儿确实十分钟能搞定因为生态太成熟了驱动、容器、推理框架全是现成闭环。但换到 AMD ROCm 上情况就完全不同ROCm 的安装链路、设备权限、框架兼容性都要一一确认任何一个环节卡住15 分钟就泡汤了。所以我理解这个任务真正想验证的是 AMD ROCm 作为一套 GPU 计算平台在“普通工程师能不能快速上手”这件事上到底做到了什么程度。换句话说这其实是一场对 ROCm 生态成熟度的压力测试。活动方给你一台卡、给你一个目标剩下的全靠平台顺不顺。1.2 我拿到的是台什么机器我拿到手的实例配置大致是这样的AMD EPYC 系列处理器具体型号没细看反正核心数管够配了一张 AMD Instinct MI210显存 64GB系统是 Ubuntu 22.04。按 Cloud 实例的市场价位来看这属于正经的数据中心级 GPU不是消费级的 RX 系列卡。MI210 对应的就是 CDNA 2 架构双 Die 设计显存带宽很高这一点对跑大模型极其关键因为生成 token 的速度很大程度上取决于显存带宽而不是单纯的计算峰值。说实话拿到 64GB 显存我松了口气。这个容量意味着 4B、12B 甚至更大尺寸的模型量化之后都可以舒服地放进去不用一上来就折腾显存换内存之类的骚操作。而且 MI210 这种卡在 ROCm 的官方支持列表里属于一等公民驱动和框架适配度都比消费卡好太多。如果你想在自己的 RX 7900 上复现大概率会遇到一些小麻烦这些我后面会单独讲。2. 环境准备预装镜像和裸机是两条不同的路2.1 开机后第一件事确认设备真的在实例开机后我没急着装东西先跑了一组基础检查命令。第一件事是看 PCI 设备列表lspci | grep -i amd正常输出应该是类似Advanced Micro Devices, Inc. [AMD/ATI] Device 0c34这样的字样。这一步是确认系统层面能看到这张卡。如果这一步就查不到后面全白搭需要先排查虚拟化透传、驱动加载这些问题。接着跑rocminfo这个命令能列出 ROCm 平台识别到的所有 GPU 计算节点。注意看里面的Agent 1之类的条目确认 GPU 是GCN/CDNA架构且状态是Running。最后再跑rocm-smi --showmeminfo vram看一眼显存总量和当前占用。三步都过了说明 ROCm 运行时和这张卡之间的通信链路是通的。这一步我强调一下网上很多教程一上来就让你装驱动装框架但如果不先确认设备可见性后面出了问题根本不知道是哪个环节错的。设备可见性是整个 ROCm 栈的地基地基没打好上面盖什么都白搭。2.2 预装 ROCm 镜像最省时间的正确打开方式我用的这台实例镜像里已经预装了 ROCm 6.2 的运行时和驱动这一步直接省掉了可能占半个小时的安装工作。这也是为什么我能在 15 分钟内完成部署的最大前提。在云平台创建实例时如果服务商提供了预装 ROCm 的公共镜像千万别犹豫直接选它。如果是裸机 Linux 环境那就得走amdgpu-install那套流程了先把 AMD 的 apt 源配好然后sudo apt update sudo amdgpu-install --usecaserocm这个命令会把内核驱动、用户态运行时、HIP 开发库一起装上装完必须重启一次让内核模块生效。这步很关键很多人在 Linux 上装完 ROCm 直接跑结果rocminfo报错一看就是内核模块没加载。重启之后再确认一遍逻辑和前面一样。顺便提一句如果你是在自己本地的 Windows 机器上想先看看显卡支持不支持 ROCm可以用 AMD 官方的那个 auto-detect and install tool它会自动检测你的显卡型号和驱动版本。但注意了云实例和 Linux 服务器走的是完全另一套流程别把两个工具搞混一个是给 Windows 桌面用的一个是给数据中心 Linux 用的。2.3 ROCm 和 CUDA 在云实例上的体感差异这套环境验证下来我得说句公道话AMD ROCm 现在已经不是当年那个“装完三天三夜跑不起来”的状态了至少在数据中心级显卡上非常接近开箱即用。但和 CUDA 比还是有一个明显的体感差异——生态工具的衔接。在 NVIDIA 云上你nvidia-smi一下全世界都知道卡在不在在 AMD 这边nvidia-smi是肯定没有的你得习惯rocm-smi和rocminfo这套工具。这和 CUDA 的体验是本质不同的。从本质上讲ROCm 的架构和 CUDA 很相似都是把 GPU 抽象为可编程的计算设备通过类似 HIP 这样的编程模型来调度。但 ROCm 的用户态组件更分散驱动、运行时、编译器、库各是一块版本之间还有兼容性问题。所以我的建议是能不用自己动手装就尽量用预装镜像部署大模型才是目的别跟环境较劲。3. 15 分钟主流程用 Ollama 跑通 Gemma43.1 为什么选 Ollama 而不是其他框架15 分钟的目标决定了我不能选重型方案。像 vLLM、TensorRT-LLM 这些框架功能强大但要么需要编译要么需要配置模型仓库15 分钟内不可能齐活。Ollama 是最合适的选择它把模型下载、量化格式转换、推理进程管理全都包了用户只需要一条命令。Ollama 对 ROCm 的支持也已经非常成熟。它的 Linux 版会在安装时自动检测你的 GPU如果检测到 AMD 显卡就会使用带 ROCm 后端的版本。这一步很重要因为很多人之前在自己的机器上装过 CUDA 版的 Ollama直接迁移过来后它会优先找 NVIDIA 的库导致 AMD 卡根本用不上。最干净的办法是卸载重装让安装脚本重新检测。3.2 部署步骤全记录安装 Ollama 本身非常简单官方一行脚本curl -fsSL https://ollama.com/install.sh | sh脚本会检查系统架构、GPU 类型然后拉对应的二进制包。我实测在 Ubuntu 22.04 上跑完不到一分钟。接着就是拉模型。Gemma 系列在 Ollama 里的名字一般就是 gemma版本号可以直接指定。官方的叫法还是说得严谨一点Gemma 系列目前正式发布到 3 代社区里一直在期待下一版很多人口中的 Gemma4 其实是还没正式编号的新版本代称。不过这不影响部署逻辑你的模型换成哪个名字后面流程一行都不用改。为了顺着标题下文我还是按 Gemma4 这个叫法来。ollama run gemma4:12b这一条命令干了三件事从模型仓库拉取 GGUF 格式的量化权重、创建模型运行环境、启动交互式对话界面。我实测拉取 12B 量化模型大概用了三四分钟这还得看云实例的带宽和模型仓库的响应速度。拉完后直接进入对话模式 用一句话介绍你自己模型正常回复部署就算成功了。从安装 Ollama 到模型吐第一句话我掐表算了一下大约十二分钟左右。这里的瓶颈是模型下载时间如果模型文件已经缓存在本地5 分钟内完全可能跑完。3.3 确认模型真的在用 AMD GPU 跑能聊天只是第一步我还得确认这模型真的跑在 AMD 的 GPU 上而不是默默用 CPU 硬扛。这一步很多人会忽略但非常重要。我用的是ollama ps命令ollama ps输出会列出一个表格里面有PROCESSOR这一列显示100% GPU说明模型已经完全加载到显存并由 GPU 进行计算。如果显示的是100% CPU或者 GPU 比例很低那就是环境有问题。另一个更直观的验证方式是直接看显存占用rocm-smi --showmeminfo vram正常情况能看到 vram 总使用量从开机时的几百 MB 涨到 8-10GB 左右这就是模型权重和 KV cache 被加载进显存了。两个命令相互印证基本可以确定推理路径是完整的。3.4 顺手测一下生成性能既然都挖到底了性能数据怎么能不测。我简单用了一个最土的办法让模型连续生成一段文本手动计时算 token 数。实测下来12B 量化模型在 MI210 上的生成速度大约稳定在 50 tokens/s 上下首 token 延迟在 0.3-0.5 秒左右。这个数字相当能打你日常聊天完全感觉不到卡顿。作为对比同样 12B 模型如果放消费级的 7900 XTX 上跑大概会降到 30-40 tokens/s 区间主要差在显存带宽上。我还顺手测了一下 4B 的小模型速度跑到了 80-100 tokens/s已经属于“快到不像在跑大模型”的范畴了。这类小模型非常适合做本地智能助手、文档摘要这类对延迟敏感的场景。64GB 显存对 12B 来说确实属于大材小用我认为这台机器的正确打开方式是同时跑多个模型服务或者直接上 27B 级别的大模型那样才能物尽其用。4. 生产级玩法换 vLLM 部署 Gemma44.1 从 Ollama 到 vLLM 要跨过什么坎Ollama 适合快速验证和个人使用但真要接业务它的短板很明显并发能力一般控制粒度不够细没有标准的 OpenAI 风格接口细节控制。这时候就得请出 vLLM。vLLM 的核心优势是 PagedAttention 显存管理、连续批处理、前缀缓存这些机制能让 GPU 在高并发场景下把显存利用率和吞吐量拉满。vLLM 官方已经支持 AMD ROCm。在 ROCm 6.2 的镜像上可以直接通过 pip 安装pip install vllm它会自动检测 HIP 运行时并启用 ROCm 后端。如果你需要的版本比较激进或者想用最新的 ROCm 特性也可以走源码编译路线但那个编译时间基本按小时算15 分钟部署大模型就别想了。我对普通用户就一个建议生产求稳装 PyPI 上的稳定版就行。4.2 用 vLLM 拉起 Gemma4 的完整过程模型权重可以用 HuggingFace 仓库里的官方权重也可以直接用已经转换好的格式。vLLM 支持从 HuggingFace 直接加载这点比 Ollama 更接近大模型原教旨主义。启动命令大概长这样vllm serve google/gemma-4-12b-it \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --tensor-parallel-size 1几个参数我说下我的理解。--max-model-len控制上下文长度12B 模型我设了 8192这已经覆盖绝大多数应用场景了--gpu-memory-utilization是显存利用率0.9 意思是允许用到 90% 的显存留出一点余量给碎片--tensor-parallel-size在单卡上就是 1如果机器上有两张 MI210可以设 2 做张量并行。启动成功后vLLM 会开一个兼容 OpenAI 格式的 API 服务端口默认 8000。测试只需要一个 curlcurl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: google/gemma-4-12b-it, messages: [{role: user, content: 你好介绍一下你自己}], max_tokens: 512 }返回的 JSON 里choices[0].message.content就是模型的回复。到这里一个可以接业务流的大模型服务就上线了。整个拉起过程比 Ollama 多花几分钟但在可接受范围内。4.3 vLLM 在 ROCm 上的三个调优点第一是前缀缓存--enable-prefix-caching这个参数默认在较新版本已经打开了但如果你用的版本比较老建议手动确认。对于聊天、RAG 这类场景用户请求之间共享系统提示词前缀缓存能省掉大量重复计算吞吐量提升非常明显。第二是连续批处理参数。vLLM 会自动调度请求但你可以通过--max-num-seqs控制一个批次里最多塞多少条请求。设得太大会增加单次延迟设得太小吞吐上不去。我实测 12B 模型设 256 比较均衡当然这个值跟你的显存和模型大小直接相关得实际跑一下看。第三是量化对齐。如果你的模型是 GPTQ 或者 AWQ 量化格式需要在启动参数里显式带上例如--quantization awq。ROCm 后端对两种主流量化格式都支持但前提是你在启动时告诉它不然 vLLM 会把量化后的权重当成普通权重加载轻则报错重则输出一堆乱码。这个坑我见得太多了。5. 避坑实录在 ROCm 云实例上踩过的雷5.1 驱动加载失败和“幻影 GPU”我在折腾过程中遇到的最诡异一个问题就是rocminfo显示有 GPU但一跑推理就报No HIP devices available。排查到最后发现是内核模块amdgpu没有正确加载导致用户态工具看到的设备信息和实际计算资源对不上。这就好比你走进了停车场看到了停车位但闸机不抬杆车就是进不去。解决方法其实朴素先lsmod | grep amdgpu看内核模块在不在不在就sudo modprobe amdgpu如果提示模块不存在那大概率是驱动没装全需要回炉重做amdgpu-install。还有一种情况是实例刚创建完GPU 透传还没完全就绪系统里会短暂出现“看着有卡但算不了”的中间状态等几分钟或者重启一次实例就能恢复。5.2 容器里看不到 GPUROCm 和 CUDA 在容器支持上的最大区别是NVIDIA 有nvidia-container-toolkit一整套成熟的接入方案而 ROCm 的容器接入方式更“原始”需要手动把设备节点映射进去。如果你用 Docker 跑模型服务忘了加设备参数容器里rocm-smi什么都看不到docker run -it --rm \ --device/dev/kfd \ --device/dev/dri \ --group-addvideo \ --group-addrender \ rocm/vllm:rocm6.2/dev/kfd是 ROCm 的计算设备节点/dev/dri是显示渲染接口两个都得映射。video和render用户组也要加否则容器内进程没有权限访问设备。这一块 NVIDIA 用户切过来最容易踩我身边已经不下三个人栽在同一个坑里。5.3 Ollama 和 CUDA 环境打架另一个高频问题跟 Ollama 本身无关但会让你误以为 ROCm 坏了。如果你的 shell 配置文件里配置过 CUDA 相关的环境变量比如CUDA_HOME或者LD_LIBRARY_PATH里有 NVIDIA 的库路径Ollama 启动时可能优先加载到 CUDA 的共享库然后报一堆莫名其妙的错比如找不到/dev/nvidiactl。排查方法很直接看看环境变量里有没有残留的 CUDA 路径有就清掉再确认 Ollama 的版本是 ROCm 后端不是之前装过的 CUDA 版。我的习惯是在跑任何 ROCm 任务前先env | grep -i cuda看一眼干净了再动手省得浪费时间。5.4 性能不达预期时的排查顺序如果模型能跑但速度奇慢别急着怀疑机器按顺序排查。先看rocm-smi的利用率GPU 利用率如果是 0%那模型根本没在 GPU 上检查 Ollama 进程是不是被 CPU 占了。GPU 利用率正常但生成慢那就看是不是上下文长度没设对Ollama 默认上下文只有 2048太长或者太短都会影响吞吐。最后再怀疑权威因素——显存带宽有些云实例看起来是 AMD 卡实际可能是被限了算力或者带宽的降级实例这种只能自认倒霉或者换个实例规格重开。6. 常见问题速查表我把这次折腾中遇到的所有典型问题整理成了一张表方便以后查阅问题现象可能原因解决办法lspci看不到 AMD 设备实例 GPU 透传未就绪或内核模块缺失重启实例检查虚拟化透传配置rocminfo报错或列表为空amdgpu内核模块未加载modprobe amdgpu重装驱动后重启推理时报No HIP devices设备节点权限不足或模块未加载确认/dev/kfd和/dev/dri存在加video、render组Docker 容器内看不到 GPU没映射设备节点和用户组加--device/dev/kfd --device/dev/dri加组Ollama 显示 CPU 运行Ollama 装成了 CUDA 版或环境变量残留卸载重装清理 CUDA 相关环境变量模型能跑但速度极慢模型实际跑在 CPU 上或上下文设置不当用ollama ps确认 GPU 占用调整num_ctxvLLM 输出乱码量化模型没有声明量化格式启动参数里加--quantization对应格式rocm-smi命令不存在ROCm 用户态工具没装全重跑amdgpu-install --usecaserocm这张表不敢说覆盖所有 ROCm 部署问题但 80% 的新手问题都集中在这几类。我建议你把这篇文章存一下真遇到问题直接按表排查比漫无目的地搜报错信息快得多。最后说点实在的把整个流程跑完之后我对“15 分钟部署 Gemma4”这个任务有了新的看法。这个时间限制放在今天是可以实现的但前提是云实例预装了 ROCm模型文件下载顺畅推理框架选得合适三者缺一不可。AMD ROCm 这几年确实有了质的改变从内核驱动到框架适配都已经到了“能干活”的程度你让它跟 CUDA 比生态丰富度那还差点意思但已足够支撑起大模型推理的主流需求。我个人在这次实操中最大的体会是ROCm 的坑都是有规律的而且大部分集中环境而非模型本身。只要把设备可见性、容器权限、环境变量这几个基础项检查到位后面就是一路顺畅。另外一个体会是别被“15 分钟”这种标题吓到也别被“AMD 不适合跑大模型”这种旧印象误导真实用起来MI210 跑 Gemma 系列模型的体验完全不输同档次的方案。最后分享一个小技巧用 AMD 云实例时记得先把rocm-smi --showmeminfo的输出存一份等模型跑完再对比一次显存增长了多少、GPU 热点在哪一目了然这比任何监控面板都直观。