拓冰网站定制 
15分钟部署Gemma说实话我一开始是不信的——直到我把AMD ROCm云实例彻底折腾了一遍先说结论15分钟部署Gemma系列模型是真的但这15分钟里藏着不少前置条件。我是Datawhale社区的老成员这次看到和AMD联合搞的ROCm云实例体验活动第一反应是“又来一个写PPT的联合项目”结果手痒领了一台实例从零开始配环境、拉模型、跑推理全程掐表还真在15分钟内让Gemma模型跑起来了。这篇不是软文我把整个过程的每一步、每个坑、每个参数的来龙去脉都记录下来。不管你手里有没有AMD的卡这篇都值得看完——因为ROCm生态的成熟度可能和你印象里的完全不一样。我这次用的环境是AMD官方提供的ROCm云实例系统是Ubuntu 22.04显卡为AMD Instinct系列加速卡预装了ROCm 6.x驱动栈。由于是云端实例省去了本地装驱动的痛苦这对第一次接触ROCm的人来说是个好消息但对想了解底层细节的人来说反而要自己多挖几层。这篇就从0开始完整复盘整个过程。1. 整体设计与思路拆解1.1 为什么选ROCm而不是CUDA很多人一提到GPU推理脑子里全是NVIDIA那套CUDA、cuDNN、TensorRT。AMD的ROCm听得少总感觉是“能用但不好用”的备胎。这次实测下来的体验是——ROCm在推理场景的成熟度已经到“开箱即用”的级别了尤其是针对HuggingFace生态的模型。ROCm全称Radeon Open Compute是AMD开源的通用计算平台。它对标的就是CUDA但走的路线不太一样ROCm在PyTorch、TensorFlow这些框架层面做了大量适配所以你在NVIDIA卡上怎么写代码在AMD卡上基本可以原样跑。关键差异在底层——CUDA只支持NVIDIA硬件ROCm支持AMD自家的Instinct系列、Radeon系列甚至还有一部分CDNA架构的加速卡。我这次选ROCm而不是CUDA原因很朴素我就是想验证一下非NVIDIA生态现在到底能不能顺滑地跑主流大模型。如果有时间你甚至可以做一个对照实验同一台实例用ROCm跑一次再用CPU跑一次对比推理速度和显存占用。实测下来ROCm的GPU加速效果比CPU快一个数量级这点后面会贴具体数据。1.2 整个部署流程的顶层设计拿到实例后我画了一张部署流程图心里想的没真画拆解成四个阶段环境检测确认ROCm驱动、PyTorch的ROCm版本、显存大小。模型获取从HuggingFace拉取Gemma模型权重这里考验的是网络和模型来源。推理验证写一个简单的推理脚本跑通文本生成。性能摸底用真实的推理请求压一下看看吞吐量、显存占用和时延。这四步看着简单实际操作中有两个隐形大头PyTorch的ROCm版本兼容性和模型的显存占用。后者尤其关键——Gemma系列虽然“轻量”但部署前你得精确计算一下显存够不够别等加载到一半崩了才后悔。1.3 为什么Gemma值得部署Gemma是Google开源的大语言模型系列相比同体量的其他开源模型它有几个特点结构紧凑、部署门槛低、中文能力让人惊喜。最让我惊讶的是Gemma-2B这种小模型居然在中文问答上比很多7B模型还稳这在大模型圈里不常见。而且Gemma的授权协议对商用友好社区生态也起来了HuggingFace上可以直接拉取权重配合Transformers库推理代码手写不超过20行。注意一点标题里的“Gemma4”在官方仓库里其实不存在社区口口相传的版本命名有些混乱我这次实际用的是Gemma系列的2B和7B版本它们在实用性和资源消耗上最均衡。如果你在别的教程里看到Gemma4这种叫法多半指的是Gemma系列的最新版别在权重文件名上死磕认准GGUF或PyTorch格式就行。2. 核心细节解析与实操要点2.1 ROCm环境检测的全套姿势登录实例后我做的第一件事不是急着装东西而是把环境底细摸清楚。以下几个方面必须确认缺一个后面都可能出幺蛾子。第一步确认驱动是否正常加载。rocm-smi这条命令会输出GPU的型号、温度、显存使用率、风扇转速等信息。如果这里直接报错说明ROCm驱动栈没装好后续一切免谈。我这次实例预装的ROCm版本是6.4显示一切正常。第二步检查ROCm的运行时版本。cat /opt/rocm/.info/versionROCm的版本直接影响PyTorch的选型。比如ROCm 6.x对应PyTorch 2.3的rocm6.x版本版本差太多会直接装不上。第三步确认PyTorch是否能调用GPU。python -c import torch; print(torch.__version__); print(torch.cuda.is_available()); print(torch.version.hip)这里有一个很多新手会踩的坑ROCm生态下PyTorch依然用torch.cuda.is_available()来判断GPU可用性因为AMD在软件层面做了CUDA兼容层底层调用的是HIPHeterogeneous Interface for Portability。所以看到cuda.is_available()返回True别惊讶这说明ROCm环境正常。torch.version.hip会显示HIP的版本号比如6.4这是确认PyTorch确实跑在ROCm上的关键证据。第四步强烈推荐装个系统监控工具盯GPU状态。watch -n 1 rocm-smi部署过程中显存和功耗波动剧烈开着这个窗口能实时看到状态排查问题时非常有用。我每次部署模型都开两个终端一个跑命令一个盯监控这个习惯帮我省了无数排查时间。2.2 PyTorch ROCm版本的安装要点AMD的云实例预装环境一般比较干净但PyTorch还是得自己装。这里有个关键的版本对齐问题pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.4注意rocm6.4这个后缀要和/opt/rocm/.info/version里显示的版本一致。如果ROCm是6.3就把URL换成rocm6.3否则会出现算子不兼容的问题——症状通常是某些模型能跑某些模型一加载就报错非常难排查。装完后做一次冒烟测试用一个小张量在GPU上跑一下矩阵乘法验证整个链路是通的import torch x torch.randn(1000, 1000, devicecuda) y torch.mm(x, x) print(y.sum().item())如果这个能输出一个数字说明GPU计算链路完全OK。这一步别跳过后面模型加载慢、推理报错回过来查这步最简单。2.3 Gemma模型选型的铁律Gemma系列目前有2B、7B等不同参数规模还有一个关键指标叫上下文长度官方默认是8192个token比很多同体量模型长不少这意味着它能处理的文本更长。但上下文越长显存占用越高部署前必须算清楚。我这里给一个简单的估算公式模型权重占用 ≈ 参数量 × 精度字节数2B模型用FP16大约占4GB显存7B模型用FP16大约占14GB显存推理时的KV Cache额外占2~4GB取决于上下文长度和batch size所以如果你的实例显存是16GB跑7B模型几乎到极限了最好用4-bit量化把显存占用砍到4GB左右如果只有8GB显存老老实实用2B模型或者走量化路线。这个公式不精确但用来做容量规划非常实用能避免部署到一半OOM内存溢出。2.4 动手部署前的避坑清单在开始正式部署前有几个坑我必须先说出来免得你走我走过的弯路HuggingFace下载超时这是中国区用户最常见的坑。模型权重文件动辄几个GB直连经常断。我这次用镜像站hf-mirror.com速度稳定在10MB/s以上具体做法看下一节的实操部分。注意这只改变下载源不改变任何代码逻辑非常安全。权限问题实例的默认用户未必有写/opt/rocm等系统目录的权限所有操作尽量在用户目录下建虚拟环境别动系统级Python。显存占用估算偏差上面那个公式只是保底方案真实显存占用还受模型加载策略影响。比如HuggingFace默认会把权重加载到CPU再迁移到GPU这个过程会短暂占用翻倍的内存。端口占用如果后面要起API服务记得先检查端口是否被占用。ss -tlnp看一下别等到服务起不来才查。3. 实操过程与核心环节实现3.1 五分钟搭建完整环境老规矩先建虚拟环境杜绝系统依赖污染python3 -m venv ~/gemma-env source ~/gemma-env/bin/activate接着装依赖这一步建议一次性装完别一个包一个包装解决依赖冲突的效率会高很多pip install --upgrade pip pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.4 pip install transformers huggingface_hub accelerate装完确认版本python -c import torch; print(PyTorch:, torch.__version__, ROCm:, torch.version.hip)我这次实测的输出是PyTorch: 2.8.0rocm6.4说明PyTorch和ROCm 6.4对齐成功。注意装完这些包之后建议顺手把accelerate升级到最新版否则加载大模型时可能会触发旧版的设备映射bug。3.2 拉取Gemma模型权重的完整过程这里不卖关子直接把模型下载过程讲透。默认情况下huggingface_hub会从HuggingFace官网拉文件国内网络环境下大概率会失败或龟速我用的是hf-mirror.com镜像。设置方式很简单import os os.environ[HF_ENDPOINT] https://hf-mirror.com或者在命令行里export HF_ENDPOINThttps://hf-mirror.com然后就可以直接用HuggingFace的API拉取模型了。如果你用的是中文社区或阿里云的模型托管服务也可以在HuggingFace官网搜索对应仓库名拉到下载链接后手动下载权重文件。关键点在于下载的权重格式要和Transformers库兼容一般认准PyTorch格式或GGUF格式就行。以Gemma 2B为例拉取命令如下from huggingface_hub import snapshot_download model_dir snapshot_download( repo_idgoogle/gemma-2b, local_dir./gemma-2b, ignore_patterns[*.safetensors] ) print(模型已下载到:, model_dir)注意我这里加了一个ignore_patterns这只是示例实际部署时千万不要加这个参数否则会跳过核心权重文件。snapshot_download默认会把整个仓库的文件都拉下来包括配置文件、分词器、权重等。权重文件的格式一般是.bin或.safetensors后者是更安全的加载格式推荐优先选它。实际下载时2B模型大概5GB7B模型大概15GB。我的网络环境下2B模型大约花了5分钟所以“15分钟部署”的时间大头其实都在下载这一步。如果缺失依赖包启动时会自动下载并作缓存这也是时间开销的一个隐藏来源。3.3 编写第一个推理脚本模型文件到位后推理脚本非常简单。因为Gemma的模型结构和Llama类似Transformers库直接支持不需要任何额外算子。这是我用的脚本from transformers import AutoTokenizer, AutoModelForCausalLM import torch model_path ./gemma-2b tokenizer AutoTokenizer.from_pretrained(model_path) model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypetorch.float16, device_mapcuda, attn_implementationeager ) prompt 请用三句话解释什么是ROCm inputs tokenizer(prompt, return_tensorspt).to(cuda) outputs model.generate( **inputs, max_new_tokens256, temperature0.7, top_p0.9, do_sampleTrue ) result tokenizer.decode(outputs[0], skip_special_tokensTrue) print(result)几个参数的选择理由torch_dtypetorch.float16半精度推理显存减半速度提升。AMD的CDNA架构对FP16的支持很好。device_mapcuda把模型直接放到GPU显存。如果你的显存不够可以改成device_mapauto让accelerate库自动分配模型层到CPU或GPU但这会牺牲速度。attn_implementationeager显式指定注意力实现避免Transformers库自动选择SDPA时在ROCm上出现不兼容。这个参数是我排错之后加上的后面细说。第一次执行时上面这个脚本会在加载模型时自动下载缺失的配置文件。如果网络不稳定建议提前用snapshot_download一次性把整个仓库拉全能省掉很多烦躁。3.4 把推理封装成服务一条脚本跑通只是第一步实际使用场景下还得把它变成服务。用FastAPI包一层HTTP接口是社区最常用的方案。下面是核心代码结构from fastapi import FastAPI, Request from pydantic import BaseModel app FastAPI() class GenRequest(BaseModel): prompt: str max_tokens: int 256 temperature: float 0.7 app.post(/generate) async def generate(req: GenRequest): inputs tokenizer(req.prompt, return_tensorspt).to(cuda) outputs model.generate( **inputs, max_new_tokensreq.max_tokens, temperaturereq.temperature, do_sampleTrue ) result tokenizer.decode(outputs[0], skip_special_tokensTrue) return {response: result}启动方式uvicorn api:app --host 0.0.0.0 --port 8000这就把模型包成了一个API服务调用方只需要发POST请求不用关心底层是ROCm还是CUDA。API服务模式下有个小技巧预热。正式上线前先用一个短请求调用一次让模型完成显存初始化和算子编译否则第一个生产请求会非常慢容易被误判为服务挂掉。3.5 性能测试与实测数据部署完不能光能跑我得拿数据说话。用一段固定文本反复请求100次记录时延和吞吐量。实测在AMD Instinct系列加速卡32GB显存上部署7B模型结果如下指标Gemma 2B (FP16)Gemma 7B (FP16)模型加载时间约20秒约55秒单次推理时延256 tokens约1.8秒约4.2秒峰值显存占用约5.2GB约16.8GB吞吐量约140 tokens/s约60 tokens/s首token延迟约340ms约720ms这个数据说明什么2B模型完全可以在8GB显存的消费级显卡上跑7B则建议至少16GB显存。如果显存紧张GGUF量化版能砍掉一大半显存占用但速度会略有下降。我建议内存和显存都预留20%-30%的余量别卡着上限跑否则换一批更长的输入就OOM了。3.6 AMD平台特有环境变量与性能加速ROCm平台上还有几个环境变量值得关注它们能直接影响性能上限export HSA_OVERRIDE_GFX_VERSION10.3.0这个变量一般不推荐乱设只在某些老显卡跑新算子报错时才需要。更实用的是这两个export HIP_VISIBLE_DEVICES0 export PYTORCH_HIP_ALLOC_CONFmax_split_size_mb:128HIP_VISIBLE_DEVICES指定进程可见的GPU编号多卡环境下必用PYTORCH_HIP_ALLOC_CONF调节PyTorch显存分配策略遇到显存碎片化时可以适当调小max_split_size_mb释放更多可用的连续显存块。4. 常见问题与排查技巧实录4.1 显存不足OOM的通用解法部署过程中最容易遇到的就是CUDA out of memory。注意在ROCm上这个报错信息依然写着CUDA跟之前讲到的一样这是兼容层在起作用别被误导。解法优先级如下降低精度FP16改成8-bit量化或4-bit量化用bitsandbytes库显存瞬间减半甚至砍到四分之一。缩短上下文长度把生成参数max_new_tokens调低减少KV Cache的显存占用。开启device_mapauto让模型层分散到CPU和GPU虽然慢但至少能跑。清理缓存进程结束后把Python终端关掉重开显存会完全释放不要在一个进程里反复加载多份模型这会让显存碎片化严重。4.2 模型输出乱码或重复内容这个问题的原因通常是温度参数太极端或采样策略不对。temperature过高会让输出天马行空过低会让模型陷入重复循环。我的经验值通用对话用0.7~0.8代码生成用0.2~0.3创意写作不要超过0.9。另外top_p一般配合temperature使用固定0.9左右比较稳。4.3 推理速度慢得离谱怎么办如果发现模型加载成功但推理极慢可以先检查NVIDIA对应的rocm-smi显卡利用率rocm-smi --showuse如果GPU利用率只有10%不到多半是算子回退到了CPU实现。解决方案升级Transformers到最新版本老版本对ROCm的算子支持不完整。显式指定attn_implementationflash_attention_2前提是你装了flash-attn的ROCm版本。这个库在AMD卡上的安装不是开箱即用的需要从源码编译耗时较长非必要不折腾。先在短时间内跑一个长一点的生成任务比如512个token让ROCm完成算子预热和缓存后续请求速度会稳定下来。这种首请求慢的现象在ROCm上比NVIDIA更明显因为驱动和框架层的自动调优需要一点时间。4.4 驱动与PyTorch版本不兼容的经典迷局前面强调过torch.version.hip要和/opt/rocm/.info/version一致。如果出现类似DataLoader worker (pid 1234) exited unexpectedly的诡异报错先回这一步确认版本。版本错配的典型症状是加载模型正常一到前向传播就报算子错误错误信息指向某个.cpp文件看着像代码bug其实是算子库不匹配。4.5 问题排查速查表现象可能原因解决手段rocm-smi无输出驱动未加载重启实例确认显卡被系统识别PyTorch检测不到GPUPyTorch装错版本确认安装的是rocm后缀版本模型加载到一半OOM显存不足换更小的模型或开启量化推理第一个请求特别慢ROCm算子预热先发一个短请求预热 AMD ROCm云实例15分钟部署Gemma全流程拆解
15分钟部署Gemma说实话我一开始是不信的——直到我把AMD ROCm云实例彻底折腾了一遍先说结论15分钟部署Gemma系列模型是真的但这15分钟里藏着不少前置条件。我是Datawhale社区的老成员这次看到和AMD联合搞的ROCm云实例体验活动第一反应是“又来一个写PPT的联合项目”结果手痒领了一台实例从零开始配环境、拉模型、跑推理全程掐表还真在15分钟内让Gemma模型跑起来了。这篇不是软文我把整个过程的每一步、每个坑、每个参数的来龙去脉都记录下来。不管你手里有没有AMD的卡这篇都值得看完——因为ROCm生态的成熟度可能和你印象里的完全不一样。我这次用的环境是AMD官方提供的ROCm云实例系统是Ubuntu 22.04显卡为AMD Instinct系列加速卡预装了ROCm 6.x驱动栈。由于是云端实例省去了本地装驱动的痛苦这对第一次接触ROCm的人来说是个好消息但对想了解底层细节的人来说反而要自己多挖几层。这篇就从0开始完整复盘整个过程。1. 整体设计与思路拆解1.1 为什么选ROCm而不是CUDA很多人一提到GPU推理脑子里全是NVIDIA那套CUDA、cuDNN、TensorRT。AMD的ROCm听得少总感觉是“能用但不好用”的备胎。这次实测下来的体验是——ROCm在推理场景的成熟度已经到“开箱即用”的级别了尤其是针对HuggingFace生态的模型。ROCm全称Radeon Open Compute是AMD开源的通用计算平台。它对标的就是CUDA但走的路线不太一样ROCm在PyTorch、TensorFlow这些框架层面做了大量适配所以你在NVIDIA卡上怎么写代码在AMD卡上基本可以原样跑。关键差异在底层——CUDA只支持NVIDIA硬件ROCm支持AMD自家的Instinct系列、Radeon系列甚至还有一部分CDNA架构的加速卡。我这次选ROCm而不是CUDA原因很朴素我就是想验证一下非NVIDIA生态现在到底能不能顺滑地跑主流大模型。如果有时间你甚至可以做一个对照实验同一台实例用ROCm跑一次再用CPU跑一次对比推理速度和显存占用。实测下来ROCm的GPU加速效果比CPU快一个数量级这点后面会贴具体数据。1.2 整个部署流程的顶层设计拿到实例后我画了一张部署流程图心里想的没真画拆解成四个阶段环境检测确认ROCm驱动、PyTorch的ROCm版本、显存大小。模型获取从HuggingFace拉取Gemma模型权重这里考验的是网络和模型来源。推理验证写一个简单的推理脚本跑通文本生成。性能摸底用真实的推理请求压一下看看吞吐量、显存占用和时延。这四步看着简单实际操作中有两个隐形大头PyTorch的ROCm版本兼容性和模型的显存占用。后者尤其关键——Gemma系列虽然“轻量”但部署前你得精确计算一下显存够不够别等加载到一半崩了才后悔。1.3 为什么Gemma值得部署Gemma是Google开源的大语言模型系列相比同体量的其他开源模型它有几个特点结构紧凑、部署门槛低、中文能力让人惊喜。最让我惊讶的是Gemma-2B这种小模型居然在中文问答上比很多7B模型还稳这在大模型圈里不常见。而且Gemma的授权协议对商用友好社区生态也起来了HuggingFace上可以直接拉取权重配合Transformers库推理代码手写不超过20行。注意一点标题里的“Gemma4”在官方仓库里其实不存在社区口口相传的版本命名有些混乱我这次实际用的是Gemma系列的2B和7B版本它们在实用性和资源消耗上最均衡。如果你在别的教程里看到Gemma4这种叫法多半指的是Gemma系列的最新版别在权重文件名上死磕认准GGUF或PyTorch格式就行。2. 核心细节解析与实操要点2.1 ROCm环境检测的全套姿势登录实例后我做的第一件事不是急着装东西而是把环境底细摸清楚。以下几个方面必须确认缺一个后面都可能出幺蛾子。第一步确认驱动是否正常加载。rocm-smi这条命令会输出GPU的型号、温度、显存使用率、风扇转速等信息。如果这里直接报错说明ROCm驱动栈没装好后续一切免谈。我这次实例预装的ROCm版本是6.4显示一切正常。第二步检查ROCm的运行时版本。cat /opt/rocm/.info/versionROCm的版本直接影响PyTorch的选型。比如ROCm 6.x对应PyTorch 2.3的rocm6.x版本版本差太多会直接装不上。第三步确认PyTorch是否能调用GPU。python -c import torch; print(torch.__version__); print(torch.cuda.is_available()); print(torch.version.hip)这里有一个很多新手会踩的坑ROCm生态下PyTorch依然用torch.cuda.is_available()来判断GPU可用性因为AMD在软件层面做了CUDA兼容层底层调用的是HIPHeterogeneous Interface for Portability。所以看到cuda.is_available()返回True别惊讶这说明ROCm环境正常。torch.version.hip会显示HIP的版本号比如6.4这是确认PyTorch确实跑在ROCm上的关键证据。第四步强烈推荐装个系统监控工具盯GPU状态。watch -n 1 rocm-smi部署过程中显存和功耗波动剧烈开着这个窗口能实时看到状态排查问题时非常有用。我每次部署模型都开两个终端一个跑命令一个盯监控这个习惯帮我省了无数排查时间。2.2 PyTorch ROCm版本的安装要点AMD的云实例预装环境一般比较干净但PyTorch还是得自己装。这里有个关键的版本对齐问题pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.4注意rocm6.4这个后缀要和/opt/rocm/.info/version里显示的版本一致。如果ROCm是6.3就把URL换成rocm6.3否则会出现算子不兼容的问题——症状通常是某些模型能跑某些模型一加载就报错非常难排查。装完后做一次冒烟测试用一个小张量在GPU上跑一下矩阵乘法验证整个链路是通的import torch x torch.randn(1000, 1000, devicecuda) y torch.mm(x, x) print(y.sum().item())如果这个能输出一个数字说明GPU计算链路完全OK。这一步别跳过后面模型加载慢、推理报错回过来查这步最简单。2.3 Gemma模型选型的铁律Gemma系列目前有2B、7B等不同参数规模还有一个关键指标叫上下文长度官方默认是8192个token比很多同体量模型长不少这意味着它能处理的文本更长。但上下文越长显存占用越高部署前必须算清楚。我这里给一个简单的估算公式模型权重占用 ≈ 参数量 × 精度字节数2B模型用FP16大约占4GB显存7B模型用FP16大约占14GB显存推理时的KV Cache额外占2~4GB取决于上下文长度和batch size所以如果你的实例显存是16GB跑7B模型几乎到极限了最好用4-bit量化把显存占用砍到4GB左右如果只有8GB显存老老实实用2B模型或者走量化路线。这个公式不精确但用来做容量规划非常实用能避免部署到一半OOM内存溢出。2.4 动手部署前的避坑清单在开始正式部署前有几个坑我必须先说出来免得你走我走过的弯路HuggingFace下载超时这是中国区用户最常见的坑。模型权重文件动辄几个GB直连经常断。我这次用镜像站hf-mirror.com速度稳定在10MB/s以上具体做法看下一节的实操部分。注意这只改变下载源不改变任何代码逻辑非常安全。权限问题实例的默认用户未必有写/opt/rocm等系统目录的权限所有操作尽量在用户目录下建虚拟环境别动系统级Python。显存占用估算偏差上面那个公式只是保底方案真实显存占用还受模型加载策略影响。比如HuggingFace默认会把权重加载到CPU再迁移到GPU这个过程会短暂占用翻倍的内存。端口占用如果后面要起API服务记得先检查端口是否被占用。ss -tlnp看一下别等到服务起不来才查。3. 实操过程与核心环节实现3.1 五分钟搭建完整环境老规矩先建虚拟环境杜绝系统依赖污染python3 -m venv ~/gemma-env source ~/gemma-env/bin/activate接着装依赖这一步建议一次性装完别一个包一个包装解决依赖冲突的效率会高很多pip install --upgrade pip pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.4 pip install transformers huggingface_hub accelerate装完确认版本python -c import torch; print(PyTorch:, torch.__version__, ROCm:, torch.version.hip)我这次实测的输出是PyTorch: 2.8.0rocm6.4说明PyTorch和ROCm 6.4对齐成功。注意装完这些包之后建议顺手把accelerate升级到最新版否则加载大模型时可能会触发旧版的设备映射bug。3.2 拉取Gemma模型权重的完整过程这里不卖关子直接把模型下载过程讲透。默认情况下huggingface_hub会从HuggingFace官网拉文件国内网络环境下大概率会失败或龟速我用的是hf-mirror.com镜像。设置方式很简单import os os.environ[HF_ENDPOINT] https://hf-mirror.com或者在命令行里export HF_ENDPOINThttps://hf-mirror.com然后就可以直接用HuggingFace的API拉取模型了。如果你用的是中文社区或阿里云的模型托管服务也可以在HuggingFace官网搜索对应仓库名拉到下载链接后手动下载权重文件。关键点在于下载的权重格式要和Transformers库兼容一般认准PyTorch格式或GGUF格式就行。以Gemma 2B为例拉取命令如下from huggingface_hub import snapshot_download model_dir snapshot_download( repo_idgoogle/gemma-2b, local_dir./gemma-2b, ignore_patterns[*.safetensors] ) print(模型已下载到:, model_dir)注意我这里加了一个ignore_patterns这只是示例实际部署时千万不要加这个参数否则会跳过核心权重文件。snapshot_download默认会把整个仓库的文件都拉下来包括配置文件、分词器、权重等。权重文件的格式一般是.bin或.safetensors后者是更安全的加载格式推荐优先选它。实际下载时2B模型大概5GB7B模型大概15GB。我的网络环境下2B模型大约花了5分钟所以“15分钟部署”的时间大头其实都在下载这一步。如果缺失依赖包启动时会自动下载并作缓存这也是时间开销的一个隐藏来源。3.3 编写第一个推理脚本模型文件到位后推理脚本非常简单。因为Gemma的模型结构和Llama类似Transformers库直接支持不需要任何额外算子。这是我用的脚本from transformers import AutoTokenizer, AutoModelForCausalLM import torch model_path ./gemma-2b tokenizer AutoTokenizer.from_pretrained(model_path) model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypetorch.float16, device_mapcuda, attn_implementationeager ) prompt 请用三句话解释什么是ROCm inputs tokenizer(prompt, return_tensorspt).to(cuda) outputs model.generate( **inputs, max_new_tokens256, temperature0.7, top_p0.9, do_sampleTrue ) result tokenizer.decode(outputs[0], skip_special_tokensTrue) print(result)几个参数的选择理由torch_dtypetorch.float16半精度推理显存减半速度提升。AMD的CDNA架构对FP16的支持很好。device_mapcuda把模型直接放到GPU显存。如果你的显存不够可以改成device_mapauto让accelerate库自动分配模型层到CPU或GPU但这会牺牲速度。attn_implementationeager显式指定注意力实现避免Transformers库自动选择SDPA时在ROCm上出现不兼容。这个参数是我排错之后加上的后面细说。第一次执行时上面这个脚本会在加载模型时自动下载缺失的配置文件。如果网络不稳定建议提前用snapshot_download一次性把整个仓库拉全能省掉很多烦躁。3.4 把推理封装成服务一条脚本跑通只是第一步实际使用场景下还得把它变成服务。用FastAPI包一层HTTP接口是社区最常用的方案。下面是核心代码结构from fastapi import FastAPI, Request from pydantic import BaseModel app FastAPI() class GenRequest(BaseModel): prompt: str max_tokens: int 256 temperature: float 0.7 app.post(/generate) async def generate(req: GenRequest): inputs tokenizer(req.prompt, return_tensorspt).to(cuda) outputs model.generate( **inputs, max_new_tokensreq.max_tokens, temperaturereq.temperature, do_sampleTrue ) result tokenizer.decode(outputs[0], skip_special_tokensTrue) return {response: result}启动方式uvicorn api:app --host 0.0.0.0 --port 8000这就把模型包成了一个API服务调用方只需要发POST请求不用关心底层是ROCm还是CUDA。API服务模式下有个小技巧预热。正式上线前先用一个短请求调用一次让模型完成显存初始化和算子编译否则第一个生产请求会非常慢容易被误判为服务挂掉。3.5 性能测试与实测数据部署完不能光能跑我得拿数据说话。用一段固定文本反复请求100次记录时延和吞吐量。实测在AMD Instinct系列加速卡32GB显存上部署7B模型结果如下指标Gemma 2B (FP16)Gemma 7B (FP16)模型加载时间约20秒约55秒单次推理时延256 tokens约1.8秒约4.2秒峰值显存占用约5.2GB约16.8GB吞吐量约140 tokens/s约60 tokens/s首token延迟约340ms约720ms这个数据说明什么2B模型完全可以在8GB显存的消费级显卡上跑7B则建议至少16GB显存。如果显存紧张GGUF量化版能砍掉一大半显存占用但速度会略有下降。我建议内存和显存都预留20%-30%的余量别卡着上限跑否则换一批更长的输入就OOM了。3.6 AMD平台特有环境变量与性能加速ROCm平台上还有几个环境变量值得关注它们能直接影响性能上限export HSA_OVERRIDE_GFX_VERSION10.3.0这个变量一般不推荐乱设只在某些老显卡跑新算子报错时才需要。更实用的是这两个export HIP_VISIBLE_DEVICES0 export PYTORCH_HIP_ALLOC_CONFmax_split_size_mb:128HIP_VISIBLE_DEVICES指定进程可见的GPU编号多卡环境下必用PYTORCH_HIP_ALLOC_CONF调节PyTorch显存分配策略遇到显存碎片化时可以适当调小max_split_size_mb释放更多可用的连续显存块。4. 常见问题与排查技巧实录4.1 显存不足OOM的通用解法部署过程中最容易遇到的就是CUDA out of memory。注意在ROCm上这个报错信息依然写着CUDA跟之前讲到的一样这是兼容层在起作用别被误导。解法优先级如下降低精度FP16改成8-bit量化或4-bit量化用bitsandbytes库显存瞬间减半甚至砍到四分之一。缩短上下文长度把生成参数max_new_tokens调低减少KV Cache的显存占用。开启device_mapauto让模型层分散到CPU和GPU虽然慢但至少能跑。清理缓存进程结束后把Python终端关掉重开显存会完全释放不要在一个进程里反复加载多份模型这会让显存碎片化严重。4.2 模型输出乱码或重复内容这个问题的原因通常是温度参数太极端或采样策略不对。temperature过高会让输出天马行空过低会让模型陷入重复循环。我的经验值通用对话用0.7~0.8代码生成用0.2~0.3创意写作不要超过0.9。另外top_p一般配合temperature使用固定0.9左右比较稳。4.3 推理速度慢得离谱怎么办如果发现模型加载成功但推理极慢可以先检查NVIDIA对应的rocm-smi显卡利用率rocm-smi --showuse如果GPU利用率只有10%不到多半是算子回退到了CPU实现。解决方案升级Transformers到最新版本老版本对ROCm的算子支持不完整。显式指定attn_implementationflash_attention_2前提是你装了flash-attn的ROCm版本。这个库在AMD卡上的安装不是开箱即用的需要从源码编译耗时较长非必要不折腾。先在短时间内跑一个长一点的生成任务比如512个token让ROCm完成算子预热和缓存后续请求速度会稳定下来。这种首请求慢的现象在ROCm上比NVIDIA更明显因为驱动和框架层的自动调优需要一点时间。4.4 驱动与PyTorch版本不兼容的经典迷局前面强调过torch.version.hip要和/opt/rocm/.info/version一致。如果出现类似DataLoader worker (pid 1234) exited unexpectedly的诡异报错先回这一步确认版本。版本错配的典型症状是加载模型正常一到前向传播就报算子错误错误信息指向某个.cpp文件看着像代码bug其实是算子库不匹配。4.5 问题排查速查表现象可能原因解决手段rocm-smi无输出驱动未加载重启实例确认显卡被系统识别PyTorch检测不到GPUPyTorch装错版本确认安装的是rocm后缀版本模型加载到一半OOM显存不足换更小的模型或开启量化推理第一个请求特别慢ROCm算子预热先发一个短请求预热