1. 为什么我盯上了 AMD ROCm 这套组合1.1 从一张显卡的闲置说起手里有一张 AMD 的显卡平时跑跑本地推理总觉得差点意思。不是性能不够而是生态上的那种“别扭”——你想装个 vLLM官方文档翻半天发现默认路径全是另一家生态的。这种体验相信不少折腾过 AMD 推理的人都懂。后来看到 Datawhale 和 AMD 联合搞了个活动主题是“15 分钟部署 Gemma4”用的就是 ROCm 云实例。我第一反应是15 分钟真的假的因为我自己在本地折腾 ROCm 环境的时候光驱动和依赖就搞了大半天。但转念一想云实例的好处就是环境是预置好的省去了最痛苦的那一段。于是我决定把整个流程从头到尾走一遍顺便把 ROCm 这套东西的底细摸清楚。这篇文章不是官方文档的复述而是我自己踩完坑之后整理出来的实操记录。我会讲清楚 ROCm 到底是什么、vLLM 在 AMD 上怎么跑、云实例部署的完整流程、以及那些文档里不会写的坑。如果你手里有 AMD 的卡或者想试试 ROCm 做推理这篇应该能帮你省不少时间。1.2 ROCm 到底是个什么东西很多人第一次听到 ROCm 会懵不知道它跟日常说的“显卡驱动”有什么区别。我用一个类比来解释如果把 AMD 显卡比作一台发动机那驱动就是让发动机能转起来的基础油路而 ROCm 是让这台发动机能跑各种高级任务比如 AI 推理、科学计算的整套控制系统。ROCm 的全称是 Radeon Open Compute platform是 AMD 面向 GPU 计算的开源软件栈。它包含几个核心部分运行时和编译器负责把上层框架的指令翻译成 GPU 能执行的代码数学库比如 rocBLAS、rocFFT对应的是矩阵运算、傅里叶变换这些底层计算通信库RCCL多卡并行的时候靠它做卡间通信框架适配层让 PyTorch、TensorFlow 这些框架能调用 AMD 的 GPU跟另一套生态相比ROCm 最大的特点是开源。这意味着你可以看到底层实现也可以自己改。但代价是生态成熟度还在追赶中有些库的版本兼容性需要格外注意。提示ROCm 对操作系统和内核版本有明确要求不是所有 Linux 发行版都能直接装。云实例的好处就是这些底层依赖已经配好了你不需要自己去折腾内核模块。1.3 vLLM 在 AMD 上的定位vLLM 是目前最流行的大模型推理框架之一核心卖点是 PagedAttention 和连续批处理能把显存利用率和吞吐量拉到一个很高的水平。它原生支持 CUDA但对 ROCm 的支持也在逐步完善。在 AMD 的卡上跑 vLLM本质上就是把 vLLM 的算子实现从 CUDA 后端切换到 ROCm 后端。这个过程在 vLLM 的代码里已经做了适配你不需要自己去写 kernel但需要在安装的时候选择正确的版本和编译选项。我实测下来vLLM 在 ROCm 上的表现已经相当可用了。单卡推理的吞吐量能达到同级别另一套生态卡的七八成考虑到价格因素这个性价比是很有吸引力的。而且 vLLM 的 OpenAI 兼容接口在 ROCm 上完全一致你之前写的调用代码基本不用改。2. 云实例选型与环境确认2.1 为什么选云实例而不是本地先说结论如果你只是想快速验证一个模型能不能跑、效果怎么样云实例是最高效的选择。原因有三点。第一环境预置。ROCm 的安装在不同发行版上差异很大光是内核版本、固件版本、驱动版本的匹配就能耗掉半天。云实例把这些都做好了你开机就能用。第二硬件门槛。ROCm 对显卡型号有要求不是所有 AMD 卡都支持。云实例提供的都是官方验证过的型号省去了兼容性排查。第三成本可控。按小时计费跑完就释放对于实验性质的部署来说比买卡划算得多。当然如果你有长期推理需求本地部署在成本上会更优。但那是另一个话题了这里先聚焦在云实例的快速验证流程上。2.2 实例规格怎么选选实例的时候主要看三个参数显卡型号、显存大小、CPU 和内存配比。Gemma4 这个级别的模型如果做 FP16 推理显存占用大概在模型参数量的两倍左右。举个例子一个 7B 参数的模型FP16 需要约 14GB 显存加上 KV Cache 和框架本身的开销建议预留 20GB 以上。如果是量化版本显存需求会大幅下降。我这次用的实例配置是单卡、大显存、CPU 和内存配比均衡的规格。具体选哪个档位取决于你要跑的模型大小和并发量。如果是做实验选最低配能跑起来就行如果要压测吞吐就得往上加。模型规模FP16 显存需求量化后显存需求建议实例档位2B 以下6-8GB3-4GB入门级7B 左右16-20GB6-8GB中档13B 左右28-32GB10-14GB中高档30B 以上64GB20-30GB高档或多卡注意上表的显存需求是估算值实际占用还跟 batch size、序列长度、KV Cache 策略有关。建议先用小模型验证流程再换大模型。2.3 开机后的第一件事确认 ROCm 状态实例起来之后别急着装东西先确认 ROCm 环境是否正常。这一步很多人会跳过结果后面报错了才回头查浪费更多时间。打开终端依次执行以下命令# 查看 ROCm 版本 rocminfo | head -20 # 查看 GPU 信息 rocm-smi # 确认 vLLM 是否已预装 pip show vllmrocminfo会输出 GPU 的型号、计算单元数量、内存大小等信息。如果这个命令报错或者输出为空说明 ROCm 运行时有问题需要先解决。rocm-smi是 AMD 的显卡监控工具类似另一套生态里的监控命令。它会显示显卡的温度、功耗、显存占用、利用率等。跑推理的时候可以开着这个窗口实时观察。如果pip show vllm显示已安装记下版本号。vLLM 的 ROCm 支持在不同版本间差异较大后面如果需要重装要选对版本。3. 部署 Gemma4 的完整实操流程3.1 模型下载与格式确认Gemma4 是 Google 发布的开放模型系列有多个尺寸。在云实例上部署第一步是把模型权重下载到本地或者挂载的存储上。下载方式有几种直接从模型仓库拉取、用 huggingface-cli 下载、或者从对象存储挂载。我推荐用 huggingface-cli因为它支持断点续传大模型下载中途断了不用重来。# 安装 huggingface 命令行工具 pip install huggingface_hub # 下载模型以 Gemma4 某个尺寸为例 huggingface-cli download google/gemma-4-7b-it --local-dir ./gemma4-7b下载之前确认两件事一是模型是否需要申请访问权限有些模型需要先在页面上同意协议二是磁盘空间是否够一个 7B 的 FP16 模型大约 14GB加上 tokenizer 和其他文件预留 20GB 比较稳妥。下载完成后检查目录结构。标准的模型目录应该包含config.json模型配置model.safetensors或分片的权重文件tokenizer.json和tokenizer_config.jsongeneration_config.json如果缺少某个文件vLLM 加载时会报错。特别是config.json里的architectures字段vLLM 靠它来判断用哪个模型实现。3.2 vLLM 启动参数详解这是整个流程的核心。vLLM 的启动命令看起来简单但参数选不对要么跑不起来要么性能很差。先给一个我实测可用的启动命令python -m vllm.entrypoints.openai.api_server \ --model ./gemma4-7b \ --dtype float16 \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 4096 \ --port 8000 \ --host 0.0.0.0逐个解释这些参数--model指定模型路径可以是本地目录也可以是模型仓库的 ID。--dtype指定计算精度。FP16 是默认值也是 ROCm 上支持最好的精度。BF16 在某些卡上也可以但需要确认硬件支持。--tensor-parallel-size是张量并行度单卡就设 1多卡就设卡数。这个参数决定了模型怎么切分到多张卡上。--gpu-memory-utilization是显存利用率上限默认 0.9。意思是 vLLM 会尝试占用 90% 的显存来做 KV Cache。如果你的卡上还有其他任务可以调低这个值。--max-model-len是最大序列长度。这个值直接影响 KV Cache 的显存占用。设得越大能处理的上下文越长但显存消耗也越大。4096 是一个比较安全的起点。--port和--host是服务监听地址。设成0.0.0.0可以让外部访问如果只在实例内部调用用默认的127.0.0.1就行。提示启动命令里的--dtype如果设成autovLLM 会根据模型配置自动选择。但在 ROCm 上我建议显式指定float16避免自动选择到不支持的精度。3.3 启动过程中的日志解读启动 vLLM 的时候终端会刷出一大堆日志。很多人看到日志就头大其实关键信息就那么几行。启动成功的标志是看到类似这样的输出INFO: Started server process [12345] INFO: Waiting for application startup. INFO: Application startup complete. INFO: Uvicorn running on http://0.0.0.0:8000在这之前会有一段模型加载的日志显示加载了多少个权重文件、占用了多少显存、KV Cache 分配了多少块。这些信息对调优很有用。如果启动失败日志里会有明确的错误信息。常见的错误类型我整理在下面的表格里错误关键词可能原因排查方向HIP errorROCm 运行时问题检查 rocminfo 是否正常out of memory显存不足降低 gpu-memory-utilization 或 max-model-lenunsupported dtype精度不支持改用 float16model not found路径错误检查模型目录是否存在tokenizer errortokenizer 文件缺失确认 tokenizer.json 存在3.4 服务验证与接口调用服务起来之后先用 curl 验证一下curl http://localhost:8000/v1/models如果返回模型列表说明服务正常。然后测试推理接口curl http://localhost:8000/v1/completions \ -H Content-Type: application/json \ -d { model: ./gemma4-7b, prompt: 介绍一下你自己, max_tokens: 100, temperature: 0.7 }如果返回了生成的文本恭喜你部署成功了。整个过程如果顺利的话确实能在 15 分钟内完成——前提是模型已经下载好了。Python 调用的话直接用 OpenAI 的 SDK 就行from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keydummy # vLLM 不校验 key随便填 ) response client.chat.completions.create( model./gemma4-7b, messages[ {role: user, content: 用一句话解释什么是 ROCm} ], max_tokens200 ) print(response.choices[0].message.content)注意api_key这里随便填一个非空字符串就行vLLM 默认不做鉴权。如果要对公网暴露记得在前面加一层反向代理做认证。4. 性能调优与常见坑4.1 吞吐量上不去的几个原因服务跑起来之后下一步就是看性能。我实测下来影响吞吐量的因素主要有这几个KV Cache 分配不足。--gpu-memory-utilization设得太保守KV Cache 块数不够请求一多就开始排队。可以适当调高但别超过 0.95留一点给系统。max-model-len 设得过大。这个值直接决定每个请求最多占多少 KV Cache。如果实际请求的上下文都很短设成 8192 甚至 16384 就是浪费。按实际需求设比如 4096 或 2048。batch size 限制。vLLM 默认会尽可能多地批处理请求但如果显存不够它会自动降低并发。观察日志里的running和pending数量如果 pending 一直很高说明并发被限制了。CPU 瓶颈。tokenizer 的处理是在 CPU 上做的如果 CPU 核心数太少tokenize 会成为瓶颈。云实例选型的时候注意 CPU 和 GPU 的配比。4.2 ROCm 特有的注意事项在 AMD 上跑 vLLM有几个坑是 ROCm 特有的跟另一套生态不一样。环境变量。ROCm 依赖一些环境变量来定位库文件。如果手动编译过 vLLM可能需要设置HIP_VISIBLE_DEVICES来指定用哪张卡。云实例一般已经配好了但如果你自己装记得检查。版本匹配。ROCm 版本、PyTorch 版本、vLLM 版本三者之间有严格的对应关系。比如某个 vLLM 版本要求 PyTorch 2.3 以上而 PyTorch 2.3 又要求 ROCm 6.0 以上。装之前先查兼容性矩阵别盲目 pip install。编译时间。如果从源码编译 vLLM 的 ROCm 版本编译过程可能长达半小时到一小时。云实例如果预装了 vLLM就跳过这一步。如果没有预装建议直接用官方提供的 wheel 包别自己编译。显存碎片。ROCm 的显存管理在某些版本上不如另一套生态成熟长时间运行后可能出现碎片。如果发现显存占用越来越高但吞吐量下降可以重启服务。注意ROCm 的rocm-smi显示的显存占用和 vLLM 日志里的数字可能有差异这是正常的。以 vLLM 日志为准因为它统计的是实际分配给 KV Cache 的部分。4.3 常见问题速查我把部署过程中遇到的问题整理成了一张速查表方便你快速定位现象可能原因解决方法启动时报 HIP errorROCm 运行时异常重启实例或检查 rocminfo模型加载到一半卡住磁盘 IO 慢或权重文件损坏检查磁盘重新下载模型推理结果乱码tokenizer 不匹配确认 tokenizer 文件与模型对应服务无响应显存耗尽被 OOM kill降低并发或显存利用率吞吐量远低于预期KV Cache 不足或 CPU 瓶颈调参并观察日志多卡并行报错RCCL 通信问题检查卡间互联和 RCCL 版本4.4 我踩过的三个坑第一个坑是模型路径用了相对路径启动服务的时候工作目录不对导致找不到模型。后来改成绝对路径就没事了。这个坑很蠢但确实容易犯。第二个坑是--gpu-memory-utilization设成了 0.95结果跑了一段时间后系统开始杀进程。原因是 ROCm 本身也要占一部分显存留的余量不够。后来改成 0.85 就稳定了。第三个坑是没注意 vLLM 版本和 ROCm 版本的对应关系装了一个不兼容的组合启动直接报错。后来查了兼容性矩阵换成匹配的版本才跑通。这三个坑的共同点是文档里不会写但实际部署时大概率会遇到。所以我的建议是第一次部署的时候把日志级别调到 debug多看日志遇到问题先查日志再动手改。5. 这套方案还能怎么扩展5.1 多模型共存与切换一台实例上跑一个模型有点浪费。vLLM 支持在同一进程中加载多个模型吗答案是不直接支持但可以通过启动多个服务实例来实现每个实例监听不同端口。比如一个实例跑 Gemma4另一个跑一个代码模型分别监听 8000 和 8001。然后在前面加一个路由层根据请求内容分发到不同的后端。这样一套硬件就能支撑多种任务。不过要注意显存分配。两个模型同时加载显存要够。如果显存紧张可以用 vLLM 的--swap-space参数把部分 KV Cache 换到内存里但会牺牲一些速度。5.2 量化版本的尝试如果显存不够或者想跑更大的模型量化是必经之路。ROCm 上支持的量化格式主要有 GPTQ 和 AWQ。vLLM 对这两种格式都有支持但需要模型本身是量化过的版本。量化的好处是显存占用大幅下降7B 的模型量化后可能只需要 6-8GB 显存。代价是精度会有一定损失具体损失多少取决于量化方法和校准数据。我试过一个 4bit 量化的模型推理速度比 FP16 快了不少生成质量在日常对话场景下几乎看不出差异。但如果你的任务对精度要求很高比如代码生成或数学推理建议还是用 FP16。5.3 从实验到生产的距离云实例上跑通只是第一步。如果要上生产还有几件事要做稳定性。实验环境可以随时重启生产环境不行。需要加进程守护服务挂了自动拉起。监控。要能实时看到 QPS、延迟、显存占用、GPU 利用率这些指标。ROCm 提供了rocm-smi的命令行接口可以写脚本采集。扩缩容。流量高峰和低谷的差距可能很大需要能动态调整实例数量。这就涉及到负载均衡和模型预热的问题。安全。vLLM 默认不鉴权对公网暴露必须加认证。最简单的做法是前面挂一个 Nginx做 Basic Auth 或者 Token 校验。这些话题每一个都能展开讲很多这里先点到为止。核心思路是实验阶段怎么快怎么来生产阶段怎么稳怎么来。5.4 关于成本的一点计算最后算一笔账。云实例按小时计费假设一小时几块钱跑一个实验性质的部署每天用两小时一个月下来也就几百块。相比买一张支持 ROCm 的显卡动辄几千上万云实例在验证阶段的经济性是很明显的。当然如果长期高频使用本地部署的边际成本更低。我的建议是先用云实例验证方案可行性确认要长期跑了再考虑本地硬件。这样既不会浪费钱也不会因为硬件问题卡住进度。ROCm 这套东西说实话成熟度还在爬坡阶段。但它的开源特性和性价比优势是实打实的。如果你愿意花点时间摸清楚它的脾气它能给你带来不一样的体验。我个人的体会是别把它当成另一套生态的替代品而是当成一个独立的、有自己特点的平台来对待心态会好很多上手也会快很多。
AMD ROCm 实战：15分钟云实例部署 Gemma4 与 vLLM 推理
1. 为什么我盯上了 AMD ROCm 这套组合1.1 从一张显卡的闲置说起手里有一张 AMD 的显卡平时跑跑本地推理总觉得差点意思。不是性能不够而是生态上的那种“别扭”——你想装个 vLLM官方文档翻半天发现默认路径全是另一家生态的。这种体验相信不少折腾过 AMD 推理的人都懂。后来看到 Datawhale 和 AMD 联合搞了个活动主题是“15 分钟部署 Gemma4”用的就是 ROCm 云实例。我第一反应是15 分钟真的假的因为我自己在本地折腾 ROCm 环境的时候光驱动和依赖就搞了大半天。但转念一想云实例的好处就是环境是预置好的省去了最痛苦的那一段。于是我决定把整个流程从头到尾走一遍顺便把 ROCm 这套东西的底细摸清楚。这篇文章不是官方文档的复述而是我自己踩完坑之后整理出来的实操记录。我会讲清楚 ROCm 到底是什么、vLLM 在 AMD 上怎么跑、云实例部署的完整流程、以及那些文档里不会写的坑。如果你手里有 AMD 的卡或者想试试 ROCm 做推理这篇应该能帮你省不少时间。1.2 ROCm 到底是个什么东西很多人第一次听到 ROCm 会懵不知道它跟日常说的“显卡驱动”有什么区别。我用一个类比来解释如果把 AMD 显卡比作一台发动机那驱动就是让发动机能转起来的基础油路而 ROCm 是让这台发动机能跑各种高级任务比如 AI 推理、科学计算的整套控制系统。ROCm 的全称是 Radeon Open Compute platform是 AMD 面向 GPU 计算的开源软件栈。它包含几个核心部分运行时和编译器负责把上层框架的指令翻译成 GPU 能执行的代码数学库比如 rocBLAS、rocFFT对应的是矩阵运算、傅里叶变换这些底层计算通信库RCCL多卡并行的时候靠它做卡间通信框架适配层让 PyTorch、TensorFlow 这些框架能调用 AMD 的 GPU跟另一套生态相比ROCm 最大的特点是开源。这意味着你可以看到底层实现也可以自己改。但代价是生态成熟度还在追赶中有些库的版本兼容性需要格外注意。提示ROCm 对操作系统和内核版本有明确要求不是所有 Linux 发行版都能直接装。云实例的好处就是这些底层依赖已经配好了你不需要自己去折腾内核模块。1.3 vLLM 在 AMD 上的定位vLLM 是目前最流行的大模型推理框架之一核心卖点是 PagedAttention 和连续批处理能把显存利用率和吞吐量拉到一个很高的水平。它原生支持 CUDA但对 ROCm 的支持也在逐步完善。在 AMD 的卡上跑 vLLM本质上就是把 vLLM 的算子实现从 CUDA 后端切换到 ROCm 后端。这个过程在 vLLM 的代码里已经做了适配你不需要自己去写 kernel但需要在安装的时候选择正确的版本和编译选项。我实测下来vLLM 在 ROCm 上的表现已经相当可用了。单卡推理的吞吐量能达到同级别另一套生态卡的七八成考虑到价格因素这个性价比是很有吸引力的。而且 vLLM 的 OpenAI 兼容接口在 ROCm 上完全一致你之前写的调用代码基本不用改。2. 云实例选型与环境确认2.1 为什么选云实例而不是本地先说结论如果你只是想快速验证一个模型能不能跑、效果怎么样云实例是最高效的选择。原因有三点。第一环境预置。ROCm 的安装在不同发行版上差异很大光是内核版本、固件版本、驱动版本的匹配就能耗掉半天。云实例把这些都做好了你开机就能用。第二硬件门槛。ROCm 对显卡型号有要求不是所有 AMD 卡都支持。云实例提供的都是官方验证过的型号省去了兼容性排查。第三成本可控。按小时计费跑完就释放对于实验性质的部署来说比买卡划算得多。当然如果你有长期推理需求本地部署在成本上会更优。但那是另一个话题了这里先聚焦在云实例的快速验证流程上。2.2 实例规格怎么选选实例的时候主要看三个参数显卡型号、显存大小、CPU 和内存配比。Gemma4 这个级别的模型如果做 FP16 推理显存占用大概在模型参数量的两倍左右。举个例子一个 7B 参数的模型FP16 需要约 14GB 显存加上 KV Cache 和框架本身的开销建议预留 20GB 以上。如果是量化版本显存需求会大幅下降。我这次用的实例配置是单卡、大显存、CPU 和内存配比均衡的规格。具体选哪个档位取决于你要跑的模型大小和并发量。如果是做实验选最低配能跑起来就行如果要压测吞吐就得往上加。模型规模FP16 显存需求量化后显存需求建议实例档位2B 以下6-8GB3-4GB入门级7B 左右16-20GB6-8GB中档13B 左右28-32GB10-14GB中高档30B 以上64GB20-30GB高档或多卡注意上表的显存需求是估算值实际占用还跟 batch size、序列长度、KV Cache 策略有关。建议先用小模型验证流程再换大模型。2.3 开机后的第一件事确认 ROCm 状态实例起来之后别急着装东西先确认 ROCm 环境是否正常。这一步很多人会跳过结果后面报错了才回头查浪费更多时间。打开终端依次执行以下命令# 查看 ROCm 版本 rocminfo | head -20 # 查看 GPU 信息 rocm-smi # 确认 vLLM 是否已预装 pip show vllmrocminfo会输出 GPU 的型号、计算单元数量、内存大小等信息。如果这个命令报错或者输出为空说明 ROCm 运行时有问题需要先解决。rocm-smi是 AMD 的显卡监控工具类似另一套生态里的监控命令。它会显示显卡的温度、功耗、显存占用、利用率等。跑推理的时候可以开着这个窗口实时观察。如果pip show vllm显示已安装记下版本号。vLLM 的 ROCm 支持在不同版本间差异较大后面如果需要重装要选对版本。3. 部署 Gemma4 的完整实操流程3.1 模型下载与格式确认Gemma4 是 Google 发布的开放模型系列有多个尺寸。在云实例上部署第一步是把模型权重下载到本地或者挂载的存储上。下载方式有几种直接从模型仓库拉取、用 huggingface-cli 下载、或者从对象存储挂载。我推荐用 huggingface-cli因为它支持断点续传大模型下载中途断了不用重来。# 安装 huggingface 命令行工具 pip install huggingface_hub # 下载模型以 Gemma4 某个尺寸为例 huggingface-cli download google/gemma-4-7b-it --local-dir ./gemma4-7b下载之前确认两件事一是模型是否需要申请访问权限有些模型需要先在页面上同意协议二是磁盘空间是否够一个 7B 的 FP16 模型大约 14GB加上 tokenizer 和其他文件预留 20GB 比较稳妥。下载完成后检查目录结构。标准的模型目录应该包含config.json模型配置model.safetensors或分片的权重文件tokenizer.json和tokenizer_config.jsongeneration_config.json如果缺少某个文件vLLM 加载时会报错。特别是config.json里的architectures字段vLLM 靠它来判断用哪个模型实现。3.2 vLLM 启动参数详解这是整个流程的核心。vLLM 的启动命令看起来简单但参数选不对要么跑不起来要么性能很差。先给一个我实测可用的启动命令python -m vllm.entrypoints.openai.api_server \ --model ./gemma4-7b \ --dtype float16 \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 4096 \ --port 8000 \ --host 0.0.0.0逐个解释这些参数--model指定模型路径可以是本地目录也可以是模型仓库的 ID。--dtype指定计算精度。FP16 是默认值也是 ROCm 上支持最好的精度。BF16 在某些卡上也可以但需要确认硬件支持。--tensor-parallel-size是张量并行度单卡就设 1多卡就设卡数。这个参数决定了模型怎么切分到多张卡上。--gpu-memory-utilization是显存利用率上限默认 0.9。意思是 vLLM 会尝试占用 90% 的显存来做 KV Cache。如果你的卡上还有其他任务可以调低这个值。--max-model-len是最大序列长度。这个值直接影响 KV Cache 的显存占用。设得越大能处理的上下文越长但显存消耗也越大。4096 是一个比较安全的起点。--port和--host是服务监听地址。设成0.0.0.0可以让外部访问如果只在实例内部调用用默认的127.0.0.1就行。提示启动命令里的--dtype如果设成autovLLM 会根据模型配置自动选择。但在 ROCm 上我建议显式指定float16避免自动选择到不支持的精度。3.3 启动过程中的日志解读启动 vLLM 的时候终端会刷出一大堆日志。很多人看到日志就头大其实关键信息就那么几行。启动成功的标志是看到类似这样的输出INFO: Started server process [12345] INFO: Waiting for application startup. INFO: Application startup complete. INFO: Uvicorn running on http://0.0.0.0:8000在这之前会有一段模型加载的日志显示加载了多少个权重文件、占用了多少显存、KV Cache 分配了多少块。这些信息对调优很有用。如果启动失败日志里会有明确的错误信息。常见的错误类型我整理在下面的表格里错误关键词可能原因排查方向HIP errorROCm 运行时问题检查 rocminfo 是否正常out of memory显存不足降低 gpu-memory-utilization 或 max-model-lenunsupported dtype精度不支持改用 float16model not found路径错误检查模型目录是否存在tokenizer errortokenizer 文件缺失确认 tokenizer.json 存在3.4 服务验证与接口调用服务起来之后先用 curl 验证一下curl http://localhost:8000/v1/models如果返回模型列表说明服务正常。然后测试推理接口curl http://localhost:8000/v1/completions \ -H Content-Type: application/json \ -d { model: ./gemma4-7b, prompt: 介绍一下你自己, max_tokens: 100, temperature: 0.7 }如果返回了生成的文本恭喜你部署成功了。整个过程如果顺利的话确实能在 15 分钟内完成——前提是模型已经下载好了。Python 调用的话直接用 OpenAI 的 SDK 就行from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keydummy # vLLM 不校验 key随便填 ) response client.chat.completions.create( model./gemma4-7b, messages[ {role: user, content: 用一句话解释什么是 ROCm} ], max_tokens200 ) print(response.choices[0].message.content)注意api_key这里随便填一个非空字符串就行vLLM 默认不做鉴权。如果要对公网暴露记得在前面加一层反向代理做认证。4. 性能调优与常见坑4.1 吞吐量上不去的几个原因服务跑起来之后下一步就是看性能。我实测下来影响吞吐量的因素主要有这几个KV Cache 分配不足。--gpu-memory-utilization设得太保守KV Cache 块数不够请求一多就开始排队。可以适当调高但别超过 0.95留一点给系统。max-model-len 设得过大。这个值直接决定每个请求最多占多少 KV Cache。如果实际请求的上下文都很短设成 8192 甚至 16384 就是浪费。按实际需求设比如 4096 或 2048。batch size 限制。vLLM 默认会尽可能多地批处理请求但如果显存不够它会自动降低并发。观察日志里的running和pending数量如果 pending 一直很高说明并发被限制了。CPU 瓶颈。tokenizer 的处理是在 CPU 上做的如果 CPU 核心数太少tokenize 会成为瓶颈。云实例选型的时候注意 CPU 和 GPU 的配比。4.2 ROCm 特有的注意事项在 AMD 上跑 vLLM有几个坑是 ROCm 特有的跟另一套生态不一样。环境变量。ROCm 依赖一些环境变量来定位库文件。如果手动编译过 vLLM可能需要设置HIP_VISIBLE_DEVICES来指定用哪张卡。云实例一般已经配好了但如果你自己装记得检查。版本匹配。ROCm 版本、PyTorch 版本、vLLM 版本三者之间有严格的对应关系。比如某个 vLLM 版本要求 PyTorch 2.3 以上而 PyTorch 2.3 又要求 ROCm 6.0 以上。装之前先查兼容性矩阵别盲目 pip install。编译时间。如果从源码编译 vLLM 的 ROCm 版本编译过程可能长达半小时到一小时。云实例如果预装了 vLLM就跳过这一步。如果没有预装建议直接用官方提供的 wheel 包别自己编译。显存碎片。ROCm 的显存管理在某些版本上不如另一套生态成熟长时间运行后可能出现碎片。如果发现显存占用越来越高但吞吐量下降可以重启服务。注意ROCm 的rocm-smi显示的显存占用和 vLLM 日志里的数字可能有差异这是正常的。以 vLLM 日志为准因为它统计的是实际分配给 KV Cache 的部分。4.3 常见问题速查我把部署过程中遇到的问题整理成了一张速查表方便你快速定位现象可能原因解决方法启动时报 HIP errorROCm 运行时异常重启实例或检查 rocminfo模型加载到一半卡住磁盘 IO 慢或权重文件损坏检查磁盘重新下载模型推理结果乱码tokenizer 不匹配确认 tokenizer 文件与模型对应服务无响应显存耗尽被 OOM kill降低并发或显存利用率吞吐量远低于预期KV Cache 不足或 CPU 瓶颈调参并观察日志多卡并行报错RCCL 通信问题检查卡间互联和 RCCL 版本4.4 我踩过的三个坑第一个坑是模型路径用了相对路径启动服务的时候工作目录不对导致找不到模型。后来改成绝对路径就没事了。这个坑很蠢但确实容易犯。第二个坑是--gpu-memory-utilization设成了 0.95结果跑了一段时间后系统开始杀进程。原因是 ROCm 本身也要占一部分显存留的余量不够。后来改成 0.85 就稳定了。第三个坑是没注意 vLLM 版本和 ROCm 版本的对应关系装了一个不兼容的组合启动直接报错。后来查了兼容性矩阵换成匹配的版本才跑通。这三个坑的共同点是文档里不会写但实际部署时大概率会遇到。所以我的建议是第一次部署的时候把日志级别调到 debug多看日志遇到问题先查日志再动手改。5. 这套方案还能怎么扩展5.1 多模型共存与切换一台实例上跑一个模型有点浪费。vLLM 支持在同一进程中加载多个模型吗答案是不直接支持但可以通过启动多个服务实例来实现每个实例监听不同端口。比如一个实例跑 Gemma4另一个跑一个代码模型分别监听 8000 和 8001。然后在前面加一个路由层根据请求内容分发到不同的后端。这样一套硬件就能支撑多种任务。不过要注意显存分配。两个模型同时加载显存要够。如果显存紧张可以用 vLLM 的--swap-space参数把部分 KV Cache 换到内存里但会牺牲一些速度。5.2 量化版本的尝试如果显存不够或者想跑更大的模型量化是必经之路。ROCm 上支持的量化格式主要有 GPTQ 和 AWQ。vLLM 对这两种格式都有支持但需要模型本身是量化过的版本。量化的好处是显存占用大幅下降7B 的模型量化后可能只需要 6-8GB 显存。代价是精度会有一定损失具体损失多少取决于量化方法和校准数据。我试过一个 4bit 量化的模型推理速度比 FP16 快了不少生成质量在日常对话场景下几乎看不出差异。但如果你的任务对精度要求很高比如代码生成或数学推理建议还是用 FP16。5.3 从实验到生产的距离云实例上跑通只是第一步。如果要上生产还有几件事要做稳定性。实验环境可以随时重启生产环境不行。需要加进程守护服务挂了自动拉起。监控。要能实时看到 QPS、延迟、显存占用、GPU 利用率这些指标。ROCm 提供了rocm-smi的命令行接口可以写脚本采集。扩缩容。流量高峰和低谷的差距可能很大需要能动态调整实例数量。这就涉及到负载均衡和模型预热的问题。安全。vLLM 默认不鉴权对公网暴露必须加认证。最简单的做法是前面挂一个 Nginx做 Basic Auth 或者 Token 校验。这些话题每一个都能展开讲很多这里先点到为止。核心思路是实验阶段怎么快怎么来生产阶段怎么稳怎么来。5.4 关于成本的一点计算最后算一笔账。云实例按小时计费假设一小时几块钱跑一个实验性质的部署每天用两小时一个月下来也就几百块。相比买一张支持 ROCm 的显卡动辄几千上万云实例在验证阶段的经济性是很明显的。当然如果长期高频使用本地部署的边际成本更低。我的建议是先用云实例验证方案可行性确认要长期跑了再考虑本地硬件。这样既不会浪费钱也不会因为硬件问题卡住进度。ROCm 这套东西说实话成熟度还在爬坡阶段。但它的开源特性和性价比优势是实打实的。如果你愿意花点时间摸清楚它的脾气它能给你带来不一样的体验。我个人的体会是别把它当成另一套生态的替代品而是当成一个独立的、有自己特点的平台来对待心态会好很多上手也会快很多。
